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

[Crowmagus]

Love the mod but it seems to have a problem loading. Any help getting it running would be very appreciated.

Here is the debug log. I've parsed it a bit to cut down on the time stamp etc.
--------------------------------------------------------------------------------------------------------------------------------------
Server: Failed to load and run /home/user/.minetest/mods/technic/technic/init.lua
ERROR[main]: ModError: ModError: Failed to load and run /home/george/.minetest/mods/technic/technic/init.lua
ERROR[main]: Error from Lua:
ERROR[main]: /home/user/.minetest/mods/technic/technic/helpers.lua:58: attempt to index global 'pipeworks' (a nil value)
ERROR[main]: stack traceback:
ERROR[main]: /home/user/.minetest/mods/technic/technic/helpers.lua:58: in main chunk
ERROR[main]: [C]: in function 'dofile'
ERROR[main]: /home/user/.minetest/mods/technic/technic/init.lua:27: in main chunk
------------------------------------------------------------------------------------------------------------------------------------

information on how to correct the errors - or how to patch up the code please?

Thanks in advance

[ABJ]

The mod's creator is no longer alive. Anyone who knows enough?

[Nore]

It looks like pipeworks is not installed or has not been enabled... If it is correctly installed or enabled, though, it looks strange. Could you tell me if there is a "Pipeworks loaded!" message appearing in the console before the crash?

[Crowmagus]

It looks like pipeworks is not installed or has not been enabled... If it is correctly installed or enabled, though, it looks strange. Could you tell me if there is a "Pipeworks loaded!" message appearing in the console before the crash?

Took a look at the pipes and it was installed and enabled. I disabled technic to get game to load and it loaded with pipes available. But just in case I deleted the pipes folder and used a fresh copy from the zip file.

Also I noted that a lot of people were talking about ver 4.14 in other areas. I was running 4.13 from the DL link on the home page. So I hunted around and found a version for 4.14 elsewhere on the site. I am running a Linux box so that may be why (??) but dont know if the version made a difference.
Anyway it now works just as described.

Thank you so much for taking the time to look at it and point me in right direction.

[ABJ]

IIRC it's been a few months since V4.14 was on the official DL link. When did you use the link last?

[Crowmagus]

IIRC it's been a few months since V4.14 was on the official DL link. When did you use the link last?

Have only been playing a week or so. I know I had the .13 version cause I checked when asked if I had pipes enabled. I did try to traceback to find the link but have no idea where I got the older version.

In my search I did see that the .14 has been out for a couple months so I dont know how I got the .13 version.

Sorry I couldnt be more help

[Crowmagus]

A new question that I cant seem to find the answer for anywhere.

I have automated the mining (with Technic and Pipeworks - two amazing mods) all the way to the grinder. But no matter what I try I seem unable to get the dust from the grinder to the MV furnace. I have tried all the pipes and the filters from Pipes - I am certain I am doing something wrong but cant find a reference on how to get things from the grinder to the furnace automatically. Everything before the grinder and everything after the furnace is automated.

What am I missing??

[Naj]

Two things :
- Grinder should be MV
- A control unit logic has to be put in one of the upgrade slots

Then you have to check on which side dust is ejected (depending on orientation). Put a chest on each side and check.

[Crowmagus]

Two things :
- Grinder should be MV
- A control unit logic has to be put in one of the upgrade slots

Then you have to check on which side dust is ejected (depending on orientation). Put a chest on each side and check.

Thank You so very much. The output side discover was the key. And NOW my mining is automated from end to end.

[Naj]

Good !
Thats a very annoying bug in technics, ejection side (right or left) depends on the orientation (N/S or E/W).

[Jesseman1]

I know RBA is no longer with us, and so I'm a little nervous about updating. Is the current version of Technic stable?

[qwertymine3]

...

[Jesseman1]

I've decided to update my version of Technic, and force updated the Minetest game to meet Technic's requirements. I've noticed a few issues already; Stainless Steel, Concrete, and Blast-resistant Concrete no longer provide shielding from radiation, and despite force updating the game, cables still look like full size blocks. I'm not a coder, so I don't know where the problem is originating from. Please help?

*Edit* Also, the meltdown timer for a damaged reactor took over five minutes from the moment of damage to the corium spawn. Last I remember, the timer countdown is supposed to be 100 seconds if only one block is damaged.

[Nore]

Hi,

Technic should be compatible with the latest version of Minetest game, and needs a fairly recent version of the engine as well (the topic title saying 0.4.11 is unfortunately quite outdated). If cables look like full size blocks, this means you version of the engine is not recent enough: it uses NDT_CONNECTED, which was added between 0.4.13 and 0.4.14.

Finally, about updating: technic is still in development, but not as actively as before; it is not completely stable either, unfortunately.

The other problems are a bit stranger, but will hopefully be fixed if you update your version of the engine, please say here if they remain after that.

[Jesseman1]

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]

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]

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]

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 :).

[Cryterion]

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

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.

[Heraclitus]

First, I REALLY appreciate the reply.

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]

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]

This post deleted due to the poster correcting his own derp. Thank you.

[Heraclitus]

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]

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]

Could someone merge this trivial fix to a node duplication exploit?: https://github.com/minetest-technic/technic/pull/295

[kaeza]

Could someone merge this trivial fix to a node duplication exploit?: https://github.com/minetest-technic/technic/pull/295

Done.

[Byakuren]

Thanks kaeza.

[Chiu ChunLing]

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.

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

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.

[Hybrid Dog]

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

[Chiu ChunLing]

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