Re: A new Flight Simulator
Posted: Sat Mar 03, 2018 6:00 pm
@bomber
1. Intuitively I think if the new sim pythonizes FDM for "making them", it does not explicitly forbid to export them in a way that plug-and-play any other system whose core-engine runs on JSBsim. In other words, the flight model could be just piped into a dir-structure with corresponding xmls, and transplanted modularly into a FG craft, per example.
I think the battle is not over the sexy stuff. I think the battle is over the paradygms of development. Read: How easy is for a new developer to create content addon that plugs and play. How easy is for that developer to have creative access over its content? In this, is where I am daring to say FG lags behind a lot for a GPL software.
Per example, take nasal. At its fundamentals, nasal is unnecesary to code an aircraft for FG. That is, if you can write in on C++ space, then you do not need really to go nasal. Nasal is trying to expose the property tree via some wrappers, and then provide a handful (not many) functions that access such property tree, so one can code without going C++.
Now, nasal is not precisely an elegant language. By all means! (difference of opinions here are existing, yet surprisingly). Now, if the core were to expose the property tree such that you can script onto it directly, without needing additional secondary coding translators (read nasal), then off course building aircrafts/scenery/other content in a way that you can rapidly access the internal properties suddenly should become much ... much.... easier.
I think, in that ease and the possibility of reusing code, is where a real advantage could exist.,
1. Intuitively I think if the new sim pythonizes FDM for "making them", it does not explicitly forbid to export them in a way that plug-and-play any other system whose core-engine runs on JSBsim. In other words, the flight model could be just piped into a dir-structure with corresponding xmls, and transplanted modularly into a FG craft, per example.
I think the battle is not over the sexy stuff. I think the battle is over the paradygms of development. Read: How easy is for a new developer to create content addon that plugs and play. How easy is for that developer to have creative access over its content? In this, is where I am daring to say FG lags behind a lot for a GPL software.
Per example, take nasal. At its fundamentals, nasal is unnecesary to code an aircraft for FG. That is, if you can write in on C++ space, then you do not need really to go nasal. Nasal is trying to expose the property tree via some wrappers, and then provide a handful (not many) functions that access such property tree, so one can code without going C++.
Now, nasal is not precisely an elegant language. By all means! (difference of opinions here are existing, yet surprisingly). Now, if the core were to expose the property tree such that you can script onto it directly, without needing additional secondary coding translators (read nasal), then off course building aircrafts/scenery/other content in a way that you can rapidly access the internal properties suddenly should become much ... much.... easier.
I think, in that ease and the possibility of reusing code, is where a real advantage could exist.,