I’ve started working on a SAI-Editor for TrinityCore a couple of months ago using C# with the .NET 4.5 framework (which means it’s Windows only as I’m not bothering with Mono). The application is opensource.
I’m sorry for the VS issue, didn’t really think about it… /emoticons/default_smile.png
As for the advantages, it really is mainly a matter of preference. The main issue with Event Horizon is that it is closedsource and has not been updated for two years (and I personally really hate the design). Besides, I am planning to make this one cross-platform using Mono when it’s in a further stage of development. Another important note is that it’s opensource so it should never be able to ‘die’ or get outdated.
As for Truice, I don’t really see Truice’s SAI tab as an editor. It’s a viewer in which you can edit some values if you do research. My main goal is to make SAI available to everyone and anyone, even those without any scripting knowledge (think of auto-generated comments based on the correct codestyle, detailed information on events, actions and targets when asked for, etc. etc.).
I’ve been considering it but I personally hate the whole design pattern (not sure if that’s how I should say it) behind WPF and truly love the Windows Forms one. It’s not really worth the performance boost in my opinion compared to the ease of development (read: opinion).
Very nice to see this! I’ve been searching for an EventHorizon alternative for quite a while now and finally found it.
I personally really like the layout of EventHorizon, so I’m very curious what kind of layout you had in mind for your own program. Could you maybe include one or more screenshot to show the current design? (I’m using a macintosh, so I can’t use your program yet untill it is cross-platform.)
I agree. There were a lot of pluses to EH compared to just about any other editor I used. A few that stand out:
[li]clean interface. Not cluttered, and hardly tabular. There was never a need for scrollbars; all the data fit in the window provided.[/li][li]The list of actions was separate from the list of params, making it easier to read and navigate[/li][li]colored phasemasks, making it simple to discern between phasemasks.[/li][li]dynamic param values (not param1, param2, etc, but actual specific values like duration or map, etc)[/li][li]Very well contextualized. If you weren’t sure what a field was for, all you had to do was hover and the tooltip provided information specific to the necessary value.[/li][li]Ability to modify other related tables (like creature_text, NPC_text, and even conditions)[/li][li]Big: ability to generate SQL instead of directly modifying the DB. (with the ability to execute / save the changes directly as well)[/li][/ul]
Most of these, with the exception of the last one, are largely visual aesthetic. But if you’re going to create a GUI, it needs to be intuitive and worth its weight, otherwise you’ll get the argument that doing it by hand is the better way. Personally, the less time I have to spend scouring documentation to verify values, the better.
That said, the documentation already available on the wiki should somehow be incorporated or hard-linked from the editor. It’s a trinity editor so using trinity resources and documentation should be a given. (unless of course you already do this).
LF dynamic param fields depending on action_type. /emoticons/default_smile.png
So we’ve talked about this, but Discover- didn’t know about it, so maybe we should discuss it here? I told Disco that you should probably figure out how you want the elements laid out before a GUI is done (because essentially, the winforms design view is your wireframe, plus it paints a much more realistic picture of what is possible).