Jump to content
The simFlight Network Forums

Accessing FS2004 "New Weather Interface"


Recommended Posts

Pete,

Further to my last...

When I attempt to read a NWI offset individually the log shows an "8F" added to the front of the read. Here is the log entry for reading "uDynamics" in Area 0 i.e. C40C:

2128160 READ0 8FC40C, 1 bytes: 00

I am debugging here trying to figure what I may be doing wrong. Other non NWI reads work fine. Any ideas? FSUPIC 3.11

James

Link to comment
Share on other sites

When I attempt to read a NWI offset individually the log shows an "8F" added to the front of the read. Here is the log entry for reading "uDynamics" in Area 0 i.e. C40C:

2128160 READ0 8FC40C, 1 bytes: 00

I don't know why the Visual Basic programming books are so awful, because everyone asks the same question.

It seems Visual Basic sign extends any hexadecial value, so your "C40C" becomes "FFFFC40C". FSUIPC uses the top 16 bits as flags for assorted operations to do with WideFS and the AWI. It masks out the bits that it likes and this results in your 8F.

According to other VB programmers (and, I would hope, the VB programming books?) you have to post-pend another & to stop sign extension:

&HC40C&

I would have thought that specifying it as &H0000C40C would be specific enough, but no, the stupid compiler thinks it knows better and changes it to &HFFFFC40C, apparently without even mentioning it to you!

I have lost count how many times I've had to repeat this stuff, there must be many mentions already in this Forum.

Regards,

Pete

Link to comment
Share on other sites

Hi Pete,

I've read many books on VB cover to cover, and as reference, and have been aware of the VB style coercing, but have never ever had this problem before with FSUIPC stuff. My appologies for not gleaming it from the hundreds of messages here on the forum.

Thanks for the info, I will give it a go...

James

Link to comment
Share on other sites

I've read many books on VB cover to cover, and as reference, and have been aware of the VB style coercing

Ah, I'm glad it is documented! I did wonder. It seems quite bad having a language where even a value explicitly declared as &H00008000 is converted to &HFFFF8000 with no warnings, nothing. How did this slip into Microsoft's design I wonder?

but have never ever had this problem before with FSUIPC stuff. My appologies for not gleaming it from the hundreds of messages here on the forum.

No need to apologise. I suppose there ought to be a warning in the VB part of the FSUIPC SDK, but the individual parts aren't really mine, and not knowing anything about VB I am reluctant to interfere with what is already written.

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.