[MOD 0.16] Charge Transmission - Wireless Bot Charging

[eradicator]

(See below for full answer.)

old

[quote="Dustine"]Also don't take all my feet dragging as me refuting all you've been kindly suggesting and advising about, [/quote]
Coming back from weekend and this. Naarg. No. You're totally right about all those numbers. And my assumtion was the wrong way around with the maximum charge. I'll edit a full answer in here later when i'm more mentally awake. Just to let you know ;)

[eradicator]

Agh, I hate the quoting system.

I don't. Though better layout wouldn't hurt.

- Opus Magnum (well, Codex, it is only a level pack) were my late childhood and a big part on getting me interested on programming so no waiting for me. No regrets either, it's all I would have wanted and more so far. And nobody out the company knew they were working on it, it was announced on this Monday to be released on Thursday. It was a really good surprise!

I told a friend after you told me... and he already bought it. So technically i could play if i wanted ^_^. But i tend to play any game only "once" so if i play it now i'll do the first two chapters and never go back. So i'd rather wait until it's complete. Not in any hurry either. I've got so much stuff on my want-to-play/do/watch lists that there's no point in rushing into EA games .

- It's sparse because there's a lot of times I need to quickly find a node either by the roboport/cell it targets, or by the chargers it includes (altho that second part is me not trusting circular references). Easily solved with a separate index for the on_tick iterating and leaving global.nodes unit_number indexed still, bigger savefile size or not. (so yeah i'm changing this, thank you <3) Altho that "complex" math is one extra if and modulo, I forgot I simplified the math since 0.3 (it was... much worse back then), so it's not thaaaat bad.

I guess you're using the unit_number indexing for on_build/mined? I usually just iterate in those two events because they don't happen often enough to make me care. Though ofc building a local (not-saved) index for quicker lookup might be an option there. But that's hardly worth to change now unless you really care. It'd also mean annoying migration code for your existing player base anyway so...bleh. It's not on_tick -> /care.

- So it is 2 1 1 1 1, I wrongly assumed and didn't check it before accusing it of being clumping. Sorry.

There's also the potential case of "1 0 1 0 1 0 1 0" btw. But i haven't thought about a solution for that or if it's even worth it.

The limit issue
*snipsnap*

Duh. Yes. Obvious. I don't know how i got the idea that most bots were mostly empty. I'll blame it on sleep-deprevation and general stress. I'm sorry for the fuss caused and the smugness i probably radiated while saying that stuff. I'm kinda tempted to just "[stroke]" all of those above posts...but i'll keep them for the record i think.

Though lacking a "trivial" solution that leaves me/you?/us? on square one optimiation wise. So i think this requires to go about it a bit more strategically. So i have a few questions:

1) How much time do you even want to spend on optimizing this?
2) What level of optimization would be a good goal? I think 1ms is a bit much still. But would 0.5ms be ok? My most taxing mod uses 0.120 and i'm pretty annoyed about that (and it's not even calling any expensive API functions).
3) What use-case would the optimization be for. Megafactory? Normal factory?
4) Do you have a dedicated "testing" map or is that just your normal factory? (and is it available for me to compare my potato against yours)
5) Does using limit actually provide significant performance boots? Try artifically limiting the scan down to 50 in your 20k bots factory and test how much of a performance impact that actually has. (Yes, i know, doing that breaks functionality. This is just for performance data). So we can determine what part of the code is actually eating up the most resources.
6) What is the target use case? (I.e. is it really nessecary to charge bots that could just as well charge off the roboport directly when there's enough charge ports available.)

The thing is, as far as i know currently your chargers just charge every bot in range (what exact range is that btw, 50?). From a lore perspective that might be ok (real-life wireless charging style), but factorio API and factorio lore usually charge by numbers (i.e. roboports have 4 slots). So if significant performance improvements are desirable for megafactories it's probably nessecary to impose some limits on the chargers. I can think of the following possibilities:

1. Reduce the frequency of the scans. (Requires statistics about average flight times etc pp. The goal would be to charge the robots later in their use cycle. (i.e. wait until they're 50% discharged instead of 5% because codewise this costs the same to recharge)
2. Enforce an artificial limit on the maximum number of bots chargable (Limits the API call cost but relies on surface_find_entities with limit= to return a random selection of bots for good charge distribution)
3. Severely limit the range of the chargers. (Reduce number of possible bots while still charging all of them in range. Requires more precise placement of chargers on hotspots).

Some of those methods (regrettably) can be solved by the player simply spamming more charging stations. Which then completely negates the performance increase. But as long as you're trying to charge 10k+ bots you're bound to have some pretty expensive stuff D:

The most "promising" method i can think of is to change the chargers paradigm to boost the charging function of an existing roboport using charging_robots and to_charge_robots. This way you don't have to do any find_entity calls at all anymore but you can only charge robots that are already queued up for charging. This also implies that you don't have to handle those 90% of robots that still have enough energy though so it has the potential to be pretty fast. But it also means it doesn't prevent robots from flying a detour to charge at a port (unless robots are added to that table way before they reach the roboport - which i don't know).

[dewitpj]

Hi,

Any plans to update to 0.16 ?

Thanks !

[Dustine]

Hi,

Any plans to update to 0.16 ?

Thanks !

I already replied on my github but to repeat it here: I was hoping the mod rewrite would be done by now (life... got in the way), but as it hasn't I'll do a quick port of it, if not tonight, by tomorrow the latest.

In short, yes but I was hoping it'd be 1.0 (it won't) hence the delay.

[dewitpj]

In a twist of faith I posted here first

Thanks anyways !

[dewitpj]

Oh - not sure if you can fix this one, but the version on the mod portal is 0.3.3 (?) while 0.4.4 is out ?

[Dustine]

In a twist of faith I posted here first

Thanks anyways !

Hah, hadn't noticed it! I don't think I got a notification for your post, only the github issue (which is why I responded faster to that one).

Oh - not sure if you can fix this one, but the version on the mod portal is 0.3.3 (?) while 0.4.4 is out ?

Huh. I'll see what I can do, probably will fix itself once I do push 0.16 (and good news, it was a rather painless update so I'm getting ready to upload it!)

[dewitpj]

Thank you !

(Can't wait!!!)

[dewitpj]

BTW - I can confirm that the mod portal is now showing 0.5.0 - thank you !

[Dustine]

Third try's the charm.

[Dustine]

0.6.0 is out! Finally finished that major rewrite I've been promising for... uh, months.

Not only is it more UPS-friendly, I added a few settings to further customize it if it isn't too stable on your own savegame.

And that's not it, I did sneak in a few extra features, like a much-wanted reason to use efficiency modules... Yes.

[eradicator]

Grats!
Kinda interested in what solution you lastly went with but no time to read large amount of code currently . Maybe later...

[Dustine]

Grats!
Kinda interested in what solution you lastly went with but no time to read large amount of code currently . Maybe later...

Remember when I said I couldn't use the to_be_charged table because I couldn't find a way to make the robots give up on charging after topping them off? Or at least a way that wasn't UPS intensive (replacing them with a copy)?

I found one in spite of a fixed bug (which is why the minimal version atm is 0.15.13) that should stick around because of game mechanics. Changing a robot's force, even to the one they already have, resets their charging drive, as bots can't charge in roboports of other forces, even friendly ones, and I don't see this changing any time soon. If it does I'll do a feature request for some other way >u>. The rest was finding a configurable way to scan that table often enough that bots don't drift towards the standard charging without hurting performance.

[eradicator]

That sounds like quite a neat hack :3. It sounds a bit strange though that they remember their current job even after "changing" force. Or maybe it's because they don't actually change that it still works. Did you try any similar methods (micro-optimization!) like teleporting the bots to their current position, or not rotating it, or active=true :D, so many possibilities. Active suonds like the only one where you don't have to transfer any objects (force, position, etc) from c to lua, hm...but i guess only if one assumes the robot is actually active. No..stop...brain. You did a good job. You deserve a break :P

[Dustine]

That sounds like quite a neat hack :3. It sounds a bit strange though that they remember their current job even after "changing" force. Or maybe it's because they don't actually change that it still works. Did you try any similar methods (micro-optimization!) like teleporting the bots to their current position, or not rotating it, or active=true , so many possibilities. Active suonds like the only one where you don't have to transfer any objects (force, position, etc) from c to lua, hm...but i guess only if one assumes the robot is actually active. No..stop...brain. You did a good job. You deserve a break

Teleport does nothing, they still fly to the roboport they were initially going to, even if it's now several miles away. Can't teleport entities (but players) between surfaces too, so no luck there. Active toggling, even over several ticks (deactivate one tick, activate the next), also didn't do anything. Rotating, uh, never tried but I'm assuming it doesn't work. The only thing I didn't try off the top of my head is to see if update_connections() did anything or not, and that's because I found out right then that changing forces *did* something, which was progress compared to everything else not stopping the charging march ^^"

Edit: Oh, and they don't remember their task when swapping forces. When I tested out if making a bot copy worked, the logistic network reassigned the task to the clone without a hitch. So I assume it's the same mechanic happening here!

[eradicator]

Edit: Oh, and they don't remember their task when swapping forces. When I tested out if making a bot copy worked, the logistic network reassigned the task to the clone without a hitch. So I assume it's the same mechanic happening here!

If they don't remember their task doesn't that make the wireless charging kinda meh again? As another bot then needs to be assigned and fly the whole way again. And cloning sounds expensive again D:. (No actual time to test anything *sigh*)

[Dustine]

Edit: Oh, and they don't remember their task when swapping forces. When I tested out if making a bot copy worked, the logistic network reassigned the task to the clone without a hitch. So I assume it's the same mechanic happening here!

If they don't remember their task doesn't that make the wireless charging kinda meh again? As another bot then needs to be assigned and fly the whole way again. And cloning sounds expensive again D:. (No actual time to test anything *sigh*)

No no, you misunderstood me. The network reassigns the now-vacant job to the "new" robot, which is right where it was before it got charged so it just continues like nothing happened, it doesn't dispatch one bot from storage (I checked). And cloning was expensive, still less than 0.5 if I did it right, but then I found a better way :3

[Dustine]

Updated the main thread post, wow those pictures were ancient. I kept it more succinct than the mod page (didn't even mention how to re-target chargers), hopefully that's good enough.

Now, on future plans:

• Add an user option to disable the overtaxed icon from showing up on their map and as a flashing custom alert
• Keep optimizing whenever you can
• Add support for other mods placing chargers, based around script_created/destroyed_entity
• Factorio-like graphics for chargers. Want me that rust
• Player bot chargers? Not sold on it...
• In-game tutorial, I feel chargers are complex enough that they may demand it

Taking this long list tho, I still consider Charge Transmission essentially feature complete (the player tidbit would slot nicely with the code I already have, for the most part), so I moved it to beta and the next major release will be 1.0.0.

[LION42]

Hi
i'm a bit sad how you changed this mod from 0.15 to 0.16
while the chargers reloaded gradually on 0.15 they now reload extremly fast and cause electricity demand spikes.
The second bigger issue i have is that bots which have to fly a bigger distance, like 2-4 roboports and get somewhere along the way recharged seem to "forget" where they were going, turn arround and put the item i the next logostics chest.

[Squish8294]

Any hope of an update for 0.17?