Friday Facts #198 - Rail segment visualisation

[TheYeast]

I wondered about that too, but it might just mean that they collect it as a fun usage statistic. Who is going to notice a deleted blueprint, not blame it on their own stupidity, and then go through the trouble of filing a bug report about it?

50709

And now we know. The actual data isn't checked during the de-duplication

Anyway, the fact that this got reported seems to be because it is a crafted example. I still doubt this will get reported when it happens accidentally. Even though a message appears on the screen in this case, the receiving blueprint book is probably quite big when it happens for real, and I would just think "oh, okay, I already did that, it's in there somewhere" if it happened to me.

[meganothing]

A lot of people are ragging on CRC checks but they do provide quick and reasonably reliable way to compare two larger objects. Sure other crypto hashes have better collision rates but I'd say a 9% chance out of 20 million blueprints is doing pretty well.

It depends, if malicious crafting of two different recipes with identical CRC has the potential to annoy someone, it is trivial to do with CRC but in pratice impossible with a cryptographic hash.

A better approach than simply replacing the CRC with a crypto hash would be to use both, then you get multiplicative reduction in chance.

(I'm assuming Factorio's CRC is really CRC32). MD5 is worlds above CRC32 in terms of collision safety, and that can be seen just by looking at the size of the hash. In numbers it is 1:2^32 compared to 1:2^128. So using both does not make any sense.

[loup-vaillant]

My 2 cents about CRC vs SHA vs just about anything else. I've written a crypto library¹ and learned quite a bit in the process, so I think I kinda know what I'm talking about.

My recommendation for the hash would be Blake2b, for the following reasons (most of which have already been said in this thread):

• Blueprints are attacker controlled strings. Collisions are going to be a hassle, if someone decides to be a jerk. We need a cryptographic Hash.
• Pre-image resistance² may be enough, but collision resistance³ is better. Depending on how Factorio works, the devs may want to shoot for the latter.
• CRC is not even a hash, non-cryptographic hashes are not even preimage resistant (obviously). Don't use them.
• MD5 is broken for quite some time, and SHA-1 has been SHAttered (google found a collision a few months ago). They are not ideal.
• SHA-256 and SHA-512 are still secure, but they're slower. SHA-3 is more secure still, but it's even slower.
• Blake2b, thanks to its modern design, is very secure, and as fast as MD5. It can produce hashes of various length (from 8 to 512 bits), so the devs can chose the right compromise between security and hash length (I'd say 160 bits is the bare minimum, and 256 should be plenty).
• My library, Monocypher, features a very simple Blake2 implementation that fits in less than 200 lines of C/C++ code. Replacing the CRC code by my Blake2b should be a snap (just copy paste my code). he size of the hash can be increased later.

Of course, if you don't trust Monocypher (1.0 is waiting for the most extreme version of my tests, coming soon), just use Libsodium.

[1] http://loup-vaillant.fr/projects/monocypher/
[2] Given a blueprint, the attacker cannot find another blueprint with the same hash.
[3] The attacker cannot find 2 different blueprints with the same hash.

[crackalackin]

Just here to add my two cents as well

1. A rail planning mode, where each block is tinted, as in the rail's textures are color tinted. This is a global mode you turn on / off and affects all rails, even ghost image ones (so you can plan easier).
2. An item / mode that shows the current extent of a block - the block of the rail hovered over - and just that one highlighted in a specific way, i.e. much higher contrast, etc. It would not be as "clear" but sufficient to debug complex intersections.

Also it would be nice to be able to see signal changes by putting "ghost trains" onto them. That would be a great feature for 1), as you can i.e. build an intersection with ghost rails and see the blocks and then put ghost trains onto tracks to see the signals update in real time and be able to test certain corner cases without having delete train, place one tile further, add second train and delete the one on the other rail. Just a simple "add trains" mode where you add the trains to the rail you want them to be and remove them by simple clicking on them and it color tints the rails the current train is blocking corresponding to the train's color. "Free" tracks are shown as usual, non-colored.


But honestly, this "advanced" use case is probably only used by dedicated players, and those have figured out how blocks work already. So is the coloring really necessary? Not sure. In the tutorial it's great to show how the blocks work, but in a real game you need to understand the blocks before you can even build / think of a more complicated intersection. So I'd mostly look at the use case of "how to debug a complex intersection" instead of "how to learn about how blocks work".

[kmcphillips]

Accessibility is important for this kind of thing. It's been pointed out at least once in this thread already, but making colour coding the only marker makes it useless a nontrivial number of users.

Trying to find a contrasting palette helps, but it's never going to work for everyone. And it's in the area of 5%+ of people that have colour vision problems. An extra click or a mouse over or symbols or something is fine.

A good trick is to take a screenshot and greyscale it, then see if the interface is still fully usable.

[bobingabout]

that is a lot of information to show at once when placing a signal. But it is still a good idea to show signal blocks. Drawing them in your head can be difficult when working on complex junctions.

[Hoeloe]

TBH: Don't know how many hours I spent chasing down signaling problems in Transport Tycoon. Actualy this is also the reason why I understood the signaling instantly in Factorio. When I read the Gameplay Help Forums with all those signaling problems I can just smile Looking forward for the Devs solution for this visualization since it would also make my life easier troubleshooting those problems.

[ratchetfreak]

as promised:

red: 0xff0000,
cyan/light blue: 0x50bebe,
light green: 0x1de226,
purple: 0xc239c6,
brown/beige: 0xb7bc86,

When driving a train having the state of the signals be more visible will be very helpful with avoiding collisions.

[mrvn]

Code: Select all

struct ItemStack
{
  ItemCountType count;
  ItemID id;
  Item* item; // null unless the item needs special data (blueprint, armor etc...)
};

Have you considered merging ItemID and Item* into a tagged value? All pointers to anything significant have the lower 2 bit 0 (don't do this with char pointers or others that have smaller alignment). So you can add a tag to the lower to bit to separate pointers and non pointers. By just using the LSB you can store 2^63 possible ItemID in the same space as the pointer. Or is the ItemCountType 32bit and ItemID fits into the padding necessary before the pointer anyway?

[mrvn]

When placing signals it shows the number of train cars fitting behind the signal. I often wonder how many train cars fit before the signal though. Usually I place the station first and then work backwards towards the waiting bays and entry point.

[d3x0r]

How about tinting the rails instead?

+1 was going to just come say that - maybe even drawing over the rails as opposed to tint.

[Exasperation]

magenta/light blue: 0x50bebe,

You seem to have confused cyan and magenta; magenta is a pinkish purple color (e.g. 0xFF00FF), cyan is a blue-green (e.g. 0x00FFFF).

[bobucles]

magenta/light blue: 0x50bebe,

It's time to get tested for color blindness.

[bobingabout]

magenta/light blue: 0x50bebe

You do know what Magenta is right?
That's not it. See above 2 posts.

[Accrettio]

I've reacted to the bright green colors of the markings when placing signals before this FFF. It doesn't work together with the graphics of the rest of the game. All the rest of the environment and buildings are kind of natural-looking, and using bright RGB colors works against that. I always assumed it was just waiting for the proper graphics.

Having said that, I really like the idea to show the rail segments. It happens quite often that something gets messed up because of a missing signal. And I have a few ideas on how it can be done.

First thing, in the FFF it seems like everything is thought of as separate information. The markings for the signals are always green, the arrows with directions of the train are always yellow, the wagons are always white. And the new segment indication is all over the RGB scale. I suggest handling it all as segments. In the red segment, use red for all of the markings needed, in the blue only blue should be used.

Secondly, the colors. Please don't use the bright RGB colors. I think it would be better to use colors more "dirty", i.e. colors that will blend in a bit better in the environment.

Third, use the environment. Is it possible to change the colors of the rails or syll? Is it possible to make the arrows part of the environment?

Forth, I think there should be a total of 4-6 colors for the rail blocks. And I think an additional 2 colors should be dedicated to preview, one in front of the signal and another one behind it. That way it's easy to see how placing a signal would change the blocks.

Fifth, arrows. I think there should be arrows along all of the markings for the rail blocks to make it simple to see which way the trains go. I don't think they need to be very close, maybe one arrow every other train block or similar.


And I have a few other suggestions as well in regards to the rails. I want markings of the locomotives and wagons for the signal before the one I'm placing as well, to be able to line up the signals easier. I also want markings for the stations for at least 6 locomotives/wagons even if there are signals in the way, at least when you select the station.

[ratchetfreak]

I've reacted to the bright green colors of the markings when placing signals before this FFF. It doesn't work together with the graphics of the rest of the game. All the rest of the environment and buildings are kind of natural-looking, and using bright RGB colors works against that. I always assumed it was just waiting for the proper graphics.

Having said that, I really like the idea to show the rail segments. It happens quite often that something gets messed up because of a missing signal. And I have a few ideas on how it can be done.

First thing, in the FFF it seems like everything is thought of as separate information. The markings for the signals are always green, the arrows with directions of the train are always yellow, the wagons are always white. And the new segment indication is all over the RGB scale. I suggest handling it all as segments. In the red segment, use red for all of the markings needed, in the blue only blue should be used.

Secondly, the colors. Please don't use the bright RGB colors. I think it would be better to use colors more "dirty", i.e. colors that will blend in a bit better in the environment.

Third, use the environment. Is it possible to change the colors of the rails or syll? Is it possible to make the arrows part of the environment?

Forth, I think there should be a total of 4-6 colors for the rail blocks. And I think an additional 2 colors should be dedicated to preview, one in front of the signal and another one behind it. That way it's easy to see how placing a signal would change the blocks.

Fifth, arrows. I think there should be arrows along all of the markings for the rail blocks to make it simple to see which way the trains go. I don't think they need to be very close, maybe one arrow every other train block or similar.


And I have a few other suggestions as well in regards to the rails. I want markings of the locomotives and wagons for the signal before the one I'm placing as well, to be able to line up the signals easier. I also want markings for the stations for at least 6 locomotives/wagons even if there are signals in the way, at least when you select the station.

The overlay information is just that, overlay. Finding a color scheme that doesn't clash with the rest of the game is important but you can be a bit brighter/cleaner for it than the rest of the game world.

A train block has a lot of stuff to communicate: where the boundaries are, which directions the trains can move in. Whether the boundary is a chain or normal signal.

You need the 5th color to make the coloring algorithm feasible to execute in real time. 4 coloring a graph is quadratic which means that for a large megabase worth of train blocks will take a pretty long time to color the entire thing.

[DaveMcW]

You need the 5th color to make the coloring algorithm feasible to execute in real time. 4 coloring a graph is NP-complete which means that for a large megabase worth of train blocks will take until the heat death of the universe to color the entire thing.

Nope. Planar graphs are 4-colorable in quadratic time, and 5-colorable in linear time.

The NP-complete COLORABILITY problem uses non-planar graphs.

[Koub]

For those thinking color is important, I'd say : it indeed is, but this feature is so much useful, that it's 1000 times worth the minor inconvenient of a temporary christmas tree during rail debugging (my opinion here).
I think most players hon't have an OpenTTD PHD, and even if I'm not the best Factorio player around, it literally took me several hundreds of gameplay hours to just dare try trains. And even then, I need to switch regularly to sandbox mode to try and make my debugging before reproducing it into my game when I have a crossing or something.

[Unclebod]

For my part, I really don't like the idea of automatic removal of blueprints at all.
I want the same bluprint in several books sometime...

/UncleBod

[widders]

So I had an idea earlier and it solved some problem, I can remember the idea, but I can't remember the problem, anyway.

Why not integrate the item stack into the item class? An item after all is a stack of 1. Possibly it's too late in development to implement such a change but 99% of items in a game are non-dynamic so there's no need to track them (who cares which iron plate from the 5000 you've made gets used?) and the dynamic items I can't think of any which stack above 1. Things like ammo and science which have a usage bar get combined when you combine two stacks anyway so that should be simple to track as only the "top" item has a damage attribute associated with it.

Still can't remember what the problem that solved was but from what I can see you've got a memory object for each item in a stack plus the stack, this way would mean only one (if slightly larger) memory object per stack regardless of the number of items.

Possibly this could even combine with the belt optimizations as that one object stores how many items there are which in turn represents a length on the belt.