[Mod] Technic [0.4.16-dev] [technic]

Jesseman1
Member
Posts: 49
Joined: Fri Dec 12, 2014 21:32
In-game: Jesseman1 or Plant_Operator
Location: My huge fortress or power plant.

Re: [Mod] Technic [0.4.11] [technic]

by Jesseman1 » Post

I already force updated Minetest in the terminal with the "sudo apt upgrade minetest" command(I'm using Ubuntu/Lubuntu) and those are the issues I'm experiencing. Did I do it wrong or update the wrong thing?

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: [Mod] Technic [0.4.11] [technic]

by Nore » Post

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?

Heraclitus
Member
Posts: 25
Joined: Tue Oct 11, 2016 17:14

Re: [Mod] Technic [0.4.11] [technic]

by Heraclitus » Post

Apologies in advance for the long post, but I want to document the issues I had for future users, since I've seen a few other posts alluding to this. (FYI -- using default mapgen v6.)

For the TL;DR version --

(1) Given the Perlin noise distribution of Technic metals, how far on average does one need to go to have a reasonable chance of seeing the noise level change enough to get out of an "empty pocket" for things like chromium or zinc?

(2) I wish the manual better reflected the reality of metal rarity, as well as making the uneven distribution clear for new users.

Details and background:

I just discovered Minetest about a month ago, and so far I have to congratulate all the developers and contributors on a great game. My (young) son has been talking about friends playing Minecraft (which I've never played), so I searched and found this alternative, which we can play together on my home network. The configurable nature is fantastic, since my son enjoys the "survival" aspects of searching for materials, but he doesn't want monsters, for example.

A few weeks ago I discovered Technic, which raises the gameplay to new levels (along with Pipeworks and Mesecons), and again, I need to say thank you to everyone who has contributed to this.

I do have a question and a comment, though, which relates to playing Technic in survival (or "semi-survival") mode, both regarding zinc and chromium.

Question: Zinc and chromium are both required to build some basic materials (zinc early on for first machines, chromium to upgrade to better machines and tools using stainless steel). I understand that they are distributed unevenly based on Perlin noise levels. However, I can't sort out the detailed implementation of the noise function enough to understand the parameters of the distribution. I'm sure there's something in those parameters that answers this question, but basically -- How far, on average, is the distance between local noise maxima and minima, as related to Technic ore generation? That is to say, if I dig for chromium in one place and don't find any, how large is the "empty" pocket likely to be? Should I go 50 nodes in some direction to try again? Or 100 nodes? 500 nodes? (I assume, based on the code, that the distribution should change in all directions below -200 for zinc and chromium, correct? So I could go down or north or east or whatever, and I should have equal chance of seeing the noise level change?)

I realize that any answer would only be an average estimate, but this is a real practical concern for trying to find these rare materials. It would be good to know that the noise changes slowly enough that digging 50 nodes away is usually not enough to make a difference, for example. Or that if I'm skipping 200 nodes away that I'm quite likely to miss some pockets in-between. Or whatever.

Lastly, my Comment: I really appreciate the detail of the Technic manual, which I read thoroughly before incorporating Technic into our game. But I really think there needs to be a clearer description for new users of the fact that the Technic metals are VERY uneven in their distribution. I first took the manual at its word that Zinc was "a common metal" and Chromium was "moderately common." This also made some sense to me, since chromium (for example) is a very common metal in the earth's crust.

However, these descriptions are simply not true, and even when you find these materials, they may be in an isolated pocket. I was lucky enough to encounter a zinc deposit early, but chromium was extremely difficult to find on my world. After a couple afternoons questing for it with my son, I tried by myself to find it and then increasingly introduced cheats (TNT, flying, then no-clip flying through underground caverns) just trying to find a SINGLE node of it. It was frustrating to play without the possibility of building anything with stainless steel. I couldn't find any after hours even with these hacks, and eventually thought there might be a bug. So I lowered the threshold for cluster generation to a very low level in a remote location and did a "deleteblocks" on that small area. Chromium did appear.

So, I took a couple dozen nodes of it back with me and reset ore generation thresholds to default levels. I used the chromium to "bootstrap" some more advanced machines, including a quarry, thinking that would finally allow me to dig large areas. But after quarrying several MILLION nodes (all -200 and under, where the code suggests distribution should be max, particularly for chromium), I still had not seen a node of chromium (other than those I had artificially generated in a small area by tweaking the threshold). With the server running for literally weeks, no chromium.

Finally, since I had many hundreds of diamonds by that point (and was running out of stainless), I made an top-grade mining drill with my few remaining stainless and just started walking in one direction. After walking about 300 nodes in one direction underground, I finally spotted a node of chromium. I almost couldn't believe I actually was seeing it. I immediately moved my quarry there.

Apologies for the long description, but now I have enough chromium (for now). But after quarrying around 10 million nodes (in a few different quarry regions), I still haven't been able to quarry a single node of zinc, and that is now starting to run low for me.

Anyhow, I'm not complaining about this exactly, and I've seen the bug noting issues with zinc in particular. But the manual really needs to be changed to make clear the zinc and chromium are the most rare elements in the game. They are not "common." (And in fact they seem to have been made artificially rare for gameplay reasons? Is that true? And yes, technically uranium is even more rare since it's only available at limited depths, but it's only necessary for relatively late stages of gameplay.) I wasted several days of gameplay just haphazardly walking around thinking I'd find these "common" metals before I started searching the forums and discovering others have had these issues. New players should be aware that they might dig several million nodes without seeing one or the other of zinc or chromium (or both). They also should be aware that if they find some early on, they shouldn't waste it and be very careful rationing it until they build up a massive infrastructure to mine on a large scale. Lastly, they should know that if they're not seeing any in one area, they may need to go far away (how far?) to try again and look for them, due to uneven noise distribution.

I realize the manual is outdated in a few other places, but this is a rather critical problem for new users attempting to play without creative mode.

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: [Mod] Technic [0.4.11] [technic]

by Nore » Post

Well, these metals are *on average* common. However, you need to find "veins" of them, which will be areas where you can find high concentrations of them. Thus, the gameplay objective is to make you find those veins, and establish an zinc mine somewhere, a chromium mine elsewhere, etc. This was however not done for ores that were not introduced by technic, and thus, the other ores are uniformly distributed.
About the distribution, the largest scale is 100 nodes - that means, if you go 100 nodes in any direction, your chances to find some mineral is independent of whether you found some 100 nodes away.
I agree a setting to disable that non-uniform distribution might be needed - I will try to do that when I can.
Finally, the manual is indeed outdated and incomplete: some help about that would be greatly appreciated :).

User avatar
Cryterion
Member
Posts: 94
Joined: Tue Jun 10, 2014 08:12
GitHub: Cryterion
IRC: Cryterion
In-game: Cryterion
Location: Durban, South Africa

Re: [Mod] Technic [0.4.10] [technic]

by Cryterion » Post

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

Code: Select all

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

Code: Select all

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

Code: Select all

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

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.
No trees or animals were hurt in the production of this message. However, a large number of Electrons were temporarily inconvenienced.

Heraclitus
Member
Posts: 25
Joined: Tue Oct 11, 2016 17:14

Re: [Mod] Technic [0.4.11] [technic]

by Heraclitus » Post

First, I REALLY appreciate the reply.
Nore wrote:Well, these metals are *on average* common. However, you need to find "veins" of them, which will be areas where you can find high concentrations of them. Thus, the gameplay objective is to make you find those veins, and establish an zinc mine somewhere, a chromium mine elsewhere, etc. This was however not done for ores that were not introduced by technic, and thus, the other ores are uniformly distributed.
I completely get that, and I realize that's the strategy to adopt now. Though I only figured that out after spending a lot of time reading through a large portion of this thread. I'm mostly saying that it's really important to make some reference to that in the manual, since there's a huge difference between expectations for these different metals, and that will affect gameplay and strategy.

I'm still trying hard to believe what you say about chromium and zinc being "common" on average -- which would mean I've encountered a statistical fluke in my world.

Can you explain briefly what the noise_threshold basically means in terms of frequency? For example, if I understand the oregen file correctly, zinc has a 1 in 6^3 chance of spawning a cluster below -32 without the noise factor. But the noise threshold is 0.5 -- is the noise a normal distribution? Does 0.5 mean there's basically a 50% chance *on average* of the noise exceeding that threshold to allow that 1 in 6^3 chance of spawning to happen? Am I interpreting that correctly? For chromium, the threshold is 0.55 -- how does that alter the stats? (I'm happy to go read documentation on how the Minetest implementation of the noise works and its distribution, rather than having you explain this, if you can point me to something.)

Other metals that use the term "common" in the manual include iron, tin, and copper. Tin (in Moreores) seems to have a cluster_scarcity of 7^3 and copper below -64 has a scarcity of 9^3, compared to the 6^3 for zinc. But zinc only spawns if the threshold is above 0.5, so if I'm interpreting that to correctly to mean a 50% chance of spawning, zinc should be marginally less common than tin, but much more common than copper. If the noise is variable enough that 100 nodes distance should basically be enough to make independent chances, then my world must be a HUGE statistical fluke so far... assuming I understand this all correctly.
I agree a setting to disable that non-uniform distribution might be needed - I will try to do that when I can.
The thing is -- I actually really like the idea of "veins" of materials in theory. The problem, from my experience so far, is that these couple metals can really stand in the way of developing certain stages of machines, so someone can be stuck for days or weeks walking around with a pickaxe hoping to find a few nuggets of zinc and chromium to create a few machines and thus make processing a lot easier. Again, this is based off of my sample of mining so far.

(Also, if the idea of veins is taken seriously, they need to be more obvious when you find them. Chromium has a cluster_size of 3, with clust_num_ores of 2 even when it spawns. Even in a region where the Perlin noise exceeds the threshold of 0.55 consistently, one could easily miss such small clusters when digging a tunnel through looking for some. I have no doubt this may be one of the reasons it took me an exceedingly long amount of time before I saw even a single chromium node.)

But perhaps my experience is just a huge statistical fluke, though I've found a couple references further up this thread and elsewhere that others have found these metals to be similarly rare.

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: [Mod] Technic [0.4.11] [technic]

by Nore » Post

The noise would be more like X_1 + 0.7 * X_2 + 0.7^2 * X_3, where X_1, X_2, X_3 are uniformly distributed on [-1,1], and with X_2 having a frequency double of that of X_1, X_3 one double of that of X_2 (that is: there are smaller-scale variations). Thus, a threshold of 0.55 is quite less that 50% chance actually. Maybe the stats about it should be redone - I might have done a mistake in my calculations earlier.

Btw, if you want to look at ore veins that are actually more obvious and that can be followed, you might be interested in my "mg" mod ;).

EdShouldBeInBed
Member
Posts: 48
Joined: Sun Feb 22, 2015 16:03
In-game: EdShdBInBed

Re: [Mod] Technic [0.4.11] [technic]

by EdShouldBeInBed » Post

This post deleted due to the poster correcting his own derp. Thank you.
Last edited by EdShouldBeInBed on Sat Oct 15, 2016 13:33, edited 1 time in total.
I'm a writer who tinkers with code on occasion. I play minetest when insomnia makes the writing hard.

Heraclitus
Member
Posts: 25
Joined: Tue Oct 11, 2016 17:14

Re: [Mod] Technic [0.4.11] [technic]

by Heraclitus » Post

Nore wrote:The noise would be more like X_1 + 0.7 * X_2 + 0.7^2 * X_3, where X_1, X_2, X_3 are uniformly distributed on [-1,1], and with X_2 having a frequency double of that of X_1, X_3 one double of that of X_2 (that is: there are smaller-scale variations). Thus, a threshold of 0.55 is quite less that 50% chance actually.
Just to be sure I'm understanding this correctly, your expression implies that the noise level can go outside the [-1,1] region, correct? (That is, X_1, X_2, and X_3 are uniformly distributed in that region, but your expression's calculated range will be larger.)

Anyhow, if that's the correct expression, I just did a quick simulation that says a threshold of 0.55 (like chromium) should spawn about 25% of the time (on average, given noise distribution over large regions), while a threshold of 0.5 (like zinc) should spawn about 27% of the time. That implies zinc should be somewhat less common than the other "common" metals, but still more common on average than, say, silver (with scarcity of 11^3 and same ores per chunk as zinc).

The problem with this is that lead, with threshold of 0.3 should spawn around 35-36% of the time. (Also with scarcity of 6^3 below -128, like zinc and chromium.) That doesn't explain the high disparity I've noticed so far between frequency of finding veins of lead vs. zinc and chromium. So far, I've seen regions where lead is rare too, but I've still found literally thousands and thousands of nodes of it so far, well over an order of magnitude more than zinc or chromium, perhaps around 2 orders of magnitude. According to that noise expression, I should be finding maybe 50% more lead than zinc below -128 (taking into account that clust_num_ores is 5 for lead and 4 for zinc). That's a pretty big disparity in expected return.

So, either (1) I'm mining in a truly anomalous world and am just exceedingly unlucky, (2) I'm misunderstanding your noise expression, or (3) the noise expression isn't correct and the difference between a threshold of 0.3, 0.5, and 0.55 is LOT bigger.

Again, thanks for your help, and I'm not trying to be argumentative here. I'm just trying to understand the noise parameters (and if I did, I could even draft a reasonable rewrite to the manual ores section to clarify all this).

Nore
Developer
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

Re: [Mod] Technic [0.4.11] [technic]

by Nore » Post

Well, I should look at the C++ code that generates those ores, then; there might be something I didn't take into account in there. I would say that (1) is definitely not the answer (if, as I guess, you enabled technic before the creation of your world; if not, all statistics you can make that include the area that was already explored before you enabled it would be biased). I think (2) is not the answer either, and that the correct one is (3). The problem with perlin noise is that the way it works might actually require to have multiple high-valued random numbers close to each other in the grid to get an area with a high enough value; that is something I did not take into account when I made my calculations because I thought it would not matter, and I may be quite wrong about this. About your first question, yes, the results can get out of the [-1, 1] range. I seem to remember paramat once made a very detailed post about how perlin noise worked, but I can't find it again.

Byakuren
Member
Posts: 818
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri
In-game: Raymoo + Clownpiece

Re: [Mod] Technic [0.4.11] [technic]

by Byakuren » Post

Could someone merge this trivial fix to a node duplication exploit?: https://github.com/minetest-technic/technic/pull/295
Every time a mod API is left undocumented, a koala dies.

User avatar
kaeza
Moderator
Posts: 2162
Joined: Thu Oct 18, 2012 05:00
GitHub: kaeza
IRC: kaeza diemartin blaaaaargh
In-game: kaeza
Location: Montevideo, Uruguay
Contact:

Re: [Mod] Technic [0.4.11] [technic]

by kaeza » Post

Byakuren wrote:Could someone merge this trivial fix to a node duplication exploit?: https://github.com/minetest-technic/technic/pull/295
Done.
Your signature is not the place for a blog post. Please keep it as concise as possible. Thank you!

Check out my stuff! | Donations greatly appreciated! PayPal

Byakuren
Member
Posts: 818
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri
In-game: Raymoo + Clownpiece

Re: [Mod] Technic [0.4.11] [technic]

by Byakuren » Post

Thanks kaeza.
Every time a mod API is left undocumented, a koala dies.

Chiu ChunLing
Member
Posts: 47
Joined: Sat Oct 22, 2016 09:37

Re: [Mod] Technic [0.4.11] [technic]

by Chiu ChunLing » Post

I found a couple of issues with the mining laser_shoot function. The particle effect wasn't working due to a typo resulting in the laser particle being added with a nil position. With that done I found the shot particle originating from above my head, so I reduced the y correction. I also found the origin of the actual block breaking a bit off, I added some fudge factors to that but yaw seems to have an effect as well.

Code: Select all

local function laser_shoot(player, range, particle_texture, sound)
	local player_pos = player:getpos()
	local player_name = player:get_player_name()
	local dir = player:get_look_dir()

	local start_pos = vector.new(player_pos)
	-- Adjust to head height
	start_pos.y = start_pos.y + 1.6 --
	minetest.add_particle({
		pos = start_pos,--pos was previously assigned to startpos,
		vel = dir,
		acc = vector.multiply(dir, 50),
		expirationtime = range / 11,
		size = 1,
		texture = particle_texture .. "^[transform" .. math.random(0, 7),
	})
	start_pos.x,start_pos.y,start_pos.z = start_pos.x + .5,start_pos.y+.4,start_pos.z + .5 --fudge factors, not wholly successful
	minetest.sound_play(sound, {pos = player_pos, max_hear_distance = range})
	for pos in technic.trace_node_ray(start_pos, dir, range) do
		if minetest.is_protected(pos, player_name) then
			minetest.record_protection_violation(pos, player_name)
			break
		end
		local node = minetest.get_node_or_nil(pos)
		if not node then
			break
		end
		if not no_destroy[node.name] then
			laser_node(pos, node, player)
		end
	end
end
Hopefully someone with more experience with minetest can work out a good way to settle the yaw effect on player:getpos(), or decide what the proper values for the fudge should be.

User avatar
Hybrid Dog
Member
Posts: 2828
Joined: Thu Nov 01, 2012 12:46
GitHub: HybridDog

by Hybrid Dog » Post

Chiu ChunLing, l fixed the problem in my version: https://github.com/HybridDog/technic

‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪

Chiu ChunLing
Member
Posts: 47
Joined: Sat Oct 22, 2016 09:37

Re: [Mod] Technic [0.4.11] [technic]

by Chiu ChunLing » Post

Cool. Is there some overall coordination of the various versions of technic or is it just every version for itself?

User avatar
Hybrid Dog
Member
Posts: 2828
Joined: Thu Nov 01, 2012 12:46
GitHub: HybridDog

by Hybrid Dog » Post

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

‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪

Chiu ChunLing
Member
Posts: 47
Joined: Sat Oct 22, 2016 09:37

Re: [Mod] Technic [0.4.11] [technic]

by Chiu ChunLing » Post

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

User avatar
SegFault22
Member
Posts: 872
Joined: Mon May 21, 2012 03:17
Location: NaN

Re: [Mod] Technic [0.4.10] [technic]

by SegFault22 » Post

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

Code: Select all

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

Code: Select all

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

Code: Select all

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

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:

Code: Select all

minetest.register_node(modname..":technic:"..ltier.."_"..machine_name, {
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.
Last edited by SegFault22 on Mon Oct 31, 2016 08:46, edited 1 time in total.

Byakuren
Member
Posts: 818
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri
In-game: Raymoo + Clownpiece

Re: [Mod] Technic [0.4.11] [technic]

by Byakuren » Post

minetest.get_current_modname is a thing too
Every time a mod API is left undocumented, a koala dies.

User avatar
SegFault22
Member
Posts: 872
Joined: Mon May 21, 2012 03:17
Location: NaN

Re: [Mod] Technic [0.4.11] [technic]

by SegFault22 » Post

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.

Byakuren
Member
Posts: 818
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri
In-game: Raymoo + Clownpiece

Re: [Mod] Technic [0.4.11] [technic]

by Byakuren » Post

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.
Every time a mod API is left undocumented, a koala dies.

User avatar
Wuzzy
Member
Posts: 4786
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy
Contact:

Maybe a critical error?

by Wuzzy » Post

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

u34

Re: [Mod] Technic [0.4.11] [technic]

by u34 » Post

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

thanks for your help!

ABJ
Member
Posts: 3015
Joined: Sun Jan 18, 2015 13:02
GitHub: ABJ-MV
In-game: ABJ
Location: In Earth orbit, with a perigee of 1048 km and an apogee of 1337 km and an inclination of 69 degrees.

Re: [Mod] Technic [0.4.11] [technic]

by ABJ » Post

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

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 15 guests