For some reason the chess renderer works perfectly in main.tscn, but as soon as I switch over to chess_board_renderer.tscn, the Godot editor starts throwing a million errors over res://Scripts/chess_board_renderer.gd:85 - Invalid operands 'int' and 'Nil' in operator '*'
for no apparent reason-I’ve checked and I don’t see any dependencies in the main scene which are causing this, so I have no clue why this is happening.
Try to put a breakpoint on the line that’s throwing the error and see what the values of the variables are. Apparently one of them doesn’t have any value assigned.
When I stop the process calling redraw the errors stop.
PS I expected your boardrenderer scene to take in a string like your fen and render the board. yet you have input management in there and play_move functions. Perhaps you need to tidy everything up first, split out functions into classes, singletons, components or objects or whatever and bear in mind as much as possible the idea of “single concern” for any of your code parts. It will make debugging, maintenance and even your development so much easier. The effort is well worth it.
PPS I can see a lot of work has gone into this already, but it has got a bit messy. You have made some excellent progress with it. I think it could be a really interesting project for others to learn from, including me.
The i, j, and tile_size seem well-defined to me, but offset and motion are @export variables without a type which can be accidentally set to null in some unfortunate circumstances. Maybe you need to re-enter the value on your instantiated scene in the inspector.
I have no clue why this property is set to null - the Inspector shows its value as 0.0, but Godot seems to assume that the value can be anything, including null.
To prevent similar problems I recommend to specify types for variables, at least for exported variables.
You can do this in either of the following two ways:
specify it explicitly by using : <typename> after the variable name
when initializing the variable within the declaration the type can be inferred and can by omitted
Yeah, I saw that too, and I thought it might throw some errors. However, the error message doesn’t even point to it, instead blaming line 85. Is there any way to fix the traceback, or is this just a bug I’m gonna have to wait to be fixed?
Sometimes fixing one error leads to the next one being shown. I have not experienced a problem with the traceback, and if it says line 85 you can be sure the problem manifested on line 85, I am pretty sure that is almost 100% certain. (Hasten to add I am no expert though). Although the actual ‘error’ in the code that generated the fail can happen anywhere something failed quietly. Like if something is null when you thought it wasn’t.
When I tried @tomyy solution above, it cleared all the errors. Mind you thinking about it now I may have still had the draw process deactivated. I can check again but I will have to download your repository again as I have since deleted it, although debugging your slightly experimental code layout is always going to be challenging
This time my program blows up as usual, but there is literally no reason. I have the code
if moving == -1:
pass
for the time being. moving is a non @export variable defined outside of the _draw function, where this is called. This is fine. It throws no errors. But for some illogical reason, if I change it to
if moving >= -1:
pass
it crashes out and keeps saying Invalid operands ‘Nil’ and ‘int’ in operator ‘>=’ for no reason. Any reason why Godot can handle equalities but not inequalities?
Edit : I fixed this by simply adding a type annotation to the variable declaration, but I still don’t see any reason why it should handle >= different than ==
Is Null exactly the same as an Int value. No. You would expect and want the ‘is it the same’ to be able to cope with different types. Otherwise you could never do checks of the sort if not this == “null”
However, with a 'greater than’ test you expect both LHS and RHS to be of the same compatible type. Is “apple” > 4 makes no sense, hence an error. Is “null” smaller than 10 also makes no sense.
So I think if your ‘moving’ variable is null, then failing on >= is perfectly valid, even though at first it might seem odd that you can do the == test with no problem. After all, null is not exactly the same as -1.
See here a bit more context to what @pauldrewett mentioned:
Note
The behavior of some operators may differ from what you expect:
If both operands of the / operator are int, then integer division is performed instead of fractional. For example 5 / 2 == 2, not 2.5. If this is not desired, use at least one float literal (x / 2.0), cast (float(x) / y), or multiply by 1.0 (x * 1.0 / y).
The % operator is only available for ints, for floats use the fmod() function.
For negative values, the % operator and fmod() use truncation instead of rounding towards negative infinity. This means that the remainder has a sign. If you need the remainder in a mathematical sense, use the posmod() and fposmod() functions instead.
The == and != operators sometimes allow you to compare values of different types (for example, 1 == 1.0 is true), but in other cases it can cause a runtime error. If you’re not sure about the types of the operands, you can safely use the is_same() function (but note that it is more strict about types and references). To compare floats, use the is_equal_approx() and is_zero_approx() functions instead.
In short - try not to rely on GDScript doing the type conversion for you, because you might get an unexpected result somewhere that you didn’t account for. Do operations only on the same types, if that’s possible, or explicitly cast them to a different type if needed.
