Jump to content
The simFlight Network Forums
juengelj

FSX Event and Offset Equivilents

Recommended Posts

Hey All,

First of all I would like to thank Pete Dawson for developing a VERY useful tool for sim builders to use. Thanks!

Ok, I am somewhat off and running on my first simulator build. I have decided to model my simulator after the CRJ-700. The first this I have done is mapped all the Auto Pilot buttons to hardware buttons using FSUIPC and IOCards. They work great. The problem I am having, is that the center button in the rotary encoders are to be mapped to the CRS, HDG, SPD, ALT "set" functions respectively.

They should work like this:

1) The CRS button will change the CRS pointer to the current heading, and the readout should display zero-wind direction to VOR.

2) The HDG button will change the HDG bug to current heading.

3) The SPD button will change the SPD hold to the current SPEED or MACH value.

4) The ALT button will change the ALT hold to the current Altitude.

I cannot seem to find these offsets in the offset list documentation. However, they do show up in the FSUIPC event/control drop-down menu's.

Can anyone point me in the right direction?

Thank you very kindly for your help, in advance.

-Jeremy

Share this post


Link to post
Share on other sites

1) The CRS button will change the CRS pointer to the current heading, and the readout should display zero-wind direction to VOR.

2) The HDG button will change the HDG bug to current heading.

3) The SPD button will change the SPD hold to the current SPEED or MACH value.

4) The ALT button will change the ALT hold to the current Altitude.

I cannot seem to find these offsets in the offset list documentation. However, they do show up in the FSUIPC event/control drop-down menu's.

You are mixing up "offsets" (which are effectively addresses of data in memory) with FS event or control numbers, which are simply numbers representing an action.

ACTIONS are controls, which have names (as listed in the FSUIPC assignment drop-downs) and numbers (which is how they look internally).

DATA, such as the current heading, is held in memory and identified in (FSUIPC only) by OFFSETS, which are hexadecimal numbers related to the data's original position in one of FS98's modules == it was in 1998 that FS still actually maintained such data areas! The whole notion of "offsets" dates from then.

If you need to identify offsets you need the FSUIPC SDK, which includes a full list.

If you need to identify FS control numbers you can use logging, as you have done, or you can simply look them up in the list installed for you in the FSUIPC Documents folder in FS Modules.

Note that FSUIPC also adds its own set of "controls". These and their numbers are listed in the Advanced Users Guide.

Regards

Pete

  • Upvote 1

Share this post


Link to post
Share on other sites

You are mixing up "offsets" (which are effectively addresses of data in memory) with FS event or control numbers, which are simply numbers representing an action.

ACTIONS are controls, which have names (as listed in the FSUIPC assignment drop-downs) and numbers (which is how they look internally).

DATA, such as the current heading, is held in memory and identified in (FSUIPC only) by OFFSETS, which are hexadecimal numbers related to the data's original position in one of FS98's modules == it was in 1998 that FS still actually maintained such data areas! The whole notion of "offsets" dates from then.

If you need to identify offsets you need the FSUIPC SDK, which includes a full list.

If you need to identify FS control numbers you can use logging, as you have done, or you can simply look them up in the list installed for you in the FSUIPC Documents folder in FS Modules.

Note that FSUIPC also adds its own set of "controls". These and their numbers are listed in the Advanced Users Guide.

Regards

Pete

Thank you, Mr. Dowson, for such a timely reply. I am still digesting what you said. I have a tremendous amount of respect for programmers like yourself, and hope one day to be half a good as you... So, if I understand you correctly. (FYI, I am using SIOC to interface with FSUIPC, which is an event driven scripting "language", that you may or may not be familiar with. I don't intend to insult your intelligence, nor breadth of experience, only stating possibly pertinent information.)

Basically,

1) FSUIPC interfaces with FSX via the Microsoft predetermined list of simulator "controls" for possible "events".

2) When one maps a hardware action from an input (controller, switch, etc...) recognizable by FSUIPC as a controller input, FSUIPC tells FSX to perform the "event" that the user assigned to it via FSUIPC. (USER_INPUT --> FSUIPC --> FSX)

3) FSUIPC has it's own controls, that it can tell FSX to perform? (I don't understand that) Wouldn't FSX need the control listed to perform it? Sorry for my ignorance.

4) (Memory Allocation) - Events have predetermined memory locations assigned to them. Of which, they hold the data that contains the current state of any given event? If an event occurs, the information starting at that location (offset 0x0000) updates to reflect the change, if applicable. I am assuming this is why you have to define the size of the word? (1, 2, 4, etc...)

Ok, if those assumptions are true... then here is where SIOC comes in. From what I understand, SIOC is an interface between hardware and FSUIPC via offsets. So, if I understand this correctly... SIOC is basically poking the information at a given memory address that FSUIPC uses to update simulator events. Since SIOC is event driven, it responds to changes is the data contained starting at the referenced offset.

(SIOC Example -

Var 1, named FSX_LIGHTS, LINK FSUIPC_INOUT, Offset $07DC, Length 4

If &LIGHTS_SWITCH = 1

&FSX_LIGHTS = CHANGEBITN 0 &FSX_LIGHTS

Var 2, named LIGHTS_SWITCH, LINK IOCARDS_SW, Input 1, Type P

)

All that said, I don't think I am fully understanding the derivative of the offsets. The list of offsets that you provide in the SDK are those defined by You (FSUIPC)? or by FSX? In other words, is there a 1 to 1 correlation between the FSUIPC events list, and the Offsets List, meaning for every "possible" event there is a predefined memory address or offset assigned to it? Because I cannot find an applicable offset, for an event that FSUIPC references.

I know you do not "support" IOCards nor SIOC... That information is given for reference only to help clarify my question.

Anyway, I hope that I have NOT confused anyone with my ramblings...

As always, thanks in advance for all your help! I really do appreciate it.

-Jeremy

Share this post


Link to post
Share on other sites

1) FSUIPC interfaces with FSX via the Microsoft predetermined list of simulator "controls" for possible "events".

No. FSUIPC interfaces with FS by all means possible, including its event system -- which, incidentally, is the very same event system you use when assigning keys and buttons and axes in FSX's own assignments. There's no difference, except FSUIPC exposes ALL of the events defined in FSX, whether they are useful or not and whether they work or not, whereas FSX only exposes those the authors deemed okay for such exposure.

If the only function of FSUIPC was to provide a slightly wider source of events, it would never have been writrten and wouldn't be worth supplying or using.

2) When one maps a hardware action from an input (controller, switch, etc...) recognizable by FSUIPC as a controller input, FSUIPC tells FSX to perform the "event" that the user assigned to it via FSUIPC. (USER_INPUT --> FSUIPC --> FSX)

That's certainly one possibility, just as FSX would do if you assigned there. But FSUIPC offers a lot more possibilities. Please, why not read through the User Guide one day so you can see what is offered?

3) FSUIPC has it's own controls, that it can tell FSX to perform? (I don't understand that) Wouldn't FSX need the control listed to perform it? Sorry for my ignorance.

FSUIPC added controls are for functions added by FSUIPC. Please read the list!

4) (Memory Allocation) - Events have predetermined memory locations assigned to them.

No they most certainly don't! Where do you get such garbage from? I thought I clearly pointed out that events are ACTIONS! Memory contains DATA!

ACTIONS are things being done, maybe acting on data, maybe on something else. Some actions may result in data being changed, but that could be indirect, due to simulation simulating something happening.

DATA is just that, values, numbers, strings, whatever. It sits there. It is not an action!

SIOC is basically poking the information at a given memory address that FSUIPC uses to update simulator events.

Writing to some offsets triggers FSUIPC into sending Events to FS, some do other things. The offsets list tells you what they do, if anything. Many offsets are simply informative, doing nothing but providing information, for things like display on gauges, or reporting things, like weather data.

I don't think I am fully understanding the derivative of the offsets. The list of offsets that you provide in the SDK are those defined by You (FSUIPC)? or by FSX?

Mostly, nowadays, by me, by FSUIPC. But many were defined in FS98, as I also already explained. After FS98 most values previously directly accessible in FS at specific offsets in specific modules were no longer so. Microsoft gradually re-wrote FS using "object-oriented" programming techniques, whereby the values we use were boxed up tight in their own functional parts. They were re-exposed by myself working thousands of hours, and mapped back to the same "offsets", or at least it was made to look that way to applications so that they didn't need re-writing for each new FS version.

These values moved and changed from version of version of FS, and every time it took thousands of hours to re-map them. Finally, in FSX, Microsoft actually agreed to help, and devised SimConnect which made it a bit easier for me, but also necessitated a complete re-write of FSUIPC. Hence the separation between FSUIPC3 (which works with FS98, CFS1, FS2000, CFS2, FS2002 and FS2004) , and FSUIPC4 (which works with FSX, ESP and lately Prepar3D).

In other words, is there a 1 to 1 correlation between the FSUIPC events list, and the Offsets List, meaning for every "possible" event there is a predefined memory address or offset assigned to it?

No, not at all. Events are ACTIONS, Offsets contain DATA, or VALUES. One may influence the other, like if there's a "HEADING SET" it changes the offset containing the Heading -- and even possibly changing the offset containing the heading produces, perhaps, a HEADING SET event (but this latter part depends on implementation between FSUIPC and FS -- it probably actually doesn't, in this case). But you must not continue to confuse the two, or make any assumptions about how things are implemented internally.

Pete

Share this post


Link to post
Share on other sites

No they most certainly don't! Where do you get such garbage from? I thought I clearly pointed out that events are ACTIONS! Memory contains DATA!

ACTIONS are things being done, maybe acting on data, maybe on something else. Some actions may result in data being changed, but that could be indirect, due to simulation simulating something happening. DATA is just that, values, numbers, strings, whatever. It sits there. It is not an action!

Oh! OKAY. So... in other words.... "Controls" and "Offsets" are two ways of saying the same thing?

I like turtles... :)

Share this post


Link to post
Share on other sites

Sorry, just a bit of humor... anyways, thanks again for the prompt reply. From the top:

That's certainly one possibility, just as FSX would do if you assigned there. But FSUIPC offers a lot more possibilities. Please, why not read through the User Guide one day so you can see what is offered?

Sorry, I wasn't making my intentions clear. I am aware of the other "features", at least mostly, of FSUIPC and I use a lot of them. What I am looking at now, is expanding my simulator to include hardware. The goal is to build a full blown CRJ-700 cockpit as real to life as I can get, using FSUIPC, IOCards, and a lot of time learning new skills! :) So, everything I am asking is from that perspective... sorry for the confusion.

No they most certainly don't! Where do you get such garbage from? I thought I clearly pointed out that events are ACTIONS! Memory contains DATA!

ACTIONS are things being done, maybe acting on data, maybe on something else. Some actions may result in data being changed, but that could be indirect, due to simulation simulating something happening. DATA is just that, values, numbers, strings, whatever. It sits there. It is not an action!

Whoa! :) Ok, I think perhaps again I stated this incorrectly... yikes. What I meant to say/presume, which may be entirely incorrect as well, but at least it will accurately state my assumption, is whether or not certain memory locations are reserved to hold the specific "data" that the "events" act upon? In any case, this is precisely what I am trying to figure out. The "Offsets" are the locations where certain data starts, and can "sometimes" be manipulated to insert the data relating/resembling an action that can be used to drive an "action" (IE 0000 becomes 0001 to turn on a light), or just sit there and be readout at a later time. This you also explained below...

Writing to some offsets triggers FSUIPC into sending Events to FS, some do other things. The offsets list tells you what they do, if anything. Many offsets are simply informative, doing nothing but providing information, for things like display on gauges, or reporting things, like weather data.

Right! Am I still looking at this wrong, or is this solution easier than I think. In order change the data(HDG) for the HDG_Bug to the current HDG being flown (let's just say 145), does one need only to "Read" the value of HDG_Current at (0x0580) and the assign that same value to "HDG_Bug" at (0x07CC)? The only potential problem that I see, as I am not a programmer, is that the size allocated at each offset is different... one is 2 bytes, the other is 4. Basically, I am trying to manipulate the data related to the "AP_PANEL_HEADING_SET 66108" control that is listed in your FSX controls document.

Remember, I can NOT actually utilize FSUIPC to assign the button to that control listed, because for now, I am trying to find an implementation using these IOCards and SIOC. As such, I have to be able to read and manipulate data using offsets, rather than direct controls within FSX using FSUIPC.

...They were re-exposed by myself working thousands of hours, and mapped back to the same "offsets", or at least it was made to look that way to applications so that they didn't need re-writing for each new FS version.

Ok, now I get what you meant by the dating back to FS98. It was the original implementation used (utilizing offsets)... Thanks.

And again, I thank you for all the hard work you did, and continue to do. I definitely appreciate the fruits of your labor. I also find it amazing that you support the product the way you do in these forums, absolutely fantastic! I couldn't get that level of support from any other software I buy! :)

... Events are ACTIONS, Offsets contain DATA, or VALUES. One may influence the other, like if there's a "HEADING SET" it changes the offset containing the Heading -- and even possibly changing the offset containing the heading produces, perhaps, a HEADING SET event...

Wait... by "...it changes the offset containing the Heading...", do you mean it changes the data at the offset for the Heading? Because if it changes the actual offset location (from 0x0001 to 0x00A0), I am really confused and will likely toss myself off a bridge!

Thanks again Mr. Dowson!

V/R

Jeremy

Share this post


Link to post
Share on other sites

Hey Mr. Dowson,

WOW! After doing some more reading and research, I have come upon the solution to this problem... Again I must say that FSUIPC is absolutely amazing, thank you so very much for a wonderful tool. Here is a snippet that I hope other people who are trying to figure this stuff out for cockpit building, will find very useful. It looks like you can directly access the controls for FSUIPC through SIOC after all! YEAH! I am so very excited about all that I still have not learned. Can't wait...

Anyways,

This information was obtained at http://www.lekseecon.nl/howto.html very good source of info... enjoy.

Send FSUIPC Control in SIOC

From the "FSUIPC for Programmers.pdf":

FSUIPC offset $3110 (length 8) operates a facility to send any 'controls' to Flight simulator. Write all 8 bytes for controls which use a value, but just 4 will do for 'button' types. (The list of controls can be found in "List of FS2004 Controls.pdf")

In SIOC we can send such a FSUIPC control (with optional parameter) like this:

Var 1 name FS_CONTROL Link FSUIPC_OUT Offset $3110 Length 4

Var 2 name FS_PAR Link FSUIPC_OUT Offset $3114 Length 4

Var 3 Link IOCARD_SW Input 12 Type P

{

&FS_PAR = 1

&FS_CONTROL = 66712

&FS_CONTROL = DELAY 0 10

}

In this example each time the button is pressed we send a value 1 first and then the control (code) 66712. Note that after a delay of 100 msec we reset Var FS_CONTROL, otherwise it will not detect that another FS_CONTROL 66712 needs to be send.

Thanks again for helping me sort this through.

Share this post


Link to post
Share on other sites

]In order change the data(HDG) for the HDG_Bug to the current HDG being flown (let's just say 145), does one need only to "Read" the value of HDG_Current at (0x0580) and the assign that same value to "HDG_Bug" at (0x07CC)?

Yes, but they are in different units so you would need take care.

The only potential problem that I see, as I am not a programmer, is that the size allocated at each offset is different... one is 2 bytes, the other is 4.

In this case the size isn't so important. The one at 0580 is much more precise -- down to minute fractions of a degree. You can simply get away with ignoring the first two bytes (at 0580) and taking the next two (at 0582). You are then only losing parts of 1/65536ths of a degree!

However, it 's more than that.. 0580 is degrees TRUE. Normally the A/P is operating in Degrees MAGNETIC, so you'd have to do some arithmetic to convert it too, using the deviation at 02A0. Look it up, it is explained there how to do it.

Wait... by "...it changes the offset containing the Heading...", do you mean it changes the data at the offset for the Heading? Because if it changes the actual offset location (from 0x0001 to 0x00A0), I am really confused and will likely toss myself off a bridge!

No. When I say "changes the offset" I meant "changes the value at the offset". I'm slipping into the way many users talk when they use the term, as if offsets were the values rather than a reference to where they are (or rather were, in FS98). Sorry, I should be more precise.

Regards

Pete

Share this post


Link to post
Share on other sites

In this case the size isn't so important. The one at 0580 is much more precise -- down to minute fractions of a degree. You can simply get away with ignoring the first two bytes (at 0580) and taking the next two (at 0582). You are then only losing parts of 1/65536ths of a degree!

However, it 's more than that.. 0580 is degrees TRUE. Normally the A/P is operating in Degrees MAGNETIC, so you'd have to do some arithmetic to convert it too, using the deviation at 02A0. Look it up, it is explained there how to do it.

As always, very informative. Thank you again for taking the time to help me out with this. I think I am once again off and running on this adventurous CRJ project. The help/support you provide in invaluable. Keep up the great work!

God Bless

-Jeremy

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • 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.