[FFF #209] Suggestion on Logistic Bot dilemma

[Ragnaman]

Was reading The logistic bots dilemma:
"The dilemma is, whether changing the game rules like this just for optimisation isn't going too far."

Suggestion:
Implement a next tier of logistic tech.
Logistic entity akin to nanite swarm OR mass -> energy -> mass conversion.

Simple implementation:
Similar to Logistic Bot, you have a nanite swarm that transfers items (or deconstructs and reassebles them in destination, use imagination). This would allow to achieve this goal mentioned in FFF:
"The dilemma is, whether to use similar approach to the logistic bots as for the smoke. This would mean that logistic bots would be created/updated/removed very fast and their memory footprint would decrease a lot, but they wouldn't be regular entities any more. They couldn't be mined (which could be for the better actually), couldn't be attacked or damaged by anything".

Complex Implementation:
The item conversion from mass -> energy -> mass is achieved by spending a different kind of energy resource.
Think of it like energy supply/demand, but of different kind of flavour. Every single item transferred would drain some "power".
(this might kill 2 birds with one stone, as power is spent directly with transfer of item - no need to recharge "logistic bots" or make calculations whether they need recharge).

Final Result
Game progression does not change, people still use Logistic and Construction bots as they did.
However, for ultra late game and megafactory stage, this would help performance.

Problem
People would abandon trains if "nanite swarm" or "mass->energy->mass" conversion would be more efficient over long distances and bulk transfers.
(potential solution is logical - similar to Real Life radio signals, the longer the distance is the more powerful the emitter must be and more power must be spent. Logarithmically this could lead to trains being viable because of huge power consumption problems otherwise)


Sorry for the chaotic writeup, i just needed to share this thought. This concept can be morphed into whatever you guys like, I hope it just helps for some brainstorming.

snip from IRC

"
.:Ragnaman:. I was reading FFF, about The logistic bots dilemma. "The dilemma is, whether changing the game rules like this just for optimisation isn't going too far."
.:Ragnaman:. What if there would be another type of "logistic bot"
.:Ragnaman:. next tier of tech
.:Ragnaman:. some sort of "nano swarm"
.:Ragnaman:. similar to logistic bots, but transfer of items would happen near instantly, spending energy for the mass -> energy -> mass conversion
.:Ragnaman:. this way you could have entity that "does not exist", and spends very small processing time
.:Ragnaman:. uses same logistic network, and is sort of like another electric network
.:Ragnaman:. you manufacture not power supply, but nanite supply, which would be consumed for every item transfer.
"

[Zavian]

Personally I would rather see more research for larger robot carrying capacities. Larger carrying carry capacity means you need less bots for the same workload. In order to keep it balanced, it would probably need to get very expensive very quickly, so maybe worker robot carrying capacity 4 would be 750 of all six sciences (including space, but excluding military), then double for each additional level.

[TheRaph]

There may also be a solution in program code. I think in a way, that they may create an invisible entity every time a bot will be created. Then they create a visible instance like smoke as described in FFF and link them together (e.g. pointer). As long the bots are swarming around they behave like smoke. But if such a smoky bot will come in the near of player or enemy it will turn in to the entity it's linked to. There should be a hysteresis for that, protecting the bots from switching to often between "smoke" and entity.
On the other hand "bigger bots" ore researches for "carry more" sounds very nice and would be a nice feature.

[nljr]

But if such a smoky bot will come in the near of player or enemy it will turn in to the entity it's linked to.

A lot of folks suggested various dual-mode solutions like this. It sounds nice, but any time you have the same thing implemented two different ways, it's more than double the maintenance load for development.

[JohnyDL]

how about simply invisible bots research it does nothing but hides base bots from view if they're not in low power mode/biter view reducing GPU load and allowing shortcuts on their movement like

Decide destination
Calculate distance
Jump distance to recharge warning point/destination/in range of biters and use a timer to make it none instant
(one way might be to have a list array with n locations and each tick it loads all the bots stored in 0th place, and removes 0 from the list making 1 the new 0; adding bots to the array list for when they're supposed to reappear to the nearest tick. If a bot can go 10 seconds flying without recharge it could reduce the amount of bot processing by 90%+ since in any given tick you're only processing a small fraction of the total bots in the air with the rest queued up for future ticks)
do normal recharge algorithm/deposit items algorithm/continue traveling while under threat
repeat