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!

No...Leavu does not do that. Leavu uses DCS lua ownship export API - which gives signal strength and signal type of a threat. Together with threat signal type you can guess the range - which both the game and leavu does. It doesnt give any position data, any IFF or anything like that. Look at the documentation by ED in your installation folder of what exact data is exported. Basically: signal strength azimuth signal type .. Look in 'Export.lua'

Almost right - Only locked targets are shared. Simply a matter of prioritizing what information goes over the rather bandwidth limited dlink systems of the era. Also clutter wise. In today's planes I expect this limitation would not be there - but I did it also for the sake of balance. Except single player where the game decides to share everything - but since that's single player I don't think that particular case merits any discussion. However I think we are in agreement that it's up to the community and admins of each particular server and event to decide what is considered a cheat or not in their environment. All such wishes will naturally be respected at least by our members.

I had this issue for the first time today. Was quite surprising to see. If i was sitting without any tws locks it was all fine, but as soon as I locked something tws - it started stuttering - Badly. Then, again, as soon as I unlocked the target it was silky smooth again. There was really no denying it - The game starts stuttering wildly when you lock something in tws. I have no clue why :P. 16 GB ram, i7, gtx980. Medium graphic settings. No AA

F15 should be easy mode compared to 21 ;). The M2000 I dont know what. But I have experience with other fighters and once you set your systems and profiles up, the workload is actually less than what you see in the F15 ingame - Assuming we're talking purely about a2a. The F15 in game is quite a lot of work in combat where in reality in a modern fighter you would not need so many manual controls. If you want an example yourself take BMS - The F16 is actually simpler to control in combat because it is not missing so many systems, integration and automation. They make it easier for the pilot if used correctly. But first of course - you need to actually learn them. Properly. It is far easier to angle one's radar towards a given target, reacquire after defenses and so on in bms compared to dcs fc f15. Same goes for wvr. Then again who knows, if you want to portrait an early 90s and 80s version of the 15, maybe it was quite manual to operate - I cannot say, I havent messed with its systems irl. But certainly it should be far more automated than a much older Mig21.

I expect it will, but based on different data sources no doubt. Whether its capability will be more or less than leavus, I cannot say. It will come down to what they think fits for their game I suppose. Then again they might leave it out entirely - less systems to worry about implementing and balancing :).

There is probably not much more than 1/30th of a second delay between the game's lua export api and leavu displaying new data - However, what you are most likely seeing is that the lua export API does not clear/forget old contacts until after at least 3-5 seconds. Instead try this: - Have an enemy lock you, - beam him maybe 70 degrees (so he keeps lock)., or just stay above - Fly with 90 degree bank for a few seconds showing your belly to the target This way you will lose the warning eventually. The cosmetic layer applied to rwr data ingame may also be interfering - making "forget times" different. It is not possible to construct an external data driven mod to have the exact same timeouts for rwr contacts unfortunately. The only way would be that these kinds of behavior instead are encoded in the data source that DCS exports through the ownship lua export API. That way both ingame and external RWRs would look the same in that regard. - I.E. ED removing the ingame cosmetic layer and implementing an actual data source change.

No - Leavu could not be edited to show that. Leavu only has access to data given by ownship lua export api - That means it only accesses the same data source as your ingame cockpit sensors. Example: Your position, speed, altitude, radar status, targets/detected contacts on radar, detected rwr threats. This limitation is dictated by the MP server (has been so for 10 years). Same reason why tacview doesnt work for clients on most public servers. The ownship lua export API isn't perfect - It has limitations and discrepancies compared to ingame presentation. One example mentioned previously in this thread is the speed at which rwr data is produced. In some areas Leavu has been constructed to artificially "dumb down" itself to look more like the game - but not all. Reasons: 1- I haven't found all places yet, and 2: I have limited time - I also have a real life to attend to :). Bottom line: Leavu cannot access any information from your own game on enemies unless you first see them on radar/rwr. What makes you see more is that leavu shares this information with your wingmen if you enable data link - so that you merge information from all friends in your flight.

Data is exported through APIs documented and explained by ED, that have been used by cockpit builders forever - It's how it's presented and shared that is causing server admins to have to make a decision whether to allow it or not. Most likely some will block it, others will allow it. If a public server says no to mods - leavu should not be used there (and in a few days will not even be possible to start) If another public server says yes - leavu and other cockpit mods can be used there

Please do not claim things like that which just arent true. - Leavu has the same blind spot limitations as the ingame rwr. - Leavu gets it's source data from rwr ownship lua data export API from the game, made by ED - Leavu displays rwr information at the same accuracy and detail the game exports sensor data at. The only reason the ingame rwr is slower is because it has a cosmetic slowdown coded on top of it. I agree this slowdown should be on the source data level - and would recommend to ED to implement that in their ownship sensor export API. Way back (many years ago) when the cosmetic slowdown was not yet implemented - the behaviour was identical (leavu2). Ingame displays can be exported to external monitors with 1024x1024 resolution - without leavu. It's in the options. Many people exported ingame displays before leavu came. I'm always open to suggestions and improvements, so it's sad that people write in public with the assumption that you're trying to cheat them, to make their lives less fun, maybe you even think we're trying to steal your bank accounts - We're not. We're just trying to make the sim more fun. And server admins are free to configure their environments as they wish. It seems like now some people are saying "bah I was killed by someone else than my target, they must have been using leavu! Baan em all - Yarrrr!!" (Not directed at you Zer). Sometimes you just face an opponent who has better SA, energy, team coordination or any other vital air combat currency. Sometimes you just have a bad day. Example of a different approach (not directed at you Zer - but as advice to anyone reading the thread): "We cannot allow leavu on our server at this point - because of X, Y and Z, but if you do A, B or C, then we can talk about it". Or, "Our server only allows unmodded game". Let's keep civil here :) Another example is: We use Leavu for 2 seater training in RvE. You can configure leavu to run as a pure remote listener - e.g. for internal squad trainings. This way I could show 10 people my radar screen at the same time, what I did, and how that affected my scan area etc. Very useful to teach squad mates about horizon stabilization, PRFs, scan width, tws vs rws etc. This is an alternative to a regular live stream setup. .

Thanks Xcom. If there's anything you are wondering about the mod, or have suggestions for, just jump on our ts and ask. I'm around virtually every day European evening time.