Emu Admin Tool

[Hardarac]

Hey Guys n Gals

Is thr anyone working on a new admin tool?

I heard that Leynu was wanting to not do it cos of RL issues.

Has anyone else taken up the batton? For those of us who are not Db fiends it would be a great boon.

Marv

[strychn]

i have a db tool in the works which i've written 95% from scratch(little pieces "borrowed" from wc's admin tool). no eta on release, it's coming along though. just need to find more time to work on it. it "should" have all the features of wcs tool, faster, plus have a really kewl script builder

[Xectia]

not rushing you but.... any news on yours or any admin tool?


-Xectia

[strychn]

having great trouble finding time to work on emu related stuff.
my emu tools are about 45% complete :(
so far it's very functional for a number of things, but has a lot of bugs, is incomplete, and likes to do weird stuff when you turn your head away(you'd never see them though, as you're not looking).
trying to get it going. i plan on including a script builder, and emu control panel(manage zone servers, world server, login server, loginserver.ini, db.ini, etc.), the npc editor automatically creates entries in the spawn table if told to, and a number of other things.
when i DO release it, i will release the source with it. it is written using delphi 6 so...sorry for you vc buffs, and .net addicts.
(pssstt.. .net sucks)

[Windcatcher]

Just to let you all know I'm not dead

I've got the tool talking to the 0.3.0 DB, but with all of the new item fields I'm trying to create a Delphi component that is a combo box with a "shared" list that it doesn't own. The reason is that it will take way too long to update all the lists for all the item drop-downs, so I'm trying to make a component that connects to a shared list that I can update only once and have all of the drop-downs simply repaint themselves. It's not easy...I'm also frantically trying to get my weight down for my Florida trip in July, so I'm spending a lot of time at the gym...

WC

[strychn]

that's good to hear. my db tools talk to all the tables, and everything works okish, but needs some work to fix crashes and misc errors. i'm just lacking time to work on it.

[Windcatcher]

Admin tool 2.5 progress:

I know it's taking a long time, but there's a lot of work involved...

I've got my Delphi component 95% complete (it works, it just needs a few cosmetic changes). I call it a TSharedComboBox. I'm considering a non-visual component as well for specifying the common list, but I haven't decided on it yet. I have the component integrated into the tool now, and it's working really well for all the item lists (e.g. tradeskill recipes).

I've made a lot of under-the-hood changes to simplify the code, but I have some more things I want to look at. I have a ton of testing to do still, and I'm about to download the newest version of the emu so I can get the 0.3.1 changes in (right now it talks to the 0.3.0 db). One of the biggest problems is that the item list isn't sorted anymore, and that will likely play hell with the current code. I'll have to test that thoroughly. I have my shared item list automatically sorting the items so that all the drop-downs are nicely manageable, but I have to make sure that this doesn't cause problems elsewhere.

Also, I'm going to TRY to come up with a way that the player profile and item profiles can be specified in a text file or something instead of being hardcoded into the tool, so that when VI changes them in a patch the emu team only has to issue a new text config file. Hopefully that will take a lot of the load off me since the tool won't be as sensitive to patch changes and it will be harder to break.

Windcatcher

[Hmm]

cool glad to hear of great news wind. admin tool is just a kickass tool. hey how about item comat procs?

one small suggestion if possible.. if its not wearable in primary , secondary or range could you make it ignore the damage , delay and range settings? heh sometimes i make a for example earring of haste perma effect shassar speed 12 dmg 40 delay :P

[Baron Sprite]

Don't know if there is a field for it (I'm lazy ) but if you can, can you add a field for damage bonus in there?

[Hmm]

baron damage bonus is decided by skill of weapon, level and offense. not sure about math but if youre lvl 35 it starts with bonus of 1. so far its basically single bonus damage increase per level. but some weapons dont follow the rule. i think its 2h has more bonus...

[Trumpcard]

Hmm... Think it starts earlier than that.. I have a 34th level barbarian warrior, and Im sure he's had a damage bonus on his mithril 2hander since 30 or so... Somewhere around there at least..

[Kaiyodo]

The damage bonus starts at level 28. It's calculated as (Level-25)/3 rounded down. The extra damage bonus for two handed weapons is based completely off the delay of the weapon, there is no magic number in the weapon to change it, therefore no point in putting an option in the admin tool.

If you want to test this, summon a load of 2H weapons with the same delay and check the damage bonus by right clicking them, they'll be the same.

K.

[Baron Sprite]

k I thought it was editable, thanks, (haven't played eq since < luclin )

[Windcatcher]

I was up late last night hacking at the admin tool code, and I'm pretty confident now that I'll be able to have the next version use text files that describe the profile structures instead of having them hard-coded. I've constructed text files for player profile, item profile, and item info (for inventory slots), and I have the read portion working. That is to say, the admin tool is using the original record structure internally, but my code allows it to read from the database using the definitions in the text files and translate the information on a field-by-field basis to its internal structure. I still have to finish the capability of going from the internal structure back to the database (making sure to preserve any "unknown" fields), but it's mostly coded. It's a little bit slower than before, but not all that much (the field list is sorted which allows Delphi to use log(n) binary searches). I can also speed it up in several places, since most of the time the tool only needs the item name, not the entire record.

What all this means is that, if fields move around due to a patch, all that has to change are the text files. The application won't have to be recompiled, unless the change is really major. The application finds fields and structures by name, so it's important not to change the field and structure names in the text files. The text files are very closely based on eq_packet_structs.h, so it would be a real snap for the emu team to update them once they update their .h file. Each text file has lots of info at the top describing the format that's expected. My code even does type-size checking to make sure that fields aren't overwritten, so even if, for example, VI went to a larger or smaller type size for a given field, the app wouldn't break as long as the text file reflected the change. It even supports nested structures (needed to handle inventory slots in the player profile), but I still have to test this. It also supports n-dimensional arrays (Delphi open arrays are *wonderful*). Unions aren't supported in the syntax that C handles them, but they *are* supported (every field definition *must* be preceded by an integer describing the byte offset from the start of the structure).

I don't know if this technology is useful to any other programs, but conceivably it allows general-purpose record translation that makes maintaining software a bit easier since the configuration can be changed without recompiling. There *is* a performance hit, but in areas where performance isn't critical it might be useful.

Windcatcher

[strychn]

wow, that sounds really kewl wc.
i hope you release the source with the tool, i'd like to take a look at it. if the performance loss could be worked out, it sounds interesting(sounds interesting either way, just :p)
heh