Factorio Forums

rainboy wrote: I could also model it as some multi-entity structure (probably a visible accumulator which I manipulate and a hidden assembler which does the actual work mechanically), but the devs have repeatedly said (and I happen to agree) that such structures are bad form in general since they introduce issues with keeping the various parts of the structure in sync with each other (eg, one part is deleted/destroyed and the other part has to do the same, which can be difficult).

eradicator wrote: Mon Jul 01, 2019 5:12 pm You can impose arbitrary limits onto the energy_source via input_flow_limit and output_flow_limit. I do this in Hand Crank Generator (see signature) to use a "tertiary" accumulator as an output-only generator. If you want to power other things you should try an electric-energy-interface with your prefered priority and gui_mode="none" and allow_copy_paste = false. You'll still have to deal with all the annoyances (performance, energy graph spikes) that happen when you're trying to large-scale teleport electricity around.

darkfrei wrote: Tue Jul 02, 2019 7:47 am You are need a modded electric energy interface with disabled GUI and primary priority, that takes the energy from the accumulator by the script.

eradicator wrote: Tue Jul 02, 2019 6:13 am The EEI exists explicitly to emulate production/consumption machines via script so it'd kinda be weird if it didn't work. And as far as i can tell it works as expected when given a different usage_priority. I'm more suprised that you said accumulators don't respect usage_priority, just tried and at runtime they report their priority as "managed-accumulator" while the EEI reports "tertiary", and i found a post by @Rsed that mentions the hardcoding of the accu priority. "You learn something new every day." Narf.

Care to share details about your algorythm? Ever since runtime-changability of flow limits of the EEI was removed i can't see a way to do it without having ridiculously large buffer sizes. How do you not have to iterate over everything regularly? Are tesseracts not supposed to have an even draw across all power input/output points even if they're on different networks? What is the performance impact if you i.e. pop 100~200 pairs on an empty map? What happens on input starvation?

script.on_event(defines.events.on_built_entity, on_creation )
script.on_event(defines.events.on_robot_built_entity, on_creation )
script.on_event(defines.events.on_player_placed_equipment, on_creation )

		local drain_total = highest_active.global_drain_per_tick
		local req_total = 0
		local sup_total = 0
		
		-- Figure out what is being requested.
		for i=1, #global.list do
			local entity = global.list[i].entity
			local config = get_tesseract_config(entity.name)
			
			if is_input(config, entity.name) then
				sup_total = sup_total + (entity.energy * config.individual_efficiency)
			else
				local req = ((entity[config.buffer_key] - entity.energy) / config.individual_efficiency)
				if req > 0 then
					req_total = req_total + req
					drain_total = drain_total + config.individual_drain_per_tick
				end
			end
		end

		-- Calculate transfer ratios.
		local req_ratio = (sup_total - drain_total) / req_total
		if req_ratio ~= req_ratio then	-- Test for NaN
			req_ratio = 0
		end
		req_ratio = math.max(0, math.min(req_ratio, 1))

		local sup_ratio = (req_total + drain_total) / sup_total
		if sup_ratio ~= sup_ratio then	-- Test for NaN
			sup_ratio = 0
		end
		sup_ratio = math.max(0, math.min(sup_ratio, 1))
		
		if game.tick % (5 * 60) == 0 then
			debug("Total request: " .. math.floor(req_total * 60 / 1000) .. "kW, Ratio: " .. math.floor(req_ratio * 100) .. "%, Total supply: " .. math.floor(sup_total * 60 / 1000) .. "kW, Ratio: " .. math.floor(sup_ratio * 100) .. "%, Drain: " .. math.floor(drain_total * 60 / 1000) .. "kW")
		end
		
		-- Perform transfers.
		for i=1, #global.list do
			local entity = global.list[i].entity
			local config = get_tesseract_config(entity.name)
			if is_input(config, entity.name) then
				set_energy_level(global.list[i], entity.energy * (1 - sup_ratio))
			else
				set_energy_level(global.list[i], entity.energy + ((entity[config.buffer_key] - entity.energy) * req_ratio))
			end
		end

Rainboy wrote: Tue Jul 02, 2019 12:12 pm Also, protip, never use table.remove. It's horribly inefficient and has plagued my performance. See this Stack Overflow post for a much better algorithm (scroll down to the answer that starts off with "Efficiency!").

Rainboy wrote: Tue Jul 02, 2019 12:12 pm Also, protip, never use table.remove. It's horribly inefficient and has plagued my performance.

table.remove(tbl,i) --standard
tbl[i] = tbl[#tbl] --don't care about order

eradicator wrote: Tue Jul 02, 2019 3:03 pm Btw, i can't get your mod to work. I built a bunch of tier-3s, and the input side shows internal power, but the output side doesn't. Also the entitys have wildly different descriptions than the items/recipes.

eradicator wrote: Tue Jul 02, 2019 3:03 pm Also protip: Use tools appropriate for the task. That guy on stackexchange tests some tables with 20 *million* entries of which over a million are removed at once. So he's comparing his "smart" approach of ~1.5million assignments to the "dump" approach of roughtly 15 *trillion* key=value assignments per table, with the obvious outcome that doing 5 order of magnitude fewer assignments is faster. I'm not sure what you do internally, but i'd expected the only events where you have to insert/remove table entries would be entity de/construction, which happens one at a time. And for one-removal-at-a-time table.remove() - as a C++ side function - should certainly be faster than a lua-side reimplementation. Futhermore...if you don't actually care about the *order* of a table (as is usually the case with lists of entities) you can just shove the last element of a table into the new position when you want to delete something:

Code: Select all

table.remove(tbl,i) --standard
tbl[i] = tbl[#tbl] --don't care about order

eradicator wrote: Wed Jul 03, 2019 9:18 am Does it break the savegame for good if i place mk3's first? I tried placing some 1's and 2's and then rebuild the 3's, but that didn't seem to help. Got it to work after removing your mod from the save and adding it again. Also it seems like you're not handling the script_raised_* group of events, so you're incompatible with scripted ghost reviving, which might have caused additional problems (due to my testing mod doing instant de/construction).

eradicator wrote: Wed Jul 03, 2019 9:18 am Stripped down sample implementation:

Build some accus on west/east sides of y-axis, then scan the surface:

Code: Select all

/c

global.ins = {}
global.outs = {}

local function update_list()
  global.list_in  = {}
  global.list_out = {}
  global.total_out_capacity = 0
  global.total_in_capacity  = 0

  for _,this in pairs(global.ins) do
    local max = this.prototype.electric_energy_source_prototype.buffer_capacity
    table.insert(global.list_in,{this,max})
    global.total_in_capacity  = global.total_in_capacity  + max
    end
  for _,this in pairs(global.outs) do
    local max = this.prototype.electric_energy_source_prototype.buffer_capacity
    table.insert(global.list_out,{this,max})
    global.total_out_capacity = global.total_out_capacity + max
    end
  end

local function add(this)
  if this.type == 'accumulator' then
    if this.position.x < 0 then 
      print('add','in',this.unit_number)
      global.ins[this.unit_number] = this
    else
      print('add','out',this.unit_number)
      global.outs[this.unit_number] = this
      end
    end
  update_list()
  end
    
local p = game.player
for _,accu in pairs(p.surface.find_entities_filtered{type = 'accumulator',force = p.force}) do
  add(accu)
  end

The tick handler:

Code: Select all

/c
--[[V2]]
local list_out = global.list_out
local list_in  = global.list_in
script.on_event(defines.events.on_tick,function(e)

  local total_supply = 0
  local total_demand = 0
  
  for i=1,#list_out do
    total_demand = total_demand + list_out[i][2] - list_out[i][1].energy
    end
    
  for i=1,#list_in do
    total_supply = total_supply + list_in[i][1].energy
    end

  local in_factor  = (total_supply <= 0) and 0 or math.min(1, total_demand / total_supply)
  local out_factor = (total_demand <= 0) and 0 or math.min(1, total_supply / total_demand)

  for i=1,#list_out do
    list_out[i][1].energy = list_out[i][1].energy
      + (list_out[i][2] - list_out[i][1].energy) * out_factor
    end
    
  for i=1,#list_in do
    list_in[i][1].energy = list_in[i][1].energy - (list_in[i][1].energy * out_factor)
    end

  if e.tick % 3600 == 0 then
    print(total_supply,total_demand,in_factor,out_factor,#list_in,#list_out)
    end
    
  end)
  

eradicator wrote: Wed Jul 03, 2019 3:35 pm Regarding the whole "animated/not animated" thing: At this point you're not using any special features of the EEI, so you might as well use some other kind of entity, like assemblers/generators that produce/consume actual fuel. On the other hand if you keep the EEI you could experiment with actually producing/consuming power, removing most script overhead for tesseracts running at full capacity, but introducing lots of complicated overhead code for dealing with the transitional states between not-used-at-all and fully-used.

Btw, were you thinking about supporting channels like actual TE tesseracts?

eradicator wrote: Thu Jul 04, 2019 3:56 pm I thought a bit about optimization, but the best thing i came up with was to have all tiers have the exact same buffer size, which should make almost all calculations slightly cheaper at the cost of having rather large buffers for lower tiers.

To get an idea of what we're dealing with i tried a minimalistic handler that simply deletes all energy in the setup from the above screenshot, and that still uses 0.65ms. This is probably more than factorissimo uses for *all* of it's handling in a medium sized factory. So i can only recommend again you switch back to a buffered solution that only runs once per second or so if you have any desire to "grow your userbase" (:p), as this sort of change will introduce all sorts of bugs again so the earlier you do it the better.