[Mod] Skinsdb [skinsdb]

[KongarTheTerrible]

Update - I completely deleted all textures, the actual skinsdb again. I installed another mod simple_skins that apparently uses the same filenaming convention, meta txt files etc.

I only uploaded my "new skins/textures" - therefore zero default skins, zero of the previous deleted. Starting my server. Boom. same problem default and old skins retained.

There should absolutely be for skinsdb or simple_skins mod - mod as in mod-module as in 20+ years of module proper programming design be the ability at minimum to clear whatever main engine (minetest) cache or other mod file holding a setting. Very lame.

Same question exists. I cannot find anyway or anywhere to flush, clear, edit and remove the skins. Next step to saver time I guess I will just delete i3 mod. And reboot. LAME. Will update in a minute.

[KongarTheTerrible]

So... next I entirely deleted the skindb from server, replaced with skimple_skins with entirely different skin textures, meaning zero old one from aforementioned install - zero old files, mods, texture files, txt even present.

I then also deleted i3 and uploaded a fresh new copy. Rebooted, launched server.

All the first old skin texture nor their mods are even on the server yet still retained and displaying no matter what i do. I heven removed all the texture files and their mod, replacing naked i3 and simple_skin

meaning some other "module" or component of minetest obviously made a copy of actual skin files + textual data to retain them ,even when i deleted them and their respective mods. Very very very very very poor.

Any help? I guess I will spend another hour of my life combing all other the inventory mods/other I have on server.

Inventory related mods on server:
appliances
cg_plus
clothing
craftguide
i3
items_update
sfinv_bags
simple_skins

:(

[KongarTheTerrible]

Yet I searched quick for copies of the texture png images and found nothing. Nothing here makes sense nor logic.

So I installed a sqlite browser and now inspecting mod_storage.sqlite

The answer: Nope. nothing. Only 23 rows in the sqlite. Checked rest of files in world folder. Nothing.

:/

UPDATE: So nothing in worlds folder. I next deleted all inventory/skin texture mods except for the fresh new copy of i3 and simple_skin (no different than skindb, they re interchangeable, same method with character_.png files and meta.txt)

So just i3 and the skin mod for textures. Old textures from first set still retained. This is preposterous and absolutely ridiculous that nothing in the mods actually handling such textures in game/world folder handle these!
Next I guess I have to go to root level for core minetest files. Pathetic.

No other mod or minetest core engine component should be "hijacking" this, but apparently it is doing so.

I would like to be able to add/delete skin textures manually and have them updated, but:
- no skin mod (skindb, simple_skin - same method) or associated inventory gui does this - fact. Fact proof here
- worse, nothing in world folder and either the minetest core or another mod (perhaps server related is preventing this, but regardless, this should not be happening due to the fact the only other possible server mods were grabbed from the content database.

If anyone knows or has a clue of engine files or otherwise to check, please let me know and i can obviously check them for this significant minetest problem to find the culprit.

I obviously can just take my backup clone copy and upload to server with a "first set" of skin textures, but that is not ideal for me or others bound to encounter this issue preventing simple manual update, ie. adding, removing new/old textures for skins.

EDIT: And to clarfiy be exact about mods and my site structure.
I have a clean root, meaning mods/ at the root level of server is EMPTY. ZERO mods that might have been activated. My world is also 'clean' meanings zero /worldmods. The minetest game hold the only mods folder with any mods (all aforementioned), so there is no possibility of cascading or conflicting/overwriting mods at all.

The only thing left to do is now basically delete all server-related mods, but why I am doubting this is going to be the issue? I am simply deleting and reducing these done to minimal as last attempt to 'debug.' will update one more time...

Thanks. See last few posts for fine details.

[KongarTheTerrible]

There is a very very stupid and bad "bug" I am discovering on minetest. The problem is something larger than this discussion of this mod or even really directly relation to it (yet it will cause such issues). Really, I can't believe it. I am doing some finally testing to confirm and if confirmed than will report in a better thread and delete these... stay tuned.

AND PS. It is is not fatal to the game, but it is in a manner of speaking to config that could have and should have been prevented similar to server launch abortion if there is a mod conflict or incorrect path that should have effectively prevented server from launching/mismatch.. so silly, so so silly. time wasted out of silliness.

[KongarTheTerrible]

UNREAL.

So I cleared all aformentioned mods, checked settings. clear server structure.
root level (minetest folder on production server) ==> minetest.conf
games/mygame_id ==> textures/
games/mygame_id ==> mods/
worlds/myworld

in minetest.conf explicitly set gameid, world, also set a enable_client_modding = false (which did not 'seem to work')

There are zero textures or mods on production server. I then after making sure ALL PATHS are correct.

PS. MAJOR GRADE-F coding on minetest:, ex.
if one issues command to launch server with these arguments:
$ ./bin/minetestserver --gameid mygame --worldname myworld

then if there is any conflict or inconsistency in any other minetest.conf in path then the server should absolutely not launch the game, similar to a error or inconsistency for mod.conf. But it does anyway. I digress on this problem.

But finally with all mod, textures removed from server I had to assume that my localhost install of minetest client (separate naturally from my production server, on a completely different server, ip etc) might be appending, overwriting or appending mods, regardless of my configuration settings.

Quick solution, similarly, I deleted the localhost .minetest folder completely. and rebooting the production, remote server and connected via local client.

I also in this case, to clarify have zero local mods. Zero remote inventory gui mods like i3 on remote server! I added simple_skins and added only a handful on new unique textures.

#1 i3 does not even exist anywhere on local or remote server.
#2 none of the old textures also exist nowhere in local .minetest or remote minetest folder, such as actual files/filename .png (searched thoroughly) and no i3 etc.

I am serious here. minetest.conf at root level checked, gameid and world specified. no other worlds games present on local or remote. Launched server. connected via fresh empty .minetest client..

WOW. So join game from client. i3 is still showing unbelievably. and guess what? the old first launch (the first time i launched the game/gameid!) all there.

So there is no intereference or client-side mod effect here now.
And zero i3 mod or texture files present on server.

The only thing left to do, which I know will just work is create a new GAME fresh, add the mods, including i3, simple_skin (insread of skinsdb simply for variation in testing at first launch) and finally the 'new unique' sample skin textures.

I bet a million bucks, server will launch just fine with a NEW GAME CREATED as it seems impossible to alter the current game, it is somehow corrupted - that is the truth here. And finally the correct textures will show. VERDICT A (BOOL, true/false)... TBD [1]

Next, I will simply attempt to delete these 'new unique' sample skins' and reboot server to see if gone. And then add a handful reboot etc. VERDICT B (BOOL, true/false)... TBD [2]

But right now it seems there are major bugs and problems with minetest, especially considering allowance of misconfigured or contradictory game path settings, perhaps this caused a corruption. Very very poor. Not a good way to spend an entire Friday night. LAME.

Be back with yet another update. Will creating a new game work. Yep, of course. But this is a fatal bug. Creating a game instance or world instance should never be prone to corruption. I noted this earlier this year and a few years ago in regard to launched new world where there were mods (in the contentdb, just like these) that can do damage. Here I believe by logic it is from the minetest core and simple programmer 101 that a server should not be able to be launched with configuration error, mismatch or inconsistency. Unbelievable.

Be back shortly...

PS.
./bin/minetestserver --version
Minetest 5.7.0-dev-cf5add1 (Linux)
Using LuaJIT 2.1.0-beta3
BUILD_TYPE=Release
RUN_IN_PLACE=1
USE_CURL=1
STATIC_SHAREDIR="."
STATIC_LOCALEDIR="locale"

local client v5.6.1

[KongarTheTerrible]

Answer part 1

I bet a million bucks, server will launch just fine with a NEW GAME CREATED as it seems impossible to alter the current game, it is somehow corrupted - that is the truth here. And finally the correct textures will show. VERDICT A (BOOL, true/false)... TBD [1]

VERDICT: YEP, exactly. TRUE. Game generated new world fine. And uploading all the exact same files, i3, skinsdb (I did not do simple_skins ala carte because error via i3 requiring the skinlist.lua that only skinsdb mod provides)

So, yea, what is the explanation - definitively!! "game" [ minetest/games/mygame ] got corrupted for no good reason.

Now I move on to the second verdict, replicating exactly by simply attempting to add a few new textures to skinsdb/textures, reboot server and check. Finally a shutdown and delete the same textures just added and reboot..

stay tuned, shortly...

[KongarTheTerrible]

Next, I will simply attempt to delete these 'new unique' sample skins' and reboot server to see if gone. And then add a handful reboot etc. VERDICT B (BOOL, true/false)... TBD [2]

AND... again as suspected, all worked fine by creating a new game. I suspected early on that something was amiss. And this might seem harsh, but amiss with very poor coding - botched coding of Minetest.

2-3 years ago (probably I dropped out of Minetest from the v4 to v5 migration period. Some people probably did not like what I had to say.

Coming back to build a server (for kids to help them interact, build basic skills and build a server for US) I literally spent 2 WEEKS of my life (like last time ending up quitting due to issues).

Well, this time I built a server on production that will work. I do not intend to spend the time making one ever again but do logically hope to use the server I built and retain it for the next 20 years.

The last step of my server build was to simply integrate/add skin texture. The truth and devs should take note (and damn seriously) is that the issue I outlined here should have never ever happened. What happened "game" (as in games/ corruption plain-and-simple and absolute..

For posterity, I have the details of Minetest core compiled direct from github on a a secure well-maintained VPS. I have many years experience as an expert admin and not a dummy.

Tonight I spend 7 hours messing with this problem, knowing from beginning I did not have to volunteer my time and simply re-create a new game and problem would likely be solved. But instead I did document what should you, the devs to be able to finally fix a very simple problem.

So here's my advice to minetest users from EXPERIENCE:
1) When you build your server, start small, add core essentials you want, launch server only from commandline terminal, so you can see any errors, but not only that warnings and correct the code. In 2023 probably 70%+ of official minetest contentdb (v5.6/5.7-dev) post v5.0 have PROBLEMS, meaning deprecated code that still have 3 years never fixed, yet is on contentdb.

The good news is that the terminal will tell you the correct syntax and line # in lua files and you can correct.

2) Backup and save. Especially when playing with old mods that I noted 3 years ago and in 2/2023 today - your "world" can and will get corrupted from bad code/mods.

Worlds is one thing, "Game" is another ie. minetest/games folder. Meaning you can build a "game" or build with its own mods, same as if you alternatively constructed a build based on /worlds/yourworld folder with /worlds/yourworld/worldmods folder.

For the aofrmentioned reason this time I decided to just generate world and instead use a "game"/mods hoping it would not be corrupted.

Note there are 3 tiers of server launch arguments that happen

$ ./bin/minetestserver --gameid mygame --worldname myworld

or on your local computer minetest is the command I suppose. But a game is select via commandline or the gui and finally a world.

Neither ideally should be able to get corrupted, especially on the higher level. A game is always required then a world specified.

What I discovered tonight, even worse than a world getting corrupted, such as by a bad mod, which is not a big deal WHILE building a server/mods build, is that my actual Game irreversibly somehow got corrupted.

NOW for devs:

consider these three structural levels of minetest:
root level ==> minetest/mod.conf
games/mygame_id ==> textures/
games/mygame_id ==> mods/
worlds/myworld

By design these *SHOULD* (a) cascade properly, meaning if you have minetest.conf or other setting files PARENT/ROOT (minetest folder) > GAMES (game_id aka game folder) > CHILD/WORLD (world folder) further within this chain they should naturally override , just like real servers should, ie apache and by convention or evern simple things like stylesheets.

But I noticed this was not happening. It is a development error. It needs to be corrected. You can argue that it is, in my view and experience, it is not.

Next, worse. I purposefully get only one minetest.conf at root/minetest level. You have fields that provide paths to worlds, game (I can't remember offhand because I removed them! AND this type of reference is not good enough, implying it should be better pronounced and available, such as even a simple txt file (rich format as will be default on linux/common apps with linebreaks so no problem) outlining every crucial server admin optional (in fact every single option for release --- this is not present!!! WHY??? No excuse, dev/doc fail extreme)

ex. minetest.conf.example

Nowhere are the path or many, many ocnfig optional that 99% of people above casual end-user NEED. WHY? It's ridiculous. Dev/doc fail.

Also, 2 major flaws, easily correctable in less time I spend tonight in 7 hours to fix this ASAP and will save collective 100s of hours fro screwing the end-user:

1) ex. ex.
selected_world_path = some incorrect path, notmyworldinlaunch_argument
game_id = notmygameinlaunch_argument

if this path (and other similar settings) does match

$ ./bin/minetestserver --gameid mygame --worldname myworld

then the server should not execute and crash exactly like it does with a mod conflict. from my test I believe this could lead to unexpected GAME corruption.

these should be fixed as a priority.

2) "enable_client_modding = false" to your minetest.conf

Seemingly this parameter exists but 100% do not believe it works at all. Similarly I do believe 99.9% that client minetest mods, game/world folders running on localhost may conflict when accessing production server instances on an entirely different ip (of course) as seemingly impossible/ridiculous as that sounds, especially in tandem with point (1) above.

Something is not right, drastically not right.

And regardless of any debugging theories, point (1) is absolutely not protected or consistent, just like mod conflicts, path conflicts are not acknlowledged in config file, which is a simple flaw.

And better, there 100% should, no rational, logical or respectable argument could be made for not having a setting allowing at least a remote server instance having the ability to prevent any hack/modding/overwriting/appending/addition to such a game or world.
enable_client_modding = false
should be setting (and one in a default doc like minetest.config.example) along with other that allow admins to exercise complete control over all textures, mods, gui, etc.

Messing around like I did tonight, I have little confidence in the cascading config; I also wish I had a pinned unmissable reference cheatsheet for minetest.config and other with 100% complete settings rthat are indeed honored and tested.

I did not expect a game/build to get so easily corrupted with the exact same files (sans a few textures) that I am running right now. What changed?? Something likely releated to my advice above - simple rules that are not locked down.

I had 2-3 worlds and 2-3 games intheir respective worlds/ games/ folders and likely same name on my localhost system with same names. 110% none of these should have caused problem.

I may have had
selected_world_path = world2 [minetest.conf]
differing from the commandline argument
$ ./bin/minetestserver --gameid mygame --worldname world1

whether this was the culprit, I don't know. But if it was or if it wasn't all my prior statements are TRUE. BOOL.

to quote Mr. T,

My momma didn't clean up floors so I could be a thug... so I could wear my pants down.

Good luck, hope this data and 7 hour debug session HELPS.

[KongarTheTerrible]

And to users of skinsdb. If you encounter a frustrating issue of your manual adds/deletions to your skinsdb/textures not working, it is because your literal game or world is corrupted (probably game, ie minetest/games folder).

If you like your world how it is, zip it up, date it. Then test on new world. If issue persists, the minetest_game or whatever game you have is corrupted. Keep a virgin a copy backed up.

Ref: v5.6.1 linux / v5.7-dev

[Nininik]

bruh I removed the mod and now my wieldhand is an unknown item


help

[Unacceptium_core]

there is a webpage wich had a lot of skins. now rhere isn't. i dont know if that webpage is yours... any info why its down?

[wsor4035]

NOTE: cross posting this on both the skinsdb (mod) and skinsdb (website) thread

yesterday i threw together a quick a dirty drop similar api at http://skinsdb.terraqueststudios.net/api/v1/content as the existing one has been down multiple times in the past, and has been down currently for a few months now. A pull request has been submitted to the skinsdb mod at https://github.com/minetest-mods/skinsdb/pull/91 to use this api (will see how long minetest-mods lets it rot in traditional fashion). hopefully soon I will have a read only/static listing of the skins available on the root of the domain.