A new Flight Simulator

[IAHM-COL]

Hi Guys

This post is a fishing expedition.
I wanted to throw out there the crazy idea of making a new GPL flight simulator, as a feasible alternative to FlightGear.
There are so many essential elements of FG that are not done with future-proof in mind, and I'd like to see if there would be CORE-Developers that would be willing to consider jumping on such a Crazy Wagon.

The more people would be interested to participate, the more possible trying something of this nature could become.

I wrote an email to a friend about some philosophical principles I'd like to move forward: this post reproduces this idea:

If we decide to go this way, We would need to make some philosophical points; my ideas are :


1. License: Core being GPL (I wouldn't devote free time to a project otherwise)
2. Modularity should be a central philosophy. Hopefully Pluggability of extensions? Allowing these extensions to be rather open in terms of licensing.
3. A more logical better 3D rendering framework? maybe your blender idea? others? Performance here should be taken hard in consideration: As FG has become a Bloated software hard to run in low specs machines
4. I thing for PUI and core development, I'd love to go in a python framework (as oppose to PLIB?, C++, OSG?).
5. Terrain engine? Maybe using non-binary terrain lookup tables that can be directly generated from Shapefiles? (see gdal). This would be a rather different approach to the terragear system (as well as the crazy ideas of Terrain version 3 that the core move forward trying to damage TerraGIT, and which they seem to have already dropped;
Modularity on terrain would be critical
pythonize terrain? GDAL works really nice with python, too
6. 3D models. I think FG got it correct here, by using ASCII-based AC3 format. But any (1) open sourced, (2) text based non-binary alternative could be considered
7. FDM: Drop YASIM. Support Only JSBsim
8. Drop XML configurations. Maybe make configurations based on JSON-like structures
9. Kill nasal, completely. (that thing is the major FG bullshit), and make replace fully with python?
10. Drive development in a way that converting the current JSBsim FG aircrafts to the new FlightSim is not that difficult, so we can start porting?
11. Maybe write some python code that allows creating JSBsim using configuration files? so Converting YASIM crafts can be also be achieved?

AND FINALLY

12. Modularity, modularity, modularity and REUSABILITY
It will be great if we can per example make the aircraft development to be like python name-space creation? so any instrument is very pluggable and thus aircraft/scenery development is more similar to developing apps/plugins. And thus making and reusing instruments is fast and doable. I say this because most FG code is overbloated. Like instruments copied all over the place, and code lacking total reusability.

13. (PS:) Something else.
I am a multiplayer. I rarely use FG differently.
So, I think rethinking the MP server infrascture will be critical for me.
The capability to have a server that connects/interacts from other simulators would be an interesting thing?

[Octal450]

Hi Israel,
Not sure I like this so much...

1) I agree.
2) Like what? Every aircraft is different, so not sure how useful these would be.
3) Don't know this area, so no comment. However, please would need backwards compatibility with the current.
4) Honestly, I don't know why everyone is trying to replace PUI. Granted it is ugly, but I have solved that. But it works fine, and is very modular and easy to modify.
5) Don't know this area, so no comment.
6) Well, if you would like add a new format option, I'm all for it, but keep AC3D, as I prefer it for my (extremely) basic 3D modelling I do.
7) No comment. However, I do find Yasim to be not very realistic, and very non-modular.
8) I also don't see why this is needed? XML is simple to understand, and works logically for property tree
9) No. Nasal is one of the core things in this simulator which allows complexity, and realism. Dropping this would be a HUGE mistake. Further, I am not going to bother learning Python, since I already know Nasal well. If this is done, I am out. (My aircraft contain thousand apon thousands of lines of nasal, which without, the plane wouldn't even load properly and be flyable. Not going to waste time converting it...) Plus, then, Canvas will be destroyed and you loose another great system...
10) Well, if you remove XML and Nasal, you can forget that. You will need to rewrite almost everything...
11) You can't just convert Yasim to JSBsim like that. That is impossible. Yasim uses geometry to model the aerodynamics IIRC, whereas JSBsim every modeller can do it a different way. It would be even less realistic if you did that, and you'd end up with a mess, plus, you'd have to rewrite many systems. (I've done a few Ya to JSB conversions and it's alot of work to do right...)
12) That can be done in FG, for example, IT-AUTOFLIGHT. It is designed to work in any plane, and be easy to customize.
13) Agreed. MP has alot of issues.

Again, I don't think this is needed, and I find it VERY SILLY to do so in the way you suggest.

Kind Regards,
Josh

PS: What is a Fligth Simulator?

[IAHM-COL]

thanks for your honest opinion Josh

For now just a quick thing.
LEARN Python. Don't be silly.

Nasal, cool you know it. OK. You like it. But it is a niche solution.

Python is a real-life programming language skill. It's simple. It's logical. It's beautiful. Has a massive user base.

[Octal450]

No thanks, I find Python rather irritating.

Kind Regards,
Josh

PS: Please fix the title...

[IAHM-COL]

Code: Select all

import this

[IAHM-COL]

Re: PS,
Thanks, Check again.

[Octal450]

Code: Select all

import this

What you mean by this? It just looks like 2 random words.

Kind Regards,
Josh

[IAHM-COL]

1 open a python shell
2. type that
3. hit enter

[IAHM-COL]

to keep in mind: https://github.com/pmatigakis/PyJSBSim

[SHM]

Code: Select all

import this

Code: Select all

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!