Slightly change wait 0 seconds logic

[FrodoOf9Fingers]

Instead of having a train stop then start instantly, add a close to 0 wait (1 tick) for this specific train wait condition.

WHY:

Wait condition of 0 accomplishes little in game. Inserters cannot take anything off of the train, it just stops then starts. It would be cool if the train waited for 1 tick, just long enough for inserters to grab an item off of the train (immediately after which the train moves on as the inserter starts to swing towards it's destination).

Now, this is accomplishable with circuit conditions. But I figured it'd make sense as a wait time of 0 too.

[Impatient]

IMO "Wait 0 seconds" should mean to not wait. Period. Anything longer than "not" would pollute this condition. If you would like inserters to be able to just grab one hand full, then I suggest that you make a feature request for such a condition. My 2 cents.

[daniel34]

Using a wait time of 1 second and a standard (yellow) inserter it will only grab one hand full (for only 1 item use the stack size limit), and 0 vs. 1 second wait time is not that much of a difference. Besides, you mentioned that it is already accomplishable with circuit conditions.

[FrodoOf9Fingers]

True, but it is much easier to say "0 seconds". Circuit conditions work, but they require more entities. Why would you have a wait time of 0 seconds otherwise? 1 second doesn't work, you lose 59 frames of efficiency . Additionally, it's supposed to work with stack inserters.

All in all, this is a QoL suggestion, I think it'd be nice, but as was mentioned, not necessary.

[daniel34]

Actually, what is your use-case for this?

People are (although it's rare) using the 0 second wait time to make sure that the train drives a certain route, for whatever reason. Mostly these stations don't have inserters anyway, so it wouldn't make a difference if it waits there for 0 or 1 ticks.

That said I'm not against your suggestion, I just want to know how you would benefit from it, especially since you mentioned grabbing off the train.
___________

Actually, I've tested it right now, and if you set the wait time to 0 then the inserter (fast inserter) will put in items every second time the train visits the station. It will alternate between 'pick up from the chest and swing the arm to the tracks' and 'put the item into the cargo and swing back'.

If you want to just register that a train has stopped at a station then connect the train stop to the circuit network and set it to "Read stopped train", this will output the train id (a number) for 1 tick, even if the train is set to wait there for 0 seconds.

[Zavian]

Can't you already achieve a one tick stop by using the circuit network to read train contents and setting the train wait condition to a circuit condition?

[FrodoOf9Fingers]

Actually, what is your use-case for this?

It's niche, but image tracks like this:

| | | | |
| | | | |
| | | | |
| | | | |
o o o o o ---- Furances

| | | | |
| | | | |
| | | | |
| | | | |
o o o o o ---- Furances

| | | | |
| | | | |
| | | | |
| | | | |
o o o o o ---- Furances

| | | | |
| | | | |
| | | | |
| | | | |
o o o o o ---- Furances

This pattern continues (the entire right side is devoted to rows of furnaces). The lines are tracks, the o's are train stops. Each track will have 14 stops along it (ore train carts have 2k ore, 12 inserters can work, each carries 12. So 2k / 12 / 12 = ~14 stops). The idea is to somewhat mimic CPU pipelines. It's also somewhat easier/cleaner to set up so far than a traditional "stop and wait for X seconds" setup. The main advantage is that I don't have to worry about some stations being starved so long as the trains visiting this setup are full.

[Lav]

It's possible to setup the station to read train's contents or ID, and set departure condition to

Code: Select all

Any > 0

This will force the train to stay for a tick or two, mission accomplished.

And I use zero-wait stations in combination with a disabled/enabled station for remote signaling. The train will stay on the zero-wait station for as long as the other station is disabled, and once it's enabled it will depart immediately, triggering a signal and effectively receiving 1 bit of information from a remote location along the track lines, no wire connection needed.

[Impatient]

... effectively receiving 1 bit of information from a remote location along the track lines, no wire connection needed.

smart thinking

[SuicideJunkie]

...effectively receiving 1 bit of information from a remote location along the track lines, no wire connection needed.

I shall call this quantum entrainglement!

[Jap2.0]

...effectively receiving 1 bit of information from a remote location along the track lines, no wire connection needed.

I shall call this quantum entrainglement!

Okay, now how large of a setup do we need to make this a feasable way to send large amounts of information?

[JohnyDL]

it depends on how you encode, if you use ores and plates (say 5-6 stacks of each) and load up a wagon you get 7-10 bytes of information if you can read and hold the signal from the train for decoding that could be quite a lot of things

[Jap2.0]

it depends on how you encode, if you use ores and plates (say 5-6 stacks of each) and load up a wagon you get 7-10 bytes of information if you can read and hold the signal from the train for decoding that could be quite a lot of things

I think you're misunderstanding. What he was doing was having a train waiting at a station for the next station to be enabled. Once that station was enabled, that was basically 1 bit of information sent instantaniously.

[JohnyDL]

Yup but if it's waiting somewhere it can be loaded with other data and the 1 tick that it's at the station giving that 1 bit of information can be more than just the train ID and can be the whole train's contents so can be turned into quite a lot of data relatively easily with precise loading

oh wait I got it backwards (I thought the data was flowing with the train not against the train) never mind

[Lav]

I've posted a proof of concept some time ago, but it didn't garner a lot of interest.

I'm using this trick in my current game actually - got three trains (codenamed BASE, ARMY and RAIL) and a single loading station. I build a temporary station somewhere in the world and call it "rail", a special 1-0-1 antenna train starts moving towards it and is immediately blocked by circuit-controlled lights, but in doing so, it triggers a signal that releases the actual cargo train from the depot, which moves to the loading station, refills it's inventory, and proceeds towards the newly created station. When I destroy the temporary station, the cargo train returns to depot, and the antenna train to it's waiting post.

There are some quirks in the system, and I had to improvise around inserter jamming at loading station, but it works fine. Essentially, I've got a belt&rail based logistic network covering my entire rail network. And with limited selection of deliveries.

Of course, if I built three separate loading stations, one for each cargo train, I wouldn't need wireless signaling in the first place, but the space was somewhat constrained once I got around to building it.

[tobsimon]

I kind of expected wait time zero to have the effect, that the train-stop acts like a waypoint, so that the doesn't come to a full halt at all, but drives right through it. So kind of the exact oppisite of what you are suggesting. And also a not so slight change to the current behavior.

[Impatient]

I kind of expected wait time zero to have the effect, that the train-stop acts like a waypoint, so that the doesn't come to a full halt at all, but drives right through it. So kind of the exact oppisite of what you are suggesting. And also a not so slight change to the current behavior.

the condition is "time passed = 0 seconds". imo this implies a stop, but no wait. like it is now.

though i like your idea. maybe it is worth a feature request. New condition "Waypoint": Train doesn't stop there, just drives through. Imo it is worth the feature request. After all this is something a lot of players use train stops for. Write it. You have my backing.

[daniel34]

I kind of expected wait time zero to have the effect, that the train-stop acts like a waypoint, so that the doesn't come to a full halt at all, but drives right through it. So kind of the exact oppisite of what you are suggesting. And also a not so slight change to the current behavior.

the condition is "time passed = 0 seconds". imo this implies a stop, but no wait. like it is now.

though i like your idea. maybe it is worth a feature request. New condition "Waypoint": Train doesn't stop there, just drives through. Imo it is worth the feature request. After all this is something a lot of players use train stops for. Write it. You have my backing.

I agree. Although I don't need that Waypoint functionality in any of my current factories there are most likely some players that could benefit from it. But not by replacing the current time passed = 0 condition, instead a new condition (as Impatient mentioned) should be made.

Since this is not the goal of this topic, if you want to make a suggestion for that idea please make a new topic.