Player: ReLoaded

Finally got the player model imported with animations. At first, I just added the animation setup to the player scene, but I knew I'd need to refactor the player. Starting with a copy of the animation setup, I copied the script and test room then started working. Referencing the original player, I added all the accessories and gave them the groups and signals needed. Since so much had changed, minor edits were required for the script's copy.

Initial tests went well. Objects fired at near-lethal velocities, so I had to scale back their speed. Vacucel aiming was a bit off, so I adapted it. Items were collected slightly better and faster. All the buildings and menus thus far work.

The major problem came from the water pools. Water was being spawned, but it kept falling into the pool before collection. Most times it wouldn't seem to appear. After some debugging (print statements) the problem was located. For some reason, the water was spawning too low. I just added an extra unit to the spawn's Y axis for a quick fix.

I'm not looking forward to adding the dialog system, but that may come next.

Tutorial, How to Debug Code:

Most times when there is a syntax error, you either get a warning or a crash. Most script editors take you somewhere close to the offending line so you can find the problem. With godot, the error is usually above the line indicated. Most flaws are within a few lines of the line indicated, if not the line itself. Remember, these editors are making a best guess, so they can be a little off.

However, sometimes something doesn't work for any number of reasons. Sometimes you cannot see the error because it's logical (and that skill may need a few levels). If a specific mechanic isn't working in a game, your first option is to check the area of code for that mechanic. Usually, this is contained in a function for ease of use. Often, just looking will reveal the problem.

If not, I like to add print() statements in the code and output different strings or values. hen the statement at the top of a function doesn't print, then the function isn't being called. More code to check, but you could have forgotten to call the function. This is also useful to check if statements in a similar way. When the requirements of an if statement are not met, it won't activate.

Printing variables can help determine if they have the correct values, or that they are being used. An errant or empty value can cause much mayhem. Bad incoming variables are also problematic, so check them if you have them.

If all else fails, get a rubber duck and read the code's lines to it. Then kick yourself smartly when the solution is obvious. The solution is almost always obvious.