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.