#Nonstandard Beacons - Factorio Mods
1 messages · Page 1 of 1 (latest)
Also, I'm guessing the beacons can use any fluid, not just steam?
steam is the example, it's just an energy_source prototype
you can technically run it on plasma if your heart desires
Speaking of which, could you also make it allow fluid beacons to output fluids too?
Like inputting plasma and outputting hot fluoroketone?
¯_(ツ)_/¯
probably
the 'energy source' is actually just a crafting machine
so probably
actually yea, i can just have it override the internal empty recipe with a custom fluid swapping recipe
i think i can just have an optional 'recipe_definitions' value that, if set, overrides the hidden one and can also define fluidboxes and the like
@weary mortar i dont have a puppy so have a box qat
awwwww
wait, why did the devs say they wouldn't implement this?
optimisation reasons
i mean yeah sure theyre gonna be intense but... it makes more sense to let modders decide if they use the UPS intensive stuff or just go with basic beacons
cause if they really want burner beacons they'll do burner beacons. see exhibit A above
something tells me you could do it without any scripting
is there any way to turn heat directly into electricity
you need scripting
there's no way to make sure that an entity only connects to a specific power network
UPDATE got the update time down to ~1.6ms with 400 beacons
hm
irritating
you could turn down the check frequency a lot though
dont know how you've done it internally but you could set it up in such a way that you only check once every few seconds
probably but id rather focus on trying to get the update time down instead of just 'have it do things less often'
what exactly does it currently do when it checks a beacon?
er wait not that one
iterates over every entity. if the beacon is on and the assembler is off, then change the beacon to off. if the beacon is off and the assembler is on, switch it to on
i would do it where you have an assembling machine producing some hidden fluid
you can't have the beacon run on fluid. hence this mod.
they are locked to electricity and void
you know how much fluid it should be producing per time period
same with roboports
try saving which status you've last set on the entity object, writing 2 things to the factorio api has overheid
if the output fluidbox has enough fluid for a time period, remove that much fluid and turn the beacon on
if it doesn't, don't remove any fluid and turn the beacon off
how so? like comparing current to previous status?
check frequency is a setting, right?
it's not accurate enough, and that has way more math and API calls than this current solution
yeah, on your table just store what status you last wrote
because that way you can turn down check frequency as much as you like and it's still perfectly accurate
not really in the current implementation but it can be
it has some latency
math is not accurate at those scales
i'd defintely recommend it, but it doesnt have to be "NOW" thing
and that doesn't work for heat or burner powered items
but if you want your beacon to consume (say) 1MW of heat, then it will consume 1MJ of heat for every second it operates
yes it does
you can have heat and burner powered assemblers
no? you can't do burner that way
burner would still just have to check if the assembler is on or off
yup
my original solution was to have an infinity pipe/heat interface but the 'power draw' simulation was too innacurate to be reliable
no it wouldnt
you have a beacon
which draws 0W of electrical energy
you have an assembling machine
which draws 1MW of [whatever] energy and is set to produce 1 beacon juice per second
tried that in a previous implementation, i forget why i went away from it but i'll see if that works. are 'storage' calls cheaper than API calls?
they are
every second, check how much beacon juice is in the assembler's output fluidbox
if there's more than 1, remove 1 and turn the beacon on
if there isn't, don't remove anything and turn the beacon off
that seems like way more then just doing "is this thing on? sure, turn x on"
you can change the power draw of the beacon using consumption_modifier
edge case, the beacon 'lost power' partway through and only produced half a juice. but it was on for half the time
but it's perfectly accurate
there's no edge cases where the beacon runs when it shouldnt or doesnt run when it should
okay then when you underclock the beaocn it'll flicker on for one whole second every 20 or something
or rather, there's no edge cases where you get more or less beacon uptime than you paid for
instead of flicking on and off more rapidly like it should especially considering it's power draw is doing that
i just dont see how that'd be simpler then whats currently been implemented
how is it more correct?
this would also (theoretically) be faster
its even less accurate
because you can turn the check frequency down arbitrarily low
ive explained like three times how it's more accurate
in the 1MW case, each second of beacon uptime costs 1MJ of energy
maybe 'accurate' but there's a clock_length delay between what it 'detects' and the actual result
I'm just wondering, how do the beacons work at different temperatures?
same way any other heat energy source works i expect
unless its a multi-second delay in turning on/off, i dont think people would care
yup. nothing fancy
yeah, i imagine it doesnt take temp into account apart from a base requirement
changing power draw with temperature would be. uh.
hell
detrimental to performance, let's say
slightly not opotmised, to put it lightly
if you can come up with an implementation then i'd be happy to look into it, but right now i don't see how its any better so i'm not going to pursue it
i still have to poll the API to check if the assembler is working or not... i wonder if any other API calls that are 'good enough' are cheaper
quezler do you know of any? or is it more that API calls have some generic latency from being API calls and not about what they do
with working, do you mean at all, or only 100%?
depending on your answer i have tricks
it's always 100% or 0%, there's no 'low power' state since there's no buffer for any of the energy sources i use
so just 100%
allright that makes it super easy then
figured out how to save the current state in storage, i'll see how performant that change is
connect a wire by script, set the working signal to W, have a hidden surface with an inserter that checks for W = 0, have an item on the ground and register that with script.register_on_object_destroyed, and when it triggers you'll know the assembling machine had an interuption
I've been pioneering this kind of circuit lua event tech
ohhhh 40% improvement in UPS
this would all be so much simpler if we could connect electric networks with scripts
is the inserter jankery the best option for API calls based on signals?
from merely not setting status & custom status each time? nice
well at least it means you won't have to check entities constantly
no just from the API call of 'is this beacon on or off'
i still set status and custom status every time
er well every 'change' from on to off or off to on
hmm
might i suggest instead of numbers to just
local BEACON = 1
local ASSEMBLER = 2
local LAST_STATUS = 3
that works too
makes it was easier to read along
how do you even discover things like this
wait... when i do that... i can have an update time of 0
i can just add them to a queue to enable/disable and just iterate over those queues
what did you mean by this?
might have misunderstood
one? 
no i use that tech excessively, though the one closest to your usecase would be the apprentice assembler
well I don't think that should be there
ah yes the classic hide_from_player_crafting
i forget that one a lot myself as well
especially when using custom crafting categories the character doesn't jave
well it doesn't have an icon