I've been thinking about how to do the default values, and I think the best way may be to allow an INI setting for the parser that will tell it which profile to use. If you can get me the default values for the other profiles I'll set it up.

Looking over the matrix right now to make sure nothing needs to be tweaked the default values. Most fo them are the grey values. But I did some guess work on a couple and want to make sure Ive got things correct.

Ok Ger,

Notes for you on the Matrix to help with your parser.

If I understand your parser is going to 'fill in' the spots for commands that don't exist in the
eq2.recent.ini

90% of the grey listings do not change.
So basically if your parser doesn't find those values in the eq2.recent.ini file it can
create the command and the default value and put in the .xml file.

There are a couple of exceptions though.and changes I need to make to the matrix

Animate procedural Textures should be 'true' by default I believe. I have it listed as true on
the extreme quality settings, but as you can see I have it false on the others.
It specifically shows up in the file at Very High Performance as false, so
I believe this value should be set to True by default.

That's a mistake on my part.

These tables were making my head swim, but I'm sure it can in handy for you when you wrote the parser.
I do have Excel Database files available if you wantt those rather than thte PDF file.
You can import the data into whatever database program you use.
The links are here.

Particle Level Of Detail Bias (r_particle_lod_scale) should set to 1.0 if it's not found in the
eq2.recent.ini file. The 1.125, 1.250 and 1.375 I created as a gradiet.
After you pass 1.5 at high performance the listing vanishes from the eq2.recent.ini file so I think it
just goes to max.

Spell Particles Close to Me (r_particle_near_plane) is a tricky one. This one doesn't show up
in the eq2.recent.ini file unless you change it to anything below max. 0.0
This one also doesn't update the slider properly, but it does get set with accept. So it's just a
freaky thing with the slider.(I might be confusing that with the triangles slider though)
I would set that value to 0.0 if it's not found in the eq2.recent.ini file.
NOTE. Anything lower than max, turns in a negative value. You can find this in the options.xlm file.
That slider has negativetype set to true.
So you may have to specifically do something with the parser to make sure it outputs a negative value.
if the user has set this setting to something other than default.


Maximum Triangle Density. 80000.0 (I think) would be the default for this one. I think. I don't think the file
list anything over 80000.0 but you might want to double check that one.

The other values I came up with. The slider goes to max on the pre-defined profiles.

Low Detail Characters needs to be set to 100.0 if it's not listed in the eq2.recent.ini file.
It's only not listed on the Extreme Quality settings,
I'm prety sure this listing is in every eq2.recenent.ini file so it's safe to use 100 as the default since
it will be likly that the command is listed in the eq2.recent.ini file.

All of the other listings use the value that is in grey. Which I believe you have done already.

Especially include the Graphics Resolution, lighting resolution, Flora Radius, and Flora Density.
If you tweak these lower, and then load a pre-configured profile, it won't change them back automatically.

If you have any other questions just let me know.
This parser is going to be super sweet, great team work. lol

Logically, I can't see any holes in our theory here.
User sets there settings. Clicks Accept.
Goes windowed. And moves the eq2.recent.ini file to the parser directory and runs it.
user goes back into game and creates second bunch of settings.
Clicks accept and and goes windowed
and moves the file and parsers it again. Creating Profile #2
Repeat again.
that's 3 .xml custom profiles.
Than they would need to restart the game, and from then on they will always have those profiles
settings set to the buttons for as long as they want.

Super sweet!

Here are links to the files.
If you want to download the Excel Files
EQ2_Display_Commnad_Table Excel File

EQ2_Performance_Profile_Matrix Excel Files

EDIT!
I just read your last post. LOL
The 'DEFAULT' Values are all of the values in grey. With the acceptions of the ones I've listed above. Which need to be set to the values indicated if the value isn't listed already in the eq2.recent.ini.

As for the settings for the other profiles they are all in the Marix.
Under each column.

You can even use the Excel files perhaps to just cut and past all the command and values! Save you some typing.
There is a typo on the max Triangle Deinsity for the Extreme Quality.
it should be 100000.0 I put an extra zero on accident.

Is there anything else I should add to the panel besides three buttons?
And the two volume buttons?

Should I make the buttons bigger?

Or just break them off the startbutton window and
keep them the same size?

Is three enough? Personall I think three is a pretty good number, to get
a good range of profiles for quick change. run in balanced
hit the high quality button for screen shots or whatever, and run in high performance for those laggy times.
I think more than 3 would be over kill.

And I dont' want to get anybody excited but I 'might' have found a way to get rid of those stupid splash screens on load up.

Take a look at this file, if you are bored.
eq2ui_loginscene.xml Just glancing at it, it seems like it would be pretty easy to remove those totally, or at the very least reduce the time they are on screen, or set some state to true to just pass over them. My first shot wll be to just remove the dang things totally, Epilespy warning will probably have to stay in there. I'm sure someone will beat me to that though. I won't be able to play with this much for a day or two. Really sucks cause it's fun to get couple of people working on this together.

Just to clarify.

The "Default' Values that the Parser would need to fill in would be the same for every profile. The 'check' that needs to be in place is if the Parser finds the listing, If it doesn't it can auto fill the 'defaul grey' values on the matrix.

The reason this would not change from profile to profile, is because if the user sets something to a non-default value. It makes it list in the eq2.recent.ini file.

Hope that is more clear.

Does EQ2 have global defaults for these settings? Or are they defined by the profile in use? I.e. if I change from extreme performance to extreme quality, does only the r_performance value change in the ini or does every other value change as well?

Ger, basically the answer to your question is yes.

Let me explain.

The 'default' values really have nothing to do with the r_performance pre-defined performance profiles that come with the game.

You have to look at it from another angle.

The 'default' values are for the display options themselves.
This is there native state, the state they are in by default.

Basically from what I can tell is that the Rendering engine lookes for values in each of the variabls.
If the value is empty, it reacts to it like it's in it's default value.
This is specific to each single setting.

For example.
Enable Bloom Effect - r_bloom is 'on' or 'true' by default.
If this data variable is empty, or set to false it will be 'enabled'

Another Example is Heat Shimmer r_heatshimmer this variable is false or empty by defualt.
When the render engine checks this variable if it's empty or false it does NOT render heat shimmer in this case.

So as you see each of these variables has different 'default' states that the engine checks.
These 'default states may be coded to the actual checkboxes or sliders with the UI, or coded someplace else, but
the end results are the same.

So the r_performance variable is basically totally uninportant to your parser and it can be ignored.
Choosing one of the Performance Prfoiles basically does the exact same thing as you wold do if you went and set each of these values manually.
With the exception of the couple of special cases I mentioned in the previous post.

You can use the grey value for the default value.
Going across the matrix from left to right you will see that the grey value does not change until it turns to 'white' which means that it's not listed in the
eq2.recent.ini file.

So the only time your parser should auto fill the variable is if it doesn't exist in the eq2.recent.ini file.
This auto fill value will be the same regardless of which performance profile BUT, it will vary depending on the specific variable.
Take my previous example.
If Enable Bloom Effect. If the r_bloom variable is not found in the eq2.recent.ini file, than it should be set to 'true'

With the other example
Heat Shimmer. If the r_heatshimmer value is not found in the eq2.recent.ini file than this value should be set to 'false'

The way you are looking at is is the perspective of the performance profiels themselves, when you have to look at the variables.
The performance profile settnings will have no affect on your parsers output file if it's coded to the variables.

Hoepfully that makes it a little more clear.

So in answer to your question.
If you changed from Extreme Performance to Extreme Quality
each individual variable WOULD change in the listing in the eq2.recent.ini would change. the r_performance is basically just a 'button' that changes all
the other values. It doesn't really have any bearing on the render engine itself. (At least far as I can tell) That is why there is a r_performance=7 for 'custom' settings.

The exception to the ones that do not change are the ones I mentioned in the previous post. Those like Graphics Resolution need to be coded to the default value also. This value doesn't change across every profile, The only time it gets listed in the eq2.recent.ini file is if the user changes it to a value other than the defualt value.


As long as you code the default value for each variable if the listing is not found everythin should work fine.

Edit:
Also to note, if you are in game, and you change from High Performance to
High Quality with the drop down box.
The changes take effect in game, but they do not go into the eq2.recent.ini file until you click the 'accept' button. At that point they are saved to the eq2.recent.ini file.

Just went through and adjusted the default values used, but I'm missing some (they didn't have a grey entry, nor were they listed in your corrections post.) I'll list them at the bottom of this post.


With regard to the number of decimal places shown, it does that because I defined the numeric types as doubles. I'll change everything to text—since I won't be doing any mathematical functions on them anyway it doesn't really matter—so that they output the correct number of decimal places no matter what.


Missing default values:

r_anim_update_start
r_fast_layer_min_distance
r_light_bump_max_distance
r_max_lights
r_max_spec_lights
r_min_anim_update_rate
r_min_dir_ambient_intensity
r_particle_priority

Just in case you want to see this is what I came up with, I made a window for the buttons alone, and used the parser on my recent.ini to supply the code for the checkbox and dropped the file into my UI folder and all worked as expected, only thing what kind of go's wrong is you need to move the new buttons out of the top,left corner of the window, but thats easy done.

Had to put the line

<include>eq2ui_mainhud_profilebuttons.xml</include>

in eq2ui_mainhud.xml

P.s or have you guys moved past this stage lol?

Not yet. I want to get the defaults right before I start working on placement and the like. If I can figure out a way to get a graphical front-end working for it I'll probably include an option of which button should be replaced, but truth be told I had originally envisioned this as a single custom file mod.

That is to say, I expected to have the standard preset profiles and 1 user-defineable custom profile. That way I don't have to worry about file/element naming or positioning. :) If we go the route Kosmos seems to be interested in (all profiles replaceable by the user) I'll have to figure out some way to let the parser know which profile it's replacing so that the button shows up in the right place and the element names/references are all assigned correctly.

Surgestion:

Change the parser so that it generates the code for 3 buttons, Have the user rename a copy of their recent.ini to somthing like recent-1.ini log back in game set new values then name that to recent-2.ini etc
Then have the parser ask for what files you want it to make code for recent-1 being button 1 , recent-2 being button 2 etc... If no 3rd file is given the parser will just generate say a high quality profile for the button, and / or other buttons as the case maybe.

Will save you a hell of a lot of work, and the parser is just deveated slightly from its origional intended purpose.

I'd like to avoid asking the user to rename files or anything like that. It introduces another human error point, and I'd like to avoid that. After nearly 7 years of working tech support I'm all too familiar with just how many problems human error can cause. :)

Yups I understand that whilst not working in tech support, I get more than my fair share of phone calls from friends, friends of friends etc lol

Well only other thing for it then is a GUI like the display options in game, But even then yes it could be made to generate the files needed, but how would the average user know what impact their new buttons where going to have on gameplay? as adjusting stuff in game you can see whats changing to an extent.

This would mean a lot of trial and error and I guess most users would soon give up on it..

The only other way would be to capture the values ingame based on the same princaple as the old cheat programs and then that will be against the EULA , Eventhough its only purpose would be to get display values, I am just thinking out loud here.

So to me better to have the user rename a few files lol ,unless there is a easier way to do the above?

What I was thinking was a very simple front end. A selector for eq2_recent.ini location, a dropdown to select which button to generate the XML for, and an OK button. :) That way it knows where to read from and where to write to, everything else is handled internally already. Enter EQ2, set first profile, camp. Parse supplying INI location and specify button 1. Enter EQ2, set second profile, camp. Parse for button 2. Lather, rinse, repeat.

Oh Durr??

Me was off looking at it from too complicated view point again lol

Now that sounds like a much cleaner way to do it, I will look forward to this :)

I agree with this 100% I think it would be easiest alternative.
The user doesn't even have to camp. They can just hit accept and go windowed mode and do it. They would need to restart for the new XML files to get loaded though But they could do all three without having to camp.
THEN camp and restart and would be done.

I'll check for those data variables you are missing.

r_anim_update_start
This one will not be necessary. The reason is that it's always listed in the eq2.recent.ini file.
So the parser would never encounter a time when it's not listed.
But if you do wan't to put one in, just to be safe. I would use 0.050, that is the one
get gets set if you click the 'default' button. On my system When I click the default button.
It resets everything to the High Performance settings but at a lower resolution.
As far as i can tell there is no 'default' r_performance. it's actually High Performance r_performance=4.
This might be specific to my system though. Not sure.

r_fast_layer_min_distance
Again, this is always listed in the eq2.recent.ini file. So the parser won't ever not see it listed.
But if you want to put in a safe value. You can use 25.0


r_light_bump_max_distance
Again, this is always listed in the eq2.recent.ini file. So the parser won't ever not see it listed.
But if you want to put in a safe value. You can use 5.0


r_max_lights
Again, this is always listed in the eq2.recent.ini file. So the parser won't ever not see it listed.
But if you want to put in a safe value. You can use 4.0

r_max_spec_lights
Again, this is always listed in the eq2.recent.ini file. So the parser won't ever not see it listed.
But if you want to put in a safe value. You can use 1.0


r_min_anim_update_rate
Again, this is always listed in the eq2.recent.ini file. So the parser won't ever not see it listed.
But if you want to put in a safe value. You can use 0.100

r_min_dir_ambient_intensity
Again, this is always listed in the eq2.recent.ini file. So the parser won't ever not see it listed.
But if you want to put in a safe value. You can use 0.300

r_particle_priority
Again, this is always listed in the eq2.recent.ini file. So the parser won't ever not see it listed.
But if you want to put in a safe value. You can use 1.0



About the Button Positions.
Before you can set that information in the parser, I suppose I need to finish the seperate window mod
so that the parser can place that information in the XML also?
Along with the final naming convensions for the parent elements and stuff.

I'm working on this now.
But Mondays are busy days so it's going slow.
I'll get that information to you as soon as possible.

Yup. I'll be basing the generated code off whatever you decide to finalize the button as. But all of that is relatively easy to change in the code, I'm more worried about figuring out how to get a GUI front end working.

Well I know a little about gui's with VB but not c++, What program are you using to complie this?

Visual C++ 6. All I really need is a GUI that can run the parser program with 2 command-line arguments: profile to replace, and location of eq2_recent.ini file. The GUI doesn't have to do any sort of logic or error checking or the like. Unfortunately, so far all of the VB examples I've found have been to open documents or URLs, so I haven't quite figured out how passing arguments works. :(

On a happy note, new version of the parser with the correct default values. Button location is still off, but it will be until I get the info from Kosmos on names and positions.

I have that as part of Visual studio 6 , Have only used the vb part of it installing c++ now, if I get anywhere I will let you know, but cant promise anything hehe :)

I apologize for the delay guys. Just trying to do a bit here and there while at work. (shhh..) don't tell the boss.

As far as the font end for the parser.

I might be totally smoking crack.

But.. Can't you just make a batchfile that the user could
double click on that would give it those command line arguments?
Rathter than writing it with C++ Or visual basic?
so the user would only have to execute the batch file rather than the parser.
I don't know if you can have batchfiles ask for input?

Gem, I'm off work now, so I should have a working copy for you in the morning. This is going to be much nicer than the previous start button mod.
Plus it will use stock images, so no extra .dds files.
Plus it should only require one extra line in the startbutton.xml file.

Maybe two, if I decide to do the force show.

Ger,

This should be enough to let you finnish up your parser I think.

I do not plan to move the buttons from these locations.

I may expand the window out to the right a bit to add an additional couple of check boxes later, but the buttons will stay where they are in relation to the top left hand corner of the mod.


I couldn't quite get the hang of the frames, I wanted the frame exactely like the one on the startbutton, but I just couldn't quiet get the thing figured out and was getting sleepy.

Perhaps I'll have another look at it in tomorrow.

At one point I had it show up in the UI Builder, but it wouldn't show up in the game.

I'm not getting that frame style from the UI I think so I'm going to have to specifically set up a style for a frame for that window I believe.
The framestyles appear to be at the root level, and as of yet, I don't think we have figured out how to address those yet?
But as I've said, every little thing with this has been a learning process. I didnt' have to mess with the frames with the earlier revision because they were part of the startbutton. So I'll have to see what I can figure out on that one.
Perhaps when you look at the code you can point me in the right direction.

So, Here it is.

The NEW AND IMPROVED Performance Panel!

Taadahh!!

I only made one modification to the eq2ui_mainhud_startbutton.xml And that was the include statement.
So I or the user can move that include statement anywhere they like and it shouldn't effect the mod at all.
Much, Much nicer. Thanks for the tip.

It will also be very easy for me to add additional functions to the panel.

Plus I didn't change any .dds files nor use any new .dds files. :)


I didn't include the trick to make the window visible.

I just set up a macro in game for it.

/show_window MainHUD.PerformancePanel

I'm going to change the element names from quality/balanced/performance to custom1, custom2, and custom3 since they aren't actually going to be quality, balanced, and performance once the parser gets through with them.

New parser. Accepts 1, 2, or 3 as a command line argument to tell it which profile to replace. If no profile is speficied it'll replace 1. Still needs to be run in the same directory as the eq2_recent.ini, that may change if I can figure out how to create a GUI front end that'll pass the full path for eq2_recent.ini as a command line argument. Included generated eq2ui_custompreset1, 2, and 3 XMLs as well as eq2ui_mainhud_performancepanel.xml (I canged the style name for the checkboxes) and, of course, the parser itself.

Very awesome man! Thanks. I'll see if I can check this out at work today but it might have to wait until I get off this evening.

So did you try out the mod, since it doesn't mess with the startbutton now?
You can just stick that include line on another window if you want.

I'm pretty proud of thise one, I think it looks 1000 times better than things did when I started. LOL

And any help on the framestyle?
I usually keep mine all transparent anyway, but I wanted it to work the same way as other windows for those people that perfer to have the frame and background.
I think it would be safest to just have the user move keep the parser in the UI Custom Directory and move the eq2.recent.ini file over there. Once the parser is done with it, the XML file will already be in the correct place.
It just checkes the current directory that it's in right? Not specficially the C:Program Files/Sony/EverQuest II/ Directory.
?

Ger,

As far as I can tell this works perfectly!

I'll try and write up directions for this and we should be able to put out the release version by tomorrow.

I'm REALLY impressed with the parser, that little tool is so handy to use with this mod. It was a terrific idea! Thanks to Ger and Laffs for all the help and testing, totally couldnt' have done it without you guys or all the helpful information no the forums here.

Can you have the program pause and wait for input.
That way the end user could just double click on it and it would bring up the window and say 'Please Enter 1,2, or 3. Then it would continue with the parsing?
It doesn't really need a GUI so to speak, but just a input prompt would be terrific.

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Andrew>D:\Unzipped\preset_parser-2\preset_parser.exe 1

Beginning XML output...
XML output complete.

C:\Documents and Settings\Andrew>D:\Unzipped\preset_parser-2\preset_parser.exe 2

Beginning XML output...
XML output complete.

C:\Documents and Settings\Andrew>D:\Unzipped\preset_parser-2\preset_parser.exe 3

Beginning XML output...
XML output complete.



Thats the output it gave me but it only updates file 1 , If any of the files dont exist already then it still says,

Beginning XML output...
XML output complete.

But does not create a new file :confused:

*EDIT*
Just double clicking on it will parse the recent.ini and produce file 1 as in the last version

Lafs, I just tested this up here at work.

You MUST have the eq2.recent.ini file in the same directory as the Parser.
If you run the parser without a eq2.recent.in file in the same directory it creates an 'empty' eq2.recent.ini then uses that for all input.

Move your eq2.recent.ini file from EverQuest directory into your parser directory.
Or move the parser into the everquest directory and do the same commands.
it works like a charm.

How do you like the looks of the new window?

Have done it with the recent.ini in the same folder and have also tried it without the recent.ini and yes it does make a blank one, if none exists

/flex

Figured out enough VB to get a basic front-end working. Still trying to get a text box at the bottom of the front-end that reads in the log file that the parser generates, but that's not really required for this thing to go live. Also working on changing the icons of both exes so it's more obvious which to run.

Laffs? Did you figure this out?
Mine worked like a charm up here.
I'll delete it all and try it again to see what my exact steps were.
The first time I didn't have a eq2.recent.ini file in the same directory.
So I downloaded the one you posted on here, and changed it to an .ini file instead of a .txt file.

And ran the program and it generated the eq2ui_custompreset1.xml
then I ran it with the '2' argument and it created the eq2ui.custompreset2.xml file with all the correct information changed inside the file.

Did you run it from a command prompt?

NVM it dont matter now Ger has made a vb gui for it now its working like a charm :)

There's no sanity checking (yet?) on the existance of eq2_recent.ini. Whether or not you run it from a command prompt or via the front end, if you don't specify a valid eq2_recent.ini file (or have one in the same location as preset_parser.exe) you'll end up parsing an empty file. I'll fix that as soon as I figure out how to get VB and VC++ to access the same file at the same time (so that the output from preset_parser.exe ends up in a text box in presets.exe)

Yes, I went back and checked it and it was only working when I double clicked the icon not when I used the command prompt.

Now I get to check out the GUI.

SWEET.

Profile #1 and Profile #2 are being created incomplete.
XML for profile #3 is good.

Styles are not being included at the bottom.

Nice job on the GUI by the way!
Does it require both exe files to work?

Here are the instructions I've created so far.
Please read them and point out any changes or typos I may need to fix.

This will be the 'read.me' file that I include with the package.

Yes, both EXEs need to be in the same place for the parser to work. The front end gathers the profile number and INI location, passes it to the parser, the parser reads in the INI, outputs the XML, and writes a log; the front-end reads the log into the list box at the bottom of the window. (New feature on this version)

The front end now also does basic sanity checking on the INI file location, so we shouldn't end up with blank XMLs anymore. I considered adding similar functionality to the parser itself, but I honestly don't think many people will run it from the command line, so having the front-end check it should be good enough.

Still working on icons. Also still trying to decide where to put the resulting XML file. Right now it gets put wherever the parser is, but I'd like to have it autoinstall in some way. Not entirely sure how I want to handle that.