FOSS gamedev and creative worlds

minetest-technic/technic is the original mod, other versions are something between out of date and changes ahead

So...basically just rely on when something was last modified?

Cryterion wrote:I've noticed this is still the case, any suggestions on a workaround to rather having to modify any updates everytime!

Cryterion wrote:Hi

had a bit of a problem trying to register an mv machine to be used in another mod, and found the following code changed fixed the naming convention error I kept getting

in /technic/technic/machines/register/machine_base.lua

line 126

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

minetest.register_node("technic:"..ltier.."_"..machine_name, {

change it to

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

minetest.register_node(":technic:"..ltier.."_"..machine_name, {

and line 158

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

minetest.register_node(":technic:"..ltier.."_"..machine_name.."_active",{

changed it to

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

minetest.register_node(":technic:"..ltier.."_"..machine_name.."_active",{

It still keeps technic functional, but will allow other mods to register lv,mv and hv machines if they wish to use the technic functions.

It may be possible for the mod to set a global variable "modname", with the string value "technic" assigned; this is then concatenated to the machine's id in the register function call, before the colon. It would look somewhat like this:

Then, any mod adding technic machines must also assign the "modname" global variable to the correct mod name string (which is of course the name of the folder which the mod is in). This way, whenever the mod adding more machines is loaded, it always uses its correct mod name as the prefix, and the naming convention is always followed (as long as that global variable gets set before the mod which adds more machines is loaded, of course). I believe this is better than using the prefix colon, which is intended for overriding registry entries which already exist (if I remember correctly).

However, I am not sure if this will work smoothly with the rest of the technic system, as I have not used it much (at all). You will have to test it to determine if it would work in this case. I have tested it with simple nodes and items, though, so this does work as long as the mod doesn't do something weird and complicated-ish which would require all of its nodes/items to be registered with the same mod name in the id string. I am not totally sure why this does work (possibly an effect of how mod loading order is implemented, and the naming convention as well), but it does work, and it doesn't introduce any (yet visible) bugs with the nodes/items registered this way, so I believe it is safe to use this as a feature without the risk of it getting totally deprecated and removed in an update some time later.

I discovered this when I was working on a mod, said mod adding several functions which wrap some of the minetest.register_*() functions. The mod is intended to be used to register items/nodes/whatever easily, by having the functions produce from a few input parameters all of the necessary parameters which are needed by the registry function call. I thought there would be a problem with the mod name used as the prefix of the id strings of the registry entries - so I did this simple experiment to see what happens, when the name of the mod which calls one of those functions is used as the prefix for the id of the registry entry, using a global variable to keep up with the mod name, and it worked on the first try. I didn't actually believe that it would work (I didn't know either way), so I was surprised when it did work.

EDIT: This only works if the code of the Technic mod is changed, to use a "modname" global variable as the prefix for registry entry ids. You can not do this from the side of another mod.

You may be able to interface with the Technic system without using the registry function call which is inside its code (make your own function which sets the metadata values correctly, maybe making an entry to relevant tables in the Technic side if that is necessary), but that may be significantly limited and very hacky, depending on how the technic power system works. I have never looked at the Technic power system much, and I am planning to make a power systems library that might be more use-able - however it will not be intended to replace Technic, since it is best to do one thing and do it well, instead of trying to do what everyone/someone else is doing except better somehow.

minetest.get_current_modname is a thing too

Byakuren wrote:minetest.get_current_modname is a thing too

That may also be useful, in the event that a developer wants to be able to change their mod's folder name without causing any errors within. However, it is much longer than simply doing modname = <mod name>, unless your mod's name is more than 17 characters long.

It could be used to prevent being bugged by newbies who haven't happened to learn that you must rename the mod folder to <modname> instead of <modname>_master as it is fresh off of github, but that is the only other use for it which I know. It is pretty annoying, and I can see how this could be added just to give a way to easily take care of that.

So it would be best to concatenate minetest.get_current_modname() as the prefix to all of the ids in all of the registry function calls. Then it doesn't matter what mod is loaded, and said mods don't have to set any global variable - they can call the wrapping function directly, and all of the created nodes/items/whatever will get registered with the modname prefix of the mod which is loading when the registry function call was done.

Edit: When I was doing that experiment I mentioned, I thought that there was a minetest function that gets the current mod's name, but I couldn't remember the call at that time, so I just set it directly. I should have looked for it after the experiment, and replaced the global variable with that function call.

So it would be best to concatenate minetest.get_current_modname() as the prefix to all of the ids in all of the registry function calls.

This is what I meant to suggest, sorry for being vague.

technic/technic/machines/MV/lighting.lua has outdated intllib boilerplate code, which has a dofile to a directory outside this mod. This is a violation of mod security, which means your mod might break when both intllib and mod security are enabled at the same time.

I have not experienced a direct failure because of this, but please update the boilerplate code anyway. It might be a hidden bug.

See here for the new boilerplate code:
https://github.com/minetest-mods/intllib

is this modpack up to date? are there any issues?

thanks for your help!

Well, the original developer is no longer alive, so the thread can't be updated, but it's open source, so yeah.

ABJ wrote:Well, the original developer is no longer alive, so the thread can't be updated, but it's open source, so yeah.

I know.
maybe somebody could continue this project.

The commit log is a better place to see if the mod is active.

Moderators can edit the first post if there's any issue.

I doubt a whole lot of people would do that though.

Inocudom wrote:This strange error came up:
2016-11-08 00:07:08: ERROR[Main]: ModError: Failed to load and run script from /home/derek/.minetest/mods/scifi_nodes/init.lua:
2016-11-08 00:07:08: ERROR[Main]: /usr/local/share/minetest/builtin/game/register.lua:130: attempt to compare number with string
2016-11-08 00:07:08: ERROR[Main]: stack traceback:
2016-11-08 00:07:08: ERROR[Main]: /usr/local/share/minetest/builtin/game/register.lua:130: in function 'register_item'
2016-11-08 00:07:08: ERROR[Main]: /usr/local/share/minetest/builtin/game/register.lua:206: in function 'really_register_node'
2016-11-08 00:07:08: ERROR[Main]: .../derek/.minetest/mods/technic/technic_worldgen/nodes.lua:159: in function 'really_register_node'
2016-11-08 00:07:08: ERROR[Main]: ...derek/.minetest/mods/technic/technic_worldgen/crafts.lua:167: in function 'register_node'
2016-11-08 00:07:08: ERROR[Main]: /home/derek/.minetest/mods/scifi_nodes/init.lua:336: in main chunk
2016-11-08 00:07:08: ERROR[Main]: Check debug.txt for details.
When technic is disabled:
2016-11-08 00:35:44: ERROR[Main]: ModError: Failed to load and run script from /home/derek/.minetest/mods/scifi_nodes/init.lua:
2016-11-08 00:35:44: ERROR[Main]: /usr/local/share/minetest/builtin/game/register.lua:130: attempt to compare number with string
2016-11-08 00:35:44: ERROR[Main]: stack traceback:
2016-11-08 00:35:44: ERROR[Main]: /usr/local/share/minetest/builtin/game/register.lua:130: in function 'register_item'
2016-11-08 00:35:44: ERROR[Main]: /usr/local/share/minetest/builtin/game/register.lua:206: in function 'register_node'
2016-11-08 00:35:44: ERROR[Main]: /home/derek/.minetest/mods/scifi_nodes/init.lua:336: in main chunk
2016-11-08 00:35:44: ERROR[Main]: Check debug.txt for details.

Techic does not get along with scifi_nodes too well.

l experienced such errors after the light_source value tests were added, maybe light_source is set to a string at some node definition in the scifi mod.

It's been fixed already, light_source was set as a string for some nodes.

Nore wrote:If you're using Ubuntu or one of its derivatives, you might have a not-so-recent version: could you paste your version number here?

I apologize for such a long wait before responding; are you asking for my current OS version number, or the version number of Minetest I'm currently running?

l assume they asks for your minetest version number.

you could tell both, OS and Minetest version number

Important info:

Technic-worldgen is known to cause lua "Out Of Memory" (OOM) errors in default minetest builds. If you experience such problems, you can use unofficial minetest 0.4.15 stable build made by sfan5 that has simple lua, that provides much more memory, but is somewhat slower: https://kitsunemimi.pw/tmp/minetest-0.4 ... t-win64.7z You can also compile it yourself.

This build can also be used with other memory consuming mods, including worldedit for large scale work.

Ok, so I have a recipe question. Normally if I wanted to remove a recipe using a mod, I would re-register it and give it an output of 0. Unfortunately, I tried this with a technic compressor recipe and it didn't work. How do I remove the [Desert Sand] --> [Desert Stone] Technic compressor recipe? (from a different mod of course).

Fixerol, if l remember correctly, l fixed the OOM crashes in my fork.

GreenDiamond, https://github.com/minetest-technic/tec ... es.lua#L53
after the unwanted recipe is added by technic, execute following:
print(dump(technic.recipes))
then search for your unwanted recipe in the shown table, after that write code which takes it from that table
the removal code may look similar to this:
technic.recipes["compres"].recipes["mod:sand"] = nil

Hybrid Dog wrote:Fixerol, if l remember correctly, l fixed the OOM crashes in my fork.

GreenDiamond, https://github.com/minetest-technic/tec ... es.lua#L53
after the unwanted recipe is added by technic, execute following:
print(dump(technic.recipes))
then search for your unwanted recipe in the shown table, after that write code which takes it from that table
the removal code may look similar to this:
technic.recipes["compres"].recipes["mod:sand"] = nil

So, putting technic.recipes['compressing'].recipes['default:sand 2'] = nil doesnt work... what do I write to take it out of the table?

The index is "default:desert_sand", not "default:sand 2".
technic.recipes.compressing.recipes["default:desert_sand"] = nil
Don't trust the craft guide, it's not up to date after removing the recipe.

Hybrid Dog wrote:The index is "default:desert_sand", not "default:sand 2".
technic.recipes.compressing.recipes["default:desert_sand"] = nil
Don't trust the craft guide, it's not up to date after removing the recipe.

ah, thankyou, but that still does not work D:

How about this:

Hybrid Dog wrote:How about this:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

minetest.after(2, function()
technic.recipes.compressing.recipes["default:desert_sand"] = nil
end)

N̶o̶p̶e̶ ̶:̶(̶
So, that works on its own in a separate mod without my mod. What I want to do is get rid of that recipe and replace it with a different recipe ([Desert Sand 2] --> [Other Node]). How do I do this?

Hybrid Dog wrote:Fixerol, if l remember correctly, l fixed the OOM crashes in my fork.

Can you post it in PR section of original technic repo? Maybe it will be merged.

When i installed version 0.4.15 i was getting error:
"Failed to load and run script from /home/administrator/.minetest/mods/scifi_nodes/init.lua:
/usr/share/minetest/builtin/game/register.lua:130: attempt to compare number with string stack traceback:
/usr/share/minetest/builtin/game/register.lua:130: in function 'register_item'
/usr/share/minetest/builtin/game/register.lua:206: in function 'really_register_node'
...trator/.minetest/mods/technic/technic_worldgen/nodes.lua:159: in function 'really_register_node'
...rator/.minetest/mods/technic/technic_worldgen/crafts.lua:167: in function 'register_node'

Does anybody know what is it?

Andrey01, that was a bug in the scifi_nodes mod.
Fixerol, sorry, l didn't remember correctly. Once l fixed an on_generated, maybe in the snow mod, which did not use the vmanip mapgen object but made its own one instead; it caused odd mapgen artifacts l think. https://github.com/HybridDog/technic/co ... 27e497?w=1
Anyway, OOM crashes often blame the wrong mods l think.