Sixty Four

Sixty Four

View Stats:
I swear there's some random offset for some machines
Something that makes them randomly take longer or shorter to do their thing.
I have a setup of 8 Celestial Radiators around a single Catalytic Preheater. The radiators are serviced by Industrial Undergound Silos, exactly two Radiators per Silo. The setup is entirely idle to start. Fill the preheater, then fill each of the silos. This runs perfectly well for the duration of the silo's fill. Then it gets weird. The last silo to be filled is the one that finishes first. Even stranger, it finishes several cycles before the other three. Then two others finish, still several cycles before the remaining silo.

Additionally, it seems that if you have multiple identical machines around a single silo, they slowly drift out of sync, and by the end of even the 8 slot silo, they won't all have gone through 8 cycles, despite supposedly taking the same amount of time each.
< >
Showing 1-5 of 5 comments
M@D HAtT€R Mar 29, 2024 @ 11:23pm 
I would assume some in-code reason for this.

Ignoring multi-threading for now, the easiest solution would be to put all "pending refill tasks" into some collection or array of sorts and to let them be resolved in a serial manner. Also meaning, that they are not resolved exactly at the same time.
Until multi core CPUs arrived truely concurrent processes did not really exist and were just an illusion anyway.
You would have to figure out how the programmer solved this, to make any predictions on when happens what.

Should the tasks/silos be organized in a collection with no fixed order, this would introduce another level of randmomness.

Should there be multiple threads processing this, then you can forget about making any predictions anyway.

Do you have a specific idea in mind on how it could be used, or just curriosity?
M@D HAtT€R Mar 29, 2024 @ 11:46pm 
Out of curiosity on my end - does this perform better or worse than the setup you can find in screenshots? I copied and used the following setup to reach red-blue:
R | R | R | R | R | R
R | P | P | P | P | R
- | S | I | I | S | -
R | P | P | P | P | R
R | R | R | R | R | R
... repeat

R - Some random converter
P - Preheater
S - Silo
I - Irradiator

It worked fine, but I wonder whether your idea is actually faster, as none of the repeaters in that setup are actually maxed.
Man's Best Friend Mar 30, 2024 @ 6:34am 
One way to handle the issue would be how Doom did it. Internally the game runs at a target tick rate. At the beginning of a tick, all active entities are polled and put into a queue for processing. The queue is processed in a serial manner, and once it's all done the game either immediately proceeds to the next tick if processing took too long, or waits until the next tick to ensure a maximum frame rate. In this manner fancy multithreading is not needed, but entities that should in theory run in sync with each other continue to do so. Though any buildings with overlapping service zones would depend on queue order for who gets to do something. Such as the case where a single machine is serviced by multiple silos. The two silos would compete, and potentially both get used over time before either one empties entirely. However, multiple machines all serviced by a single silo would run in sync the whole time, assuming they are all the same machine, and all started in the same state.

That said, even Doom did have a random offset for many things specifically to eliminate entities running in sync because having a whole bunch of enemies doing their idle animations in sync would just look silly. Though their tick rate was a mere 35/sec.

As for if my setup is more or less efficient than anything else, I couldn't say. I'm winging the whole thing, and haven't even built the Inverse Chasm.
M@D HAtT€R Mar 30, 2024 @ 8:47am 
Factorio solved all that by abstraction too - multithreading is not that fancy, but poses the issue of synchronization - not that much of a problem, but simply one place more where the whole thing could theoretically fail (deadlocks etc.). I have no idea how 64 works, I don´t even know the language it has been written in (engine used?). But let´s be honest here... it is a fancy cookie clicker, the developer themselves jokes about that in the end. I suppose I would have taken the easy way out in their place ^,^ - it runs fine for what it does and for the intended scale.

Would love to see how it would perform with the ammount of machines and scale, that can be seen in factorio, though.
M@D HAtT€R Mar 30, 2024 @ 9:10am 
Would actually love to see that, now that I think about it... would pay for an expansion!
< >
Showing 1-5 of 5 comments
Per page: 1530 50