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.
Hello,
GUI improvements often surprise us with just how impactful they can be, even for simple cases, they can really compound on the quality of life.
While playtesting, it was a little bit annoying having to remote view to the labs back on Nauvis, just to check if research is working. So we wanted to add a nice and convenient display of what is going on without having to completely break the players current gameplay context.
The graph shows the last 10 minutes of science production (FFF-408), and we di...
Read more
Hello,
It's time for those "tesla items" I mentioned in FFF 399.
On Fulgora you learn to control lightning, turning it from a threat into electricity. After learning to make more advanced electrical components and mastering the planet's Electromagnetic science pack you are ready for the next stages: Converting electricity back into lightning and unlocking the Tesla turret.
Mp4 playback not supported on your device.
Graphi...
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?)
Having the bots move once every 20 ticks looks interesting, but how does that work with robot-biter interaction? If a worm tries to kill a bot that flies overhead, it needs its current position updated at the speed of combat.
The construction robots (only kind of robots relevant to this), upate every single tick whenever enemies are around. This keeps the behaviour around enemies consistent, but keeps the performance boost when enemies are not around (which is usually almost always).
Hello,
We all love building bigger and bigger, but hitting the UPS ceiling really puts a damper on the mood.
Thats why we must continue our endless quest to optimize the game.
I've profiled many save files over the years of working on Factorio and frequently see saves where logistics and or construction robots are taking a lot of update time. That's nothing new, but along with robots come Roboports - in large numbers.
A typical factory with lots of roboports.
Roboports have never been "slow" but they're always present and people are encouraged to build a lot of them - even more in the upcoming Space Age where you want to do a lot remotely. After the most recent play-testing session, the resulting save once again showed them taking some small, but non-zero amount of time, and it got...
Read more
devtrackers.gg
