Friday Facts #209 - Optimisation is a way of life

[kovarex]

https://www.factorio.com/blog/post/fff-209

[Koub]

Optimisation is always nice
And those graphics *drool*

[noliVe]

always love your work Keep it up ;D

Those Stone path Looks cute.
thank you

[HammerPiano]

I like to optimize my time schedule so I always have time for the precious FFFs!

[sillyfly]

I have a bug report about the FFF - you've written "meda" instead of "made"

[ske]

You know how to cure an earworm? By an even bigger earworm.

[DjTeo]

I am the only one who think that this FFF is the forth year anniversary?

BTW nice stone path.

PS: you should go see a doctor about addictions

[Neemys]

Nice FFF as always, love to know how things are going.

For the logistic bots dillema. I don't think thats a good idea :

If you just change logistic and not construction bot, it will be weird to have two bots acting so differently (not interactable and invulnerable for one).

And having things that can move resource even over enemy base is not in line with other transportation mode. As bot always fly there will be no way for biter to stop bot from transporting as even destroying roboport won't stop them to transport. Belts and train can be destroyed. In some use case it can be use like an exploit even more in some modded game with big roboport that can cover enemy base.


I understand the need for optimization but there should be limit to it.

[Xterminator]

I too can not get enough of these optimizations! I love reading about them, and love playing with them even more.
The electric network and smoke improvements are really nice as those are two that I personally noticed getting a bit high as well.

In regards to the bots. I would say that making the the proposed change just for optimization would definitely be worth it. As you said in the FF, having it not apply to Construction Bots would be good because otherwise that would be too cheaty sense they are involved in combat and such. However, having Logistics Bots not be mined or be able to take damage would actually be an improvement even outside of the performance increase.
I really don't think it would be too cheaty or anything because it's not like it's giving the player any type of unfair advantage, it's just simply increasing game performance and getting rid of the announce of accidentally picking them out of the air as well.

I can imagine that the performance improvement from making the change would be pretty significant and welcomed by most people. I know I would certainly enjoy it!

[can00336]

With regards to the logistic bots dillema, Factorio is primarily a game about automation of a factory, not about combat. Changing the game rules to allow logistic bots to avoid attack and damage seems like a reasonable trade-off in exchange for additional UPS. I always thought it was weird that biters could bite my flying bots in the air anyways.

[DanGio]

Do it !

New pavement borders... Meh... But in the end I think I'll like it more than the *old* one.

These optimizationz ! Yayz !

[cpy]

Well how about allowing mods to use separate CPU thread to run? I'm sure that factorisimo running in 8 more threads itself with each of mini factory which is world itself would allow us to create insanely big worlds. But that would require some connection that connects those separated worlds.

[ske]

Couldn't you buffer electricity for a few ticks inside the consumers and only refresh a part of all entities each tick?

I would also very much like a few things about bots:

* Some kind of rate-limiting when bots leave the roboports. Currently they are still way overpowered (in my opinion).

* Make the bots stay inside the green area. Some simple cached pathfinding should do the trick. They may fly longer and less 'ideal' paths but in the end it will look better.

* Make the bots a bit smarter about recharging. Staying inside the green area sure helps with this. A bit more intelligent energy/distance-checking when crossing voronoi-borders should do the trick.

* Make the bots reconsider their decisions from time to time. A repair bot flying in from the other side of the map for 10 minutes while 10 others finished their work watch the building blow up isn't the most intelligent design. Same with logistcs bots that bring those 10 plates from "a storage unit far far away" while the local chest fills up to the brim in the meantime. It would suffice if each bot reconsiders their decision once each minute-or-so. That shouldn't be too hard to handle.

[Gergely]

Are you serious? I hope it is only in half finished state at the time this image was created, because it does not look good at all.

[Krizs]

@Bot dilemma

Since I love building mega factories with my friend and have been doing so ever since we found the game somewhere around v12.x it's always an issue that we aren't optimising factories for "gameplay efficiency" but UPS efficiency, so we can run our mega bases in multiplayer at a reasonable speed.

I believe since the game's core idea is not about combat but optimizing and evolving factories, that the logistic bot performance increase could only benefit the game as a whole, not hurt it, especially with the construction bots not getting this "combat buff".

Since for mega bases in my experience belts cap out way faster performance-wise and probably will never be as efficient as bots, making the bots have a better performance enables us mega base builders to push the boundaries even further, which I absolutely love in this game after 700+ hours in.

Cheers,
Krizs

[Mango]

That stone path is absolutely gorgeous. (don't listen to that guy above )

IMO being able to "mine" flying bot is unnecessary and annoying.
For the damaging part - I wouldn't mind if you made buildings repairable only when thay didn't take a hit for lets say 5s.
That would make construction bots start repairing them only after a wave of bugs is dead and therefore bots shouldnt get in contact with them.

It would also resolve the problem where if you have this:

[S] = bug spawn
[R] = roboport

[R]--[R]--[R]
|
[R]-----[S]
|
[R]--[R]--[R]

And your bots want to fly from one black Roboport to the other one they will get destroyed.
The only solution right now is to destroy every spawn that could interfere with your bots, even out network reach.

[ske]

Well how about allowing mods to use separate CPU thread to run? I'm sure that factorisimo running in 8 more threads itself with each of mini factory which is world itself would allow us to create insanely big worlds. But that would require some connection that connects those separated worlds.

I think that's essentially why the speed of light is a limiting factor in this universe. Through that one simple trick you achieve locality but lose globality. "The number of things at time x" or "The amount of power consumed at time x" or even "time x at different places" do not exist anymore after losing globality. Lag-hiding tries to compensate for that by creating an illusion that two people can actually play the same game at the same time. Wait.. i'm talking about thousands of cores with weak interconnects. Running 8 threads on the same CPU in parallel where each does some part of the work each tick is "no big problem". You still need to chop up the tasks but that's quite less hard.

[Syriusz]

Great stone path!
I do not think, that making bots invulnerable is good idea. The only thing that could make it look good is making hybrid version- they would not be entity when they are far away from enemies, but when they will be in f.e. 10 chunks away from enemy, real entity would be spawned in place of "quasi-bot". The problem is, that logic for checking if bot need to be real probably will make this useless... But you could check it not too often, then it may be valid option. And mods messing with speed and range of enemies or speed of bots could induce some weird behaviour.
What would help is more tiers of bots- the better the bots, the fewer you need. Or you could make "stack inserter" version of logistic bots- bots that are slow, need huge amount of energy, only move items to storage or to that new chest but move one stack of items at a time. And they could be hybrid, since slower would mean it could have more tics between checks. Something like this. It could be fun to come up with new ideas to make better factories with this.

[infogulch]

I've been thinking about smoke. Is there any reason why smoke needs to be ticked at all?

Just store a static list of smoke start location (x,y in chunk) and tick number that it was placed there (which could be as low as 4 bytes per entity). All the logic can be in the render function: smoke age = current tick - placement tick; location is a pure function of age, start location, and the current wind vector. All the cleanup you have to do during the tick is advance the head of the circular buffer to invalidate the old smoke (should only be a single int per chunk).

[quyxkh]

Pretty please do for carriages in trains what you did for items on belts? Given the train's lead-carriage position all the rest of the positions can be derived from chord lengths pdq, everything shares a speed and known path, and the pos/fuel/acceleration-calc data could be collected for the train and handled without needing to visit all the carriages individually every tick. I'd love it if long trains enroute were cheapcheapcheap regardless of length, there should be a reason to make long trains.