LEAVU development phase, coding MPCD graphics

[BrumTx]

By Yoda:

LEAVU isnt part of FC2. FC 2 is by ED. LEAVU is by me/us.

 

Thanks for the clarification

 

Sure we can make it tell lockon "im using this", but the problem is that it is open source,

if someone with bad intentions modifies it he can disable this notification.

 

Is there any way to "lock" the code so it can-not be "played" with ?

I'm not trying to be awkward asking these questions ...... Enquiring minds etc ........

Edited December 4, 2009 by BrumTx

[RvEYoda]

By Yoda:

LEAVU isnt part of FC2. FC 2 is by ED. LEAVU is by me/us.

 

Thanks for the clarification

 

Sure we can make it tell lockon "im using this", but the problem is that it is open source,

if someone with bad intentions modifies it he can disable this notification.

 

Is there any way to "lock" the code so it can-not be "played" with ?

I'm not trying to be awkward asking these questions ...... Enquiring minds etc ........

 

 

Yeah that would be to not use open source code. But I would like to have people start writing

pages and instrument panel modules for leavu.

Imagine if 20 ppl were working on this, we could have full interactive cockpits soon!

[159th_Viper]

 

Leavu models older types.

 

Apologies if I missed the Answers somewhere......

 

What are the Specifications/Inherent 'Limitations' of the Datalink modelled? Is it LOS? How far does one Plane have to be from the other in order to be 'Linked' the relevant Info?

[Moa]

Yeah that would be to not use open source code. But I would like to have people start writing

pages and instrument panel modules for leavu.

Imagine if 20 ppl were working on this, we could have full interactive cockpits soon!

 

For the Gripen and F-18 mods :)

[BrumTx]

Yoda, Thanks for your answer's I'll sit in the corner and watch :D

[RvEYoda]

Apologies if I missed the Answers somewhere......

 

What are the Specifications/Inherent 'Limitations' of the Datalink modelled? Is it LOS? How far does one Plane have to be from the other in order to be 'Linked' the relevant Info?

 

I don't have specifics. on the previous F-15 data link.

But it's nothing fancy. If you were somewhat good with electronics

and computers in 1980s im sure you could go buy enough equipment to

make your own data link and fit it inside your backpack.

 

Basically powersource, some cables, antenna, some amplified oscilloscope

thingie and a programmable circuit or computer ( 80s computer power

is easily enough )

Edited February 17, 2010 by =RvE=Yoda

[Case]

I don't have specifics. on the previous F-15 data link.

But it's nothing fancy. If you were somewhat good with electronics

and computers in 1980s im sure you could go buy enough equipment to

make your own data link and fit it inside your backpack.

I think Viper may have been referring to what limitations your software sets to this. Or at least that is what I am interested in.

[RvEYoda]

I think Viper may have been referring to what limitations your software sets to this. Or at least that is what I am interested in.

 

well at this point nothing at all.

What limitations do you suggest aside from LOS?

 

LOS checks can probably be achieved.

Distance limits also.

 

It's pretty safe to assume if your radio can talk with good quality to the other

AC then DL can also, since many DLs were just radio transmissions.

Edited December 4, 2009 by =RvE=Yoda

[Case]

well at this point nothing at all.

What limitations do you suggest aside from LOS?

 

LOS checks can probably be achieved.

Distance limits also.

Well, if you are designing this on the basis of reality, such limits would seem pretty important to me.

[Moa]

Well' date=' if you are designing this on the basis of reality, such limits would seem pretty important to me.[/quote']

 

I agree. In this thread you'll see I made a suggestion that terrain Line-Of-Sight limitation can be done simply using two 2-D Bresenham evaluations and a heightmap. Simple enough for an initial implementation and maybe we can do fancier math later.

[RvEYoda]

Well' date=' if you are designing this on the basis of reality, such limits would seem pretty important to me.[/quote']

 

 

Welll radio transmissions probably reach across the flight area we are talking about ,

or whatever comms are used. I'm sure the planes can talk to GCI from substantial ranges etc.

 

IF you have suggestions on how to perform LOS then that would be good.

if you have a good algorithm for it then ill implement it asap.

 

What I can provide you is heightmap of whatever resolution you want.

if you can generate a preloaded data set required to perform los checks

and the algorithms necessary ill imeplement it into leavu .

 

In the meantime it holds low prio, especially given that the ru DLINK doesnt perform such

LOS checks. You can fly in the canyon super low well out of LOS from any station or awacs

but still detect enemies through dlink, pop up and kill them with archer.

[RvEYoda]

I agree. In this thread you'll see I made a suggestion that terrain Line-Of-Sight limitation can be done simply using two 2-D Bresenham evaluations and a heightmap. Simple enough for an initial implementation and maybe we can do fancier math later.

 

Moa if you know what to do!!

 

Please do it and ill kick it into the software as soon as you're done :)

 

Just make sure its fast and uses preloaded data.

Ill give you a heightmap.

What resolution do you need?

 

if you give me the lat/long or XZ limits ( max and min of both ) and

what resolution you need in each dimension. Ill make this map for you.

 

You can use this map to generate whatever preloaded data you need.

I dont know what Bresenham is :P

Edited December 4, 2009 by =RvE=Yoda

[EtherealN]

What I wonder is why no-one is being deathly terrified of the fact that FC2 is online compatible with DCS. I mean, the Ka-50 modeled in DCS:BS has a datalink! OMG! :D

[CyBerkut]

Yeah that would be to not use open source code. But I would like to have people start writing

pages and instrument panel modules for leavu.

Imagine if 20 ppl were working on this, we could have full interactive cockpits soon!

 

Yoda, would it be feasible to make part of the code locked (perhaps compiled, and that section of the code not open source), while making the parts that enable folks to make instrument panels, etc. open?

 

Basically, put a notification handshake to the Lockon Server in the compiled part, along with some indispensible portion of code that would not be easily recreated by someone else (of bad intentions)...

 

OR, similarly, make the underlying wizardry of LEAVU closed/locked/compiled (with a hard-coded handshake to the LO server), with some sort of SDK for folks who want to make instrument panels, etc.?

 

Just trying to think of something that could address the concerns being expressed by some on here. I realize the above (especially the second version) may not be trivial to implement. If it's not feasible, so be it. If it is feasible, maybe it is worth considering.

 

---------------------------------------------------------------

 

Personally, I think it will ultimately come down to E.D. doing something in FC2, as the reality is (however distasteful it may be to some folks) that if Yoda can develop it publicly/openly, someone else of bad intentions could develop essentially the same capabilities privately. Yoda's open source approach offers the possibility that everyone could end up on a level playing field, even if it does mean that some other folks will have to step up and develop the user interface parts for other aircraft platforms.

 

Folks, if Yoda just stopped right now, and threw the code away, the community would still have the possibility looming over its head of someone else developing a similar capability and NOT sharing it with everyone. THEN you really would have an imbalance, and one that would not be easily corrected. Like it or not, Yoda doing this in an open manner is a good thing. E.D. can see it, the community can see it, and one would hope that some folks will use the tool to do equally cool things for the other aircraft.

 

CB sends

[Moa]

Moa if you know what to do!!

 

Please do it and ill kick it into the software as soon as you're done :)

 

Just make sure its fast and uses preloaded data.

Ill give you a heightmap.

What resolution do you need?

 

if you give me the lat/long or XZ limits ( max and min of both ) and

what resolution you need in each dimension. Ill make this map for you.

 

You can use this map to generate whatever preloaded data you need.

I dont know what Bresenham is :P

 

Will do tonight (6 hours from now).

[RvEYoda]

I've been discussing some form of validation/handshake approach, GG suggested

some ideas but we found flaws in them all.

 

The issue is how does the Game server tell the datalink, datalink server or leavu

that it is allowed or not allowed? Automatically?

 

I cannot think of anything...

 

The setup looks like this :

Edited December 4, 2009 by =RvE=Yoda

[Moa]

I've been discussing some form of validation/handshake approach, GG suggested

some ideas but we found flaws in them all.

 

The issue is how does the Game server tell the datalink, datalink server or leavu

that it is allowed or not allowed? Automatically?

 

I cannot think of anything...

 

The setup looks like this :

 

Usually it is done with encryption keys (yes, just like the real datalink). There are many ways to use them for authentication/authorization, but you need support on the server (or a proxy) to do this. Are we able to modify the game server?

 

Each player has a public/private key pair generated for them and stored on their machine. During handshake they submit their public key (which they share freely). The server encrypts something with that key and sends it to the player. Only that player has the private key that can decrypt that token. The player uses that token to authenticate with the server (which can register a token to the client IP/port). Variations on this can be used to allow/deny communications between client and server.

[Azrayen]

@ Yoda :

 

Sorry if the answer had already been given, I didn't see it.

 

Am I to understand that, on FC 1.12, some exports functions (of "self" data) still work even if server had set EnableExportScripts = False ?

 

Thanks :)

Az'

 

PS : question related on LotATC and other third part tools my squadron mates are developping.

[RvEYoda]

@ Yoda :

 

Sorry if the answer had already been given, I didn't see it.

 

Am I to understand that, on FC 1.12, some exports functions (of "self" data) still work even if server had set EnableExportScripts = False ?

 

Thanks :)

Az'

 

PS : question related on LotATC and other third part tools my squadron mates are developping.

 

Yes you are correct.

 

if you set "EnableExportScripts = False" what happens is

"LoGetWorldObjects" and "LoGetObjectById" no longer work.

[RvEYoda]

Usually it is done with encryption keys (yes, just like the real datalink). There are many ways to use them for authentication/authorization, but you need support on the server (or a proxy) to do this. Are we able to modify the game server?

 

Each player has a public/private key pair generated for them and stored on their machine. During handshake they submit their public key (which they share freely). The server encrypts something with that key and sends it to the player. Only that player has the private key that can decrypt that token. The player uses that token to authenticate with the server (which can register a token to the client IP/port). Variations on this can be used to allow/deny communications between client and server.

 

 

Do you have some idea on how to implement such a thing and if it would even

work on our setup ?

 

The only thing i think we can do on a server is to have it host some extra functionality,

like some datalink confirmation or denial message. That is all i can think of.

This is your area of expertise Moa :).

 

How will it even know where to check in for confirmation?

What if you tell it to check in with localhost but you are playing on 104th server and they dont allow it ?

 

Sounds like im putting all work on you atm.

[Kuky]

If you release this tool and every aircraft can use same ability to share datalink of their radar, how is that more toward realism? You can have your fun Yoda but you might as well end up flying against AI... I for one will not want to fly knowing this thing is around...

 

Good thing at least Oleg Maddox is smarter about this and does not allow any 3rd party moding/software and if ED does not take control of their own software and allows servers to disable stuff like this they are shooting themselfes in the foot.

 

anyway, I'm done talking here... do what you want

[RvEYoda]

No I release this tool so that every user can build his own cockpit.

I have started to build mine and I share what ive made so far. At this

point i am making f-15/16 instruments for myself.

[GGTharos]

No, this goes a lot deeper. You don't care about authenticating the user ... you care about authenticating the jar - in short, you want a trusted jar. And the requirement is that this must be done remotely as well, otherwise it's pretty pointless if it's stuck on the same host.

 

It has a lot more of a PKI feel to it than plain encryption - in fact, I don't think we even really need that (it's just overhead and it really doesn't add anything) - we need some form of handshake that can verify a jar remotely, so that you know someone hasn't altered it. Then you can lock it down. An altered binary would simply be rejected since the signature check would fail.

 

I know you can sign jars, but we need a reliable way to check the signature remotely (which itself requires encryption, certainly). Going beyond this to lock things up though is pointless. I do wonder if it should just be all or nothing as well, seems like too much work.

 

Usually it is done with encryption keys (yes, just like the real datalink). There are many ways to use them for authentication/authorization, but you need support on the server (or a proxy) to do this. Are we able to modify the game server?

 

Each player has a public/private key pair generated for them and stored on their machine. During handshake they submit their public key (which they share freely). The server encrypts something with that key and sends it to the player. Only that player has the private key that can decrypt that token. The player uses that token to authenticate with the server (which can register a token to the client IP/port). Variations on this can be used to allow/deny communications between client and server.

[Moa]

No, this goes a lot deeper. You don't care about authenticating the user ... you care about authenticating the jar - in short, you want a trusted jar. And the requirement is that this must be done remotely as well, otherwise it's pretty pointless if it's stuck on the same host.

 

It has a lot more of a PKI feel to it than plain encryption - in fact, I don't think we even really need that (it's just overhead and it really doesn't add anything) - we need some form of handshake that can verify a jar remotely, so that you know someone hasn't altered it. Then you can lock it down. An altered binary would simply be rejected since the signature check would fail.

 

I know you can sign jars, but we need a reliable way to check the signature remotely (which itself requires encryption, certainly). Going beyond this to lock things up though is pointless. I do wonder if it should just be all or nothing as well, seems like too much work.

 

The problem isn't signing the JAR or taking a checksum/hash. It is making sure that the JAR being checked is indeed the JAR in use. I have to do some homework on this.

[GGTharos]

Yes, exactly. Therefore a remote method is required to present credentials ;)

 

The problem isn't signing the JAR or taking a checksum/hash. It is making sure that the JAR being checked is indeed the JAR in use. I have to do some homework on this.