LUA Help needed: Locked Target info flags

[Hitman IF]

Hi,

I'm having trouble trying to interpret the "flags" field returned in the LoGetLockedTargetInformation() result table. Perhaps someone here can help me out with a clear explanation.

 

It's specified as follows:

flags = , -- field with constants detemining method of the tracking

--whTargetRadarView = 0x0002; -- Radar review (BVR)

--whTargetEOSView = 0x0004; -- EOS review (BVR)

--whTargetRadarLock = 0x0008; -- Radar lock (STT) == whStaticObjectLock (pinpoint) (static objects,buildings lock)

 

--whTargetEOSLock = 0x0010; -- EOS lock (STT) == whWorldObjectLock (pinpoint) (ground units lock)

 

--whTargetRadarTrack = 0x0020; -- Radar lock (TWS)

--whTargetEOSTrack = 0x0040; -- Radar lock (TWS) == whImpactPointTrack (pinpoint) (ground point track)

 

--whTargetNetHumanPlane = 0x0200; -- net HumanPlane

--whTargetAutoLockOn = 0x0400; -- EasyRadar autolockon

--whTargetLockOnJammer = 0x0800; -- HOJ mode

 

I've tested the output to this with different aircraft, with very different results. Note that mig29's and F-15's were jamming.

 

• 1 of 2 f5's tws from su27 == 0x20
  
• f5 tws by f15 == 0x80
  
• f5 tws by su27 == 0x20
  
• Mi-26 tws by f15 == 0x808
  
• su27 tws by f15 == 0x80
  
• su27 tws by su27 == 0x20
  
• f15 stt (from tws mode due to jamming) from su27 == 0x10a
  
• f15 stt from f15 == 0x800 --don't know what was going on here.
  
• f15 stt by su27 == 0xa
  
• f5 stt by su27 == 0xa
  
• f5 stt by f15 == 0x8
  
• mig29 stt by f15 == 0x108
  
• su27 stt by f15 == 0x8
  
• su27 stt by su27 == 0x10a -- See Note a)
  
• f15 eos by su27 == 0x10
  
• su27 eos by su27 == 0x14
  
• f15 hoj by mig29 == 0x802
  
• mig29 hoj by f15 == 0x800
  

 

From the values there, you can see evidence of combinations of two or more of the flag constants as per the definition. This indicated to me that the flags field is a 2 byte field with individual bits in that field, or groups of bits, acting as flags. Though I'm not sure where the 0x10* values come from in this scenario, perhaps this was something that was added after the lua script definition was written. Note a) These 0x10* values seem to come when you get a lock against a jamming russian aircraft, so perhaps I added a jamming pod to the su27 loadout by mistake in this case.

 

Could someone from Eagle Dynamics please post a definition saying what each bit (group of bits) flag in the field represents? The info I'm trying to export, is whether or not the radar is on, so that I can make an IFF interogator that only works when the radar is on.

[Hitman IF]

bump.

Anyone?

[Alex Okean]

bump.

Anyone?

 

Sorry OK :icon_frow

 

It' s really bit field and examples on script explain individual bits , if you send data from LUA to C you can use bitwise AND operator for example

if(target_flag & whTargetRadarLock)
{
//YOU ARE LOCK HIM
if (target_flag & whTargetNetHumanPlane)
//this is a human 
}

current basic LUA core don't have internal bitwise operators but , on the http://www.lua.org you can find some realisation

[Hitman IF]

Ok, thanks, that was what I suspected. I'll go away and try to implement something.

 

Perhaps an integrated IFF interogator could be a new feature for a future patch or version of Lock On? It's very difficult trying to engage using the F-15 close combat modes online when the same aircraft types might be on Red and Blue teams.

[zorlac]

As a client, how do you get LUA to export to another machine? I can get LUA to open a tcp socket to another machine and send pre-formatted data (working nicely with a perl listener on the other end), but only when the Lomac machine is also the server. As a client, it just refuses to do anything (and nothing helpful on the error log). You using the export.lua for client?

[GGTharos]

I believe this is an anti-cheat measure ... the export.lua of the server is forced onto the client, or exports are plain disabled on clients.

 

A better solution would be for the server to restrict export functions available to client.

[zorlac]

mmm... ok, that makes sense.

 

How are people creating their own "cockpits" with dials and things if LUA export is disabled on clients?

 

ED, any definitive comment on this?

[Alex Okean]

mmm... ok, that makes sense.

 

How are people creating their own "cockpits" with dials and things if LUA export is disabled on clients?

 

ED, any definitive comment on this?

 

 

the list of server dependent files can be modified by this file

 

LOCK_ON_DIR\Config\Network\Config.lua

 

just remove filename from this list on server and client will be use local file

[Valery Blazhnov]

Ops, sorry :)

[GGTharos]

the list of server dependent files can be modified by this file

 

LOCK_ON_DIR\Config\Network\Config.lua

 

just remove filename from this list on server and client will be use local file

 

 

Can we ADD files to this list?

Last time I tried, it caused LOMAC not to work, or not to work well at the very least.

 

Also, it seems that in some cases the client can use its own files anyway (Liek in teh case of the mexinit files where if the mission is not locked the client uses its own)

 

I believe that, for the future, also a 'client side' export.lua is needed where the functions that can be used by it are restricted by a list on the server, ie.

 

LOGetWorldObjects OFF

LOGetOwnAirspeed ON

 

etc.

 

This way a client can export information for his own cockpit for example without the problem of the server not allowing them to, and at the same time the server can be sure that functions like LOGetWorldObjects, which would allow someone to see positions of all objects, are not used by clients.

[Hitman IF]

Ah, I hadn't thought of that. Thanks for pointing it out GGTharos. Looks like an impossible problem for my mod idea anyway, unless I could get servers to support it.

[Tracker]

Alex answered the question quite nicely. Simply put, rem out the line of the Server Files section in client side Config.lua pertaining to the file you don't want pushed to the client. i.e. export.lua