DarkEDIF - Taking suggestions

[Phi]

So instead of a parameter, you run a program? Okay, but how would the program communicate the results with the extension?

[Atom]

It wouldn't directly, if you wanted the program communicate the results with the extension you could for example make it generate a string which you would then copy and paste in for a input in the event editor etc.

Edit - The programs programs could do anything you wanted though so they could for example read and modify local files from MMF2 folders like langauge INI's or text presets etc, it would just be a nicer and much quicker way of running helper programs that do certain tasks.

[LB]

Atom you realize that's all possible with any SDK...right?

[Atom]

I guessed you could somehow, i don't know how to though. If it's easy i would appreciate it if you could add some quick examples with DarkEDIF. I mainly wanted to use them with the JSON setup you were adding though like i suggested in post #14 which would be great if it's possible.

[Phi]

I am not sure how you will be doing the GUI controls in the JSON code but with a quick guess for the button to run a exe you could maybe have something like this -

"Editor Properties":
[
[0, "Value Input" , "Name:Test 001", "Min:0", "Max:100", "Default:0"] // Some other control
[1, "Value Input" , "Name:Test 001", "Min:0", "Max:100", "Default:0"] // Some other control
[2, "Button" , "Name:Run Map Editor", "OnClick: Load("Data\Runtime\ExtName\MapEditor.exe");"] // The button that loads the EXE you want
]D

It's actually all like:

{
"UK English":
{
// Actions and stuff...
"Properties":
{
[
"Name": "I'm a checkbox name!",
"Info": "This is the stuff that appears on the bottom when you select me!",
"Bold": true,
"Checked": false // Ooh, comments.
]
}
},
"French":
{
// Actions et des trucs
"Properties":
{
[
"Name": "Je suis un nom case!",
"Info": "C'est ce qui apparaît sur ​​le fond quand tu me choisir!",
"Bold": true,
"Checked": false // Ooh, commentaires.
]
}
}
}

[Jaffob]

Here are some initial requests I've thought of.

1. A simple one to start off: Remove the need to type the open parenthesis in expression titles. Every expression name (like "String$(") requires an open parenthesis, so typing this in the name of every expression is unnecessary. I would do this myself, but I don't want to cause incompatibilities when I upload all of my extensions to your repository.

2. I just started using Edif and it's a bit cumbersome to edit values in five different places to make a single A/C/E work. Maybe you could try combining some of the different tasks needed into a single place. For example, instead of having titles and parameter names for A/C/E's outlined in the JSON, perhaps have them be defined along with the class functions themselves (in A/C/E.cpp). This could be done by requiring the developer to call a function that interprets a JSON string of the same format as the current Edif.

3. Make custom parameters easier to implement. Creating custom parameter types still requires that the old MMF2SDK format be used. A more friendly way of defining your own parameter types would be great.

[Phi]

1. I prefer it with the '(', so I'll make it optional
2. Cannae do that, mon. The menu and finer details of a/c/e's are deliberately separated so the menu design is clear. Any class members inside Extension.h require declaration and definition, separately for clarity. The only possible improvement would be automatically linking in Extension::Extension(), which would be a very bad idea, as it would make the extension unstable if any conditions are missing or defined out of order in Extension.h.
3. I presume a custom parameter is a custom dialog in the resources? That would be easy to implement.

[Jaffob]

1. Sounds good.

2. Alright, I'll probably get used to it soon enough anyway.

3. That's one way to do it, but really it can be anything. For example, I've been using a custom parameter to call the MessageBox() function and display information about an action to the user. If you want, I can refresh myself on how custom params work and provide more details.

[LB]

3. Make custom parameters easier to implement. Creating custom parameter types still requires that the old MMF2SDK format be used. A more friendly way of defining your own parameter types would be great.

Custom parameters are working fine in the current version of EDIF.

[Jaffob]

They do work, but they're a pain to use, especially when it comes to returning a value to the user or canceling the dialog. It would just be nice if the process could be simplified.