Factorio Forums

I really look forward to see what you'll come up with concerning rail blocks visualization

Really cool for the rails, maybe you could simply add a line like you does bou only on the current block and adjacent one. The current One would always be of a specific color or a vibrant color where other segment would be of an attenuated color.

How about tinting the rails instead?

4-colour theorem says that you should only need four different (hopefully harmonising) colours to display any such rail-markers.

If you can find four nice colours, that go well together without circus effects (e.g. pastelly or something), it should be easily do-able and you only have to worry about what's on the screen so running a colouring algorithm shouldn't be intensive to select one of A, B, C, D for each visible block on screen.

Personally, I don't see why you can't combine all the various the lines.

One line, with end markers, with tick-marks indicating the possible positions of signals.

And CRC is going to come back to bite you. Computationally, it costs almost nothing in a one-off CRC generation for a new blueprint to just replace it with SHA-1 or something and make it really modular so you can replace it if there are problems with that.

Would it be too performance intensive to do a full compare if checksums match? Everything that optimizes comparisons with checksums has to deal with this eventuality, from hash table data type implementations to filesystem deduplication engines.

The item stack change is a cool example of a little change to help deal with cache misses. I look forward to the combined impact of things like this in the next major release.

What if there was a key to toggle between showing stations/signals and the block indicator as shown in the FFF? The same way we use tab to show assembler recipes etc.

ledow wrote:4-colour theorem says that you should only need four different (hopefully harmonising) colours to display any such rail-markers.

If you can find four nice colours, that go well together without circus effects (e.g. pastelly or something), it should be easily do-able and you only have to worry about what's on the screen so running a colouring algorithm shouldn't be intensive to select one of A, B, C, D for each visible block on screen.

complex intersections can give you the lie on such small palettes - IIRC, there was already a demonstrable case where colors were being reused adjacently. you're not *just* dealing with a 2-line intersection; there's complex interrelations going on here that might necessitate as many as 8-10 unique colors to prevent ambiguity

ledow wrote:4-colour theorem says that you should only need four different (hopefully harmonising) colours to display any such rail-markers.

If you can find four nice colours, that go well together without circus effects (e.g. pastelly or something), it should be easily do-able and you only have to worry about what's on the screen so running a colouring algorithm shouldn't be intensive to select one of A, B, C, D for each visible block on screen.

Personally, I don't see why you can't combine all the various the lines.

One line, with end markers, with tick-marks indicating the possible positions of signals.

And CRC is going to come back to bite you. Computationally, it costs almost nothing in a one-off CRC generation for a new blueprint to just replace it with SHA-1 or something and make it really modular so you can replace it if there are problems with that.

Four color theorems don't apply for rails because a single segment could have more than 4 element and if one segment connect to 4 rails that connect to another common segment that connect to the first segment ... you got the idea ...

I think that we don't need colors because if separators are clearly visible then it's enough to see each rail block.
It can be green like signals indicators.

y.petremann wrote:

ledow wrote:4-colour theorem says that you should only need four different (hopefully harmonising) colours to display any such rail-markers.

If you can find four nice colours, that go well together without circus effects (e.g. pastelly or something), it should be easily do-able and you only have to worry about what's on the screen so running a colouring algorithm shouldn't be intensive to select one of A, B, C, D for each visible block on screen.

Personally, I don't see why you can't combine all the various the lines.

One line, with end markers, with tick-marks indicating the possible positions of signals.

And CRC is going to come back to bite you. Computationally, it costs almost nothing in a one-off CRC generation for a new blueprint to just replace it with SHA-1 or something and make it really modular so you can replace it if there are problems with that.

Four color theorems don't apply for rails because a single segment could have more than 4 element and if one segment connect to 4 rails that connect to another common segment that connect to the first segment ... you got the idea ...

The color theorem applies here, you can always transform the segment into a point, and all the connections to other segments to a graph connections while still being planar.
But it is much easier to do 5 colors than 4.

Neotix wrote:I think that we don't need colors because if separators are clearly visible then it's enough to see each rail block.
It can be green like signals indicators.

I think that they should include a "faulty separator" when a rail signal is used to separate part of the same segment.

kovarex wrote:

y.petremann wrote:

ledow wrote:4-colour theorem says that you should only need four different (hopefully harmonising) colours to display any such rail-markers.

If you can find four nice colours, that go well together without circus effects (e.g. pastelly or something), it should be easily do-able and you only have to worry about what's on the screen so running a colouring algorithm shouldn't be intensive to select one of A, B, C, D for each visible block on screen.

Personally, I don't see why you can't combine all the various the lines.

One line, with end markers, with tick-marks indicating the possible positions of signals.

And CRC is going to come back to bite you. Computationally, it costs almost nothing in a one-off CRC generation for a new blueprint to just replace it with SHA-1 or something and make it really modular so you can replace it if there are problems with that.

Four color theorems don't apply for rails because a single segment could have more than 4 element and if one segment connect to 4 rails that connect to another common segment that connect to the first segment ... you got the idea ...

The color theorem applies here, you can always transform the segment into a point, and all the connections to other segments to a graph connections while still being planar.
But it is much easier to do 5 colors than 4.

Proof of concept of what I've said : Here their is two magenta part connected together
The fact here
is that there is
A -> {B1,B2,B3, ... Bn] -> C -> A

EDIT : The fact is that I just realised that it's not the four theorem that was in wrong, it simply the actual coloring method ...

I also propose CRC -> SHA-* as you don't use it permanently (only when loading/saving) so performance hit is a non-issue and it's more future-proof.
Actually, I was astounded to get to know you use a meager CRC for creating object-hashes...

Rail segment indicators are nice for inexperienced players.
For myself I'd like to turn it on manually while designing new crossings and have it turned off otherwise. As I currently do with the debug option.

What I like to display are train paths and breaking distance. Turning those into option available when you eventually lock down debug displays would make manually driving a little bit safer.

Another very useful display would be rail usage to find bottlenecks in train networks.
OTTD has a very nice and visually pleasing way of showing this by slowly growing grass on tracks and adding rust to the rails in a few stages. If a train passes the counter is reset.

y.petremann wrote:Proof of concept of what I've said :
Here their is two magenta part connected together

Yes, but you may want to colour all those 2's as if they're adjacent for clarity. And such preferences may lead to non-planar problems which aren't 4-colourable.

I spent so much time trying to fix incorrect rail crossings, until I discovered the debug mode. I'm happy to see you're considering a UI change to include it in standard gameplay. But then I still like to have one other debug option enabled: show_rail_paths. With this it's very easy if it's safe to cross a rail or not, haven't died once after this.

Or I should build safe circuit-based railway crossings everywhere, as they are already in the busier areas.

dee- wrote:I also propose CRC -> SHA-* as you don't use it permanently (only when loading/saving) so performance hit is a non-issue and it's more future-proof.
Actually, I was astounded to get to know you use a meager CRC for creating object-hashes...

You can throw as many bits onto the checksum as you like, collisions are still inevitable and surprisingly likely.

With the T-ends on the rail indicators, they don't really need to be different colors. What is important is the clarity of separation between blocks. Another suggestion for the graphic is to have a rectangular box of the same width as the T you showed, again all the same color.