Akephalos

No, the breath element guage is not required either. If it were, then you would not be able to completely cease that window from ever being loaded, period, or else the UI would say, hey, missing required file Breathe_Guage.


To take a default UI folder, and then delete the line of code that causes it to be loaded into the UI (<Include>EQUI_BreathWindow.xml</Include>), and save that file, and load the skin should cause a crash, based on what you are saying, because that file is required.

However, it does not crash, and the breath window is never loaded, because it is not required.

This has already been establised, the problem is not with the fact that these files are required or not, it has to do with references to child elements, and the need to change those references to point to the correct place to find them.



EDIT : Correction, by deleting this <Include> line in the EQUI.xml file in a DEFAULT FOLDER, one with NO MODS, you are removing the guage also. THAT is what trashes the theory of things being required.

NijK

Akeph I really appreciate you explaining it the way you did, that's exactly how my brain would have reiterrated it. Before I got back to this post, I had finally successfully edited part of a UI. Now deleting the Target window so the target gauge/label will work in another window is my next step of toying with this stuff. While I'm thinking about it though, does everyone agree that we can't make buttons in a UI window for keyboard commands such as "/book 8" etc, because those aren't EQTypes? I'm almost 100% sure of this, would just like for someone to confirm. Thanks again.

Akephalos

Yes, that is true. The UI is simply that. An interface between the user, and the commands that are available in the exe. Unless that command or feature you want is in the exe, the UI cannot interface with it. Likewise, the interface cannot create any commands or features in the exe.

Basically, just use a social

Does that help?

Geddine

Akeph I still not sure what it is your trying to acomplish though.

I like your clarification and your right you most prob could remove those windows becuase they contain elements which can be displayed in any window (they contain pure EQType items). Have you tried with a window with a button in it?

When you do a /loadskin the client goes through the files and as its loading is doing errorchecking, now I don't why but for some reason the client requires certain things to exist not only that but they have to exist in a certain window. I'm just thinking this is becuase of the way Verant has the client talk to the UI. If you have noticed the only things that are moveable between windows are plain text labels and items with an EQType. I'm guessing that when the client outputs to an EQType it is just telling the UI this Type has this value and the UI does all the rest. All I can say is hopefully Verant will make all the buttons with EQTypes or else we are stuck with them in the windows they are.

__________________
Geddine
"Of all the things I've lost, I miss my mind the most"

dregor

if you are having trouble with the pathname to the child... maybe you should just put the child back where it was to begin with. then just change _your_ referance to the child instead of trying to change the hardcoded referance.

Milambus

The problem is you are making assumptions about the UI without any proof. You believe all the code is in the XML documents, but then when you fail to find something you are refusing to see that it must therefore be in the EXE.

If you notice everything that you can not remove is something that the client has specific code that interacts with it. The pet health bars have a toggle to display them (right-click the player window, there is a toggle to turn off "Pet HP").

So there is specific code within the EXE that makes reference to this Child nodes of the window.

Basically there is this piece of code in the EXE that needs to hook to an object, and you are trying to take that object away. This is causing your errors.

Would it be nice if the had coded it some you could move everything? Yes. But unfortunity it seems they took short cuts on some of the programming, such that you can move buttons to new windows, and you can't remove buttons from a window.

If you can prove me wrong? Great. But so far you are just stating that you think is SHOULD be that way, when all evidence points to the contrary.

psychogears

Ak, thanks for the clarification, and I think Guice is on to something. I'm gonna look into seeing what exactly we can remove and what we can only "hide"

-TJ

PS: I think we can hide gauges and labels... not sure, but my gut tells me that Gauges are kinda like Labels in the sense that they're output-only types of ScreenPieces, and since you don't click on them or modify the contents of gauges or labels in any way, you don't have to show them. But the Player Window you can provide "input" because when you click on your HP gauge you target yourself... so I'm guessing if you either remove the HP gauge, or the player window in its entirety, you'll mess up and your UI won't load or will crash the game.

__________________
Hazul, Plik, Xzhamacharathae, Seis, Lyca, Pogi, Camm...

of Xev

Akephalos

Its not assumptions that Im making, its the understanding of the XML language that leads me to these conclusions. The problem is, I dont understand it completely.

Whats more, everyone claims that this stuff is hard coded, which is fine, believe that, but, when you remove something, and get an error, its an XML error. If the client EXE was "Hooked" as you say, to the XML, the client would cause an invalid page fault, (You know, the windows error) not an XML error, and that is the biggest thing right there, telling me that the XML is referencing child elements within itself, and causing its own errors.

It simply means that it needs to be tracked down, and loacated. You say, prove to you that the issue is not hard coded. The simple points above are fact. I say to you, if you have proof that its hard coded, show it to me. I want to see fact, not just "It doesnt work, so it has to be hard coded. We dont see it, so it has to be hard coded. I dont want to learn any more about this, so it has to be hard coded." That is not fact, more so speculation on the part of whomever is passing that idea around.

The simple fact is that the UI is an interface between the various functions and commands, and features of the game, and the player. These hooks you refer to are nothing more then the information that the UI interprets. The toggle pet health button is simply a switch. To either turn it on, or turn it off, easily able to be done with the XML, much more difficultly done in the hard code.

Your ramblings did give me something to look for, and that is the health switches, I will check and see if I can find any within the xml, and adjust or turn them off completely, and see if that works.

Dregor, that would make this entire conversation worthless. The point of this is to gather enough information to make the mods that I would like to see in the game. Once this breakthrough is made, the sky is the limit with the UI. Its just too new for anyone to really know that much about its hierarchy, and method of functionality yet.

Psychogears, you can move the HP bar just fine. I have, and it works fine in the hotkey window without a problem. The only item in the PlayerWindow that cannot be moved is the Pet_HP, because it is referenced by something in the xml somewhere, and you will get an xml error when you do so.

Akephalos

Geddine, you are right, certain things are required. Those certain things are child elements, and they are required because something in the xml is referencing them somewhere, or is telling something where they are.

I completely concur with the fact that, with the knowledge we have currently, certain things cannot be done. This topic is to discuss, and further our knowledge so that those things can be done.

Such as taking all the information from the PlayerWindow, and putting it in the HotKeyWindow without any stupid XML errors =D

I will find out, eventually, how to move these things, and make it all work, OR, I will find out precisely why it cannot be done, not just wild speculation on the part of "It just cant be done".

psychogears

I can't wait until VI releases a better aboutSIDL.doc... it's all guesswork as far as I can tell, and XML understanding or not there are a couple of things at least I don't really know for certain that I'm sure lie within the game engine-to-client realm. Ak, can you tell me why that when you remove some things it crashes or gives errors, and other things it acts fine? When you remove something, I'm talking about commenting that part of code out, not setting it's size to 0 x 0.

-TJ

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.

psychogears

Ak, try this.

Go to Line 51, you will see:

51: <ScreenID>PetHP</ScreenID>

Now do this:

51: <ScreenID>PetHPx</ScreenID>

You're right in the sense that this child element is "linked"... but it's not linked in the XML files, it's in the .exe itself. I did a search for the string "PetHP", and it came up with

eqgame.exe
testeqgame.exe
UIErrors.txt
EQUI_PetInfoWindow.xml
EQUI_PlayerWindow.xml

You see 2 *.xml files there, but the string "PetHP" in the EQUI_PetInfoWindow.xml file is actually part of three strings:

236: <Gauge item = "PIW_PetHPGauge">
237: <ScreenID>PetHPGauge</ScreenID>

and

313: <Pieces>PIW_PetHPGauge</Pieces>

So that really leaves "PetHP" in EQUI_PlayerWindow.xml, and that specific string is used to reference the gauge by ScreenID, and not directly. By making the change in line 51 as described above, you aren't even removing the gauge from loading. It's still defined, and it's still listed in the Screen item "PlayerWindow".

Okay, so since "PetHP" is really just listed once in all of the .xml files in that directory, and there are no other hidden text files in that directory or even in the uifiles directory tree that have that string "PetHP", I am pretty sure that "PetHP" isn't referred to via a file used specifically by the new UI.

So checking the files above, you can exclude UIErrors.txt, because "PetHP" was generated as part of an error return string that gets written to UIErrors.txt when something in your interface either crashes the game or prevents the UI from otherwise loading. This leaves the two .exe files, eqgame.exe, and testeqgame.exe, both of which are the actual game clients.

Now, like I've been saying before and I will say it again and again, there are some things which you cannot change... wait, let me reiterate, you *CAN* *NOT* *CHANGE*. You can't change this, no matter how much you believe that the answer lies in the XML files. It doesn't. This is not a web application we're messing around with, this is a game that has two parts, the game itself that propagates the actions that are intended by the player, and the interface which relays the player's intention to the game.

Think of it this way, You have a person who speaks English, and a person who speaks Spanish. The spanish person says "hola", now the English person can say "Hello", "Hi", "Hello means Hi", "Greetings", "Hello means Hi, and means Greetings as well"... you can rename the english word over and over, call it "Smith", "Barney", and *define* these words as meaning "Hello", you can reiterate yourself as many times as you wish, but *EVENTUALLY* you have to use the word "hola" to make the spanish person understand that you are doing the action of greeting the person....

I have no idea how else I can demonstrate this. So there it is. If you can't understand that we CANNOT simply name everything whatever we want and expect the eqgame.exe and testeqgame.exe to understand our changes... then I have no idea what else to tell you except wait for VI to say what I've already said here. It's called a standard, and in this case the standard has not been communicated clearly as of yet to the community of EQUI modders by VI.

Sorry to tear you down, but this is what needs to be done because you insist that the answer lies solely within the XML files.

-TJ

Akephalos

Tear me down? Hardly my friend, hardly.

What you have demonstrated is that you did not read this, nor any previous posts. You have missed several key points in the discussion, and have missed them a couple times, since I have laid them out for you clearly in a couple different areas. Closed mindedness is never a good thing.

But I digress, this wasnt supposed to turn to a flame war, this is an information gathering thread. You seem to think you have enough information to determine that it cannot be done, I seem to think that I have enough to determine that it is a possibility.

We will leave it at that. I will still experement, and see what I can come up with.

psychogears

*shrug* okay. You didn't read my post then if you still think you can do it. It's the reason why we can't make new windows, it's the reason why we can't delete certain ones, it's because there is a hard coded portion of the UI that we can't change and thus some of the things in the XML files if altered will cause errors for loading the UI or simply just quit the client.

Trust me, "friend", I read your posts, I tried what you suggested, I analyzed why it works the way it does. These are the results, and I'm not making it up. I have no idea why you refuse to believe that there is a hard coded portion of the game when it clearly exists... otherwise if the WHOLE client is done in XML then we should be able to do amazing things like add more spell gems to our memorization bar, or have more hotbutton slots or spells per page... it just doesn't work like that. There has to be a limit to the customization or else we would be able to create UIs that give us extremely unfair advantages. I know removing the pet gauge from the player window hardly seems like an advantage, but if you can alter that one thing, then the game itself would have to compensate by adding in extra programming in the game that deals with "Okay, the guy who made this particular UI didn't include a declaration for a pet gauge here, we need to do something else to deliver this information"... no. I don't even want to get into that.

I know how XML works, and I know that the way it's been used in recent applications that there are certain things that are immutable such as this particular "PetHP" <ScreenID> reference being where it is. Take a look for yourself you'll see what I'm talking about. Where else in the XML is this referred to? No where? So it looks like it's totally useless because it looks like it's declared and never used, but it is.

But whatever man. Your projects will remain broken if you keep looking for the magical file that you can edit to make your mods work. Just accept that you cannot change this and adjust your modifications accordingly.

-TJ