Factorio Forums

xng wrote: ↑

Fri May 24, 2019 12:23 pm

You're in good company with the signed integer cast problem, that is the reason Gandhi in Civilization is so aggressive (his aggressiveness was -1). The bug was introduced in the first game and because it was an interesting bug to have Gandhi as a nuke maniac he still is the same in every new iteration of the series.

Hahahaha I didn't know about that
The nuclear Gandhi is still in the new version of civilization? They keep the bug on purpose?
(P.S.: I need to play civilization)

And you've somehow made bug fixing into an interesting read for the lamen. Bravo ^^

So, I still repeat the phrase: "Crashing on dereferencing null? Just add a null check!" as a reminder to myself and others to always look deeper into why and never stop at the basic symptom of a problem.

A very nice advice for the developers. But usually they don't follow it.

can we change the train logic to assume if the player train is moving it clears the path for full speed distance ahead? i often have trouble when i just start up a train and another zooms up and we collide because i was not going fast enough to trigger the red lights on the other paths.

Great FF! The bug details are always the most interesting thing.

NelsonSKA wrote: ↑

Fri May 24, 2019 2:13 pm

xng wrote: ↑

Fri May 24, 2019 12:23 pm

You're in good company with the signed integer cast problem, that is the reason Gandhi in Civilization is so aggressive (his aggressiveness was -1). The bug was introduced in the first game and because it was an interesting bug to have Gandhi as a nuke maniac he still is the same in every new iteration of the series.

Hahahaha I didn't know about that
The nuclear Gandhi is still in the new version of civilization? They keep the bug on purpose?
(P.S.: I need to play civilization)

Yes nuke loving Gandhi became a meme and sort of a trademark of civ. Even having fixed this silly underflow he is kept this way on purpose. Perhaps so the devs never forget to check against under- and overflows.

xng wrote: ↑

Fri May 24, 2019 12:23 pm

You're in good company with the signed integer cast problem, that is the reason Gandhi in Civilization is so aggressive (his aggressiveness was -1). The bug was introduced in the first game and because it was an interesting bug to have Gandhi as a nuke maniac he still is the same in every new iteration of the series.

Mother of... Well, THIS explains quite a bit!

All these years - the bastard! I will teach him (as soon as I am done with factorio ).

This reminds me of the 6 stages of debugging:

1 That can’t happen.

2 That doesn’t happen on my machine.

3 That shouldn’t happen.

4 Why does that happen?

5 Oh, I see.

6 How did that ever work?

Thanks for your continuing efforts, and for keeping us all in the loop! :>
Saving the tank/car color is a really nice change.

ledow wrote: ↑

Fri May 24, 2019 12:50 pm

NULL checks are critical and should be absolutely everywhere. And result in instant failure of the application, with full debugging trace.

The first line of any new C function that I write is literally just a list of any pointer parameters with:

assert(parameter != NULL);
assert(parameter2 != NULL);

Honestly if you have to do this then the wrong language is being used. In C++ document that a passed in value will never be null by taking it as a reference instead of a naked pointer. Or better yet, use an ownership type to enforce it by checking constraints at compile-time instead of run-time (thus converting to the owned type would force a runtime check, but all things considered everything should be created in an owned state so no checks should never need to be performed at all). This is trivial in C++ and is, honestly, the main reason to use C++ (a pox on classes). C++'s type system is significantly stronger than C's and by using it you get more succinct code, better documented code, *faster* code, and most importantly, much harder for you yourself to break it when you 'maintain' it sometime in the future.

Rust's ownership system takes the standard C++ ownership style and bakes it into the language itself, so any aspiring programmers I'd highly recommend learning rust. Even if you don't "use" rust (which honestly you should use rust) learning that ownership model will help you when programming in any other language.

Checking null on pointers that should never ever be null just means your checks are in the wrong place and your type system is weak, you can and should do better for a variety of reasons.

On an aside, the two errors mentioned in that article would not have happened with Rust or in a well typed C++ setup (there are some fantastic libraries out for that).

Omnifarious wrote: ↑

Fri May 24, 2019 1:27 pm

I rarely trust myself to generate test cases that truly exercise all the code paths or combinations thereof, and so I write a test that generates significant swaths of the possible input space and tests all of them. Even then I've sometimes missed things.

You might be interested in property check testing systems then. Quickcheck is the most popular.

Even then, both of these bugs would not have even needed to be tested for with better types in their codebase as they just would have been categorically impossible, nor are they something most humans would even think to check for as they are 'impossible cases'. If a case should be impossible then make it so via using proper types.

Rakshasa wrote: ↑

Fri May 24, 2019 1:20 pm

The point of 'assert' is that you can compile it with NDEBUG defined to disable it when making a release build, thus allowing you to have as many asserts as you want while working on the code without affecting production code.

This is also a very bad use of assert. Either enforce that the argument cannot be `nullptr` via proper Types, or always perform an explicit test if it is otherwise possible. Don't do this wishy-washy stuff, it just makes it hard to maintain in the future, adds needless cognitive load, etc...

NelsonSKA wrote: ↑

Fri May 24, 2019 2:13 pm

The nuclear Gandhi is still in the new version of civilization? They keep the bug on purpose?

In later games they split general aggressiveness and affinity for nukes. Civ 1 Ghandi was super aggressive. The newer Ghandi is less easy to anger, but when you do it he loves nukes

Serenity wrote: ↑

Fri May 24, 2019 4:58 pm

NelsonSKA wrote: ↑

Fri May 24, 2019 2:13 pm

The nuclear Gandhi is still in the new version of civilization? They keep the bug on purpose?

In later games they split general aggressiveness and affinity for nukes. Civ 1 Ghandi was super aggressive. The newer Ghandi is less easy to anger, but when you do it he loves nukes

The story went like this. Aggressiveness of the AI was on a scale from 1-10. Ghandi started at 1. Now when an AI adopted Democraty as government form, there aggressiveness would be reduced by 2. Ghandi flipped into -1 or 255 on the 1-10 scale. And nukes became available around the same time as Democraty on the tech tree. And the rest is history.

Some of your bugs sound like you are missing:

The vehicle changing color when you exit was something that annoyed me every single game I played. It was not enough to make me to write a post about it on the forum though. Anyways, it is a change I would cherish on any future playthrough.

Really enjoyed the account of the bug hunt as a programmer myself. Thanks Rseding!

This FFF pleases me.

- Cars/Tanks remember their color
Nice. Not a huge deal, but nice QoL addition.

- Performance: It's never what you think it is
That's going to be an amazing change to megabases with massive train networks.

- Crashing on dereferencing null? Add a null check

the mod API didn't prevent mods from doing: entity.burner.remaining_burning_fuel = -1

So basically you were right... it was the mod's fault for doing something dumb.

Great detective work. Always gotta keep in mind that APIs have to be fool-proof.... and there's some pretty big fools out there. Hahaha

That bit about symptoms and causes is very close to a long-standing policy of mine when making mods for Factorio, Minecraft, or other games. That is, it is not particularly uncommon for an exception to arise somewhere in my code due to someone else - almost always another mod - feeding some sort of invalid input. For example, recipe parsing code crashing when one of the items has variants that exist only on the client and not the server, or a placed block with a null ID, or a world generator which was given a null chunk on which to operate.

Almost without fail, people will then tell me - usually rather flippantly - that the issue is my fault and that I need to just add some sort of input sanity check, usually explicitly a null-check.

However, I never simply do so, because all that does is hide the problem; whatever mistake was being made somewhere is still being made, and who knows what other issues it has caused, is causing, or will cause in the future. For example, that null-world-in-world-generator issue could be hidden, but will probably now result in generated terrain missing features, something often impossible to ever fix without deleting the world data. Not to mention that the fix can incur its own problems; try-catch for example, is very computationally expensive, and checking things like lists containing no duplicate entries requires iterating the entire list.

Unfortunately, few people ever seem to understand this, and instead attempt to characterize it as my forcing everyone else to work around my "refusal to fix things", which is especially bothersome when the issue is something blatant like a typo in the other mod's code.

Hello,
What is the line code to write to change character color please?

Thanks !

Reika wrote: ↑

Fri May 24, 2019 8:42 pm

However, I never simply do so, because all that does is hide the problem; whatever mistake was being made somewhere is still being made, and who knows what other issues it has caused, is causing, or will cause in the future.

Amen.

However, I usually add checks there, so I can throw an exception that points to the guilty party. Still gets reported to me (people just don't read error messages), but at least I can close the ticket faster.

"Hello support, the program is showing me that 'press any key' error code again, what should I do? And when will you fix that stupid bug?"