Home Forum Downloads My Favorites Register FAQ Mark Forums Read

Go Back   EQInterface Forums > Developer Discussion > General authoring help / discussion
User Name
Password

Reply
 
Thread Tools Display Modes
Old 07-29-2002, 01:21 AM   #31
psychogears
A Shissar Disciple
 
psychogears's Avatar
 
Join Date: Jul 2002
Server: Xev
Posts: 106
Send a message via ICQ to psychogears Send a message via AIM to psychogears Send a message via Yahoo to psychogears
Default

Now that I'm looking through the hex code of the eqgame I'm seeing alot of familiar strings..., like PlayerWindow, which is a reference to the Screen item "PlayerWindow" defined in EQUI_PlayerWindow.xml... I really honestly think that this is 100% proof that there are things hard coded in the .exe that are required to be present somewhere in the library of .xml files for that particular interface.

Ak, maybe your understanding of XML is 100%, but there is a relationship between the XML docs and the .exe that we can't really be too sure about... to say otherwise would mean to deny that the UI has anything to do with the game itself. We're not just making pretty pictures here, we're making something that has to communicate with a block of code that is client-side EQ. I fail to understand why this is confusing, especially after I presented my own evidence, concrete and real, that counters what you are implying. Perhaps I might be "narrow minded", but I think that's just as bad as giving false hope to other aspiring modders. There are limits. Accept them or make your own game that other folks can customize the way you want them to.

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

of Xev
psychogears is offline   Reply With Quote
Old 07-29-2002, 02:26 AM   #32
Akephalos
A Ghoul
 
Join Date: Jul 2002
Posts: 16
Default

Id like to state that I never said that the UI had nothing to do with the exe. Of course it has to interact, but the pure definition of a UI is what you seem to be missing.

Spell gems are hard coded. The game allows only 8 of them in the hard code. The UI cant create more of them, of course not. The same thing with hotkeys. The game allows 10 per page. The hard coded exe sends that information to the UI. The UI takes that information and displays it. Yes, all of that is hard coded. What I do not believe to be hard coded are the windows. I dont forsee the hard code of the client saying

"You must have this one file in this exact spotin this exact window in the UI, or you cannot run EQ." That would use uneccessary processes from the computer, send unnecessary data between the server and the computer, and who knows what else.

I took a look at the section that you found that string. It appears as though that whole section of the code is listing the things that the UI picks up and displays. It also listed the TargetWindow, the BreathWindow, as well as just about every other thing that we have currently in the UI. I dont see one section of the code in that whole area that says anything about a requirement of inclusion, or any check and balance system of any sort requirement code either. I do however thank you for pointing that section out, I will see if I can decipher the code there a bit more, and see if there is anything exclusive between it and the UI.

There are just too may things in the unknown that neither you, nor I, can prove with any certainty. You know it, I know it. This thread was for people who understand xml (more then I) and have a similar belief that more can be done with the UI then the general people seem to think. For all we know, it could be a texture in the PetHP child element that is not loading properly, causing the issue, however, from the section of code you showed me, it doesnt show me much, aside from every file, and button we have in the UI, as well as references of where to save the default and preference information, where to store the UI errors, and a couple other things. It just doesnt say anything specific about the PetHP/PlayerWindow relationship/requirement.

Of course, that goes back to the, there are too many unknowns to really prove either side. The biggest thing you have is the fact that it doesnt work no matter what you try currently, and the biggest thing I have going for me is the fact that I know how xml works pretty well, and my UI is almost fully functional, with the exception of my empty windows where the PlayerWindow, and Spell Gems used to reside.

/shrug Its been a good conversation, we will just simply have to wait and see what happens as more information becomes available. Im not opposed to the possibility its not possible, I just dont have enough information to determine that its not possible right now. Once I get that, then hey, Ill jump right on the bandwagon with you =D

Untill then, Ill keep looking around, seeing what I can see and how many times I can crash =D


EDIT: Edetad fer gramtikal eror.
Akephalos is offline   Reply With Quote
Old 07-29-2002, 02:48 AM   #33
Akephalos
A Ghoul
 
Join Date: Jul 2002
Posts: 16
Default

I just found a couple things in the code that I did see. This seems as though it has nothing to do with an eqtype or a screen id. This seems to have something to do with input modes.

Everything that I have tried to move permanently out of a window, then disable the window, and cant because of an xml error has some sort of an input function to it. The PetInfoWindow, the PlayerWindow (pethp is an input because it has the toggle to turn it on and off.) Though, weather its on or off is housed in an ini file somewhere.

Last edited by Akephalos : 07-29-2002 at 02:55 AM.
Akephalos is offline   Reply With Quote
Old 07-29-2002, 02:54 AM   #34
Akephalos
A Ghoul
 
Join Date: Jul 2002
Posts: 16
Default

It might make sense, if the hard code is looking for its input from a specific window, and if you moved those child elements, the exe would not be looking in the right spot for its information.

However, this still does not make sense, because the only error you get from moving stuff from the PlayerWindow is the PetHP, and the only input that has is weather or not to display the PetHP bar, and that information is stored in a UI_charactername.ini file, not seemingly even really processed by the exe, just not loaded by the UI.

The other thing that doesnt make sense, is if this were the case, it would not be the XML that is crashing, it would in fact be the eqgame.exe file crashing, because it is the eqgame.exe that would be looking for that information, not the XML. The XML just sends the information back.

Hmm, more discrepancies to add to the pile.
Akephalos is offline   Reply With Quote
Old 07-29-2002, 03:49 AM   #35
Tefrod
A Ghoul
 
Join Date: Jul 2002
Posts: 11
Default

Akeph, I read thru your long post about parent / child and I still agree with Psychogear that the Pet_HP is a hard coded reference in the game EXE.
Can you show us exactly why he doesn't make sense?


I just checked something ingame. I went to my EQUIPlayerWindow.xml file and removed everything in Pet_HP except for the preamble:

<Gauge item = "Pet_HP">
<ScreenID>PetHP</ScreenID>

</Gauge>

Then I started EQ and checked that my pet's green HP line under my own HP gauge has disappeared. Yet when I remove the 3 lines above from the xml file, the game crashes as we all know.

I then searched the entire Everquest directory for the string Pet_HP and found it in the executables.
Tefrod is offline   Reply With Quote
Old 07-29-2002, 10:39 AM   #36
Bolelen
A Fire Beetle
 
Join Date: Jul 2002
Posts: 2
Default You are probably both right

First of all, Ak seems to be assuming that Verant did things the most logical way. I hate to break it to you, but it is rare that anything is ever done the MOST logical way. They probably had reasons for doing some things in code that would have been quite a bit easier to do in XML.

Secondly, it doesn't necessarily need to be "hard coded" in the exe for it to still be "hard coded". In the rest of the world, most any XML also has a DTD. The DTD defines the structure of the XML. We aren't privy to the content of the DTD for the UI, however it is very much possible that there are mandatory elements that, if missing, could cause an XML error.

Now, the XML is being processed in code somewhere, be it in the client or some other DLL. It is very much possible that if the data that comes out of the processing of the XML does not contain certain elements that the exe will report back that there is an XML error, even if the XML parsed fine.

Since we will likely never see the internal code from Verant, until they tell us anything as fact, we cannot make any determination other than, "if I try this, it doesn't work; if I try that, it does."

So, we're down to who believes what assumptions.

I think what would be more helpful to this discussion is listing what has been tried and what the results were.

Bolelen - 51 Monk, Terris Thule
Bolelen is offline   Reply With Quote
Old 07-29-2002, 11:55 AM   #37
psychogears
A Shissar Disciple
 
psychogears's Avatar
 
Join Date: Jul 2002
Server: Xev
Posts: 106
Send a message via ICQ to psychogears Send a message via AIM to psychogears Send a message via Yahoo to psychogears
Default

Quote:
Originally posted by Akephalos
I just found a couple things in the code that I did see. This seems as though it has nothing to do with an eqtype or a screen id. This seems to have something to do with input modes.

Everything that I have tried to move permanently out of a window, then disable the window, and cant because of an xml error has some sort of an input function to it. The PetInfoWindow, the PlayerWindow (pethp is an input because it has the toggle to turn it on and off.) Though, weather its on or off is housed in an ini file somewhere.


OMG Did I not just say this? (edit: Yup, post #22 of this thread) I could have sworn I said this already, you can't move some stuff because when you click on certain things the EQ game gives you a response, and If you remove that the client effectively loses that expected input...

-TJ

PS: Also, the reason you don't see the eqgame.exe straight up giving a protection fault when it doesn't find what it expects to find where it's suppoed to be is because there's probably some type of error recovery, and that's not too hard to program. I'm not for sure for certain that the guys at VI coded any error-recovery, but it would make sense given that there hasn't been an actual GPF that has been reported as happening when there are mistakes in the XML file.

Also, what's the DTD?

Last edited by psychogears : 07-29-2002 at 12:01 PM.
psychogears is offline   Reply With Quote
Old 07-29-2002, 12:06 PM   #38
arantius
A Crystal Gargoyle
 
Join Date: Jul 2002
Posts: 97
Interface Author - Click to view interfaces
Default

Ak and Psycho.. you both need to calm down. You have both made some good points, and correct ones.

Ak though, you are, to put it lightly, wrong. There are some parts of the UI that are "special". The pet guage in the player window is one of them.

Why? Because the pet guage can appear and disappear when you summon a pet or do not have a pet. Does the XML know when you have a pet and when you do not have a pet? No. The XML says "put the guage here". The client then puts that gauge there but only at the appropriate time.

The way it does that is it knows, when there is no pet do not draw the gauge in the player window called PetHP. When I get a pet, draw the gauge in the player window called PetHP.

I can't believe I replied to this.

EDIT: P.S. The first thing you have to learn about coding in a computer is this. Error messages only mean one thing. There was an error. SOMEtimes, the contents of the error message can tell you what that error is. Sometimes it takes a lot of sleuthwork to figure out what that error really is. In this case, it is an XML error simply because the engine parsing the XML code and looking for the PetHP gauge finds it, and it generates the error.
arantius is offline   Reply With Quote
Old 08-08-2002, 08:12 AM   #39
dregor
A Ghoul
 
Join Date: Jul 2002
Posts: 10
Default

normally i would agree with alot of what ak has to say.. but ak is missing a couple of points

1) you assume that the programmers at EQ actually know what theyre doing (this has been proved false many times)

2) you seem to assume that the EQ client was made specifically for an XML GUI... sadly this is not the case.. it was half-assed after the fact to make it compatible with XML.

3) you assume that (assuming the programmers know what theyre doing) they are going to make everything moveable/adjustable... now maybe the easiest way to do something is with XML.. but that doesnt mean that its the most secure way to do something. and for a game like EQ security is king.

for a normal program made to work with XML i would agree heartily with you ak... but not in this case. in the case of EQ i must agree with psycho.

and as for my first post... you dont even seem to realize what i was saying... as a programmer you should know that there is more than one way to do a certain task. i havent looked at it, but i was suggesting that there may be a way to fool it into thinking that the object it was looking for was in the right place.... but anyways, im not going to get into that.
dregor is offline   Reply With Quote
Old 08-08-2002, 10:45 AM   #40
Pini Uldar
A Shissar Disciple
 
Join Date: Jul 2002
Posts: 135
Default

Holy wow. Long thread that I'd never read before. I just skimmed this lol.

The reason why some things are hard-coded is because there is programmed behavior involving that element. It's poorly documented what these elements are too.

For example, that Pet HP thing. There's hardcoded behavior with that because it's invisible until a pet is there, then it's visible. That's not defined in the XML. It's just not. Fact. Instead, it's in the game code that as a part of summoning a pet, make the PetHP element of PlayerWindow become visible.

The same is more than likely going to be true of every element that you get errors for when you try to move it. The game needs it where it is in order to function and the way the game tells you it can't function is by saying "Hey, dude, this thing I need ain't here. I'm loading default."

Yes, what is has hard-coded functionality is very poorly documented. But *shrug* oh well. It's not stopping you from doing things. When you see an error, document it and move on.

Of course all that is my current belief. I have no actual idea what's up in the code. I just dink with it and try to figure out how things work.

- Pini
Pini Uldar is offline   Reply With Quote
Old 08-12-2002, 04:17 PM   #41
Faille
A Gray Wolf
 
Join Date: Aug 2002
Posts: 8
Default

The DTD that defines how a specific EQUI xml file has to look like is what's causing your error. The PetHP gauge is probably REQUIRED whereas the Breath Bar for instance is optional. This is most likely what's causing your XML error.

There are certain things you cannot change about the interface currently, even though *technically* you should be able to. Techincally you can change the help files to ones of your liking, but these are repatched when you run EQ. There is a workaround, but aside from doing something after the game patches, it is just not possible.

If Verant let us change whatever we wanted about the DTD file then the whole program would break, because the parser wouldn't know what to do with the new things it wasn't expecting. On a certain level, things have to be hardcoded. There has to be specifications that dictate how a file looks and what it contains and what is optional and what is not. That's just how it is.
Faille is offline   Reply With Quote
Old 08-14-2002, 05:06 PM   #42
Kiriani
A Shissar Disciple
 
Join Date: Aug 2002
Server: Saryrn
Posts: 114
Send a message via ICQ to Kiriani Send a message via AIM to Kiriani Send a message via Yahoo to Kiriani
Default

I think it makes perfect sense that VI would make certain windows required by the client, especially since this functionality of xml is being added to a specific piece of software that was not originally designed to use XML.

It also makes sense for the sake of retainig some control over what content/functionality can be added.

It further makes sense when you remember that this is all still considered BETA and not a final release. I imagine they are going to continue to add/remove functionality/flexibility until they decide it is totally perfect and ready for FINAL status.

They didn't do avery good job telling us what can and can't be done because, I think, or rather it's likely, that the programmer at VI aren't really sure about the whole thing as of yet.

Those of us modding are going to be the ones to find out the hard way and accept some simple truths that there will be things we can and cannot change. We also have to accept that we are goign to have to redo most of our mods several times as VI continues to update the UI.

Until VI releases a full document explainig each and every parameter that can be used and where, each and every function that can be coded in and where, and basicly everything you could possibly need or want to know about how the xml is used for the UI and what is required of the xml by the client EXE, nobody will have all the answers, regardless of whether you are a professional that can code xml in his/her sleep or if you are just a gamer like the rest of us who is trying to figure out what we can do with our new set of toys.

Face it: Like anything else EQ, there are limits to what we can and can't do, and VI often likes to provide as little information as possible.
Kiriani is offline   Reply With Quote
Old 08-14-2002, 06:06 PM   #43
ForinIronshield
Premium Member
 
Join Date: Aug 2002
Server: Tunare
Posts: 25
Interface Author - Click to view interfaces
Send a message via AIM to ForinIronshield Send a message via Yahoo to ForinIronshield
Default More limitations

To add a bit to the fray here, one thing I've noticed is that not all elements ("nodes") defined in a given XML entity are used by the UIengine. Further, not all parameters of various elements of the UI_<name>_<server>.ini file are applicable to all windows.

Example:

I was playing with eliminating the casting window and moving the casting bar.

My first attempt was to look at the .ini file, where I'd noticed a "Show=0" entry on certain windows that I had disabled from within the game. I added that entry to the [CastingWindow] section. Loaded affected character and guess what? No dice. I cast a spell and the casting window popped up with a casting bar in it.

I then modified the XML - I set the <StyleTransparant> value to true for the casting gauge and the CastingWindow ScreenItem. Tried that, again, no dice. I got a window and a casting meter.

I then went in and set the <ShowBorder> value to false. That worked somewhat, this time I had a window with no border, but a casting gauge still appeared in the screen.

As noted above, setting the size to 0,0 effectively eliminated the window.

Based on this and some other things, here's what I think is going on. The UIengine is using the XML to define values for various screen elements. To the extent that the engine's behavior for the default configuration doesn't change those settings, our modifications will hold. The UIEngine adjusts colors and <Show> properties for the elements as the game runs. Hence my default values for not showing the CastingWindow not working. The default for that window is "don't show" - except when your casting a spell. The UIengine overwrote my values to perform as it was intended to do - to show the window when the casting was occuring.

Further, as is noted, the color of some <EQType> labels change based on game events - noteably the Player HP and MaxHP, AC, stats and saves - which turn red if you are debuffed, white normally and green if you are buffed. These cannot be controlled by the XML since the values loaded are changed dynamically by the engine while the UI is running.

I think one factor that may control the necessity of a given <Pieces></Pieces> callout is whether that element is dynamically toggled by the game (like the appearance of the PetHP gauge) or if the element is used for UserEntry (like clicking on the PlayerHP gauge).
__________________
Forin Ironshield
Paladin of Underfoot
Aegis Wolves
Master Smith, Master Fletcher
Animals die, friends die and I shall die, but one thing never dies....
and that is the reputation we leave behind at our deaths.
ForinIronshield is offline   Reply With Quote
Old 08-14-2002, 11:52 PM   #44
Muse
EQ Atlas Webmaster
 
Join Date: Aug 2002
Posts: 67
Default Schemas and DTDs

I think the part that is being overlooked in your comments Ak is that all XML, in order to be used, must be validated. Somewhere (it looks like psychogears found where this is in the .exe) it has a file that will check the .xml files that are on our computer to make sure they are valid. Some, it doesn't care about (the ones you deleted). Some, it does. Within those, the Schema or DTD states how often and in what order the Elements must appear. They can do this in a few ways, but the aboutSIDL.doc mentions one way, the minOccurs and maxOccurs attributes.

It's likely that within the DTD/Schema (that we don't have access to) that is used to verify the PlayerWindow.xml file, there is a PetHP minOccurs=1 maxOccurs=* bit. This also explains why you get an XML error, because this validation is an XML process and not a .exe process. The PlayerWindow.xml file, however, is mandated by the .exe because they didn't anticipate us doing away with such a key window.
__________________
Muse
EQ Atlas
Muse is offline   Reply With Quote
Old 08-15-2002, 10:12 AM   #45
ForinIronshield
Premium Member
 
Join Date: Aug 2002
Server: Tunare
Posts: 25
Interface Author - Click to view interfaces
Send a message via AIM to ForinIronshield Send a message via Yahoo to ForinIronshield
Default

Actually, isn't SIDL.xml the schema?
ForinIronshield is offline   Reply With Quote
Reply



Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off


All times are GMT -5. The time now is 08:08 PM.


vBulletin Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
© MMOUI