#Sushi Mechanics?
1 messages ยท Page 4 of 1
its more the extension of thyme's idea for me. like his very first step of the tutorial works, but it's not the "best" or most compact way to do something. so now im trying to further extend the logic to the wagon
The waste is you're splitting a bluebelt into 1/7th, 7 times
There's multiple facets to that
and im merging /consolidating blue belt from a wagon in the first place so its a lot of unnecessary steps
if im not consuming a bluebelt of science theres no need to form/make a full yellow/red/blue belt
just to split it off again
If you need a 7th of a bluebelt, half a yellowbelt will do
but i still need the blue belt sushi for lab to reduce the number of beacons
its just the inputs dont need to be blue
Yup
These colors are specifically chosen
Not that you need them, just that they're sufficient
2/7ths is less than a yellowbelt at 1/3rd. 4/7ths is not
The only rate control you actually need are the two belts right before the last splitter, to make it so it's taking 1/3rd of the y/w, and 2/3rds of the other
one third of a 50-50 and 2/3rds of a 25-25-25-25 gives you 1/6th of each.
can i rely on inserters to be rate control?
have not thought very deeply into whether i need all the different splitters if i just assume inserters are working full time to supply at whatever is the prevailing rate a stack inserter works on a yellow belt
You can rely on some very weird rate controls with A-B sushi. Jouster's the master of that, I've merely dabbled
But yeah if there's room on the belt stuff can place
1 stack inserter 24/7 unloading into a red belt = almost exactly 1/7 of a bleu belt
If there isn't room, it won't. This is a combo of rate and A-B
you'd have to recycle through the chest
im just talking purely rates for now i dont know how it would work in practice
I'm not stoked but you prolly could do that. I don't think I've seen it before
Prioritizing recycle would be tough
yea im not 100% sure how recycle will work with this. also how to protect vs input starvation
i assume i have to link all 7 train station chests together (and their outserters)
The other thing I see is that inserters can only put items on one side of a belt
only enable if all 7 stackserters have enough to grab to make it 1/7 of a belt? idk if this will mean i can skip splitters, or i would still need a splitter for it
But actually the more I think about it the more I like it
๐
im just spitballing for now. i have to do a draft to actually see if theres any merit to this idea
If you're rate controlling with inserters you can minimize recycling
If you don't allow it to flow when even one is missing, that avoids most recycling
you basically only "need" 7 stackserters to make one sushi belt in this theoretical idea
im still not sure if this protects from overload or not
or whether backpressure from main sushi belt can take care of this
still not sure how to merge all the 7 different stackserter belts into one since they will presumably be also a medium distance apart
I was looking for a railcrime but I guess sushicrime will have to do
i tried to draw the whole idea purely on paint but i couldnt do it. guess it will have to wait
what even is a sushicrime? That's like saying fraudcrime, it's all crime to begin with
Blue collar crime?
sawdust in the carbeurator?
Railcrime feels like blue collar crime, it's just track and signals. Sushi crime feels like white collar crime, you gotta have something going already
is this new method i cooked up strictly inferior to other methods? trying to see the cons of this 'cut out the middleman' (aka splitter). also trying to see potential problems but its hard without the actual thing running
or its unnecessarily overengineered? i think 2 paralel belts (one with 5 sciences, the other with purple+black sideload) would be a decent compromise for simplifying things. black/purple is only consumed when particular research is being used except for follower bot
so it probably doesnt warrant overcomplicating things, but reducing the number of input belts to feed labs can be a boon (imo) for beacon builds
and 8 beacons is somewhere in the middle ground where you can have two easy parallel input belts cutting through without spaghettifying everything
I think your math was wrong somewhere but the concept may still work
Yeah conceptually, you're on the right track
unload onto a red belt, not a blue belt i think
blue belt is a lot more than the red, red is so close it almost seems too coincidental
redbelt is slightly too fast
ive no clue
hmm ok. thanks for the quick draft. that was exactly something i had in mind
Even onto a YB starts to back up, which is immediate fail state
It's very close though
Stack size 7 onto a YB has the tinies of gaps
Stack size 8 slowly backs up. I think 7's the best you get
why is backing up a fail state? without the clip of it failing im not sure what causes the whole thing to lock
tiniest of gap i can potentially write off as a tradeoff for simplicity, key is still whether it works as one consistent sushi belt and how easy/difficult it is to protect against the more common fail states
im technically only feeding 11.8 labs for follower robot research anyway off one blue belt sushi'd at 1/7 each
If it's backing up, that means that you're oversaturating. More than a full belt is going in
that is pretty nice to look at
Shit you can clean up the design further. great job!
also very nice with just 1 splitter use
any downsides you can think of to this approach?
pog
yea i havent really thought about how to handle the output end of the belt
i might be able to reduce the complication if i separate purple and black. since those two are the main culprits
thanks a lot for translating my word vomit into something usable. will be nice to troubleshoot when i get back
oof
yea recycling is always a bitch with sushi
have to wonder if chest defence is sufficient if its just the 5 non-purple/black sciences
as expected things would not be so easy the first time around. mockup using pseudo train wagons from the theoretical infinity chests model
seems like its the classic two lanes not moving in lockstep problem, but not 100% sure
i feel like this is important but still cannot understand the significance or reasoning behind this
maybe some number of splitters is necessary for a better / more seamless way to merge the 7 inserters together...idk
pardon the extra two chest+inserter per train - i thought i'd try and do all 3 sushi belts at once but clearly that was not feasible and i should have stuck with just 1 working sushi belt first ๐คฃ
im guessing looping the exit end back to the individual wagons should be the end of my worries?
#1277595827547799552 message You're starting to grasp twobelts. This is kindof the core thing about twobelts, that I'm not saying the color of the belts when I say that there's two of them. I chose yellows when I only needed yellow rate, red when I needed a rate >YB but <RB. Twobelts is two belts as a reference is just pointing to rates as the important thing.
It's funny that being nonspecific is pointing at being hyper specific. Stack inserter with hand size limit of 7 with a yellow belt is slightly under on rates, but 8 is over
Redbelt is way over
8 hand size isn't a lot more, but it's barely enough. If you get your rates correct it should fit on a blue belt and you can sideload.
one of the weird thing about applying rates to belts is that you really need to account lane-by-lane not just purely the belt "as-a-whole"
blue belt can transport 4500/min but really it is 2250 /lane/min. trying to do something like 2500 + 2000 on two sides of the belt technically fits within 4500/min but will fail spectacularly because of the lane limitation
what implication does handsize 7 have on saturation of a sushi belt? especially if im trying to do a 5-item science sushi instead of 7?
Twobelts is twobelts. Rates is just rates
the thing about the gaps being present means that i can use faster belts on the unload?
And yeah good shout on the sides thing
switching to 8, doesn't matter if there's room on the other lane, that's too fast
wonder how many splitters i need to do a smoother job as opposed to this sideloading. you had one earlier setup that used more splitters
this one
Not sure what's with the timing, I ignored it
It's either at rate or it isn't
If you want to mess with that you can, as long as you don't mess with the rates you're fine
just recalled that belt weaving is a thing so i might just do it instead and call it a day if this seems particularly overengineered
My kind of sushi is not intended to be used with a return belt. You can do it, but all the unsorting back into pure imputs kind of defeats its purpose.
Since Labs don't have a fixed consumption ratio, it's more optimal to just sideload the correct amount onto a looped belt.
+1 labs is honestly the easiest defense for belt end, I think
Overconsume, you don't end up with dregs
Yeh im starting to realise that sushi is not really necessary for lab science. Wrong tool
Belt weaving seemed simple enough no need to overcomplicate with unnecessary splitters and more footprint
I do need to think about how to unload two wagons evenly though. Or maybe just stick to one wagon
It seems just 1 inserter might be enough for what i need for 1k spm to unload
Not necessary, but by far the most fun
i guess this is the part where shoehorning sushi is necessary to extract maximum challenge
im gonna stick to low tech for now to get to the rest of the game
lol yeah, I was like "I should get around to yellow science, let me look at the calculator. Two machines under beacon?!? Unacceptable"
im re-designing a new red chip factory with the new knowledge i gained the past 2-3 weeks (or has it been a month?) and damn its gonna look very different. i wonder how that would play out
the part where 1 inserter can fill the role of filling 15-25% of a blue sushi belt is kind of tripping my head a little bit
i need about another 200 more red chip machines and i think its finally go time
somehow i dont think its possible to use DI to have 1 wire machine feeding 8 RCs in a 12beacon setup right?
i could make it 1
: 4RC but that would mean twice as many AM3 making wires and more beacons/t3 modules. or maybe i just belt
DI in 12 beacon is super hard
You must handoff, unless I'm sorely mistaken, which might be the case. I'm like 99% sure
isnt it borderline impossible? best case is chest handoff
i dont see how i can squeeze another am3 between 12 beacons
If it's possible, i would love to see it lol
theres just no space for another 3x3. it must occupy where a beacon will go
There might be something here
maybe an 11 beacon ๐ค
But I don't see it even so
nah that's too much of a meme even for me
That asm is taking up a beacon spot
yea it might be doable on 11 beacon
idk if its worth โข๏ธ tho
might as well go the whole hog if im gonna try for pollution minimisation. 12 beacon everything, see how much pollution i produce for 1kSPM just as a reference point. then i make tradeoffs from there in future saves
its getting very tedious and samey though with 12 beacon everything
lol it's still only 10
There's a tile though, maybe
I guess I can get it to 11
I think the other machine will always take up one beacon slot, if 12 was possible with a DI, then 13 beacons would be possible.
Same size, sameish locality constraints
yea looks absolutely horrible
my only rationale that 11 was possible is cause the AM is same sized as a beacon so it could theoretically take the place of one beacon but i dont think thats how it works in practice
That is how it works
now im not too sure what tradeoff i need to make for chest handoff 1 wire machine to 4 RC (far from optimal ratio by about 100%, should be 8 RC) as opposed to just belting it
i dont need that many wire machines cause i intend to belt the plastic and GC as opposed to making it on-site (big mistake from very very first sushi version)
I know I sounded crazy when I said GC and RC are actually one of the biggest hurdles for megabasing, but fr, wire's a bitch
it gets so bad when you try to do volume
yea i put it off for so long because i couldnt deal with moving that much wires
the tradeoff for DI is usually more machines (making wires) and therefore more beacons right?
what is the main benefit for DI in this scenario?
Not necessarily. I have no extra wire beacons and the beacons on the RC have excellent sharing
Compact helps with beacon sharing
im thinking just "more belts" that is spread across more stacks
oh right you make the GCs together with RCs
Idle machines are "good" for ups, or rather, they aren't so big a penalty. Decreasing beacon counts with DI can be optimal
im just gonna isolate the main stuff like GC and RC. definitely UPS unfriendly since theres so much "double logistics" but its just easier to move/produce
This is why factorio is eternally interesting to me. Even if I get the theory cooked(I do not have it cooked lol), in practice, i still have to make interesting choices
I chose to import plastic there
yea i think importing plastics is typically a no brainer
the input materials are just too differnet to make sense making it with the rest. GC+RC together is the real headache. there is a lot of overlapping materials
lol I found these oils after I had already planned GC here, now I'm bummed
but belting everything to make it fit the ratio is nearly impossible with the way wires expand the volume of a belt of copper plates
I have coal and water too. That was a better RC spot
But yeah b/c all the circuits are that way, you can really limit what you're moving on the tracks
need to make some important tradeoffs at some point. whether its DI or outsourcing GC production
or something else entirely. not sure
i might just do GC import just to see which works better for me
but still on the fence of belting copper wires vs 1:4 chest handoff
ya i just made BC another outsourced production facility. its just easier to handle right now, i cant do the belting properly. sushi helped a bit but not all the way
It's just such a tight ratio....
im not sure if theres an easy way to compare DI vs. belt approaches for beacon average for a required X number of machines. just for purposes of (1) reducing beacon/t3 module production cost; (2) reducing power cost (3) total number of belt/inserters?
guess i have to do it the hard way and try to make two different blueprints and count the required beacons
Yeah investment cost is a static at least, so you can calculate payoff time
DI will almost always save inserters
I am saving wire inserters here, though I have almost double the GC machine count that I need, so I'm only saving one GC inserter. 1 out to belt 4 in, versus 4 direct, and assemblers on standby half the time
Probably different solutions are optimal for different things
if you unload into a splitter is it both output belts give 18 i/s or you need to merge both belts for it to work?
i never understood what the exact benefit unloading into splitter gives. like its faster, but whats the terms and conditions?
trying to reduce the number of steps from wagon to sushimaker by applying the knowledge so far
Thought Process: 0.25
worth of
/
works out to a rate of ||(4500/60/4 =)|| 18.75 item/second each. I think a stack inserter unloading into a blue splitter should be able to deliver within this amount, if not, I am slightly undersupplying 0.24XXX belt worth of plastic+GC which is totally fine, as 23 RC machine will not be able to consume more than that amount
I also only need to supply 950 copper plates per minute to make the necessary copper wire to fill TWO lanes (represented by splitter to two different sushi belts). Works out to about 15.8 item/second. Well doable by one stack inserter.
need 192
machines, works out to 24x8. so i need 8 sushi belts. 2 wagons, so 1 wagon can have 4 inserters. i don't really have a compact way to fit all 4 inserters-->splitter-->sushi on same side of wagon, so im thinking to use two sides of wagon instead
Also i guess i should move the splitter over here to reduce the number of blue belts. no point having so many parallel ones.
You can put it on one side or both, depending on the out belting. It's not great for UPS, but for the most part it's just one of those tricks to boost your i/s, that you shouldn't really abuse.
1 splitter > 1 inserter in UPS cost?
also isnt the right picture gonna get stuck
the left version unloads better i/s than the right, surely
Left is slightly higher but it's pretty close, and both are more
It's not 100% clear to me that splitters are worse than 2 inserters, but if you're doing something you don't need to be doing, that is worse. If you don't need the i/s, it's an additional unnecessary thing
well. the step it avoids is having 2 inserters giving me 18.75 i/s as opposed to doing the same job with 1 inserter+1splitter
i dont know which method is the most UPS-efficient to get me 18.75 i/s but i figured the less objects i use to move said 18.75 to the final belt the better. running 4 inserters to 1 full blue belt, then splitting it 4 ways and rate-limiting it like my very original approach was the rudimentary way to guarantee 18.75 i/s without jamming
my task now is to cut out all the middlemen (aka rate limiter, splitters, sushi makers etc.) and go to the source and see how i can do it with as few "steps" as possible
ultimately i just need to extract 8 proportions of 18.75 i/s from 2 wagons, without the belt jamming during input starvation or output full scenarios. not sure what other scenarios might cause issues.
Yeah, if you find yourself needing 16-18 i/s from one inserter, it's a decent tool. But if you only need 13, you don't need it
You obivously need to use both outputs.
Speed boost comes from items moving away from the inserter head quicker. It's like using a faster belt.
I'm not entirely sure where the inserter places the items. It must be in the buffer zone of the splitter, rather than its input side.
yea shortly after asking i just tested all 3 setups to see for myself by comparing the chest count after a certain amount of time
It's input side and generally it clears out
Both sides is fastest but one side is faster
this mainly goes into transport lines and how to optimise UPS with them, but there's a section that talks a bit about how splitters work.
oh, splitters only have 8 transport line segment, I thought it's 12
It's very close to the same
It has to be in the "flexible" part of the input side though, otherwise the items/s wouldn't be higher
very close is how close though ๐ค
The internal buffer on the splitter is large enough, there's a teleporty thing that happens, the items go to the out
They're both over 18
that straight belt one is only 13 i/s or so right?
cant believe the difference is so huge honestly
Didn't expect the left and middle one to be the same speed
thanks for the link, i bookmarked for now but way too over my head
Yeah it's b/c it's only 6 items, you get use of both lanes long enough
honestly the eyetest makes it look like the farther half of splitter wasnt getting utilised at all lmao
lol there's a fucker hiding in there but you can barely see him
of course when i need something like 20-25 i/s to fill a lane then it would make sense to just use actual 2 inserters to two belts instead of this splitter trick
Yeah, there's a range from 14~18 where it's useful, but that's it
for now im juuuuust straddling the line of barely enough with the splitter so i figured why not
thats as far as it goes
any more and it doesnt make sense to use this niche trick
seems like now is a good time to revisit what we learnt
why is the asteroid belt jammed? i need to loop it back?
It's not jamed, it's simple backpressure
the top splitter can not put more of the filtered item on the left (in direction of flow) output, so it cannot take in more items
Is the best way to deal with asteroid backpressure to chuck it into the void?
Feels counterintuitive, the inserter throwing will be fighting against the collectir
na, stuff that is tossed away won't be collected
depends. do you have to many chunks? more specifically, too many of the one that's blocking something? could it also be caused by a production bottleneck instead?
chuck* into the void not chunk sorry. 6am brain at work
found a small solution with some probably inefficient use of combinators
the rework certainly didnt help things
ya that was my thought
i think i implemented a rough version of that but it involves a probably inefficient amount of combinators
since i need to transmit the raw information that i have >X iron ore, or Y iron asteroid, and reduce it to -1 iron asteroid to cancel out the constant combinator that is telling it to filter FOR the iron asteroid?
or is there a better way to do this
Should need just one constant and one negator
one constant for 3 items, and 3 negators for the 3 different asteroids right?
or is there a way to condense the 3 different item negation filter settor into one?
I haven't tried it with filters yet, but you should be able to do any amount of signals with a single constant combinator and a single arithmetic combinator now
the improved circuit stuff is amazing. give me a second, I'll show you
i'll bet those that know how to use it think it's amazing. for me it's too drastic a change when i was just getting the hang of rudimentary functions
this is what im working with
that is one way to do it
btw you don't need those Accumulators. It's always "day" in space.
You could argue it's for demand spikes, but you can place more solar panels instead
Here's how you can set requests with a constant combinator and an arithmetic combinator. This also works with filters, as signals < 0 are ignored for that:
It turned out to be a bit more cumbersome for asteroid collection that it would have been for logistics requests or similar, because I wanted to stockpile some amount of iron/carbon/ice, but the filters are for asteroid chunks.
The inserters into the crushers disable when the desired iron/carbon/ice amounts are reached, resulting in asteroid chunks to be in the hub.
Constant combinator has desired amount of chunks as output on the green wire.
Arithmetic combinator does EACH green minus EACH red, output EACH
output goes to 
any asteroid chunk you want more of has a positive signal, everything else is negative
this has a bit of delay though, not sure it's optimal for this use case
this works for any situation where you want calculate required items from desired amount and current stockpile though
yea i know, its just that crushers are not active 24/7 and results in power usage spikes, and early game (im still on the first platform) those space platforms cost a ton of steel to make
2x2 accumulator beats 3x3 solar panels
the output of negativ asteroid chunk, will it lead it a positive or negative filter signal?
i.e. in your picture, -1 signal iron asteroid chunk, is the same as 0 signal? for purpose of set filter
is there a useful thread for people to discuss early game space platform ideas/strategies that isn't parroting what certain content creators say is ideal
im running a few preliminary tests right now to see the viability of space platforms as a way to generate pollution-free steel
to support my purple/yellow science, since i basically beelined rocket for TINS+Lazy bastard achievement run
im wondering at what point it becomes not so great, cost wise, to keep making more and more orbital space platforms to generate steel as opposed to mining what's on nauvis. and at some point i will start to colonise the other planets too. currently about 8 hours into game
im struggling to even do some basic math because of the randomness of the asteroids
for the purpose of filter signals, values >0 are used for the filter, values <= 0 are ignored
whether the filter is blacklist/whitelist depends on the entity
my furnaces are not running 100% of the time, so i think the 2nd image, i could reduce cost of platform even more by trimming furnaces
can the circuit signals determine whether it is a black or white list? or its entirely entity-based
If you want to reduce the cost of the platform, you can send up Copper instead of platform tiles, and make the Steel up there. That also gives you twice as many tiles per rocket, and that before any productivity buff.
the grabbers cannot do black/white filtering, no? so it's whitelist by default
for the purpose of filter signals, values >0 are used for the filter, values <= 0 are ignored
this is the same for "set recipe"
that is interesting food for thought
but how cost effective is sending copper up?
cant neglect the cost of building 1 rocket for the sake of building idk 383 platform tiles
In a single rocket, you can send up 1k Copper, which is enough to make 2 rockets worth of platform tiles.
also the first furnace will take a while to get running and establish the rest of it, i reckon
it's not free, you pay with other things than steel instead
it's slower, might need an extra rocket initially (for the ASM, possibly prod mods), ..
Prod mods for the ASM making Copper Wire would help a lot
yea its definitely not free, the calculation is a little too difficult for my calculator-addicted brain
prod1s?
yeah, doesn't get any better than that while you're setting up the platform that's supposed to make the space science needed to research module 2s
yea i just researched mod2s
but i dont know if i should take some minor hits and research automation3 for ASM3s to send into space as well
to craft that initial second space platform
ASM-III consume more power than ASM-II
together with mod2s, cause those are probably huge power drains
might need a ton of space
also how many copper plates (or wires) can you ship up in a rocket?
.
ah sorry i must have missed it alt tabbing so much between game and checking my trusty pocket calculator and discord
this happens when i removed one too many furnace ๐ฆ
i dont understand why a smaller setup with fewer furnaces could outperform the bigger platform with more furnaces ๐ค
is it because of the asteroid collector bigger surface area?
more collector area means more collection
i ran this setup for 10 hours and this one is significantly worse, at 37.5 steel per minute
now im wondering how to create a better optimised platform while minimising my cost
this isn't straightforward like mining, also is there a better place to be posting and discussing this for better visibility
i found the main #space-age and #space channel to be too full of unhelpful people
If this one is worse, then it's because it's power starved, limiting what the
can do
i checked the power graphs it wasnt power starved but more importantly iron ore starved
the furnaces were active roughly half the time which lead me to cut the fat in the former picture
also i need a better way to be signalling these inserters ๐ญ
they need to hold off unloadin the asteroid chunks unless i need iron, but i must b doing it wrong
currently i just read the cargo hub content for iron ore
but this just leads to cargo hub oversaturating with ore
but then this leads me to think i need one more furnace stack?
It has the same amount of
than the one I'm linking. When, with the same potential primary production, increasing furnaces decreases the overall output leads to actual primary production is going down, the grabbers are slowed by something.
ya indeed it has the same amount of collectors which leads to my confusion
i have to guess that is a surface area issue and not a power issue
the surface area is the same, no?
there's also inserter speed and hub being potentially overfilled, but the most likely reason is brownout
thats the part im confused about i dont know why the 37.5 blueprint is running so slow
i fastforwarded it for 10 hours though
it has many peaks and troughs
some windows of unluckiness the furnaces were completely inactive
im gonna run the reduced furnace count platform again just to make sure it wasnt a fluke
running the simulation for 10 hours smooths out any effect the RNG may have
You did run both configurations for 10 hours, right?
Or are you comparing apples and oranges?
i ran the first one for 10 hours, yes
second one, i ran for about 2.5 hours, then i ran into the clogging issue
i fixed it up with a decider combinator for now
hopefully no issues
here this is the 45 steel/min setup
it ran into bug so i needed to de-bug, then re run the test again
separate steel and chunks onto different belts
theres a bit of a lag effect when it comes to this
steel is produced slow enough to share the same belt, if i can carefully manage the rates/timing of when they get placed
saves me some marginal cost yet again to reduce the size of the platform
the grabber has an inventory, which will lead to huge hysteresis effects
whats that effect
part of designing a smooth running factory is making it react quickly to state changes
buffers slow down the reaction time
yea need a simplification of that wall of text, lol
im way too dumb to understand that
The grabber outserter enables when there's not enough chunks in the hub, placing chunks on the belt.
But it takes a while for the chunks to reach the hub, so more get placed on the belt.
This creates unstable behaviour.
Instead you always want the grabeber outserter to place chunks on the belt, and limit insertion into the hub instead. This way, the feedback is instant. No instability.
ok i can get behind that
But you have to separate the Steel from the chunks for that to work.
how about if i set the threshold to be tighter
the hub has a lot of available space
so this instability, as long as it never crosses a threshold, will be fine, correct?
it is ping ponging around roughly this mark right now
No, the instability is inherent to the design. You can reduce it with tighter paramters, but it's still there.
It may be enough to control the platform though.
i suspect i can even put more furnaces in since all collectors are full
i suppose this almost 6-8 hour testing window is sufficient to conclude i am overproducing or at least stable to produce 45 steel per minute?
it hasnt changed, much different compared to the other setup weirdly
that production graph doesn't get more stable
seems like user error in that particular "underperforming" blueprint, couldnt replicate the stats
ya it was user error ๐คฃ
no inserter for left side asteroid chunk collector
is it possible to produce copper in space?
i saw someone mention recycling but looking at the tech tree in game i dont get any
nvm found it under advanced XYZ processing instead
It's a Gleba unlock. Also reduces the Iron yield.
EACH signal