sedenion

Hotfix 1.0.7 ... sorry for people who already downloaded the 1.0.6. I made a mistake that may produce wrong package restoration during upgrade/downgrade of package that is overlapped. Better use the 1.0.7 to avoid any problem. See link in previous post.

New 1.0.6 1.07 release that changes the default behavior for package download and upgrade, the behavior should now better fit use of the most users. Changes Packages download and upgrade default behavior: "Upgrade" Button is removed as package upgrading is now part of the default behavior. New "Download without supersede" command menu for former download default behavior. By default, the downloaded package version now replace the previously installed one, either the version is greater or not. New icons for the remote package list: "Star" Icon indicate remote package does not exists at all in local Library, download will add the package in the library. "Up Arrow" Icon indicate remote package is of greater version than the one in local Library, download will do an upgrade. "Down Arrow" Icon indicate remote package is of older version than the one in local Library, download will do a downgrade. When supersede a currently installed package, it is automatically uninstalled and the downloaded version is installed instead. https://github.com/sedenion/OpenModMan/releases/tag/1.0.7

Anyway... I decided to publish a new hotfix release with the latest correction: https://github.com/sedenion/OpenModMan/releases/tag/1.0.4

The source folder is alread saved, either you ask for folder to be expanded, or dialog to be scrolled down right to the current selected folder. First can be fixed easly, be second is a bug from the API itself I did'nt managed to workaround, you'll have to scroll down each time, sorry. This is easy to fix, yes. As workaround for now, you can save time and manipulation by saving packages in the same folder as where source folders are stored, typically, the mod Library folder. This way you'll don't have to change the destination folder each time.

Done This will be available in next release, but I will not create a release only for that so, if you have other suggestions like that, do not hesitate.

Notice that, actually, the Software Context is only an abstract container located in a folder. One single "Software Context" can relate to multiple games or program using several Target Location, and his "home" being located anywhere you want, can be saved, copied, duplicated and combined with other Software Context simply by transfering configuration files and folders... I even have the case of an user that use Software Context using shared locations over local network (to mention the variety of usage)... I never though of this possibility while coding. While I perfectly know the "Software Context" is only a container, is very flexible, can be used for what you want, I have even difficult to explain what it is... It is indeed possible to create a second contextual menu, and pretty simply I think... I simply never thought of that, and if nobody tell me "hey, this would be cool to have a contextual menu for the installation batches list"... Notice that most users have many more complexe and intensive usage than me, so, many things are simply "ok like that" for me. I do not use "tool"... the whole UI is hand-coded in C/C++ using plain old C WinAPI library... Advandage : This is highly compatible, very efficient, optimized and lightweight. The drawback is that I am limited to plain old Windows "controls" and this is very low-level programming, so it is long and boring to create a simple parameters dialog, I have to dig the MSDN yo find the proper C structure definition and interaction messages for each kind of control (lists, buttons, progress bar, etc)...

I don't use this as argument, I simply explain the why. I agree with you that it is confusing at first glance and I had hard time to name things that are very abstractive. I well know Apple strategy, they make software that do few things and don't let choice to user, in order to be simple for common users. OvGME was like that in some way (and many users told me: "I want to be able to do that, and that, and also that..."), Open Mod Manager opens potentialities, give more freedom and become confusing (and now, users tells me "why so complicated ?"). But I admit that the current design is not optimal, I know this is not optimal from the begining, since I myself had hard time to names things and organize menus and parameters dialogs... I completely agree, I still open to suggestion, especially to properly name things... but it is now too late to completely re-design the software. But I can change names and modify menues. I care of, because I know the problem. I know the Linux world, where many software lake of proper UI/UX. As I said, for Open Mod Man, I had hard time to combine "freedom" and "easy to understand/learn"...

I understand and I am sorry for that. I think the problem is not the UI itself, but the general architecture (Software Context, Target Location, etc.) which is overly complex for most usages. Long story short, while developping OvGME I took users comments and suggestion and everybody have their own usage with very various configurations, so I wanted to create something very modular and flexible so the software can fit very various usages. The counterpart is that the software now is more or less like a lego box you have to built yourself.

Interesting... reading code in the hid.tmh file (one of the stock Target header file), there is a function declaration that take hardware VID as parameters, function used to initialize the script... here some code samples. This may be a way to add some non-TM hardware. Unfortunately I cannot test myself since I have only TM hardware. in hid.tmh : //Selects a USB device, installs the filter driver, disables the associated HID device //and assigns the device to joy# following the call order (1st call assigns joy1, 2nd call joy2, etc.) //usbHwid - hardware ID of the device (HWID_* arrays can be used) //device mode: // 0-disable physical device // 1-keep physical device, gather input from device // 2-keep physical device, process device input (not fully supported, uses EV_HID_INPUT_DATA_FULL) //returns: >=0 on success representing the device's index, <0 on error int SelectUsbDevice(alias usbHwid, byte deviceMode=0){} In target.tmh (6) alias Throttle = "VID_044F&PID_0404", Joystick = "VID_044F&PID_0402", LMFD = "VID_044F&PID_b351"; alias RMFD = "VID_044F&PID_b352", HCougar = "VID_044F&PID_0400", T16000 = "VID_044F&PID_B10A"; In target.tmh (171) int Select(alias id) { int i = id[0]; id[0] = 'V'; if(i == MODE_EXCLUDED) return -1; else if(i == MODE_KEEPENABLED) return SelectUsbDevice(&id, 1); else if(i == MODE_FILTERED) return SelectUsbDevice(&id, 2); return SelectUsbDevice(&id); // 0 } In target.tmh (186) int Init(alias h, int cfg=CREATE_JOYSTICK+CREATE_KEYBOARD+CREATE_MOUSE) { &Throttle = GetIndexJoy(Select(&Throttle)); // expect a Warthog Throttle to be plugged on USB &Joystick = GetIndexJoy(Select(&Joystick)); // expect a Warthog Stick to be plugged on USB

Nop, TARGET Script work with TM drivers, and TM drivers only recognize TM hardware. You should edit the MapThrottle.thm file within the mapping folder to write your own mapping. The script already embeds advanced AP/LAST switch functioning, but you can wrote your own.

Errors should not be blocking. You can disable the stick within the main script entry (Run_Complete.tmc and Run_Simplified.tmc) by setting the following macro to 0: define USE_JOYSTICK 0 //< HOTAS Warthog A10/F16 Grip define USE_JOYSTICKF18 0 //< HOTAS Warthog F18 Grip

After some other testing, I notice two things whichn in conjunction make the Mirage F1 currently very hard to control: The Well known pitch sensitivity problem, which makes the aircraft to reach the max AOA very quickly with huge "elasticity" (the nose go back down once we release the stick). The pitch is so sensitive that we currently can properly fly with only the half of the joystick Y axis amplitude, we still reach max AOA. The roll in the other hand, seem to have huge latency and inertia, making the aircraft long to make it roll and still rolls pretty long time after joystick returned to center. The result is that we have sensation to fly a nervous jumbo jet. This is hardest module to control I have tested ever, even the Mig-29 still more controllable. I really doubt the real Mirage F1 is as hard to control as in the module.

Unfortunately, Open Mod Manager doesn't implement such feature at this time. However you can easily manualy "update" package by downloading file using web browser: When you select a package in the list, you'll find a Package Details tab in the bottom frame, scroll down a bit and you'll find a download section with the URL to download file. Simply click on the link to download via your default web browser. You should put the downloaded file in the "Library" folder of the corresponding "Target Location". You are free to keep or remove the old package version from your Library folder.

Open Mod Manager allow you to target both Locations within the same Software Contexts, or to create multiple Software Contexts... in fact, everything is very modulable and customisable, that's probably why you have some troubles. Don't fear to create some dummy Software Context to test and understands how things works. Notice that, the Software Context main folder can be created anywhere you want and even moved later... it is only a "container" to store configurations, mods, backups etc. -> First create a Software Context, names it "DCS Word" with a Target Location pointing to DCS main installation folder. -> Once created, select the "DCS Word" Software Context you just created, then you can add a new Target Location pointing to DCS saved games folder. -> You now can store installable mods in the Library folder of each corresponding Target Location (Main install folder, or Saved game). Your Software Context folder should appear like this: 🗀 DCS World Mods 🗀 Target Main Folder 🗀 Library <- Here you store installable mods 🗀 Backup <- Backup data stored here 🗀 Target Saved Games 🗀 Library <- Here you store installable mods 🗀 Backup <- Backup data stored here

Do you have created a Software Context ? Please look at this tutorial and tells which step is confusing for you :

Actually the quot does not mention any "minimum", it only says that the turn radius is "more than satisfying" at 290kt... which clearly relate to a subjective evaluation compared to pilot's experience.

No FWB doesn't mean absence of flight assistance, and the Mirage F1 does have a lot of them, it is not a warbird...

I second the OP, I find the Mirage F1 currently very hard to pilot, a little sharp maneuver turns the aircraft crazy, especially the conjunction of pitch up and roll is almost prohibited and totaly useless since uncontrolable. I still have the sensation to pilot the aircraft using raw input and without any damping mechanism...

I would say this kind of lose of control is even too much easy to produce in the DCS Module... You practically can't apply both pitch up and bank without generating aircraft destabilisation and spin departure...

This should work fine, anyway, the script allow you to disable (exclude) any device, see the main *.tmc file for instructions.

@Trigati had the good approach, however its example is a bit confusing. To acheive what you want, and if you use the mapping I created, you have to modify the mapping commands within the MapThrottle.tmh (in the mapping folder) at lines 53 to 56: // Disable original mapping function by make them comments // MapKey( &Dev, BSF, DX34); // MapKey( &Dev, BSB, DX35); // MapKey( &Dev, BSM, DX36); // Add new mapping functions MapKey( &Dev, BSF, PULSE+DX34); //< Press MapKeyR( &Dev, BSF, PULSE+DX34); //< Release MapKey( &Dev, BSB, PULSE+DX35); //< Press MapKeyR( &Dev, BSB, PULSE+DX35); //< Release

Ok. Long story short, in some case (for exemple when you shutdown computer while the application is minimized in task bar), when the application exit and query the system for its own position, the returned values are inconsistant and buggy. To prevent to save such inconsistant values, I implemented a very (VERY...) rudimentary safety system that check a valid range of value and replace any value outside this range by the "safe" 0 value. The valid range is 0-2000, so if you placed the window at a X or Y coordinate greater than this value, the invalid X or Y (or both) value will indeed be saved as 0. So, for your specific desktop configuration, "0" is not nessecarly a "safe" value anymore and ineed when you place the window on your bottom screen, the X value is probably saved as 0 while the Y one is properly saved. I should definitely elaborate a more complex and smarter safety mechanism... This is the height of the bottom frame (package image and description) of the application window. EDIT: I managed to correct the problem by simplifying things since Windows already have some automatic placement mechanisms. In case of inconsistant values, I let Windows choose itself where to spawn the windows. You can download fixed version here : https://github.com/sedenion/OpenModMan/releases/tag/1.0.3

OMM is designed to add new or replace existing files, not to delete existing file.

I guess you mean the neutral position dead zone. Yes you can, I already did it in a development stage on my side. You have to modify the MapThrottle.tmh file at line 160 and 161, replace the original lines by the following ones: // -- Digital Axes Mapping --------------------------------------------------- if(DIGITAL_SCY) { KeyAxis(&Dev, SCY, '', AXMAP2(LIST(0, 1, 99, 100), DX90, 0, DX92)); } if(DIGITAL_SCX) { KeyAxis(&Dev, SCX, '', AXMAP2(LIST(0, 1, 99, 100), DX93, 0, DX91)); } Notice that the first parameter of AXMAP2() function turned from '3' to a another macro function call LIST. This list enumerates the "stop" positions of each triggering section of the digital axis. In the above setup positions, expressed in percent, axis is divided in 3 zones delimited by 4 stops : 0, 1, 99 and 100, which is schematically like this: 0 1 99 100 |--|---------------------------------------------------------------------------|--| DX 0 DX

You see, finally Target Script Editor is not "way over" your head...