Strange Compiler Error

Huh. Yep, getCollDetection returns TYPE_FLOAT, and it's not the only one. Changing that shouldn't cause any problems, I don't think.

Saffith wrote:Huh. Yep, getCollDetection returns TYPE_FLOAT, and it's not the only one. Changing that shouldn't cause any problems, I don't think.

Nah, I fixed it for 2.55/2.60, and I will apply the same fix in 2.53. I knew what it was as soon as [MENTION=61261]ywkls[/MENTION] reported it on Skype, but I wanted him to post it here as a reminder for me.

For the record, this affected [FONT=Courier New]CollDetection [/FONT]for [FONT=Courier New]lweapon[/FONT], [FONT=Courier New]eweapon[/FONT], and [FONT=Courier New]npc[/FONT]; but none of the other vars, or functions seem to have an incorrect return type at this time. My apologies if this created extra work for you [MENTION=38582]Saffith[/MENTION]. I merely needed a reminder, and I asked [MENTION=61261]ywkls[/MENTION] to post it in the dev chat. I didn't expect him to submit a full bug report, although it was nice of him to do that.

Update: Fixed for 2.53/2.50.2.1.sheep, too.

P.S. [MENTION=61261]ywkls[/MENTION]:[FONT=Courier New] if ( ptr->CollDetection )[/FONT] only worked because float is typecast to bool in that type of statement. When there is an explicit COMPARE to a boolean type (true/false), the proper bool return is mandatory. -- Clearly, no-one had ever tried [FONT=Courier New]if ( ptr->CollDetection = true )[/FONT] in the past ???.

Link->Invisible needs it, too. I think that's the only other one.
Shouldn't this be corrected in the repo before it's marked as fixed?

ZoriaRPG wrote:
P.S. [MENTION=61261]ywkls[/MENTION]:[FONT=Courier New] if ( ptr->CollDetection )[/FONT] only worked because float is typecast to bool in that type of statement. When there is an explicit COMPARE to a boolean type (true/false), the proper bool return is mandatory. -- Clearly, no-one had ever tried [FONT=Courier New]if ( ptr->CollDetection = true )[/FONT] in the past ???.

It does seem odd to me that this has never turned up before, but I figured it would be an easy fix.

I'm guessing that the setters were all correct, otherwise they'd have complained long hence. There's no telling why the getters were wrong.

Saffith wrote:Link->Invisible needs it, too. I think that's the only other one.
Shouldn't this be corrected in the repo before it's marked as fixed?

It is corrected in the stuff that I have staged to merge. DarkDragon asked not to make any new commits until he finishes his internal changes. I can put the 2.50.2.1 source up separately if you want, but I do not have access to dump it to GH/AGN.

Here is the revision for this fix for master:

https://github.com/ZoriaRPG/ZeldaClassic/compare/23_SpriteData...ZoriaRPG:24_Fix_CollDetection_Return?expand=1

I thought that marking a bug as 'sick' was the appropriate middle-ground between implementing the fix, and verifying that it was fixed in use?

Here is the 2.50.2.1 code: https://github.com/ZoriaRPG/ZeldaClassic_2.53

Edit: I re-applied the changes to the 2.50.x branch:
https://github.com/ArmageddonGames/ZeldaClassic/compare/2.50.x...ZoriaRPG:2.50.x

Let's hope that I did not overlook anything, and that this compiles properly.

ywkls wrote:It does seem odd to me that this has never turned up before, but I figured it would be an easy fix.

I'm guessing that the setters were all correct, otherwise they'd have complained long hence. There's no telling why the getters were wrong.

Aye. The setters are fine, and as I said, i suspect it is because the syntax [FONT=Courier New]if ( Link->CollDetection )[/FONT] or [FONT=Courier New]if ( Link->Invisible )[/FONT] is cleaner, or easier to type, and read; as compared to[FONT=Courier New] if ( foo == true )[/FONT] . It is also less error-prone, as you cannot have an assign here where you intend a compare, when doing a simple boolean evaluation, so fewer people use [FONT=Courier New]== true[/FONT] in these cases.

Similarly, most users will do[FONT=Courier New] if ( !foo )[/FONT] rather than[FONT=Courier New] if ( foo == false )[/FONT]. I would still have expected it to be reported before, but the userbase is clearly not reporting issues when they should, and they try to find hacks, or workarounds to the, rather than alerting us fix them.

Internally all of these values are integers. Only the ZScript parser distinguishes between float, and bool; or other types.