Jump to content
The simFlight Network Forums

4.749d ipc.testflag


Recommended Posts

Did the ipc.testflag functionality change in this version?

Not that I'm aware of. Compared to which version, 4.749c or something earlier?

I'm relying on it for my ThrottleManager, and it seems to be returning the opposite of what it used to.

It returns true or false. How are you testing the result?

Pete

Link to comment
Share on other sites

4.745. I'm still investigating.

It does seem to act the opposite of 4.745 and before.

In my ThrottleManager I use flags to toggle states (forward or reverse).

In 4.745 if I do an ipc.clearflag and then test with ips.testflag in the generated event, it returns a true boolean.

In 4.749d the same condition returns a false boolean.

Link to comment
Share on other sites

It does seem to act the opposite of 4.745 and before.

...

In 4.745 if I do an ipc.clearflag and then test with ips.testflag in the generated event, it returns a true boolean.

In 4.749d the same condition returns a false boolean.

Hmm. if the flag is clear it should certainly return a FALSE. If 4.745 did the opposite it was most certainly wrong and you should really have reported it.

TRUE = set = non-zero

FALSE = clear = zero

This convention holds throughout everything. not only my code, but all programs everywhere.

I've not deliberately changed anything here in FSUIPC, and I would never ever deliberately return a "TRUE" for a clear flag. So I honestly don't know what happened.

In any case it is correct now from what you say.

Regards

Pete

Link to comment
Share on other sites

This convention holds throughout everything. not only my code, but all programs everywhere.

I concur with this, but I didn't report it because I thought you were following this Lua expression condition:

http://lua-users.org/wiki/ExpressionsTutorial

Note on test expressions and nil

An important point to note is that the value 0 is not a false test condition in Lua. In some languages, for example C, a test of:

if (0)
  printf("true");
else
  printf("false");

Also, this has been working as originally described since at least 4.739 so I don't know what else it will break and for whom.

Link to comment
Share on other sites

I concur with this, but I didn't report it because I thought you were following this Lua expression condition:

Sorry, I've never seen that. What part is relevant? I'm not sure what point you are making. Surely if a flag is set then testing it should return "TRUE" and vice versa.

An important point to note is that the value 0 is not a false test condition in Lua.

Correct. You have to test whether the result is "true" or "false". All numbers and all strings and all other things other than "nil" and "false" are TRUE in Lua. I don't like it, being used to C, but there it is.

if (0)

printf("true");

else

printf("false");

That doesn't work in Lua, and is opposite of correct in C.

Also, this has been working as originally described since at least 4.739

"As originally described"? You mean it is described incorrectly somewhere? Please tell me where.

Pete

Link to comment
Share on other sites

Sorry, I've never seen that. What part is relevant? I'm not sure what point you are making. Surely if a flag is set then testing it should return "TRUE" and vice versa.

The part meaning 0 is true. Clearing a flag would cause it test 0, and should be false (a cleared flag is false, it's not set, but might read 0 which according to that convention is "true"). So it depends on whether testflag() was returning a boolean primitive or a number. If a number - 0 or the set bit - it was correct before since "if testflag()" would have evaluated to true when cleared and false otherwise. If that changed to a boolean primitive it is now correct.

I meant working since I've hacked together my ThrottleManager a few months and versions ago which worked as I described (that clearflag resuted in testflag equating to true).

Link to comment
Share on other sites

The part meaning 0 is true

But in Lua all values are TRUE except "false" and "nil". strings are true, all numbers are true. Functions are true. Arrays are true. Only false and nil are false.

For me it is probably the most annoying thing about Lua, but there you are. it is what it is.

it was correct before since "if testflag()" would have evaluated to true when cleared and false otherwise.

No, that could never have been correct. If it returned a number and you compared it to "true" or "false" it would be "true" no matter whether you cleared or set the false, because in Lua all numbers are true!

If that changed to a boolean primitive it is now correct.

As far as I know it was always a BOOLEAN, but I only recently corrected the documentation to make that explicit. I've not changed the code, only the documentation.

Regards

Pete

Link to comment
Share on other sites

As far as I know it was always a BOOLEAN, but I only recently corrected the documentation to make that explicit. I've not changed the code, only the documentation.

Clearly something changed between at least these two versions. I can live with it, but it'll likely break a lot of people's scripts like it did mine.

Link to comment
Share on other sites

Clearly something changed between at least these two versions. I can live with it, but it'll likely break a lot of people's scripts like it did mine.

Hmm. Well, I'd like to know what actually changed other than the documentation. In that I clarified where it said "x = ipc.testflag" which implied X was a number to "boolean = ipc.testflag", as it should really have been documented in the first place.

Anyone who programmed Lua expected a cleared flag to be TRUE when tested would surely have incorrect logic in the first place! It simply wouldn't make any sense.

Regards

Pete

Link to comment
Share on other sites

Hmm. Well, I'd like to know what actually changed other than the documentation. In that I clarified where it said "x = ipc.testflag" which implied X was a number to "boolean = ipc.testflag", as it should really have been documented in the first place.

Anyone who programmed Lua expected a cleared flag to be TRUE when tested would surely have incorrect logic in the first place! It simply wouldn't make any sense.

Regards

Pete

It did seem counter-intuitive to me at the time, but I didn't question the logic, I just went with how/what worked. And when that changed on the upgrade to 4.749d I thought I'd point it out. In any case, whatever changed doesn't matter to my script any more, as I changed it to ignore the actual flag state and keep state internally, as long as I get events on toggling. This way it works with either version of FSUIPC.

Link to comment
Share on other sites

It did seem counter-intuitive to me at the time, but I didn't question the logic

Well, I wish you had. Now I no longer have the source for that version and cannot see how or why it changed I'll never understand how it could have been wrong. I have a set of test Luas I use to check things and I'm sure I would (should) have spotted it if wrong, and if I didn't, how did it correct itself?

Seems it will remain a mystery forever.

Regards

Pete

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.