RvEYoda

Well since Im not active in DCS anymore (this last fling turned out quite short) just PM me at the start of next week to remind me (currently not at home). I might have some time to spare to make a special version for that purpose. I guess another option would be to make it locked to the distance to the currently selected waypoint.

FYI: I increased the default hsd scale to 20 nmi - Should be more useful in case you're playing somewhere where sensor export is disabled (i.e. where you cant change the scale)

Depends on server settings. The server admin can enable: 1. Player export: Own analog sensor data + rudimentary digital data like own position 2. Sensor export: Own digital sensor data like rwr and radar information I think most servers disable (2), which means leavu is very limited in use.

It is actually locked to the display range of the ingame sensor. For example if the F15C vsd/radar display is set to 80 nm scale, the leavu hsd will also be set to that scale. Btw did you get your leavu working after the new patch? I think the server just has to enable player + sensor export. Maybe it will work with partial funcitonality running only on player export.

Thanks for telling me. Seems like the dlink server had crashed. You can always run your own thouhg.. dont have to go through mine :) EDIT: From the looks of the logs... looks like it might have been DDOSed If you see this happening again (dlink down for more than 1 minute). PM me instantly if you got time!

Doesn't look like ED has implemented their configuration patch yet.

4. is solved in the next patch of dcs. In the meantime, due to public disagreements, RvE is only using leavu where explicitly stated as OK, such as our own server and events. After the next ED patch admins will be able to control what data will be exported for tools like leavu. So after that we will see where we can use it again.

Summary -------------- Under certain conditions in multiplayer games (100% reproducible) missiles will take significantly different flight paths in the game of the attacker compared to the game of the defender. In the tests we performed I was hosting and =RvE=Bilbo was the client - but the missile discrepancy occurred based only on who was shooting and who was receiving. We do not use any missile mods. Bilbo confirmed the discrepancy from his end. Reproducing ------------- Attacker will be at 15.000 ft Defender will be at 10.000 ft Amraam 120C is fired at about 6-7 nm Defender will chaff + perform Split S then break into notch IF the missile loses lock --------------------------- Defender will see the missile flying into ground Attacker will see the missile turning up and flying towards the horizon (through a chaff cloud) This will probably mean different re-acquisition behavior attacker vs defender and even more so in a multiplayer environment with more than 2 planes - other planes could be acquired and targeted with inconsistent results. Desired behavior -------------- Same missile flight path visible for attacker and defender's games :). FYI: In single player, the missile turns up to the horizon and the chaff cloud. Tacview tracks -------------- Bilbos tacview track Yodas tacview track 01:30 - I am attacker, Bilbo is defender 03:30 - I am attacker, Bilbo is defender 13:30 - Bilbo is attacker, I am defender 16:10 - Bilbo is attacker, I am defender .

Thanks. Looks good. What if you call a function that is not allowed by the server. - Just return nil?

:thumbup: Is it possible to get a complete list of what LoGet-functions are part of the sensor_export vs which are part of the ownship_export? My guess is as follows: global: LoGetObjectById, LoGetWorldObjects sensor: LoGetTWSInfo(), LoGetTargetInformation(), LoGetLockedTargetInformation(), LoGetF15_TWS_Contacts() local: the rest ? .

I have the same hopes - but I think it might be hard as - and this is just an educated suspicion - that the old FC planes basically share a lot of the same sensor code - they just have different numbers and cosmetics on top.

Seems like Coff is working on a better solution already which is not just on/off. Let's hope for it. Looks promising so far. Maybe some servers will only block radar + rwr data, not ownship position & basic gauge data. Also this might not affect the high fidelity aircraft at all. Might only be a blocker for the old FC aircraft.

Three Questions: 1. Three different checkboxes, right? 2. Rwr export is controlled by sensor_export, right? (LoGetTwsInfo()) 3. What is the default setting? (for all three)

The setting that ED is adding to the game for server admins cuts off all ownship data export (at least for dcs fc planes, but probably also at least partially for other planes). That means that no cockpit mods like leavu or helios will work on those servers. At least that's what I heard. Most likely some servers will still allow it. I know at least ours will, and I know some admins out there are definitely considering it. Perhaps ED will find a better solution in the long run - And as always, I'm always open to suggestions for changes to Leavu3 to become more accepted.

This is very doable - to limit it. However let's look at last time (Leavu2) when I actually did that. 1. People complained about the other way around - that I gave an advantage to only some of the planes. 2. The software (and I'd like to keep it that way) is open source - so anyone can just go in and remove the limitation. People actually did that last time too :(. 3. The only possible way (and unfortunately I doubt this could ever happen) would be if the server admins could have an ingame setting which would allow data exports based on what aircraft the client was flying - i.e. not just on/off like ED will add to server admins shortly, but a much more refined set of settings - and per data subset conditional per client aircraft. These are the reasons why I have intentionally not added such an artificial limit yet to Leavu3. I'm definitely open to technical suggestions and solutions if you see a way around these problems!