Lua optimization tipps

[Byakuren]

You need to check out how technic does this, they associate all the logic with the switching block and update it when a node is placed or removed from the wire nodes that connect to that switch. If you don't do something similar, no amount of other optimization is going to save you.

How are you so certain that there are no performant approaches that don't rely on a single controlling node?

[SegFault22]

The system I was describing would have a controlling node, but it is not limited to one per network. All provider nodes are controlling nodes, and only control whatever is on the output side. If it has an input side (as would a power storage device) then it can also partially be controlled by another provider. For example, a generator controls the input side of any connected power storage device, to put power into it; and the power storage device controls all devices attached by their input side to its output side, in order to put power into them.

This avoids the limitations which come with a single controller node. If the part of a network with the central controller is destroyed in an explosion or something, the whole network will stop; but with this other system, only the part of the network which has been detached will stop functioning, and any providers can still output power to any consumers which are still connected. It would much more flexible, but it may use more system resources unless it is optimized.

[Chiu ChunLing]

It's not a matter of certainty. It's that there is a proven, workable approach for making it so that you can identify active networks and carry out calculations for them only rather than having to continuously check every node type that can attach to a network. I'd be happy if SegFault22 or anyone else discovered a radical new way to do this kind of calculation efficiently, but needs and hopes should never be confused when both are in play.

SegFault22 needs to check out how the technic mod puts all the logic involved in a single node type that serves as a hook for identifying and storing the configuration of a given network. I hope that anyone makes a radical breakthrough in computing theory. By identifying the difference between those propositions, I can see that SegFault22 learning how technic mod handles this and understanding how it saves computation resources increases the likelihood of making future improvements over that approach.

On the concern of knocking out parts the the network, you can use transformers to have a hierarchy in which the top level of the network is independent of the lower networks, and the lower networks are all independent of one another. Technic only uses these one way, and with a fixed power draw. You could make them go both ways and provide an interface for the lower level system to give excess power back to the higher level grid. That's building on a proven approach.

[Byakuren]

It's not a matter of certainty. It's that there is a proven, workable approach for making it so that you can identify active networks and carry out calculations for them only rather than having to continuously check every node type that can attach to a network. I'd be happy if SegFault22 or anyone else discovered a radical new way to do this kind of calculation efficiently, but needs and hopes should never be confused when both are in play.

SegFault22 needs to check out how the technic mod puts all the logic involved in a single node type that serves as a hook for identifying and storing the configuration of a given network. I hope that anyone makes a radical breakthrough in computing theory. By identifying the difference between those propositions, I can see that SegFault22 learning how technic mod handles this and understanding how it saves computation resources increases the likelihood of making future improvements over that approach.

On the concern of knocking out parts the the network, you can use transformers to have a hierarchy in which the top level of the network is independent of the lower networks, and the lower networks are all independent of one another. Technic only uses these one way, and with a fixed power draw. You could make them go both ways and provide an interface for the lower level system to give excess power back to the higher level grid. That's building on a proven approach.

If you didn't mean to make an absolute statement, you shouldn't have said something like "no amount of other optimization is going to save you"

[Chiu ChunLing]

By "something similar" I meant an approach that dramatically reduces the sheer number of calculations that must be made rather than just increasing the efficiency of those calculations, and I'll stand by that.

Too refer to that as "so certain" is fundamentally mistaking the gap between things in which knowledge is particular and measured in certainty and points about which it must be absolute. It's like saying how are you so certain that reality or your self exists...it is fundamentally meaningless to talk or even think about such things as if they were less than certain. Certainly everyone does entertain such anti-logical questions from time to time, but it never goes anywhere because you cannot properly think at all until you rest on certain assumptions rather than leaving them open..

[Byakuren]

By "something similar" I meant an approach that dramatically reduces the sheer number of calculations that must be made rather than just increasing the efficiency of those calculations, and I'll stand by that.

Too refer to that as "so certain" is fundamentally mistaking the gap between things in which knowledge is particular and measured in certainty and points about which it must be absolute. It's like saying how are you so certain that reality or your self exists...it is fundamentally meaningless to talk or even think about such things as if they were less than certain. Certainly everyone does entertain such anti-logical questions from time to time, but it never goes anywhere because you cannot properly think at all until you rest on certain assumptions rather than leaving them open..

Sorry, by something similar, I thought you meant the way Technic does it. Because the post I quoted didn't mention anything about reducing calculations, only the switching block method.

[Chiu ChunLing]

The key point is both that the calculation logic is associated with one blocktype and that updating it is only necessary when the blocks attached to that block are altered. This is a specific method of reducing calculations at the top design level, and there are other approaches, but they are all similar in the sense that you have fewer blocks that invoke a lot of complex calculations and they update the calculation logic only when necessary.

The actual code in technic isn't necessarily perfect or optimum, nor is it impossible to make changes that would allow new arrangements of power grids...the fact that currently the only way a transformer turns off is if the grid supplying power doesn't have enough to run anything is a pretty big limitation. It would be nice if the receiving system could shut transformers off from the bottom if they had enough power already (for instance, if they had nearly full battery charge). That (relatively) simple change would go a long way towards allowing SeFault22 to realize far more complex power grid interactions. Of course, you'd want to have different values for when a receiving grid turned off the transformer, so that they wouldn't just flip back and forth constantly (which undoes much of your savings on calculations). If it turned off when the receiving grid was 90% full and turned back on at 50%, a proper balance of battery storage and transformers should allow stable power supply distributed where it was actually needed without needing too frequent updates to the switching nodes.

[SegFault22]

I thought I said that my network would only update when the nodes connected to it are changed, for example being broken or exploded. Instead of using a switching node as the center, any node which can be a producer is the center, so it would have some of the benefits of the Technic system. It would be a lot different though, because you would be able to connect two or more producers to the same cable feeding some machines, instead of having some kind of conflict or error when you try to connect two controllers on the same cable.

Nodes which can accept or produce power would be "sided", so for example a generator doesn't output from the input side (fire heat generator's front face, or a solar panel's top face), and any power storing nodes (including transformers) would act as a "network controller" for whatever is on the output(s) as well as being a receiver/consumer on its input side(s). Machines such as a powered furnace do not need to output power, so they are entirely consumers.

It is just so much more straightforward when you don't have a single central node controlling the whole network; you can just put down a generator, a cable, and a powered furnace all connected, and the generator would feed power to the furnace since it is kinda like a controller. If you want to use a switch to turn off parts of the network, a switch node would be implemented that acts like a cable when it is on, but when you turn it off it isn't a valid cable any more and it triggers a network update so that the producers can be aware that power can not flow through that node any more because it is not part of a valid connection.

It is also possible to just not use a voltage system, if for example your mod isn't based on electricity. That would get rid of the need for transformers, but you would probably still need to specify a voltage number for all of the mod's devices and conduits, since it will be a central part of the power system library/API/whatever. If you want to use a voltage system and transformers, that would also be possible, but as with previously mentioned "conduit switches", the only way to turn them off would be to transform them into a node which represents the off state and doesn't act as part of the network (for transformers, they would have no input, but the output would still exist so you could drain any remaining power in the buffer) which can easily be done with some skillful mesecons integration. If your transformers should only run when the storage on the output side is less than half full, for example, you could set the storage node to output a signal when it is half full, and the transformer to turn to the off-state when it receives a signal - if they are properly connected by a mesecons wire, then it will only ever conduct when the power storage is less than half full. However there is an obvious downside, that it would cause the network to "stutter" switching the transformer on and off when power is flowing through the storage node, but this can easily be fixed by setting another storage node (connected in parallel with the other one) to output a signal when it is less than a quarter full or some arbitrary lower limit, feed the signal from both storage nodes to a toggle latch, and one of the toggle latch output sides to the transformer wire. This will turn the transformer on only when both storage nodes go below whatever capacity you specified, and turn it off only when both storage nodes go above half capacity, so long as the toggle latch is synchronized properly of course.

I would also refrain from writing any code to update the network when power flow is changing, for example when a storage node goes from full to less than full or a machine begins consuming power from its buffer. Really the network only has to update when its structure has changed. This means you don't have to worry about transformers updating the network too often, since they would be simple power storage nodes outputting whatever higher or lower voltage instead of their input voltage. They would not update the network when they are running, only when they are switched on or off, and it would be best to leave them active, since they will never output power or consume power unless there is a consumer connected to the output which has a buffer that is less than full.

It should be understood that many people can't understand concepts that are this complex, mostly due to the limitations of written language that is based on spoken language. So it may be best to wait until I release the library/API/whatever and a simple mod demonstrating its usage, and then try to understand how it works and what are the benefits of optimization and using producer/storage nodes as the network controller instead of some extra block which serves no function to the player except being a vulnerable central controller.

[Chiu ChunLing]

It will be great if you can do this without using exponentially more calculations than a simpler control system would.

[SegFault22]

I intend that the system will be efficient; if its efficiency is anything of or less than that of technic, people wouldn't be able to use it without having lots of lag for just a few players. It will have to run smoothly on systems that aren't fastest.

It is a misconception that the system I propose is more complicated, and not simple. It is actually more simple than the technic system, in implementation - but to explain it is not simple, as the concepts used in its creation are advanced, and many people would have trouble comprehending the implementation.