sedenion

Yes Joystick Gremlin is a good option. I personnaly use TARGET with extended number of DX buttons, allowing to create advanced mapping (which Joystick Gremlin don't do as far as I know).

The main, and probably the most obvious issue not using TARGET is that switches are not fully assignable (unless very specific command exists in the game/module). For the 3-positions switches, you can assign only two positions (back and forward), and only one position for 2-positions swiches (the ON position). Using TARGET allow to overcome this limitation.

Late answere (I guess you already found solution) I suppose you unproperly copied the line, indeed the first character is "&" and not "a". Anyway, the error probably do not come from this line in the target.tmh, but this is where the error "occured". Somewhere in your mapping function, you probably mapped a key, a macro or invalid value, which in the internal mapping process (which occure within functions of target.tmh) trow an "index out of bound" error, which mean: you (the program) attempted to reach an array index (here, the array is kayalloc[]) that is out of bound. For example, if an array is defined with a size of 128 (128 slots), and you try to access to the index n° 240 (the 240th slot) of this array, the programm will tell you this is impossible, because this array does not have 240 "slots"... This is what "index out of bound" mean. byte MyArray[2]; //< declare an array of 3 char MyArray[0] = 10; //< assign value to index 2 MyArray[1] = 6; //< assign value to index 0 int foo = MyArray[1] + MyArray[0]; // OK, foo is now equal to 16 int bar = MyArray[8]; // Error, MyArray[] have a size of 2, the index n°8 does not exists : Index out of bound.

The "KP+" Macro is not defined in defines.tmh, and anyway it cannot be... That's it, the "+" is an arithmetic operator, parsed as this by the interpreter/compiler. You can define the name "KP+" (the compiler shoud warn you, but it seem devs did not handled this exception), but using the name itself will cause a compile error: define KP+ USB[87] //< compile pass (but should not...) // ... MapKey(&Throttle, LTB, KP+); //< Error, the "+" is parsed as an operator and expect a right operand Notice that, the "+" indeed act as "arithmetic add", the fact that the "+" act as simultaneous activation is due to how the background program itself parse the resulting number via binary masks operations. So the LCTL+'x' expression actualy ADD numbers/numerical values (the 'x' is parsed as byte value corresponding to its ASCII value), wich result in a particular number that is later "parsed" using bit masks. The "-" character is also interpreted as "arithmetic subtract", the "KP-" does not work better than "KP+" once you actually use it. You can "define" it, but using it throw same error as with the "+". This is perfectly valid: define KPPLUS USB[87] // perfectly OK Also notice that USB is what we call an array in programmation, it simply hold numerical value that you access in order by index ( [index] )... The USB[0x57] is exactly the same as USB[87], 0x57 is simply the hexadecimal while 87 is the decimal value. Finally, the index N° 87 of the USB[] array hold the numerical value 1087, so you can shortcut all by writing this: define KPPLUS 1087 // same as USB[0x57] or USB[87] To "play" with this, you can use the "printf" function with your "main()" function tu see what variables and macro really stand for (as numerical values): printf("The value of KPPLUS actualy is : %i", KPPUS);

Notice unless specific case, in such configuration on a push button (which automatically release) you don't need PULSE... The logical button (or key stroke) will simply release once you physically release the button. The PULSE can be interesting for switches (which stay their position indefinitely, letting the key stroke or logical button in pressed state) or for more complexe mapping such as short/long combo (TEMPO), sequences (SEQ), etc...

I think you should describe more precisely what button's behavior you need. I personally don't know how the F-18's "cage / uncage" button is attended to behave and how that work in game, so I can't help you...

I'am not sure what you mean, but I am pretty sure the anwere is no. To do such thing the software would need to communicate with the server using a protocol that support file listing (at least FTP, or some advanced HTTP)... this would become a second software by itself. What I recommands to you is to keep a local mirror of your distant repository (both packages and xml file), as what one did for all website, then you can simply localy edit your local repository, using the "add folder" feature to create an XML file, and uploading all what you need.

You can edit a existing repository XML file, adding (or deleting) referenced packages, editing packages individual data... then reupload the new XML file to your server.

Hello all, I created a new "all in one" profile, please see the first page of this topic.

New version 2.9 Mod released. This version is for both last Stable and Open-Beta release (2.7.5.10869). - Correct PCA aligment (mod files removed) - Echo changes of the 2.7.5.10869 release. Download links here: https://forums.eagle.ru/showthread.php?t=255177

New version 2.9 Mod released. This version is for both last Stable and Open-Beta release (2.7.5.10869). - Correct PCA aligment (mod files removed) - Echo changes of the 2.7.5.10869 release. All links are, as usual, located in the first page of this topic.

I juste verified, and indeed the PCA indications are slightly shifting to the right along the row, but it's very slight. Did you see a very bad and large missalignment ? Can you post a screenshot ?

Dear OvGME users, I encourage you to move to my newer mod manager software:

New version 2.8 Mod released. This version is for the last Open-Beta release (2.7.4.9632). - Echo changes of the 2.7.4.9632 release. Download links here: https://forums.eagle.ru/showthread.php?t=255177

New version 2.8 Mod released. This version is for the last Open-Beta release (2.7.4.9632). - Echo changes of the 2.7.4.9632 release. All links are, as usual, located in the first page of this topic.

New 0.9.7 Release. https://github.com/sedenion/OpenModMan/releases/tag/0.9.7 This release does not implement much new feature, it is more a polished version of the 0.9.6 with the requested adjustments. Developer mode back as enabled by default. Fix undo install not working with archive files backup. Package created folders no longer generate overlapping. I also updated the first page of this topic with a new presentation text and a better "getting started" chapter.

Hi, You will find some manual here, I am writing it slowly... https://github.com/sedenion/OpenModMan/wiki Unfortunately, this is currently incomplete and very formal. If somebody have time to do some tutorial beginners, I will be very happy to add it to this wiki. If you have questions, subject you want to be reviewed in first, I will try to write it before...

Too late Considering myself the various scenarios, I decided to limit overlapping detection to files only and implemented a stealth mechanism of created folder deletion with the cost of some more verification loops. I had to make some modifications but not that much. That's it, this is why I guessed this was "not an option" for you to create the folder... I have to write the f*** manual... It is on the way, but I have hard time... One of my early project was to allow to create some generic "game setup" mechanism that call a wizard with game specific instuction... Something like what you will do, but with more automatism and dialogs that guide user. This still in my mind, but never take time to implement it right now. Notice that overlapping are not formally an issue. The manager fully allow and handle it in a safe way. This simply throw a warning by default (warning can be disabled) and display an orange cross...

Indeed, I think your mods generate overlapping because they creates folders that does not exists in the destination. Such alert may appear as useless but the problem is not as trivial as we think: A created folder (or file) at installation, should be deleted at uninstallation (in order to cleanup and restore destination initial state), and if several mods create the same folder, they mechanically "overlaps" because each of them have to delete the same folder at uninstallation. And if one is uninstalled, it will delete the path (and all files whithin) created by another and mechanically delete files of the other mod : caca-boudin. This is why "shared created folder" are actually flagged as overlapping, and invokes the uninstall sequence of all overlapping installed mods. This is to properly cleanup without damage the destination folder. At this stage, to prevent this phenomenon you have no other alternative than previously creating the folder within the destination folder, so mods does not have to create it. But I guess this is not an option for you. On my side, I have no easy way to prevent this except by simply ignoring folder overlapping, but in this case, mods may creates new folder within the destination that will never be deleted at uninstallation. precisely to restore overlapping data in the right sequence to restore destination at its initial state. In your case, this mean : deleting folder contents before deleting the parent folder. I will think about a less strict and restrictive overlapping control, allowing "shared folders", but this would obviously require to refactor a part of the install/uninstall process. This is not trivial.

New version 2.7.2 Mod released. This version is for both Stable and Open-Beta release. - Fix CCRP HUD mode not working properly - Fix stroke material color for VTH & VTB vector components Download links here: https://forums.eagle.ru/showthread.php?t=255177

New version 2.7.2 Mod released. This version is for both Stable and Open-Beta release. - Fix CCRP HUD mode not working properly - Fix stroke material color for VTH & VTB vector components All links are, as usual, located in the first page of this topic.

Indeed, I did not pay attention to that (I have not much time for try and test last days)... RAZBAM is progressively replacing textured sprites with new vector rendering, and it appear that shader used to render are very different, so colors and alpha components does not output pixels the same color for same input. I adjusted a bit the colors, this is ok for the HUD, but for the VTB the best result I got still unsatisfying for me... Anyway, I will out a new release with the corrections later today or tomorow.

I don't know much, but I'am pretty sure this is not on my side. I found only one other error and not related to the radar designation diamond. Are you sure this isn't the same in the vanilla version ?

Ok, I found two other bugs, I think now this will fix the problem: Again in the HUD_page_2.lua, at line 239 and 247, change the value CCRP_Sight.name to FOV_center2.name

! ATTENTION ! Nothing really serious, but I made a mistake in the last releases that may induct some confusing situation in the future if I don't correct this right now. I made an error for Package and Backup specific file extensions. The fix is already done and the new Installers are availables BUT, please follow these steps carefully before installing the new build: Uninstall all your packages for all Contexts and Locations Uninstall the previous version of Open Mod Manager Install the Open Mod Manager using the newest available installers (https://github.com/sedenion/OpenModMan/releases/tag/0.9.6) If you created some packages with the specific .omp extension, rename them with the .ozp extension and all will be fine. Sorry for the annoyment.