Problem with offset 0x0842

[robvanderwiele]

Hello Peter,

After upgrading to version 4.05 the offset 0x0842 doesn't work anymore. I also checked version 4.052 but stil the same. After switching back to 4.04 it is working again. I could use offset 0x02C8 instead but I didn't tried that yet.

Regards, Rob

[Pete Dowson]

After upgrading to version 4.05 the offset 0x0842 doesn't work anymore. I also checked version 4.052 but stil the same. After switching back to 4.04 it is working again. I could use offset 0x02C8 instead but I didn't tried that yet.

Ooops! Yes, you are right. The changes to try to speed things up by reducing the different messages sent to me by SimConnect messed it up. Also, by the looks of it, some of the DME character strings.

I'll fix that in the next increment release, or maybe it will be 4.06, probably on the weekend.

Regards

Pete

[robvanderwiele]

Thanks for your quick reply Peter. I can live with version 4.04 for the time being.

Rob

[robvanderwiele]

Hello Pete,

Just gave version 4.06 a go but still the same problem with offset 0x0842. I changed the offset in my code to 0x02C8 and this one does work!

Regards, Rob

[Pete Dowson]

Just gave version 4.06 a go but still the same problem with offset 0x0842. I changed the offset in my code to 0x02C8 and this one does work!

HmmI'll re-check. I might need more information then, as it looked okay here when I checked it. There were some other changes afterwards, but they shouldn't have affected this.

BTW I mistakenly referred to 02C8 in the Release Notes. I've got a bad cold/flu at present and have been unable to concentrate as well as I usually do, let alone work the long hours!

Regards

Pete

[robvanderwiele]

Hello Pete,

Just let me know if I can be of any assistance to you. I noticed that in the Fsuipc4 Offsets Status document there is a question mark behind offset 0x0842 and an ok behind 0x02C8. Maybe I should have used that one in the first place. But still it is odd that is was working with version 4.04 and before.

Take care, no hurry needed.

Rob

[skydriver]

Pete,

I've just found the same problem! Should have checked the forum 1st :shock:

Will you be able to fix the value in 0x0842 before your next release?

All of my FS2004 code is using 0x0842 and I would like to continue using it in FSX

:D

[Pete Dowson]

I've just found the same problem! Should have checked the forum 1st :shock:

Will you be able to fix the value in 0x0842 before your next release?

Haven't you tried 4.063 available above? I pretty sure I fixed it way back in version 4.061, directly after the reports above!

Pete

[skydriver]

Pete,

It's working in v4.063 - Thanks!

However, I seem to be having a problem with the flaps (0x30F0) compared to FS2004. They don't seem to return to 0 (instead they go to approx 17).

Has anyone else experienced this?

:?

[Pete Dowson]

However, I seem to be having a problem with the flaps (0x30F0) compared to FS2004. They don't seem to return to 0 (instead they go to approx 17).

Ah. As part of the changes I've been making to speed up FSX when FSUIPC4 is installed, I tell SimConnect not to send changes of less than some specified significance. The Flap angles at 30F0 and following are in degrees x 256, but I don't currently get notified of changes of less than a degree. I can change that, but it seems excessive to be notified of every change of 1/256th of a degree.

I'll change these to be more accurate, but can you tell me what you need these for, exactly, and why a value of 17 (representing about a sixteenth of a degree) is a problem?

There may be many other variables like this, but I have no idea who uses what and how. The more traditional (since FS98) flap indications down at 0BE0 etc are working okay.

Regards

Pete

[skydriver]

However, I seem to be having a problem with the flaps (0x30F0) compared to FS2004. They don't seem to return to 0 (instead they go to approx 17).

Ah. As part of the changes I've been making to speed up FSX when FSUIPC4 is installed, I tell SimConnect not to send changes of less than some specified significance. The Flap angles at 30F0 and following are in degrees x 256, but I don't currently get notified of changes of less than a degree. I can change that, but it seems excessive to be notified of every change of 1/256th of a degree.

I'll change these to be more accurate, but can you tell me what you need these for, exactly, and why a value of 17 (representing about a sixteenth of a degree) is a problem?

There may be many other variables like this, but I have no idea who uses what and how. The more traditional (since FS98) flap indications down at 0BE0 etc are working okay.

Regards

Pete

Pete:

Thanks for the information - the project I am working on looks for a reading of zero to indicate: "The flaps are up".

From this - the application takes various actions based on the aircraft "Having its flaps up". A non-zero value throws this off as you can imagine.

At other flap settings, similar actions are taken, based on the flap setting in degrees. The settings in degrees are handy as it is not necessary to perform any other calculations to determine this from a proportion of the overall flap range.

This all works great with 2004.

Thanks for your help!

[Pete Dowson]

the project I am working on looks for a reading of zero to indicate: "The flaps are up".

Is that all? Odd to choose one of 8 possible flap angle indicators just for that. And even the percent values (30E0 and following) should be more speciific. The traditional values for such basics are those at 0BE0 and 0BE4, which have been valid and guaranteed since FS98 days. All the values above 2000 are extras which really need feedback to prove okay.

I'll change it to be more accurate, but these sorts of things are overheads in FSX, as they depend on TCP messages arriving from SimConnect. In previous versions of FS these offsets were simply mapped through to memory locations inside FS.

For most real-world values, the general philosphy should probably be to treat values in "ranges". In this case 17/256ths of a degree is as good as "flaps up", for instance.

Anyway, I'll fix it, so look out for 4.064 or maybe 4.07 in due course, maybe a few days.

Regards

Pete

[skydriver]

All the values above 2000 are extras which really need feedback to prove okay.

...

Anyway, I'll fix it, so look out for 4.064 or maybe 4.07 in due course, maybe a few days.

Regards

Pete

Pete,

I'm using the following values over 2000:

CONST VOR1Identity = 0x3000

CONST VOR1Name = 0x3006

CONST TRAILING_EDGE_LEFT_FLAP = 0x30F0

CONST TRAILING_EDGE_RIGHT_FLAP = 0x30F4

CONST FS_COM2_FREQUENCY = 0x3118

CONST AGL = 0x31E4

CONST SURFACE_TYPE = 0x31E8

CONST ATCFlightNumber = 0x3130

CONST ATCTailID = 0x313C

CONST ATCAirlineName = 0x3148

CONST ATCAircraftType = 0x3160

CONST HOTKEY_READ_DATA = 0x320C

CONST AltimeterReading = 0x3324

CONST READY_TO_FLY = 0x3364

CONST IN_MENU_OR_DIALOG = 0x3365

CONST ZERO_FUEL_WEIGHT = 0x3BFC

CONST CURRENT_AIRCRAFT_PATH = 0x3C00

CONST CURRENT_AIRCRAFT = 0x3D00

I understand why you're trying to cut down on the messages from FSX in order to speed up FSUIPC, but this completely breaks backwards compatibility! One of the huge advantages FSUIPC provides for developers is that it acts as middleware, shielding us from any changes MS makes in new versions of FS 8)

Good luck!

[Pete Dowson]

I'm using the following values over 2000

Most of those aren't continuous variables so aren't in any way affected by any attempts to gain efficiency. Of the continuous variables, as an example, you don't really need to have the AGL accurate to 1/65536ths of a metre, do you? The flap angle values are only an exception because of the apparent need to test for "special" exact values such as exactly 0.0000 ...

I understand why you're trying to cut down on the messages from FSX in order to speed up FSUIPC, but this completely breaks backwards compatibility!

Well, sorry, but you are looking at it the wrong way around. What I have to do, to counter all the changes between different versions of FS, is try to create compatibility -- there's actually none of it to break in the first place without all the work that goes into it.

The work involved in each and every release is slow and painstaking, and much of it depends upon feedback. This is no different now, with the new methods used in FSX, than it was before. In each version I have had to find different ways of getting compatible information, and there are always some areas which are not quite right in the initial months following each new release. Without folks using, testing, observing the values and feeding back there would be many more differences continuing well into an FS version's lifetime. Believe it or not I am still occasionally told of differences between FS2002 and FS2004 values which I then rectify.

Oh, and I'm not trying to "speed up FSUIPC". It makes no difference to FSUIPC. I am only trying to reduce the impact on FSX's performance, which is dismal enough as it is. I have always been engaged in such improvements in all releases, it is just that this particular one affected your program, and I agreed to fix it. Okay?

Regards

Pete