Friday Facts #279 - Train GUI & Modern Spitter

[Pi-C]

A second functionality would be to have a what I call a way point train station. I.e. a train station that the train has to pass, but not stop at?

[snip]

The reason for that, is when a train is scheduled to leave a station, the Factorio determines the course to the next station. Once the train hits a way station, it will recalculate the path to the next station. In this example the way station is set up between the holding area and the unloading area, so once the train passes the way station, it will figure out to which one of the identically named unloading stations sent the train to. Without the way station, the I may have the all 3 trains attempting to head to the same unloading station at the same time. With a way station, all three trains hit the way station, and then each will be directed to the first available unloading station.

Currently, what happens, is the train comes to a complete stop at the way station, picks the next station proceeds to it. Ideally in this case, the train should not slow down at all at the station, but just pass the station routed to the next destination.

I see a solution to a problem I had in my major previous game. Inspired by Aavak's series (parts 6-9; unfortunately, the series has been abandoned right at the point where the really interesting stuff should have been explained),I tried to build a smart rail system where all stations have the same name and trains are routed based on type (fluid or solid cargo) or wagon content. Before branches, I used routing stations that check whether a train of the current's train type/cargo is needed at any station behind that branch-off and set the signals accordingly.

Now, train path finding apparently prefers the closest station, even if the way to it is blocked by a signal. So sometimes there would be a train blocking the routing station because the next station it was supposed to go to (behind the branch-off) was considerably further away than the next station on the main track (which was blocked by a signal). My solution was to put a "way point station" just a train length behind the branch: Trains (going from stop to stop based on the same conditions -- "circuit signal Green > 0" AND "1 second of inactivity") would stop at the way points where they'd get the green signal immediately, but still would have to wait for 1s before moving on. So, having a way point station that would just yell "COME HERE!" at a train without slowing it down would be killer! Seeing that such a station might also be useful (enforcing recalculation of the path) in more conventional railway systems, I really do hope that it will be added at some point.

[SuperSandro2000]

I like the new biters.
Still cliffs are useless piece of shit that only annoy you.

[cpy]

Yeah cliffs were requested but, they don't seem to create height map only random stuff. You can turn them off right?

[<NO_NAME>]

I like the new biters.
Still cliffs are useless piece of shit that only annoy you.

Cliffs are great! They are basically walls that cannot be destroyed by enemy. I love incorporating them into my factory's defense.

[Raphaello]

This has already been mentioned, in this thread and others, but if the Train GUI looked like this in 0.17, I would be very, very happy. (This is a mockup for Conditional Goto Orders, ala OpenTTD.)

conditional-goto.png

Of course, I'm already going to be happy. But this would be even better.

Also, the new biters look amazing!

Automatic refuelling option would be great! I'd suggest to make it simpler: one small line on the bottom of train GUI (maybe enabled by a tech) that would say 'auto refuel', allow to enter refuelling station name and field with MJ value. The train would then go to refuelling station once it detects that it only has set amount of MJ value left.
This is simple and does not clutter the GUI.

EDIT: Also, some visual hint to show AND/OR groupping is a must IMO.

[kovarex]

This FFF hints at, but does not really explicitly confirm or deny, a thing I have wanted for a long time:

Condition combination control; that is, currently with AND and OR, your ability to control is somewhat limited if you want them combined in complex ways. For example, there is no way to achieve condition (A & (B | C) & D) | (E & F) | G.

Will that ever be a feature, with 0.17 or ever?

It is, your condition can be decomposed to:

A & B & D | A & C & D | E & F | G.

No need for brackets. (I know it is not perfect, but considering how much of an edge case this is, it is good enough.

[kovarex]

I love the new train GUI and I hate it.
It looks much better and the drag & drop and visual progress indicator will both be super useful.
However, the "and" and "or" operations are confusing as ever. I think they are supposed to be parsed from top to bottom without any precedence rules but even knowing that doesn't really help to parse it mentally. Wasn't the new train GUI supposed to introduce some kind of braces?

I won't write much about train skipping conditions because anyone who is interested already knows that this is one of the most popular requests.

Train conditions follow some weird-o rehash on RPN, which looks and feels horrendous. I think even biters could do better and implement normal-looking compound conditions interface.

For example — full-featured RPN would look less confusing at least for some (engineering/scientific) audience.
Another way to implement — make it look like infix notation that spreads across multiple lines, although it's not nearly as powerful without grouping operator.

On the side note - nice work, as always, interface might need some small changes still, but, nonetheless, it looks way better than before. Love changes to biters, looking forward to meeting them in 0.17!


RPN style exapmle — Isn't it beautiful?

I'm sorry but I consider RPN to be very obscure and weird notation that almost no one uses.

[theolderbeholder]

I'm sorry but I consider RPN to be very obscure and weird notation that almost no one uses.

^^^^^^
This.
So.
very.
much.
I mean, my father in law insists on its superiority, but... parents in law.

[Jazoboz]

Would be kinda cool if worms were to work more as flamethrower turret

[Cobaltur]

This FFF hints at, but does not really explicitly confirm or deny, a thing I have wanted for a long time:

Condition combination control; that is, currently with AND and OR, your ability to control is somewhat limited if you want them combined in complex ways. For example, there is no way to achieve condition (A & (B | C) & D) | (E & F) | G.

Will that ever be a feature, with 0.17 or ever?

It is, your condition can be decomposed to:

A & B & D | A & C & D | E & F | G.

No need for brackets. (I know it is not perfect, but considering how much of an edge case this is, it is good enough.

So please visualize also in this way.
Make not a single indention that can be misunderstood

Proposal : Please use first indention for OR groups and a 2nd indention for AND inside a OR group

see attachment

[Philip017]

i rarely use complex signaling, however when i need it i use the circuit network to define them.
with the ability to read the train's contents, unique train identifying numbers, wagon filtering, with circuit control of inserters and logistics system, i can have just about any condition i want.

it would be great to have the scheduling be adaptive based on it's fuel level.
- i really do like the idea of fuel level at a glance instead of a separate tab for fuel. - could devs please consider this idea.
till then i have to have fuel at, at least one of the stations, in that train's schedule. and i have to have special trains just for fuel to visit every hub that is specialized, ex smelting depots.

not sure i like the new spitter predictive mechanics, but hopefully it doesn't cause much lag. i remember when the acid would home in on me - MINUTES! after i ran by that worm! because i had lots of exos and the acid followed you forever. but the new method seems like it is going to be more deadly / challenging to avoid. but as long as turret creep is still possible, i will deal with it. once i have robots and lasers i let them do the dirty work.

[Nova]

@Cobaltur: Thta's a great idea. Mister kovarex, can we get something like that, please?

(I also really like how kovarex basically wrote exactly what I did. )

And yes, fuel please in the main tab. I think the fuel field is small enough to fit right there.

[ThaPear]

I love the new train GUI, it looks much better! I agree with the point made above that the fuel information can be integrated into the main view though, since it's very tiny and always feels like a chore to navigate to just to check how much fuel my train has left.

The combat should become a lot more interesting with the new non-homing acid blobs, thank you for that!

However...

I feel that the worms look quite bland. There's large areas with little contrast. While the new sprites are undoubtedly higher resolution, they look like they are lower resolution which are upscaled and blurred.
Their animation looks a bit jagged, with quite clear transfers between animations and a lack of smooth movements.

The new nests are a HUGE step backwards. They look much flatter and blurrier than the old nests.
Especially with the high res biter next to it in the image below, they look so much blurrier.


Something that both the new nests and the new worms share is that they feel like they're they're stickers that have been pasted on the terrain. They don't look like they're part of the terrain.

[phi1010]

Here's an idea: If the condition is set to Item Count = X, and current count is greater than X, have the entire bar be green, but overlayed on top of that is a yellow bar that fills in from the side. The width thereof could be ([(]currentCount - X[)] / X) or something like that. If currentCount is more than twice X, another red bar could be displayed.
Either that, or the progress bar has a marker in the middle, and if currentCount = X, the green bar reaches exactly to the marker.

For ItemCount < or <= X, a one-colored hyperbolic bar still filling from the left (1-current/goal) might also work -- it will not be linear and not start at zero, but the inactivity bar also does jump a bit around.

e.g:

Start: 5000, Goal: <= 1000

Code: Select all

5000: [XXXX________________]
4000: [XXXXX_______________]
3000: [XXXXXXX_____________]
2000: [XXXXXXXXXX__________]
1000: [XXXXXXXXXXXXXXXXXXXX]

I think for Count = X using one single green bar -- using either the hyperbolic function for values larger than the goal, or the linar proportion function for values smaller than the goal -- might also be intuitive enough, since a half full bar shows that we are off by the Factor 2, either on 50% or 200% of the desired level.

[Avezo]

I hope that flamethrower turrets will get this prediction algorithm too. As I see the logic is basically the same, a stream of [acid / flammable oil] is shot in "mortar style" (to a position rather than at an object) and a pool of [acid / burning oil] remains at that position. It just has different effects, damage and damage type.a

I hope so aswell, due to poor flamethrower turret aim I rarely ever use them, easier just to add more lasers instead of building all kinds of perimeter to slow down biters so turret can aim properly.

[Amarula]

One technique I found very useful is for my administrative trains, once that either I ride to have a train station named "Come to me" defined in the train's schedule. This way if I am out away from the base, I can always run up to a train track, drop a station, and name it "Come to me" and select one of my administrative and send send it to me, pick what ever I need from the train, and send it back to it's default location. Once the administrative train has left the station, I pick up the train station and continue on.

Hiladdar

I always learn something new when I come to the forums, and this is simply brilliant! Thank you Hiladdar!

The updates to the train GUI look good. As others have pointed out, not perfect so still room for improvement, but getting better all the time.
<more cheers from the crowd 'come on 0.17, come on! you can do it!>

[RobertTerwilliger]

The problem with predictive aiming is target just has to zigzag a bit: say, moving right, you constantly press up-down-up-down-... and every single projectile will land lower or higher than your actual trajectory.
The only solution is adding less convenient AoE: spray acid beam in short lines, or make additional lesser puddles of acid around main one, to create more kind of barriers for dodging.

[steinio]

The problem with predictive aiming is target just has to zigzag a bit: say, moving right, you constantly press up-down-up-down-... and every single projectile will land lower or higher than your actual trajectory.
The only solution is adding less convenient AoE: spray acid beam in short lines, or make additional lesser puddles of acid around main one, to create more kind of barriers for dodging.

Are you a spitter? Your arguments sound so...

[Nova]

The problem with predictive aiming is target just has to zigzag a bit: say, moving right, you constantly press up-down-up-down-... and every single projectile will land lower or higher than your actual trajectory.

Spitters / worms (or just worms, to make them more dangerous) could save the player movement of the last second and calculate an estimated place on acid arrival from this. Maybe they could for 50% of shots use this place and for the other the "normal" predictive targeting is used. This would make the attack more random and harder to dodge.
The question is: how needed is that? The spawner constantly spawn new spitters and biters, other worms shoot at you, you have to be careful not to get stuck... only playtesting can show us how hard it is now to dodge these shots.
Another thing is: do we even want to make it harder to dodge? Fighting in Factorio is more or less some side activity. Maybe it should be fully dodgeable with some skill.

[Sad_Brother]

I hope that flamethrower turrets will get this prediction algorithm too. As I see the logic is basically the same, a stream of [acid / flammable oil] is shot in "mortar style" (to a position rather than at an object) and a pool of [acid / burning oil] remains at that position. It just has different effects, damage and damage type.a

I hope so aswell, due to poor flamethrower turret aim I rarely ever use them, easier just to add more lasers instead of building all kinds of perimeter to slow down biters so turret can aim properly.

I hope they would not.
Worms and Spitters have one priority target (Player) to hit. Flamethrower turret put burning puddle on the way so mass attack can be weakened.
What would do your Flamethrower turret when some Biters move through dragon claws? Burn them or light them?

As a side question: should Personal Laser Defence target acid spits? I want so!