I like it. It would make it easier to eyeball which ones are missing. Especially if they left spaces in between for packs that are missing.
Whish is exactly how we did it. (and why)
Big Brother Kovarex is always watching lol
the packs are now drawn in a way, that the position of each pack is unaffected by other packs being filled or not.
This means, that when you miss a one science pack in the lab, you will see a hole in the icon list.
Oh cool. Is this (map previews) something that will be available via mod API as well? Could imagine some mods wanting to make use of it.
The Camera widget is already available for mods
Wonder if I'll be able to pin my diff spidertron squads so I can easily check in and make any necessary adjustments without having to remember where I had them lol that'd be handy for all my construction spiders.
Yes!
That's confusing, as the tooltip says "science production". Research productivity is applied at science pack consumption. Either you are mistaken, or the tooltip needs to be clarified.
I don't see a problem. This is the final addition to the progress of the research measured. The same way as producing of electronic circuits is measured with all the productivity included.
Camera previews for map pings seem like they could also be useful.
Ah, I forgot to mention that in the FFF, we have that too!
The big question is whether the research info tooltip shows SPM or eSPM. But a nice addition nonetheless
It shows the effective SPM, with all the productivity included.
Finding out kovarex is a dwarfer is almost more interesting than a new enemy design.
Being dwarfer and being czech are sets with very very large intersection :)
The achievement name for finishing the game is a Red Dwarf quote - from Ace Rimmer
Correct.
Read moreMy idea is for the electric update to calculate the satisfaction percent based on the energy demanded for the shared buffer and save that in a new field on the energy buffer. If you have a merged buffer of 100J and 50J is consumed but only 30J is available to refill the buffer then the satisfaction is 60% (30J/50J) even though the buffer would be 80% full. During the entity update each entity would key off the percent satisfied field on the energy buffer instead of the energy available in the buffer.
This results in behavior almost identical to current behavior even in low power states. The one way this changes behavior slightly is in a low power state where an entity goes from idle to active. Currently the entity will operate at 100% speed for 1 tick because its buffer is full at first before reaching the equilibrium speed based on how low the power is. With this idea the newly active entity would operate at the speed of the current satisfaction equilibrium but if you simu...
Can you code in C++? If you want to work for us and program this (or something else), you can be my guest, and I will not require you to go through the testing process. (This is my reaction of your analysis which was exactly what went through my head thinking about it)
Isn't this already done for accumulators?
When they are placed or changed, they are separate until their energy level syncs up with the rest of the accumulators, and are then computed as a single entity.
Yes, but the difference is, that they can be used together, without any change in behaviour. Consumption machines can use different levels of energy based on activity (one fully beaconed assembler uses way more than assembler full of efficiency modules for example). So the problem with entities is little bit more complex, but solvable.
As the game engines stands now, is it better to have more smaller rail blocks (signals closer on straight sections) or fewer larger blocks, assuming we don't make such a drastic change that the distance between trains going the same way changes?
For performance, it is always best to have as few blocks as possible, as blocks (parts of blocks actually, as junctions split it even more), are the steps the pathfindiner is using to find the goal.
This is because of simplification, the pathfinder is using the already existing block structure for itself. But it would be reasonable to build special data-structure for pathfinding, where only junction points would divide individual steps, which would greatly reduce the comlexity of the search in real-life scenarios.
Good read. I still think the electric network update could be changed to having one electric buffer per entity type (eg all fast inserters on one network share the same buffer and all the stack inserters share a different buffer, etc) reducing the number of buffers to update from the number of electric entities to the number of entity types for each network. This would improve both the electric update obviously but should also help the entity update by significantly reducing cache misses for fetching the entity's electric buffer because the buffers are shared.
I believe I have a way to incorporate all electric network mechanics except drain but there are several ways to make something like drain depending on what the intended gameplay purpose is.
Wait a second ....
...
My brain is trying to figure out the reason why it can't work.
Eh? Derp?
Obviously, it would change the behaviour in some ways, but maybe not in ways that would matter. It might be weird for some bigger entities like roboports, which can charge up and discharge. So a lot of roboports in a big network sharing their buffer would mean it takes much longer to run out of energy completely, but maybe it doesn't really matter that much.
For small buffer entities like inserters, assemblers or laser turrets, they have buffers, but just for technical reasons, and we want them to slow down or shut down in a coordinated way when there is not enough electricity anyway, so a shared buffer wouldn't matter.
This would be a problem once we want to independtly update entities at the same time, but in this case, the buffers could still be split based on the group in which the entities would be updated.
And as you suggested...
Read moreRead moreI have a save file that i quit a while ago because of performance. I was about 900 hours in with 39% of research done. I wanted to complete a PY run with every intermediate having a train station but with only the base game, no LTN or Cybersyn
Some spec:
Trains: 1130
Train station: 5372
UPS: between 24-26
My train take 2/3 of the update time
But 95% of those repath are not required. The train go in a straight line and wont encounter a fork until about 300-400 tile later. It should be scheduled for a repath. But the repath should not happen until he really need to figure out were he want to go for an optimal path… a fork
There is still quite a big reserve when it comes to both train movement and repathing, it just wasn't usually that much time consuming in our saves, but with the additional improvements, it is just a question of time before it does. Can you post a link to the save (or the forum with the save?)
devtrackers.gg
