sedenion

As my grandfather said: better, is the enemy of good. :smilewink: maybe I am wrong, but i think we can't really have an FM that strictly fit with data charts while being close to the real aircraft behavior. Aerodynamic is a too complex things to make this acheivable in a generical simulator. Only an approximation, a good deal between data charts and aircraft global behavior, can be achieved. My two cents :)

Some months ago, the FM appeared to me relatively okay... but at the same time, some people was complaining about some small innaccuracies with data charts (while beleiving that the "data charts" are the only thing you need to have a "realistic" FM). I think things taken the realy wrong direction from this time, but i was absent for long time, so i don't know. For now, i consider the Mirage 2000 unplayable except for navigation, bombing and BVR (only BVR!)... but, to me this is NOT a mirage 2000, even if i never piloted a real M2k... this is something else, an aircraft that is clearly unable for dogfight.

I think you are a bit nasty with Razbam ... As you said, FM is hard to do ... But, what you said reminds me that Razbam used some former Mirage III pilot feedbacks to adjust the FM. So, yes, in addition of some error due to an "overshoot" of fit to "data charts" (by creating FM with the ultimate goal to fit with "data charts", you easily forget how the aircraft should fly), they probably used too much Mirage III experience to evaluate the global performance. Anyway, this is only a guess... But i think razbam should relax with "data charts" and takes some time to evaluate the FM in a more global and intuitive way... To me, the Mirage 2000 is now clearly under-powered (by drag, engine, both or whatever, i don't know)... even if some are able to dogfight against Mig-29: The Mig-21 could too, so this is not really the point. The plot is : Why the hell this is SO HARD, and why the Mirage 2000 seem to be barely more powerful and manoeuvrable than a Su-39... which appear clearly anormal for the Mirage 2000.

Thanks ! Even in clean configuration, the engine seem to be athmatic.

I well understand that... but... i am not sure all is very balanced near 200kts between drag and thrust... because, even at landing, one time, i simply crashed because i losed for one seconds, too much speed, and NO WAY to recover... never seen before too. Ok, Delta wing can act as huge break, OK the M53-P2 is not super-powerfull, but... but...

More time, or infinite time ? I very quickly reached the state where the Mirage 2000 simply fall without ability to regain energy... Never seen that before, especially without payload !...

So, i am a very bad pilot, because the only thing i successfully achieved on my side in three attempts (and verifying my throttle worked correctly) is to lamentablilly crashing on the ground even before the Mig-29 kill me. The Su-27 is to me a far better dogfighter... Case closed.

Juste make a gun's only dogfight against a Mig-29... try it... If for you all is ok, it's ok. Maybe i am a very bad pilot... this is perfectly possible.

Hi ! Yes, a new troll thread about Mirage 2000 performances... I just tested again (after long time not playing), to be clear, i simply tested a guns only dogfight against a mig-29 (100% fuel, no missils)... and, it is obvious that the Mirage 2000 is now clearly a flying brick... it is even less manoeuvrable than a Su-33, it loses its energy incerdibly quickly, even at low Gs, can barley make a simple loop (without payload !) except with a lot of momentum. Well, i don't know if it is realistic, but, after all the people complaining that the Mirage 2000 was over-powered, all people asking for Nav and AG feature, i hope they are now happy that the Mirage 2000 is at last a good bomber ready for navigation and a balanced competitor for the Mig-21 :D Thanks.

As Livers said, the function is under the Mods menu... You also can select all (or a bunch of) mods in the list (like in the explorer, with shift-click, or ctrl-click) and click the "Disable Selected" button... (If any mod selected is allready disabled it will be ignored)

OvGME version 1.7.2 is out. This is a minor update, only some debug and a small new feature: OvGME 1.7.2, 2017-01-06 - Fix mod description display when using arrow keys. - Add "Sort by enabled" option for mods list view. - Add reposition of mods list scroll for long list. Download links on the first page, or here : http://www.ovoid.org/ovgme/downl.htm

No, some features are easy to add or modify. The function checks if a backup data file exists in the OvGME internal folder. First, backup data files are added to list as "enabled mods", then the mod list folder is analyzed, and if any zip or folder did'nt have its "backup data file", it is added as "disabled mod". In fact, technically the list don't show "Enabled Mod", but "Backup Available". This is pretty rustic, but that work fine.

Excuse me i forgot your request. If i well understand, what your are talking about, is like what we have with new incoming emails in a mailbox, who are in bold to signify they are "unread". Your request appear simple, but in fact, this is horribly complex due to 1) how OvGME currently build the mods/backup list and 2) how Microsoft API implemented its (in)famous "listview" GUI element To do what you suggest, i need to introduce a kind of database of the mods list content and change all the process of mod list building, this mean a lot of work, And this is a lot of work for a very little feature, so the Work/Benefit ratio is very bad for me. If one day, i decide to enterly rework how OvGME manage the mod list, i will think about your idea, but for now, i can't say "ho yeah, easy, just some code to add", because i need to rethink all the process.

:thumbup: I suggest using Pandafree (if you don't want to pay) in combo with Addblock or uBlock in browsers... less intrusive, more lightweight, less paranoid... for the rest, just be carefull about what you download and execute.

I think i understand what you mean by "cache", You suggest to pre-extract all Zip in some location even if they are not enabled (installed in the game)... But in this case, you lose the benefit of the zip archive, and you use a lot of disk space. This also requier a totaly new process architecture, where you have to "install" mods in OvGME in order to enable it, then "Uninstall" it if you don't want to keep it in the list. Currently OvGME is pretty flexible and reliable, it is easy to add or remove mods from list, restore backup etc... and yes you are right, the bottleneck is the copy/write I/O transfer, however, after studying the problem, it appear this is the price for optimizing disk space, flexibility, and reliability. Because what you suggested perfectly remind me what currently happen in the banking system, do you know how that ends ? :D Ok, so no, i don't want to "deport" all game data in the OvGME bakcup folder, this is not a good practice.

There is no benefit to create symlinks in this case, since the uncompressed zip data is writen on the disk in all case. Currently, this work this way: 1 - extract zip data in memory 2 - write data in the game folder What you propose is this: 1 - extract zip data in memory 2 - write data in a X location 3 - create symlink of data into the game folder In term of I/O operation, this is exactly the same, except you create symlink in addition, and you horribly complicate the process. Are you a banker or do you work in the international financial mafia ? :D If i do what you suggest, you never empty the OvGME backup folder, then, all the game data is "stolen" from its original folder to be kept in the OvGME backup folder... it is like sucking all game data to transfering them into the OvGME bakcup folder... Sorry, OvGME is not a Rothshild or Rockefeller software :D As i said, the only thing i can reasonably did, is to replace a "copy" command by a "move" command for bakcup data... so people who have backup folder and game folder in the same partition will see a performance gain in I/O process.

What do you mean by "cache", what kind of cache, how and where ? The process is the folowing... Enabling mod: 1 - analysing Zip-mod content & compare to game tree (almost no time) 2 - copy original game files to backup folder (take some time depending file size) 3 - extract zip data (in memory) and overwrite original game files (take some time depending file size) disabling mod: 1 - analysing backup-data (almost no time) 2 - copy from backup to overwrite modded file (take some time depending file size) 3 - cleaning backup folder (almost no time) I can only modify the backup process, by replacing a "copy" command by a "move" command, but i have to take care that this will not create some border effects. And in any manner, if the backup folder is in another partition than the game folder, the "move" command will copy (hard I/O transfer).

Yes, profile feature was reworked, you now can create several profiles, you apply profile by selecting it in the list (menu)

I don't very well understand what you want here. You want mods who just being moved into the mods-stock folder to be tagged as "recently added" ? If yes, this is not a small feature, this requier a kind of database, and some rules to tell when a mod is no longger "recently added"... fuzzy concept in context. Yes, files are copied/replaced "physiqually". What you suggest is not a bad idea, however, you miss some details: 1) OvGME is now optimized for zipped mods, and zipped mods must be extracted (in memory), then files writen in the desired location: this mean "physical I/O write", impossible to "move" or "link" here. 2) You take benefits of "moving" only if source and destination folders are on the same hard drive/partition, if this is not the case, the system performs a physical copy/write even if you ask for a "move" (the system delete from one partition, and write to the other): most people enjoy OvGME because they can splits backups, mods and installations between several partitions... maybe i can replace the "copy" command by a "move" command for backup, but in this case, i have to cleary studdy if there is no risk of "losing" data (i am not sure this is secure, i have to think about it)

The online documentation is the copy of the available one directly through the software in the menu Help :)

Indeed, this is not implemented... i doubt i will implement it, is it realy useful in praticity, in what scenario do you use this feature ?

This is highly not recommanded to edit manually something with OvGME, and you will understand why... The normal procedure is to create a new configuration with the new root folder, then deleting the old one. If you have some backup (mods installed) while you switched drivers letter, then, you have a problem, so: I - Identify and backup your old configuration subfolder 1 - Go to OvGME, select the configuration to modify, and copy-paste the root folder path to any text editor 2 - Close OvGME 3 - Go to this website https://www.md5.fr/ and convert this root path into MD5 Hash 4 - Go in the "ProgramData\OvGME" folder of your main Windows partition, you will see a folder named as the MD5 hash you got in the previous stage. 5 - Move this folder to another location for backup (outside the "ProgramData\OvGME" folder), so you can restore it if something goes wrong. (Do not only rename it with some "-old", this will generate bugs, the subfolder must disapear from "ProgramData\OvGME") II - Create a new configuration structure 1 - Run OvGME and create a new configuration, with the new desired root path and the same folder and backup parameters as the previous one. 2 - Close OvGME 3 - In the "ProgramData\OvGME" you should see a new folder (with a new MD5 hash), this is your new configuration folder 4 - Copy all the content EXCEPT the "game.dat" file from your backup configuration subfolder to the new one. III - End You now ca reopen OvGME, you should see your configuration with the new root folder... and theorically, this is done, you can now use the configuration to restore backups etc...

Maybe there are some 2000-D or 2000-5 hud, but for what i was seeking for, i doubt the difference with 2000-C was significant. Maybe you can tell me what element is not at the right place for a 2000-C Hud ? If you look close, you will see that almost all elements are placed in the same configuration than the original Razbam HUD elements, but all is realigned and adjusted according proportions. What realy changed is mainly the DLZ (completely reworked), the heading tape, and the interception circle. Also the Navigation indication was placed according sources, and logically (in the Razbam version, this elements move from normal to APP mode)... other things are little texture tweaks and size/placement of elements. I cannot add elements that Razbam did not implemented in its module (such as "Radar Slaving")... we can only modify on the cosmetic part (Lua and textures).

funny, i thought about this kind of feature for myself. This is not as easy as it appear, mainly because how Windows API manage this: https://msdn.microsoft.com/en-us/library/windows/desktop/bb760017(v=vs.85).aspx so to say, a gas factory (Microsoft fashion, but worse than usual). but i will think about this.

Version 1.7.1 available http://www.ovoid.org/ovgme/downl.htm OvGME 1.7.1, 2017-20-02 - Added support for multiple mods profile per config. - Fixed version column width for large version numbers. - Improving logs reports. - New debug logs access via GUI. - Help update