Factorio Forums

nosports wrote: I did not got the electrical cart to move – need to check again, also fueling of the cart

Working on the docs for this:

https://gitlab.com/aerosuidae/logicarts ... ctric-cart
https://gitlab.com/aerosuidae/logicarts ... urner-cart

nosports wrote: I would include Akkumulator in the recipe to the electrical cart

It uses battery equipment and solar currently.

nosports wrote: Cart against tree gives combat, I just don’t know who ultimately will win, because my bot repaired the cart…..

I am ashamed to say I have already been killed by a cart while distracted

nosports wrote: It gave a chuckle last night when I noticed that I could insert 50 locos in this small single cart

Flat-pack locomotive kits, probably Much smaller that the real thing...

dorfl wrote:

nosports wrote: I did not got the electrical cart to move – need to check again, also fueling of the cart

Working on the docs for this:

https://gitlab.com/aerosuidae/logicarts ... ctric-cart
https://gitlab.com/aerosuidae/logicarts ... urner-cart

nosports wrote: I would include Akkumulator in the recipe to the electrical cart

It uses battery equipment and solar currently.

nosports wrote: Cart against tree gives combat, I just don’t know who ultimately will win, because my bot repaired the cart…..

I am ashamed to say I have already been killed by a cart while distracted

nosports wrote: It gave a chuckle last night when I noticed that I could insert 50 locos in this small single cart

Flat-pack locomotive kits, probably Much smaller that the real thing...

ahh now it works.......

I set up the construction and a test area and dabbled a little * I find the cost of the electrical too cheap because its powered without fuel
* research is also to cheap for my feeling
* speed is about just right
* i hope you will do a combat cart (like more armoured with only in cargo slot but extended Grid, it just calls for some personal defence placed in it) so then you can let them loose, or may be add a follower item so that the army of combat carts will follow you into the rampage * maybe the combat cart should stop when shooting ?
* place a paint around which the cart will circle around ever increasing the radius (but this you can blue print)

and considering the flat pack, i am pretty sure that are dried up locos which you need to add water to get it whole again

It would be a very slow rampage

Some new stuff I'm having fun with in my test city blocks base:

Flexible stops without logistics chests: https://gitlab.com/aerosuidae/logicarts ... stops-tech

Easy traffic routing without circuits: https://gitlab.com/aerosuidae/logicarts/wikis/stickers

Edit: Or an armoured kamikaze cart as a crawling bomb?

dorfl wrote:It would be a very slow rampage

Some new stuff I'm having fun with in my test city blocks base:

Edit: Or an armoured kamikaze cart as a crawling bomb?

Slow depends on POI.......
But yes some kamikaze cart loaded with explosives triggered by very first obstacle seems nice and i think it will be not overpowered if the cost is right and will explode at first obstacle, may that be a tree stone hive or so

and i found a nice use for the cart system.....

as i want to minize the infrastructure for far out small patches like this small uran ore patch which is way off from pickup-trainstation...... Top left train pick up (was beside a large ore field
lower bottom the small additional ore field
two triangles for the two carts....

in combination with barreling the sulfuric acid i made a small operation with two cart (one for the barrels to and fro, secound one for the ore)

Ore - mine: unload and get new sulfuric acid Need to travese some rails due to the long way they are take considerably long, but that is not critical, and in the end could be helped with more carts
some arrows are not really needed but it keeps all more checkable
the nice outshining tile is defentively the drive-offroad-till-next without this it would be just another belt...

for this way one could want more cargo-space, but i think no not really

Nice

I rearranged some stuff in the latest release that will break your layout, but those group-specific tiles can be recreated with stickers.

dorfl wrote:Nice

I rearranged some stuff in the latest release that will break your layout, but those group-specific tiles can be recreated with stickers.

certainly....
the two cart of the uran operation gone awol
had to search them
But its certainly a nice improvement... more clearly visible

This is probably a silly idea but perhaps a radar module for the equipment grid? Could reveal a small area on the map around the cart (in case radars arent in range or missing) and make it possible to load the cart up with fuel to send off in a direction to explore? I tried this earlier for fun hehe. Obviously not very useful on biter heavy maps.
What I'm describing would probably be better as a standalone mod, an 'Auto-Exploring Drone (or vehicle)' with its own sprite and may not be appropriate for this mod the more I think about it lol. May be more of an AAI type of thing.
Anyways, thanks again for this mod, its progressing nicely.

Splicer9 wrote:This is probably a silly idea but perhaps a radar module for the equipment grid? Could reveal a small area on the map around the cart (in case radars arent in range or missing) and make it possible to load the cart up with fuel to send off in a direction to explore? I tried this earlier for fun hehe. Obviously not very useful on biter heavy maps.
What I'm describing would probably be better as a standalone mod, an 'Auto-Exploring Drone (or vehicle)' with its own sprite and may not be appropriate for this mod the more I think about it lol. May be more of an AAI type of thing.
Anyways, thanks again for your this mod, its progressing nicely.

That would be something for an extra mod or modular equipment mod or something with a switch to turn on/off so you can choose if you want to have the ups draw

Splicer9 wrote:This is probably a silly idea but perhaps a radar module for the equipment grid? Could reveal a small area on the map around the cart (in case radars arent in range or missing) and make it possible to load the cart up with fuel to send off in a direction to explore? I tried this earlier for fun hehe. Obviously not very useful on biter heavy maps.
What I'm describing would probably be better as a standalone mod, an 'Auto-Exploring Drone (or vehicle)' with its own sprite and may not be appropriate for this mod the more I think about it lol. May be more of an AAI type of thing.
Anyways, thanks again for your this mod, its progressing nicely.

i tried this out also with 4 carts loaded with two personal defences (beside battery and some solars......
(see pic before)

would be fun if we had some 10 or 20 carts armoured and some personal defences heading off

I think the radar won't happen in this mod

I would love some kind of planner item that you could carry around instead of a bunch of paint squares. I'm thinking something similar to the AAI zone planning tool. So that its not free, it could use a paint charge item for every paint tile it places, and mined paint tiles would give back a paint charge. This would greatly reduce the count of the items you need to carry around.

the current version of this mod (0.1.24) has a small bug in the zip file:
besides the info.json file in the logicarts_0.1.24 directory, it has a second info.json file in the logicarts_0.1.24/templates directory. this duplicate file doesn't hurt factorio when starting and running factorio, but it messes up other programs like ModMyFactory which crash because of it :-(

prepare to get a HUGE wall of text :-)

but since i have extensively used and tested this mod for over a month now, there are lots of details, small features, missing features, some bugs (but only one of them gamebreaking, and that one can be avoided), etc.
don't take the length of this post as a bad sign since i wouldn't write so much if i wouldn't love the mod, and thus hope that it still can be improved. anyway THANKS A LOT FOR THE WORK YOU HAVE DONE UNTIL NOW !!!

I started this whole list after reading the description and wiki, continued after playing up to red+green science only, then again after getting blue science/electric carts, and finally now after cheating myself to having researched all techs and bonuses. thus the following is written from many different perspectives, as player who started a new map, as someone who wanted to replace belts/bots/trains with carts, etc, and as someone who finally used electrical carts with max bonus ...

someplace, someone had asked about fuel consumption and range of carts. I did some calculations and also tried to confirm them with a simple test route of 500 tiles (250 back and forth; btw: why does english first come back and then goes forth to the destination while german first goes to the destination before coming back "hin und zurück" :-) which should be exactly 6 minutes (1/10 of an hour) when going at 5km/h = 5000 tiles per hour (assuming that 1 meter = 1 tile). here are the results:

• walking instead of driving : 55 seconds (500/55=9.1m/s = 32.7 km/h) and using no fuel for a resulting unlimited range :-)
• cart on any ground : is shown as and should be 5 km/h and thus for 500 tiles it should be 360 seconds (shouldn't it?), but it really took 424 seconds (500/424 *3600 = 4245 tiles/h = 4.25 km/h). where is the mis-calculation? is one tile not one meter, or maybe more probably is it some rounding error when calculating the speed in the mod, causing it to be rounded down from 5.00 to 4.25 ? fuel consumption for these 500 tiles was 11.5 coal, and at 8MJ/coal this would be 92MJ/500 tiles. with stacksize 50 for coal, max distance would be around 2100-2200 tiles (thus action range would be a little more than 1 km), but watch out for driving around in waiting circles and similar which might greatly reduce the distance until the cart needs to be refueled.
• passive riding on a yellow/red/blue belt : 4:30/2:15/1:30 minutes (exact values should be 4:27/2:13/1:29) because according to the wiki, for yellow belts the calculation is: 1/32 = 0.03125 tiles per tick, 1.875 tiles/sec, 112.5 tiles/min, 6.75 km/h (and half the time for red = 13.5 km/h, and a third for blue = 20.25 km/h), and it costs no fuel (or only very little on a few paint tiles to hop on/off, change direction, etc) for a resulting almost unlimited range.
• active driving on a yellow/red/blue belt : with the added speeds of belts and the cart itself, time is reduced to 2:50/1:50/1:20 for the three belts, at the cost of some fuel consumption (5/3/2.5 coal)

and now for the list of all the other comments :

1. hint (and wrong calculation/numbers?) :
   energy consumption of electric carts: portable solar panels show that they have a max output of 10 kW (thus average for a whole ingame day is less) and electrical carts show that their energy consumption is 50 kW (while driving, not while waiting/loading). thus i had assumed that i need exactly 5 panels during daytime and around 7 or 8 solar panels to keep a cart driving all the time around the clock (7 kW average production times 7 panels ~ 50kW), but while testing i found that already THREE panels almost exactly match the max power consumption of a cart. why ?
   the overproduction during the day will be stored in a battery. as buffer for the night this needs a battery with 2.1+ MJ, but since MK1 has 20 MJ and MK2 has 100 MJ, any battery will do, and to power an electrical cart you don't only need solar panels or some other generator, but you (undocumentedly) need to have a battery anyway! during the night that surplus is almost exactly used up: the cart will only stop 3 or 4 times in the morning for only one second each when using this setup of 3 panels and 1 battery and not having stopped for at least those 3 or 4 seconds anytime during a whole ingame day (eg for loading, at a crossing or in a jam).
2. what to do against too many stacks in the inventory:
   shortly after i started the new map, i thought this: although the idea of making the items with some untinted paint and then (even in some logical pattern) additionally requiring something (copper ore for normal pathes, iron ore for conditional pathes, unloading with copper plates and loading with iron plates) is very nice, i have to agree with zzzzzig that 10-20 items and paints take up too much space in the inventory, especially when using them in early game at a time when the inventory only has a total of 60 inventory slots (heavy armor). for alternatives you might look at the AAI zone tool (as suggested by zzzzzig) or at the textplates mod. then the items still could be made "on the spot" from untinted paint and some additional items (iron/copper ore/plates are cheap and most of them are in the inventory anyway), but mining the items should give back some of the untinted paint so that everything falls back into a single stack of paint in the inventory. there is also a mod (sorry, i don't remember the name) that should be supported: it allows to revert items like hazard concrete and all kinds of asphalt roads back to one single basic concrete or asphalt by holding a stack and pressing J.
   when playing a lot longer, i saw that the items stack up to 1k each, and thus the problem is less grave. also the iron/copper needed in the inventory to craft 1k arrows "on the spot" would probably use up even more space than a few stacks of different arrows. now, i only am annoyed a bit by rarely used arrows like the bidirectional arrows where i often have 1 or 2 pieces only of 4 different kinds. but just for these 4 items, the recipe requires no other igredients anyway, and they should be mined back into 2 normal straight arrows.
3. no rotation:
   another problem i had with the pathes is that i can't rotate or move them after placing, but have to mine and place them again.
   in the meantime, i found that the arrows can easily be moved like other items when using the "picker extended" mod, and i got used to quickly mine and place with a right and a left click
4. no quickreplace:
   path tiles also can't be "quickreplaced", eg by the same tile in a different orientation, by (un)loading tiles or by conditional tiles, and instead have to be mined and placed again.
5. mining arrows under carts:
   mining path tiles becomes even more difficult since it can't be clicked when a cart (or a belt etc) is on top of it.
   this applies especially to early game when mining arrows with an iron pickaxe takes ages, and/or when an arrow has to be mined quickly between two carts that have only 1 or 1.5 tiles distance to each other.
6. problems on jammed routes (worst with fully loaded carts):
   to me, all these "mine before replacing" cases are no longer as annoying as they were at first (see the three list items above), except when carts are jammed somehow and i can't access the painted arrows easily without first removing several carts first, and this is even worse when the carts are fully loaded, and/or because mined carts don't remember their trunk's filters that have to be setup again. and in a jam, you might not be able to mine arrows quickly enough so that several queued carts need to be removed ... always have chests/cars/tanks in your inventory for temporary storage, or some more carts to place them first, move their contents, and even copy+paste their filters!
   I have no obvious easier solution, but maybe some additional functionality could help like a switch to start/stop or enable/disable carts (similar to trains being on manual/automatic), or to manually change direction of carts without picking them up first
7. rotation on pipette:
   also, the pipette tool only picks the path item, but keeps the last rotation instead of the vanilla behavior to pick an item including its rotation.
8. rotation on blueprints:
   similar happens in blueprints: pathes are not rotated along with the rotation of a blueprint and thus blueprints with pathes can only be used without rotation (or with lots of work afterwards)
9. problems with fuel path:
   the fuel path should not be an optional path. if the path might be used/blocked, it is better to queue, wait and cause a temporary jam, instead of going straight and almost certainly run out of fuel later which blocks the entire system and is much more difficult to fix. if several refueling stations are to be used, that still can be done using a single "divert if refuel needed", sending all carts to a "fuel path" where they may queue without blocking the main route and from that path use optional pathes (without need to check for fuel) to several fueling stations.
10. wiki:
    the wiki seems to be not accurate or not detailed enough in some points, eg i understood that checks and conditions are only done when a CC is next to a stop tile. but when i tried it, i could read the contents and set filters and conditions at any arrow. I like this since i can build simple small logic setups at any place, eg one logic combinator and one CC to check for fuel and redirect carts on that condition to the left or right. this is a bit more difficult than using the "fuel check tile", but can be used to check for different levels of fuel, and to send carts in different directions depending on their contents, equipment, etc.
11. yield:
    btw: also yield should get a better description in the wiki. currently it only says "used at crossings" which led me to put it in front of crossings and a single sentence on what it really does is hidden somewhere in the middle of this forum thread. I also found by experimentation that the yield sign interrupts any "go offroad" commands that the cart might have had before, and thus a new "go offroad" (or any other arrow) needs to be placed behind a yield sign to not stop carts on top of the yield and jam all directions.
12. timeout:
    having all stops with a default timeout of three seconds is nice for beginners and to quickly set something up, but on several many or (for me) even most occasions i would like different timeouts, eg when unloading into a chest of a slow assembler i would have liked longer timeouts so that the cart can stay until really no more items are used from it, and on a miner's buffer chest i would have liked a shorter timeout so that the cart won't stop forever (but go to the next chest) when every 2 seconds a new single ore drops into the chest. it IS possible to do all that myself by using combinators, but if i block carts by using a red signal, i would like to have a timeout of 0 so that i don't need to set up logic which explicitly sends a green signal as soon as the red signal is gone. maybe that could be achieved by introducing another new signal (similar to L,R,S, green and red signals) that overwrites the three-second default, eg a signal I (for inactivity) which can have values I>0 for a timeout of 1+ seconds, I=-1 for immediate timeout (0 seconds), and no signal (I=0) could use the old default of 3 seconds when no explicit I signal is set.
13. stickers and their graphic updates:
    stickers are a really nice method to add lots of conditions without needing lots of different items, and it's even possible to copy/paste the properties of stickers. too bad that the copied property (which item is set as filter) is not automatically updated but only after clicking the sticker and closing the window again with E. after using it some more, i got accustomed to this, and i found that moving a sticker (with picker extended) only moved half the graphics until the sticker is opened by clicking and then closed again with E. but as long as this properly moved the icon to the new location and updates it (and also removed the icon from its old location from before the move), i don't care. most important that the functionality works flawlessly and that by a simple click and E i can update it.
14. stickers on stop/load arrows:
    another problem i had with the stickers is that they only apply the condition to the direction of the arrow (follow the arrow or ignore it), but all other properties of the tile (eg stop, load, unload) are still observed even when the set sticker icon does not match. thus it is not possible to have a conditional stop (eg on one stop only ore is unloaded, and on the next stop only plates are loaded, or on two consecutive stops ore and coal are unloaded separately to two different chests for a burner smelter). everything can be achieved by using additional conditions with combinators, but that requires lots of additional effort and most of all also lots of additional space around that arrow (at least one CC right next to it)
15. stickers and fuel:
    maybe stickers could also be used to check for the signals F and E so that only those carts with lower values than the set F or E value will react to the tile. this could easily replace the fuel check and make it more variable, eg allowing to use the fuel check with normal or optional pathes, allow for variable amounts of fuel (depending on where the check is done, near a station or just before a cart is sent forward to an even more distant station). and together with the above suggestions it also would allow to stop a cart for refueling (when passing by a fuel depot) only when necessary instead of stopping and waiting 3 seconds to refuel as little as a single piece of coal.
    another important check would be whether the passing cart is fuel powered or electrically powered: i had an edge case where i checked for F=0 to see whether it is electric, but a coal powered cart that was running on its last piece of coal with no reserves was considered to be electric by this (maybe rounding up by adding +1 to the F value for fuel powered carts would help?). the opposite check (for E=0 instead of F=0) failed too and i got a similar problem when an electrical cart passed by during the night and paused (out of energy) for a moment on every tile
16. sticker values by wire:
    a whole new world of options would be opened if the value of stickers could be set by wire (similar to vanilla filter inserters or vanilla requester chests)
17. stickers and numbered conditions:
    stickers could make setups a lot easier if they could have a value, eg "120 iron plates" to be valid and thus redirect carts or stop them only if the cart has 120 or more iron plates, and eg "-500 copper ore" to be valid and thus redirect carts only when they have at least 500 free space for copper ore (meaning it is completely empty). this would replace setups which i use quite often, that consist of a CC next to the arrow, and one or more combinators to do the check and send signals like L/R/S.
18. stickers and multiple conditions:
    also multiple conditions might be useful: when using LOTS of carts on some kind of bus, there always need to be several arrows with stickers to check for conditions and reroute carts to a parallel "turning lane" from which they finally turn onto a new path. if stickers would allow more than one item all those arrows with stickers (and one icon on each) could be replaced with one single arrow that has a sticker with multiple items.
    having two different stickers would allow to have such multiple conditions to be either AND or OR: one type of sticker could be used if i want to send all iron ore carts and all copper ore carts and all stone ore carts to a sidetrack, while the other type of sticker could be used to separate carts which transport iron ore and stone ore from those that transport iron ore and copper ore
19. check for contents, negative and positive results:
    checking for contents of carts was my next problem: filtered slots are shown as negative numbers when empty. on the other hand, a fully loaded cart is shown as 1000 plates. thus the shown count on loading (for a cart with 10 filtered slots) first increases from -1000 to -1, followed by +1000 when all filtered slots are full. this allows for some tricks, and it allows to see a difference between 0 for "no slots filtered" and +xxx instead of 0 for "all filtered slots full", but generally it complicates the layout of my logic setups that try to find out how many more items need to be loaded. it also makes it very difficult to check for a number of loaded items when items are partially loaded into filtered and partially into unfiltered slots (counting all filtered slots as negative, except counting all filtered slots as 0 when they all are full, and then adding all loaded items as positive, adding both counts before showing them as a single number.)
20. separate results for reading contents:
    would it make sense or be helpful if the CC would either show the filtered slots (similar to what T does for setting filters) or show the number of loaded items (maybe even two different values for items in filtered and unfiltered slots). i would like to be able sending a signal to read the contents and get different answers, eg separate answers for a display of the filtered slots (either their total number or a display that could be sent to another CC which sets filters with T), a readout of the number of items in unfiltered slots, a readout of the number of items in filtered slots, and a readout of available space in filtered slots, and most of all a separate readout for the grid contents ... or some similar functionality.
    example: currently i use the following setup quite often and have to adjust the numbers every time. to check whether a cart is empty, i use a CC that reads the contents, and a comparator that checks for -500 ore or -1000 plates etc, and finally sends a red signal when the value is not reached. the type of items as well as the number have always to be adjusted, sometimes even to unknown values (when i don't know yet what some mod has set as stacksize for its items, or how some mod has changed vanilla stacksizes like wood to 400). in addition, how do i check how many batteries or solar panels a cart transports (NOT counting the items in its grid) ?
21. which stop (un)loads what?
    i recently used loading and unloading stops for mixed carts that have part of their trunk filtered and part unfiltered. one difficulty is to check how many items are in the cart (AFAIK, eg 2 empty filtered slots and 2 filled unfiltered slots of the same item type result in a count of 0 and thus are indistinguishable from a cart that has as many empty filtered slots as it has full unfiltered slots for that item type). the other difficulty is caused by me missing the exact wording of the five different loading/unloading stops where three of them load/unload only the filtered or only the unfiltered slots, but the fourth stop (collection stop) loads items first into the filtered slots but then also into the unfiltered slots. this is no bug, but it took me quite a while to notice the different wording in the description of those four stops.
22. not enough space at action tiles:
    i would wish for some improvements on placing tiles and CC: quite often i have a track of path tiles, with a chest on one side of a loading tile and a CC (to check the state of the cart and to control the cart) on an other side. this leaves only two directions to go (forward or back), but since the next cart might already have queued, it only leaves one option to go: forward. similar applies to checking for the contents of a cart and setting a direction with the LRS signals: since one direction is blocked by the CC, only two of the directions are usable for leaving the tile (LS or RS or LR). it would be nice if the CC to check a cart could be located elsewhere (diagonally of the path tile, or two tiles away from the path tile, or maybe even kind of invisible (with selection box but without collision box) on top of the path tile itself) and be connected by a wire to a path tile.
    this also would help eg when a miner puts ore in a chest in front of it: a load tile currently has the chest on one side, a miner (either this miner or the next miner) on the second, the incoming path on the third and the CC on the fourth. in which fifth (lol) direction is the cart supposed to leave this tight space ?
    (edit: i found a tricky solution to do this and thus do mining with carts instead of belts, but the space is still very tight and i can't place all combinators that i want, eg to send a green signal to cancel the timeout; maybe I'll post such ideas in the future if people are interested :-)
23. more direction signals:
    first i wanted to ask since there already are LRS signals, what about a B signal to reverse a cart and send it (B)ack to the incoming tile?
    but i now found that the situation is even more restricted and confusing: the L and R signals are relative to the direction of the arrow, while the S signal is relative to the direction of the cart itself. when the arrow (main direction) points straight ahead, S is not needed anyway, and when the arrow points left or right, S is the same as R or L. this sounds as if it would be easy: just place an arrow in one direction and use a signal to redirect to a second direction (third direction is always blocked by the CC, and fourth direction might be blocked by queued other carts) but as soon as blue or orange arrows are involved (or if you want to have a default direction, in case of brownouts etc), they have to point in a specific direction and LRS are sometimes not good enough to redirect carts to the desired second direction.
    i think and hope that it shouldn't be too hard to introduce all the missing directions (of course, the changes themselves might be a problem on migrating setups on existing maps; but no problem if doing a new version for 0.17 :-) change "relative to arrow" directions to "compass" directions NSEW since relative to arrow and compass are all fixed directions as soon as the arrow is placed down on a map, and have also all four directions available that are relative to the cart: use L and R to turn left and turn right, S to go straight (just like it is now), and introduce a new B (turn back) to reverse.
24. yield again :
    the description of the "yield" tile in the wiki is almost non-existant, and i thought it would be used in front of a crossing (like in real life where yield signs are not in the center of the crossing) to ignore the next tile and/or check for another cart on the crossing route, or even to check ahead whether the cart can leave the crossing and thus not queue up on the crossing behind another cart thus jamming everything. as i see it now, the yield tile is almost never needed at all and mostly can be replaced by "path straight offroad" on each of the incoming routes and leaving the crossing empty. maybe the following can make it more useful again ...
25. some crazy? idea about future yield functionality:
    a really good use for some "yield" functionality would be to check (and then reserve) space in front of carts, to check some tiles in front of a cart, or similar. such a functionality would improve loading and unloading stations hugely, eg when carts come in (from the west) on a lower horizontal route, are sent to the north by "optional path" tiles, cross over a second horizontal route (leading to the west) and then have their unloading station. currently i can't make it work to let the cart return south and being redirected west on the upper horizontal route since the cart first has to cross that route (using yield on the crossing) and on returning it needs an arrow at the same spot. this part of the problem currently can be solved by using the bent double-arrow, BUT the next cart will see that crossing as a free tile and redirect the next cart to follow the first so that it will queue up on the crossing, jam that loading spot and also jam the westward outgoing path. having a yield tile with this new functionality between the two horizontal routes would work like this: cart comes in from west, the optional blue arrow wants to send it north where the yield tile is. instead of checking whether that yield tile, that tile and the next tile are skipped and the tile that is really checked is the tile after the next (the station on the northern side of the upper horizontal route). when returning from that tile the cart immediately hits an arrow pointing west on the upper route (which was skipped because of the yield sign) and follows it. instead of a yield tile, maybe also a sticker could be used that has a Y signal (eg having Y=5 to skip the next 5 tiles including itself; Y=1 would result in the current behavior of yield tiles; thus one less separate tile to make and store :-)
26. some rambling about speed and throughput

    i find the current balancing quite useful, except for a few minor ideas/adjustments:
    - (fact) the throughput of a cart track is determined by two components (similar to trains): the loading/unloading time and the transport throughput.
    - (fact) in contrast to belts (see wiki), transport throughput depends on the stack size of the items, but the calculation is almost the same.
    - (fact) on a yellow belt, throughput is "number of items per tile" (32/9 = 3.55 items/tile since an item has a size of 9/32 = 0.28125 tiles) times "speed in tiles per second or minute" (1.875 tiles/sec or 112.5 tiles/min). this results in the well known throughput of 6.66 items/sec (for one lane) or 13.33 items/sec or 800 items/min (for a fully compressed twolane yellow belt). multiply that by 1/2/3 for yellow/red/blue belts, for a max of 2400 items per minute on a blue belt.
    - (fact/estimated) carts have a size of exactly one tile, but if you have a standing "compressed queue" of carts and then start it, it takes some time (depending on their speed and mostly their reaction time of around one second) until all carts are moving. when i did that i found that in such a moving queue of carts every three carts use up 10 tiles of space (on average), resulting in 3/10 = 0.3 carts/tile (10/3 tiles/cart). the speed of carts (according to popup and wiki) is 5 km/h = 83.3 tiles/min = 1.388 tiles/sec. in addition (or rather in multiplication :-) each cart has a capacity of 10 stacks (500 ore, 1000 plates, 2000 circuits). the resulting max throughput for the transport alone is 100*10*83.3*0.3*(plates/stack)*(stacks/cart)*(stacks/cart)*(carts/tile)*(tiles/min) = 25k plates per minute, roughly 10 times as much as a fully compressed blue belt and 30 times as much as a fully compressed yellow belt, but NOT including loading and unloading. therefore i think that 5 km/h might sound and look quite slow at first sight but really is a very high throughput and needs no change.
    - (my thoughts/belief) any improved speed of carts (eg by getting higher tiers of carts, or by getting a bonus from stone, concrete or asphalt roads, or by additionally driving on belts) probably will change only the time to transport a specific item from a source to a destination and cause less carts to be needed on the route, but won't change the throughput a lot since the gaps between carts will proportionately grow larger when the speed increases, since the reaction time to start moving doesn't change and is a large part of gaps and throughput.
    - (my wish) nonetheless, i find it looking very strange when the character and other vehicles move faster on roads, but carts keep their pace. this is especially valid when a cart route is next to a paved road or some belts, where yellow belts appear to be moving twice as fast and blue belts 6 times as fast as the carts although the througput of carts is just the opposite (5, 10 or 20 times as fast depending on stacksize). it's also strange to see carts on belts being accelerated a lot (appearing to move 3, 5 or 7 times faster than on a road), but not when driving on paved roads. as stated above, all this probably makes little to no difference for throughput, but it looks strange and increased speed would reduce the time and number of carts that are needed to connect distant source and destination. thus please allow for at least the usual "paved roads" bonus.
27. bug or wrong description on loading speed - first thoughts on map start:
    after talking a lot about the transport throughput (in the spoiler above), the most severe bottleneck are the loading and unloading stations. the wiki says "Carts will reverse up to chests like little delivery vans. We simulate a built-in loader, with transfer speed eqivalent to a yellow belt multiplied by current inserter capacity bonus. A basic cart can manage around 14 items/sec, climbing to 84 items/sec after fully researching inserter capacity bonus."
    my first thoughts on these numbers:
    - 84/14 = 6 ... but 14 is the base value, and there are seven levels of stack inserter bonus. thus it should be 14 (1x14) to 112 (8x14) ???
    - and the max stack bonus on level 7 is 12 for an even higher load/unload throughput ???
    - what is the base idea of calculating the loading/unloading speed? to unload fast enough for filling a yellow belt (when having no bonus yet)? and what about double and triple speed to fill red and blue belts when those techs are researched?
    - in any case, unloading with a throughput of 84 items per second (or even 112 or 168, but probably limited to one stack at a time, thus 50 for ore and 100 for plates) would take 10 seconds or at least something between 3 and 20 seconds, depending on stack size (and even when ignoring the time to enter and leave the loading area) the loading/unloading time itself would be 25000 (plates/min) / 84 (plates/second) = 298 seconds per minute, a factor of 5, thus requiring at least 5 chests in each station (per route) to keep up with loading and unloading at maximum throughput, barely achievable with the current versions of paint tiles which cause huge loading/unloading stations for a single route.
    did anybody yet discover some nice loading/unloading layouts, do i have a lot more to experiment with, or is the max transport throughput not achievable because of loading restrictions? at least it will still be a welcome challenge to improve my layouts when i get to better bonus as soon as i have researched blue science :-)
28. bug or wrong description on loading speed - after getting carts with max bonus:
    - my carts had a loading/unloading speed of 14 all the time up to the last bonus, and only 28 after getting the last bonus, far away from a constant increase during research, and far away from getting a transfer rate of 84+
    - with only 28 instead of 84 transfer speed, the ratio between loading and transporting items is even worse: 15 instead of 5, and thus at least 15 loading ports are needed for every route that should operate at max throughput. do i have an error in my calculations, or is it really intended to have such gigantic huge stations ?
29. balancing:
    overall, the balancing seems to be quite nice.
    for some special usages, additional parameters might be useful, eg when i want to replace belts with carts. then it might be quite hard to do all the necessary research (roughly 500+ red science and also some green science) until the carts become useful and belts between miners, smelters and assemblers are not missed dearly any longer.
    it also takes quite some time to research and be able to use electrical carts. when that milestone is achieved, a lot of the setups have to be changed, most notably all the forced refuel stops, checks whether carts are fueled or electric, and I'm stuck with dozens (if not hundreds) of fossil carts in some chest that i need to shoot or forget since the old carts are not reusable in any way. it would be nice to have some option to upgrade old fossil carts to new electrical carts that never need to be refueled.
30. upgrading fossil to electric carts:
    besides the above, it is a lot (and i mean really a lot) of work to setup electrical carts when they have to be placed and their grids have to be filled manually for each single cart. in addition, carts and electrical carts stack to 10, but only as long as their grids are not yet used. with items in the grids they no longer stack and each is a separate item in the inventory. thus it wouldn't be bad at all to counter that effect by allowing to have bigger stacks of (electrical) carts with empty grids (you also need to have stacks of generators, power panels, batteries, and other items). i would love to have some "garage" machine that can place newly built carts in the world and fill their grids, and also can clean up the grids of carts that no longer are needed and pick them up (recycle them into the logistic network).

just as a reminder: if i wouldn't love the mod, i wouldn't have written such a wall of text with comments.
thus take this as a big THANKS, and I'll hope that some future versions will include corrections, improvements or other ideas from this list, either soon(tm) for real problems/errors, or later (after 0.17) when quite a few things have to be changed anyway :-)


and finally a real bug, non-crashing but still breaking game logic :
when i recently sent a squad of carts on a mission to travel as far as possible (equipped with personal lasers, roboports, construction bots and repair packs) they hit on some water area and stopped. i was lucky enough to have a few landfill and placed them. now the strange behavior of the carts:
- as expected, placing landfill directly in front of the cart allowed it to proceed.
- as expected, placing landfill the tiles to one or the other side of the cars travel path didn't do anything.
- completely unexpected, placing landfill on both sides but NOT in front allowed the cart to proceed !!!
- and to check some more when carts can travel across water, i placed stripes of landfill perpendicular to the travel path and the carts could pass the water between those stripes.
have fun with the following picture documenting where carts can travel acros water :-)

ps: in case someone wants to do some other testing like i did (checking energy usage, see top of this post):

some addition to some points in my long list:

5. & 6. mining arrows under carts:
would it be possible to slightly increase the selection box of arrows, or reduce the selection box of carts ? thus it might be possible to click an arrow under a cart by clicking on the outmost pixels of it no matter whether a cart is on top of it, carts are jamming, etc.

27. & 28. bug or wrong description on loading speed:
I'm no modder or LUA programmer, but after a look at the source and the lua-api, you seem to have used different bonus values in the mod and in the description:
lua-api: inserter_stack_size_bonus :: double [Read-Write] The inserter stack size bonus for non stack inserters
using this value, you get a bonus of 0 for without research, a bonus of +1 for the tech "inserter capacity bonus 2", and a bonus of +2 for the tech "inserter capacity bonus 7".
in your code, you use: local throughput = max(1, car.force.inserter_stack_size_bonus) * 14
which results in max(1,0) without tech, max(1,1) for tech 2+, and only max(1,2) for tech 7, and thus a throughput of always 14 until tech 7 increases throughput to 28
to get a max value of 84 (as stated in your wiki), you might use:
lua-api: stack_inserter_capacity_bonus :: uint [Read-Write] Number of items that can be transferred by stack inserters
and change that line in your code (for two functions) to: local throughput = (1 + car.force.stack_inserter_capacity_bonus) * 7
since that bonus goes up to 11 (for stack inserter capacity 1+11=12), and thus multiply by 84/12=7 (instead of 14).
i also wouldn't mind having some other formula which results in a "round" value of 50, 100 or 200, eg
local throughput = 4 + 8 * (1 + car.force.stack_inserter_capacity_bonus)
this would result in a base value of 12 (without additional research), increasing in steps of 8 per tech research (for tech 1-4) or 16 per tech research (for tech 5-7), up to exactly 100 (to transfer at once two stacks of ore, or one stack of plates or half a stack of circuits)


while browsing through the source, i also remembered another thought that i had about the mod parameters:
the fuel threshold is given as percentage, the F value is given as stacksize, and the F value is given as Joules. thus the threshold varies depending on the fuel used and might be good enough for one fuel while not enough for another. similar applies to the F value which doesn't tell anything about the remaining range of the cart, in contrast to the E value of electrical carts. otoh, the E value is pretty useless since it's easy to fill the grid with enough power generators (eg 3+ solar panels or a fusion generator) to never run out of energy for driving (unless some heavy fighting, using shields, personal lasers, roboports, etc).
wouldn't it be better to add (hehe, multiply :-) the energy value of fuel to your formulas for F, so that the remaining range can easily be seen from it, or maybe even give the result as remaining range instead of remaining fuel stack size ? and similarly giving a min fuel value (= min range) in the mod options, to send a cart to the next fuel stop when its range drops below xx (joules or tiles of range) instead of when it drops below xx% of the max theoretical fuel/range for any random fuel type ?
in summary to point 15 (stickers and fuel) and the above: would it make sense to have only a display for F (a value >=0, given in joules or tiles of range) for fossil fuel, and a value of -1 or 999999999 for electrical carts ? this would allow for easy fuel checks and refueling until current range >= "some value" (that's why 999999999 or any other giant number instead of -1 might be useful for electrical carts)


and finally, i found some more small bugs/glitches ...

blueprints need to be placed twice
when a blueprint with stickers is placed, the stickers can't be put down immediately since there is no valid arrow to attach them to. only after arrows in the blueprint have been placed, the blueprint can be used a second time, and THEN the stickers will be attached to the arrows.
this is the same behavior as putting down arrows and stickers manually: stickers can only be attached to arrows and not be put down eg on empty tiles. BUT after an arrow and a sticker have been placed, the arrow can be mined and the sticker stays valid (very useful if i want to rotate the arrow or replace it with a different arrow).
thus the question: is it really necessary to limit placing stickers to attaching them to an arrow? can't it be made possible to put down a sticker anytime and anyplace? that probably should also solve the problem with blueprints since the stickers in a blueprint then can be put down before the corresponding arrow has been placed.

items at front of chests are used first
in vanilla and many mods that access chests, the last items in the chest are used first when unloading the chest. there are at least two cases where this behavior is crucial: when a chest is limited to a lower number of stacks than before, some stacks may be in the red (protected) area of the chest. in vanilla, those stacks are used first since they are towards the end of the chest and no new items will be placed there. only when that surplus in the red area is cleared, new items will be put in the chest. when logicarts takes items from a chest, you iterate through the chest from the front and take the first items that are found, thus leaving the items in the red area untouched and they will stay quite a long time, maybe even forever (unless the production of new items is too slow). the second case are the duplicating chests of the creative mode mod: they replicate the first stack all over the chest and thus the chest will always be full of that item type, unless the entire contents of the chest is transferred at the same time which is almost impossible to happen. but with the fast loading of logicarts (i noticed this after having patched the loading throughput, see above; but it should also apply to items with a small stacksize <=14 or <=28) the first stack will be removed from the chest and thus the duplicating chest no longer knows which item to duplicate.

are carts driving in reverse? :-)
the graphics of carts is nice but has big red backlights at the frontside and vertical bars and a white light at the backside. thus i always am confused when i see a stopped cart that tries to move in the direction of the red backlights ...
(btw: i love the different look of the light cones at night that are not just a simple single cone)

traffic rules ?
it would be nice to have some traffic rules at crossings and merges. currently it looks pretty random which carts go first and which carts wait (although it is deterministic as factorio requires it to be, it looks quite random). traffic lights or other means to direct traffic would also be nice, but when i tried to use walls and gates, the carts couldn't open gates (unless i was in a cart) and i only succeeded in crashing lots of carts by manually opening and closing gates since gates close even when a cart is right on top of them. similar probably also applies to train tracks where trains and their signals could be used (without the need for power and combinators) to close a gate and stop carts which arrive later, but carts are crashed when they are on top of the gate when it closes. the alternative would be to use red logistic signals to stop carts which is easy to do IF there is electricity to power the deciders that are needed. with deciders everything is possible, but it's also quite some (interesting) work, and most of all unsuited for remote locations which i don't want to connect with power poles (else i could have used trains and the usual layout of power lines along tracks)

undefined stickers act as "for everything"
when stickers are put on arrows but have been given no value (yet), imho they should match nothing and thus redirect no carts, and not match everything and reroute all carts as if there would be no sticker. this also applies when i temporarily want to remove such conditional routing. with the behavior that i had expected, i only would need to remove the item type from the sticker or even more simply turn the implicit CC off (there is an on/off switch right next to the item type!). an application where this alternate behavior would be useful: i have made blueprints of crossings where the main direction is straight ahead, and depending on cargo type several carts may be redirected to a parallel path on the left or right side which later (at the crossing) really turns left or right. to make life easier, i wanted to include stickers without values, but currently they would make all carts go to the left or right turning lane.

biters attack painted arrows
i had connected a mining outpost with logicarts, and sometime later wondered why no carts were coming back. luckily i had "accidentally" found that i could ride carts as a passenger (just stand next to them and press enter), put down a new cart at my unloading station and enjoyed the ride ... until i came to a bend where biters had deleted some painted arrows and all carts from the mining outpost had continued driving in straight lines in different directions :-(
it would be nice if biters wouldn't attack painted markers so that i can use logicarts to connect distant outposts without the need to connect everything with power poles and protect all crossings and turning points (bending routes, pathes through cliffs and around water, etc) by setting up mini-outposts with turrets at each such location.

here is a screenshot of such a crossing and the blueprint for it which i did in a train-less, bot-less and almost belt-less rail world :-)
(deadlock should almost be impossible: 4 carts would be needed, each from a different direction, all turning left, and with very specific timing; else even 15+ carts shouldn't be able to block the crossing forever since there is enough space to wait in turning lanes) is anybody interested in more screenshots and blueprints, eg of my attempts to build a beltless mining site, and some tileable ore-unloading station (carts to belts) with N*4 unloading buffer chests and waiting area? i also would like to see some such inventions by other people .... :-)

after having posted already two "walls of text", this one will be shorter :-)

symmetrical straight double-paths are not symmetrical
the green and white straight double-paths look symmetrical and for driving along the direction of the arrows or opposite to it, it is symmetrical, but when hitting such a double-arrow from the side, it behaves differently depending on its rotation: when such a tile directs carts north or east and such a tile is rotated by 180 degrees (of course you can't rotate it, but it's that effect: just place a double arrow, then press R twice and place it again, then compare the preferred direction of those two tiles) that second rotated version of the arrow will send carts to the south or west instead of north or east.
i like that behavior, allowing to have a preferred direction for hitting the arrows from the side, but the graphics should be modified slightly so that it's possible to see which direction is the preferred direction. just a little dot at the tip of the arrow (in the preferred direction) would already be good enough. without knowing that there is such a difference in behavior and without being able to see the rotation, it can become quite confusing.

unloading behavior doesn't match description
the description says "Cart will unload unfiltered trunk slots to the adjacent chest."
when i tried to use that behavior for some tricks (to unload only some stacks, etc; example see below) i found that the mod behaves a bit differently: it checks whether there are unfiltered slots, then checks which item types are in those slots, and finally unloads ALL items of that type from the ENTIRE cart, from unfiltered slots as well as from filtered slots!
I don't know whether it's possible to unload specific slots only, but either the description or (preferably) the behavior should be changed to match each other.

example for loading : have a CC with signals Tc ("T" and "copper ore") and load with a stop-load tile, advance to the next miner and change the filters with Tcc thus loading the second stack at the next miner. by doing this 10 times, an entire cart can be loaded from 10 miners, one stack from each and thus not blocking the path for other carts or similar unwanted effects. this works fine (at least as long as all miners are still mining something and none is depleted yet). example for unloading : i wanted to do similar to unload 10 stacks to 10 chests by setting filters to Txxxxxxxxx ("T" and 9 dummy filters) before the first chest and unloading only the one unfiltered slot with a stop-dump tile (then Txxxxxxxx to unload the last two unfiltered slots into the second chest, etc). but instead of unloading only that one stack in the first chest, the mod saw that there is unfiltered copper in the cart (in the last slot) and removed ALL copper from ALL unfiltered and ALL filtered slots too. this was the behavior i mentioned in the previous paragraph.
i would be able to achieve similar by using one CC and several combinators, but they need some power supply and they use up more space than is available in a mining field or between assemblers and their beacons (most difficult to place all of this on only 7 tiles, and impossible to place a chest, the CC, an incoming path, an exiting path, maybe an inserter (total of 5+ tiles) next to the unloading tile). in the screenshot you can see that there is not even enough space for a CC next to the stop tile, which would be needed to read the status of the loading cart and send red or green stop+go signals to it.

Hi, we're having a lot of fun with your carts : But we recently had our server crash when a player tried to do this : It seems that the issue comes from a typo in control.lua on line 1600 : I could do the 3rd screenshot without any problem after fixing it. (Though I didn't try to replicate the crash myself.)
EDIT : typo above with [game.tick] twice.

Last, but not least, have you considered making LogiCarts be even more go-anywhere than belts by making it so that, like the player, they can run through rows of belts/power poles/lamps/etc. ?
(Looks like Collision Masks might be a solution...)
Also, what is the point of "Yield"-painted tiles if the LogiCarts already do that well by themselves?

thanks for updating the mod to 0.1.26 which fixes three of the four or five most important problems/bugs. when will you release that version?
i read about those fixes only in the changelog on github and the current version is only shown as 0.1.25 on the mod portal (which did only a RU translation).
could you please add the changelog in a way that the mod portal can show it on a changelog tab so it's easier to see what was changed?

somewhere above i had written a long "wall of text" listing many things that i had noticed, many only hints or less important "features", the most important ones being fixed in 0.1.26, but since quite a few seem to still be in the current (or rather next) version and i consider them quite important to fix (one or two BUGs, and to make the mod better usable and/or to match the description how it works) here is a shortened list of the most important points from those previous posts with only some shortened details for each:
the problem at 27+28 is caused by a bug: you use the wrong bonus of inserters instead of stack inserters at two locations of the code. instead of
local throughput = max(1, car.force.inserter_stack_size_bonus) * 14
which results in only max(1,0)*14=14, max(1,1)*14=14 and max(1,2)*14=28 it should be
local throughput = (1 + car.force.stack_inserter_capacity_bonus) * 7
to get up to 84, and to get some "round" max value of 50, 100 or 200, the formula could be something like
local throughput = 4 + 8 * (1 + car.force.stack_inserter_capacity_bonus)
local throughput = 12 + 8 * car.force.stack_inserter_capacity_bonus


ps @BlueTemplar: yes, Yield is not needed most of the time when carts follow white arrows anyway, but if there is an arrow right in front of the crossing (eg with a constant combinator to send it to another route, or a blue or orange arrow, the cart would stop (or at least not continue straight across the crossing) without having passed across another white arrow first. thus Yield signs on a crossing (with a white arrow directly behind the crossing) can sometimes (but rarely) be useful or needed to make a setup more compact.

@Anson, thanks for the summary. Must admit I havn't been through all your points in detail yet, but will do.

Currently waiting for 0.17 to drop and distracted tweaking a new mod on the side Will see how the current logicarts feature set fares or breaks in 0.17, then look at improvements.

Will be downloading this mod once it's upgraded to 0.17

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.

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.

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