[Mod] Technic [0.4.16-dev] [technic]
-
- 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]
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?
Re: [Mod] Technic [0.4.11] [technic]
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?
-
- Member
- Posts: 25
- Joined: Tue Oct 11, 2016 17:14
Re: [Mod] Technic [0.4.11] [technic]
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.
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.
Re: [Mod] Technic [0.4.11] [technic]
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 :).
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 :).
- 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]
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
change it toCode: Select all
minetest.register_node("technic:"..ltier.."_"..machine_name, {
and line 158Code: Select all
minetest.register_node(":technic:"..ltier.."_"..machine_name, {
changed it toCode: 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.Code: Select all
minetest.register_node(":technic:"..ltier.."_"..machine_name.."_active",{
No trees or animals were hurt in the production of this message. However, a large number of Electrons were temporarily inconvenienced.
-
- Member
- Posts: 25
- Joined: Tue Oct 11, 2016 17:14
Re: [Mod] Technic [0.4.11] [technic]
First, I REALLY appreciate the reply.
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.
(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.
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.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'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.
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.I agree a setting to disable that non-uniform distribution might be needed - I will try to do that when I can.
(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.
Re: [Mod] Technic [0.4.11] [technic]
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 ;).
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 ;).
-
- Member
- Posts: 48
- Joined: Sun Feb 22, 2015 16:03
- In-game: EdShdBInBed
Re: [Mod] Technic [0.4.11] [technic]
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.
-
- Member
- Posts: 25
- Joined: Tue Oct 11, 2016 17:14
Re: [Mod] Technic [0.4.11] [technic]
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.)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.
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).
Re: [Mod] Technic [0.4.11] [technic]
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.
-
- 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]
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.
- 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]
Done.Byakuren wrote:Could someone merge this trivial fix to a node duplication exploit?: https://github.com/minetest-technic/technic/pull/295
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
Check out my stuff! | Donations greatly appreciated! PayPal
-
- 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]
Thanks kaeza.
Every time a mod API is left undocumented, a koala dies.
-
- Member
- Posts: 47
- Joined: Sat Oct 22, 2016 09:37
Re: [Mod] Technic [0.4.11] [technic]
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.
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.
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
- Hybrid Dog
- Member
- Posts: 2828
- Joined: Thu Nov 01, 2012 12:46
- GitHub: HybridDog
Chiu ChunLing, l fixed the problem in my version: https://github.com/HybridDog/technic
-
- Member
- Posts: 47
- Joined: Sat Oct 22, 2016 09:37
Re: [Mod] Technic [0.4.11] [technic]
Cool. Is there some overall coordination of the various versions of technic or is it just every version for itself?
- Hybrid Dog
- Member
- Posts: 2828
- Joined: Thu Nov 01, 2012 12:46
- GitHub: HybridDog
-
- Member
- Posts: 47
- Joined: Sat Oct 22, 2016 09:37
Re: [Mod] Technic [0.4.11] [technic]
So...basically just rely on when something was last modified?
- SegFault22
- Member
- Posts: 872
- Joined: Mon May 21, 2012 03:17
- Location: NaN
Re: [Mod] Technic [0.4.10] [technic]
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: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
change it toCode: Select all
minetest.register_node("technic:"..ltier.."_"..machine_name, {
and line 158Code: Select all
minetest.register_node(":technic:"..ltier.."_"..machine_name, {
changed it toCode: 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.Code: Select all
minetest.register_node(":technic:"..ltier.."_"..machine_name.."_active",{
Code: Select all
minetest.register_node(modname..":technic:"..ltier.."_"..machine_name, {
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.
-
- 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]
minetest.get_current_modname is a thing too
Every time a mod API is left undocumented, a koala dies.
- SegFault22
- Member
- Posts: 872
- Joined: Mon May 21, 2012 03:17
- Location: NaN
Re: [Mod] Technic [0.4.11] [technic]
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.Byakuren wrote:minetest.get_current_modname is a thing too
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.
-
- 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]
This is what I meant to suggest, sorry for being vague.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.
Every time a mod API is left undocumented, a koala dies.
- Wuzzy
- Member
- Posts: 4786
- Joined: Mon Sep 24, 2012 15:01
- GitHub: Wuzzy2
- IRC: Wuzzy
- In-game: Wuzzy
- Contact:
Maybe a critical error?
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
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
Re: [Mod] Technic [0.4.11] [technic]
is this modpack up to date? are there any issues?
thanks for your help!
thanks for your help!
-
- 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]
Well, the original developer is no longer alive, so the thread can't be updated, but it's open source, so yeah.
Who is online
Users browsing this forum: No registered users and 19 guests