sedenion

Like other axes, you have to add axis mapping curves functions calls using proper parameters. Since this is the TFRP T.Flight Rudder Pedals you can edit the MapTFRPRudder.tmh file and write the proper function call, either or J curve or S curve depending your needs, for example: // store device alias alias Dev = &TFRPRudder; // buttons and axes mapping here SetSCurve(&Dev, TRPRIGHT, 5, 0, 5, 0, 0); SetSCurve(&Dev, TRPLEFT, 5, 0, 5, 0, 0); SetSCurve(&Dev, TRUDDER, 5, 0, 5, 0, 0); If you include new hardware device to be "mapped" by script, you have to modify the axes assignations for the virtual device. The axes assignation (hardware device axis -> virtual device axis) is done using the MapAxis() function. You'll see call to this function at bottom of each relevant mapping script file. For exemple, here is how Warthog Throttle axes are mapped (MapThrottle.tmh): // -- Axes Assignment -------------------------------------------------------- MapAxis( &Dev, THR_LEFT, DX_ZROT_AXIS, 1, MAP_ABSOLUTE); MapAxis( &Dev, THR_RIGHT, DX_Z_AXIS, 1, MAP_ABSOLUTE); MapAxis( &Dev, THR_FC, DX_SLIDER_AXIS, 1, MAP_ABSOLUTE); MapAxis( &Dev, SCX, DX_XROT_AXIS, 1, MAP_ABSOLUTE); MapAxis( &Dev, SCY, DX_YROT_AXIS, 1, MAP_ABSOLUTE); Now, here is the axes assignation from the TFRP mapping file (MapTFRPRudder.tmh) : MapAxis( &Dev, TRPRIGHT, DX_XROT_AXIS, 1, MAP_ABSOLUTE); MapAxis( &Dev, TRPLEFT, DX_YROT_AXIS, 1, MAP_ABSOLUTE); MapAxis( &Dev, TRUDDER, DX_ZROT_AXIS, 1, MAP_ABSOLUTE); As you can see, both share the same virtual device axes, that's why your rudder and throttle share the same axes of the Virtual Device. To avoid that you have to make choice and reorganize the current axes assignations. If you want to keep using your rudder's 3 axes, you'll have to sacrify Thottle axes since there is only 8 availables virtual device axis, they are the following : DX_X_AXIS DX_Y_AXIS DX_Z_AXIS DX_XROT_AXIS DX_YROT_AXIS DX_ZROT_AXIS DX_THROTTLE_AXIS DX_SLIDER_AXIS If you want to go further and perform more complexe code adjustement, please consider reading the TARGET Script Editor manual: https://ts.thrustmaster.com/download/accessories/pc/hotas/software/target/target_script_editor_basics_v1.5_eng.pdf

I am not the author of the tutorial youtube video. Open Mod Manager expect specifically formated XML file to interpret repository content, it cannot do anything with a .git repository file. To create an online repository, you need: Create Package files for each mod/liveries (Tools > Package Editor) Upload all Packages files in an available online location Create repository XML file that list all available packages with proper parameters and optional data (Tools > Repository Editor) Upload the XML file in an available online location You'll found a quick (and elusive, sorry) tutorial about Repositories in this post with additional/updated information here I advise you to first learn to create packages, testing them to verify all work fine, then once you'll have a local library with all packages you'll be able to quickly create a repository XML file via automatic generation from library content.

This is in the dame file bellow the JOYX and JOYY axes lines... however for FC slider, this is a "J" curve, you can't add dead zones. If you want an S curve to add dead zone on this axis, you have to edit the MapThrottle.tmh file (at line 167) to modify the THR_FC axis curve function call with desired parameters. Example: // Disable the original function call by adding // at begining of line // SetJCurve(&Dev, THR_FC, CJ_THR_FC[0], CJ_THR_FC[1]); // Add new SetSCurve() call for THR_FC with desired parameters SetSCurve(&Dev, THR_FC, 5, 0, 5, 0, 0);

Not necessarily. Real aircraft do have controls assistance that changes the required force to set stick at position depending speed and other factors, this in order to prevent the pilot to make excessive maneuvers and keep the aircraft stable. You can't simulate that except using FFB devices, so software have to emulate this using some software curves and deadzones.

I never noticed it, but I confirm M2K have the same throttle deadzone as F1... However I don't see any pitch/roll deadzones in the M2K.

Theoretically, but it seem this indeed does not launch the exe file. I have no clue why. In the same tmc file line 105 and 106 : int CS_JOYX[5] = { 0, 0, 0, 0, 0 }; //< Joystick JOYX int CS_JOYY[5] = { 0, 0, 0, 0, 0 }; //< Joystick JOYY The three first values are the dead zones values, respectively the upper (or right), center and lower (or left). The fourth value is the curve factor, and the last value is the zoom (or crop/saturation) value. All values are in % (range 0-100).

I also find the alarm sounds (not only AOA) a bit too loud. BUT... I would add that the AoA sound become quickly annoying because we reach it very quickly and often. First because of control stick Y axis range problem (can be attenuated temporarily with axis curve), and secondly, because I think that in the real aircraft the hydroelectrical system would prevent pilot to reach the AoA limit too easily by applying physical resistance to the stick, which does not exists for most of us that don't own FFB stick. This is a hard choice but I think Aerges should implement internal control damping to prevent the player to naturally have the strength of hulk, In other words, the player should not be able to reach the very end of stick run.

"Lisse" refer to something without rugosity nor asperity, primarly to qualify a surface. "Bidon" refer to container for liquid, so the translation by Google is not really correct. Better translation for "bidon" is indeed actualy "tank" or "jerrycan", considering a "bidon" can contain any liquid.

Minimum time turn is apparently neither STR nor ITR, but another combined/computed turn performance evaluation. Some data here (don't know if this is really related, but that the only thing I found): https://arc.aiaa.org/doi/abs/10.2514/6.1985-1780 https://arc.aiaa.org/doi/abs/10.2514/8.10661?journalCode=jans

Great, it only remain the flaps efficiency problem so

Did you tested the 2000 recently ? They changed the FM, this is way better now. Apart of the pitch sensitivity problem (which is obvious), I tend to say this is the same problem as the landing-like-a-brick, there is something wrong with the flight model, lack of lift... I especially suspect flaps to be too poorly efficient, they changes almost nothing except the drag and warnings.

You work in the big structure where one or several people are here to verify. Not everybody have such luxury.

I can assure you that even the most obvious thing that the common user will try first, can remain perfectly obscure for the developer working in the "code" side, because he is working on a totaly other thing since, lets say 5 days, so doesn't even have the idea to try and check the thing that was OK and coded 6 month ago. And as gnomechild explained there is so many things that can occure and make the dev thinking all is Ok and finally no... Usualy developper work on their own "copy" of the software, the published "copy" is not the same...

"Why don't I have checked that before release ?" is typically what devs think when they realise they made a release thinking all was ok and discover 5 minutes later there is a big bug... Except if you have army of beta-testers, one cannot verify each single thing and scenarios each release, one verify what we think has been modified. However modification in portion of the code may affect apparently unrelated other elements the devs may forget to check.

I think we almost all agree that payload drag is exaggerated, this was already observed prior to the last update... But anyway it seem many thing still to be adjusted.

Well, not realy, my perspective is more flight-model accuracy related. Imagine for example our simulated Mirage F1 can reach 1500kts at sea level, this would obviously mean that drag is not properly adjusted or thrust way too powerfull, so the flight-model is potentially all wrong. EDIT : the same problem exist in the opposite situation, in the case the simulated Mirage F1 is stupidly stuck at 750 kts to fit an arbitrary limit given by standard specifications.

Possible, but this 1470km/h number seam to be nothing more than the conversion from Mach 1.2, a well rounded number, sounding more arbitrary than "scientifically" measured...

What disturbs me is that the alleged Mirage 2000 max speed at sea level is the same, 1470 km/h / Mach 1.2... however Mirage 2000 have 2.5 tons more thrust than the Mirage F1.

I would agree the general reasoning... now, the question remain : Is this mentioned 1470 km/h max speed of the Mirage F1 an operational maximum speed, or the maximum sustained speed actually reachable by the aircraft according thrust/drag parameters.

The Mirage F1 in clean configuration have probably not much more drag than the F-104... I think the Mirage F1 cross section is even smaller than the F-104, wing are a little larger I guess. After, you have thrust, etc...

The alleged maximum speed of Mirage F1 at sea level is 1450-1470 km/h depending the source... so ~780-790 kts, which seam reasonable maximum reached speed for such aircraft.

869.67 kts is the world known record with an F-104... https://www.quora.com/What-is-the-fastest-speed-achieved-at-sea-level-by-a-manned-aircraft

As I said, I think this were not intentional...

Default gamma is 2.0 or 2.2... 1.5 is quite dark.

I think the devs are hard working on the flight model and pushed a WIP version not realising it will be embedded in the update.