Friday Facts #198 - Rail segment visualisation

Regular reports on Factorio development.
draknor
Burner Inserter
Burner Inserter
Posts: 8
Joined: Fri Jul 07, 2017 6:18 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by draknor » Fri Jul 07, 2017 6:23 pm

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.

User avatar
prg
Filter Inserter
Filter Inserter
Posts: 947
Joined: Mon Jan 19, 2015 12:39 am
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by prg » Fri Jul 07, 2017 6:35 pm

pleegwat wrote: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?
Automatic Belt (and pipe) Planner—Automate yet another aspect of constructing your factory!

draknor
Burner Inserter
Burner Inserter
Posts: 8
Joined: Fri Jul 07, 2017 6:18 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by draknor » Fri Jul 07, 2017 6:37 pm

Mooncat wrote: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
Manual Inserter
Manual Inserter
Posts: 2
Joined: Fri May 19, 2017 8:48 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by Gren » Fri Jul 07, 2017 6:37 pm

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
Burner Inserter
Burner Inserter
Posts: 8
Joined: Fri Jul 07, 2017 6:18 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by draknor » Fri Jul 07, 2017 6:52 pm

Gren wrote: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 :(

User avatar
ledow
Long Handed Inserter
Long Handed Inserter
Posts: 85
Joined: Sat Sep 24, 2016 3:00 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by ledow » Fri Jul 07, 2017 7:04 pm

MrGrim wrote:
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.

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
Filter Inserter
Filter Inserter
Posts: 372
Joined: Sat Oct 17, 2015 8:00 am
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by ske » Fri Jul 07, 2017 7:09 pm

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

Ratzap
Filter Inserter
Filter Inserter
Posts: 369
Joined: Sun Aug 16, 2015 11:15 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by Ratzap » Fri Jul 07, 2017 7:12 pm

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
Fast Inserter
Fast Inserter
Posts: 115
Joined: Sun Jun 08, 2014 3:57 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by Darloth » Fri Jul 07, 2017 7:14 pm

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
Manual Inserter
Manual Inserter
Posts: 1
Joined: Fri Jul 07, 2017 7:33 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by mrsimicsak » Fri Jul 07, 2017 7:37 pm

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

Anthlon
Burner Inserter
Burner Inserter
Posts: 10
Joined: Tue Jan 31, 2017 2:28 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by Anthlon » Fri Jul 07, 2017 7:45 pm

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
Fast Inserter
Fast Inserter
Posts: 158
Joined: Fri May 19, 2017 7:31 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by pleegwat » Fri Jul 07, 2017 7:52 pm

hykns wrote: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:

Image

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
Inserter
Inserter
Posts: 37
Joined: Mon Aug 15, 2016 9:01 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by JCav » Fri Jul 07, 2017 8:09 pm

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
Long Handed Inserter
Long Handed Inserter
Posts: 90
Joined: Mon May 30, 2016 12:12 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by DerGraue » Fri Jul 07, 2017 8:23 pm

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.

User avatar
Mango
Long Handed Inserter
Long Handed Inserter
Posts: 70
Joined: Fri Feb 22, 2013 6:27 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by Mango » Fri Jul 07, 2017 8:30 pm

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).
Hm.... so we have a mystery doner... intriguing.

IronCartographer
Filter Inserter
Filter Inserter
Posts: 296
Joined: Tue Jun 28, 2016 2:07 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by IronCartographer » Fri Jul 07, 2017 8:33 pm

Perhaps highlighting the rails and dividing lines?
rail block vis example.png
rail block vis example.png (367.17 KiB) Viewed 2240 times

JOndra91
Burner Inserter
Burner Inserter
Posts: 5
Joined: Fri Mar 17, 2017 9:00 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by JOndra91 » Fri Jul 07, 2017 8:34 pm

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.
Last edited by JOndra91 on Fri Jul 07, 2017 8:37 pm, edited 1 time in total.

bobucles
Smart Inserter
Smart Inserter
Posts: 1575
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by bobucles » Fri Jul 07, 2017 8:37 pm

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
Burner Inserter
Burner Inserter
Posts: 13
Joined: Fri May 05, 2017 6:41 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by mcvey » Fri Jul 07, 2017 9:03 pm

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
Filter Inserter
Filter Inserter
Posts: 934
Joined: Sat May 23, 2015 12:10 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by ratchetfreak » Fri Jul 07, 2017 9:18 pm

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.
Last edited by ratchetfreak on Tue Jul 11, 2017 8:22 am, edited 1 time in total.

Post Reply

Return to “News”

Who is online

Users browsing this forum: No registered users