LRM 2.0 Beta1 enters public test phase

I have personally experienced that I was in turn, kept pressing KP0 and I got TDS to snap to position before I even saw the blip on the radar screen.

What you are missing is that it has a memory, just like a real radar:

You either detected something else in that position, with other

setting like bore/vertical, or you had detected this target earlier,

and the radar memory still remained. The memory is set to 7 seconds.

So basically when you come back it looks at the last known position.

(it proved to be a good number to give intended effect without screwing with

your actual ability to snap)

There are unlimited possibilities how this could have happened, all within

intended limits.

Example : you see something(his timer starts), you turn away, you turn back (within

time of this somethings timer not reachin the memory limit.

There are hundreds of other possibilities, but fact of the matter is I programmed it,

and it uses only contacts detected at some point by lockon radar.

Basically script works like :

1. contiously Lockon radar data goes into processing.

2. In the processing module contacts are either put into lrm radar memory or updated

in radar memory if they already exist

3. If contact disappears for more than 7 seconds, it is removed from memory.

(there are a few more criteria that call remove from memory)

The step function simply remembers which one you stepped to last,

and then takes the next one in the list, sorted by range.

ECM contacts dont appear in list unless in burnthrough range.

If the last one stepped(or next) doesnt *exist*, it goes to the

closest (in terms of range to you) contact in the list that exists.

Also I tried to snap the TDS onto somenoe that was outside my selected scan zone... ie, my radar range was as 10nm and target snapped to some 15nm and radar range switched to 20nm so basically I pressed KP0 and got TDS snap to target that didn't show on my radar screen... yes the target was detected by my radar as it was in scan volume and range but I saw no radar blip as my radar raneg was 10nm and he was about 15nm.

Kuky The 10 nm is just a scale for your display.

Your radar still scans full out to maximum.

If you had changed your scale manually, you would have seen the contact

instantly, even before the radar antenna scanned him again.

You can check the scripts yourself.

It only uses data from the lockon radar. It needs to have found something

for you to be able to snap to it. It is possible that the lockon radar has a

graphical delay of a few 100s of a second, but during the weeks now I've been

using this feature online and offline for testing, NEVER have i encountered a situation

where it snaps to a target that wasnt actually detected by radar. (in fact it is impossible)

It has been programmed to add only contacts detected by radar into memory,

in fact it CANNOT see anything else, so even if it wanted to add other contacts,

it couldnt!. And believe me...ive tested/played with it

a LOT :P

Then you either detected something else in that position, with other

setting like bore/vertical, OR you had detected this target earlier,

and the radar memory still remained. The memory is set to 7 seconds.

So basically when you come back it looks at the last known position.

 

Example : you see something(his timer starts), you turn away, you turn back (within

time of this somethings timer not reachin the memory limit.

I remember this instance was when I was going away then turned in again to see how quickly I could lock somone while in quick turn (it was well over 7 seconds) and I was amaised I did not have to do anything with my TDS... just pressed hotas button and snap/lock was there.

Kuky The 10 nm is just a scale for your display.

Your radar still scans full out to maximum.

If you had changed your scale manually, you would have seen the contact

instantly, even before the radar antenna scanned him again

yeah that's all fine and true but what I'm talking about is that this still eliminates some short time that I would normally require to change radar scale to actually see a blip on radar... move the TDS over it and then lock... this takes some time... the mod makes this time to negligble value. One more thing crosses my mind... say if map mission was made with high scenery and I had to manually slew the TDS (as I do) it takes quite a few seconds to get it over contact because the TDS speed is dependent on framerate in game. If you use axis it's quick but button is very slow. With the TDS snap this time is again minimal/negligble.

I remember this instance was when I was going away then turned in again to see how quickly I could lock somone while in quick turn (it was well over 7 seconds) and I was amaised I did not have to do anything with my TDS... just pressed hotas button and snap/lock was there.

Most likely lockon has a graphical delay to the radar display, this could

explain why the ru radars detect targets faster, even when they have the

same sweep speed and eagle set its 3A setting and they scan the same direction.

I may have experienced this graphical delay, where the snap is posible lets say 0.1-0.2 s

before the graphics, but I cannot recall any specific events of such.

It might be possible to introduce a delay to adding new contacts

to the radar memory, so that this effect doesnt become visible.

Another possibility is that you simply found him, but you turned away fast enough

not to see the graphics(radar or nose), then got him back the next antenna

sweep, but the memory of the first sweep remained, so you could step before the

graphics of the second sweep appeared. As said before, there are a lot of

possibilities. The real radar for example will provide you graphical indications of

targets that are in memory but cnnot be detected by radar (they will disappear

eventually), but we cannot edit the lockon code, only provide simulated user input

(such as cursor up/down), so we cannot graphically show this radar memory.

yeah that's all fine and true but what I'm talking about is that this still eliminates some short time that I would normally require to change radar scale to actually see a blip on radar... move the TDS over it and then lock... this takes some time... the mod makes this time to negligble value. One more thing crosses my mind... say if map mission was made with high scenery and I had to manually slew the TDS (as I do) it takes quite a few seconds to get it over contact because the TDS speed is dependent on framerate in game. If you use axis it's quick but button is very slow. With the TDS snap this time is again minimal/negligble.

This is the entire purpose of the function in the real jet.

The purpose is so that the pilot doesnt have to spend seconds moving a

stupid cursor around :)

Real life example:

Radar gets no *ping* from contact, but a very distorted image

==> computer processing

Computer tells pilot #From all this junk data i see something here that is a possible target#

pilot tells computer : Move cursor to this possible target with a button.

computer moves cursor (and can also lock automatically)

computer moves radar elevation/az/barscan/freq/etcLimits/lalalala automatically.

Example : you see something(his timer starts), you turn away, you turn back (within

time of this somethings timer not reachin the memory limit.

 

There are hundreds of other possibilities, but fact of the matter is I programmed it,

and it uses only contacts detected at some point by lockon radar.

 

Basically script works like :

1. contiously Lockon radar data goes into processing.

2. In the processing module contacts are either put into lrm radar memory or updated

in radar memory if they already exist

3. If contact disappears for more than 7 seconds, it is removed from memory.

(there are a few more criteria that call remove from memory)

So a contact that is stored in the memory can be reacquired within 7 seconds, this is a good workaround with no history being displayed on the radar but if the target changes altitude while in memory then can it still lock?

If so then this is very wrong.

The idea behind auto target acqusition is it scans a set place not auto finds targets.

So a contact that is stored in the memory can be reacquired within 7 seconds, this is a good workaround with no history being displayed on the radar but if the target changes altitude while in memory then can it still lock?

If so then this is very wrong.

The idea behind auto target acqusition is it scans a set place not auto finds targets.

auto target aquisition?

I have no such thing.

Target step lets step to empty space for 7 seconds, but if there is nothing

there, pressing the lock button wont help you. It wont ever change where your

radar scans. The ONLY thing it ever does, is moves the cursor

OK, cool, I was just unsure as to whether these ghost contacts were still being tracked or not if thats even possible within LO.

It only moves cursor.

you can only lock what lockon allows to lock.

But remember since lrm 1.0 TWS elevation follows bugged target(s).

this activates as soon as you bug something,

This means if the bug/lock succeeds, then elevation will move.

Meaning you can lock/bug what lockon itself (i havent added this) memorized

outside scan limits.

For example, scan bandit, then move scan zone away from him (example: under him) , bug him, scan automatically adjusts (unless lockon's own memory has faded)

Blocking users scritps

With the new lrm (im rewriting the entire thing) you will be able to

_completely_ deny clients to run ANY scripts except the server's.

I'm also integrating tacview so its timings don't interfere with lrm.

This way the playing field is even for everyone.

^^

For the release version target step will have a 0.1-0.15s delay.

.

Just a little update on the current development completion state.

As you may have seen i decided to completely rewrite LRM 2.0, to make

algorithms and code much more efficient. The new totally rewritten LRM 2.0

now also has tacview integrated, and also optimizes the tacview export algorithms. Details follow... :

1. The tacview script is now included in the main LRM script,

but somewhat modified, and activates if client has a file /Config/export

/tacviewflam.....lua. (Meaning you still have to have normal tacview installed)

2. The entire LRM is now based on the "Beforenextframe" routine, as this

has many performance advantages to coroutines, especially when it comes

to dynamically (while playing) adapting CPU load to framerate and time between frames.

Coroutines are more efficient when different scripts and algorithms deal with

their own data (and doesnt throw a lot of stuff back<->forth from the game

at higher rates than framerate) and it makes for easy programming, but they are hard to

make dyanically optimized based on client computer performance. Also the coroutine

Frequency doesn't automatically adjust when framerate drops/stutter occurrs.

3. Each part of LRM is given a CPU priority and a CPU load parameter.

If enough scripts have been run shortly before then CPU total load parameter

of LRM will not allow minor scripts to activate this frame. This means, together

with the native behaviour of *beforeNextFrame*, that LRM effectively adapts

CPU load to client computer performance. Although the algorithms are now so

much more efficient, this feature probably wont be needed.

4. No scripts run *every* frame. There is always of course a minimal time

that must have passed before one script is run again.

The new system also allows me to for example :

In those frames when Tacview runs, LRM is halted (and also the next frame

as a small buffer if the fps is high enough). This, combined with now MUCH

smaller and much much more efficient programming and algorithms, should

drastically reduce any negative effects on game performance, and tacview

will NEVER conflict with LRM again. This is also the only way we can

guarantee that users don't override LRM by including custom data that breaks

in LRM in their own local tacview scripts.

Completion status

Finished (being tested) :

• Eagle RadarFix : F-15 IFF, elevation/azimuth follow target(s), (Required for : LBST, 8B3A, target Step), new ECCM, stt->tws fix
  
• Ru Fighter radar : new ECCM, ECM range estimation
  
• Cursor step : Now stores contacts slightly shorter time than previous lrm 2.0 BETAs and also has a delay each time you step.
  Also includes LBST & 8B3A (like before)
  
• Reduced chaff
  
• Counters to barrell exploit
  
• Counters to unrealistic radar floor exploit
  
• Customizable payload control, including full database of standard weapons
  
• Dead is Dead : No missiles fired when multiple major systems down (>=3)
  
• Lua export log (exports trucks per airfield)
  

Left to program, Airfield scripts! :

• Airfield ownership
  
• Airfield ownership indication lights
  
• Customizable spool time
  
• Only takeoff from runways (or Kuz)
  
• Only refuel at parking
  

(the above was finished in about 1-1½ day's work, so expect all features to be done within a few days at most)

Where did turbulence go?

I am not sure whether to make turbulence or not included in the final lrm 2.0 version,

given two reasons :

1. It is a performance intensive script that runs at very high frequency, and it requires to be run

as a coroutine, cause if you run it "before next frame", the size of turbulence would vary with

how much fps you had. Running it as a coroutine on the other hand could/would interfere with

tacview and all other timings and optimizations.

2. When turbulence input is given, it overrides users Key-pitch/yaw/roll commands (joystick axis/pedals/mouse still work).

This is the release variant that I am working on...

but there will probably be several release candidates before a

final version is officially released - we are still in BETA

.

Maybe instead of turbulence mod, simple do shake like in 25T? When u fly with so much shaking plane u cant see very good. Look at Su-25T when it carries Vikhrs. At fast speed it is really hard to watch TV and HUD. It would be same with normal fighters and by this mod wouldn't takes for itself key hooks as like pitch, yaw, roll. ect steer commands.

Maybe instead of turbulence mod, simple do shake like in 25T? When u fly with so much shaking plane u cant see very good. Look at Su-25T when it carries Vikhrs. At fast speed it is really hard to watch TV and HUD. It would be same with normal fighters and by this mod wouldn't takes for itself key hooks as like pitch, yaw, roll. ect steer commands.

Activate cockpit camera shake? =)

Yes but with same conditions as like with turbulence mod. Player couldn't be able to turn it off.

I don't know is it good idea or not - you can add also drag value - I mean if plane carries many missiles it drags more than plane with few missiles. Like with Vikhrs in 25T.

I don't know is it well modelled in LO but ER is more draggy than 73.

So if many missiles plus flying fast and low = more shaking power than only flying low and fast without missiles. I don't know is it real if yes it is imho nice.

This isn't really feasible, not does it do what is desired: Ie. stop people from flying under the radar floor.

A simple thing to do in this case Yoda might just be to initiate a pitch-up maneuver under certain altitude.

This isn't really feasible, not does it do what is desired: Ie. stop people from flying under the radar floor.

A simple thing to do in this case Yoda might just be to initiate a pitch-up maneuver under certain altitude.

Pitch up maneuve IMHO is bad. Sometimes when u are in combat, it happens u just accidientally fly under 20-10 meters. Let's see you do maneuver and script disturbs this important maneuver...

Why do u think it is not feasible? Get normal shake and double, triple x times when lower. I don't think anyone would be so cool to fly with shaking HUD from up to down on whole LCD monitor :D In 25T shaking is terrible, and now multiply it x times ;] You won't be able even to see on what alt you are or read anything in kabina.

I think the camera shake is funny as ** :),

too bad we cannot do it though because trackir takes precedence

Thanks for the work and the update Yoda. If Tacview is updated to a new revision, would LRM have to be updated as well? Looking forward to trying out the optimized LRM.

I will need to speak to the guys behind tacview.

Havent been able to get in touch with them.

Originall the problem is that tacview calls "logetworldobjects" every frame!

(but only logs every 0.1 second, so example : if you have 50 fps, basically

80%, 40 out of 50 frames, of the lockon export cpu power could be considered wasted.)

and also calls some time variables and such that I already have - there is no need for tacview to load them again,

so i stopped tacview calling this (and removed some unneded if statements

that my scripts already guarantee). This made it quite a lot faster, in combination with it not running every frame,

and is lrm of course now forbidden to run the same frame as tacview does.

If there is a new version released of tacview im sure we could integrate or

just run it straight.

The second advantage of integrating it is that we do not need to worry about

users bypassing lrm by running custom cheat scripts included in their tacview lua script

.

New Status update

Finished (being tested) :

• Eagle RadarFix : F-15 IFF, elevation/azimuth follow target(s), (Required for : LBST, 8B3A, target Step), new ECCM, stt->tws fix
  
• Ru Fighter radar : new ECCM, ECM range estimation
  
• Cursor step : Now stores contacts slightly shorter time than previous lrm 2.0 BETAs and also has a delay each time you step.
  Also includes LBST & 8B3A (like before)
  
• Reduced chaff
  
• Counters to barrell exploit
  
• Counters to unrealistic radar floor exploit
  
• Customizable payload control, including full database of standard weapons
  
• Dead is Dead : No missiles fired when multiple major systems down (>=3)
  
• Lua export log (exports trucks per airfield)
  
• Customizable spool time
  
• Only takeoff from runways (or Kuz)
  
• Airfield ownership (can only take off at friendly airfields)
  
• Only refuel at parking
  

Not yet finished

• Airfield Ownership indicator lights (i'm leaving this out for the moment reasons:
  
  1. it requires more work than any other Airfield mod
     
  2. People can always read the briefing
     
  3. Those that don't read the briefing won't know what the flashing lights mean anyway!
     

Have you also noticed, that the server is almost totally empty 24/7 a week, except few test- or event-moments?

 

(..coming back to: .."you can program ya ### off with all your nice beautifull ideas, if ppl are not "educated" enough and falling back to "easy customer usage" and "fast food" behaviour :megalol: +:cry:+:doh:)

I still believe it comes down to having people in server to "jump-start" it every day. There simply isn't any reason for someone to join a empty server unless they intend to do air-to-ground. Once a server establishes regulars to come in and play its not to difficult a choice for others to join. Besides when there is only 6+ servers typically around on a daily basis and maybe 100 different players connecting to hyperlobby to actually fly on a given day its not likely players will have a difficult choice in choosing between two different servers because generally only one has a sizable group in game.

Yes what Grimes say, and naturally Stats will create regulars.

I think the camera shake is funny as ** :),

too bad we cannot do it though because trackir takes precedence

Ahhhrrrrr as I don't use TiR didn't know it takes this... Baaad :(

I still believe it comes down to having people in server to "jump-start" it every day. There simply isn't any reason for someone to join a empty server unless they intend to do air-to-ground. Once a server establishes regulars to come in and play its not to difficult a choice for others to join. Besides when there is only 6+ servers typically around on a daily basis and maybe 100 different players connecting to hyperlobby to actually fly on a given day its not likely players will have a difficult choice in choosing between two different servers because generally only one has a sizable group in game.

Still Grimes, it's pretty depressing to see everyone flocking to the server thats 'serving fast food (sorry i mean flight) to the community' day in and day out in HL :noexpression:

Sorry Mustang, the mission is what the player makes of it. There are also other reasons why our server is popular besides having enemy bases that are with 160 km of each other. Like admins who enforce the rules, a consistently reliable server and stats etc. Also, if the player wants a longer trip to the front lines to setup for tactics, you just simply pick a base that is further out to spawn at.

Anyway, this is off topic and I won't comment on server popularity anymore. The sad fact is that there are not enough Lock On players to populate more than a few servers in Hyperlobby. If the RvE Realism server is not populated you can't blame it on the mod alone when the player base is not there.

Also, people on a whole are always resistant to change. Let's hope people will keep an open mind when it comes to the options made available that Yoda is working hard to implement.

.

Private online testing started!

The new rewritten LRM 2.0, now beta 1.5, is up on HL

with server name "LRM2_beta1.5". This server is passworded,

and you can get this password if you request it from me in a PM.

Current mission on server : 169th server mission (with 169th permission)

The mission was chosen to provide the highest possible CPU load for stress testing.

Current features active on server :

• Eagle RadarFix : IFF, automatic elevation/azimuth, new ECCM
  
• Ru Fighter radar fixes : new ECCM(faster than eagle), ECM range estimation
  
• Cursor step support (new version with built in delay)
  
• Reduced chaff
  
• Counters to barrell exploit
  
• Counters to unrealistic radar floor exploit
  
• Payload control - exit mission screen if illegal weapon types loaded
  
• Dead is Dead (no firing missiles with severely dmged aircraft)
  
• Only takeoff from runways
  
• Tacview support
  

NOTE : Server does not run ALL LRM 2.0 features, only the features that will be default ON at LRM

2.0 release (=list above). The other features are programmed in LRM 2.0, but simply turned off.

AMRACT/ingame messages are currently NOT active on the server, as this is a test of LRM only.

Source code is available here :

http://yoda.reservoirselite.com/LRM%202.0%20with%20snap%20support/onServer/Config/export/export.lua

If anyone knows how I can get in touch with Vyrtouz (maker of Tacview), that would be great,

as I am currently using part of his scripts.

.