You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@rp- I've been wanting to run an idea past you for a while: what do you think of changing the various exporters to export to a data format (probably JSON), and then generate the Python API from that?
The main reason I want to do this is so that making changes to the shape of the Python API doesn't require going through DCS to re-run the exporter. Instead we could just re-run the JSON-to-python script. Should make maintenance a lot easier.
Another reason I'd like this is so that we can make it so that modded aircraft in Liberation can actually be a mod. Since it's all compiled-in Python atm, we can't actually let users provide support for their own mods. If users could just do the export themselves and put the JSON in their Saved Games directory where we can dynamically inject it into pydcs, it would make aircraft mods significantly cheaper for us to support (with the status quo, we've effectively stopped accepting new aircraft mods because they're a pretty large burden).
I think when loading these dynamically we'd want some new APIs. Dynamically creating types for every airframe is very doable, but for our use case that hasn't been very ergonomic (iterating over class members instead of just calling an iterator for doing things like finding pylon information, for example). Those APIs work wonderfully when you're interacting with a known airframe (code completion and everything!), but are a burden for callers as dynamic as Liberation, since we only ever work with an unknown Type[FlyingType]. I think it'd be pretty straightforward to keep generating the existing API for the use cases where that performs better even if we do need to add some new ones. Could possibly even implement one in terms of the other so we don't have divergent bugs?
I think the best way to do that would be to create a new repo just for the data dump. If you like the idea, I'll start that work in a new repo of my own. Once you're happy with it, I can move it into the pydcs org (or it can live separately if you prefer that). If you'd rather create a new dcs-data repo in the pydcs org up-front and have me send PRs, there, that works too.
I'd also like to contribute some of the hand-maintained airport data we have to that same repo (ICAO, ATC, TACAN, ILS, etc).
If that all sounds good, my first step would be to update the exporter to dump JSON, then generate all the existing APIs from that data. No user visible changes in the first PR.
The text was updated successfully, but these errors were encountered:
@rp- I've been wanting to run an idea past you for a while: what do you think of changing the various exporters to export to a data format (probably JSON), and then generate the Python API from that?
The main reason I want to do this is so that making changes to the shape of the Python API doesn't require going through DCS to re-run the exporter. Instead we could just re-run the JSON-to-python script. Should make maintenance a lot easier.
Another reason I'd like this is so that we can make it so that modded aircraft in Liberation can actually be a mod. Since it's all compiled-in Python atm, we can't actually let users provide support for their own mods. If users could just do the export themselves and put the JSON in their Saved Games directory where we can dynamically inject it into pydcs, it would make aircraft mods significantly cheaper for us to support (with the status quo, we've effectively stopped accepting new aircraft mods because they're a pretty large burden).
I think when loading these dynamically we'd want some new APIs. Dynamically creating types for every airframe is very doable, but for our use case that hasn't been very ergonomic (iterating over class members instead of just calling an iterator for doing things like finding pylon information, for example). Those APIs work wonderfully when you're interacting with a known airframe (code completion and everything!), but are a burden for callers as dynamic as Liberation, since we only ever work with an unknown
Type[FlyingType]
. I think it'd be pretty straightforward to keep generating the existing API for the use cases where that performs better even if we do need to add some new ones. Could possibly even implement one in terms of the other so we don't have divergent bugs?I think the best way to do that would be to create a new repo just for the data dump. If you like the idea, I'll start that work in a new repo of my own. Once you're happy with it, I can move it into the pydcs org (or it can live separately if you prefer that). If you'd rather create a new dcs-data repo in the pydcs org up-front and have me send PRs, there, that works too.
I'd also like to contribute some of the hand-maintained airport data we have to that same repo (ICAO, ATC, TACAN, ILS, etc).
If that all sounds good, my first step would be to update the exporter to dump JSON, then generate all the existing APIs from that data. No user visible changes in the first PR.
The text was updated successfully, but these errors were encountered: