Friday Facts #198 - Rail segment visualisation

Regular reports on Factorio development.
PursuedMeatl325
Burner Inserter
Burner Inserter
Posts: 6
Joined: Tue Oct 27, 2015 9:34 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by PursuedMeatl325 » Sat Jul 08, 2017 3:08 pm

I think there should be a shortcut button to make the signal segments to show up. The rail tutorial should tell you what the button is to bring it up, so newcomers can learn from the tutorials.

Junion
Long Handed Inserter
Long Handed Inserter
Posts: 71
Joined: Thu Sep 11, 2014 3:30 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by Junion » Sat Jul 08, 2017 3:14 pm

how about instead of a circus.

Go with shades of a few colors?

Neon Green, neon yellow, Neon Red.
Bright green/yellow/red
A darker green/yellow/red


And just choose colors that would look good and visible at 3 different shades, when backgrounded with the track

widders
Manual Inserter
Manual Inserter
Posts: 4
Joined: Sat May 13, 2017 11:11 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by widders » Sat Jul 08, 2017 3:23 pm

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.

A better approach than simply replacing the CRC with a crypto hash would be to use both, then you get multiplicative reduction in chance. Calculate the CRC and check, if they're the same calculate and check the crypto hash (you could even keep going if you wanted to be really pedantic up to eventually running full comparison of the blueprint contents). I don't know how often these comparisons are made but I would think a CRC->MD5 would be sufficient to remove almost any chance of a collision in the real world but you could go for a SHA-1 afterwards if you wanted to be extra safe.

juliejayne
Inserter
Inserter
Posts: 29
Joined: Sat Apr 01, 2017 1:52 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by juliejayne » Sat Jul 08, 2017 3:48 pm

Is this really needed, all this colour display option. If you hover over a section of track it tells you what the Block number is, hover over an adjacent piece, if the Block number is different, it is a different block.

Instead of all these colours, why cant we just have an demarcation line showing between one block and another and the number of the block displayed on the rail. And so long as the option is toggle-able, it need never interfere with the day to day running of the game.

DisK
Burner Inserter
Burner Inserter
Posts: 6
Joined: Thu Aug 20, 2015 12:15 am
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by DisK » Sat Jul 08, 2017 4:58 pm

Idea for how to handle Rail Block visualizations, perhaps it could show only rail blocks related to intersections, and even then, only those a signal would interact with?

User avatar
5thHorseman
Filter Inserter
Filter Inserter
Posts: 693
Joined: Fri Jun 10, 2016 11:21 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by 5thHorseman » Sat Jul 08, 2017 5:18 pm

IronCartographer wrote:Here's an idea: "Less is more" AKA "What do current signals/rail see, and why?"
*snip*
I love everything about this idea.
"So you completed the game with a spaghetti factory? Well I hand crafted a rocket and threw it into space with my bare hands!"

User avatar
TheYeast
Inserter
Inserter
Posts: 35
Joined: Sun Feb 05, 2017 3:57 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by TheYeast » Sat Jul 08, 2017 7:32 pm

At first I (like some others) thought 9% (or 4.3%) ??? That can’t be right! It is almost certain there will be collisions with these numbers. But the fallacy is assuming that all these 20,000,000 blueprints are in the same pool. They are not. It’s about the change of one player having a collision in a pool of 20 (P=4.42378*10^-8) and using that to find the chance of one or more players out of 1,000,000 have that happening (P=4.32736*10^-2).

(I got my numbers using numerical approximation in Maxima)

Now, I read a lot of comments here claiming that using CRC this way is horrible because of the high chance of collision. But even if the chance of collision is way worse than P=4.42378*10^-8 for 20 blueprints (as some claimed), I think this is completely irrelevant. I assume that the clever Factorio devs use the CRC only to quickly see that two blueprints are different, not to assert that they are identical when CRCs match. When there is a match, you can still compare the actual blueprints before removing one as a duplicate.

After all, the bug described was about blueprints being erroneously duplicated, not deleted.

Using a hash to quickly determine that two objects are certainly different or probably identical is a very good way to detect duplicates. Without it you would have to compare every blueprint from one book to every blueprint of the book you are merging it with. For 50 blueprints each that makes 2500 comparisons. With the CRC it will normally be 50 comparisons at most (when the books are completely identical), and rarely 52 or something when there is a CRC collision.

But then again I’m assuming. Kovarex, you guys do compare the actual data before deleting a suspected duplicate, right? :)

anarcobra
Inserter
Inserter
Posts: 25
Joined: Sat Nov 12, 2016 12:45 am
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by anarcobra » Sat Jul 08, 2017 8:58 pm

TheYeast wrote:
Now, I read a lot of comments here claiming that using CRC this way is horrible because of the high chance of collision. But even if the chance of collision is way worse than P=4.42378*10^-8 for 20 blueprints (as some claimed), I think this is completely irrelevant. I assume that the clever Factorio devs use the CRC only to quickly see that two blueprints are different, not to assert that they are identical when CRCs match. When there is a match, you can still compare the actual blueprints before removing one as a duplicate.
That's true, but from this line:
Lets wait if it happens or not :)
it sounded to me like they weren't doing this.

mOoEyThEcOw
Inserter
Inserter
Posts: 21
Joined: Fri Mar 17, 2017 11:27 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by mOoEyThEcOw » Sat Jul 08, 2017 10:19 pm

People forget the authors are not in the U.S. and that algorithms like SHA are under arms export control laws. SHA may not be a legally viable option for a commercial product.
Escadin wrote:Dat level of optimization :D

I really wonder if it would make any difference. Please keep us updated!
If each operation takes one second. Going to main memory (arbitrary pointer lookup) takes about 5 minutes. Accessing that value they added (in register or L1 cache) is about 5 seconds. Then consider how often they need to compare the types of objects. That's not even counting all of the memory operations (allocations, deallocations, which take *hours* in this metaphor, or ~15 minutes if they are using a memory pool) this prevents.

golfmiketango
Filter Inserter
Filter Inserter
Posts: 526
Joined: Fri Jan 29, 2016 2:48 am
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by golfmiketango » Sat Jul 08, 2017 10:31 pm

IronCartographer wrote:Perhaps highlighting the rails and dividing lines?
rail block vis example.png
This looks pretty sweet to me. It solves the "more clutter" problem of this idea elegantly and creates a subtle cue that can be ignored (for better or for worse, I suppose), if desired. Only concern: perhaps it's so subtle that people wouldn't even realize it was there.... but maybe this is fine; after all, rail segments are a semi-advanced concept that you really don't, strictly speaking, need to grasp to do signalling.

TheVeteraNoob
Long Handed Inserter
Long Handed Inserter
Posts: 64
Joined: Wed Jul 20, 2016 2:20 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by TheVeteraNoob » Sun Jul 09, 2017 3:30 am

Somebody beat me to the highlighting rails suggestion already. But how about this. The ends of the blocks have lines. And the color that the rails are highlighted is based on the signal (green red yellow blue). Won't look like a clowny at all when there are no trains. And it would be much easier to diagnose from a distance. And i think that would really help show how they work at the same time.

PacifyerGrey
Smart Inserter
Smart Inserter
Posts: 1014
Joined: Wed Jun 29, 2016 10:02 am
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by PacifyerGrey » Sun Jul 09, 2017 7:26 am

TheVeteraNoob wrote:Somebody beat me to the highlighting rails suggestion already. But how about this. The ends of the blocks have lines. And the color that the rails are highlighted is based on the signal (green red yellow blue). Won't look like a clowny at all when there are no trains. And it would be much easier to diagnose from a distance. And i think that would really help show how they work at the same time.
I have the same vision.

There is no need to show all blocks in different colors.
1. You should show blocks when you hover over signal.
2. Draw block borders similar to that you painted in FF
3. Color them green/yellow/red depending on current block status.
4. Highlight the block that signal you hovered over depends on
5. Optionally draw paths that chain signal calculation depends on highlighting all signals that it depends on finishing with normal one.

As an option you can also draw blocks when you hover mouse over rail segment but this is probably too resource intensive

As an addition. Every train should have its ID displayed everywhere from train shedule interface to multitrain train management window.
If a rail block is yellow/red it should also display ID of the train that caused this state. Ideally you should be able to focus the train in question or highlight it somehow.

So no circus, only useful information and the goal of understanding rail physics is reached.

Edit:
Other useful information on this graph could be available driving directions eg one-way or 2-way on a selected rail piece. I know this is already available as you can't place stops on a wrong side of tracks. So adding some kind of arrows to the lines would be awesome.
Last edited by PacifyerGrey on Sun Jul 09, 2017 8:19 am, edited 1 time in total.

offtheball
Burner Inserter
Burner Inserter
Posts: 6
Joined: Mon Aug 22, 2016 9:35 am
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by offtheball » Sun Jul 09, 2017 8:08 am

I love the idea of moving rail visualisations into the base game.

Whatever way you choose to go, I hope you keep in mind accessibility. Relying solely on colour with such a large (and hopefully expanding) user base could lead to some being left out, and having a much harder time getting the hang of rails. I get that it's currently a debug option, so it's not intended for the general audience, but I feel like it's different once it goes into the regular options.

I do love the idea of using basic shapes, because I feel like it's visually consistent with the hit boxes and signal placement markers, but it wouldn't help with the clutter at all.

RIscRIpt
Manual Inserter
Manual Inserter
Posts: 4
Joined: Fri Feb 03, 2017 2:19 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by RIscRIpt » Sun Jul 09, 2017 8:08 am

Yet another reason of choosing other hash function:
We have only 64bit version of the game, and in 64bit process the CPU can hold 64bits at once in a single register. So by choosing other 64bit hash function you will still be able to compare hash values like numbers (not arrays).

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 » Sun Jul 09, 2017 9:49 am

PacifyerGrey wrote:
TheVeteraNoob wrote:Somebody beat me to the highlighting rails suggestion already. But how about this. The ends of the blocks have lines. And the color that the rails are highlighted is based on the signal (green red yellow blue). Won't look like a clowny at all when there are no trains. And it would be much easier to diagnose from a distance. And i think that would really help show how they work at the same time.
I have the same vision.

There is no need to show all blocks in different colors.
1. You should show blocks when you hover over signal.
2. Draw block borders similar to that you painted in FF
3. Color them green/yellow/red depending on current block status.
4. Highlight the block that signal you hovered over depends on
5. Optionally draw paths that chain signal calculation depends on highlighting all signals that it depends on finishing with normal one.

As an option you can also draw blocks when you hover mouse over rail segment but this is probably too resource intensive
All of the above, except instead of showing all blocks it should just highlight the entire block around the rail segment you hover over (and maybe blocks after it, in the case of blue with only one exit via chain signal). Showing all blocks/colors causes the circus effect and should be less intrusive, behind a toggle of some kind, though certainly more convenient than the Debug options. :P

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 » Sun Jul 09, 2017 10:05 am

RIscRIpt wrote:Yet another reason of choosing other hash function:
We have only 64bit version of the game, and in 64bit process the CPU can hold 64bits at once in a single register. So by choosing other 64bit hash function you will still be able to compare hash values like numbers (not arrays).
This. An algorithm with 64-bit word size will likely be faster than one with 32-bit word size, if only because you only have half as many input words.

luc
Fast Inserter
Fast Inserter
Posts: 164
Joined: Sun Jul 17, 2016 9:53 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by luc » Sun Jul 09, 2017 11:36 am

IronCartographer wrote:Perhaps highlighting the rails and dividing lines?
Image
That looks really nice! Subtle, but clear enough if you're looking for it. Or perhaps just 1px thicker. Something like that. I really like this one :)

As for when to show it: definitely something with signals. Placing one, hovering over one... those options both sound like they make sense.

User avatar
TheYeast
Inserter
Inserter
Posts: 35
Joined: Sun Feb 05, 2017 3:57 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by TheYeast » Sun Jul 09, 2017 11:43 am

anarcobra wrote:That's true, but from this line:
Lets wait if it happens or not :)
it sounded to me like they weren't doing this.
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?

Loewchen
Global Moderator
Global Moderator
Posts: 5128
Joined: Wed Jan 07, 2015 5:53 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by Loewchen » Sun Jul 09, 2017 11:57 am

TheYeast wrote:
anarcobra wrote:That's true, but from this line:
Lets wait if it happens or not :)
it sounded to me like they weren't doing this.
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

User avatar
TheYeast
Inserter
Inserter
Posts: 35
Joined: Sun Feb 05, 2017 3:57 pm
Contact:

Re: Friday Facts #198 - Rail segment visualisation

Post by TheYeast » Sun Jul 09, 2017 12:21 pm

pleegwat wrote:This. An algorithm with 64-bit word size will likely be faster than one with 32-bit word size, if only because you only have half as many input words.
The size of the output hash (32 bit in this case) is not necessarily related to the word size used during its computation. I'm no expert, but from a quick glance at the wikipedia page i'd say you can do a CRC-32 in 64 bits registers just fine.

Anyway, the hash is only calculated when a blueprint is modified, and it is saved with it (has to be the case considering the bug description), so there is little point in trying to make its computation faster.

After computation extra bits would just mean more memory bandwidth and less efficient use of CPU cache, so I doubt it will be faster. Besides, de-duplication of blueprints would be so infrequent (compared to, say, an inserter picking something up) that it is a waste of time to optimise it further.

Post Reply

Return to “News”

Who is online

Users browsing this forum: No registered users