Weird bugs are someone else's fault.

DaveTheCoder

Once again my code appeared to have a weird, intermittent bug.

As usual, my first reaction was to assume that there's a bug in the API.

But conventional troubleshooting determined that it was a logic error in my coding. :flushed:

cybereality

Definitely found some driver and engine bugs in my work, but 90% of the time it's something I did wrong.

newmodels

It can be hard to tell sometimes.

dialNforNinja

Preach, my brothers!

cybereality

It's like they say: if something smells like crap, check your own pants first.

DaveTheCoder

@cybereality said: Definitely found some driver and engine bugs in my work, but 90% of the time it's something I did wrong.

In my experience, even if the fault is a strange driver or engine bug, traditional troubleshooting techniques are the way to isolate the issue. Print (or something equivalent) is a programmer's best friend.

But I continue to forget that.

OpinionatedGamer

The Code doesn't work! You frantically run painstakingly through each paragrah, each line, each letter of your code, and it's all correct. You run some print functions and discover one of your important functions is never triggered! Your colliders aren't colliding for some reason! Then you see it. You stare at the screen in shock for ten straight minutes... before you face palm yourself harder than thought humanly possible. You painstakingly wrote the damage function, but never called it. Ever. You run your code and it works. You are rejuvinated! Your future is bright, and you have overcome the hurdles, knowing your coding experience will be smoother from now on! Then you spend the next two hours figuring out why your enemies health isn't working. Such is the life of a coder. Sorry for the long comment, lol.

Kequc

My favourite pastime is to look at git blame, find out who made the mistake, and see that it was me.

DaveTheCoder

I came across another weird "bug". A project worked in the Editor, on Android, on HTML5 Run in Browser, but not on HTML5 exported to a web server.

Conventional troubleshooting revealed that it was my mistake.

There are two instances of a "player" scene, and the common script created a RandomNumberGenerator so that the players move randomly. The symptom was that the two players were moving exactly the same.

It turned out that the RandomNumberGenerator::randomize() method depends on OS.get_ticks_usec() to compute the seed, and on HTML5 exported to the web server, the usec are apparently always returned as 0, so randomize() was using the same seed for both instances.

One solution was to ensure that different seeds were used, but I fixed it by using only one RandomNumberGenerator.

Xrayez

My favourite pastime is to look at git blame, find out who made the mistake, and see that it was me.

And then realize that you're the sole author for that feature... :D

It turned out that the RandomNumberGenerator::randomize() method depends on OS.get_ticks_usec() to compute the seed, and on HTML5 exported to the web server, the usec are apparently always returned as 0, so randomize() was using the same seed for both instances.

Looks like this is fixed by https://github.com/godotengine/godot/pull/48098 in Godot 3.4.

DaveTheCoder

That would help if unix time has microsecond or nanosecond resolution in the context of an HTML5 export, but my code was still sloppy.