shillingworth

Decided to update this post since it's the first one anyone sees and the old info was a tad out of date.

The project is in two parts now:
EQIA is a Class Library, more commonly known as a DLL, that assist programmers looking to write their own EQUI tools. It handles reading in EQUI XML files into a set of straight forward classes. The parser has three levels to it: EQUI_Interface for loading an entire interface; EQUI_File for loading a single file; and the individual EQ Interface Definition Language (EQIDL) elements themselves. Each EQIDL class is capable of storing the data for a given element and drawing it on to a sprite batch, which can be used for both drawing to an image and drawing to the monitor.

EQInterfaceArchitect is the actual editing studio. I'll be using this to demonstrate how to work the EQIA Class Library, and as the actual editing studio. My aim is to make this as easy to use as possible while providing minor restrictions to ensure the generated and/or typed XML code will work in EQ.

Progress:

• EQIA
  • EQIDL
    • All XML related interaction completed !
    • Drawing functions completed for the following: TextureInfo, Ui2DAnimation, Button, Label, Screen, TabBox, Page, WindowDrawTemplate, Gauge, InvSlot, StaticAnimation
    • Unfinished drawing functions: Combobox, Editbox, FinderBox, Listbox, Slider, SpellGem, STMLbox, LayoutBox, Static Elements
  • Manager
    • EQUI_File - Complete
    • EQUI_Interface - Complete
• EQIA_Core - Partially Complete
• EQIA_Debug - Complete
• EQIA_Defaults - Partially Complete
• EQIA_Xml - Complete

__________________

Pyndragoon

I don't understand most of the things you are describing, I am something of a novice at working on these UI's. But I just want to say kudos to you for taking on something of this magnitude that will benefit all of us UI junkies. Thanks.

fenrian1

WOW, sounds like you have done a ton already.



I would not worry over much about this, simple being able to "Save As" would be enough in my book, and I dont mind having to find the EQ files manualy, especialy if it will default back to the last folder I opened.



It would be nice to include in this the scaling the EQ uses on images over 256x256. SidlWidl does not show over sized images properly.

Support for visual editing of nested screen items would be nice, it would make modifying parts like the tradeskill window alot less painful as well as editing custom parts that we add our own screen elements to, to allow easier moving of blocks of items.


The one other tool that would be wonderful to have, would be a duplicate item parser. I have noticed that EQ will tolerate some duplicate items and randomly produce an error message or randomly crash the game. This would be especialy nice if it parsed the entire folder, rather that just the UI item currently opened. Some duplicate items will cause the default to load, but not add any error message to the UIErrors folder.

I look forward to seeing the end result, even if yu give up, I thank you for even making the effort.

Fen

shillingworth

The image scaling isn't actually scaling at all. It's the difference between your desktop resolution and the in game resolution. Resolution is in the form: Pixels Wide x Pixels High. So if you set your desktop to 800 x 600, and in game to 1024 x 768, the images will appear smaller in game since it uses more pixels to draw the screen. I'm not sure what the developer of SidlWidl did when he handled images, but I've noticed that too and found it a bit annoying.

I think I have nested screen elements solved without trying, the way I'm storing and reading the data starts with the root screen element and works it's way inward from there.

The duplicate items wont be allowed, the method of storing elements, at least in a single file, doesn't allow for duplicate entries under the same name (name being the item tag). Extending this to the entire UI wouldn't take much effort at all, think I'll add that functionality to the project manager.

Yeah I got a lot done when I first started working on this a couple months ago. I have tons of free time, so I program until I get bored, then do something else til I get bored of it and return to programming to repeat the process. I usually give my programming projects more time than anything else though, things like this one would look pretty good as a demo of what I can do on a resume.

shillingworth

Today I was working on the element sorter, and I'm starting to get there. Below are two screen, one before and after. Note: I copy and pasted the output to visual studio so that I could shrink all the elements to see if it was getting all of them. You can see by the line counts that I havn't yet fully implemented the default value filter.

The serializer (part that turns data into files) starts with the root screen element, in this case PlayerWindow (which it finds on it's own programatically). Then it works inward. After it builds the list in the order it found screen elements calling them, it re-arranges any elements that are called before another, like TextureInfo before Ui2DAnimations by looking for where it's referenced. If any elements exist in the file that are not referenced by a screen, page, or layoutbox (all 3 flavors of them), then it adds them to the top of the list and sorts them in the same manner as with screen elements.

Before parsed by EQIA (this is the default EQUI_PlayerWindow.xml)


After it was parsed and rebuilt by EQIA (same file as above), and a shot of the pieces list in EQUI_PlayerWindow.xml to show why it's arranged differently than default's.

fenrian1

Nice feature. I thought of another nice idea if its not too hard.
A button that will toggle between collpased and expanded trees. I have an xml editor that has a few nice features, but its most irritating thing is that it defaults to expanded trees and you cant colapse all. Kinda of a pain when viewing a UI piece with over 6000 lines of code.

shillingworth

I was planning on implementing collapse/expand features into the editor. It's the main reason I been using visual studio to edit all my ui files for so long. For now though the selected element (from a list on the left side) loads without the rest of the xml, just the xml of the selected element. I imagine the collapse/expansion stuff is gunna be tough to figure out, so that's pretty low on my list.

Unfortunately I had to remove the ability to do math in the properties panel and incoming xml stream. Until I figure out a faster method to do it. With the method I was using loading a 2000 line file took almost 5 minutes, without it takes maybe 1 or 2 seconds.

myxiplx

Suggestion for the element sorter. How hard is it to have it give you a choice of sort orders?

While this view makes sense, arranging by location may also be useful. For example, you're editing a hotkey or bank view, and the original code is all over the place.

Being able to quickly re-sort it by x,y co-ordinate will very rapidly sort that code out.

I'd also like any re-sorting to be optional, for example; in my group window my code is arranged as:

<!-- Player 1 -->
<Label> - player name
<gauge> - hp's
<gauge> - pet hp's
<label> - hp %age

That makes it much easier to move that entire block, or tweak the layout if I need to as I'm not hunting all over the code for the common pieces.

However, being able to re-sort the whole thing by simply re-arranging the lines in the <screen> element and clicking 'sort' would be awesome!

(hope I'm not creating too much work, but I believe in throwing ideas out there)

Myx

GreenDragon

it looks like you are coming along nicely. I hope that we can both get ours done so people can have the best possible. By this I mean a little competition not for speed of delivery. I mean for best quality and features. There will be no awards or prizes other than the community getting the best possible editor. Also I like you idea making them into DLL files so others can make their own flavor of editor if they want. If you need some help with optimizing send me a message I am a whiz at making fast code.

shillingworth

Sorting order is very easy to set. I was already thinking about taking a text file with the order of elements, then only forcing orders that are required, like with referenced elements.

That sounds like fun GreenDragon, but I have a feeling our editors will be very different, which is good because while some might like mine, others will like yours. I imagine a small amount of people will use both editors to make use of the strong points in each. I doubt I'll need much help in optimizing but will definitely keep that offer in mind if I get stumped. I'm pretty good at optimizing, it just takes me a few rewrites to get things down to bare minimum.

The whole speed issue with the math in strings was because I was using reflection to build a mini-program in-memory, so every time math was performed it had to compile the mini-program without the benifit of a real compiler. I'll probably rewrite the math evaluation using Regex or string functions, but that's one the things at the bottom of the list.

shillingworth

Just finished integrating a property on all the elements I never knew about before (IsNullable), it tells the serializer to ignore this element if the value is null, 0, false, or empty. Code generation from EQUI_Inventory went from: Default untouched 3000, After re-generation 7853, After filtering null values 4477. I also learned about another serializer attribute called Order, it's suppose to order elements, so I'm going to study up on that as it may prove much faster than the way I'm doing it.

myxiplx

I gotta say, even without a GUI I want your tools now!!

Just being able to run xml files through this to re-sort them would be a godsend. Much of my work made use of other people's mods as a base, but some of the code is horrendous, things have obviously evolved over time and I'm left hunting all over the place to find the xml elements.

Don't suppose there's any chance of releasing the re-sorter as a standalone app, so I can just point it at a file and say: go sort it. If that's possible you've got a willing beta tester for your sorting work here.

Myx

shillingworth

Well I'm not far from releasing an alpha of the text editor side of it. Further sorting:

Text file I used as input (just used the list in AboutSIDL.doc and removed a few elements from it that don't appear in UIs) - And the result (trimmed a lot of lines out for screenshot sake, but left in at least 1 of each element type):


The AboutSIDL.doc file is applied to the sorting first, than if any custom sorting order is specified, it'll go back through the list and re-arrange it to match. This way things will look neat in the case of only having a couple element types in the input file. The entire sort took less than half a second. Think next addition to the sorting mechanism will be adding weights, so that they can be sorted by alphabet and element type at the same time.

myxiplx

Well, you've got a willing alpha tester here, I don't care how buggy it is, I'll use your editor on a copy & just revert to notepad if it dies . Interested to see how your doing this in code too. Once I get started on my installer program I'll need to be checking dependencies to split UI parts out, can see me 'borrowing' a lot of your ideas ;-)