Coder Social home page Coder Social logo

technic's Introduction

Technic

Build status License

This Minetest modpack adds machinery and automation procedure content to your world. A few notable features:

  • Electric circuits
  • Automated material processing (ores, wood, ...)
  • Extended chest functionalities

Dependencies

FAQ

The modpack is explained in the Manual included in this repository. Machine and tool descriptions can be found on the GitHub Wiki.

  1. My technic circuit doesn't work. No power is distributed.
    • Make sure you have a switching station connected.
  2. My wires do not connect to the machines.
    • Each machine type requires its own cable type. If you do not have a matching circuit, consider using a "Supply Converter" for simplicity.

For modders: Technic Lua API

License

Unless otherwise stated, all components of this modpack are licensed under the LGPLv2 or later. See also the individual mod folders for their secondary/alternate licenses, if any.

Credits

Contributors in alphabetical order:

  • kpoppel
  • Nekogloop
  • Nore/Ekdohibs
  • ShadowNinja
  • VanessaE
  • And many others...

technic's People

Contributors

antumdeluge avatar asl97 avatar auouymous avatar cheapie avatar coil0 avatar desour avatar dokutan avatar ekdohibs avatar est31 avatar gabriel1379 avatar hybriddog avatar jordach avatar kaeza avatar khonkhortisan avatar kpoppel avatar numberzero avatar obko avatar panquesito7 avatar realbadangel avatar rogier-5 avatar sdzen avatar sfence avatar shadowninja avatar sires0 avatar smalljoker avatar t4im avatar thatgraemeguy avatar thomas--s avatar thomasrudin avatar vanessae avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

technic's Issues

Moving a stack of items to a gold chest only moves one

Iron chests behave as expected, but when I tried to move several stacks of items to a locked gold chest, only one of them was moved, as if I had right-clicked a slot with it and then replaced it back to my inventory.

Add extractor.

Extractor is a machine which is used to get more rubber from latex raw. For example when you put 1 latex into furnace you get 1 rubber, but if you but 1 latex into the extractor you get 3 rubber.

Code duplication of item_drop

Hi,

as there are no other ways to contact you, at least none known to me, I am using the issue tracker for a question.

While packaging for Debian, I have noticed that the repository contains duplicated code from the item_drop mod.

Normally, I would remove the code and make technic use a seperately packages item_drop mod, but I noticed that there are changes to item_drop. Have you tried to get those changes merged back to the upstream item_drop mod? Are these changes somewhat technic-specific? Does the technic mod need your specific item_drop version, and will this break other mods that use the original item_drop when your version is installed?

It would be good if you clarified that a bit.

Thanks in advance,
Nik

supply converter cannot harness the power stored in batteries

found in: 468d79d

So basically if I have the following grid:
hv: solar, switching station, battery
mv: switching station, battery, mv furnace
and connect them with a supply converter the mv furnace will be powered at day, but the mv battery is not charged and at night everything stops because the hv battery is not used, too.

Wrong-side Stargates

Stargates teleport you out the back end. Find a cliff face, put two stargates in front of it, connect them together, go through either one, and you will teleport into the wall. The destination should be on the side the player is on when placing, not on the opposite side.
mineteststargatewalltest

Proposal for different switching station recipe (and splitting in lv, mv and hv variant)

I propose to add three different switching stations. While this makes things more complicated it reduces the issue a bit that the first switching station should be reasonable simple to get without completely spoiling the 'fun' for later.

Idea for the recipe is:
control logic unit at the top and three wire in/outputs. If the voltage is not lv a transformer is necessary to not fry the control logic unit. This is still horrible oversimplified, but on the other hand real current would find its way on its own,..

lv (no transformer needed here):
{'default:steel_ingot', 'technic:control_logic_unit', 'default:steel_ingot'},
{'technic:lv_cable0', 'technic:lv_cable0', 'technic:lv_cable0'},
{'default:steel_ingot', 'technic:lv_cable0', 'default:steel_ingot'},

mv:
{'technic:stainless_steel_ingot', 'technic:control_logic_unit', 'technic:stainless_steel_ingot'},
{'technic:mv_cable0', 'technic:mv_transformer', 'technic:mv_cable0'},
{'technic:stainless_steel_ingot', 'technic:mv_cable0', 'technic:stainless_steel_ingot'},

hv:
{'technic:stainless_steel_ingot', 'technic:control_logic_unit', 'technic:stainless_steel_ingot'},
{'technic:hv_cable0', 'technic:hv_transformer', 'technic:hv_cable0'},
{'technic:stainless_steel_ingot', 'technic:hv_cable0', 'technic:stainless_steel_ingot'},

Flashlight causes 100% CPU use

Tested on VanessaE's server: as soon as a player with flashlight joins, servers goes at 100% CPU for a few minutes, and cannot be used. Removing the flashlight from the hotbar seems to fix the problem.

lua error

here is the patebin link
http://pastebin.com/HBTFQSsH

I basically just remove the stairsplus from ores.lua and technic works fine.

Any clues to what I could be missing? Hopefully just something stupid.

Ideas

Hi RealBadAngel

I wrote up some ideas here: https://github.com/kpoppel/technic/wiki/Todo
Some are things just to have the basics right, some are new stuff that would go nicely with this mod.
Do feed back to me if you like these and think some or all would be appropriate to what you'd like this mod to evolve into.
I'd like to contribute to this mod because I think the theme is excellent so if you care to write a bit maybe on the wiki page here about your overall vision and goal that would be nice.

Electrical Engineering

I've enjoyed playing on a server called King Arthur's. It's distinguished primarily by a theme -- buildings not conforming to the theme are forbidden, although I don't know who decides or on what basis. And although the server has some shortcomings, it has a great look to it. Everything works together, because of the unifying theme.

Now when I first looked at 'technic', I thought it had a theme: engineering, specifically electrical power engineering. Boy, was I ever wrong! I decided quickly that nobody involved in the development had ever touched a soldering iron -- certainly never held a multimeter in hand.

We have to work within the limitations of the Minetest engine, which probably cramps our ability to mimic the laws of electrodynamics. But we do not have to ignore them completely. A hallmark of a good model is that it reflects its prototype, at least superficially. An HO-gauge model steam locomotive does not actually have a tiny steam engine inside, let alone a tiny engineer and a tiny little stoker shoveling tiny lumps of coal into the tiny firebox. But we do shape the plastic or tin into the shape of a real prototype steam locomotive; and we paint it black; and we weather it so it looks real. We stick an electric motor inside the shell and we gear it to the wheels. It's a model, not a simulation. We can do as well with 'technic', I think.

At this point I expect a rash of objections, all based largely on imagined limitations of the core engine. I say that we can overcome at least half of them; and when we run out of room, we can fake it. At least we can give the appearance of a system that acts as its prototype would.

I expect another raft of objections that all tend toward "this is just a game, so who cares how it works". I invite such people to work on my proposed 'unicorn' mod instead, where candy-cane zepplins are driven by rainbow power and fairy dust.

Let me explain how to go about this:

Electricity does not come in "electrical units". It comes in the units of volts, amps, watts, and watt-hours. (Yes, there are other equivalent units.) These quantities are strictly related:

P = EI

... where P (power in watts) is equal to E (voltage in volts) times I (current in amps). So a 1000 watt hair dryer running on 117 VAC must be consuming a bit more than 8.5 amps.

And:

Wh = Pt

... that is, energy (in watt-hours) is equal to power (in watts) times elapsed time (in hours). If a power level of 10 watts is sustained for 8 hours then that is a total amount of energy equal to 80 watt-hours. Energy is not power! The conventional unit of energy in this context is the kilowatt-hour, kWh.

Another rule is pretty simple, the First Law of Thermodynamics: You can't get something for nothing. You can never take more energy out of a system than you put into it. The Second Law is even harsher: You can't break even. The Third Law is worse still: You can't quit the game.

To model this well in 'technic' does not require a major tearing-up; it only requires some desire to be faithful to the prototype. First thing, banish "EU" entirely; this has no meaning. I'll tolerate the terms 'MV', etc. only on condition that they are tied to specific, documented quantities. I'd suggest, reasonably, that LV be 120 VAC; MV, 240 VAC; and HV, 480 VAC. Actually none of these are really high voltage. But then, 230 kV will arc through almost any thickness of rubber, so as long as HV cable is merely double-insulated, we're still making sense.

So now, when we look at a voltage converter -- which is merely a big transformer -- we know how to model it. Since power before loss is constant, we might reasonably hope to get, say, 980 watts out for 1000 watts in. It doesn't matter whether we're going up or down in voltage; wattage will be about the same. The capacity of a transformer is measured in watts; when that capacity is reached, it won't pass any more power. However, it may always pass less.

If we have two machines doing roughly the same job -- say, an LV grinder and an MV grinder -- then they should consume roughly the same amount of power. The MV unit does more, so it consumes more; but not radically so. A big industrial grinder might well eat 40 kW -- that's 40,000 watts. If it's running at anything in the 120-480 volt range, it will require some real thick cabling -- which, fortunately, is just what we have -- cables that appear to be about 20 cm in thickness. But since our grinder fits in a one-meter cube, I have to figure it's a bit smaller. It would not be out of line to call an LV grinder a 10 kW load, an MV, 15 kW.

Now again, I don't insist on anything like strict adherence to real life in batteries. But let's try to look at them honestly. I think we'd like a fully-charged battery box to run at least one machine of its voltage tier overnight. If we take the LV grinder above, that's 12 * 10 = 120 kWh. That's a honking big battery; a Tesla Roadster has a battery rated at 54 kWh. Still, it's within hand-waving range. Considering we're building an LV battery box out of 4 portable batteries, it's a bit of an... overstatement.

The MV battery box, though, is built from 5 LV battery boxes; and can be expected to hold 5 times as much energy, more or less. So should the MV box hold 600 kWh? Note that the fact it operates at the Medium Voltage of 240 V is not the consideration; only that it contains more batteries. We might then expect the HV box to have a capacity of 3000 kWh, and this is kinda lunacy in the Real World. Since construction of such a thing demands quite a bit of resources, though, should the payoff not be great? Oh, yes, fiddle with the numbers, balance the game play. But why not start with numbers that make sense?

I'd actually prefer to consider the batteries arranged in a series-parallel circuit, so that each tier only doubles the capacity of the previous one. So LV box, 120 kWh; MV, 240 kWh; HV, 480 kWh. That's a bit more credible and provides a bit more balanced game play. After downconversion, the HV box might run as many as three MV grinders... for about ten and a half hours.

It should be patently obvious that a hand-held power tool has, internally, a single battery and holds charge at a fixed voltage. So regardless of which box it is charged in, it should consume the same amount of energy, in watt-hours, leaving the box depleted by that much. We can wave away the charging circuitry that allows the same tool to be charged at various source voltages.

Again, I'll gladly wave off any consideration of the fact that batteries hold DC and virtually all industrial machinery consumes AC power. As model railroaders like to say, there's no need to count the rivets on the boiler.

Now let's look at our generators, since batteries only store power. Like machines that consume power, generators generate power and are rated in kWh regardless of the voltage they produce. I can't see the least reason why there should be an MV windmill and an LV water turbine; it makes no sense. Rather, let there be LV and MV versions of both, with the MV version significantly more expensive to craft and capable of producing more power.

For that matter, since only MV units work with pipeworks... is there any reason there should not, automatically, be MV versions of every LV machine? Tell me why not. Should it even be a major task to code them all? It might even be within my limited ability.

Solar power is a sore point with me; it's vicious to produce, as I did, four HV arrays and parts for another. Do the math; that's 1000 doped wafers per array, therefore over 10 full chargings of the alloy furnace, with another 20 full chargings to make the blank wafers. With 5 HV arrays produced, that's.. yes, 150 full chargings, assuming no slip-ups. I suppose I might have used pipeworks to accelerate the process... but my alloy furnaces were busy with wafers, not stainless steel. To start, I had to use LV alloy furnaces. And so it goes. (Please don't say we fixed that already. My point is that I already invested that effort.)

Now the point of solar power, I'd think, is that it works, at least if the sun is out. I put mine on a tower reaching above 130 m, as dictated by the comments cleverly hidden in the code. This worked; although there is much grumbling about how. Certainly I don't consider it an improvement to go up the ladder, disconnect the arrays, and stick them on my roof. I worked hard on that tower and it's a shame to see it go to waste. I don't care what sort of nasty kluge must be worked; solar should work when the sun is out. I should think it a simple thing to check the time of day.

Now we have windmills; and I don't see the point, if they're required to be at a certain distance from the ground to work at all. Should I build my workshop in the air? Or pay a kid to stand up there all day and night? No. Electricity does not stop working when you turn your back. Please do not blame the core devs or weaknesses in the core engine. It's a simple thing to store a complete electrical network, distinct from its nodes, merely as an electrical network; and recalculate the network when something alters the nodes that comprise it. A player has to load the chunk to alter it. I refuse to worry about a guy who builds a castle in the sky, two chunks up from my solar, and manages never to load the chunk the solar is in while he shadows it. There is no need to worry that a bird is going to shit on the solar array when you're not looking... or get caught in a windmill's blades.

As long as we're discussing generation... nuclear reactors should indeed be quite expensive to build; and the time you get out of fueling one should be long. So far, so good. It's my understanding -- not tested yet, thank you -- that damaging one in operation does not actually cause anything significant to happen. A big concern, and a realistic one, is that a reactor melting down will ruin the next-door neighbor's house. But let's show some unrealistic sense and simply kill the player standing next to it -- and, of course, shut down the reactor. Can we at least agree to do that?

Now back to cabling -- by which I mean to include all the forms of connection among parts that generate, consume, and store power. I don't know what's going on now but it doesn't work. Why not? I smell a lack of respect for basic electrical engineering.

First, let's agree to disregard all cable losses, just to simplify the model. Then all connected cables can be treated as a single point. What seems to be confusing everyone is what happens at that point, to which a large number of sources and sinks are connected. Let me explain how this works in the prototype.

We said that the nominal LV was 120 V. If we have sufficient generators online and our batteries are fully charged, then we can assume voltage regulators simply discard power. But if we connect too many loads to the circuit, then the actual voltage will drop below the nominal value. This is the time that battery boxes should start discharging; and at a rate proportional to the discrepancy in generated and consumed power.

So, for example, if we have one 10 kW generator going and one 10 kW grinder, all is well. If we connect a second grinder, our load is 20 kW; and if we have exactly one battery box in the circuit, that box has to discharge at a rate of 10 kW to make up the difference. That box has a capacity of 120 kWh; so it will last about 12 hours before fully discharging -- assuming it was fully charged at the start. During the whole discharge cycle, actual line voltage will remain somewhat below nominal; when the battery is exhausted, voltage drops to zero, of course.

It's perfectly reasonably to assume constant losses and calculate them on some simple basis. Standby power for machines, battery leakage, cabling losses per node.

Power converters seem to be a special mystery; but all they are is big transformers. The rule on a transformer is -- disregarding losses -- a load on the output is a load on the input. So a converter connected to an output line with no machinery on it should hardly load its input; a converter on a heavily loaded output line should draw maximum input power. Watts in, watts out. Voltage does not enter into this.

The simplest way to model batteries is to assume that each has a constant maximum rate of charge and discharge. If the actual line voltage is equal to nominal, the battery charges... which puts additional load on the line and might actually pull it below nominal. So the charging rate -- in kW -- decreases; and if the line voltage goes low enough, stops charging altogether; if lower still, the box starts to discharge. It's easy to work this all out with simple ratios of power available and power consumed. For reasons I hope should be obvious, batteries should be greedy to charge and reluctant to discharge, compared to converter response. That is, a shortfall should be made up out of converter capacity first.

I realize that to those untrained in EE, the above discussion may not be as plain as I'd like. I'm more than willing to clear it up as best I can, if anyone will be kind enough to point out any obscure features.

I'm not at all certain of my ability to dinker with the code itself to bring it into line. I have some ability but I don't imagine myself a software jock; I'm just an old hardware dog. However I'm willing to dip in and fiddle. What's wanted most of all is a willingness among the 'technic' team to think seriously about sticking to a particular model of electrical power distribution and not try to invent physics all over again de novo, like Athena from Zeus' brow.

Charging batteries and discharging

Hello,
I've the problem (which I can't solve myself), when I try to power a quarry with 9 HV generators and 1 HV battery then I get this:

  • Battery fills up, cause I discharge my blue energy cristals
  • Quarry digs 33 cobble
  • I think Battery needs to fill up again and fire up some generators
  • Quarry stopps when supply is over 0
    = Battery can not charge and discharge at once :/

function Settings not found

00:38:01: ERROR[main]: ========== ERROR FROM LUA ===========
00:38:01: ERROR[main]: Failed to load and run script from
00:38:01: ERROR[main]: /home/pagliaccio/.minetest/games/technic_game/mods/technic/technic/init.lua:
00:38:01: ERROR[main]: ...t/games/technic_game/mods/technic/technic/config.lua:4: attempt to call global 'Settings' (a nil value)
00:38:01: ERROR[main]: stack traceback:
00:38:01: ERROR[main]: ...t/games/technic_game/mods/technic/technic/config.lua:4: in main chunk
00:38:01: ERROR[main]: [C]: in function 'dofile'
00:38:01: ERROR[main]: ...est/games/technic_game/mods/technic/technic/init.lua:13: in main chunk
00:38:01: ERROR[main]: =======END OF ERROR FROM LUA ========

i have try add technic.conf in world path, but it not work. minetest version 0.4.7

Rant

Please see:

So I've been playing on BrandonReese's server, which runs 'technic' as well as many other mods; and from the start I've been upset by 'technic'. I'm an old hardware dog; my foundation is EE, with CS sprayed on top, not the other way around. Nothing in 'technic' obeys the laws of physics -- I mean the laws pertaning to electricicty. But I'm an engineer, which means I'm a practical person; so I experimented and learned how this through-the-looking-glass world works. And I built accordingly. I spent many, many hours over a period of weeks building according to the model with which I was presented. I got to the point of building some pretty decent processing lines.

Then BR decided to update 'technic' and other mods. Now my factory is idle, dead. Little that used to work, still works. My batteries don't charge, my solar arrays don't power up, my converters don't convert. The mouseovers on converters and switching stations either lie or tell a tale of absurdity. Either way, it's weeks of hard work down the drain. I feel cheated and abused.

I might even suck it up and say, "The gods changed the laws of physics; I will learn the new set." Alas, the only slightly-outdated documentation I've found is now totally outdated. I have no way to see what's what anymore without digging through the source code and experimenting painfully. I'm pretty sure that my long hours spent crafting up four HV solar arrays are gone forever. What's less clear is whether, if I spend time building windmills, then I will get to enjoy them for any length of time before they, too, are smashed by the next update.

Now I have three cures for this problem and they work together -- not really three distinct cures but three aspects of the same thing. I have written them out as separate issues because otherwise I think they'll be indigestible; and they do attack the problem from different angles.

If I had to give one name to this three-headed solution, it would be: Quit fooling around. We're professionals; let's act like pros. I have zero respect for any viewpoint opposed to this basic idea -- none. Any job worth doing is worth doing well. That does not imply perfection; it implies doing a good job and not smoking too much dope to think straight.

It is impossible to begin the game

Let me explain myself: you can't get power.
That's why:
To get power, you need a switching station.
To get a switching station, you need stainless steel.
To get stainless steel, you need iron and chromium dust.
To get dusts, you need to run a grinder.
To run a grinder, you need power.

It is therefore impossible to get power when playing survival.

Charging station idea.

With tools at different supply levels I suggest adding a proper charging bench which can charge the tools thus eliminating the charging functionality from the batteries.

Requiring energy for lighting etc. requires whole banks (rooms!) of batteries and as such it becomes unwieldy to use them as charging benches.

All supply tiers can be changed regardless of the supply network it is placed on.
However(!): the same conversion restrictions the supply converter has applies here.
LV supply will charge a MV tool at 1/4 charge, and HV at 1/16 charge
MV supply will charge a LV tool 5x faster and HV tool at 1/4 charge
HV supply will charge a LV and MV tool 5x faster.
5x is max boost a battery in a tool can handle if it should not burst into flames.

The machine will need some plugins to function:
LV/MV/HV charging modules opening LV, MV, and HV charging.
Each charging module will add 2 charging slots.

4 expansion slots are provided for a total of 8 charging slots per machine.

Implementation wise it is much the same as the supply converter in regards to detecting what kind of supply network it is put on.

Comments?

Solars seem to no longer work when in an inactive block

tested with: 468d79d

Solar in inactive blocks no longer work. Typical example are solars placed over the clouds at 130. They used to produce power but don't update their state (even work at night when last visited at day) as long as the switching station was in an active block. Now they seem to not work at all.

Additionally solars need to be placed above 0 and have already max power at a high of 35 now while the comments in the code still say > -10, max @ 130

LV Machines do not appear to generate power:

On a private Technic_Game server, I made a LV Water Mill, LV Bat Box and a LV E. Furnace.

I wired the machines up as usual.

Put a water source on top of the water mill.

And expected power to have been generated.

However, power did not generate from the water mill.

I repeated replacing the cable and replacing the machines, to no avail.

I even tested with a coal generator.

This is a serious issue.

The server version is: 0.4.7 (unknown commit, because /status doesn't issue a commit version.)

Editing Higher Chest Infotext

I have considerable difficulty editing infotext on silver chests, locked or unlocked; I don't hope it's better with gold. On first construct, I get an error warning of a missing pencil icon image.

When I open the chest, I see a dummy icon, a colored square that changes -- very reluctantly -- between "edit" and "ok" states. In one state, editable text appears. If I'm lucky, when I close the chest, I get the edited text in my HUD.

I've tried punching the icon, right-clicking, clicking two or three times, clicking like a madman; I've tried waiting for long periods of time, closing and reopening the chest, digging up the chest and replacing it. It's just very stubborn; nothing seems to work consistently.

Suggest the issue may be caused or aggravated by the desire to switch formspec states between "edit" and "ok". Suggest a single state with an 'OK' button only, the infotext editable at all times. I don't think this will hurt anyone.

Suggest the 'OK' button be a simple text button reading 'OK'; and perhaps that it appear to the right of the editable text field, as editing the text comes logically before okaying it. We don't need the burden of loading yet another image.

Wires "raillike"??

Now that I am working on devices that would be needed to get electrical light etc. working all the wiring needed requires some funny house architecture or really thick walls which look silly when windows are put in.
So my question is if it would be possible to have the wires act like rails, i.e. cling to whatever surface they are on? Then the wires could be placed on the inner surfaces of a house or on the outside and fed through the wall without requiring the wall to get any thicker.
I don't know how to do this, so this is a proposal for you other clever people out there.

Problem with Technic translation

I'm translating Technic to Brazilian Portuguese and when I finish the work and tried to test it, Minetest stopped world creation with this error message:

stack traceback:
    ...minetest/sources/minetest/bin/../builtin/builtin.lua:15: in function 'error'
    ...st/sources/minetest/bin/../builtin/misc_register.lua:67: in function 'check_modname_prefix'
    ...st/sources/minetest/bin/../builtin/misc_register.lua:98: in function 'register_item'
    ...st/sources/minetest/bin/../builtin/misc_register.lua:170: in function 'register_craftitem'
    ...echnic/technic/machines/register/grinder_recipes.lua:67: in function 'register_dust'
    ...echnic/technic/machines/register/grinder_recipes.lua:88: in main chunk
    [C]: in function 'dofile'
    ...test/mods/technic/technic/machines/register/init.lua:9: in main chunk
    [C]: in function 'dofile'
    ...dgg/.minetest/mods/technic/technic/machines/init.lua:3: in main chunk
    [C]: in function 'dofile'
    ...e/adm/fredgg/.minetest/mods/technic/technic/init.lua:35: in main chunk
11:10:48: ERROR[main]: ========== ERROR FROM LUA ===========
11:10:48: ERROR[main]: Failed to load and run script from 
11:10:48: ERROR[main]: /home/adm/fredgg/.minetest/mods/technic/technic/init.lua:
11:10:48: ERROR[main]: ...minetest/sources/minetest/bin/../builtin/builtin.lua:16: Name technic:carvão_dust does not follow naming conventions: contains unallowed characters
11:10:48: ERROR[main]: stack traceback:
11:10:48: ERROR[main]:  [C]: in function 'errorfct'
11:10:48: ERROR[main]:  ...minetest/sources/minetest/bin/../builtin/builtin.lua:16: in function 'error'
11:10:48: ERROR[main]:  ...st/sources/minetest/bin/../builtin/misc_register.lua:67: in function 'check_modname_prefix'
11:10:48: ERROR[main]:  ...st/sources/minetest/bin/../builtin/misc_register.lua:98: in function 'register_item'
11:10:48: ERROR[main]:  ...st/sources/minetest/bin/../builtin/misc_register.lua:170: in function 'register_craftitem'
11:10:48: ERROR[main]:  ...echnic/technic/machines/register/grinder_recipes.lua:67: in function 'register_dust'
11:10:48: ERROR[main]:  ...echnic/technic/machines/register/grinder_recipes.lua:88: in main chunk
11:10:48: ERROR[main]:  [C]: in function 'dofile'
11:10:48: ERROR[main]:  ...test/mods/technic/technic/machines/register/init.lua:9: in main chunk
11:10:48: ERROR[main]:  [C]: in function 'dofile'
11:10:48: ERROR[main]:  ...dgg/.minetest/mods/technic/technic/machines/init.lua:3: in main chunk
11:10:48: ERROR[main]:  [C]: in function 'dofile'
11:10:48: ERROR[main]:  ...e/adm/fredgg/.minetest/mods/technic/technic/init.lua:35: in main chunk
11:10:48: ERROR[main]: ======= END OF ERROR FROM LUA ========

As you can see on the "technic:carvão_dust" element, it looks like Technic is translating node names (and image filenames too, as I discovered when made some other tests).

I used the latest template.txt to create my translation.

Add grinding ingots

Add posibility to change ingots into dusts in grinder. This can be useful when we have gold ingots and we need gold dust for solar panels.

MV to LV step-down does not work

The new Converter is awesome and all, but when I try to step-down from MV to LV, it refuse to work... HV to MV works fine. I believe that it just isnt sensing the power in the MV cable. Also, the Nuclear Reactor still overheats even if i make the required covering...

Update recipes in chests mod.

Change recipes of copper chest and gold chest. Change moreores: copper_ingot into default:copper_ingot and moreores:gold_ingot into default:gold_ingot.

LV, MV, HV tools

How about letting the different tools only charge in the battery tier they belong to?
The laser should really be a MV or HV thing considering the power it packs.
The chainsaw an LV item, the sonic screwdriver perhaps a HV tem?

The chargers should then be upgradable with more slots or faster charging or something like that. I think some of the MV machines have this feature.

I suggest this because it doesn't make much sense for instance charging a 5V device directly on the 230V mains, right? (blue smoke!)

Opinions?

nuclear craft recipe error

minetest.register_craft({
output = 'technic:hv_nuclear_reactor_core',
recipe = {
{'default:stainless_steel_ingot', 'default:stainless_steel_ingot', 'default:stainless_steel_ingot'},
{'default:stainless_steel_ingot', '', 'default:stainless_steel_ingot'},
{'default:stainless_steel_ingot', ''technic:hv_cable', 'default:stainless_steel_ingot'},
}
})

-->

minetest.register_craft({
output = 'technic:hv_nuclear_reactor_core',
recipe = {
{'technic:stainless_steel_ingot', 'technic:stainless_steel_ingot', 'technic:stainless_steel_ingot'},
{'technic:stainless_steel_ingot', '', 'technic:stainless_steel_ingot'},
{'technic:stainless_steel_ingot', 'technic:hv_cable', 'technic:stainless_steel_ingot'},
}
})

GPL-2 only license makes it incompatible with AGPL mods

Hi,

after a discusion with Anthony over at Uberi/Minetest-WorldEdit#25 , I chose to ask you to allow the use of the Technic mod under later versions of the GPL.

THe issue at hand is that, due to the licenses, the Technic mod and WorldEdit can never be shipped or used together because the licenses prohibit the combination with code under the other one.

As AGPL makes a lot of sense to Anthony, and there are more mods that are AGPL than GPL-2 only, I kindly ask if you would be willing to relicense the technic mod under GPL-2+, allowing the AGPL-compatible GPL-3 and thus making it possible to ship both mods with Debian.

-nik

lamp?

someone want or is writing an electric lamp?

[master] battery and other machine not charge

after last update of branch master my machine not work.
i have create a new world for test
snapshot1

battery box is in idle, furnace is upowered but solar pannel produce and also generator

Allow battery boxes to also be used on low-voltage circuits

If you have an LV power circuit at the start, but have gotten lvl2 or lvl3 power tools, it can take an exceedingly long time to charge them since you're limited to a 50k-charge battery box. It'd be nice to either a) have upgradable battery boxes or b) use the MV/HV battery boxes for storage.

I propose allowing the higher-voltage battery boxes to be used at their level or lower. I think this is also consistent with their construction, as the MV boxes have an MV transformer, and LV transformers in all of its consituent LV boxes (the HV box follows this pattern for LV, MV, and HV circuits). So it would make sense that these boxes would work on any voltage level below their own design. A way to penalize this a little is to lower their charge/discharge rates by 10% per level difference. So a HV battery box on an LV system would only charge at 80% of how fast an LV battery box would charge on that same system, since it has to go through two sets of transformers to the batteries, each imposing a 10% inefficiency.

Putting the reactor in wrong setting causes crash

Just tested, iwhat happen when a reactor gets misplaced.
I misplaced and fuelled it....this happened:

14:28:46: ERROR[main]: ServerError: LuaError: E:\Programme\minetest\bin..\built
in/vector.lua:5: Invalid vector
14:28:46: ERROR[main]: stack traceback:
14:28:46: ERROR[main]: [C]: in function 'assert'
14:28:46: ERROR[main]: E:\Programme\minetest\bin..\builtin/vector.lua:5: in fu
nction 'assert_vector'
14:28:46: ERROR[main]: E:\Programme\minetest\bin..\builtin/vector.lua:107: in
function 'subtract'
14:28:46: ERROR[main]: ...test\bin..\mods\technic/machines/HV/nuclear_reactor.
lua:123: in function 'check_reactor_structure'
14:28:46: ERROR[main]: ...test\bin..\mods\technic/machines/HV/nuclear_reactor.
lua:215: in function <...test\bin..\mods\technic/machines/HV/nuclear_reactor.lu
a:195>

Documentation

My father was an old mainframe guy -- really. I was inducted into the mysteries not merely of the 80-column Hollerith card but of the obscure control card drum behind a discreet door in the keypunch machine. At home, we used 132-column greenbar fanfold for scratch paper.

When I was just starting out -- as a hardware dog but, as a microelectronics guy, constantly brushing into software of some sort -- Pop gave me one piece of advice that has always stuck with me, and which I consider a tenent of my only religion:

"One line of comment per line of code." -- probably originally from IBM

I should explain that to get your score, you count blank lines as zero, code lines with trailing comments as zero, code lines without comments as -1, and "block" comments or comment-only lines as +1. The goal is to achieve a score of roughly zero.

Kids scorn comments and think that rule is nonsense. They write entire undocumented subroutines and say, "Anybody can understand that self-documenting code, because my writing is so clear."

BULLSHIT.

I agree that as we move away from FORTRAN towards C and Ruby, we probably need a bit fewer comments than in the old days. But not much. Yes, the code itself is more readable but the task it performs is more complex. The amount of explanation required is about the same.

Nobody is sure who said this first: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." However, it is gospel. That maintainer may very well be you. It might be me.

However, I didn't start here to talk about comments in code. I started to talk about documentation. Docs are distinct from comments. As I said recently to a fellow, code is written for the machine; comments are written for developers; docs are written for users.

And if you don't have users, then your code is worthless, eh?

I'm going to keep this issue short because I've already promised to take up the burden of documenting 'technic'... provided we get some agreement on this and the other two heads of a solution to my rant-problem. However, I can't do it alone. So, some principles:

  • Docs need to be in some sort of content management system. One big web page is not that. I uphold wikis, specifically the MediaWiki engine, because it is fast and powerful. Wikis, unlike BB-style forums, downplay egos and provide a high signal-to-noise ratio. Navigation is easy and deadwood easily archived out of sight. Please do not judge all wikis by the wikis you may have seen, especially not by Wikipedia. That latter suffers from the crushing burden of "Anyone can edit"; and if everyone could agree on anything, we wouldn't have wars in which poison gas is employed against civilians who worship in the wrong direction. Wikis work best when the group is fairly small -- such as the number of people who use 'technic'.
  • Docs are everyone's responsibility. I'm willing to take a big bite out of the task... and there should indeed be some one person carrying the can. But docs are good when everyone on the team makes them good. It simply is not acceptable to write code and turn it over, saying "This does neat stuff, buy it." Every new feature, every patch, every pull request should be accompanied by as much plain English as is needed to explain what the thing does. This might be pretty rough and you can leave it up to the dedicated docs man to clean it up and fit it into the docs package. But you cannot just drop code into the project with a one-line explanation.
  • That said, I'm not above reading code when writing docs. Help me out. Don't hope I have a telepathic connection to your head of a week ago. Comment, comment, comment. Yes -- I tell you again -- your code is not self-documenting. Really, it's not. Yes, really. You need to commment it. What if you get hit by a bus tomorrow? What if I have to maintain it some day? What if I know where you live?
  • Docs must be kept accurate. As the underlying project changes, so must the docs. But how is that possible if the code changes every day? Well, the docs cannot document every new fiddle -- it's impossible. There will always be some lack of synchronization with the bleeding edge. However, docs can accurately reflect the code at some given point. We call that point a "release" and we need to take that concept seriously -- for this reason alone, ignoring all others. It's perfectly okay to have more than one version of the same docs -- one version of the docs for each release of the project. Yes.
  • Docs are meant to be read by users -- by definition, people who do not develop the project. Therefore it is inexcusable to refer to the code or use terms that don't apply outside the code base. As much as possible, docs must be written in end-user terms. We can tolerate imprecision; it's accuracy we require of docs.

Software should not be a puzzle that users try to solve, a knot that they pick at for days or weeks trying to unravel. Software, like any other tool, is most useful if users can figure out easily how to use it to best advantage. I will not be the person to inveigh against masturbation; but sex with other people is better. And writing software that other people enjoy using is better than writing cool code that amuses only yourself.

Untranslated strings on technic

I used UI search feature to filter nodes that have "technic:" on name (sorry if I'm listing any block that isn't part of technic) and found the following untranslated strings:

  • RE Battery
  • Blast-resistant Concrete Block
  • Brass Block
  • Brass Ingot
  • Chromium Block
  • Chromium Ingot
  • Chromium Lump
  • Concrete Block
  • Concrete Post
  • Concrete Post Platform
  • All three Constructors MK
  • Copper Chest
  • Copper Locked Chest
  • Frame
  • Frame motor
  • Gold chest
  • Gold Locked Chest
  • Granite
  • All glowlights (does technic have this nodes too or they're from homedecor?)
  • Injector
  • Iron Chest
  • Iron Locked Chest
  • Marble
  • Marble Bricks
  • Chromium Ore
  • Uranium Ore
  • Zinc Ore
  • MIthril Chest
  • Mithril Locked Chest
  • Power Radiator
  • Rebar
  • Silver Chest
  • Silver Locked Chest
  • Stainless Steel Block
  • Stainless Steel Ingot
  • Template
  • Template motor
  • Template (replacing)
  • Template tool
  • Tool Workshop (which is strange, because it IS translated on pt.txt)
  • Uranium
  • Uranium Block
  • Zinc Block
  • Zinc Ingot
  • Zinc Lump

Failed to load and run

If I try to start minetest with this mod(Dependencies istalled and working) say:
ModError: Failed to load and run
Y:\minetest\bin.. \mods\minetest\techinik-maste\init.lua
Sorry for my bad english.

Bug in furnace

From IRC
I have an electric furnace, with the 4 output slots occupied, I added a different kind of ore to the input slot, and now the menu keeps flickering and I can't remove anything quickly enough

Chainsaw -- Do Not Use

Right now (2013 Nov 30) on BrandonReese's server, using the chainsaw invariably causes some fatal fault resembling a server crash: All clients are disconnected. We've tried this several times and with more than one player wielding different chainsaws on different targets. In each case, the target is not cut and all clients are disconnected.

We recommend DO NOT USE CHAINSAWS at this time.

Git Workflow and Project Discipline

I just spent about an hour and a half discussing this git workflow. Here's the same thing rendered on a scale suitable for printing on paper and snapping into your project binder.

Now the original, by Vincent Dreissen, is hugely popular. Google "gitflow" if you don't believe me. Mine is a minor improvement, largely to cut down on the SVG file size; and even so, a couple people have forked it. Run that as an image search and you will see dozens of variations on the same basic idea... which is pretty simple:

  • Work on more than one branch. Work on several branches, since git is not SVN; creating and merging branches is easy.
  • Apply a consistent naming scheme to branches. There's plenty of room to wiggle but if you call a branch "feature-moof" then I will figure that you are developing a dog-cow feature there. If you call a branch "bugfix-4423" then I will hope that you are fixing issue #4423 in that branch.
  • Avoid the branch named 'master'. It is the default so different people use it for different things... and nobody is really sure what it is but everyone assumes he is. This is just plain dangerous.
  • Maintain two "immortal" branches; I have called them 'devel' and 'trunk' but of course other names would work as well. Their roles differ sharply.
  • The 'devel' branch is the integration branch; this is where various features are pulled together and conflicts sorted out. No end-user should ever download and install 'devel'.
  • The 'trunk' contains only releases. Every single commit on 'trunk' shall be tagged with a version number and constitute something that is being shipped. Only commits on 'trunk' should ever be considered shipped to end-users.
  • All other branches are work branches and can be pruned off when either abandoned or merged into another branch.
  • At some point in time, some one person, preferably in consultation with the team, shall decide: "It is time to release this thing." At that moment exactly, it is time to bump the version number (see below) and create, from 'devel', a 'release-x.y.z' branch. From that point on, work on that branch should be dedicated only to making the package ready to ship. No feature may be added! Bugs should be fixed, broken features disabled. It is okay to merge back to 'devel' but never the other way around. When the release branch is "done", it's time to merge it into 'trunk', tag that merge commit with the version number, and step away from it.
  • When we ship something, we promise, implicitly, that the thing works as advertised. We can waffle all we like and evade legal responsibility but we have a moral, ethical, and professional obligation to ship stuff that works. Those who can't accept that obligation aren't professionals; they're dabblers.
  • Despite the previous point, it is a plain fact of life at the bleeding edge that we will ship stuff with bugs. The only file that contains no bugs is the empty file. So when a bug is reported, we need to uphold our professional reputation by fixing it. So create a bugfix branch, fix the bug, and merge it into trunk -- bumping the patch number, of course. It might not hurt to merge that bugfix into 'devel', too.
  • Although we may think the new, cool stuff is the only stuff -- it's not. Out there, our users may actually like the old stuff. Don't spit in their faces by ignoring them and just coming out with one major release after another. If a release proves popular, create a support branch for it. Work there from time to time. That doesn't mean to add more features; it means to continue to iron out bugs from an earlier release, incrementing the patch number. Therefore it is completely possible that 'v 1.2.5' and 'v 2.0.1' are both current releases. Let the user decide; don't be an arrogant dictator. Not everyone is willing to pay the price for new features.
  • And... because we are currently wallowing in a trackless release wasteland... yes, somebody needs to dig through the repo and pick exactly one commit, one SHA, and determine that this will be made into a functioning release. Set the version to '1.0.0', create the 'release-1.0.0' branch, and let's get started with a clean slate.

Semantic Versioning:

In a nutshell, all releases should be numbered x.y.z where a bump in x means a release incompatible with the previous, a bump in y means new features but compatible, and a bump in z means no new feature but only bugfixes.

There is simply no good reason for any other system. Semver is gaining ground rapidly, it's based on conventions hammered out over time by thousands of developers. In our case -- in the case of 'technic' -- I would avoid all use of extra elements, such as '-alpha'. Release only numbered versions! KISS.

Note especially that any incompatible change forces a major version bump. That includes dependencies on other packages. If the new release requires a new release, even a bugfixed release, then bump the major version -- it's no longer backwards compatible. Every minor version bump release should be a drop-in replacement for the previous one and bring only smiles; every patch bump release should be purely conservative and lessen the user's grief -- never add to it.

The 'technic' version number cannot track the version number of Minetest! That's a messy and dangerous swamp. The hidden assumptions lie like hungry alligators waiting to eat your feet... and mine. Bump mod versions when required, and only when required, and whenever required. There's a place to state a dependency on a given version of Minetest (README, at minimum). So state; and let the mod version say what it must.

I should like to think I can skip my final comment on version numbers... but I know better. We must, absolutely, sever all connection between version number and ego. I don't care what the public thinks it means when a package says "Version 2.0". They're probably wrong. Bump versions when and as demanded by Semver. Period.

Missing textures

There are some missing textures on technic:

  • technic_akalin_dust.png
  • technic_alatro_dust.png
  • technic_arol_dust.png
  • technic_talinite_dust.png
  • technic_template_replacer.png
  • technic_template_tool.png

Trees and branches

Lately we faced problems merging things developed here and there.
A few weeks ago new project has rised, Technic Game.
Some folks were contributing to master, indev or game.
We had serious problems merging together all the changes, so here goes my proposal:
Lets sync all the plants pieces together at the weekend.
And then let commit only to indev.
What will work and proven good quality will go to master/game.
IMHO master/game shall be all the time the same.

Propose change to power distribution

Now that I have worked with the down converters I found that having everything going over the batteries made the electric networks starvation prone.
Lets say we have a producer making 1000EUs. We have a battery and a grinder attached with the battery being closest to the producer. Now as long as the battery is not fully charged the grinder will get no power.

With the latest addition we have three types of machines:
PR: Produces EUs
RE: Consumes EUs
BA: Stores and delivers EUs

My suggestions are as follows:

  1. Let the producers (PR type) and batteries (BA type) distribute EUs to all receivers evenly. Receivers are defined by the RE and BA types.
    Perhaps having BA supply BA will create unwanted convergence issues so that we for efficiency should let PR distribute to BA+RE, BA distribute to RE only.
    Distribution is done by counting the number of RE and BA nodes and make an even distribution.
    The down converter provides an example of this very behaviour. It is fun to see a bank of 16 batteries charge all at the same time :-)

  2. Machines should have no power reservoir of their own. When power is cut they stop working. This would for example mean that we could run the machines on solar power alone, but when the sun settles the machines would stop working immediately unless batteries are present.
    The even distribution means that enough power must be supplied to all the machines unlike today where some might still work where others are starved when power is low.
    In fact the machine can check if it receives say 2000EUs on its mains. If not it will not work. (And IF used we could even make it break down?)
    We could also set a "standby EU-draw" like real machines have.

What do you think?

Cheers.

Balance drill and lasers

A conversation with VanessaE online tonight about adding recipes for the mk2 and mk3 laser devolved into a lengthy discussion about the charge, recipes, and costs of the mining drill, mining laser, and the energy crystals. The following ideas were suggested as the result of the discussion. I've added rationales where appropriate:

Mining drill:

  • Drilling cost per node: 200, 500, 800 (200, 600, 1800 currently)
    • By assuming a a drill head costs 100 to run and the mk1 having 1, the mk2 having 4, and the mk3 having 7, with the base machine costing 100 to run by itself.
  • Drill charge: 50k, 200k, 650k (60k, 240k, 960k currently)
    • Based on crystal power values
  • Yielding:
    • Shots at max drilling settings: 250, 133, 89
    • Nodes per full charge: 250, 400, 722 (300, 400, 533 currently)

Mining laser:

  • Drilling cost per shot: 1000, 2000, 3000 (400, 400, 400 currently)
    • Yields rough per-node costs of 143 (58, 36, 13 currently)
      • Laser is more power-efficient than the heavy mechanical drill.
  • Alter recipe for mk1 (consistency with mining drill and colors now make sense for mk1):
    • Upper-right battery is changed to a red crystal
    • Middle-right battery is changed to a steel ingot
  • Mining laser charge: 50k, 200k, 650k (40k, 160k, 640k currently)
    • Based on crystal power values
  • Distance per shot: 7, 14, 21 (7, 11, 30 currently)
    • Each diamond used in the lens allows for 7 tiles to be shot, since 1x diamond lens is added per level, it increases by 7.
  • Yielding:
    • Shots per full charge: 50, 100, 217 (100, 400, 1600)
    • Nodes per full charge: 350, 1400, 4550 (700, 4400, 48000 currently)

Red crystals:

  • Change red crystals charge to 50k (currently 100k)

Green crystals:

  • Charge: 150k (currently 250k)
  • Change gold in recipe to mese crystals

Blue crystals:

  • Charge: 450k (currently 500k)
  • Change gold in recipe to mese blocks

For reference:

  • Batteries have 10k of charge

The only fallout from these modifications are:

  • The initial mining laser is much more expensive as it required a red energy crystal. I don't think this is an issue for the early game, and I think it actually makes the mining drill look like a viable option for the early game as well.
  • Makes these objects inconsistent in terms of charge with other objects relying on the crystals, like the Battery Boxes. Currently they're set to have charge of 50k, 300k, 1500000, but if we follow the energy values we've suggested here, they really should be 40k, 200k, 1M. If that seems like too little, modifying the recipes to fill the lower-left and lower-right squares with batteries/battery boxes would give charges of 70k, 490k, and 2.8M.

MV/HV solar arrays

According to comments MV solar array is supposed to produce up to 720 and HV up to 2880. However both are capped to 160 by this:
if charge_to_give>160 then charge_to_give=160 end

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.