Friday Facts #198 - Rail segment visualisation

[draknor]

I posted this on /r/factorio, but thought I'd share here as well:

Hash Collision Probabilities:

Code: Select all

preshing.com/20110504/hash-collision-probabilities/

Key takeaway: CRC32 has a 50% collision probability once you reach 77,163 unique values. The graph on that page shows you hit about 100% probability collision somewhere above 200k unique values.

Here's another interesting link:

Code: Select all

stackoverflow.com/questions/996843/when-is-crc-more-appropriate-to-use-than-md5-sha1

... which links to:

Code: Select all

web.archive.org/web/20120722074858/ h t t p : / /bretm.home.comcast.net/~bretm/hash/8.html

... which says:

CRC32 was never intended for hash table use. There is really no good reason to use it for this purpose, and I recommend that you avoid doing so.
If you decide to use CRC32, it's critical that you use the hash bits from the end opposite to that in which the key octets are fed in. Which end this is depends on the specific CRC32 implementation. Do not treat CRC32 as a "black box" hash function, and do not use it as a general purpose hash. Be sure to test each application of it for suitability.

Just registered, so could not post actual links.

[prg]

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.

If two nodes with the same color end up next to each other, you could simply add an edge between them and still have a planar graph, no?

[draknor]

How about tinting the rails instead?

I kind of like this idea! When placing a signal, just tint all of the rails that would be included in that block.

[Gren]

Oh god the block visualization is something I absolutely need, for whatever reason I've just never been able to really understand the block concept and make it work in my head.

[draknor]

Oh god the block visualization is something I absolutely need, for whatever reason I've just never been able to really understand the block concept and make it work in my head.

I've found it (the debug option) tremendously valuable for figuring out NO PATH errors when I had placed a signal somewhere that I later forgot to pickup

[ledow]

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.

http://preshing.com/20110504/hash-colli ... abilities/

The chances of 160-bit collisions, even with billions of billions of data points being compared to each other, is hundreds of millions to 1.
The chances of CRC32 collisions, as stated in the FFF post, comes out to about 9% in real-world usage.

It's a no-brainer, given the data sizes and actual computation impact involved.

EDIT: Beaten to it, even with the same link!

[ske]

Rails with tunnels can form non-planar graphs, don't they?

[Ratzap]

If you put the rail segment stuff in, please make it an option. I'm quite happy laying rails without any colourful indicators so I'd like to be able to not have them.

[Darloth]

I quite liked in OpenTTD that rail blocks / segments would be highlighted by slightly brightening or darkening the tracks.

It looks completely fine to have that happening pretty much all of the time since they don't leap out of the background as bright colors might, but you can easily see the difference between one block and an adjacent block.

Not sure if that's helpful to you here, as the scale is quite different and the graphical style of Factorio is much more detailed with lots of debris and scatter and such, but it might be worth considering if for some reason you haven't already.

Another thing to consider from there, is that you could have trains highlight their planned path at least as far as the next block. I kept that option turned on all of the time, as most of the time the next block was not actually that far away, and as mentioned, since the highlight was just a slight darkening of the track, it looked okay. Doing this -vastly- improved my understanding of what trains were doing, when, and why. I'm unsure if such a feature could or would work well in Factorio, but it would be great to be able to see visualized planned pathing data for at least a single train a time.

[mrsimicsak]

How about making the rail blocks an overlay option on the map?

[Anthlon]

For sure i am looking forward to see any indication for rail segments! and for sure make it ON/OFF option please!
Great idea!

[pleegwat]

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.

Disagree. Let's take the image with it:



Note the cluttered background. If one of the signals inside the intersection were missing, and there was no colour difference, you might mistakenly think those blocks where separated because the T's aren't very visible.

[JCav]

First, I apologize that I'm not going to create a fancy graphic to illustrate my idea.

Second, for denoting rail sections, why not use the boxes which show up while trying to place signals? You already have a bunch of little green boxes that show up where you can place a rail signal, would it not be possible to use those same boxes to denote the start/end of sections so you know where you actually *should* place those signals?

The only drawback I can think of offhand, is that you wouldn't get a complete overview of the rail system all at once. However it would eliminate the "circus" concern, as the indicators would only be visible while placing a rail signal, train stop, or chain signal.

[DerGraue]

Ok, now I understand why 15.28 deleted some of my blueprints from different blueprint books in my library. Thanks for the info.

I honestly don't think this is a good solution. Of course, blueprints should not be duplicated, but checking each new version if there are equal blueprints in different books will cause other problems. For example some people will sort their blueprints, maybe download some blueprints from other people and sort those in their own blueprint books. Those will be deleted. I personally have some backups of old blueprint books in my library and put some of those in new blueprint books, all of those were deleted.

Maybe you can find a better solution for this.
Maybe you could just compare blueprint book vs. blueprint book and blueprint(without book) vs. blueprint, and not all blueprints regardless where they are stored.

Deleting stuff will just cause problems and raise bug reports I think.

[Mango]

Yes.. when building near train station is too much things showing. I think it would be fine to show it when you hit ALT (show info).

[IronCartographer]

Perhaps highlighting the rails and dividing lines?

rail block vis example.png (367.17 KiB) Viewed 7981 times

[JOndra91]

Few things I have in mind:

CRC, really? Well it's not like it cannot be used as a hash function for collision checks (even though it's not its purpose). So I wonder, is CRC an actual alogrithm used to generate the checksum or it's just one of those brainfarts when developers use a different name than they should?

Anyway, how did you compute the 9% probability. Using formula from http://preshing.com/20110504/hash-colli ... abilities/: (1-exp((-20*19)/(2*2^32))) multiplied by number of players I can get approx. 4.2%. Am I doing something wrong (yeah, probabilities are tricky)?

Also, you can use other meta informations like number of entities or blueprint dimensions to compare blueprints instead of just adding more bits to the checksum (if available).


And to visualize rail segments, you don't really need more colors as segments just need to be separated by clear visual marker.

[bobucles]

In terms of rail segment colors, I think the colors should be informative in some way. For example
Green: Available track
Yellow: Reserved track
Red: Occupied track
Blue: Chain signal open
Orange: Chain signal closed

That way we use colors that resemble the road side signals, except the display shows how the blocks react and is thus much clearer.

Should the segment lines also have arrows on them? That way instead of looking like |----| it looks more like <-----| for one way and <------> for 2-way.

In addition, will these rail line colors be viewable in the map view? Rail lines currently have a single grey color. If the map colors changed with the signals it might show how things work on a larger scale.

[mcvey]

I think having it visible when hovering over a segment of rail would be a good idea. It would only have to show that block and connected other blocks. If it becomes an option for a whole screen, map view might be too big, but a similar toggle for non-map view would fit.

[ratchetfreak]

Having a directionality indicator on the ends of each segment is a must, Also some indicator for whether it's a chain or normal signal. You can also combine the direction on the segment with the length indicator of the train wagons.

I've had to come up with colors for graphs before that needed to contrast with each other (for a white background though), I ended up with red, light green, light blue/cyan, purple and beige. They contrast pretty well. You can drop the beige for white to account for the brown background of the rails. I can get you the exact RGB values I used on monday.

For the items; the damage bar is also a pretty common bit of extra data. When it's just a damage bar that needs to be stored you can use use a union to store the damage data directly in the same space as the pointer and avoid the indirection.