sedenion

* Support for generic "description.txt" and "readme.txt" in zip : done... * Right-click pop-up menu for "open folder or archive" : done... * Option for custom backup folder : wip... New version will probably be available tomorrow...

Ok, your problem is that the .txt file is in your mod folder, the .txt file must be at the root of the zip file, in parallel of the mod folder, like this: Controls ~~ Warthog_Custom_Controls.txt Controls ~~ Warthog_Custom_Controls - Mods - aircraft - ... ( think about that: if you put the description txt in your mod folder, the description txt is considered as mod file, so is copied to the game file tree, this is not the destiny of a description text :D ) I will considere a generic "description.txt" yes...this is not hell to code :)

OvGME is coded for full wide-char (unicode) support, and has no other name restriction than the system's (windows) name restriction... however, the zip library don't support wide-char, (so i have to convert each path name to 8bit ascii)... maybe the bug is here... (also .txt files are 8bit encoded) Can you give me your archive to take a look at the problem ? PS: the part of code you copied is the one for mod-directory type description (yes, folder mod can also have description, if you let a properly named text file in the mods stock dir), the zipped mod code use another function.

Nop... just watched... it is a totaly network based mod manager, with an online platform, right ?... This is on my "Maybe TODO list"... i had the same thought than you, i have the same usage of the C: disk... but i was waiting for somebody to ask me for that feature :D I will considere it, since hopefully i prepared the groud with by-game custom backup path...

Maybe, but i never really touched any network code in my life, so i have to learn before... maybe it's in fact simple, but i don't know...

The exact same name as the mod sub-folder name with .txt, and zip archive name, see just more up here : http://forums.eagle.ru/showpost.php?p=2867769&postcount=5 ;)

Argh... network code is totaly other... paire de manches... The backup simply copy original files in the application home directory, in a game dedicated sub-folder. The backup data is unique by game (one game, one backup data tree) so to say: all mods shares the same backed files for the same game (this prevent some backup corruption when mods have files that overlaps). if you want more details ask me. The backed game files are stored in a "root" named sub-folder in the game sub-folders within the OvGME application home directory indicated by your system. Usually "<User>\AppData\Roaming\OvGME\<game sub-folder>\backups\root" My first apporach was to zip all backup data to reduce weight, but 1 - zip compression / decompression take time a lot of time (zip don't like 20Mbs DDS textures files... ). 2 - backup archive can become quickly very large (with textures). 3 - there is no efficient way to remove a file from a zip archive except by re-creating the entire archive (read the full archive, modify, then WRITE the full archive again). 1 + 2 + 3 = the backup process becomes quickly horribly slow... So i decided to keep a simple file to file copy, this take more space, but it is incomparably faster.

I think it's because your zip is not recognized as valid mod. Zip archive structure must follow some rules to be identified as a valid mod, this to keep a working standard: ( i copy past the help ) Mod archive (Zip) So to say, the mod archive is only a zipped version of a directory mod. However, to be recognized as a valid mod archive by OvGME, it must follow some simple rules - The archive must be compressed in ZIP format OvGME does not support rar, 7z, gz or any other compression format. - The archive must contain the properly named mod directory at its root. The zipped archive root must contain the mod root directory (and not directly the mod files). Also this mod directory must have the same name as the archive itself but without the .zip extension. For example, if you have a mod archive named "My Super Mod.zip", it must contain the folder named "My Super Mod" where mod files are stored, like in the uncompressed version. - The archive can contain a description text OvGME automatically checks if a .txt file is in the archive root. If this .txt file has the same exact name as the mod directory, OvGME will take it as the mod description. For example, if you have a mod archive with mod directory named "My Super Mod", the description file must be named "My Super Mod.txt". For example, if the game file tree is the following: ....Textures ........Landscape ............picture1.dds ............picture2.dds ........Vehicles ............picture1.dds ............picture2.dds And if your mod consist of changing some .dds texture files in "MyGame\Textures\Vehicles" your mod archive should be structured as follow: MyGame { ....MyTextureModV1.0.txt ....MyTextureModV1.0 ............Textures ................Vehicles ....................picture1.dds ....................picture2.dds } MyTextureModV1.0.zip

OvGME is no longer supported nor updated, I encourae you to move to my newer Mod Manager software: Old post: OvGME is a Mod manager based on the idea and concept of JSGME, it take the GME acronym from JSGME which stands for Generic Mod Enabler. The main purpose of OvGME is to provide an easy way to import and enable mods for games then restore original files when disabling mods. OvGME works by comparing the destination folder file tree with the given mod file tree, then identifies what files to replace, create and save as backup. OvGME implements the following key features: Support for multiple destination folder (game, software, etc.) through the main GUI. Custom mods and backup folder for each configuration. Destination folder file tree snapshot and comparison based on xxHash. Zipped Mods files (Mod-Archives). Mods description (readme.txt). Mods versioning. Mods enabling profile for each destination folder. Mods network repositories. Mods online updating and downloading. Zip Mod-Archive creation tool. XML repository creation tool. Detailed embeded Help. If you already use JSGME: Please read carefully the "OvGME and JSGME" chapter in the embedded help before doing anything.

With the DX button based profile, almost all configuration is done in DCS command so you have nothing to save, but if the command list change, you have to change some bind...

Ok, i don't know how real radars work and how that should work... i can only tell that it appear simpler to use the "ground occlusion" algorithm to do this (so it should take mountains into account de facto) ... But, real radars actually take reliefs into account in this kind of situation ? Don't they simply use some average "horizon" level to "split" the dectection area (wich should obviously produce some problems near horizon if there is mountains) ?

That would be very odd ED don't implemented a ray casting for ground vs target z-sorting, it's some elementary process. As far as i know, a target behind a mountain cannot be detected, so the z-sorting data exists... behind or front of, you choose what to do with that data, occlusion or ground clutter.

In fact that made my brain less confused. If i well understand in fact the recieved frequency is sampled through PRF cycles (one sample by "listening" phase, causing aliasing problem), and i thought this frequency was sampled directly during one "listening" phase.

I guess it is related to an hardware limitation that cannnot emit at full power instantaneously... or i don't understand why "duty time" could affect power... Here i don't understand what you mean by "doppler frequency" in relation with the PRF... there obviously something i don't understand correctly about Pulse/Listen logic... in my mind the pulse emits a wave with a given frequency (which is not related to PRF), then the radar recieve the echo with a shifted frequency... PRF should not affect this shift detection, except if this detection is not made as i believe.

I don't understand all, but i understood the essential i think... High PRF: - Long range detection (high power, why ?). - Good velocity resolution (best for ground clutter rejection) - Bad range resolution (computed on PRF cycle basis) Low PRF: - Short range detection (limited by power, why ?). - Bad velocity resolution (even non existant, ground clutter rejection almost impossible) - Good range resolution (high precision in return time computing) This is a detail (in our context) but what i don't understand is why Low PRF can't use doppler shift to evaluate velocity ?

In Mods/aircraft/M-2000C/Cockpit/ : clickabledata.lua give you the full list of virtual cockpit buttons and switchs. To have the correct button Id for input default LUA, you have to add 3000 to each original value, for example: device_commands.Button_235, [b]235[/b], 0, 1)235 => 3235 devices.lua give you the device list with id in comments (at right, after -- )

We are speaking about non-toggle commands :) The warthog switchs are two ways without automatic return to center (unlike the X55)... this is why non-toggle commands are precious to map Warthog... To be precise (and to understand exactly what is the problem): Physicaly (without programming) the Warthog switchs are: - Position Up : ButtonX Pressed (keeped ON) - Position Down : ButtonX Released (keeped OFF) (in this case, the "3-Pos. Switch Abstractions" are used) Virtually (if we use programming) this is: - Position Up : Command A (Only Once) - Position Donw : Command B (Only Once) (in this case, the separated X OFF and X ON commands are used) All without return to center, this is Up OR Down... this is why toggle commands are a problem to map with Whartog.

Here is for Master Arm and Gun Arm {down = 3234, up = 3234, cockpit_device_id = 6, value_down = 1, name = _('Master Arm On'), category = _('Weapons Management')}, {down = 3234, up = 3234, cockpit_device_id = 6, value_down = 0, name = _('Master Arm Off'), category = _('Weapons Management')}, {down = 3463, up = 3463, cockpit_device_id = 6, value_down = 1, name = _('Gun Arm To Armed'), category = _('Weapons Management')}, {down = 3463, up = 3463, cockpit_device_id = 6, value_down = 0, name = _('Gun Arm To Safe'), category = _('Weapons Management')}, However, for Master Arm i have tested and, if the switch (the 3D model) is actually activated, the program does not take it as "Master Arm" command, it only moves the switch, so unfortunatly, this is perfectly useless... For Gun Arm, i don't have tested... EDIT: I forget that: To enable the Master Arm switch to moves (which is useless i repeat) you must also edit the clickabledata.lua script.. line 500, as this: elements["PTN_234"] = default_2_position_tumb(_("Master Arm Switch"), devices.PCA_PPA, device_commands.Button_234, 234)

That's it. H = Haut/Haute = High B = Bas/Basse = Low HFR = Haute Fréquence de Répétition BFR = Basse Fréquence de Répétition And ENT = ENTrelacé = Interleaved Wikipedia precisely say : "Low PRF radar have reduced sensitivity in the presence of low-velocity clutter that interfere with aircraft detection near terrain." Technically, i don't know why, but as i understand, low PRF is only good for weather or terrain.

(ENT > Entrelacé > Interleaved... i say it since nobody say it... )

All that is pretty confusing... What i understand is that PRF determine the time between each pulse, so to say, the time dedicated to recieve the echos of the previous pulse... This ca influence target detection in two manner: - Target distance: If target is too far, the echo is recieved after the next pulse was emitted, so the radar is confused. - Target closing speed: If closing speed is too low or negative, the recieved echo wavelenght can be to long for the intervale to determine the proper speed of the echo, or even to be detected...

https://en.wikipedia.org/wiki/Pulse_repetition_frequency#Low_PRF Sumary: Low PRF : Mostly used as weather radar Med PRF : Good for long range detection, but not very precise High PRF : Best precision, but limited to medium/short range.

Hi, I guess people familiar with TARGET Script does not realy need script since they can code their own. however, i share some "modules" i programmed and uses in my own profiles, maybe that can interest some people. Full documentation are in the files as comments, i leave here some descriptions: DX+ Module: Allow to use more than 32 DX button for mapping. (this is a more convenient version than the previous one i posted in this forum) 9 Positions Hat Module: Allow to use a Warthog Hat as a 9 positions hat (4 standard + 4 corners + 1 abstract middle) with IOUMD layer support for mapping. LED Control Module: Allow controlling LED with buttons in paralelle of standard mapping + some shortcut functions. AP Control Module: Allow an advanced handling for Warthog AP buttons and Switch, to mimic a real behavior. Throttle Switch Synchro: This module is hard to describe, it allow to define a trigger button which will force Throttle switches to be pressed again at their current position. So to say, it forces synchronization of switchs with game status. For example, if a switch selects a weapon, the weapon will be forced to be selected (without acting on the switch) when the specified button is pressed. dx+.rar apc.rar sws.rar h9p.rar

The Trim rudder commands are inverted: Left is Right and Right is Left... I also mention than i find trim rudder increment too smooth, it take long time to have effect...

bkthunder if you are intersted programming warthog in full DX button mapping: http://forums.eagle.ru/showthread.php?t=171098 Just found that this afternoon...