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)
Code: Select all
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 .... :-)