Ocktavo๐คฏ I'M ADDICTED! First time playing Factorio and I can't stop! See my factory grow from nothing! ๐ฅ New ep is here!
#Factorio #BlindPlaythrough #LetsPlay #NoobGamer #AuDHD #Gaming #Automation #NewVideo #FactoryGame #PCGaming #IndieGame #Gamer
YouTube
Never played Factorio before?! ๐คฏ Join my blind playthrough and watch me learn! ๐ AuDHD brain + Factory game = chaos! โ๏ธ๐ฅ New episode is LIVE!
#Factorio #BlindPlaythrough #NoCommentary #LetsPlay #Gaming #AuDHD #NewVideo #Automation #FactoryGame #OcktavoYT #Gamer
Factorio - No Commentary Blind Playthrough (EP7)
Jazzynupe.XboxDissolved Silica is SO FUN! - Satisfactory 1.1 - YouTube
https://www.youtube.com/watch?v=GAPR3tE3sxA
#ImKibitz #Satisfactory #FactoryBuilder #FactoryGame #PCGame #Gaming
Dissolved Silica is SO FUN! - Satisfactory 1.1
FICSMAS in Satisfactory 1.0! - YouTube
https://www.youtube.com/watch?v=akpzJGc0OLU&ab_channel=ImKibitz
#ImKibitz #Satisfactory #FICSMAS #Christmas #Gaming #BaseBuilding #FactoryGame #PCGame
https://www.youtube.com/watch?v=akpzJGc0OLU&ab_channel=ImKibitz
#ImKibitz #Satisfactory #FICSMAS #Christmas #Gaming #BaseBuilding #FactoryGame #PCGame
FICSMAS in Satisfactory 1.0!
Why Does THE BEST Oil Setup Need to Be So Complicated? - Satisfactory 1.0 - YouTube
https://www.youtube.com/watch?v=E2ExbZo_pNk&ab_channel=ImKibitz
#ImKibitz #Satisfactory #Oil #FactoryGame #PCGame
https://www.youtube.com/watch?v=E2ExbZo_pNk&ab_channel=ImKibitz
#ImKibitz #Satisfactory #Oil #FactoryGame #PCGame
Why Does THE BEST Oil Setup Need to Be So Complicated? - Satisfactory 1.0
Building a ROCKET FACTORY in Factorio Space Age!
https://youtube.com/watch?v=Q3cU1Jc41Lc&si=PRXLJASyHvOl6eSr
> Building a ROCKET FACTORY in Factorio Space Age!
#IMKibitz #Factorio #FactoryGame #BaseBuilding #FactorioSpaceAge #PCGame
Building a ROCKET FACTORY in Factorio Space Age!
nyatalily (Natalie)#FactoryGame
Ok. So. Conveyors hard. Well. Performant conveyors hard.
---
There's the relative distance approach. Items track the distance to the next item on thr belt. This means you only need to update the distance of the first item on the belt, and the other items are updated as they're effectively relative to it. To my knowledge, this is the approach factorio uses (these days,).
Pro: Cheap to update, cheap to change belt length, arbitrary belt length
Cons: Viewing, inserting items or extracting items requires iteration of items from the head to the relevant distance along the belt.
Con mitigations: Caching (last time we were waiting for item #18 and it was 5 units away, don't check until we think it should have arrived or an item is inserted between 17 & 18 or of 18 is removed before it gets to us ie.)
Con mitigation con: ow. no thanks. exploiting temporal coherence is an exercise left to the reader.
---
Then there's the timestamp approach. It's an evolution of the relative distance approach. Instead of tracking relative distance, you mark the timestamp it would reach the end of the belt at, if unobstructed. To resolve the position of an item you pick the higher value of: a) the time between it's end time and the current time, and b) the # item in the queue it is. B ensures items don't overlap, and instead accumulate at the head of the belt.
Pro: Less iteration required, belts have 0 update cost
Con: Factorio maps have already run long enough that 32bit timestamps aren't enough, lengthening/shortening belts from the head is expensive, arbitrary belt length
Con minimisation: when the 32 bit timestamp is hit pause the game and adjust timestamps to exist closer to zero, when lengthening or shortening belts track the "time offset" (apply to all belt timestamps when save/load or offset limit hit)
Con minimisation con: gross, but the second one is probably fine
---
The approach I came up with is what I call the occupany map approach. We represent each belt as a 32/64 bit interger. We do some shifting magic involving
Pros: updates are cheap (like 4x 1 clock cost instructions), memory footprint amortizes well (64bit/63 items*, ~1 bit per item vs 32bits/item), position of items is explict and absolute.
Cons: belt lengths are limited, machines without the BMI1 instruction set will have less terse asm
Con mitigation: we'll get into this with my next post because this is what I've been scraping my face against
* 31/63 items is due to needing to reserve the top bit to cause 1s to shift in naturally, instead of requiring a branch
- posted by Natalie
Ok. So. Conveyors hard. Well. Performant conveyors hard.
---
There's the relative distance approach. Items track the distance to the next item on thr belt. This means you only need to update the distance of the first item on the belt, and the other items are updated as they're effectively relative to it. To my knowledge, this is the approach factorio uses (these days,).
Pro: Cheap to update, cheap to change belt length, arbitrary belt length
Cons: Viewing, inserting items or extracting items requires iteration of items from the head to the relevant distance along the belt.
Con mitigations: Caching (last time we were waiting for item #18 and it was 5 units away, don't check until we think it should have arrived or an item is inserted between 17 & 18 or of 18 is removed before it gets to us ie.)
Con mitigation con: ow. no thanks. exploiting temporal coherence is an exercise left to the reader.
---
Then there's the timestamp approach. It's an evolution of the relative distance approach. Instead of tracking relative distance, you mark the timestamp it would reach the end of the belt at, if unobstructed. To resolve the position of an item you pick the higher value of: a) the time between it's end time and the current time, and b) the # item in the queue it is. B ensures items don't overlap, and instead accumulate at the head of the belt.
Pro: Less iteration required, belts have 0 update cost
Con: Factorio maps have already run long enough that 32bit timestamps aren't enough, lengthening/shortening belts from the head is expensive, arbitrary belt length
Con minimisation: when the 32 bit timestamp is hit pause the game and adjust timestamps to exist closer to zero, when lengthening or shortening belts track the "time offset" (apply to all belt timestamps when save/load or offset limit hit)
Con minimisation con: gross, but the second one is probably fine
---
The approach I came up with is what I call the occupany map approach. We represent each belt as a 32/64 bit interger. We do some shifting magic involving
blsr, which causes the bits to shift right but to never shift 0s out, causing them to accumulate. 0s represent items on the belt and their position, and the number of 0 bits before an item determines its index in an array.Pros: updates are cheap (like 4x 1 clock cost instructions), memory footprint amortizes well (64bit/63 items*, ~1 bit per item vs 32bits/item), position of items is explict and absolute.
Cons: belt lengths are limited, machines without the BMI1 instruction set will have less terse asm
Con mitigation: we'll get into this with my next post because this is what I've been scraping my face against
* 31/63 items is due to needing to reserve the top bit to cause 1s to shift in naturally, instead of requiring a branch
- posted by Natalie
#FactoryGame where you start out ordering super conducting magnets and quantim ocilators, assembling them into something, and work down the tech tree to improve profit margins
- posted by Natalie
- posted by Natalie
#FactoryGame
Okay. So, if our factory is using fixed-speed belts with max stack size controlling throughput, how often do we need to update the factory simulation?
---
Looking at other games, it's varied and kinda random:
- Satisfactory runs at 30 ups, with a base belt speed of 1 item/sec.
- Factorio runs at 60 ups, with a base belt speed of 7.5 items/sec (per side of belt).
I think the ups these games run at either don't reperes5the real factory tick rate, or they're using that ups granularity to make items move smoothly. Factorio definitely does the latter, satisfactory allows you to throttle visual updates (so i assume they have interp?).
---
We could easily have 1ups and a base throughput of 1 item/sec, basically calculating the future state of the factory and interpolating towards it.
This has a downside, in that a 1 second lag is very visible to a user. For example, if you removed a machine, it'd still be fed into for the rest of a second despite having been removed. Adding a belt the items would be delayed nearly 1s before moving onto it. Floating items etc. etc. Inventories are more discrete, and won't have this issue though.
I think we can work around it. We could animate the buildings being built/deconstructed, and time it so it's done by the start of the next factory simulation update. Obviously there's some minimum animation time, otherwise some buildings will be very slow and others would be instant depending on when you clicked.
---
That's still a lot of latency to be trying to hide though. It'll make things feel sluggish. I'd look up the science, but, everyone seems to have an opinion fabricated out of thin air. So. I'm going to base mine on Bluetooth audio latency.
SBC (disgusting) has a latency of 200ms, the audio lag of being 68m (225ft) from the audio source. I can't stand it. APT-X (fine) has a latency of 40ms, the time it takes for sound to travel about 13m (45ft). There's a bunch of people claiming that under 110ms feels "instant" in terms of reaction, so we'll consider that too.
That's a range of 5 ups to 25 ups, with "instant" being around 9 ups.
Let's throw framerates in, since we're going to be interpolating. Be nice to make it a consistent speed. We'll consider 60, 120 & 144. The greatest common factor between these 3 is 12.
Given that 12 is roughly in the middle of that audio latency range, and near the unsourced perceptual instantaneous limit... And that 12 is pretty and divisible and cute.
I think it might be the UPS to go with. This is very much not science, and is extremely arbitrary and not really backed by real justifications. I just like how the number feels tbh
---
12 ups = base speed of 12 items/sec = 83.3333ms latency for modifying the factory.
- posted by Natalie
Okay. So, if our factory is using fixed-speed belts with max stack size controlling throughput, how often do we need to update the factory simulation?
---
Looking at other games, it's varied and kinda random:
- Satisfactory runs at 30 ups, with a base belt speed of 1 item/sec.
- Factorio runs at 60 ups, with a base belt speed of 7.5 items/sec (per side of belt).
I think the ups these games run at either don't reperes5the real factory tick rate, or they're using that ups granularity to make items move smoothly. Factorio definitely does the latter, satisfactory allows you to throttle visual updates (so i assume they have interp?).
---
We could easily have 1ups and a base throughput of 1 item/sec, basically calculating the future state of the factory and interpolating towards it.
This has a downside, in that a 1 second lag is very visible to a user. For example, if you removed a machine, it'd still be fed into for the rest of a second despite having been removed. Adding a belt the items would be delayed nearly 1s before moving onto it. Floating items etc. etc. Inventories are more discrete, and won't have this issue though.
I think we can work around it. We could animate the buildings being built/deconstructed, and time it so it's done by the start of the next factory simulation update. Obviously there's some minimum animation time, otherwise some buildings will be very slow and others would be instant depending on when you clicked.
---
That's still a lot of latency to be trying to hide though. It'll make things feel sluggish. I'd look up the science, but, everyone seems to have an opinion fabricated out of thin air. So. I'm going to base mine on Bluetooth audio latency.
SBC (disgusting) has a latency of 200ms, the audio lag of being 68m (225ft) from the audio source. I can't stand it. APT-X (fine) has a latency of 40ms, the time it takes for sound to travel about 13m (45ft). There's a bunch of people claiming that under 110ms feels "instant" in terms of reaction, so we'll consider that too.
That's a range of 5 ups to 25 ups, with "instant" being around 9 ups.
Let's throw framerates in, since we're going to be interpolating. Be nice to make it a consistent speed. We'll consider 60, 120 & 144. The greatest common factor between these 3 is 12.
Given that 12 is roughly in the middle of that audio latency range, and near the unsourced perceptual instantaneous limit... And that 12 is pretty and divisible and cute.
I think it might be the UPS to go with. This is very much not science, and is extremely arbitrary and not really backed by real justifications. I just like how the number feels tbh
---
12 ups = base speed of 12 items/sec = 83.3333ms latency for modifying the factory.
- posted by Natalie
I Automated EVERYTHING* Dangerous in Satisfactory 1.0 - YouTube
https://www.youtube.com/watch?v=L9zly5nOFrE&ab_channel=ImKibitz
#ImKibitz #Satisfactory #FactoryGame #PCGame #Weapons
https://www.youtube.com/watch?v=L9zly5nOFrE&ab_channel=ImKibitz
#ImKibitz #Satisfactory #FactoryGame #PCGame #Weapons
