Mod programmer : how, where do you test your updates ?

[Festus1965]

Today I missed to update
* cool_trees
* plantlife_modpack
on my 5.2.0 server.

Are there server, main then 5.1, 5.2, 5.3, 5.4.1 and 5.5 "official" server, where you can confirm your changes that will run under several still OPEN versions, even as 0.4.17 ???

What brings me to another Idea, that there maybe kind of test server (official mod testing) in every main mt version, that are just there to show new version of your mod is running or not under this ...

sure not easy as no all ! mods will run same time on one server.

[Komodo]

Thats a good question. How can you test mods on multiple versions of Minetest easily to check for compatibility?

If im remembering correctly, ContentDB asks for a lowest version required for a mod's compatibility too.

I would be interested in seeing if this is anything anyone else has methods for this or if its even worth worrying about.

[Festus1965]

Are there server, main then 5.1, 5.2, 5.3, 5.4.1 and 5.5 "official" server, where you can confirm your changes that will run under several still OPEN versions, even as 0.4.17 ???

What brings me to another Idea, that there maybe kind of test server (official mod testing) in every main mt version, that are just there to show new version of your mod is running or not under this ...

would be a server on every version since 5.0 main that is still possible to load and us with the belonging minetest_game ... where
* only this mod is tested after an update ... what need also to have the set of depreciated mods same version there also
* maybe all mods (not possible as some are doing same) are running

that is really a problem,
I just try to imagine I have my server just for fun in 5.01. 5.1, 5.3, 5.4.1 and 5.5 beside to be able to test from what version back a updated mod fails.

So that THIS maybe to not possible, I guess need a report back system to tell programmer ... your mod x failed on my server version 5.x ... mhhh

hmmm
first solution ... not update if no problem

[TenPlus1]

Test your mod initially on a singleplayer and multiplayer world locally on your own pc, upload to contentdb for others to use and test, and maybe create a new server of your own to test thoroughly :)

[davidthecreator]

Test your mod on the oldest version you expect it to work on and the latest and if it works on both, it probably will work on all versions in between

[Blockhead]

Here's would I would do: I would compile every Minetest version you want to test and keep them in separate directories. So for example:

Code: Select all

$ ls -1 ~/minetest_testvers
0.4.16
0.4.17.1
5.0.1
5.1.1
5.2.0
5.3.0
5.4.1
5.5.0

Build the server and the client for each version and build with cmake . -DBUILD_SERVER=TRUE -DBUILD_CLIENT=TRUE -DRUN_IN_PLACE=TRUE. It is important to keep separate directories and not put all your binaries in one directory mostly because the code in builtin needs to match the engine version.*

*(you could use git worktrees instead of separate clones, and keep your bin directories symlinked, and have /home/user/minetest_bin/minetest-0.4.17.1, minetest-5.5.0 etc, but let's not overcomplicate it).

After compiling every version you want, install the appropriate version of Minetest Game (or whatever game you want to test with) into each Minetest directory as well. Then symlink the mods directory in each of these minetest directories to the same mods directory, so it looks like this

Code: Select all

$ ls -l ~/minetest_testvers/5.5.0/mods
lrwxrwxrwx 1 user group 30 2022-02-12 18:22 mods -> /home/user/.minetest/mods

That should let you vary your engine version easily while you keep your mod set the same. Then you can check your mods are compatible with all these engine versions. If you also wanted to test different sets of mods at different times you could use two levels of symlinks like this:

Code: Select all

$ ls -l ~/.minetest/mods/
lrwxrwxrwx 1 user group 30 2022-02-12 18:22 mods -> /home/user/minetest_mods_set_a

It gets a bit more complicated with world files: You might want to test on the exact same world files each time as well. However with 5.5.0 you can't use the same world files since the world format has changed. You could still symlink the same worlds together for 5.0.1-5.4.1 though. Also you might want to test what upgrading your world 0.4.17.1 -> 5.5.0 does (not necessarily straight from 0.4.17.1 to 5.5.0, but probably with at least one other intermediate version)

If you had a lot of hardware you could run all your different servers concurrently and permanently if you really wanted, and reboot them when you have changed to mod set. They can't share the world files in that case, though that sounds kind of fun to try :) The other servers would probably freeze due to not being able to get a lock on the map.sqlite database, just like when you play on a server with world downloading and try to play singleplayer on that world at the same time.

Test your mod on the oldest version you expect it to work on and the latest and if it works on both, it probably will work on all versions in between

This will only work assuming there are no regressions in the intervening versions, but may be good enough for a lot of cases. I haven't followed Minetest closely enough to know if this has been a problem.

[Festus1965]

nice,

but I don't program any mod ... anymore

as I don't know for which version I should do

I wanted to know from the main programmer, how they proof their mod works on x version and how this is seen CLEAR ... run on 5.2 until 5.5 like

[Festus1965]

other side also,

if your mod need to have dependencies, which version is then important for you
* only the newest ...
* or do you try also that older versions
even beside different engine versions ?

I guess, this is a lot of fun ... work

[Komodo]

Here's would I would do: I would compile every Minetest version you want to test and keep them in separate directories. So for example:

Thanks for the helpful answer. I was thinking something locally like this using directories. Much easier than maintaining seperate virtual machines or servers.

[Mantar]

I just have a minetest git set up. I compile the binary (say, 5.5.0) and rename it to bin/minetest-#.#.# and have a script that does a git checkout and runs the appropriate version, like "./run.sh 5.5.0" will do "git checkout v5.5.0" and "bin/minetest-5.5.0". I can run any version of minetest I have compiled with one command.
It occurs to me I could easily extend the script to also compile and rename the binary if it doesn't exist.

[Festus1965]

as last 3 options it seams not to also use the right version of MTG ... that should be also included
or did I miss a option to load the shared files from several individual version fixed folders ?

[Mantar]

I don't do any MTG code, being focused on Exile, but the script I use could also be extended to cd into the MTG directory and check out an appropriate version of that as well.

[Linuxdirk]

I test my mods in my local environment using the most recent officially released non-dev version of Minetest. All of my mods are checked for compatibility with this version and neither do I care for outdated versions nor dev versions of Minetest or Minetest Game (if the mods are game-specific).

for 3rd party mods I just update. Since I try to keep my mod footprint small that's not a big issue :) If a mod breaks I check out the previous git commit and live with it till it's fixed upstream.

[Festus1965]

yeah,
this problem is always actual as just seen at:
* homedecor_modpack
* unified_inventory

maybe solution like this ? : table of engines against mods and their commits

[Festus1965]

yes, a nice proof how changes in engine ... hit mod programmers !!!

anyways, for people reading this for future reference, the reason the error existed is because homedecor hardcoded and assumed the mesh (from mtg doors mod) would always have the same name and extension(.obj). PR https://github.com/minetest/minetest_game/pull/2906 changed this, so the commit i linked fixes this, some alpha warnings, and cleans up legacy code in one go.

Festus: if you want to run outdated code, feel free, but dont expect support for it and/or if you make custom forks/patches. additionally, please stop spreading misinformation.

So for ME I see only one change to make most sure to get most best fixed mod to engine compatibility is:
Download all mods you use maybe the day before a new engine gets out.
Yes, some mods might be faster actual for the new version, but MOST i see comes after.

This mean, you are always one engine release behind, but with the highest promise of less problems.

So in the moment, as of the lack of missing information INSIDE the mod download, hard coded in init.lua, about for what engine version, and maybe even what depend mod version this release is meant ... it will not get better.


- - - just investigating a bit: as of homedecor_modpack door_a.obj

09.11.2021 - started discussion about obj or b3d, and
24.01.2022 - merged in new mt engine version
12.02.2021 - commit object change in homedecor_modpack
24.02.2021 - release of 5.4.1 - maybe with new model
31.01.2022 - release of 5.5.0 - sure new model

look very careful this timeframe ...
so there was then a new mod version with commit new models, that was released BEFORE the belonging enginge with this change was out. Gap about 12 days !

MEAN ! the nice speech take newest version (just look his comment before haha) was absolute WRONG between 13. and 23.02.2021 for keep engine 5.4.1,
or this update should include a hint that need to run on 5.4.1 and later ?

[wsor4035]

i quote myself
"Festus: if you want to run outdated code, feel free, but dont expect support for it and/or if you make custom forks/patches. additionally, please stop spreading misinformation."

your dates are completely wrong regarding when things happened, as anyone can verify by looking at git.

09.11.2021 - started discussion about obj or b3d, and - if you read your link, can see it actually started on Nov 8, 2021
24.01.2022 - merged in new mt engine version - again, read your own link, merged on Dec 12, 2021
12.02.2021 - commit object change in homedecor_modpack - by your own link, merged on Feb 11 2022
24.02.2021 - release of 5.4.1 - maybe with new model
31.01.2022 - release of 5.5.0 - sure new model - 30 Jan 2022. https://dev.minetest.net/Changelog

additionally the change is backwards compatable as it dehard codes the mesh reference

[Festus1965]

31.01.2022 - release of 5.5.0 - sure new model - 30 Jan 2022. https://dev.minetest.net/Changelog

nice again,
and search for Mesh (15 Matches) I find too much, so what Mesh + words would show me exact that solution ?
I don't find the line that tells me, guess main change from obj (no match) to b3d (no match), where/then this happened and might be further able to guess what mods will be effected and need update in code and then on server.

Hey, I am a bit lucky, that I can read a bit code, but most admins don't!
And to search all commits / ... for whatever words are used ... can't be the way.

And again, if your (all mods) code include a clear line, that this version is running on engine version x-x all this problems might be easier,
as even during a change on the server, the admin can look this one line and see clear the ONE person, coding this mod, tell me clear that I need here engine/game x until x , or only one.

I am sure a lot of issues might be gone, useless forum requests are less ...

As devs made very late clear that engine and game version must be same ... happened somewhere near 5.3.0,
I am sure you as programmer of mods have to state that also ... easy to see inside code,
NOT make need of guess around, as once downloaded there is no any trace anymore about what version or commit is was.

Since I use this memory in init.lua of every mods with
* link I got it,
* version date it is
* missing now to add that sure version it is made for (min, max, range)
It is much easier to find out THAT there is a new version, and maybe compare to new one.

When I think back to my time at German Army position database manager Oracle we was far further in that problems I see here now ... 20 years later. There was a clear inbound note about to what sql version the html/php belong to and other direction.
database, sql and php had to fix together, even we run only one version life, and one testing version where always all three components had to be same together fixing version.

When I got a call and re-ask this data - they just got silent, oh ... "ok, got it", and done. Thay forgot to inform the other both partner groups to inform active about their change and ask for a fix.

So what I miss here at minetest mods is now a clear statement, that is inside the running code of a servers PC, to find this: version, date, belonging engine version,
as I know devs give a shit on the mods running ... for their changes.

[Festus1965]

- - - just investigating a bit: as of homedecor_modpack door_a.obj

09.11.2021 - started discussion about obj or b3d, and
24.01.2022 - merged in new mt engine version
12.02.2021 - commit object change in homedecor_modpack
24.02.2021 - release of 5.4.1 - maybe with new model
31.01.2022 - release of 5.5.0 - sure new model

wsor4035 : are you a bit sick ?

your dates are completely wrong regarding when things happened, as anyone can verify by looking at git.

09.11.2021 - started discussion about obj or b3d, and - if you read your link, can see it actually started on Nov 8, 2021
24.01.2022 - merged in new mt engine version - again, read your own link, merged on Dec 12, 2021
12.02.2021 - commit object change in homedecor_modpack - by your own link, merged on Feb 11 2022
24.02.2021 - release of 5.4.1 - maybe with new model
31.01.2022 - release of 5.5.0 - sure new model - 30 Jan 2022. https://dev.minetest.net/Changelog

why you call it "dates are completely wrong" when
* one date is correct,
* 3 dates are 1 day different as of my difference in time zone !
* and one date is a month different as of different understand how I see it ?
that is sick of you ! and so a false, when even not lied status.

"Festus: if you want to run outdated code, feel free, but dont expect support for it and/or if you make custom forks/patches. additionally, please stop spreading misinformation."

and there IS a DIFFERENCE in failing or outdated code.
As you see there is still running 0.4.16 and mods for that version that might be outdated, but still less failure than 5.6.0 that needed a 5.6.1 anyway.

I run over this theme after I have seen 5.6.1 and now pointing on a luacheck tool, that was missing here also.
But luacheck search for lua code mistakes, but will not be able to find a change of var names or used values.