LEAVU development phase, coding MPCD graphics

[Vault]

I'm not going to get in to the argument of whats morally/legally right anymore, what I'm interested in is will ED protect its customers from 3rd party exploit software like Leavu?.

[A.S]

*

 

Little bit offtopic and unfortunatly only german language (im looking for english version) but huulaariouuuss as hell :megalol:

 

http://nuoviso.tv/experimentalfilme/der-cheat-report.html

 

..."PACT Physical Anti Cheat Tool" ...and "Cyber Security Enhancement Act" ... hahahaha....damn i wish i could find an english version...there is an english subtitled one on youtube though.

 

*

Edited December 4, 2009 by A.S

[CyBerkut]

As CyBerkut noted before, the issue of whether or not Yoda should continue with LEAVU is a moot point, as the code and the idea is out there and people can take advantage over it. It would not matter if Yoda were to keep parts of the code closed or were to remove functionality, because that could be added by someone else.

 

The only real solution to this problem is having ED implement some sort of server based flag that allows or disallows clients to the server to use the exported OWNSHIP data. Only if this is disallowed can anyone be certain that players are not sharing information between each other in an automated fashion.

 

It would be great if the flag could even have multiple options, where you could set it to export no OWNSHIP data at all, all OWNSHIP data, or OWNSHIP data but without the targets seen on the radar. The latter would allow LEAVU users to use the datalink to relay their own positions between each other.

 

I think this more nuanced concept has merit, as it doesn't necessarily leave the folks with home built cockpits, etc. completely out in the cold. I don't know how feasible it would be for E.D. to implement with the current export .lua file system.

 

It occurs to me, that perhaps E.D. should examine the possibility of splitting the current client export.lua file (hope I got that right) into several files that would allow a more granular approach, which could enable a more selective control at the server. Perhaps something like:

 

cockpit_export.lua For handling status of switches, lights, etc.

ownship_export.lua For handling datalink of the user's position data

target_export.lua For handling datalink of detected target position data

 

The server could then enable just the first one, to allow folks to use their homebuilt pits, TouchPal, TouchBuddy, LOVP, BSVP, etc., without enabling data linking. OR, the server could enable the first two, to allow data linking without target sharing occuring over the data link. Enabling all three would open up the whole ball of wax.

 

The above is meant to illustrate the concept, not necessarily the particulars of how it should actually be divided up. I realize that it would require E.D. to re-write some of the core code. Whether it is worth the effort versus the estimated benefits to MP play is better judged by those in the know.

 

It would also have fallout on the 3rd party side of things. Homebuilt pits, TouchPal, TouchBuddy, LOVP, BSVP, etc., would all be affected, and need to tweak their code to reflect the new file structure. As a potential benefit though, they could potentially see more MP servers that allow their use online.

 

CB sends

[Panzertard]

It occurs to me, that perhaps E.D. should examine the possibility of splitting the current client export.lua file (hope I got that right) into several files that would allow a more granular approach, which could enable a more selective control at the server. Perhaps something like:

 

cockpit_export.lua For handling status of switches, lights, etc.

ownship_export.lua For handling datalink of the user's position data

target_export.lua For handling datalink of detected target position data

 

Good to see more constructive suggestion :)

[RvEYoda]

Ta :)

 

I do not for a moment Doubt your Sources/Information and the Extent to which you have implemented it into the LEAVU programme. What I am attempting to ascertain for my Own Peace of Mind is whether a Scenario that I have contemplated as per post #311 is relevant to LEAVU or whether the RL Counterpart Software and as a consequence LEAVU has Inherent restrictions that alleviate the 'Gods-Eye' Mode as contemplated.

 

And If So - What are the Said Restrictions/Does the LEAVU Software model said Restrictions?

 

 

LEAVU is prob about 2 wks of full time work into development at this point,

and I dont expect the F-15 module for leavu to be finished any time soon. It is

very much a work in progress. I spend as much time as I can on it.

( it is currently i think around a few thousand lines of code )

 

The Datalink features etc are all subject to change at any point. This thread is meant

to inform of the project, gather information and feedback for improvements/changes.

Currently the datalink is a very primitive network host. It just passes messages along, and

there are no limitations at this point.

 

It would be good if you have some idea of what limitations you would like to see, you could

post them here and I'll see if it is possible to implement them.

 

Everything is of course a tradeoff. We could find infinite number of limitations in any system,

so we must find a level of realism and modelling that we as developers are happy with and

is reasonable to implement ( for example if one limitation takes 2 mths and the project total

is 3 mths, then that limitation makes no sense to implement ).

 

For example a range limitation on datalink is pretty easy to implement, but :

Does it makes sense to implement it ?

Older type data link is likely just coded radio transmissions.

These prob have enough reach to cover a large area of the lockon world.

Also how to implement range limitation ?

 

 

Lets take the following example :

 

The datalink is shared by 3 clients

 

C1, C2 and C3

 

C1 transmits "hello, my pos is ...."

 

the datalink host server gets the msg and sees that

C2 is not in range but C3 is, so C3 gets the message.

Then the dlink host program checks, is C2 in range of C3?

if so then the signal gets through anyway because it is relayed.

 

 

We could have the same potentially for LOS.

If Moa has time to finish the LOS calculation, we can do the same here

 

C3 transmits "Hello here i am.."

datalink host server gets the message checks if C2 has LOS from C3.

let's say he does.

Ok now Dlink server checks if C1 has LOS from C3. Let's say he doesn't

Then dlink server checks if C1 has LOS from C3, lets say he does.

This means this message is relayed and goes to all players.

 

Does this sound like a good idea to you?

 

Personally i think LOS and range checks are overkill, especially since modern dlinks

probably relay through almost everything incl satellite. Also keep in mind there is no LOS

check for the LOFC russian fighter dlink, which sees much more than a LEAVU Flight Data Link.

However I'll try to implement LOS checks since there seems to be large public interest.

Edited December 4, 2009 by =RvE=Yoda

[GGTharos]

export.lua can be added to the list of fingerprinted files, just like in Black Shark.

 

This will allow server owners to prevent any modification whatsoever to that file.

[RvEYoda]

export.lua can be added to the list of fingerprinted files, just like in Black Shark.

 

This will allow server owners to prevent any modification whatsoever to that file.

 

Ok so problems solved then : Server admins can if they wish disable all client side lua exports.

This is quite cool. We can have 1980-2000+ hi tech servers with dlink and stuff, and we can have old school

servers where you make do with classic equipment with dlink failure. Exciting :)

 

I guess like before there will always be groups who prefer one or the other.

We can have some cool dlink event where RED side use the built in dlink and BLUE

use leavu dlink.

Edited December 4, 2009 by =RvE=Yoda

[3Sqn_Sven]

I think the arguments have gotten a bit too complex. Think of it as this.

 

LEAVU allows Dlink for F-15 in a mostly realistic fashion = Good

LEAVU allows Dlink of western style for Russian jets = unrealistic

LEAVU at this stage cannot be controlled by server = bad

There is no way to tell if someone is mis-using LEAVU = bad

 

On the balance, despite the awesomeness of LEAVU for the F-15, it shouldn't be released until the next three problems are sorted out.

 

@ Yoda...corrections?

[Case]

It occurs to me, that perhaps E.D. should examine the possibility of splitting the current client export.lua file (hope I got that right) into several files that would allow a more granular approach, which could enable a more selective control at the server. Perhaps something like:

 

cockpit_export.lua For handling status of switches, lights, etc.

ownship_export.lua For handling datalink of the user's position data

target_export.lua For handling datalink of detected target position data

These were exactly my thoughts as well. This way server admins can decide what they want to export and what not.

 

Very good idea CyBerkut!

[RvEYoda]

I think the arguments have gotten a bit too complex. Think of it as this.

 

LEAVU allows Dlink for F-15 in a mostly realistic fashion = Good

LEAVU allows Dlink of western style for Russian jets = unrealistic

LEAVU at this stage cannot be controlled by server = bad

There is no way to tell if someone is mis-using LEAVU = bad

 

On the balance, despite the awesomeness of LEAVU for the F-15, it shouldn't be released until the next three problems are sorted out.

 

@ Yoda...corrections?

 

 

LEAVU allows Dlink for F-15 in a mostly realistic fashion = Good

LEAVU allows Dlink of western style for Russian jets = partially wrong, since it can also

be used to display russian style MFDs and instruments. ( same as touch buddy )

LEAVU at this stage cannot be controlled by server = wrong, read above. LUA can be turned off entirely

There is no way to tell if someone is mis-using LEAVU = Argument can be applied to anything

 

LEAVU has nothing to do with just F-15. I chose to draw

cockpit instruments for F-15 but if you want to make other aircraft LEAVU instruments

that is fine, and I encourage it. Just same as touch buddy

 

Hehe, funny how some think that "target datalink" is unrealistic, since that was among the first types of datalink

IRL ever made :P. Weapons and weapon systems got targeting data information.

Edited December 4, 2009 by =RvE=Yoda

[3Sqn_Sven]

If I fly the Su-27 then can I use your LEAVU F-15 instruments?

[X-man]

If I fly the Su-27 then can I use your LEAVU F-15 instruments?

 

Yes

[CyBerkut]

Thanks, Case. It really is your proposal, just fleshed out with what might be a way to get there. As mentioned by someone previously, these issues also have a potential impact on the DCS series down the road. I think we all want to see an optimum arrangement achieved. We, the multitude of users, look at this with varying levels of priorities... Realism, balance, performance, functionality, mod-ability, etc. E.D. has to weigh everything out and balance that along with the bottom line.

[AirCavMoby]

Yoda you are an amazing gift to the lock on community.

[3Sqn_Sven]

Yes

 

That's unrealistic = bad

 

If LUA can be disabled, then really there is no issue as LEAVU can be banned in servers that so desire.

[Vault]

It occurs to me, that perhaps E.D. should examine the possibility of splitting the current client export.lua file (hope I got that right) into several files that would allow a more granular approach, which could enable a more selective control at the server.

 

:thumbup: :smartass:

[RvEYoda]

That's unrealistic = bad

 

Can you draw an hsd US style on your computer, yes in mspaint.

I cannot stop this, it is ultimately the same wiht LEAUV, touch buddy and

software - let me explain :

 

I can put in a test in LEAVU which does "if not flying US aircraft, dont draw F-15 instruments".

But, what is to stop someone with programming knowledge to change this?

Maybe It stops 95% of people from doing it, but is it enough?

 

You dont need leavu to do this. But sure I can put in such a control. I'm just saying

there is no foolproof way to protect yourself from it with lockon's lua export.

If you remove LEAVU you can still install TB and do the same. Or some other software.

What would you consider enough anti cheat here?

This isn't a flaw in LEAVU but a general result of the lua script interface.

you can tell your application anything you want, like "im an F22" should you want to.

I can make the standard version of the lua say "Im the correct plane ...." but

if someone changes it we're back to square 1 again

[RvEYoda]

That's unrealistic = bad

 

If LUA can be disabled, then really there is no issue as LEAVU can be banned in servers that so desire.

 

Yes GG just got that info that like Black Shark, in FC2 the server can

tell clients to do checksums on installed files. If so just add export.lua to

the checked files list on the game server, and it cannot be modified on clients

( or more correctly, they cant connect ).

[3Sqn_Sven]

Yes GG just got that info that like Black Shark, in FC2 the server can

tell clients to do checksums on installed files. If so just add export.lua to

the checked files list on the game server, and it cannot be modified on clients

( or more correctly, they cant connect ).

 

Well then based on your last two posts, I guess all you can do it your best to make it above reproach. If people aren't satisfied then they'll disable exported LUA's. It's a tough cookie isn't it? You'll never please everyone. I still don't know how I'd like to implement it on our server. On one hand I'd like the Eagles to have Dlink. On the other I don't want it mis-used or used by Migs/Su's without appropriate instrumentation...which, seeing as their Dlink is displayed in the HUD, LEAVU probably cannot do.

[GGTharos]

Actually Su's have it displayed on the little monitor ... they have a different system than MiGs, complete with FDL and connection to A-50 and GCI, IIRC.

 

There is a great section in the Su-27SK manual about it.

[RvEYoda]

Well then based on your last two posts, I guess all you can do it your best to make it above reproach. If people aren't satisfied then they'll disable exported LUA's. It's a tough cookie isn't it? You'll never please everyone. I still don't know how I'd like to implement it on our server. On one hand I'd like the Eagles to have Dlink. On the other I don't want it mis-used or used by Migs/Su's without appropriate instrumentation...which, seeing as their Dlink is displayed in the HUD, LEAVU probably cannot do.

 

in lockon the Ru dlink isnt displayed in HUD is it?

i was sure dlink in lockon for ru planes was displayed in the mfd-like display on the right?

You could make such a page and/or mfd/display in leavu.

 

Like before, yes, this is all the security we could possibly do. We can put restrictions

like " if you are this plane, you can use these instruments ", but someone can edit the

restrictions or intercept the message from lockon saying "im this" and add his own informaion

to it, and then pouf back to 0 again.

[GGTharos]

Development of security for this is like developing another LEAVU ... in terms of effort. It can be done, but at which point will people consider it 'beyond reproach?'. It isn't like things can't be circumvented, so how do you convince non-technical people that it is 'safe enough' and 'if they can do this, they've probably already done something else'?

[Case]

export.lua can be added to the list of fingerprinted files, just like in Black Shark.

 

This will allow server owners to prevent any modification whatsoever to that file.

But does this also stop clients from accessing their OWNSHIP data? Because this I think is the problem. Only if they do not have access to this data can you be sure that they cannot share it with others through LEAVU or some other piece of software.

[RvEYoda]

But does this also stop clients from accessing their OWNSHIP data? Because this I think is the problem. Only if they do not have access to this data can you be sure that they cannot share it with others through LEAVU or some other piece of software.

 

yes they cannot access anything

This is because as soon as they edit the default export.lua, the server wont let them in.

To access any data whatsoever through lua you must edit export.lua.

 

it works like this. When you start a lockon game, the file export.lua in your

config/export/ will be read. Here you can put custom code before launching

a mission. It can be anything from data export to radar automization ( i use both ).

 

You can also use it to for example code autopilots. ( I wrote an autopilot for FC2

beta to verify that the flight performance of aircraft was the same in the game as

it is in the aircraft manuals ).

 

This is the only file that has access to input-output functions from lockon.

If you edit other files they still cannot access ingame data, self data or others data.

 

Adding this file to the list of "checksummed" files on the server prevents the clients

with custom export.lua files to connect to the server. Simple as that :)

This is part of built in optional security features in BS and FC2

Edited December 4, 2009 by =RvE=Yoda

[X-man]

People who want realism and only refer to more avionics/systems is missing some very important points. IRL systems are not 100% all the time. Take RWR and IFF in LO. Both these systems are flawless. You never get an wrongly indicated guy on the radar scope. Even at 60nm, you still have perfect IFF. Same goes for RWR which never misses a single signal in it's field of view.

 

These two systems alone kinda screws the realism in LO. What worries me is that when you start adding even more of these flawless systems, you'll end up with some very overmodeled planes which are not simulating RL.

 

Adding DL to the planes isnt really making things more realistic (quite the opposite if used in certain aircraft), only easier to fly and cooperate... When you create mods which tunes down systems, thats when we can start to talk about realism, until then, please dont ;)