Postby jwocky » Thu Jan 05, 2017 6:16 pm
I have such a feeling, Valery and me are both kind of flirting more with the rewrite idea, we only don't have the manpower.
Mutlithreading for example is nothing just done on the seat of your pants. You have to identify what to put in which thread. For example: Terrain reloading on the fly can go into a thread on it's own because the main system needs terrain only when it is loaded. So this can go in some worker thread. Or on MP, the planes of other pilots around. Those models can be loaded asynchronous, which makes them a candidate for a worker thread. Other things, for example everything, that involves two pilots, are a little more complex because their actions influence each other and are also hampered by network lags. Imagine for example air-to-air-refueling. Any position change of one of those two planes, tanker and receiver, have to go forward fast on both systems. We can do the protocol traffic in an extra thread, but we need internally a quite fast dispatcher to make those things actually visible.
The rub here is, at this point, I mentioned already three candidates for worker threads ... but as FG s programmed right now, the source of those candidates is not in just one defined module but spread out. So we end up anyway checking which end of the spaghetti is used in which of the modules, isolate the code, streamline it, centralize functions ... so at this point, we are already at the same amount of work, if not more as if we would just make a clean concept and rewrite it.
The real nasty part for rewriting though would be backwards compatibility. We don't like Nasal and still we would need to keep it alive because we have hundreds of planes using it and nobody can rewrite them all on Phyton or Java or whatever we chose. So, there we are nailed. And another not so visible thing is the property tree. THe idea per se is cool, but over the years there were virtually hundreds of properties more or less hard coded into it. So this is another thing, we would need to sort out and, purely based on my instincts, this feels like some enormous work.
The third big thing is, if we decide for other components, for example JMonkeyEngine (or any other 3D engine), we would first need to do some testing to get familiar with it. We can't just take such a thing out of a box, read the manual and hope, it all works as we dreamed it. This is not how things work, I'm afraid.
So from where I stand, a fork will not give us what we desire most: Multithreading. It will also give us only some rather improvised solutions for combat abilities because we would need to set them on the old laggy MP system which is ... well, some things in there are outdated at best. We will have the same problem by the way with Canvas, parts of it are quite hard-coded and spread out. Thus, a fork will only serve to preserve the sources to keep FG alive if they are going one day into some scorched earth fantasies, but that's it.
And on an organizational question: Shouldn't we put this into a thread on its own? This has gone far beyond nVidea tweaks.
Free speech can never be achieved by dictatorial measures!