Author Topic: Thoughts on an API  (Read 3657 times)

ceo1944

  • Newbie
  • *
  • Posts: 10
Thoughts on an API
« on: March 02, 2012, 11:09:28 pm »
I must say this is an outstanding add-on and one we've all been needing for quite some time, it fills in a hole and adds an enormous boost of realism to ground operations.  It's very, very well done congratulations to the developers!

I'm the developer of FSCaptain and I'm excited about interfacing it to GSX.  As a fellow developer I know how busy you must be right after a product launch but I've read about how you're considering an API and so thought I could contribute some ideas here.

A list of exactly what I wanted in a ground services API would look something like this:

1.  Use XML LVars for the command and status interface items.
2.  Allow the same commands and options from the API that users can select from the menus, except of course for things like setting parking space options.
3.  Place the progress status of the current operation in an Lvar so we can monitor it.
3.  Reject invalid/inappropriate commands with an error code in an otherwise zero Lvar.
4.  Allow a process to be ended via a command (i.e. end the boarding/catering at any time.)
5.  Allow options to suppress green-line messages and control volume of boarding sound levels.

At every stage of the ground process, FSCaptain already knows what should be going on; it would be wonderfully realistic to just have these things happening, with status updates on the ACARS, without the user having to see or manipulate a menu ever.

I can see nearly every FSCaptain user wanting GSX if we can work out an API that would allow this.  Perhaps some GSX users might have a look at FSCaptain too :)

Thanks for listening,
Dutch

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 50659
    • VIRTUALI Sagl
Re: Thoughts on an API
« Reply #1 on: March 03, 2012, 12:17:46 am »
Yes, we are very busy right now, there are just so many things we can add, because the foundation that has being laid out is much more powerful than what GSX does now.

Every suggestions for an API is very welcome, but it's maybe best to wait until the product is more established in its features, we'd rather not breaking other developers work with large changes, which are still happening now.

Quote
1.  Use XML LVars for the command and status interface items.

Not sure about using LVars for communication between GSX and other addons.

We don't want to have a different API for in-process (.dll/.gau) modules and out of process modules ( external .exe ) and while LVars are easy to access by dll modules and gauges, they can't from an external process, unless using something like FSUIPC is used but, since GSX doesn't require it, it wouldn't be a good idea to put it as an additional requirement for a GSX addon. On top of that, communicating only via LVariables means that to handle events, there must be some kind of polling, which is not very nice or efficient.

Simconnect, for example, provides both the ability for two FSX clients to handle custom events  ( see the documentation SimConnect_MapClientEventToSimEvent, used with "Custom.event" ), and the ability to define a data area ( see SimConnect_CreateClientData ) that clients can access. Once you have events and a data area, every communication is possible, and Simconnect can provided the needed infrastructure, which can also routed on a network.

Quote
5.  Allow options to suppress green-line messages and control volume of boarding sound levels.

This should probably belong to a setting in GSX itself, rather than an API that addons can call. What would happen if two GSX addons running together tried to set a different volume level, at the same time ?

ceo1944

  • Newbie
  • *
  • Posts: 10
Re: Thoughts on an API
« Reply #2 on: March 03, 2012, 06:37:47 pm »
Thanks for the quick reply, Umberto!

You're correct that waiting until the feature set settles is the right thing to do.

You're right about the Lvars being difficult to use with an external program.  Whatever method you pick we'll use.  The important thing is to be able to start, monitor, and stop GSX services from the client program.

We'll be awaiting the time when you start in working on it and eager to interface with GSX.

Good work, and good support!
Dutch