Val: Okay, as I said earlier, I like my Java better than C++. So I looked into the JMonkeyEngine earlier. But since everybody is so hellbound for C++, fine, yeah, why not? The argument for Java is only portability, that we can make use of more programming capacities since Java is easier to learn and handle and that we could actually abuse Java to program also Java in planes and compile it at loading time into bytecode and run it controlled on the same virtual engine. So, question: Do you speak JAVA?
By the way, we can always go for the machine-dependent parts C++ and the rest JAVA, they have an interface that works nicely.
Israel, I definitively will NOT defend Nasal. You know, I call it the "programming language for masochists" and my hang to masochism is not so developed. My thinking was, instead to implement just another limited script language, we could maybe implement a fully blown programming language. See, from where I stand, engines for example are classes. So, in a 747, I have for example 4 instances of the engine class. Nice and easily to handle because packed in objects. With another script language, we have again this chaos of here a piece of code for an object and there and then somewhere else.
However, if we would go again fully C++ for the core, we can't use native code (as in C++ in the planes) because C++ is not exactly human-friendly, it rises the risks to machine level. Imagine, someone programs a plane extension in C++ and messes up his pointers. With a Java-class this can't happen. All that would happen is, that the sim is continue running and your plane specific class says, it has an exception.
Also on the subject of programming language for planes:
- we have to consider that the old planes should still run, so we can't cut off Nasal entirely
- I wish a complete oo-language mainly because this speaks to my idea of a cleaner easier programming in planes
- You wish for a real script language
What would be your take on a script language we actually translate in a kind of byte code at starting time? A "for-loop" for example would translate to the same bytecode construct whether it is a "for-loop" in Nasal, Python, Jave, Whatever, andanotherlanguafewedontevenknow yet ... Same with all basic programming structures. That would give us a lot of flexibility for the future.
@Lester: About the whole combat question and in part also historical aspects.
I once had this crazy idea to connect objects in the scenery with time-ranges. Buildings are build, they disappear over history, other buildings are built. The basic idea, and I haven't checked yet whether this is even possible, is, to run simulation at a certain "historic time". Means, for example if you fly WWII, this one server for the time, he is set to WWII, will not let you in with an F-14 and there will be no World Trade Center in 1941. Well, that is just one of my crazy dreams. Another one is, to have more stuff that doesn't fly. We have already player-carriers and motorcycles, is there a reason why we don't have working submarines and warships. Especially war ships with AA could add some new dimension to combat flight simming.
See, what we are talking here is not really an FG fork anymore. The question would be, is it easier to do such a thing from the scratch or fork and develop step by step to our vision. We talk not only the client for example. For a real good combat sim, we would also need to expand a lot on the server software and the protocol in between.
The problem, with both ways, is not only how to program it but also the what. See, I can probably bring up a lot of clouds in the sky ... if someone could tell me which kind of clouds, how do they look and what are the weather conditions for them ... I could probably even program a motorcycle if I had the faintest idea about morotcycles. So, aside of programmers, we would need a lot of specialists who can give us that kind of input.