Factorio Forums

DaveMcW wrote:

Code: Select all

/c
request_fuel = function(entity)
  if not entity or entity.type ~= "furnace" then return end
  local item = "coal"
  local add_more = true
  for fuel,amount in pairs(entity.get_inventory(defines.inventory.fuel).get_contents()) do
    if amount < 10 then
      item = fuel
    else
      add_more = false
    end
  end
  if add_more and entity.surface.count_entities_filtered{name="item-request-proxy", force=entity.force, area=entity.bounding_box} == 0 then
    entity.surface.create_entity{name="item-request-proxy", target=entity, force=entity.force, position=entity.position, modules={{item=item, count=10}}}
  end
end

request_fuel(game.player.selected)

This adds a temporary request for a single furnace. You need to add more logic to always update every furnace on the map.

Alex99 wrote:Also is there any way to use logistic bots instead of construction?

DaveMcW wrote:Not easily. The only way is to create a hidden logistic entity that requests coal (see defines.events.on_built_entity), then code to transfer it to your furnace.

bobingabout wrote:No, something that is constantly updated must be on the on_tick event. This is one reason why I personally do not include features of this nature in my mods.

There are however some guides around on how to attempt to offset the UPS disruption, such as only checking each chest for requests once a minute, but iterate through this list so that something is checked every tick.

something like

Code: Select all

for i, entity in pairs(list) do
if game.tick % 3600 == i % 3600 do

function OnTick(event)
	local tick = game.tick
	for i=1, #global.VoidChests do
		if (i + tick) % update_interval == 0 then
			global.VoidChests[i].get_inventory(defines.inventory.chest).clear()
		end
	end
end

function OnTick(event)
  global.tickCount = global.tickCount or 1
  global.chestIndex = global.chestIndex or 1

  -- only work if index is within bounds
  if global.chestIndex <= #global.VoidChests then
    local stopIndex = global.chestIndex + global.VoidChestStride - 1
    if stopIndex >= #global.VoidChests then
      stopIndex = #global.VoidChests
    end

    -- log("[VCP] "..global.tickCount.." / "..game.tick.." clearing chest ids "..global.chestIndex.." to "..stopIndex)
    for i=global.chestIndex, stopIndex do
      global.VoidChests[i].get_inventory(defines.inventory.chest).clear()
    end
    global.chestIndex = stopIndex + 1
  end

  -- reset clock and chest index
  if global.tickCount < update_interval then
    global.tickCount = global.tickCount + 1
  else
    global.tickCount = 1
    global.chestIndex = 1
  end
end

Optera wrote: I've benchmarked that to be 40% faster than above snippet in Void Chest +

local UPDATEDELAY = 60

local function on_tick(event)
  local tock = tick % UPDATEDELAY
  for index=#global.mystuff-tock,1,-1*UPDATEDELAY do
    --stuff
    end
  end

• one modulo per tick
• only loops through entities that are actually updated
• updates all entities in a fixed time window (aka does not get slower with more entities)
• (con) if new entites are constructed during an updatecycle some will be skipped until the next cycle

eradicator wrote:

Optera wrote: I've benchmarked that to be 40% faster than above snippet in Void Chest +

The last time i tried to to a tick-distrubuted update i used a construct like this:

Code: Select all

local UPDATEDELAY = 60

local function on_tick(event)
  local tock = tick % UPDATEDELAY
  for index=#global.mystuff-tock,1,-1*UPDATEDELAY do
    --stuff
    end
  end

Features:

• one modulo per tick
• only loops through entities that are actually updated
• updates all entities in a fixed time window (aka does not get slower with more entities)
• (con) if new entites are constructed during an updatecycle some will be skipped until the next cycle

It basically walks backwards through the array (because sometimes i need to delete stuff if it becomes invalid, and forward walking screws up the index in that case) and updates every n-th entity.

I only did some very short tests tho as in my case with very few entities (entity_count < UPDATEDELAY) the numbers seemed to suggest that doing them in bulk every n seconds was faster.

Optera wrote: Overall I'd say the wiki should be updated to use your version. It's far more simplistic and unless you have to call different functions depending on accurate execution order your stepping with stride will work perfectly fine.

Bilka wrote:

Optera wrote: Overall I'd say the wiki should be updated to use your version. It's far more simplistic and unless you have to call different functions depending on accurate execution order your stepping with stride will work perfectly fine.

Which wiki (page) talks about this?

Optera wrote: That's a nifty way of stepping with stride.
Benchmark results for 480 Void chests using either version as on_tick over 100k ticks:
My current version: avg 11805.281 ms
Your version: avg 11776.126ms

eradicator wrote: Thanks (also for the numbers). It's amazing that the difference would be so tiny despite your frequent access to the global table for index management. I guess my intuition about what is expensive and what isn't is pretty bad . Also btw in your code i think you can call .clear_items_inside() directly on the chest entity, which should save the get_inventory call and thus the passing of another reference object over the c++/lua barrier.