New GME software

[Gliptal]

Nice, can't wait!

[Automan]

Nice news, thanks for your efforts :thumbup:

[Aviators]

wuao!

[.Tigre.]

Very interesting news, thanks :thumbup:

 

:pilotfly:

[Jack McCoy]

You had this problem on JSGME or OvGME ? Theorically this problem was solved in OvGME long time ago...

 

You nailed it: I'm using JSGME. Thanks.

[fill]

sedenion has given us a very useful tool and it does everything it was supposed to do, and it's free! We should accept what he says: It was never structured for becoming a much bigger and therefore more complex application. And if he tries to add a lot more functionality the bowl of spaghetti may become a Gordian Knot, difficult to maintain and potentially unstable, a source of frustration.

We should not ask him to invest more of his private time into the evolution of OvGME. He has probably some good ideas and we should let him work on those and have fun.

Bien dit, nice answord my friend.

[.Tigre.]

Bien dit, nice answord my friend.

 

I agree with absolutely shareable considerations :thumbup:

[Marsy]

Sounds very good. Looking forward to the new tool!

 

Can you please add the feature to add lines to exisiting files?

This would be a needed feautre for liveries that uses the textures folder.

You need to add a line to the autoexec.cfg file in Saved Games\DCS\Config for each zip file you have in Saved Games\DCS\Textures so DCS imports the textures at the start of the game.

 

Of course I could add a mod that changes only this file - but if you want to install additional skins/liveries from other authors/repositorys/etc that file would not have the correct content.

That's why I suggest to let a mod add a line to a existing file.

 

Keep up the good work!

 

Marsy

[sedenion]

Sounds very good. Looking forward to the new tool!

 

Can you please add the feature to add lines to exisiting files?

This would be a needed feautre for liveries that uses the textures folder.

You need to add a line to the autoexec.cfg file in Saved Games\DCS\Config for each zip file you have in Saved Games\DCS\Textures so DCS imports the textures at the start of the game.

 

Of course I could add a mod that changes only this file - but if you want to install additional skins/liveries from other authors/repositorys/etc that file would not have the correct content.

That's why I suggest to let a mod add a line to a existing file.

 

Keep up the good work!

 

Hahaha ! This appears always so simple when people ask for features :D

 

From now, when somebody ask me for a new feature, we will play a game: Be the software-concept architect, while I stay the programmer.

 

As a programmer, I can tell you: Adding some text at the end of an existing file, this is very easy, i know how to do. But, dear software-concept architect, how do you want your feature to appear in the software ? Where is the "line to add" ? How the Mod Maker should build its mod so that the software know that "this line" must be added "here" ?

 

Be sure I have some ideas, be sure i know what are the problems, but I want you to explore yourself the puzzle. And maybe you would have a good and elegant idea about how to implement as design an "exception feature" for an "exception case".

Edited December 29, 2017 by sedenion

[Home Fries]

Hahaha ! This appears always so simple when people ask for features :D

 

From now, when somebody ask me for a new feature, we will play a game: Be the software-concept architect, while I stay the programmer.

 

As a programmer, I can tell you: Adding some text at the end of an existing file, this is very easy, i know how to do. But, dear software-concept architect, how do you want your feature to appear in the software ? Where is the "line to add" ? How the Mod Maker should build its mod so that the software know that "this line" must be added "here" ?

 

Be sure I have some ideas, be sure i know what are the problems, but I want you to explore yourself the puzzle. And maybe you would have a good and elegant idea about how to implement as design an "exception feature" for an "exception case".

 

You could just have people submit Use-Cases with alternate flows and exceptions. :D

[Marsy]

Hahaha ! This appears always so simple when people ask for features :D

 

From now, when somebody ask me for a new feature, we will play a game: Be the software-concept architect, while I stay the programmer.

 

As a programmer, I can tell you: Adding some text at the end of an existing file, this is very easy, i know how to do. But, dear software-concept architect, how do you want your feature to appear in the software ? Where is the "line to add" ? How the Mod Maker should build its mod so that the software know that "this line" must be added "here" ?

 

Be sure I have some ideas, be sure i know what are the problems, but I want you to explore yourself the puzzle. And maybe you would have a good and elegant idea about how to implement as design an "exception feature" for an "exception case".

 

Place a xml file in the mods zip archive:

Contet:

<?xml version="1.0"?>
<filesToEdit>
 <file name="autoexec.cfg" path="%USERPROFILE%\Saved Games\DCS\config" content="table.insert(options.graphics.VFSTexturePaths, ""%USERPROFILE%/Saved Games/DCS/mytextures"")aaa"/>
</filesToEdit>

The new software now has to check if this file exisits in a mod archive:

If yes, add the line in content to the mentioned file in path+name

If no, do nothing

 

When the mod is enabled this line has to be added.

When the mod is disabled this line has to be removed.

 

I think that is a needed feature for DCS Liveries to be saved as designed by DCS.

Unfortunatley i can't write C++

 

Other possible solution is to include two powershell script in the mod archive that will run once the mod is enabled and disabled.

[sedenion]

Place a xml file in the mods zip archive:

Contet:

<?xml version="1.0"?>
<filesToEdit>
 <file name="autoexec.cfg" path="%USERPROFILE%\Saved Games\DCS\config" content="table.insert(options.graphics.VFSTexturePaths, ""%USERPROFILE%/Saved Games/DCS/mytextures"")aaa"/>
</filesToEdit>

The new software now has to check if this file exisits in a mod archive:

 

Yes, this is the most obvious way to do : Adding another file in the mod, that the software will check and parse...

 

But in your example, the mod maker manually defines the destination path where to modify the file, which is a problem because this break the software general paradigm, where destination path is defined by the user into its personal game/mod configuration. And why this paradigm is important ? :

 

If I allow mod-makers to modify an arbitrary file with an arbitrary destination path, which is not the the destination path defined by user, then, I allow the mod-maker to traficate anything in the user's computer, this could becomes an huge security issue.

 

So, I cannot validate this solution... However, ba happy, I know an alternative:

 

- The mod-maker places the file to be "modified" in its mod, like any other mod file, but the file contain ONLY the "line" or "content" to be concatenated to the existing file, and the mod maker add an extra XML file with something like this inside:

 

<exceptions>
 <[b]concat[/b] src="\config\autoexec.cfg"/>
</exceptions>

 

So the software is informed that this specific file, in the mod files tree, is to be "concatenated" to the already existing file instead of "overwrite". Notice that the path is completely relative, and depend on the target destination folder the user choosed for this mod... this way the user cannot be fooled by a malicious mod-maker, and this is even simpler to write for the mod-maker.

 

HOWEVER:

 

The problem remain, that is that this remain an pure exception usage, which needs another file to be checked and parsed, but more important : a full new conditional branching in the installation, backup and restoration algorithms, for only ONE exception usage:

 

When the mod is enabled this line has to be added.

When the mod is disabled this line has to be removed.

 

That is obvious, but this is not as simple as that. In fact, this exception feature would impacts ALL the installation, backup and restoration algorithm, because we would need to check for each mod files if the file is to be "copied" or "concatenated" at installation (depending the exception list), storing the appropriate backup info, then at the restoration, same mechanism again.

 

I think that is a needed feature for DCS Liveries to be saved as designed by DCS.

Unfortunatley i can't write C++

 

You said it, this is a "needed feature for DCS Liveries", but nothing else...

 

Other possible solution is to include two powershell script in the mod archive that will run once the mod is enabled and disabled.

 

Haha ! And maybe you also want to allow mod-makers to automatically execute a virus while enabling a Mod ? :D Sure this is possible... But I Am sorry, I know this kind of "huge security hole" is a common behavior in the Microsoft world (see also: ActiveX*), but I came from a world where this kind of thing is simply forbiden by principle.

 

 

* ActiveX was controversial from the start; while Microsoft claimed programming ease and good performance compared to Java applets in its marketing materials, critics of ActiveX were quick to point out security issues and lack of portability, making it impractical for use outside protected intranets. The ActiveX security model relied almost entirely on identifying trusted component developers using a code signing technology called Authenticode. Developers had to register with Verisign (US$20 per year for individuals, $400 for corporations) and sign a contract, promising not to develop malware. Identified code would then run inside the web browser with full permissions, meaning that any bug in the code was a potential security issue; this contrasts with the sandboxing already used in Java at the time.

 

https://en.wikipedia.org/wiki/ActiveX

 

 

Do you want me I request $20 to each mod-makers to give them an "authentic signature" with their promise that they don't did malware with mods ? Interesting business model... :D

 

Ok, lets be serious again:

 

I can implement such "exception" feature, with an extra XML where some exceptional behaviors are described by the mod-maker. But, since this would needs an installation / backup / restore algorithm refactoring, I Need that this feature to have a more general purpose, something that can be usefull for other things that only "edit the autoexec.cfg" of the "DCS specific" liveries management... I need a good reason, something that tell me "Ho yeah, this feature will make this software greater for many many people, and not only DCS's liveries mod-makers", can you understand this ?

 

So, I ask to others users and mod makers... how this "feature" can be enhanced, to become more general, and provide a real good deal for mod makers and users, not only for DCS's autoexec.cfg file ? That is the only thing I ask : A real GOOD reason to implement this...

[Marsy]

Sure,

i know thats possible a lot a work to change all the affeceted parts of the code.

And yes, Powershell and my other proposed option have securtiy isssues, that's right.

 

Another problem is that the content of the added line in autoexec.cfg needs to be dynamic. the path of the users saved game folder is diffrent for each user :(

 

But to find additonal use cases for the GME:

Add Keybinds like in Quake, Counterstrike etc.

[sedenion]

For the new year, a bunch of "Work In Progress" screenshots with some configuration and settings dialog to help you understands the new Module / Context software paradigm...

 

Remarks, comments and questions are welcomed, especially if you see something that appear to your as a "wrong idea"... Since things still in development, this is NOW or, maybe never...

 

 

 

[sedenion]

Sure,

i know thats possible a lot a work to change all the affeceted parts of the code.

And yes, Powershell and my other proposed option have securtiy isssues, that's right.

 

Another problem is that the content of the added line in autoexec.cfg needs to be dynamic. the path of the users saved game folder is diffrent for each user :(

 

Outch ! Indeed, here, even if it is possible, this become a very specifical behavior which imply even more dirty things... If Windows embeded something like Linux's Bash, with a security environment comparable to linux (which disallows scripts to traficate things everywhere), I probably would have included a way to automatically execute a custom shell script at mod install... But the Windows environement and average Windows user behaviors tell me "Ho no, man, don't do this, this would be a time bomb !".

 

But to find additonal use cases for the GME:

Add Keybinds like in Quake, Counterstrike etc.

 

Ok, good argument. I keep that in mind and I will think about that.

[Automan]

Good progress.

Just in case, the path for saved games folder can be retrieved from the registry in the key

{4C5C32FF-BB9D-43B0-B5B4-2D72E54EAAA4}

 

under these locations:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\

 

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\

[sedenion]

Good progress.

Just in case, the path for saved games folder can be retrieved from the registry in the key

{4C5C32FF-BB9D-43B0-B5B4-2D72E54EAAA4}

 

I already said I will never implement such automatic path retrieval. The application will not be called "DCS Mod Manager", it is intended to be generic and "universal". If I implement such special DCS feature, I would have to implement it for all other potential games...

[fill]

I already said I will never implement such automatic path retrieval. The application will not be called "DCS Mod Manager", it is intended to be generic and "universal". If I implement such special DCS feature, I would have to implement it for all other potential games...

Ah zut, faudra faire un soft spécial DCS et un autre pour le reste.:thumbup:

Sorry:

you will have to make a soft for DCS and another for all other games!:music_whistling:

No, I am joking .:megalol:

Au plaisir Sed.

[Automan]

I already said I will never implement such automatic path retrieval. The application will not be called "DCS Mod Manager", it is intended to be generic and "universal". If I implement such special DCS feature, I would have to implement it for all other potential games...

 

Saved games folder is used by a lot of games, not only DCS...;)

[sedenion]

Saved games folder is used by a lot of games, not only DCS...;)

 

Saved Game folder is used by many games but the registry keys to found parameters are different for each games, so what do you conclude ?

[Automan]

The key {4C5C32FF-BB9D-43B0-B5B4-2D72E54EAAA4} retrieve the Windows' s Saved Games folder path: this is not a key stored by the installation of DCS, it's choosen by OS.

 

The name of the DCS folder under Saved Games, instead, is inherited by DCS installation type:

DCS-->release version

DCS.openbeta-->openbeta version

DCS.openalpha-->openalpha version

Happy new year;)

[sedenion]

The key {4C5C32FF-BB9D-43B0-B5B4-2D72E54EAAA4} retrieve the Windows' s Saved Games folder path: this is not a key stored by the installation of DCS, it's choosen by OS.

 

Happy to know, but, what the point ? We don't need to dig manually into the registry to retrieve this kind of path, specific functions exists in the API for that...

 

The name of the DCS folder under Saved Games, instead, is inherited by DCS installation type:

DCS-->release version

DCS.openbeta-->openbeta version

DCS.openalpha-->openalpha version

Happy new year;)

 

So, this is specific to DCS, and so, this need to be hard-coded in the program specifically for DCS... so, I don't understand what you suggest...

 

Happy new year

[Automan]

Well, an old C++ book is still in my library to take dirt...so I'm not here to help in program this things, but only to suggest a direction to take *IF* you want make a more DCS oriented app instead of a generic one.

Actually the DCS 2.2-2.5 will require some mod to be installed only in DCS folder under saved games, while some lua code is still needed in the main DCS folder.

 

So, what I suggest is to stores the 2 Folders, the DCS main folder choosen manually by the user, the DCS under saved games retrieved automatically by the APP.

 

1. Retrieve the path from the registry for Saved Games

2. Read the file dcs_variant.txt in the DCS main folder, that stores the installation type.

3. Path retrieved.installation type

[sedenion]

Well, an old C++ book is still in my library to take dirt...so I'm not here to help in program this things, but only to suggest a direction to take *IF* you want make a more DCS oriented app instead of a generic one.

Actually the DCS 2.2-2.5 will require some mod to be installed only in DCS folder under saved games, while some lua code is still needed in the main DCS folder.

 

So, what I suggest is to stores the 2 Folders, the DCS main folder choosen manually by the user, the DCS under saved games retrieved automatically by the APP.

 

1. Retrieve the path from the registry for Saved Games

2. Read the file dcs_variant.txt in the DCS main folder, that stores the installation type.

3. Path retrieved.installation type

 

First, as stated before, if I make a specific DCS handling, I have to make a specifical handling for severl games, or the software should be called "DCS mod Manager", maybe you will understand why with this explanation:

 

We assume the idea: suppose you have both folders, including the one retrieved automatically. then, how mod-maker did their Mods ? how to automatically dispatch "this file" here or there ? The answere is that in this case, the mod must be architectured in totaly different way than the current one, and maybe carring an extra config file which describes each source and destination, all according DCS specific environment variables...

 

I am sorry Eagle Dynamics tend to scatter all files in several folder with config files to edit... but, yes, if you want something that fitt with your ideal, the software have to be specifically designed FOR DCS, and the mods have to be specifically designed FOR this software...

 

OR... may be, tell me something like:

Ok, from now, we totally break with the JSGME legacy logic, here is a new software, more powerful, but more complex, mods are full of scripts, we include environment variable logics, mod makers have to create their mods according precises rules, old mods will no longer work until you completely rebuild them.

 

We can surely inspire from the concept of Linux Deb or RPM packages, but in this case, the mod-makers have to know that tmaking a mod will be an totaly other advanture, complexe, taking more time and attention, no longer automated, because nothing is magical...

Edited January 1, 2018 by sedenion

[Automan]

...omissis...

 

OR... may be, tell me something like:

Ok, from now, we totally break with the JSGME legacy logic, here is a new software, more powerful, but more complex, mods are full of scripts, we include environment variable logics, mod makers have to create their mods according precises rules, old mods will no longer work until you completely rebuild them.

 

We can surely inspire from the concept of Linux Deb or RPM packages, but in this case, the mod-makers have to know that tmaking a mod will be an totaly other advanture, complexe, taking more time and attention, no longer automated, because nothing is magical...

 

Yes, exactly this: since from DCS 2.2 the logic has changed, it's right to redoing all the previous mod.

ED have choose the new way of modding DCS, breaking with the past, we should do the same with a new modding tool.

I know it's time consuming, but, if possible, you should dedicate a fork of your project to DCS(DCSGME?:D)