Jump to content

write arbitrary external app data to FS


Recommended Posts

Hello:

I have a requirement to implement a weapons/targeting display system for a military airfcraft simulation. It would be implemented as a separate executable from FS, communicating with FS via FSUIPC.

I need some of the data from this new subsystem simulation to be communicated back to Flight Simulator, so that it can be displayed in custom FS gauges. For example, targeting information could be displayed in a FS heads-up display.

Is there a way to communicate such data back to FS via FSUIPC? In other words, are there any "expansion" offsets where non-FS data can be placed, so that custom FS gauges can read data from custom external simulations?

Thank you for your support,

Tim Crews

GECO, Inc.

Link to comment
Share on other sites

Is there a way to communicate such data back to FS via FSUIPC? In other words, are there any "expansion" offsets where non-FS data can be placed, so that custom FS gauges can read data from custom external simulations?

Yes, there are offsets which can be specifically reserved for individual applications, as mentioned in the table in the Programmers Guide. You would need to work out your needs and let me know. I would register them to you and the project name. Try to keep your request down to as small an area as is adequate for your needs -- some multiple of 64 bytes (64, 128 or 256 fr instance).

Pete

Link to comment
Share on other sites

Pete:

I do now see the range of offsets that are "available for applications". I'm sorry I missed that the first time around.

If I succeeded in reserving offset 5280, for example, and I wrote an external application that writes values to that offset, would I use the "Library for FS Internal Users" to read data at that offset from my custom gauge code?

One thing that I failed to mention is that the application will not be publically available. It would be used internally for prototyping of real cockpit displays. So, I would certainly understand if you were uninterested in setting aside space in your offset map for applications that none of your customers/users would ever see.

(On the other hand, I do see a strong possibility that we will be contributing a Java API for FSUIPC when we complete this task, if that's something your users would find useful. )

If our use of the desired offsets is purely private, do we need to apply for reservations of offsets at all? Does FSUIPC have to do anything additional to support data transfer at these new reserved offsets, or are the offsets transferred by FSUIPC already? For example, if I decided to use offsets 6300-7424 for our private application, would this data make it through to our custom gauges without any additional FSUIPC changes?

If that answer to that question is No, I wonder if a chunk of locations could be set aside for private implementations? In other words, no publically available application should rely on this range of addresses for any particular purpose, but multiple different private applications could use this range of addresses for their own purposes. Of course, only one of these private applications could run at one time, since they would all be overloading the use of the same offset ranges.

Thank you again for your time,

Tim Crews

GECO, Inc.

Link to comment
Share on other sites

If I succeeded in reserving offset 5280, for example, and I wrote an external application that writes values to that offset, would I use the "Library for FS Internal Users" to read data at that offset from my custom gauge code?

Yes, Gauges and other internal programs must use the internal library (or equivalent code). They are in the same Process as FSUIPC, so the normal "IPC" (="inter-PROCESS-communication") method is not only inapplicable, it is horrendously inefficient by comparison.

Incidentally, you wouldn't actually choose the locations in FSUIPC address space yourself -- I have a more up to date list of the areas which are allocated, and would select an area for you when I know how much you need. The list in the SDK was only correct when it was published.

One thing that I failed to mention is that the application will not be publically available. It would be used internally for prototyping of real cockpit displays. So, I would certainly understand if you were uninterested in setting aside space in your offset map for applications that none of your customers/users would ever see.

Wel, certainly knowing that would help if you wanted a largish area, but I would otherwise try to assign something unique. You never know what other 3rd party additions you may use or try and you wouldn't want the surprise of having your data areas trampled on.

(On the other hand, I do see a strong possibility that we will be contributing a Java API for FSUIPC when we complete this task, if that's something your users would find useful. )

Actually, Mark Burton has already contributed a Java section for the SDK. It is ready here ready for inclusion in the next edition (within the next two or three weeks).

If our use of the desired offsets is purely private, do we need to apply for reservations of offsets at all?

Not for any technical reasons, only to avoid double use, as I mentioned above. Also, future versions of FSUIPC may use more. For instance, in FS2004 I am providing new Weather control facilities which use areas previously free. I'd need to allocate them and keep a record to avoid causing you problems in future.

Does FSUIPC have to do anything additional to support data transfer at these new reserved offsets, or are the offsets transferred by FSUIPC already?

It doesn't have to do anythng, but it is best if I reserve an area for you for the above-mentioned reasons. Otherwise you will have to stick with a know working edition of FSUIPC and not add any more third party stuff in case they also used your area.

If that answer to that question is No, I wonder if a chunk of locations could be set aside for private implementations? In other words, no publically available application should rely on this range of addresses for any particular purpose, but multiple different private applications could use this range of addresses for their own purposes. Of course, only one of these private applications could run at one time, since they would all be overloading the use of the same offset ranges.

That's certainly a possibility, but I would hate to lose a large chunk that way, and a small one may not be enough. I'd rather keep it the way it is for the time being. I will certainly bear your idea in mind though. Thanks.

Regards,

Pete

Link to comment
Share on other sites

Actually, Mark Burton has already contributed a Java section for the SDK. It is ready here ready for inclusion in the next edition (within the next two or three weeks).

Our project has a short fuse. It is should be more than half finished in two to three weeks. Would it be possible to get a "sneak preview" version of the Java SDK?

Tim Crews

GECO, Inc.

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
 Share

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