[0.16] Logistic Carts

[BlueTemplar]

Hmm, wouldn't that make LogiCarts a bit too much like AAI ?

[Anson]

One thing I have been wondering reading through the docs is if the paint and stickers thing is still the best way of doing it? Conceptually a kind of programmable RFID panel on the ground would feel better.

painted arrows and stickers are two different things. the painted arrows are the instructions, and the stickers are conditionals whether a specific cart should follow the painted arrow or ignore it (depending on its cargo, the currently loaded as well as reserved slots). if you want realism, just imagine that the stickers are like the labels on goods in reallife which have an RFID chip in/under them, and the cart checks them to determine whether to follow the arrow or ignore it.

you also say the best way to do things is not to run the paint under the belt but put things on at the beginning and the end of belts.

to save on UPS, calculations are not done every tick, but roughly only once per tile. thus changing the speed gets the cart "out of sync" with that calculated next time to check whether there is another arrow, and that is difficult to handle. if you want to speed up carts you should best let the cart drive itself onto the belt (have a "straight offroad" arrow before the belt and no arrows under the belt) and when it leaves the belt also have no arrows under the belt and maybe even 1 or 2 empty tiles or tiles with straight arrows before the next special (eg orange or blue) arrow or arrow in another direction so that it drives at normal speed and can get "in sync" again. crossing a belt should be avoided at all cost since the additional speed perpendicular to the driving direction probably will get the cart "stranded" between two tiles.

btw: for throughput two components are important: the loading/unloading speed (including the time to enter and leave the area, maybe additional rerouting to find free loading/unloading chests, etc) and the speed of transport itself. since higher speed (eg by driving on top of a belt) usually causes gaps between carts to be larger, this has almost or absolutely no influence on throughput (example: going twice as fast doubles throughput for the cart itself, but having half as many carts on a section of track halves throughput for the route. thus 2 times 0.5 results in same throughput). the only difference is that you probably will need less carts for a route and that the first carts arrive more quickly. but when you have lots of carts on the same route, throughput will not be improved by much by going faster, and thus going on belts is not really needed.

Would making every device into a "go until you get another instruction" panel solve the issues of having to use separate "stickers"?

see above: "go on" is a command, stickers are conditionals whether the command should be obeyed. having only "go ahead" commands without any stickers would make it impossible to split off some carts from a straight track when they meet conditions (like their cargo or some additionally assigned group) ((edit: unless you introduce one separate "go ahead" arrow for each possible type of cargo, increasing the number of different arrows in this mod from 1 or 2 to the number of different items in factorio, several hundred, or a lot more when using mods)). maybe the mod could get rid of green arrows and use only white/blue/orange AND stickers, but green arrows can be useful as optical markers for the user to more easily see different routes, or even be useful to stop carts during construction work or because of other problems.
i once had planned something similar to carts and was about to use some "marker posts" at the side of the road to give special orders while my carts would by default simply "go straight ahead", but that wouldn't have been easier, and instead have caused collisions with real objects, been more difficult to have conditionals, etc.

[BlueTemplar]

crossing a belt should be avoided at all cost since the additional speed perpendicular to the driving direction probably will get the cart "stranded" between two tiles.

Oh my, did that cause multiple issues when I was first adding carts to a spaghetti base !
(Also, assuming that carts could just drive "through" inserters and power poles...)

throughput will not be improved by much by going faster, and thus going on belts is not really needed.

But they are so funny when they are whooshed away by a blue belt !

[Anson]

throughput will not be improved by much by going faster, and thus going on belts is not really needed.

But they are so funny when they are whooshed away by a blue belt !

absolutely true !!!

but it's nothing more than a nice effect without influence on throughput.
what most people don't think of: the carts arrive at the start of a belt with normal speed, and THAT determines the throughput. on a belt (maybe even a MK4 or MK5 belt from some mod :-) it's nice to watch them go supersonic. but the gap behind them is as large as it takes for the next cart to arrive with normal speed at the belt and to hop on the belt. and at the end of the belt, the second cart will catch up with its high speed, and the gap is as large as before. similar to reallife car traffic or a car race, when one car follows another, the first speeds up on a straight and increases distance, the second speeds up later, but in the next curve the first slows down first and the second catches up. this "shrinks" the distance between curves, but how many cars can pass the track depends on the low speed and the low distance of cars before and after the straight.

[BlueTemplar]

Oh, right, like waves passing through different mediums ?

[dorfl]

Carts on belts brings up embarrassing memories. Spent days fiddling with the on-tick code to eke out efficiency so more frequent checks for higher speed carts wouldn't kill the UPS. Wanted speed research, highways etc.

Then a cart drove onto the end of a straight belt by accident and whizzed off, essentially for free... Duh! So fixated on one approach, didn't consider the obvious one.

[dorfl]

You say that the rationale is because you can't put filterable/programmable things under belts, but then you also say the best way to do things is not to run the paint under the belt but put things on at the beginning and the end of belts.

Those things are not connected, though I can see how you might have got the impression.

Not placing paths under belts is just about handling cart entry and exit cleanly. The code that handles travel on a belt doesn't take much into account (arrows, stickers, etc) because there's no way to stop or exit cleanly in any direction but straight ahead. Therefore it seemed best not to waste paint under belts, or have people confused about why that didn't always work nicely.

The restrictions with layering combinators and belts is built into the game engine. Certainly there may be other ways to do it I've not thought of...

[McDuff]

A few thoughts on balance etc after playing:

The paint recipes seem too complicated to me, even though I know why you wanted to do it that way, it adds a lot of cruft to an inventory that's already filled up with the various markers.

I think it would make more sense to have the "paint" instead be RFID type things, and just make them with an iron or copper plate and an electronic circuit. Having to cart around copper ores to craft things is tedious.

It would be nice to have a way to check if a cart is empty as well as if it has inventory filters set. That way if I have a long track for carts to follow, I can get them to return to a pickup location rather than do the whole loop and waste fuel.

[BlueTemplar]

Yeah, and also, on (at least 0.16.51) Seablock, while you need iron/copper ore elsewhere (for the red catalyst), there is no way to get coal for paint !

(I tricked the game by using Reverse Factory, which luckily picked up a different recipe and "disassembled" charcoal "back" to coal, not sure how long that will work...)

[McDuff]

Oh something else, something in the way the "paint" is coded means biters really really really really hate it. I had a couple of cases where the biters would swarm through my base and systematically deconstruct every Logicarts paint marker before hitting anything else.

[BlueTemplar]

They hate the way it smells?
The biters have very sensitive noses, haven't you noticed?

[Anson]

The paint recipes seem too complicated to me, even though I know why you wanted to do it that way, it adds a lot of cruft to an inventory that's already filled up with the various markers.

someone already wrote a mod that allows painting (making the arrows) for free :-)

i also would wish that mined arrows can be deconstructed so that they take up less space in the inventory. how often did i make arrows, had one too many and either spent an inventory slot for it, or had some kind of graveyard where i put down all those arrows to pick them up later when needed.

It would be nice to have a way to check if a cart is empty as well as if it has inventory filters set.

i think that's already one of the many points i wrote in a long "list of observations and suggestions" in a post somewhere above.
currently, this CAN be done with a combinator setup: constant combinator reads the contents, condition in a decider checks whether the contents is eg -500 if the cart you want to reroute has 5 slots filtered for plates, and if check is true send a L or R signal back to the constant combinator. this will cause the cart to reroute.

i have done similar quite often, eg sending red signal when the detected signal is not >0 while loading (with a green signal on opposite condition to get it going immediately instead of additionally waiting for the default timeout), or send red signal on an unloader while the count is >-500 (on carts that are supposed to unload all of their 5 reserved plate stacks), or also to reroute filled carts that go back and forth in a mining field.
but the setup is always some work and takes space which often (eg next to a miner) is not or barely available. something easier would be nice, eg easier methods to check, or a configurable timeout (maybe an additional signal) so that at least the doubled setup for red and green signals can be avoided.

Oh something else, something in the way the "paint" is coded means biters really really really really hate it. I had a couple of cases where the biters would swarm through my base and systematically deconstruct every Logicarts paint marker before hitting anything else.

that's also something i have reported. a long route to a mining field may not have turns or crossings, or else that location needs an entire outpost with protection by lasers etc (and thus also needs self-sustaining power generation, or some power connection) to protect the arrows. and since a single missing arrows messes up the whole route completely and probably sends off all carts into the far distance where they get lost, this is no small problem and makes carts unusable for long distance transports, using trains or even belts again instead of carts.

but let's see, maybe it can be exploited to keep biters busy outside of a factory and give turrets more time to kill them :-)

[Krivougolnik]

The network has two types of signal: copper and iron. How to give a cart 1 filter only iron, and a cart 2 filter only copper? How to give a filter for multiple slots? Do you still support this mod? I'm trying to make a logistics network, where each machine will not be tied to only one route, but will accept delivery requests. I have a lot of complaints that you can fix and make your mod perfect.

[Meculus]

Is there a mod that adds logistic chests that work with this but don't try to pull from the logistic network? Or could something like that be added? Or, more simply, is there a way I can make specific chests not warn me if no logistic network is present?

[Zach the Fishbowl]

Bug report: when placing a Constant Combinator next to active paint, it returns an error when a cart passes the combinator.