DarkEDIF - Taking suggestions

Phi · June 27, 2012 at 11:44 PM

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

Atom · June 27, 2012 at 11:50 PM

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 · June 28, 2012 at 4:32 PM

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

Atom · June 29, 2012 at 2:47 AM

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 · June 29, 2012 at 3:25 PM

Quote from Atom

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:

Code

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

Display More

Jaffob · July 2, 2012 at 11:45 AM

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 · July 2, 2012 at 2:18 PM

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 · July 2, 2012 at 3:34 PM

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 · July 3, 2012 at 7:03 AM

Quote from Jaffob

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 · July 3, 2012 at 7:51 AM

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.

Phi · July 8, 2012 at 3:29 AM

For those interested, development is currently hit a hurdle, you can help at this thread:
Please login to see this link.

At the moment, I can confirm properties work, including string, editboxes, etc, and variants of those properties work, e.g. lowercase-only editbox, uppercase-only, password-protected, combo of those...
Combo box is giving issues, but that hurdle is the main problem atm.
I recreated Lacewing Relay Client in DarkEDIF about a week ago, after I released James was far too busy to even give a short reply to my PM requesting the current EDIF code. It it only took a couple of half-days, and I'm happy to report it's completely backwards-compatible as the old one was. I'm also using DarkEDIF's multithreading system in order to boot a separate timer thread, making Lacewing ultra-responsive, but the system ensures it doesn't infringe on MMF's single-threaded nature.
Properties are still very much WIP, once I know I can set all of the types up, I'll look into storing values dynamically.
Φ

Phi · July 12, 2012 at 2:05 AM

An update: properties are working, you can now edit string parameters.
It appears with SetPropValue(), MMF2 lies about what type of parameter is being changed, and changes string properties to buffer properties. Consequently, you need to pad 4 bytes with the string property in order to make it compatible with buffer properties, and additionally query your own local copy of the property rather than MMF2's, as that will tell you it is a buffer.

Once I realised this inconsistencies, I fixed the bugs quickly, and I'm now stuck on memory access issues copying from edittime to runtime. I'm going to try several storage containers in case MMF2 somehow thinks it's permitted to overwrite already allocated memory.

Phi · September 10, 2012 at 9:43 AM

Big update guys, finally got around to finishing off the languages.
The header files have been cut down significantly and communication with MMF2 has been optimised, including removing loops and cancelling functions that would otherwise crash the program.
Also included is the first version of Bluewing Client, a test for DarkEDIF's multithreaded system, and for fixing a bug I was getting with Lacewing Relay Client. It is designed so you can disable and enable multithreading easily. The a/c/e/p will synchronise with Lacewing exactly, so you can overwrite the mfx file if you wish.

Other extra features include:
• Conditions to check if a peer is joined to a channel, useful for invite lists which might not be up-to-date or checking a series of channels.*
• An expression to dump a binary message containing multiple variables of multiple types, useful for debugging and logging.*
• Strict usage. If you try adding a byte of value 300 to Lacewing, it will wrap the value, as would C++ during a regular cast with loss of information. However, Bluewing will report an error instead.
*If you use these, you cannot convert back to Lacewing without removing them. Since they're new and Lacewing doesn't have them.

I've also added Looki's WaveOut example extension, allowing audio streaming.
See the new DarkEDIF commit here:
Please login to see this link.

Dines · September 10, 2012 at 2:41 PM

About using external exe files as edit dialogs and custom parameters:

To handle the returning of data, what about using a block of shared memory between your extension and the dialog? The dialog would need a helper extension inside it to detect the shared memory block and expose it. Then the developer would define his shared structure's format in a custom header in the SDK, and replicate that structure using something like Format Object, pointing to the shared memory address.

Then I'd imagine your bright-eyed, bushy-tailed MMF-built dialog could access the shared data structure like that. Bless its little heart.

So essentially:
DarkSDK sets up some shared memory in a format determined by the developer.
DarkSDK triggers MyDialog.exe (a Standalone EXE made in MMF) using ShellExecuteEx().
It waits for the process handle to finish.

Meanwhile, in a galaxy far far away, MyDialog contains an extension (let's call it DarkSDK Dialog Object). This extension finds the shared address and exposes it via an expression GetSharedAddress().
MyDialog contains, say, a Format Object with a format that matches the structure in the SDK. It reads the data at GetSharedAddress() and edits it in accord with whatever the developer tells his MFA to do with it.
When MyDialog closes, the SDK uses its amazing psychic WaitForSingleObject mutant powers to detect the dialog's closure and triggers the developer's code to use, save, or whatever based on the returned data...?

That's all just brain noise, so it probably wouldn't work, but be gentle... it's a theory

LB · September 10, 2012 at 10:49 PM

Just FYI Phi, liblacewing is designed to be run in single-threaded environments. You can use the manual-tick method in Extension::Handle. From what I've seen of the multithreading I'm thinking the bug you fixed was that the Lacewing Relay Client was too fast. As for the extra features: Select peer by name and compare to peer name; Memory object; do we now have to specify signed and unsigned in the actions? But seriously, multithreading like this is a way to slow your extension down and give yourself some headache-inducing crashes. I've heard from the best (aka the author of liblacewing).

Dines: This may be of interest to you: Please login to see this link. note the "SHARED" option. This applies to the Ext.def file.

Phi · September 13, 2012 at 2:22 PM

Quote from LB

Just FYI Phi, liblacewing is designed to be run in single-threaded environments. You can use the manual-tick method in Extension::Handle.

I knew that, which is why the multithreading is optional (and if the thread fails to boot, it falls back on single-threaded anyway). I am aware that the MMF2 library is not designed for multithreading which is why DarkEDIF incorporates a queue and handles the queue inside Handle, pretty much what Lacewing does with its events.

Quote from LB

As for the extra features: Select peer by name and compare to peer name; Memory object; do we now have to specify signed and unsigned in the actions?

Sorry, I can't interpret that at all...

Quote from LB

But seriously, multithreading like this is a way to slow your extension down and give yourself some headache-inducing crashes.

Crashes are easy to remove if you know what you're doing, and if you find you don't, the only way is learning and experience
I'm actually considering adding multicore to one of my already multithreaded C++ apps. Since my 2nd extension, I've been working with multithreading. If there's an issue, it will be isolated and resolved, since the only place the error could be would be in my code.

LB · September 13, 2012 at 10:50 PM

Quote from Phi

Other extra features include:
• Conditions to check if a peer is joined to a channel, useful for invite lists which might not be up-to-date or checking a series of channels.*
• An expression to dump a binary message containing multiple variables of multiple types, useful for debugging and logging.*
• Strict usage. If you try adding a byte of value 300 to Lacewing, it will wrap the value, as would C++ during a regular cast with loss of information. However, Bluewing will report an error instead.

Quote from LB

Select peer by name and compare to peer name; Memory object; do we now have to specify signed and unsigned in the actions?

Quote from Phi

Sorry, I can't interpret that at all...

Was it just too out of context?

Phi · September 14, 2012 at 4:28 AM

Oh now I follow you.
"Select peer by name and compare to peer name" requires you to use 2 events and looks messy. In Bluewing, if it can't select a peer, you get an error, and the original peer remains selected. Unless you use this condition.

No, you don't have to specify unsigned/signed in the actions, for compatibility with Lacewing, but it will detect if it's (x < min_signed x > max_unsigned).

What's that about memory object?

LB · September 14, 2012 at 1:47 PM

You can get the address of the binary to send and the received binary with Lacewing, so the Memory object is all you need to access it. I'm not sure what you mean by 'dump' as Lacewing already supports saving the received binary to a file.

Forum User · September 14, 2012 at 4:04 PM

My suggestion of an improvement is to remove the "multithreading", because it's always going to add overhead. You're just adding another queue.

Log in or register!

Looking for Customer Support?

DarkEDIF - Taking suggestions

Participate now!

Tags

Useful Links, Resources & Information

Fusion 2.5 Resources

Crowdfunding Focus