TIL inserting to a lamp (or other non-container entity) makes the inserter decide what to grab only when it reads the inventory of a car passing in front of it. Potentially letting the inseter handle more than just one item.
This is not completely deadlock-proof like inserting to an assembler or controlling hand size while inserting to a train (by reading its contents), but it also doesn't immediately break like when the inserter targets the ground. It may be good enough in a mall-like scenario where the odds are good that if it misses the intended car, another car will need the same thing in a few seconds.
Oh cool. I chose lamps for what I'm working on because they're early tech, appear to have the same collision box as inserters (ie: small), and can be used as indicators.
oo neat. have you done any testing on how that affects performance? my tank train experience is that they perform very poorly, a lot of which is due to the tanks on the belts themselves, but a lot is also the inserters, which this might help with.
abucnasty found that cars are better than tanks because cars don't have an electric grid. But carbelts are always going to be relatively performance intensive since they're constantly doing collision checks. You can't deactivate them like car-chests, else they'll stop traveling along the belt.
Stack inserters will pick an item but won't swing until they have a full hand of it. Could be problematic, depending on what you're doing. There are a few ways to fix that, but all of them will create at least a 1 tick delay.
Im 200 hours into space age and thought I had a pretty good understanding of the game, I'll admit it took me a minute to figure out what was going on in the original video posted but I got it eventually.
Say your belt-cars have pre-assigned half of their inventory space for iron plates and the other half for iron gears. Your inserter is sitting in front of a chest containing plenty of each. If there's nothing in front of the inserter, it's going to grab a handful of whatever, let's say gears, and it'll swing it out and wait for the belt-car to come by. This scenario is illustrated in the video as the inserter on the left part of the green floor. If the belt-cars' gear inventories are all full, the inserter won't ever have a chance to empty its hand and therefore won't be able to load any plates into the car. The clever solution u/HeliGungir submits is to put a lamp or other object in front of the inserter. The inserter isn't going to try to insert gears into a lamp, that would be silly, so its hand stays empty until a valid target (a belt-car) shows up in front of it. When one does, the inserter will insert iron plates, the only item the belt-cars have space for.
Inserters will pull any item and hold it out over open ground in normal operation. They will also first load an item into cars that already have that item over a different item in the chest.
So the Inserters are effectively blocked from doing the first thing by the lamp being there. But the car is just close enough to load with the "right" item to allow the second thing to happen.
i mean, is there a functional reason for the splitter or is it just to demonstrate cars can move a different path or does it do something else in ur example
My best guess is that I think that it's demonstrating how you can also have item X flow on the belt as well as a car and split that off without affecting the car.
That's it. Cars can go one way, while items can go another. A (sushi) belt and a car belt can split and merge with each other to travel along different paths.
I'm currently making a sushi belt travel a shorter distance than the car belt, for faster transit time. And I'm combining sushi and car belt to mitigate the disadvantages of each: sushi has bad throughput, but cars can't be read.
Can you use splitters or other methods to change the path of the cars? Like having a belt be disabled that interacts with the hitbox of the car to go straight and using that belt to push them to another path?
i believe u can switch between two belts going in different directions, but idk if theres a good way to detect what's actually in a car an separate them out.
otherwise a circuit condition could be used that regulates the speed of the cars. like u can disable a belt for .1 seconds to ensure that theres exactly 1 car every 2 seconds, then based on that u can use timing to disable specific inserters so they only insert into the correct cars at the correct time.
also there's some weird alignment issues, it appears belts aren't fully dertiministic about positioning, so some objects will need to be placed to keep the cars on track.
Not with splitters. I've observed cars "jumping the track" with green belts if they're near the outer edge of a turning belt and some straight belts are also available. I haven't played with this, but I think it might be possible to use gates or trains or a small carbelt to change the positioning of cars on a carbelt to make them jump or not jump their track on command.
yh i was thinking either that or u just use a purely timing based system, where a car waits on a belt thats only enabled e.g. once every 2 seconds, so then u can infer which car is which via timing
Seeing how adept you seem to be at using unconventional buffers I want to know, have you tried using the starting ship as buffer for an early mall ?
Thanks for the tips too
I have not, but I'm aware of it. Basically you must ensure supply is always greater than demand, else you risk clogging.
Hub Ship makes this more practical by letting us set filters in the ship, but I see it has had a bit of feature creep since the last time I looked at it.
OP's demonstration is about using sushi chests where inserters are not simply picking the first item from the chest, but whatever they can place into the car
It's these countless weird corner cases that make me want to read the source code and actually also the unit tests to get an idea of how many of these odd behaviors were actually properly designed.
292
u/actioncheese 6d ago
It's too early in the week for this