pilotjohn Posted December 1, 2011 Report Share Posted December 1, 2011 Did the ipc.testflag functionality change in this version? I'm relying on it for my ThrottleManager, and it seems to be returning the opposite of what it used to. Link to comment Share on other sites More sharing options...
Pete Dowson Posted December 1, 2011 Report Share Posted December 1, 2011 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 More sharing options...
pilotjohn Posted December 1, 2011 Author Report Share Posted December 1, 2011 Not that I'm aware of. Compared to which version, 4.749c or something earlier? It returns true or false. How are you testing the result? Pete 4.745. I'm still investigating. Link to comment Share on other sites More sharing options...
pilotjohn Posted December 1, 2011 Author Report Share Posted December 1, 2011 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 More sharing options...
Pete Dowson Posted December 1, 2011 Report Share Posted December 1, 2011 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 More sharing options...
pilotjohn Posted December 1, 2011 Author Report Share Posted December 1, 2011 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 More sharing options...
Pete Dowson Posted December 1, 2011 Report Share Posted December 1, 2011 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 More sharing options...
pilotjohn Posted December 1, 2011 Author Report Share Posted December 1, 2011 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 More sharing options...
Pete Dowson Posted December 1, 2011 Report Share Posted December 1, 2011 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 More sharing options...
pilotjohn Posted December 1, 2011 Author Report Share Posted December 1, 2011 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 More sharing options...
Pete Dowson Posted December 1, 2011 Report Share Posted December 1, 2011 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 More sharing options...
pilotjohn Posted December 1, 2011 Author Report Share Posted December 1, 2011 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 More sharing options...
Pete Dowson Posted December 1, 2011 Report Share Posted December 1, 2011 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now