Mirage 2000-5

[5H1N0B1]

Hi dude,
First of all, please, see bellow a FPS improve of the 2000...
https://dl.dropboxusercontent.com/u/109132916/Mirage-2000.tar.gz

Finally I used setlistener for the stick movments, put a flag to not have "double" execution of the SAS script, and lower the SAS loop refresh to 4/sec...

Code: Select all

################################################ Main init loop################################################
#####         Perhaps in the future, make an object for each subsystems, in the same way of "engine"   ########
################################################################################################################
var main_Init_Loop = func(){   
       
   
    print("Radar ...Check");
    settimer(radar.init, 5.0);
   
    print("Flight Director ...Check");
    settimer(mirage2000.init_set, 5.0);
   
    print("MFD ...Check");
    settimer(mirage2000.update_main, 5.0);
   
    print("Intrumentation ...Chsck");
    settimer(instrumentation.initIns, 5.0);
   
    print("Transponder ...Check");
    settimer(init_Transpondeur, 5.0);
   
    print("system loop ...Check");
    settimer(updatefunction, 5.0);
   
    if(SAS_rudder == nil){
        var SAS_rudder = setlistener("/controls/flight/rudder", func {
                #mirage2000.computeSAS();
                Update_SAS();
        });
    }
    if(SAS_aileron == nil){
         var SAS_aileron = setlistener("controls/flight/aileron", func {
                #mirage2000.computeSAS();
                Update_SAS();
          });
    }
    if(SAS_elevator == nil){
         var SAS_elevator = setlistener("controls/flight/elevator", func {
                #mirage2000.computeSAS();
                Update_SAS();
          });
    }

}

######################################SAS double running avoidance #######################################
var Update_SAS = func (){
   
    if(SAS_Loop_running == 0){
        SAS_Loop_running = 1;
        mirage2000.computeSAS();
        SAS_Loop_running = 0;
    }
}


##################################################################################################################
var UpdateMain = func {settimer (updatefunction, 0.25);}


var updatefunction = func(){
     #deltaT = getprop ("sim/time/delta-sec");
   
     Update_SAS();
     #mirage2000.computeSAS();     
     mirage2000.UpdateMain();
}

Thanks to "Nasal guys", I learn a lot on "what is ressource consumming ?"
You should be able to dogfight in Israel, where (if my memories is good) there is not a lot of 3D sceneries.
Please, make test. For now there things that I can still do (like integrate the Gjis/Philosopher "canvas nav", which is really sexy) to reduce more the time between frame.
It will take a little time...

787 or A330 work faster than this one.

<- if you dogfight with these beauty, you are awesome

About the missile : The script was originally taken from fox2.nas, and at the begining, there is a bombable "compatibilty". I used to destroy C172, in a C172 invaders bombable scenario. I didn't try to shoot them with the canon, but the 2000 have a mp variable which is dedicated to bombable. I'll check that.

The about the visibility on multiplayer this does not work. You have to understand that the missile created an object on your own property tree, but this can't be visible for other multiplayer YET.

But before working on missile visibilty in MP, I have a lot of rework to do in the m2000 nasal, and put more Object programming : First the radar (after reworking this, time between frame will be even faster:) ), change/adapt the "target" object, (in order to avoid double object for the same thing, and also allow to create a target designed by a laser pod, for A/G) and then splitt the missile in differents objects (FDM, graphical, main etc..)
And make them avoiding aircraft with a "flare" compatibility.
The nasal guys showed me the direction. But the task is huge. It can't be finished in the next 3 month...

But I'm glad that you like this plane
Do not hesitate to give me feed back.

5H1N0B1

[HelldiverSquadron]

No worries, mate. You've done wonderfully. I'll try out the version you just posted and get right back to you. Many thanks

[HelldiverSquadron]

My God. I downloaded the new v2.12.1 bug fix release, and it is fantastic in how fast it loads. the Mirage has MUCH better framerate, but it still is on the slower side and there is still no way I could feel good about taking on a MP dogfight. and that was OFF of MP.

Many thanks

[5H1N0B1]

That's a beginning...
I'll look how I can reduce more the lags and increase framerate.
But the last one was a big improve.

Have fun with this one for a start

[Hooray]

Thanks to "Nasal guys", I learn a lot on "what is ressource consumming ?

@5H1N0B1

Just so that you know, we've been tossing around some ideas to provide better runtime inspection means for callbacks running via listeners or timers - basically, it should be possible to provide new extension functions that return the current state of things, including file name, line number - and optional identifiers. This would then also allow us to run the equivalent of systime() to see how much time is spent in each callback, and sort them accordingly - analogous to ThorstenB's performance monitor, just specific to Nasal-space callbacks.

Philosopher has done quite a bit of work related to this, and while most of it is much more sophisticated, we could reuse a portion of it, to pull this off

[Philosopher]

yeah, a little too sophisticated... when I get back into naC hacking, I will probably start with easier things than that problem again .

Anyways, yes I can provide info and ideas with that, but note that it does require recompiling. Or perhaps someone can provide you with a modified binary.

In the meantime what you could do is keep taking things out until you find some things that slow FG down. Start with the 3D model (eg replace with UFO) then take out various parts of Nasal, particularly those that have timers, listeners, or other callbacks. From there you can narrow it down by checking individual call times via systime(), like my framework does (on a large scale), or maybe debug.benchmark when I provide a small patch...

Good luck! I'll help if I get time.

[Hooray]

regarding callbacks invoked via timers and listeners, I would also suggest to always maintain a counter to see how many instances of each loop are running - i.e. initialize the counter with 0, and then use +=1 and -=1 at the end of the callback.

you can then easily dump all counters to the console via print

[HelldiverSquadron]

Hello all,

I went to a very bleak place with no terrasync about fifty miles from me hometown in Adelaide with the M2000-5 in FG. Same result: better, much better, framerate, but nonetheless I still couldn't fly it with stability.
Just thought I'd put it out there that it's not the scenery or even ocean. tried that.


Friend

[Hooray]

one of the more common reasons for this is that multiple instances of a loop are running without the developer being aware of it, which is why I suggested to inc/dec-rement counters.

[HelldiverSquadron]

That's all Darkonian to me. haha

[Hooray]

...to me too, I'm just typing for bananas: see Philosopher's signature


I don't quite remember everything we have got here, but we do have finished code that allows tracking GC stats per naCall() - which basically means that any callbacks invoked via listeners or timers can be separately tracked, so that you can get a short summary of "GC pressure" (events), i.e. in terms of newly allocated/freed blocks (aka "temporaries") - these stats would need to be gathered over several minutes to be "useful". But basically this can tell you just how bad a certain callback really is in terms of GC stuff. Obviously, it doesn't help with algorithmic stuff - i.e. inefficiently coded loops and such.

(but this requires applying patches and rebuilding SG/FG from source)

[5H1N0B1]

"Given enough time, a hypothetical monkey typing at random would, as part of its output, almost surely produce all of Shakespeare's plays." (Infinite monkey theorem)

Just kidding.
thanks for the +1/-1 thing, that help.

And I saw that I had(and still have lot of loop, waiting 1 or 2 variable change to do some code...
I think the best is to shut down the loop until the setlistener triggers it...
(I still have some change to do...)

[Hooray]

you can use the loopid method for these things, to ensure that there are never multiple versions of the same loop running at the same time

[HelldiverSquadron]

hm

[Hooray]

to avoid such errors from ocurring, I usually tend to use a Nasal class as a wrapper for loops with the loopid method - that way, managing different "tasks" running via loops is straightforward - and you can even add loop-specific logging code easily.

In addition, no matter how often someone invokes a timer or listener, the object can be implemented as a singleton to ensure that only a single instance ever gets to run to avoid lag.

You can come up with something like a ManagedLoop or "Task" abstraction that handles these things, all based on the loopid method, where loopid is just a member field - i.e. me.loopid is checked.
Callbacks would then always refer to func object.callback(params)