Time to time there are requests for new functions for the plug-in developers. To keep all the plug-ins fully compatible I did not add them to the current API.
On the other hand it is also time to go to 64 bits with EuroScope. That surely requires all the plug-ins to be at least recompiled.
So I would couple the things:
Update the API to have more features and also easier to be extended in the future.
Go to 64 bits exclusively.
There will be several updates before this will happen. So the target release is not the next one
Please use this thread to register all the requests you would like to see in the updated API.
Thank you for reaching out in this matter. I think it’s a good approach, which obviously will require some effort, also the developer side. But I think if there is already a change that requires updates for the plugins, it’s worth to make a big one.
Here are some things from the big stack of wishes for the API:
Support mouse middle click
Read the users current ES version (to enable/force compatibility with different ES versions)
Read the currently loaded plugins
Read the client information from other users (like the .inf command) and provide that in a structured form (also to check compatibility and or plugin availability of other users when interacting with them)
One big thing we’d like to see is flagging event data. You already do this with controller-assigned data but nothing else, and it makes identifying why the event has been raised a challenge.
We’d also like to be able to readthe sequence field.
While Jonas posted a few worthy updates, I will go further:
not only middle mouse click support, but entirely mouse/keyboard event interaction, including scroll events,
Make it easier to access a message loop for some more commands if possible (i.e. mouse click outside Registered Object - now possible with making the mousehook, but that’s kinda pain),
anything making GDI+ less hassle would be nice (now, we need to draw everything manually and then do an entire GUI logic with your Event trigger commands),
access to heading drawer!
access to sending a message (i.e. on limited access, as we already discussed on email a few years back - some potential violations over the network can happen, but i.e. automatic CTOT update sent on private message by Delivery controller would be awesome to see. So maybe on limited timeframe or rate of sending a message, i.e. no more than 10 messages at once, and not more than X per few minutes to block potential spam, and only when logged in as a controller (even with a higher rating than S1) ),
User CID and Name to be read
manipulation of simulated traffic (to i.e. create custom panels/connections for easier simulation control, not only on the tags)
access to VCS (again, writing/integrating custom panels, or even doing 3rd party client that connects ES internal VCS with AudioForVATSIM for finally true VCS)
I know ES is not multithread safe - so something on this field maybe?
Not trully PlugIn API, but I would love to see a possibility to change ES titlebar colors - most of the ATS systems are gray, so a native support to this would be a nice feature
dynamic sector ownership assignment - possibility to change set of sector ownerships by plugin. If it was propagated in any way to others it would be even better.
/Edit: and access to send pings and event trigger OnPingReceived function
I second the dynamic sector ownership, this would be a total game changer for many vACCs. This need not be a change to the plugin API, although I think it would be the ideal solution. It would be sufficient to extend the current sector ownership dialog to propagate changes to all controllers affected by the new ownership.
manipulation of simulated traffic (to i.e. create custom panels/connections for easier simulation control, not only on the tags)
thread safety / handling - (running plugins on a separate thread)
Having a plugin cause a freeze is annoying. This can be avoided. I mitigated this by processing everything asynchronously, but this of course adds more complexity.
personal thoughts:
client connect / disconnect event - would be a good way to start / trigger plugin logic only once someone has connected / disconnected. During testing I observed that the OnControllerDisconnect does not trigger when the own client disconnects, but I may be wrong here. Of course you can check the connection type on a regular basis, but an event should be the better solution.
interoperability of plugins:
cache tag items - someone else’s suggestion, I’m just forwarding it.
Pass the old tag item into the OnGetTagItem function, this would allow one to use things like try lock or update the tag item based on the old one.
access other plugins tag items - would be nice to access other plugins tag items
move plugin synchronisation from scratchpad string to separate event. It would be nice if we could move plugin sychronisation from using the scratchpad to a separate event / function. My suggestion would be to create a separate event, something like OnPlugInMessage() with the plugin name, the message and maybe the radar target / callsign.
improved documentation - there is some information missing in the documentation, e.g. what FlightStripAnnotations are and how they are used.
modified communication between AFV and ES regarding sending info about Callsign transmitting audio. Now this works thru specific hidden window, would be nice to work thru websockets or something.
option to programmatically work with active airports/runways based on some external data.
option to add custom lists (like departure, startup etc) which would have no connection to flight plans - just generic lists for other data.
I’ll probably come up with more later on, but here are some ideas that come to mind:
Extend OnGetTagItem, making it possible to draw colored backgrounds and borders to tag items, and to have the information available whether the item is being drawn on an untagged, tagged or detailed level.
Make it possible to draw a colored border around a label
Make it possible to send messages between connected EuroScope instances (to be able to keep plugin data synchronized between the main and all proxy instances)
Make it possible to send messages to other controllers’ plugins (and something like OnPlugInMessage as suggested above to handle them)
A broad request, but generally the ability to get/set as many as possible of the EuroScope settings, colors, active runways, radar antenna on/off status, etc., so anything you can now set using a dialog window within EuroScope could also be set using a plugin.
Change InitiateCoordination so that specifying the target controller is optional, or provide another function where EuroScope sets the target controller automatically according to whatever EuroScope would itself use for that coordination point/level.
Make it possible to coordinate “next controller” as well as point/level
Make it possible to probe the effect of a level or direct-to clearance like already exists in the EuroScope default menus on mouseover an item where the profile is temporarily updated accordingly without actually having to set the clearance.
Another note, while I know it’s probably tough to say @904331 , but is it matter of weeks or rather months (years?) to complete? I would like to know as I’m in the middle of digging into my plugin, and I’m not sure if I should wait as potentially my code will become obsolete or not.
It would also be cool if the label anker line (line from the target to the label box) could be used/coloured separately. I know RL systems which use this particular part to provide some kind of indications.
A functionality that should even be added to the default ES capabilities is the coordination of speed (same as COPX, levels) restrictions (including “or greater”, “or less”). I tried an implementation with a plugin including specific additional values for “minimum speed”, “minimum clean speed” and “high speed”. Unfortunately due to the missing support for autotext triggers, text pilots cannot be supported.
Coordination capabilities should also be extended to include headings.
Another long missing feature is the type of approach being somehow integrated. This should be an extra field that can be selected for every approach. Ideally the available types (per runway, and/or depending on the selected STAR/APP) can be configured. The default type of approach should also be added to the runway dialog, from where it finally can make its way to the ATIS (remember many of the ATIS URLs include a hardcoded type of approach, because there is simply no variable for this in ES).
+1 for getting other plugins’ and built-in TAG items. Useful for radar screen plugins and for a complex list plugin I was attempting to build (would have a more complex sorting system)
It would be nice to get access to all the VATSIM network data that EuroScope downloads. The flightplans are already available to the plugins, but how about ATIS and controller connections and prefiled flightplans?
I know that this is probably not really an API request, but it would be great to have access to the velocity packets to get faster scan rates on PAR scopes.
ES already has them, as it can forward them to proxy clients, but you can’t access them through a setting or on the plugin interface. I would prefer if you could enable “fast scan rate” through a setting in the ASR, but if that is too much work having access to them on the API would also work fine for that application.
There are a number of things that can be set with a specific text string in the scratch pad. Maybe rather than creating specific functions, there could be a single one providing a selection of values as a parameter as to what action should be done. This function can then send this string, but preserve the scratch pad text if there was any set by the user.
Another request would be to have the aircrafts radio call sign from the ICAO_Airlines file, so that plugins don’t need separate routines to access such data.
