nVidia Driver Tweaks for Fligthgear on *nix OS

[valery]

yep, what to do best in Sunday

[jwocky]

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.

[OPFOR77]

Just a thought.

Instead of forking and really improving fgfs, why not fork and improve fgms?

fgms is much simpler, could use a boatload of improvement, and you can integrate combat much more nicely without touching fgfs code.

[IAHM-COL]

@PINTO

Well that allows to chew on 8 and 9 of the "my wish-list"
viewtopic.php?f=58&t=954#p18691

Even agreed, its a much approachable task, these are the bottom of the priority atm.

I wonder, if you would concur with me that fgms needs an overhaul, not just a clean the house. (?)
And if doing so, I wonder how much of an incompatible or compatible of a multiplayer experience this could become.

I think stuff like tracking methods, network packets, rubberbanding of multiplayer, common crashes if many players coincide, combat experiments, differences in time (temporal) and weather on multiple players, need of "having installed aircraft and corresponding livery" on all concurrent aircrafts or seeing a yellow-glider or incorrect livery, single-threading, servers with the capability of login services.

That's the list that comes to my mind on that front.

[OPFOR77]

fgms definitely needs an overhaul.

Limited packet size is the biggest immediate issue in my opinion. We have the /sim/multiplayer/generic properties, but we can't use all of them due to packet size. If we broke up that info into multiple packets, or increased packet size, that'd be a huge improvement. Also the encoding for the /string[] properties is not the most effecient.

[IAHM-COL]

OK
I just made a bare copy of the official FGMS on Sourceforge and push everything to this fork in Github

https://github.com/FGDATA/FGMEMBERS-fgms

IH-COL

[OPFOR77]

That's a really old version of fgms.

Current fgms is hosted on gitlab, not sourceforge, at https://gitlab.com/fgms/fgms-0-x

[IAHM-COL]

thanks for the tip
I updated it from the gitlab as mirror.

IH-COL

[jwocky]

Well, yeah ...

a short look and you have all the relays and crossfeeding and basically a static package size that has to be also applied on the client-side. See, one of the problems is, in the current "official" infrastructure, that someone logs into lets say server4 and server4 has to send all his data forward to a relay which then sends it forward to all other servers. Which most of the time works, sometimes not, which is the reason, you can see sometimes someone on some servers and not on others (aside of the blacklisting mechanism, that is another story).
So, if you are for example in server4 and the guy you are playing combat with is in server5, every little maneuver has to be sent from ->relay-server->5 and the same way back. I really think, we need to invest first a little brain-grease here before we start to change code (which btw would also mean to change at least the MP part in the client). Maybe we even need to experiment a little more.

J.

[IAHM-COL]

I was about to type something similar in relation to relay times and about changing not only the server but also the client would be needed. Which goes to point #1 of needing to fork FGFS by itself ?