Factorio Forums

I am never gonna get any sleep.....

Added flags to energy_source prototypes "render_no_network_icon" and "render_no_power_icon" to prevent rendering those icons when set.

Not sure if that affects lamps or not. I only just started delving into Factorio coding.


The thing that got me addicted to smart trains was the "train at station" signal. I got tired of my farl train getting loaded with random crap in one half and all of the fuel striped out of the loco on the other half when I stopped near a station so I put smart inserters between the loading chests and the trains to only trigger when train at station was greater than 0! problem solved. Can't live without it. Then I discovered Sigg's super awesome setup and it has snowballed from there!

Nexela wrote:I am never gonna get any sleep.....

Added flags to energy_source prototypes "render_no_network_icon" and "render_no_power_icon" to prevent rendering those icons when set.

Not sure if that affects lamps or not. I only just started delving into Factorio coding.

Thanks for looking that one up

Nexela wrote:The thing that got me addicted to smart trains was the "train at station" signal. I got tired of my farl train getting loaded with random crap in one half and all of the fuel striped out of the loco on the other half when I stopped near a station so I put smart inserters between the loading chests and the trains to only trigger when train at station was greater than 0! problem solved. Can't live without it. Then I discovered Sigg's super awesome setup and it has snowballed from there!

That's brilliant.. never thought of that lol

Edit: seems render_no_network_icon doesn't work for lamps, guess it's only for the newly added prototype. Also setting energy usage to 0 makes the no power icon appear once the lamp is connected to a network

Choumiko wrote:Currently Station # is only set when there's a train at the station, to make it output constantly i will have to add some way to tell it what to output, since the station can be on multiple lines in different positions.

OK, for me it's only useful if it's always on.

I recommend the following rules/heuristics for picking the station number to display:

1. If the station is in multiple logical lines, don't output anything or output a "-1" or maybe "-x" where "x" is the number of lines the station is in. Even if the station is in the same "position" in all of these lines, don't output anything.
2. If the station has a manual mapping, output that value.
3. Otherwise, output the station number for the (only) line that the station is in.

You could add configuration to fine-tune this, but you should not add any checkboxes or anything like that in prominent places, as that will probably create more confusion than anything (since this is an obscure feature that not many people will use).

The station number should update immediately if the train line gets updated (it rarely happens and only due to player interaction anyway).

Nexela wrote:The thing that got me addicted to smart trains was the "train at station" signal. I got tired of my farl train getting loaded with random crap in one half and all of the fuel striped out of the loco on the other half when I stopped near a station so I put smart inserters between the loading chests and the trains to only trigger when train at station was greater than 0! problem solved. Can't live without it.

I've never liked the basic train scheduling in 0.12 so SmartTrains had a lot of appeal immediately. I've never thought about protecting the train from being unloaded like you have. Maybe I should add that to my loader setups. I've had it often enough that the coal was unloaded from the locomotive or the rails from the FARL wagon.

On the other hand I usually configure my unloaders with filter settings so they'll only unload the stuff they're supposed to anyway (and the wagons have all slots filtered on my special purpose trains, so there's no problem either.

Then I discovered Sigg's super awesome setup and it has snowballed from there!

Wait until you see the latest additions, they make it even better. When the 0.13 dust has settled there will be the multi-product provider and it will all be pure awesomesauce

I'm in a situation where I get a repeating error when the train UI is open.

I guess it's easiest when I simply attach the save file. Just click the train I'm standing next to and you'll see the error.

The save file is so big because the sandbox map is too large. It's mostly empty, though.

siggboy wrote:I'm in a situation where I get a repeating error when the train UI is open.

Fixed in SmartTrains 0.4.0
Despite the nice number it's still a prerelease I don't suggest using the new features for huge clever systems yet, the behavior might change a bit.

• copy/pasting between smart trainstops pastes the settings for the lamp
• changed icons for station # and destination #
• constantly output station number if a mapping is set or the station is only on one line
• fixed error when removing invalid trains

While writing i realized i forgot a few things: The station number isn't updated immediately at the stations combinator itself when it changes. Right now it will change only if a train arrives/waits or leaves
At least i know what i'm gonna do after watching Iceland rule France (no, not Hearts of Iron )

Choumiko wrote:I don't suggest using the new features for huge clever systems yet, the behavior might change a bit.

Well, until the devs fix that rail bug nothing is happening anyway with regard to clever setups (you can't really use combinator conditions due to that bug right now). So I guess you have some time to tweak SmartTrains until it becomes relevant if it is ready for prime time or not...

Nexela wrote:

xmnovotny wrote:
Thank you for the demo, now I see, that there is some bug in my savefile (or maybe some mod collision), because for me it is not working and the train leaves station immediately even circuit condition is not met. I try hard reset Smart train, remove train from track and put it back, but nothing helps.

I am having the same problem in my save migrated from .12.35 to .13.3 I can't figure it out for the life of me! New worlds created in .13.3 the circuit conditions work fine. Hopefully I am able to figure out a fix for this or it magically gets fixed in the next factorio update My next step is possibly to remove smart trains from my 12.35 and then migrate that way and see if it fixes it.

I also have the rail/signal placing bug.

Well I managed to get circuit conditions working again. It was a migration issue with my save somewhere. I loaded up .12.35 removed as many mods as I felt safe enough doing pretty much everything but Bob's Mods and extra chests (I didn't want to port my migration script to 12.35!). Saved it and loaded in .13.4 using the base set of mods from the .12 save and it works. Re-added all my other cool mods I.E All of Choumiko's rail ones and some others and everything is hunky dory. I have to replace all my train stations but since all my stations need revamping anyway this is no big loss as this is mostly a test world anymore anyway.

I have another small bug for you.

Trains at stations don't update circuit conditions when switched from manual-auto


Just using factorio gui for this and not smart train lines
Create a train LC and schedule it to a station
While the train is waiting at the station in automatic mode add a wagon or engine to it. Train switches to manual mode
Switch the train to automatic. Train makes a slight jump forward and stops again at the station
Smart station doesn't output signals.

I have a suggestion regarding the signal condition:

Currently any signal can be used for the signal condition. The players is responsible for setting the signal condition in the schedule, and SmartTrains needs to parse the conditions so it can apply the JumpTo rule.

This is quite arbitrary and has the following problems:

• Not easy to explain/document to new users (which signal? what if there are multiple signals?)
• Impossible to handle cleanly if there's more than one condition on the train stop (you don't know which condition is relevant)
• Impossible to handle cleanly if the condition uses the "anything" or "everything" rule (you don't know which of the signals provides the station number if multiple signals match the condition)
• Not easy to use (conditions have to be set manually through the vanilla UI)

I propose the following change:

Create a new proprietary signal that needs to be used in the signal condition. You could also simply use the existing "Destination #" signal that's pulsed when the train leaves (that's probably the best option, and also very consistent and logical).

Then, the signal condition is always "Destination # > 0", and it's the signal you have to use to input the destination station (I don't know if negative station numbers are allowed by the station mapping, if they are then the generic condition would be "Destination # > -2^31", arguably not very pretty but unfortunately we don't have the "not-equals" comparison).

Since we now know the signal type, and it's a proprietary signal that's not supposed to be used anywhere else, you can set the signal condition from SmartTrains for any relevant train schedule.

If the player selects "use signal #" in the UI, you can simply update the schedule for the respective line and insert the "Destination #" generic condition for that station.

This eliminates all of the above problems.

The only problem I see is that you cannot use exotic signal conditions if SmartTrains sets them automatically. However, you could check if there's a non-standard rule set in the schedule and then simply not touch the respective stations (e.g. if the user already has something like "Destination # > 100" in the schedule then you don't set the rule "Destination # > -2^31" for this station).

Seems like a good idea to me the longer I think about it. What do you think?

In my opinion now is the the perfect time to make a change like this that is not really backward compatible; since 0.13 breaks so many setups anyway.

Quick question: can the green lamp now be freely used to indicate arbitrary conditions or is the condition still used by the mod?

(I vote for being able to use the lamp without it interfering with the station.)

Since we are speaking of lamps now; another bug, well not really a bug as it works as intended ish

The current lamp on the station is green. with .13 we cab change the color of lamps via signal network (ish.... it picks the first color signal instead of the highest number). With the ST lamp sending it a "white" signal makes the lamp light green since the default lamp color is green as of a few ST versions ago. I propose a change back to stock My feelings won't be hurt if you deny me this though Awesome job on ST!!!!

Yeah, maybe change the lamp back to white so the colors will match the colors of the stock lamp.

siggboy wrote:I have a suggestion regarding the signal condition:

Currently any signal can be used for the signal condition. The players is responsible for setting the signal condition in the schedule, and SmartTrains needs to parse the conditions so it can apply the JumpTo rule.

If i understand it right, that is not completely correct.
A quick rundown how it currently works:

• Train leaves a station (Due to time, full/empty/whatever)
• SmartTrains checks if the departure time matches the time it calculated when the train arrived (basically arrival tick + (waiting time OR 2^32-1 if no wait time is set))
• SmartTrains updates the line if necessary
• If the time matched (meaning the train leaved due to passed time), the train goes on
• If the train left the station early, SmartTrains check if jump to signal/jump to is set. If jump to signal is set, it gets the signal value from the lamp and jumps accordingly to that value

SmartTrains doesn't care/know what condition caused the train to leave (i don't think that information is available through the api)

siggboy wrote:This is quite arbitrary and has the following problems:

• Not easy to explain/document to new users (which signal? what if there are multiple signals?)
• Impossible to handle cleanly if there's more than one condition on the train stop (you don't know which condition is relevant)
• Impossible to handle cleanly if the condition uses the "anything" or "everything" rule (you don't know which of the signals provides the station number if multiple signals match the condition)
• Not easy to use (conditions have to be set manually through the vanilla UI)

• The signal set in the lamp is what counts
• Not a problem with how it currently works?
• Also not a problem if the signal from the lamp is used
• You only need to set it once, and having the "leave condition" in the schedule allows combining multiple conditions, e.g. Destination signal > 0 AND "red signal > 0", that way deactivating your system only requires setting red to 1, without having to add additional combinators. Your scheduler acts/will act on the pulsing of the destination signal i guess and if no train leaves there is no pulse so it won't get confused/messed up?

I havent checked the operator precedence of AND/OR in the schedule (is A and B or C equal to (A and B) or C or equal to A and (B or C)) but i think it could be quite powerful and even save a few combinators at each station?

For a start i'm at least going to set the signal at the lamp to be Destination # when a trainstop is built (and change it back to white).

Edit: Since i only got 2hrs of sleep last night when on call, i apologize if anything comes over in a strange way

Edit2: Quickly changed the positions of lamp/combinator: (left old, right new)

Ignoring the overlappings, i think the right one looks slightly better (as in: easier to see whether lamp or combinator are connected) Southern stop will need to have the connector sprite moved since right now it's under the combinator.

New prerelease: SmartTrains 0.4.1

commented howto for custom hotkeys

Now I am curious

Nexela wrote:

commented howto for custom hotkeys

Now I am curious

Not sure if Hotkeys make sense for SmartTrains at all, i just wanted the prototype/code somewhere

I guess right now I'm confused how this works in 0.13, especially concerning the roles of the lamp and the Vanilla circuit conditions, respectively. I hope you can clear it up for me.

What I assumed is that the "circuit condition" that is set in the schedule (like on a Vanilla 0.13 train stop) is what replaces the condition on the lamp.

I also assumed that the relevant signal is determined by looking at the condition.

What do I mean by "relevant signal"? Well, what if you set several signals simultaneously (on the lamp or whatever the appropriate input is)? Let's say I set "red 1" and "green 3" on the lamp, will it then send the train to station #1 or station #3? I have never tried this but I always assumed that you need to set a condition (on the lamp) that explicitely names a single signal, and this signal is then taken.

But what if you set the condition "anything > 0" on the lamp and then input multiple signals? Are the signals then ignored, because the "anything" condition does not tell you what signal is relevant?

Now, if I understand you correctly, the "leave" condition would be taken from the Vanilla schedule, but the "jumpTo" value would be taken from the lamp. Is that the reason why you did connect lamp and station at first when putting down a station?

Is the lamp condition copied into the Vanilla schedule when the line is updated?

Some of my assumptions are because you talked about removing the lamp entirely, so I thought it's now only there for decoration/as an indicator, and the Vanilla condition is what counts.

So I hope I'm making sense and you can explain this to me.

Right now I feel it's a little confusing and complex, maybe it needs to be simplified. That was actually the thought behind my proposal.

[*]If the train left the station early, SmartTrains check if jump to signal/jump to is set. If jump to signal is set, it gets the signal value from the lamp and jumps accordingly to that value

Yes, but what if there is not a single "signal value" on the lamp, but there are multiple signal values. What value does it take, then? I assumed it needs the condition then to filter the value of interest, but that wouldn't be possible if the condition uses "anything" or "everything".

• The signal set in the lamp is what counts

See above, how do we resolve multiple values on the lamp?

[*]You only need to set it once, and having the "leave condition" in the schedule allows combining multiple conditions, e.g. Destination signal > 0 AND "red signal > 0", that way deactivating your system only requires setting red to 1, without having to add additional combinators. Your scheduler acts/will act on the pulsing of the destination signal i guess and if no train leaves there is no pulse so it won't get confused/messed up?[/list]

I havent checked the operator precedence of AND/OR in the schedule (is A and B or C equal to (A and B) or C or equal to A and (B or C)) but i think it could be quite powerful and even save a few combinators at each station?

I'm still confused if and why I need the destination signal in the schedule. If the destination signal is taken from the lamp it wouldn't have to be in the schedule, or would it?

For the scheduler this is not really a problem, as long as I have a way to know when the train has left the station and as long as I can rely on the correct signal number being used for the jumpTo we're all set.

I'm just terribly confused about the station vs. lamp situation right now.

Ignoring the overlappings, i think the right one looks slightly better (as in: easier to see whether lamp or combinator are connected) Southern stop will need to have the connector sprite moved since right now it's under the combinator.

The right one looks better and it's what I had in mind. The lamp is more prominently visible.

siggboy wrote:What I assumed is that the "circuit condition" that is set in the schedule (like on a Vanilla 0.13 train stop) is what replaces the condition on the lamp.

I also assumed that the relevant signal is determined by looking at the condition.

What do I mean by "relevant signal"? Well, what if you set several signals simultaneously (on the lamp or whatever the appropriate input is)? Let's say I set "red 1" and "green 3" on the lamp, will it then send the train to station #1 or station #3? I have never tried this but I always assumed that you need to set a condition (on the lamp) that explicitely names a single signal, and this signal is then taken.

But what if you set the condition "anything > 0" on the lamp and then input multiple signals? Are the signals then ignored, because the "anything" condition does not tell you what signal is relevant?

The signal set in the lamp determines where a train jumps to, by looking up the value of the signal. Right now SmartTrains doesn't care whether the condition is true or not, you could set it to "signal" == 2^32 and even if the signal had a value of 3 it would still jump to 3 as long as the train leaves before the calculated time.
Any condition set in the schedule determines if a train jumps at all (Train can have only "Full cargo inventory" rule set in the schedule and jump to signal would still work)

Anything/Everything will probably cause the train go to the next station, since it won't find the value of these.

siggboy wrote:Now, if I understand you correctly, the "leave" condition would be taken from the Vanilla schedule, but the "jumpTo" value would be taken from the lamp. Is that the reason why you did connect lamp and station at first when putting down a station?

Is the lamp condition copied into the Vanilla schedule when the line is updated?

Some of my assumptions are because you talked about removing the lamp entirely, so I thought it's now only there for decoration/as an indicator, and the Vanilla condition is what counts.

Yes, that'S why i connected them at first.
Right now the lamp condition is copied into the line schedule when updating from a 0.12 version of SmartTrains, but since 0.13 requires a rework of most combinator setups i guess that's not even necessary. When updating a line's schedule the lamp condition isn't copied into the schedule.

If i were to remove the lamp, SmartTrains would probably look at the first circuit condition in the schedule to determine which signal value to get.

Siggboy wrote:Yes, but what if there is not a single "signal value" on the lamp, but there are multiple signal values. What value does it take, then? I assumed it needs the condition then to filter the value of interest, but that wouldn't be possible if the condition uses "anything" or "everything".

See above, how do we resolve multiple values on the lamp?

Don't know how old SmartTrains behaved, but the new one doesn't really support anythin/everything as a condition on the lamp.

Siggboy wrote:I'm still confused if and why I need the destination signal in the schedule. If the destination signal is taken from the lamp it wouldn't have to be in the schedule, or would it?

I'm just terribly confused about the station vs. lamp situation right now.

The destination signal isn't needed in the schedule, only in the lamp to determine which signal value to get.
Maybe a picture makes it clear why i think this isn't too bad of an idea:


If a train at an iron mine isn't full after 30 seconds it goes to the next station. If it is full it goes to the station determined by the signal. The signal comes from your base and is either 1 or 2 depending on which Smelting stop currently needs iron?
It surely can be solved differently or may not make sense, but i think it's a possibilty and SmartTrains should be able to handle it. If only a condition in the schedule was checked i'm not sure it would work (depending on how "time 30s or full and signal > 0" is resolved by Factorio) Maybe we should request brackets for the schedule

Thanks, (I think) I understand it all now .

To sum things up:

• The "leave condition" is now handled by Vanilla, and not tied to the lamp condition anymore. The idea of connecting lamp and station by default was to make the tie that way.
• The lamp is still the source for the destination signal. It needs to have a condition that allows SmartTrains to select the correct signal, i.e. no wildcard conditions. The lamp signal is only used if the "leave condition" was not that the wait time has expired (same as in 0.12).
• If multiple signals are on the lamp, only the signal in the condition is considered, the others are ignored (that's how it has been all the time, also in the 0.12 version).

I agree that this is actually more flexible, because the signal source (lamp) can now be completely independent from the leave condition, and I understand what you mean when you say that leaving the lamp was probably a good idea (I think so, too).

It's also more difficult to understand . BTW when I started using SmartTrains it took me about 1 hour to figure out that you actually have to connect to the lamp and set a condition there to use the signal. It was not mentioned anywhere in the mod description (I think it still isn't).

So probably you should document the above very clearly, so others will know how to actually use this. The fact that we now have two different signal inputs (Vanilla and lamp) didn't make this exactly easier to understand than 0.12.

Here's how I used it in my scheduler in 0.12: Requesters (unload) used "empty & signal -> go to signal"; in 0.13 the "empty" will be the leave condition, and the signal will be set as before. Providers only used "signal", the leave condition was determined by the circuit (because I don't want to use "full" but only load a configurable amount); in 0.13 the leave condition will be a circuit condition, and the destination will be set separately and put on the lamp.

I guess this is fine, the only downside is that you have to go to two different places to configure a new station. The SmartTrains config needs to have the signal enabled, and then in the schedule the leave condition has to be set as well.

Choumiko wrote:If a train at an iron mine isn't full after 30 seconds it goes to the next station. If it is full it goes to the station determined by the signal. The signal comes from your base and is either 1 or 2 depending on which Smelting stop currently needs iron?
It surely can be solved differently or may not make sense, but i think it's a possibilty and SmartTrains should be able to handle it. If only a condition in the schedule was checked i'm not sure it would work (depending on how "time 30s or full and signal > 0" is resolved by Factorio) Maybe we should request brackets for the schedule

That example finally made it clear to me why you kept this funny behaviour in 0.13 (I mean the check "if leave condition was timeout, then ignore signal and proceed). In 0.12 I just assumed it was a limitation of the game, i.e. that if the time expires you can't tell the train to go to signal because it left on its own. Probably that was the reason?

So in your scenario you want to have the train take a round trip along the outposts, and when it becomes full you send it to the unload that has demand. Let me point out though that you could also do this in a circuit and then you would not have this slightly odd rule of "obey the signal UNLESS the time expired". The circuit would set the signal to "unload with most demand" if the train is full, and otherwise it would set the signal to "next station" (which is the current station number + 1, now conveniently accessible from the combinator ).

(By the way that's actually another good use case for having the "train-is-full" signal in the combinator.)

Of course your special case, which might be considered a common scenario, is handled a bit more easily like things are now -- if you have the right idea.

At the end of the day, this does not concern me, because my setup takes full control over the schedule and never sends a train to the next station in the sequence anyway (the ordering of stations is random as far as my scheduler is concerned).