"BO"
Moderators: BTT, andy55, b.dwall, juxtiphi
MCP.txt has/had a (float) cast. It is most likely what you saw. SoundSpectrum has already been informed/fixed. You can just delete the cast if you want things to work on your end. Other configs seem to be correct.
It would have been convenient if the preprocessor could have handled:
#define (float)
[read: delete it] ... because NOW certain configs can't be the same between GF4 and previous versions. But to be fair, cpp would have a problem due to the '(' and ')'s
(I HOPE I don't have a BO error
)
It would have been convenient if the preprocessor could have handled:
#define (float)
[read: delete it] ... because NOW certain configs can't be the same between GF4 and previous versions. But to be fair, cpp would have a problem due to the '(' and ')'s
(I HOPE I don't have a BO error
)-
JayPro
- Posts: 738
- Joined: Sat May 01, 2004 10:51 pm
- Location: Huntington Station, Long Island, New York
Forgive my IGnorance but....
...what do you mean by "cast" in this context? Did ANdy eliminate the float function altogether?
How then would a config that would other wise call this function be scripted?
How then would a config that would other wise call this function be scripted?
"God is syntax."
It USE to be required to EXPLICITLY (cast) a binary expression, i.e., (ID == 0) to a (float) if you were going to use it as part of another expression, i.e., 'B0="2 + (3 * (float)(ID == 0))" ' (PRE-GF4) ... which always seemed kinda silly to me ... namely because I would have GUESSED if any cast was required, it should have been to an (int) ... [since we were going to use it to multiply by '3', in this instance]. I assume ALL math ops MUST have been handled as (float).
The other possibility is that where all math was previously required/converted to (float), NOW with the 64bit implementation, everything is (double) or something... THIS IS JUST A GUESS HOWEVER
In GF4 however, conversions must happen IMPLICITLY and are no longer required... although it IS a little surprising to ME that they would cause a syntax error. No matter, things NOW seem to be handled properly determined by context, and the (cast)'ing has been done away with.
In 'C', where all variables and functions are strongly typed, I can understand the A NEED (kinda) for EXPLICIT (cast)'ing, here however things are simple enough that IMPLICIT assumptions can probably always suffice.
The other possibility is that where all math was previously required/converted to (float), NOW with the 64bit implementation, everything is (double) or something... THIS IS JUST A GUESS HOWEVER
In GF4 however, conversions must happen IMPLICITLY and are no longer required... although it IS a little surprising to ME that they would cause a syntax error. No matter, things NOW seem to be handled properly determined by context, and the (cast)'ing has been done away with.
In 'C', where all variables and functions are strongly typed, I can understand the A NEED (kinda) for EXPLICIT (cast)'ing, here however things are simple enough that IMPLICIT assumptions can probably always suffice.