Akephalos

I will try and explain that as best I can. I thought I had somewhat touched on that earlier, but I guess not.

When you comment something out in the code (EQUI.xml), you are removing that particular parent file from being loaded when the UI loads up. We both understand that.

Further, we both understand that some parent files(EQUI_TargetWindow for instance) are easily commented out, and never loaded in the UI. We also understand that there are some parent files (EQUI_PlayerWindow for instance) that are not easily able to be commented out.

This is the knowledge that we currently posess, but at the present juncture, we do not know precisely why this is the case, aside from some vauge references and heresay. What I am about to say will, hopefully, demonstrate some factual basis to further display my point.

Here is the basic way the UI works, from my understanding of both XML, and other programming. When you load EQ, the game goes through all its other normal processes, untill it gets to loading the eqclient.ini. Once it reaches this file, it looks for "NewUI=TRUE". If it does not find this in the eqclient.ini, it will load the old, limitedly customizable UI (Hard Coded UI at that).

If, however, it finds that line in the eqclient.ini, it returns that information to the exe, and the exe, from that point, reads EQUI.xml for its loading process.

This should be understood as being fact, not supposition or speculation. Now, from this point, everything within the UI will be loaded by whatever that single file (EQUI.xml) tells it to load. I liken the EQUI.xml file to be the .ini (initialization) file of the new UI. EDIT - Each file listed in the EQUI.xml file is a parent file. A parent file is defined as being the base file from which child elements are loaded. A child element is basically anything loaded within the parent. This would be something such as a guage, or a button, or a hotkey, things of that nature. Each one of these items is a child. If your hotkey box has 10 hotkeys, there are likewise (at least) 10 child elements defined within that parent window. In reality, there are more like 30 child elements for 10 hotkeys.

Now, when you comment out files from this, some are commented out without a problem. Others are not. What is the reasoning behind this? What causes this? Is this something that we can change to make this work? I will touch on these questions in the following text.

What is the reasoning behind some files being able to be removed easily, and others not currently being able to be removed at all (so some think.) If you look, you will notice that all of the windows that are able to be commented out without any addition to the code (or subsequent removal of the code) are all files that do not currently have a child element defined within the parent file. Typically these are the one function windows (Target window, breath window, casting window to name a couple). They do not have any linked child elements within them. This is the reason they can be removed easily.

What about the ones that cannot be removed so easily. These files have child elements that are interlinked with some other area of the UI? This is a little more tricky. If we were to comment out, say for instance, the EQUI_PlayerWindow.xml parent file from being loaded, you will notice the UI promptly crashes out, but why? Well, this is an example of one window that has an interlinked child element. In this case, I have narrowed it down to the Pet_HP child element. Because this Parent File has a child element that is linked to another (hereafter referenced as a secondary child element) file within the UI, it must remain intact, and in working order (or at the least, that child element must remain intact) or else the UI will crash. Let me explain a little further.

In our example in the above paragraph, where we commented out the the EQUI_PlayerWindow from loading, it caused the UI to crash. This is because it has a child element within it, that links to a secondary child element. With this file commented out, the link is now severed, and thus, the UI is not able to load properly.

Is this something that we can change? In short, I dont know the answer to any degree of certainty, but it is my honest and sincere belief based upon the facts I have available to me that it is something that is able to be changed, but I currently do not know enough about interconnectedness of the UI, nor xml to be able to locate, and test how. Everything that I see in the code here, and everything that I know about XML points me back to these facts, and these processes.

The way in which code is built, rebuilt, and improved upon is based upon logic. Code is a language. A language of logical thinking, and process concepts. As a coder, you find the shortest, cleanest way to do something, with the least amount of resources used, and with the least amount of lines of code possible (typically).

There are two phases in code. The first is the build process. This is the process in which you write the code to accomplish what you want. The second is the refinement process, which takes everything you learned along the way, and revamps the entire code layout, and makes it faster, better, smaller.

It is illogical, in a code minded setting, to cause something to be hard coded, when it is extremely simple to implement in the XML state. There is no need to use cross code-platform processes to accomplish something that can be done on only one side. (All jay-walking laws and hazard considerations aside for the moment) Would it be logical to run down the street 2 miles to the crosswalk, to cross the street and then run back 2 miles to go to the store that is across the streed from your front door?

No, that is illogical, and a waste of resources and time, and is precisely the reason why I do not believe any of this "Its all hard coded" crap that is flying around right now. I think that our lack of understanding and knowledge about the system that is the issue, not that its hard coded.