[WIP] Some useless calculations

[samogot]

No description provided.

[ghost]

democratic collaboration
Approved reviews will speed up the merge, request changes will slow it down.

Please review the PR to help.

[samogot]

in near future may be useful for handling carry size
in distant future may be useful for choosing best rooms for reservation

[samogot]

lack of visibility is a problem for real usage. caching possible paths on scout visit may solve it

[ghost]

Adding WIP label, the title is prefixed with [WIP]

[TooAngel]

I like this

[mschultheiss83]

me to, can we cherry pick?

[samogot]

feel free)

[TooAngel]

Would like to jump in here for some discussion about sourcer and carry optimization.
I tried to make the system independent on the distance to the base room. Especially when you have multiple external rooms, the carries should share the paths from different sources which influences the number of carries.

So looking only from the sourcer perspective, let's assume:
harvesting: 10 energy / tick
carry size: 1000

So check time is 100 ticks (carry size / harvesting) the sourcer fills up a carry.
If the container > 1000 (carry size) energy the sourcer calls a carry and waits 100 (check time ticks before checking again.
Shouldn't this make sure that the energy converges to 1000 energy?

harvesting can be calculated on the work parts of the creep.
carry size I think we should have fixed carry sizes per base RCL. This would give us the carry size here.

Maybe even adapt the check time dependant on the energy stack.

What do you think?

[samogot]

Shouldn't this make sure that the energy converges to 1000 energy?

In theory, it should. But what carry size should we take? If we take maximum available carry size per RCL, we would waste energy on spawning huge creeps, that would travelling underfull from near external rooms. On the other hand, if we spawn smaller carries, we would waste CPU time on handling huge ammount of them, on distant rooms, despite there could be less carries of bigger size.

Also it is hard for me to model influence of sharing the paths. I'm not sure it will have huge effect.

In my point of view, it would be better for each sourcer to call creeps of exact size and quantity, that is needed, depending on distance to base. Also in than case carries do not have to transfer energy to carries with different target. But I have no clue in which point of time sourcers should call such carries, and how to take into account if sourcer already have some stack of energy under himself.

[TooAngel]

Regarding carry size I would try to work with something like max size. For the described idea, I don't think it is important what size, it is more important to have a fixed size per RCL.

What prevents me from exact calculations is mostly the CPU limit, the dynamic world and the tick based. I would like to improve a bit more in the mentioned direction. I'm also fine with more sophisticated system, like the one you mentioned and started, maybe have a feature flag, so that we can test and compare.

[mschultheiss83]

• i like the idea of a 'config_brain_calculations.js' were we could extract heavy calculations and memorise them in some way.
• i think for the carries (non helpers) on RCL 8 are those 11M/11C/1W totally okay, they're not so CPU intensive, but effective.
• i did some measure on 'creep.handle': creeps roles cpu usage vs count of execution from highest to lowest scout (>3), carry (>0,4), sourcer (>0,4), harvester (>0,5)

i hope this helps to focus

BTW please if you adding console.log outputs change to console.log(Game.time, ) or if object specific use this.log on that object e.g. object.log();

[mschultheiss83]

me to, can we cherry pick?