Factorio Forums

• 1 beacon
• 2x radars
• 10x processing units
• 20x batteries

• Mike C for the concept and not giving up on it
• desseb for being key on the brainstorming and playtesting
• Nexela for general code help and workarounds
• KatherineOfSkies for her friendly and welcoming community

• Adding a power armour version of the bot charger (personal bots still charge if they are in range of a fixed charger, but a portable one could be tasty...)
• Speed and processing optimisations
• Better model and component icons

mraider94 wrote:Nice gonna have to try this out. Had nearly this exact idea 9 months ago over on reddit.
https://www.reddit.com/r/factorio/comme ... echargers/

Infinity-Simplex wrote:Hi Dustine & community, thanks for this great and elaborated mod. In particular, thanks that it is so small! Great for people with slow internet connections. Some config-only-mods can be huge, but yours is just right.

However, with that large of a charging area, to me, the transmitter feels pretty overpowered (pun not intended... maybe ._. *cough*). Are there plans for an "independent" charger with a smaller charging area? Something like 7x7 tiles? That would feel a lot lees unfair, since it would mimic the beacon's limited range a (and that of inductive charging in general) slightly better. Such a charger would be restricted to predetermined locations with high robot traffic, like robot-operated train stations or heavily frequented roboports.

As an added, luxurious bonus, maybe you could (optionally) scale wasted energy with robot speed, or speed research? Thereby, the speed research would factor quadratically into power consumption. This would make for a great deterrent against transporting every small item with bots. (In-lore, it might just be harder to target bots the faster they move... ) I have some multiplayer colleagues who connect their ultra-compact factory set-ups to trains via robots, and robots only, and therefore spam their train stops with roboports for recharging. This kind of breaks the purpose of clever planning. Your non-blocking chargers seem like the perfect solution, but they also seem too easy and forgiving, planning- and energy-wise. But they're great for non-competitive single player set-ups.

Thanks for this great mod, and keep up the good work.

Dustine wrote: Oh wow, this made my day today! I've been... busy with my meatshell being horrible to code anything, so I'm still glad to see this getting use even after long on me adding well-needed updates to it.

Dustine wrote: The small size is actually incidental (and could be smaller if i removed some unnecessary libraries from it) because it doesn't have a lot of custom graphics, and the biggest one is reused from the main game (the animated antennae). I do want to have better graphics in the future but i'll be more conscious of the final mod size as that is a good feature to have!

Yes, it is overpowered, if not for ease. Initial plans were to make it basically a retextured beacon (including the beacon area) but the current system made both the coding and user usability of it a lot simpler. Like, if you make the area too small you end up needing to carpet the world with them to have any effect (i mean, you wouldn't but i know people would want to!), altho you lose some of the strategy regarding it, true (placing in critical spots vs plopping it on planned constructions). Having a intermediary tier could serve a purpose (and probably even be cpu-friendlier! huh.) but I'd need to balance and code it first. I already had a few ideas for to expand the mod (charge players!) but i'm not that excited about them so i was thinking on focusing on 1.0 first. I do like what you suggested a lot, i just can't promise it any time soon if i end up adding it, sorry.

Dustine wrote: And a quadratic increase in power versus linear? Honestly, if not for the energy cap (necessary code-wise, sadly. unless i did add the small-range chargers...) i would adore to do that ewe i do want to make them more expensive power-wise and that's a delightfully evil idea!

Thank you so much, will do so!

piterek2003 wrote:Hey,

Awesome idea for the mod. I instantly wanted to use it, cause I thought:
1. More "air-time" = less bots needed = more UPS.
2. Charging stations are 2/2 in size and can be placed in so much better spots, therefore minimizing distance between train and assemblers. Again more UPS!

So I gave it go and in reality it's a...UPS killer :/ After placing only around 20 chargers my UPS dropped significantly. Any chance of optimizing it?

eradicator wrote:I've had a look at your on_tick function, it's a lot longer than what i would have expected for a mod like this. Especially you seem to be doing node maintenance, which is guess is related to the charging cells? If my interpretation of that is right don't really see a reason to do that in on_tick instead of using on_built/on_mined type events. While i kinda expected this to be a simple:
Loop through chargers -> find bots in chargers range -> chargs some bots until charger is depleted.

By the way what kind of target bot count do you have for this? Large factories can easily have several thousand bots which makes it not uncommon for one or two thousand bots to be in the same logistic cell. Especially with train stations.

Also btw i saw your interface request for reading beacon data directly (the main reason i came here ). And i was wondering why you need to iterate through beacon data so often that it becomes a performance hit?

Dustine wrote:

piterek2003 wrote:Hey,

Awesome idea for the mod. I instantly wanted to use it, cause I thought:
1. More "air-time" = less bots needed = more UPS.
2. Charging stations are 2/2 in size and can be placed in so much better spots, therefore minimizing distance between train and assemblers. Again more UPS!

So I gave it go and in reality it's a...UPS killer :/ After placing only around 20 chargers my UPS dropped significantly. Any chance of optimizing it?

Weird, I never got notified of this post, sorry for the delay!

On the UPS weight... yep, I'm optimising it (and 0.5 should be even better on that regard, even with the new features I'm adding). The mod is on alpha, so I'm trimming UPS from its main cycle every new release in one way or another, and will only call it 1.0 once I'm sure I can't squeeze more performance off it. That and my mod dev computer isn't... the best, so I usually do catch it when I make a mistake or two and it gets a lot heavier.

That said, 20 chargers (specially if they're around the same spot) shouldn't lag the game this much, even if by your description you hadn't connected them to anything. Do you still have the savegame where this happened?

piterek2003 wrote:

Dustine wrote:

piterek2003 wrote:Hey,

Awesome idea for the mod. I instantly wanted to use it, cause I thought:
1. More "air-time" = less bots needed = more UPS.
2. Charging stations are 2/2 in size and can be placed in so much better spots, therefore minimizing distance between train and assemblers. Again more UPS!

So I gave it go and in reality it's a...UPS killer :/ After placing only around 20 chargers my UPS dropped significantly. Any chance of optimizing it?

Weird, I never got notified of this post, sorry for the delay!

On the UPS weight... yep, I'm optimising it (and 0.5 should be even better on that regard, even with the new features I'm adding). The mod is on alpha, so I'm trimming UPS from its main cycle every new release in one way or another, and will only call it 1.0 once I'm sure I can't squeeze more performance off it. That and my mod dev computer isn't... the best, so I usually do catch it when I make a mistake or two and it gets a lot heavier.

That said, 20 chargers (specially if they're around the same spot) shouldn't lag the game this much, even if by your description you hadn't connected them to anything. Do you still have the savegame where this happened?

I'm happy to provide the save game (https://drive.google.com/file/d/0B8h8O2 ... sp=sharing), but keep in mind I use quite a few mods, some of which are needed to run the save (advanced nuclear, roboport recharge upgrade, robot batter research, ups-up). It's a mega base that has just dropped to 57 UPS (but I'll fix it soon, rebuilding atm ). Try putting chargers in the biggest bot networks (that need to be reworked by me ), namely train stations PGB Science or Wheels Monster.

eradicator wrote:Ah. So the chargers are beacons now instead of EEI? (sorry, i didn't really read ALL of your code, just some bits ). As neither beacon efficiency nor module effects change during runtime this sounds like a good place to add some caching or even memoization. If that doesn't help enough then imho just reducing the frequency of the check is a good option. Realistically module configuration isn't going to change very often. (I have at least one slow-update cycle on one of my modded entities which i just explain to the player lorewise in the tooltip to get away with it. So they don't go "wtf" when updating isn't instant). Though if the impact of that is only 0.005ms then i'd probably aim to optimize the other parts as good as i can before that. What's the minimum time your mod takes with 100 chargers if there's no bots at all?

So if you're grouping chargers onto roboports does that mean that the list you're iterating over is basically an ordered list of roboports_with_charger and you're calling find_entities_filtered exactly once per roboport? If yes than i guess that's as low as you can get on the number of function calls there. So let's move on to the next: I noticed you had some "odd" distinction between logistic and construction bots which i didn't quite get. Is the charging range different for those two bot types? Because if it's just a way to determine maximum charge that's another thing that can be cached by bot type.

As to why you're causing desyncs with something as common as adding things to a table i'm not sure what you're doing there . Is the table not global maybe?

Regarding spreading of calculations i recommend you read my post on another thread.

Also looking at the documentation i noticed that find_entities_filtered supports a limit= parameter to reduce the number of entities returned. As this is probably the most important call in your on_tick i recommend you have a closer look there. The idea would be to estimate based on available charger energy how many bots you can at maximum charge, and then limit it down to that many.

Dustine wrote:Ah, no, the EEI stays because I do want something with a variable energy usage (prettier energy graphs! without that much of a performance hit, i though?), but I suppose there are ways around that.

Dustine wrote: As of right now, 100 chargers without bots, on the same node, reaches 0.078~0.120ms on my machine (normal graphics, small test world). I can't tell if the fluctuations are from the mod or my computer because all mods running alongside (creative-mode specially) get the same ups spikes in the same intervals.

Dustine wrote: And true, true, I hadn't thought to cache module efficiency as I already do for bot's maximum energy (and other stats, should the need arise). I had planned to cache the module efficiency result at least but that should also be a good step, specially as I only care for one kind of module (efficiency) on chargers. So, thank you so much <3. Come 0.16 that won't be an issue anymore~

Dustine wrote: And you're right, it's better to aim elsewhere if there are bigger issues but I also like trimming off the easy parts too now than to never do them, delaying them over and over while chasing the miliseconds elsewhere. That and it avoids programming burnout from my part, having more than one task to focus on.

Dustine wrote: Yes, that's almost right. Chargers are grouped around roboports (nodes), and find_entities_filtered is called twice (i'll go over on why twice later, it's something i wish i didn't have to do) so to iterate over all the bots, of that force, in the considerable target area, and then assigned energy consumption as a batch. Now, I have to run the scan twice because find_entities_filtered only accept, as far as I know, as a filter one entity type at a time. And construction and logistic bots have different types, they're not both "robot". I already cache a robot's max energy on a game's start-up, all I'd need to do is cache it per force and update it every 30 seconds or so (?) because of some force-modifiers that directly touch robot battery size now. Just a simple multiplication.

Dustine wrote: On what's causing desyncs... I wish I knew! The table I'm referring to is on global (global.nodes), and it's iterated with next(...) inside on_tick over several ticks. I've read online that adding elements to a table while using next() is unadvised (removing is fine) but I've also read that in Factorio that'd be fine because of determinism. So, I didn't mind at first. And then the desync reports started coming. And then I did the blind leap of making a separate global table for newly created nodes and only add them to global.nodes before starting next() iteration (when the iterating index is equal to nil). Tested on the desync maps, no more desync, and never got any more reports from people using the mod on multiplayer. It could be a coincidence, heck it probably is, but the overview it adds seems to be minimal.

Dustine wrote: I haven't read the link you've sent me YET (wanted to write this... really big reply, whoops, first. wish i had pictures to cut it too) but the biggest issue with spreading calculations, as I've tried before, is that any mechanism that saves the bots for later causes a lot more ups consumption than not. Could be me doing anything wrong, I'm open for suggestions or anything that does work gladly so thank you for the stuff, I'll check it once I'm done writing this. I've had the idea of making smaller scans over an area and spread that over time, but unsure on how to implement it.

Dustine wrote: Oooh, didn't know of limit. I feel the math wouldn't be as easy as it seems at a first glance (how do you predict how X of energy you'll need when spread over several robots with different battery sizes (as in, how much of X to each type?), without doing a count_entities_filtered that while lighter on ups is still an extra weight on the critical code path) but that is DEFINITELY something I need to investigate and play with. Specially as I either already have or plan to have all the necessary variables cached or known before the scan!

eradicator wrote:That doesn't sound too bad at least @120ms. That every mod gets the same spikes is obvious. Far too many people use if game.tick % 60 == 0, so everybody does their heavy calcuations on the exact same tick. The post linked above (that you should've read by now ) mentions this and how to fix it.

local next_node = next(nodes)

local iter = 0
local count = table_size(nodes)
local max

-- Damage control, does ALL remaining nodes in the end until you nil
if event.tick%60 == 59 then max = math.huge 
elseif event.tick%60 < count%60 then max = math.ceil(count/60) 
else max = math.floor(count/60) end

while next_node and iter < max do
  local node = nodes[next_node]
  iter = iter + 1
  -- (...)
  next_node = next(nodes, next_node)
end

eradicator wrote:Yea. Can only do one type per call. But the really expensive part is the number of objects returned (thus limit) not the number of calls. So it wouldn't be much cheaper even if you could batch them. Yea, every 30s should be fine. It's just reading number in a table after all. That way you're safe if any mod ever should increase it without triggering it by technology.

eradicator wrote: Trivial. Suppose you have two bot types, and a node that has 100 energy available:
botA, max_charge = 10
botB, max_charge = 20
So now take smallest max_charge, which is 10. Devide 100 by 10 -> You now know that you can at most charge 10 bots before running out of energy, so you can limit entities_filtered to 10. This would be just to limit the impact of getting back 2000 bots when you can only charge a small amount of them in megafactories. In normal factories it probably won't have a very large impact.

Dustine wrote:So I won't be able to do anything code-wise or anything today because Opus Magnum came out and I already lost several hours to it. Many more to come, I'm sure.

Dustine wrote:Only global.nodes is a sparse list so stuff is done a "biiiit" differently.

Dustine wrote: The following code, which is inside on_tick, around line 400 or so of control.lua, was changed so it makes more sense out of its context but the logic is the same:
*snip code snap*
The math is a bit... confusing (took me an afternoon of fumbling around and testing to make sure it worked as I wanted) but what it does is it spreads out all nodes over 60 ticks as evenly as possible, as just using math.ceil(count/60) as the max would clump up most nodes at the start if the number of nodes is close to a multiple of 60.

An example of what I mean by clumping, imagine if you have to iterate 6 nodes over 5 ticks. If you used math.ceil(...) as your max you'd get 2-2-2-0-0, while this method would give you 2-1-1-1-1. If that makes sense.

for i = 1 + offset, #my_table_of_entities do stuff() end

Dustine wrote: Also I wasn't clear on the fluctuations, they're more that every few seconds every mod gets twice as heavy ups-wise, stays that way for a few seconds more and finally it slowly dwindles to the previous ups usage. This all over twenty seconds or so. It's a rolling kind of lag, I'm unsure if %0 is to blame here!

Dustine wrote: Yeah but you'd be giving priority to botA, wouldn't you? Wouldn't it be fair to also save some for botB kind?

Dustine wrote:Only I'd use the estimated energy usage per 60 ticks (or whatever pooling interval i'd use) because that's the minimum energy you're estimated to recharge per bot, so you wouldn't get the case where you asked to charge 10 out of a 2000 and still had juice left over by the 10th.

Dustine wrote: Actually, what do you think would be heavier: for area A, doing 2 find_entities_filtered for all kinds of robots, or doing n searches but one per each (valid) robot prototype? Like, you said above the biggest ups usage is creating/storing the bot entity references, while i always thought the heaviest part was the scan itself which is why I went for 2 (hoping for 1). Homework for me too I suppose.

local available_energy = get_energy() * 0.7 --your stuff costs more right? so make energy less valuable for calculation purposes
local i = 1
local e,m
repeat
  e = Cbots[i].energy
  m = Cbots[i].max_energy
  t = m-e --transfered energy
  if available_energy >= t then
    Cbots[i].energy = e+t
    available_energy = available_energy - t
  else 
    Cbots[i].energy = e+available_energy
    available_energy = 0
    end
  i = i+1
  until available_energy == 0
  
  --repeat for Lbots

  end