Hi, from some time, I'm developping more or less in secret a patch to compensate lag and reduce the rubber band phenomen: the wiki page

I'd like to have it someday included in FG, and here are my questions about that:

Is it something having enough interest to be included some day?

- I need to have coherent indicated speed, acceleration or angles between the different fdm, this need the bug 202 and bug 901 to be addressed, and i fear those suffer a lack of interest from anyone but me .

-currently we are only 2 to test the patch, it would be fun to have more pilots, we can provide windows binary, and patches for linux and mac users, so feel free to ask for a test flight (see the videos on the wiki page)

- It would be good to have a ping value to the server, currently we ping before starting fg, and put the value in a nasal file. a minimal ping value from 4 ping every minutes would be good enough for me, but i really don't know how to implement this.

If you know the shotest way to make it appear one day in FG, or want to help in the development, any help is welcome

I'm convinced that your mp-patch is useful. The multiplayer feature seems to be largely popular (looking at the mpmap we have regulary ~60 users) so I think it's important to improve this part of the simulator.Unfortunately I'm like you : I haven't the magic key for pushing in FG repo

It could be good to find a solution for discussion started on the bug tracker (#202 & #901)

I didn't look at your code, and didn't check which projects are affected (fgfs & fgms ?) - but in general, it would seem like a good idea to get in touch with the people who previously committed changes to the affected files. If this affects fgms, you will want to get in touch with the fgms developer obviously - and regarding fgfs, you can check the git history.Note that these people will probably be pretty busy, but even just getting their signed-off-by may help to have other/active developers show willingness to review/discuss/commit your changes.

That being said, we've discussed a bunch of sensible MP improvements over the years - but HLA is gaining more and more traction, so that people are obviously hoping for the existing MP implementation to be depreciated and replaced with a more flexible HLA-based implementation. On the other hand, this also meant that a number of good ideas didn't end up being implemented, out of fear of wasting our time because of all the HLA work...

Overall, the main issue concerning changes to the existing MP code will be maintaining compatibility with the old system - so if your changes are backward compatible, you should definitely say so - if they are not, it will be REALLY difficult/painful to convince people, especially given the inertia in the MP department.

Generally, the question is how long it will take for HLA to become a viable alternative - I have a bunch of experimental branches here that extend AndersG's binary generic protocol, so that PUBLISH/SUBSCRIBE could be supported in a fashion similar to how the telnet protocol supports both using "onChange"-listeners, a feature I needed for a different project. Which basically means that the existing MP protocol could be implemented on top of the generic protocol, and the (unmaintained) C++ code could be yanked. On the other hand, in comparison to HLA, all of such attempts would obviously be really ugly hacks

To state the obvious, HLA has been frequently brought up during such discussions, but it hasn't yet really materialized to really be a feasible MP replacement at the moment - and I do know, that F-JJTH is also affected by this "HLA movement", because of his fgais code.

Finally, I would suggest to file a gitorious merge request and use the issue tracker to log a review request, that should get you some developer attention (hopefully), and is more future-proof than using the forum or the devel list: https://code.google.com/p/flightgear-bu ... %20request

so if your changes are backward compatible, you should definitely say so

they are, i just provide a way to optionnaly display mp planes in the futur, aiming to see others in the same position as seen on the mpserver.this way our respective position are coherent between players, and an observer would see us is the same respective positions, even if he don't use the patch. (that is only if we are on the same mpserver, having this working on different mpserver would need more work)

it doesn't touch fgms, and is compatible with not patched mp player, except they have a biased velocity sent for yasim plane (bug 202) and both yasim and jsbsim plane don't sent acceleration in the mp paquet (the field exist but is allways 0).

this give some jumpy plane if you display them in the futur, but they are fine otherwise.

About HLA, it really has no importance how i got the mp planes informations, HLA or the current mp protocol, but the plane position prediction will allways be needed to compensate for the lag (except if HLA provide this, i read the HLA doc the same way you read my code )

I didn't want to fill a merge request before the bug were addressed, but i can reconsider my position and do a merge request with the bug correction included ...

Johan yep i know, i pushed it the truth is it works quite well here, but not good enough to be pushed in FG yet (from my point of view): a bit difficult to adjust, and using the plane VRP instead of the CG for the rotation center, and some more problems.

for onox, it's not something aplied to a server, but on your fg, I can still provide linux or mac patch if you want to compile it yourself and give a try, or a windows binary if asked, once i manage to plug again my windows HD.

don't expect something too soon, as it's still hollidays and as the weather seems good for paragliding

the good news is that most of the FG pilots use a recent FG with a correct yasim ground speed, the result were bad with earlier versions and some moderate to strong wind.

A basic version of the patch was sent as merge request recently, adding the basic flightgear code, and some nasal to configure the patch's use.it allow you to display the other planes in the futur, if they are close enough (a distance slider is included).for now it's up to the user to play with the slider to have the better mp experience (i never managed to gather 3 pilots to test this) and it's better to use the same mpserver.

a good start is to try it with yourself as mp plane (using 127.0.0.1 as mpserver) and play with the menu, if the flightgear part is merged someday

more improvements will follows, but maybe too late for the feature freeze.

jano

ps: if you want to help improve the patch, flying skills are needed to try this on formation flight, refueling , the only requirement being that you can compile a patched FG .

-Got the "initialising the mp lag system" message in the console twice upon startup once it remembered it being turned on from previous session.-Dragging the "Apply to close mp" slider makes no change in the reported number, both in the dialog and /sim/multiplay/lag/range - if I manipulate this property, it changes the number, but slider doesn't seem to read or write it at all. It gets refreshed only when I close and re-open it. [EDIT]: changing the line 118 in gui/dialogs/lag-adjust.xml from "<object-name>range</object-name>" to "<object-name>Range</object-name>" fixes it - simple case mismatch. -(Being a perfectionist) please make the first letters of the words in the "lag options" menu entry capitals, like all other menu entries have it .

When turned on but without any manual lag adjustments, when I perfectly aligned two aircraft on one FG instance, it got me to about one aircraft length (~13m) of difference on the other instance while flying at 320kt. Very nice result .

I can assist you with testing, I can bring two or more aircraft at the same time running multiple FG instances, however all but one have to be on autopilot obviously.

"There are no problems in the air. The only problem is hitting the ground"