old LTN discussion thread

[Anson]

Let me get this straight. you managed to get trains run 20 time with only 200 items from a provider with over 4k of that item in stock to a requester with a minimum delivery size of 3.5k?
My first guess would be the stop isn't seeing the whole 4k stored. If it does see the whole 4k I'll need the save for debugging.

while testing, i spent dozens of nixies to easily see amounts of ore and other data :-)
i don't have that old save, but currently the same is still happening someplace else ...

my provider station has 13695 ore waiting, and the train is only loading 875, roughly 1/20 of what is available.
from being a yellow number, you can see that the nixie is directly connected to the yellow input lamp, thus the input should also see the full amount of 13695 items (plus or minus a bit when the train got its orders and left the depot)

test1-provider.PNG (155.86 KiB) Viewed 6879 times

until i walked to the requester station, the next train was already there, delivering its 864 ore, roughly the same as the other train had loaded. the station had already 15410 ore, and request was set to min size 3.5k, and desired amount 20k. thus i would have assumed that the trains get orders for up to 4590 ore, with my current 2-wagon trains a full load of 4k or at least 3.5k

test1-requester.PNG (328.54 KiB) Viewed 6879 times

together with the first of these screenshots, i made a save. since it is a bit bigger (26MB) and i have lots of mods installed on this testworld, I'll send it via my dropbox (URL in PM), together with a modlist to be used with the ModMyFactory utility :-)
(really nice utility: just set it up, import the json of the modpack, and it downloads all required mods automatically)

[Kerboros]

Hi,

I would like to thank you for this really great mod. I love it, but...

... I would like to see 2 more signals.

The first one should act like an active provider chest. This way all items could get picked up (maybe with priority before normal stations?) for normal delivery or if a limit reached will get transported to another station with the second new signal: "Storage Station". The Storage Station would also use a signal for each allowed item to accept.

I'm currently playing with Bobs and Angels Mods including Petrochem. So I have some byproducts which is hard to transport with LTN now.

Maybe you see a way to implement this

Thank you again for this great mod.
Kerboros

[Optera]

Hi,

I would like to thank you for this really great mod. I love it, but...

... I would like to see 2 more signals.

The first one should act like an active provider chest. This way all items could get picked up (maybe with priority before normal stations?) for normal delivery or if a limit reached will get transported to another station with the second new signal: "Storage Station". The Storage Station would also use a signal for each allowed item to accept.

I'm currently playing with Bobs and Angels Mods including Petrochem. So I have some byproducts which is hard to transport with LTN now.

Maybe you see a way to implement this

Thank you again for this great mod.
Kerboros

Making the current LTN behave like active provider and storage is very simple. I've tested collecting used Air filters from outposts with the following setup.

• Set your requester to constantly request a decent sized shipment of byproduct x
• add a decider combinator between pickup storage and stop set to byproduct x > desired shipment size = everything

Note: I've set max train length to 4 on the requester and added a two L-CC-L train only for those runs. That way my normal deliveries are never touched by this.
With Bobs & Angels you will probably need more throughput than two L-CC-L can provide so experiment with bigger/more trains.

[Kerboros]

Hi,

Making the current LTN behave like active provider and storage is very simple. I've tested collecting used Air filters from outposts with the following setup.

Set your requester to constantly request a decent sized shipment of byproduct x
add a decider combinator between pickup storage and stop set to byproduct x > desired shipment size = everything

Note: I've set max train length to 4 on the requester and added a two L-CC-L train only for those runs. That way my normal deliveries are never touched by this.
With Bobs & Angels you will probably need more throughput than two L-CC-L can provide so experiment with bigger/more trains.

the idea with trains using different lengths is nice, I will test this. The decider setup I don't understand. Maybe you can share a picture?

[Optera]

Hi,
the idea with trains using different lengths is nice, I will test this. The decider setup I don't understand. Maybe you can share a picture?

This station is a bit more complex than what you might need since it's designed to request unused filters and provides used filters with priority.

2017-01-10-16-16-50-4768956.jpg (540.28 KiB) Viewed 6856 times

Decider is set to cancel used air filter signal from the green wire while they are below 200.

All arithmetic are each * -1 = each
The ones next to the inserters are to switch sign for unloading.
The 2 on top are to always report everything except used air filters. I could save one of them, but then the signal canceling out used filters when below 200 would be 2 ticks behind.

[Optera]

Updated the no longer working 0.5.1 demo map from OP with a working 0.5.6 version.

[Anson]

via PM, i got convinced that all my problems which i described in other posts, are no bugs at all and everything is working as intended, although some of my applications are difficult to do with the current intended workings.

that being said, two questions about what Optera just suggested :

• Set your requester to constantly request a decent sized shipment of byproduct x
• add a decider combinator between pickup storage and stop set to byproduct x > desired shipment size = everything

this is similar to a suggestion how to do transports without "best effort" taking effect. but:

while the threshold is not reached, everything is fine, but what will happen during the time after the threshold is reached and before a train is sent and lowers the amount below the threshold again ?
if i now understand this correctly, a first train will be sent to grab the available items and internally that amount will be reserved, but until that train arrives and lowers the amount below the threshold, the decider will still forward the current amount and thus LTN will see more items arriving at the provider station and send a second train for a low amount of additional items. depending on how often and how many more items arrive and how long it takes the first train to get the items (lowering the amount below the threshold of the decider), the decider will keep sending the numbers to the station's input and LTN maybe even sends a third or more trains to get low quantities each ...

since the providing station can't know whether a train (and with what capacity, etc) was sent, the signal can't be shut off before the train arrives and lowers the number below the threshold. to know that, the output of a station would need to make available internal data like a signal for the number of reserved items (similar to the currently available signal of what the train wants to load or unload, but the new signal already being sent when a train is scheduled and didn't arrive yet), so that the decider calculates numbers based on that corrected amount and shuts off the signal below the threshold before the first train arrives.

how can this be handled with the signals that are available in the current version to avoid getting more trains sent for low amounts? maybe the simple decider (that compares amount to a threshold) needs to be replaced by a setup with two arithmetic combinators that calculates the amount of items for full loads like this:
available amount / desired min amount (rounded down) = desired number of trains
desired number of trains * desired min amount = amount to send to the station's input

Note: I've set max train length to 4 on the requester and added a two L-CC-L train only for those runs. That way my normal deliveries are never touched by this.

nice idea to use the train length for simulating separate networks. but won't your shorter special trains go to your longer normal stations too? and in case that my normal trains are shorter, special trains no longer would go to normal stations, but the normal trains might also go to those special stations. to really separate groups of trains or stations from each other, or to have not only one but two or more types of special trains besides the normal trains (and thus using three or more different train lengths), we would need an additional signal "min train length" besides the currently existing signal for "max train length".

this new signal could also be useful to force long trains on a separate rail for refueling and waiting at a depot. without such a "min train length" signal, no big train would enter short stations (forbidden by use of low values for max length) but that long depot station could still be used and thus blocked by short trains. and thus i still would have to build all depot stations long enough to be usable by the longest train even when 99% of my trains are only short trains.

[Optera]

since the providing station can't know whether a train (and with what capacity, etc) was sent

At all times does LTN keep track of what deliveries are currently under way. How else would it be able to reserve items from providers and promise items to requesters!?
Since i'm not going down the linguistic nightmare trying to explain this simple algorithm any further with words here's an example:
Network consists of 2 L-C trains one provider, one requester only iron ore is shipped. Best Effort = TRUE.
t=0: Provider has 3200 iron, Requester has 2000 iron, on it's constant combinator is turned on with iron = -10k and minimum delivery size = 2k
t=1: Provider has 3210 iron; Requester has 2000 iron => 2k-10k= -8k, 8k> 2k therefore an 8k delivery is generated.
Train1 can deliver wagons * wagon inventory * stack size; 1 * 40 * 50 = 2000 therefore delivery is only 2k iron ore.
t=2: Provider has 3220 - 2000 (Train1 Delivery); Requester has 2000 + 2000 (Train1 Delivery) => 4k-10k=-6k>2k a 6k delivery is generated
Train2 too can only deliver 2k, but the provider currently has 1220 unreserved ore so a 1220 delivery is created
As in the example the provider gains 10 iron/tick on t3 a Train3 would try and load 10 iron ore. That's just how Best Effort works and it's not a bug.

Same Example with Best Effort = FALSE
t=2: Provider has 3220 - 2000 (Train1 Delivery); Requester has 2000 + 2000 (Train1 Delivery) => 4k-10k=-6k>2k a 6k delivery is generated
Train2 too can only deliver 2k, but the provider currently has 1220. 1220 < 2k minimum Deliver Size => no delivery is created

how can this be handled with the signals that are available in the current version to avoid getting more trains sent for low amounts?

in config.lua set use_best_effort = false

[Anson]

TL;DR: most of this post is for clarification. for a real useful method to get minsize working even while besteffort is true, read all of my last post, or skip to the last few lines of this post.

Since i'm not going down the linguistic nightmare ... here's an example:
... As in the example the provider gains 10 iron/tick on t3 a Train3 would try and load 10 iron ore.
That's just how Best Effort works and it's not a bug.

although it is no bug, this is probably the most confusing part of the mod. in another post you already had said that too, but most people (including me) probably will still underestimate and/or forget the full meaning of it :

summary (to get it into my brain and those of other people :-)

• the requester station always requests goods only when at least "min size" is missing. after one or more trains have delivered their orders, there usually will be at most the desired amount of items, unless very bad luck with numbers (almost full station and very slowly using those items) fills the station almost completely and the number of inserters and their bonus cause some minimal surplus.
• with default settings (best effort = true), min size has no effect on provider stations and they will always and immediately (check is done every 2? seconds) provide any amount that they have (even if it is a single item only). repeat: no effect of min size with unmodified mod.
• only after unzipping the mod and editing the control.lua and setting best effort to false, will the provider only send batches of at least minsize items per train.

since the providing station can't know whether a train (and with what capacity, etc) was sent

At all times does LTN keep track of what deliveries are currently under way. How else would it be able to reserve items from providers and promise items to requesters!?

of course, LTN (the mod itself) knows all the (internal) data, but to the user and to the circuit setup, only some data is available that is revealed by the station (and the reserved amount is none of that shown data). thus the mod knows how much is reserved for a train that is on its way, but the provider station doesn't know it yet before the train arrives. for the provider station to see the reserved amount, there would have to be additional signals, similar to the station outputting the desired amount from the train that is stopping to do its loading/unloading, but that would (insanely?) increase the complexity of the station by either introducing another output combinator or starting to multiplex reserved amount and train amount on the same output combinator.

how can this be handled with the signals that are available in the current version to avoid getting more trains sent for low amounts?

in config.lua set use_best_effort = false

yes, but you quoted me out of context ... i was referring to several other posts with suggestions to simulate the effect of besteffort=false without editing the mod. in those suggestions, some deciders would block signals for partial amounts from being sent to the station and thus no trains would be called for smaller amounts until that threshold is reached, and while below the threshold that method works well. but as far as i could see, the suggestions ended at this stage and didn't account for what is happening afterwards.

related posts to such suggestions

Optera in this post:
If you want only large ore trains to ignore best effort leave it true and add a decider with provided > Minimum Delivery Size = output everything between storage and input. If you use the same Minimum Delivery Size as on your ore unloading station you will have emulated best effort = false for this provider. I'm using this setup myself for my Megabase and have yet to notice an ore train below my min delivery size.

Optera in this post:
Making the current LTN behave like active provider and storage is very simple. I've tested collecting used Air filters from outposts with the following setup.

• Set your requester to constantly request a decent sized shipment of byproduct x
• add a decider combinator between pickup storage and stop set to byproduct x > desired shipment size = everything

Optera in this post:
Decider is set to cancel used air filter signal from the green wire while they are below 200.

I, Anson in this post:
while the threshold is not reached, everything is fine, but what will happen during the time after the threshold is reached and before a train is sent and lowers the amount below the threshold again ?
...
how can this be handled with the signals that are available in the current version to avoid getting more trains sent for low amounts? maybe the simple decider (that compares amount to a threshold) needs to be replaced by a setup with two arithmetic combinators that calculates the amount of items for full loads like this:
available amount / desired min amount (rounded down) = desired number of trains
desired number of trains * desired min amount = amount to send to the station's input

my above question was concerning that time after the threshold was reached, a train was already on its way, but the provider station had no info about that fact and thus still would relay the full amount to the station (including the reserved amount), thus eventually sending more trains for small amounts until a train got the items and the threshold would cut off the signals again.

i also had suggested extending those methods by replacing the simple decider by two artithmetic combinators that effectively increase the thereshold in steps of minsize, eg for minsize=1k: send no signal below 1k, send providing=1k between 1k and 1999, send providing=2k between 2k and 2999, etc. thus the station and LTN would only see multiples of minsize and never send trains for minimal amounts.
what do you think of that method ?
would there still be some problem left with minsize working while besteffort is in effect ?

(excpt for the edge case that currently also can happen on any other station: available amount is barely over twice (or a multiple of) minsize and new items are produced very slowly, 2 (or more) trains are sent to get some amount, but the number of inserters and their bonus causes to load more into each train and the last train has to wait a bit until there is enough available again)

[Optera]

for the provider station to see the reserved amount, there would have to be additional signals, similar to the station outputting the desired amount from the train that is stopping to do its loading/unloading, but that would (insanely?) increase the complexity of the station by either introducing another output combinator or starting to multiplex reserved amount and train amount on the same output combinator.

Indeed. I had an internal test version where instead of internally calculating i made the hidden constant combinator, controlling lamp colors, would output reserved items as negative and promised items as positive number. I figured having the input output seemingly random values would be even more confusing.
If there are enough players who wish for this, I could add it as optional toggle in the config.

my above question was concerning that time after the threshold was reached, a train was already on its way, but the provider station had no info about that fact and thus still would relay the full amount to the station (including the reserved amount), thus eventually sending more trains for small amounts until a train got the items and the threshold would cut off the signals again.

Now I understand what you mean.
Yes, that's the limit of "simulating" a switch turning off best effort for one station only. In such a situation it is possible to have trains going to that provider using normal best effort regardless.
The clean way of fixing that would be to output reserved items somehow. (see above)

i also had suggested extending those methods by replacing the simple decider by two artithmetic combinators that effectively increase the thereshold in steps of minsize, eg for minsize=1k: send no signal below 1k, send providing=1k between 1k and 1999, send providing=2k between 2k and 2999, etc. thus the station and LTN would only see multiples of minsize and never send trains for minimal amounts.
what do you think of that method ?
would there still be some problem left with minsize working while besteffort is in effect ?

(excpt for the edge case that currently also can happen on any other station: available amount is barely over twice (or a multiple of) minsize and new items are produced very slowly, 2 (or more) trains are sent to get some amount, but the number of inserters and their bonus causes to load more into each train and the last train has to wait a bit until there is enough available again)

Dividing by min delivery size and then multiplying by it again using the truncation to your advantage is a nice work around. I like it.
Yes, that should work. If you add the inserter overhead to the provider min delivery size it should also take care of the edge case.

[doe]

Hi

I like sound of this mod, and read through all the topic. Loaded a quick map to try create a small logistic network to understand and try get it working to no avail. Trains wont leave depot. Someone who understands all this able to check my save and let me know what i am missing / doing wrong to get it working.

Many Thank's

Logistic Trains Test.zip

(4.32 MiB) Downloaded 101 times

[Optera]

Hi

I like sound of this mod, and read through all the topic. Loaded a quick map to try create a small logistic network to understand and try get it working to no avail. Trains wont leave depot. Someone who understands all this able to check my save and let me know what i am missing / doing wrong to get it working.

Many Thank's

Logistic Trains Test.zip

Your inputs are not connected correctly, even through the wires look right.
Removing all stops, placing them by hand and manually connecting them fixed everything.

[doe]

Your inputs are not connected correctly, even through the wires look right.
Removing all stops, placing them by hand and manually connecting them fixed everything.

After abit of fiddling about, i managed to solve it.
Thank's for help Optera, appreciate it.

[Anson]

would there still be some problem left with minsize working while besteffort is in effect ?

Dividing by min delivery size and then multiplying by it again using the truncation to your advantage is a nice work around. I like it.
Yes, that should work. If you add the inserter overhead to the provider min delivery size it should also take care of the edge case.

i just set up some stations to test this method, and it was a complete mess.
not because of my divider trick, but because of how roundrobin seems to work :-(

i had guessed that for roundrobin the first delivery would be computed, then the next, then the next, etc.
but as it looked to me, this mod counts all requesting stations (all those with any negative amount on their input) no matter whether they really need more items (also including in the count all those which are missing only less than minsize items), and then tries sending equal parts of the available items to all stations, only then reducing amounts or even entirely skipping those that don't need a full share.

example: i have four requester stations A-D and one provider, minsize set to 500, and (either with the above trick, or simply by connecting a wire), i dumped 500 items at once into the providing station's chest.
expected result: one delivery of 500 to A, and the next time when there are 500 they go to B.
what really happened: four deliveries were scheduled at once, each for 125 (500/4) to each of the stations, not only causing a jam at the pickup station, but also delivering small quantities only, as before without the trick.

when i tried it again, the setup was the same, but requester station A was already full.
the result was complete chaos:
expected result after the other attempt: three deliveries of 500/3=166 to stations B-D, maybe followed by 1 or 2 small deliveries of the remaining few items.
what really happened: all my 20 trains were immediately sent to transport ever decreasing amounts of items: first 3 x 125 (the same fraction as for four stations; btw: when there are 10 stations, only one of them needing items, and 1000 items are available, is it really intended that roundrobin sends only 1000/10=100 items each time ?) which caused the last quarter to be left over. then LTN immediately tried sending those remaining 125 items, but of course not 3 x 41 or 42, but instead 3 x 31 (125/4) as before, the next three trains were sent for 8 (32/4) each, the next three for 2 (8/4) each, and then all remaining trains were sent for 0 (2/4 rounded down is zero!) each ...

if my observations and conclusions are correct, this leads to two suggestions (if those effects are not even real bugs):

most important would be the problem from the second example: don't divide the number of available items by the number of all stations and skip them later since that causes a rest to be divided similarly, then a rest of the rest, etc, sending all trains to do the huge number of small deliveries. but instead divide only by the number of stations that really need items, taking into account whether a station might require less than the number of items that is calculated (or even no items at all). and if some rest would appear, the division should not be rounded down, but done in some way that rounds up and down and leaves no surplus.

less of a bug than the other but still a bad feature, and solving this problem also makes the other problem vanish automatically: calculating an average for all stations and then delivering a fraction is no real roundrobin. calculations should be done for one station after the other, all independently of each other.

to make my divider trick work, i probably would have to compute a multiple of full train loads, eg when i have 5 requester stations and minsize 500, i would need to divide by 2500 and then multiply by 2500, so that the signal is forwarded only when each of the requesting stations can get a full trainload. but this would still cause a traffic jam (eg 5 trains at the same time) on the loader station, and it would fail again when one of those requesting stations was already full and thus LTN would try to distribute the rest too, using up all trains again.


finally i searched through all the thread and found this in the hidden (spoilered) changelog:

- provided items are split evenly among requesters with Best Effort enabled
- added round robin handling, sending a train moves the request to the bottom of order list

does this mean that you replace "round robin" by "split evenly" when best effort is true ?
with default settings (which i assume lots of users will be using when installing mods), this effectively removed round robin from the mod with the same update that introduced it ... yet another confusing aspect of "best effort", very unintuitive and unclear in the OP.
anyway, even when this is intended, the above problem with splitting available amounts into shares for all stations instead of only those that will accept items still applies to "split evenly" and should be changed so that it doesn't always send all trains because of the surplus.

to test this, i finally edited the config, and everything seems to work perfectly now,
as i would expect from the names "min delivery size", "round robin", etc

but i also found this in the config :-)

Code: Select all

-- default 18000 = 5min
delivery_timeout = 18000

-- default 18000 = 30s
stop_timeout = 18000

0.5 minutes or 5 minutes ? ... ingame, both are 18000 = 5 minutes
(or rather at 18060 = 5 minutes and 1 second since the timeout is at >18000 and the check is done once per second :-)

btw: if i need to edit the config anyway, it might be nice to have two separate timeouts for loading and unloading instead of a single stop_timeout, and i wouldn't mind either when i can set the log_level in config instead of having it only in some global.

ps: i think i found a very tiny bug: what is the correct spelling of "comparator" ?
in LTN, you write "comperator", thus either you mistyped it, or factorio is incorrect :-)

[Optera]

Round Robin really should create exactly one delivery to A then B then C asf until it's back at A. Honestly I can't remember why I added splitting items like that.

Code: Select all

-- default 18000 = 30s
stop_timeout = 18000

Yes, should be 5min not 30s. It was 1800 at one point and i didn't update the description.

ps: i think i found a very tiny bug: what is the correct spelling of "comparator" ?
in LTN, you write "comperator", thus either you mistyped it, or factorio is incorrect

Where did I make that Typo?

PS: please don't use such font colors. I'm using the white design and cant read it without selecting your text.

Update:
To fix round robin I'll have to rewrite the whole Dispatcher logic. Depending on workload I might be able to release the fixed round robin as version 0.6.0 this weekend.

[Optera]

As promised here's version 0.6.0 using pure round robin.
Requests are sorted by age per station. If a request is partially shipped the station is also sorted to the back of the queue.
Currently it's generating one delivery/update cycle. Let me know if you need more, for example when you have several depots capable of sending multiple trains in one tick.

As for Bugfixes, I finally squashed the annoying bug where circuit connections from blueprints needed a second stamping before they appear. As side effect of this fix blueprinting stops while in instant blueprint mode of Creative Mode also generates valid connections.

[Anson]

Round Robin really should create exactly one delivery to A then B then C asf until it's back at A.
To fix round robin I'll have to rewrite the whole Dispatcher logic. Depending on workload I might be able to release the fixed round robin as version 0.6.0 this weekend.

as i also wrote, round robin works perfectly, if you disable best effort.
only when best effort is true, you replace round robin by distributing equal shares.
thus you shouldn't have to rewrite everything, but only remove the check for best effort and always do round robin !?

Honestly I can't remember why I added splitting items like that.

you probably wanted to do "best effort" all the time and everywhere, not letting any station wait for its turn but giving it small shares immediately.
and it wouldn't be too bad, if you would have computed the shares after skipping stations which don't need full shares or any shares at all so that you don't have some remainder to distribute after computing the shares.

in LTN, you write "comperator", thus either you mistyped it, or factorio is incorrect :-)

Where did I make that Typo?

LTN, control.lua, lines 90 and 722

Code: Select all

090:global.LogisticTrainStops[stopID].input.get_or_create_control_behavior().circuit_condition = {condition = {comperator=">",first_signal={type="virtual",name="signal-anything"}}}

722:input.get_or_create_control_behavior().circuit_condition = {condition = {comperator=">",first_signal={type="virtual",name="signal-anything"}}}

PS: please don't use such font colors. I'm using the white design and cant read it without selecting your text.

to me, it looked really nice, clearly indicating the setup in light yellow, the expected result in light green, and the bad result in light red, everything not too much different than the default white text which isn't really white but only a very light grey on dark grey.

but the default font colors are a little strange on the forum (writing a message in dark grey on light grey), and even more so on the portal (all text in dark grey on medium grey, and only quotes on lighter background). thus i have to mark all text on the portal to read anything there :-(

[Optera]

as i also wrote, round robin works perfectly, if you disable best effort.
only when best effort is true, you replace round robin by distributing equal shares.
thus you shouldn't have to rewrite everything, but only remove the check for best effort and always do round robin !?

Round Robin did not work perfectly in 0.5.x. It kept preferring requesters by their build age, messed up calculation of item counts and sent multiple trains to the same requester while starving others.
This rewrite was mostly taking the parts that where actually working well and removing pointless item count manipulation, checks and so on.

Honestly I can't remember why I added splitting items like that.

you probably wanted to do "best effort" all the time and everywhere, not letting any station wait for its turn but giving it small shares immediately.
and it wouldn't be too bad, if you would have computed the shares after skipping stations which don't need full shares or any shares at all so that you don't have some remainder to distribute after computing the shares.

I know what I Wanted to achieve, but the way this thing was written looked like i was stoned.
That thing was part of the useless complexity my rewrite got rid of. Sadly it didn't improve UPS, but that's kind of expected as most is used for reading circuit signals and the api does not allow for a faster way than reading both red and green wire seperatly with get_circuit_network and merge the signals in lua. That's why connecting a roboport's logistic network output to a stop will increase UPS by ~0.05 per roboport.

in LTN, you write "comperator", thus either you mistyped it, or factorio is incorrect

Where did I make that Typo?

LTN, control.lua, lines 90 and 722

Code: Select all

090:global.LogisticTrainStops[stopID].input.get_or_create_control_behavior().circuit_condition = {condition = {comperator=">",first_signal={type="virtual",name="signal-anything"}}}

722:input.get_or_create_control_behavior().circuit_condition = {condition = {comperator=">",first_signal={type="virtual",name="signal-anything"}}}

those are typos in the api: http://lua-api.factorio.com/latest/LuaC ... _condition

but the default font colors are a little strange on the forum (writing a message in dark grey on light grey), and even more so on the portal (all text in dark grey on medium grey, and only quotes on lighter background). thus i have to mark all text on the portal to read anything there

Factorio forum design with grey on dark grey is terrible to read that's why i'm using the default phpbb skin.

[Anson]

>> in LTN, you write "comperator", thus either you mistyped it, or factorio is incorrect :-)
> Where did I make that Typo?

LTN, control.lua, lines 90 and 722

Code: Select all

090:global.LogisticTrainStops[stopID].input.get_or_create_control_behavior().circuit_condition = {condition = {comperator=">",first_signal={type="virtual",name="signal-anything"}}}

722:input.get_or_create_control_behavior().circuit_condition = {condition = {comperator=">",first_signal={type="virtual",name="signal-anything"}}}

those are typos in the api: http://lua-api.factorio.com/latest/LuaC ... _condition

at that linked info, i only see comparator with an a :

Code: Select all

a_behavior.circuit_condition = {condition={comparator=">",
first_signal={type="item", name="rail-chain-signal"}, constant=4}}

[Optera]

>> in LTN, you write "comperator", thus either you mistyped it, or factorio is incorrect
> Where did I make that Typo?

LTN, control.lua, lines 90 and 722

Code: Select all

090:global.LogisticTrainStops[stopID].input.get_or_create_control_behavior().circuit_condition = {condition = {comperator=">",first_signal={type="virtual",name="signal-anything"}}}

722:input.get_or_create_control_behavior().circuit_condition = {condition = {comperator=">",first_signal={type="virtual",name="signal-anything"}}}

those are typos in the api: http://lua-api.factorio.com/latest/LuaC ... _condition

at that linked info, i only see comparator with an a :

Code: Select all

a_behavior.circuit_condition = {condition={comparator=">",
first_signal={type="item", name="rail-chain-signal"}, constant=4}}

Nvm... I confused myself since it defaults to comparator = >.