Factorio Forums

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.

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

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.

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.

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?

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.

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?

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.

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

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.

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.

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.

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.

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.

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).

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.

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.

IronCartographer wrote:Perhaps highlighting the rails and dividing lines?

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.

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?

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

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.