sedenion

hi people, Very long time I am not really come here. Since the Mirage 2000 is now very near to its final stage, I decided to release my Cockpit indications fix. This is a fix for all HUD, VTB (Radar), RWR, etc symbologies and fonts. The purpose is the same as few years ago, but, in a way more aboutished way. I reworked all texture almost integrally, recreated fonts textures from scratch, aligned and adjusted all elements. More details here, hop you will enjoy: https://forums.eagle.ru/showthread.php?p=4108348#post4108348

Hi, Now that the Mirage 2000 seem very close to its final stage, I come back with fix for cockpits indications alignment, textures, etc. This mod is a global rework of HUD, Radar, RWR and cockpit digital display (PCA, etc..) symbology. My goal was to: - Being the closest as possible to the real aircraft's indications and visuals, in location, size and proportions. - To rationalise elements positions and proportions, for a perfect alignment. - Improving fonts and textures for better visual render, including fix for mipmap filtering and opacity (brightness) adjustment issues. The result is that all textures was almost integrally recreated, including new fonts, created from scratch and almost All LUA files related to cockpit indication was reworked... I hope people will enjoy (download link at bottom of post). * General - All symbologies and fonts textures redone using pixel-aligned vector graphic - New textures pack in DDS format for better quality alpha mipmapping * HUD Symbology Rework - New HUD font, two separate textures for large and small text - Adjusted HUD font dot character width for correct font spacing - New "zoom-proof" HUD heading tape texture with corrected ratio - Fixed HUD heading tape mipmaping problem - New "zoom-proof" HUD symbology texture with harmonized style and tickness - HUD elements rationally aligned together according real data & best guess - Fixel HUD dynamic elements opacity and brighness control - HUD symbology color adjusted and default opacity fixed. * VTB (radar screen) Symbology Rework - New VTB font texture - New "zoom-proof" VTB grid textures with correct alignment - Fixed VTB grid textures mipmaping problem - New "zoom-proof" VTB heading tape textures with corrected ratio - Fixed VTB heading tape mipmaping problem - New "zoom-proof" VTB symbology texture - VTB grid, font and symbology textures style harmonized with screen effect - VTB elements rationally aligned together according real data & best guess - VTB symbology color slightly adjusted * RWR Symbology Rework - New dedicated RWR font texture - New RWR symbology texture - RWR font and symbology style harmonized with screen effect - RWR elements rationally aligned and adjusted for better readability - RWR symbology color adjusted * Miscellaneous Cockpit Displays Rework - New PCA font texture closer to the real digital display - PCA digits position slightly corrected - PCA digits color slightly adjusted - New common LCD font texture. - Adjusted position for fuel gauge and PPA bomb display - New radio Dot-Matrix font texture. - Changed UHF radio display from LCD to Dot-Matrix - Version for latest DCS Stable Release - v2.9 (2021-08-20) for DCS World 2.7.5.10869 (2021-08-11) Mod Download page (DCS Website) - Version for latest DCS Open-Beta Release - v2.9 (2021-08-20) for DCS World 2.7.5.10869 (2021-08-11) M-2000C_-_Cockpit_Indications_Fix_v2.9.zip

Do not use Target GUI, it is not suitable for advanced scripting, you have to edit and run the script from Target Script Editor. If you try to edit an advanced script using Target GUI, it will always rewrite le script using default minimalistic pattern.

What do you mean "all changes in scripts are deleted" ? I don't understand...

Your code cannot copile, you forgot a closing braces. Pay attention, every time you see an opening brace '{' it must be a closing one '}' corresponding... In your case, you forgot to close the main() or while()... you must add a closing brace, like that: [color=Navy]int[/color] main() [b][color=Red]{[/color][/b] [color=Gray][i]//< main() function opening brace[/i][/color] [color=Gray]// mapping commands here[/color] [color=navy]int[/color] i=0; [color=navy]while[/color](i < 52) [b][color=Red]{[/color] [/b][color=gray][i]//< while() loop opening brace[/i][/color] DefEventHandler(EV_HID_INPUT_DATA, &Throttle, i); i = i + 1; [b][color=Red] }[/color] [/b][color=gray][i]//< while() lopp closing brace[/i][/color] [color=red][b]}[/b][/color] [color=gray]//< main() function closing brace[/color] [color=navy]int[/color] EventHandle(int type, alias o, int x) [b][color=red]{[/color][/b] DefaultMapping(&o, x); [b][color=red]}[/color][/b]

At the end of the main() function, just before ce closing brace '}' : int main() { // your mapping commands... int i=0; while(i < 52) { DefEventHandler(EV_HID_INPUT_DATA, &Throttle, i); i = i + 1; } }

I realised I missed the september 10 update, but with the last update it is even worst, the radar is full of bugs...

In low PRF (BFR) mode, radar contacts who are flying away are displayed as reversed V like in high PRF (HFR) mode, instead of a square.

All si in the title, HUD brighness adjustment does not work for dynamic elements such as gun snake, gun reticle circle, rocket reticle circle, CCIP line, etc...

I made some tests with the Device Analyzer, then review my own C/C++ implementation of HID game device handling, then all becam clear: The Microsoft HID API does not allow to get the current device state until driver send an input data chunk (which do contain the device state), and driver send input data chunk only on physical device state changes (and according some filters to prevent data flood)... So, when you start any software (Device Analyzer or DCS, or whathever), the initial device state is defined by the software (neutral or 0 axis with all buttons released in most cases), and the device state is updated only when you change the device's physical state, forcing the driver to send an input data chunk to all softwares listening to HID events... In two words: It is not a bug, it is a Microsoft API limitation, what you want to be done, cannot be done, even at C API level... Complains to Microsoft's dev team :D

I understand, but this never anoyed me this way. You maybe can found some helpfull code to adapt in my sws.tmh file in the "TM Warthog DX++" profile. The module is not used, but the code work. I used it a while to do this synchronisation when specific button is pressed. This may work by putting the commands in the "main()" function instead by calling it via conditionnals and events withing the event callback.

I never tested. If you want something to be done ONCE at profile loading, you need to put it within the "main()" function, preferably after the call to Init() (or DXpInit()) function. The EventHandle() function is a callback, called EACH TIME (and only if) new data is received from the device (button press/release, axis move, etc.) I think the better way to avoid this problem is to map all switches with "PULSE", like: MapKey(&Throttle, BSB, PULSE+DX51); MapKey(&Throttle, BSM, PULSE+DX52); MapKey(&Throttle, BSF, PULSE+DX53);

Ok, the logic is somewhat fuzzy, This a mix of my own habits, original HOTAS design, and according real HOTAS behaviors of the module I use the most: M2000-C... For example, the "submod" directly reflect the Mirage 2000 C "Master Arm" mode. I use the Boat switch to switch weapons modes, so I need different behavior depending Master On or Off. In paralelle, I am used to use the TMS (Hat2) hat as view control (zomm in, out, center view, padlock-view lock and release, etc.), since I don't use VR nor TrackIR, I use the S1 button for MAGIC IR Lock/Unlock which is a very specific Mirage 2000 feature, etc.

I don't undestand the question. You mean, the choice I made for the mapping, or how it is programmed ?

Do not use "TARGET GUI", use "TARGET Script Editor" instead... "TARGET GUI" won't allow you to properly edit profile script. Indeed, if you want to modify the default mapping, you'll need to put hands in code... I am not a kid, and I have known DOS Basic too :D TARGET Script language is very close to C in term of syntax (better than BASIC). Not really hard once you learned and understand the 3 or 4 essential things.

Hi, I see this topic still alive 2 years later and I made some progress since the first "finding". If you are interested in some advanced Warthog programming, I let you two profiles I made last year you can use as inspiration or reuse. I never publicy released them since now because... well, good question, why ? I don't know... The two profiles are almost the same except that the "TM Warthog DX++", which is an older one, profile includes some unused .tmh files which implements advanced functions, which can interest the most intrepid ones of you. All files are commented, code explained as possible to allow other people (and myself when I read back years after) to understand, reuses and adapt. https://forums.eagle.ru/attachment.php?attachmentid=215970&stc=1&d=1566468192 https://forums.eagle.ru/attachment.php?attachmentid=215971&stc=1&d=1566468192 Enjoy TM Warthog DX++.zip TM Warthog Universal HID.zip

Funny coincidence, i just passed few hours by rewriting the default keyboard and joystick key binding file, both for commands name and default combo key assignation. If we let the command naming problem, which is easy to fix, the main problem with the current available commands is the emphasis for "clickable cockpit" and the lack of consideration for "HOTAS+Keyboard" way. The typical examples are Master Arm Switch and the Radar Power Knobs. The Master Arm Switch does have a toggle command, which make it easy to map on a keyboard key, and this is pretty cool, but in the same time this is the typical "Mode Switch" command you need to map as separated On and Off positions on the HOTAS to create dual-mode mapping, and: There is no "Master Arm On" nor "Master Arm Off" available like for the Airbrake or Landing Gears, which is pretty frustrating. In the other hand, the radar power, which is another very important command, have the four separated knob positions available for mapping (Off, Warmup, Standby, On), but no toggle/Cycle command. However, this is precisely where we could need a toggle/Cycle the most, because you need to enable and shutdown the radar quickly, but not using 2 or 4 different keys or buttons to do it. What you need, is an unique command mapped on the "I" key which cycle through Off/Warmup/Standby/On... Here are to me the missing commands in the current input: - Master Arm On - Master Arm Off - PCA Stores Buttons Cycle (I mean, one or more command which allow to cycle smartly through the available weapons and fuel tank, including the AG Gun button. This can be: "Select Next PCA Store Button", "Select Previous PCA Store Button" and "PCA Store Buttons cycle".) - Bomb Fusing Unarmed/Delayed/Instant - Radar Altimeter On/Off (we don't need a quick access to the "test" position) - Radar PRF Mode Low/Int/High (infinite cycle) - Radar Sweep Angle Increase - Radar Sweep Angle Decrease - Radar Sweep Angle 30/15/60° (infinite cycle) - Radar Scan-Lines Increase - Radar Scan-Lines Decrease - Radar Scan-Lines 2/1/4 (infinite cycle) - Radar Emit/Standby Toggle - Radar Power Cycle Warmup/Silent/Emit/Off (infinite cycle) - Radar Mode PPI/B-Scope Toggle - Radar TDC Mode S/Z Toggle - Radar IFF On/Off Toggle - RWR On/Off Toggle - D²M On/Off Toggle - Decoy Dispenser Mode Manual/Semi-Auto Toggle - Decoy Dispenser Program Cycle (infinite cycle) Note: Here we also can imagine a command which cycle through only 3 or 4 Decoy programs, which are the most commonly used, instead of cycle through the all 11 knob positions... - Decoy Dispenser Box On/Off toggle - Jammer Master On/Off Toggle - Jammer Emission Mode Off/Manual/On Cycle - Selective Jettison On/Off Toggle (command automatically open and close the safety cover) - Parking Brake On/Off Toggle - Cockpit Illumination Toggle (I Mean, a command which disable and enable all the cockpit backlinght and floodlight in an ideal level, with all lights at 75% for example. The current "Console Floodlights" toggle is pretty useless, this is not what you need when you want to enable and disable the cockpit illumination) - Dashboard Floodlights Toggle (0/75%) - Dashboard Backlight Toggle (0/75%) - Console Floodlights Toggle (0/75%) - Console Backlight Toggle (0/75%) - HUD Power On/Off Toggle - HUD Declutter On/Off Toggle - VTB Screen On/Off Toggle - Gun Arm Armed - Gun Arm Safe People who use the PCN, INS and Radio in regular basis would probably add some other commands, on my side I don't use these devices enough to tell what is needed and convenient here. I let you my personnal rewrite of the input LUA files in attachment... https://forums.eagle.ru/attachment.php?attachmentid=204918&stc=1&d=1550837488 This is a totaly rewrited input command list, if you use it, you will need to recreate almost all your binds (and if you include it in the module, you will need to update the manual): - I renamed all command according both current module manual and DCS common style and for better readability - I changed some commands category to better fit the DCS commons - I added some already existing categories in DCS commons (Modes, Weapons, Autopilot, etc...) - I removed some M2000 specific categories, then moved commands in DCS commons: Systems, Flight Control, Modes, Weapons etc... - I renamed some M2000 specific categories with shorter names - I added some missing commands - I removed commands which have not effect (not implemented, deprecated features, etc.) - I removed some barely usefull command, like the intermediary levels between "off" and "full" of the cockpit lights. - I corrected some existing mistakes in the current input LUA script - I added default combot key bindings according DCS commons where possible - I changed some default combot key bindings to fit the DCS commons (Trim commands for example) Anyway, I use this for myself, and this probably can be perfected. M-2000C - Input Fix.zip

OvGME behaves as follow: Mod installation: 1 - Backup: Copy original files to backup 2 - Apply: - if Zip: Extract files to destination (overwrite original files, no TEMP used) - if Folder: Copy files to destination (overwrite original files) Mod uninstall: 1 - Restore: Copy files from backup to destination (overwrite files) File copy is always performed using the CopyFileW() WinAPI function.

As I said, the binary installers are locaded within the "redist" folder of the OvGME project folder... You can mirror it as you want.

It's only an usual "life reboot" like I made it several time... nothing serious. When I deleted my github account, I did not expect it will produce this "artifact" :D

Hi, i confirm I deleted my GitHub account. The full source, including binary release and all needed stuff to rebuild all are available to download at this adress (12Mo) : http://www.ovoid.org/ovgme/OvGME.zip (binary installers are under the "redist" folder). Please, download and create mirrors, because the ovoid.org domain will also "disapear" next month. EDIT: I can also give you my work for the OvGME's successor I never finished... You can finish it if you want, or use it to create a new appli... enjoy : http://www.ovoid.org/ovgme/ModManager.zip Notice to developpers: Both OvGME and its unfinisehd successor was developped for GNU g++ compiler. You will need to adapt some details to compile it using Visual Studio

DCS uses all available cores, as evey other applications. More precisely, process and threads of DCS are treaterd by O/S Kernel as any other application through chipset/bus/firmware and OS Kernel auto-optmization etc.... People complaining about "non multi-core" or "Why GPU is at 99% while CPU is at 12%" simply don't understand anything about computing and programming, and make assertions and supposition based on bad understandings of how thoses things works...

There might be several good answere to "why Default shadow put GPU to max load even with few trees on screen ?". The "Default" shadow use shadow mapping method, while "Flat" use another one (don't know which one exactly). And shadow mapping is a typical "per-pixel" shader computing, while the "Fat" is - I guess - more a "per-polygon"... Constraints and behaviors are not the same. One thing you can see at first glance, is that even if you are close to trees and see only 2 trees, the entire screen is concerned by the "shadow map testing", which mean, ALL PIXELS of the image are tested... To know exactly "why", we must know the shadow mapping algorithm of DCS.

When CPU have more job to do, the GPU have to "wait" for CPU to finish its job; When CPU have less job to do, the GPU is free to loop at maximum speed... This is why your GPU load changes with CPU load. To be correct, the GPU don't realy "wait" the CPU, but the draw-calls (the stage in the application loop where program calls DirectX functions to draw something) can be separated by more or less "time" between each frame (loop)... The typical loop is: 1) Get input data (pure CPU job) 2) Update scene / IA / etc (pure CPU job) 3) Draw Scene (GPU job) 4) goto 1) Considering this, depending the time CPU or GPU job takes within the loop, the load will be in favor of CPU job or GPU job...

The most important thing to understand I think, is that nothing can really be significantly changed. The debate about multi-core CPU and game exists since the firsts dual-core CPU (10 years ago), with always the same "myths" and the same answere. There is no way to really exploit the multi-core to improve performance of such game-like application, even if the application is multi-threaded. Multi-Core CPU were designed both for commercial purpose and considering some technical limitation about voltage/heat (this is my opinion). What multi-core CPU provide is simply another computing unit which spread load between cores to allow the CPU to run at very high clock frequency without burning (this is how I interpret the Intel's and AMD's multi-core strategy)... The small "plus" is that this allow some OS/Thread related optimizations running at low-level, done by the hardware/firmware in a automated way, that's all, the "illusion" stop here. DCS is probably already optimized at its best considering the real terrain of technical limitation and APIs... Simply enjoy this, and stop beleive a game can magically exploit the super full potential of 8-cors CPU using a super programming technics, this is myths, partially maintened by CPU manufacturers.