Doors for Newer Zones
 

I am trying to add some doors to Dreadspire and I was wondering if anyone could tell me where to pull the door names from. I notice that PEQ has something like 700+ door names and I was wondering if those were attained from packet collecting, or if the door names could be found from the EQG files or something somehow.

I tried setting all of the ones currently in PEQ (from the list of doors in the wiki), but I was only able to find 3 or 4 that actually worked in Dreadspire and they all seemed like Global objects like the message board, a crate, and the PoK scroll. I am sure there are at least 3 or 4 doors that must be custom loaded to Dreadspire from somewhere. I just need to find their names so I can start adding them.

If anyone knows how to do this, I will gladly post the SQL needed to add them all into the zone for anyone else who wants to do so. I am pretty sure the doors I am looking for are a bookcase, a wall looking door and maybe 1 or 2 others. Most of them are for secret passageways and they aren't very secret without doors lol! I imagine once I have them, it might take a while for me to get them all in, but I will definitely share the database info once they are all complete.

I am guessing that the best person to answer this question is Cavedude. So, if you see this one, can you please let me know the answer? Or if anyone else knows where to pull these names from, it would be appreciated. Thanks!

For reference, I figured I would post links to the door related Wiki pages. So, anyone who finds this post in the future can easily get most of the door related information they might be looking for. Here are the links:

Door Table Schema wiki page:

http://www.eqemulator.net/wiki/wikka...uDBSchemadoors

Door List from PEQ wiki page:

http://www.eqemulator.net/wiki/wikka...=DoorsNameList

Doors come from packet collects. Looking through my files, I don't have any logs for Dreadspire at all. Now the problem of course is we don't have a packet collector that works with Live that can export to a format that eqextractor can use (that's the tool used to extract door data) Worse yet, eqextractor wouldn't work with Live collects anyway, as it also would need to be updated :(

If anybody feels brave and wants to try to update both the packet collector and eqextractor (so that it can extract door/object/etc data AND export to EQBuilder) I would forever be in your debt, and would spend the summer collecting all of the newer zones. The big problem is going to be the spawn opcodes, as they are a royal pain to get.

Woot! I was sure that info had to be in the EQG files somewhere, so I kept trying to figure out how to find the names. Finally, I remembered trying out S3DSpy a while back and seeing object names in there. I installed it and sure enough, it lists all EQG files as well!

When you pull up the list, you can see all of the object names, because they all end in .mod. The naming convention has changed as well and actually seems much better than the old door and object naming system lol.

Here is a Link to GeorgeS emu page where you can find the S3DSpy app in the bottom section there.

http://66.159.225.58/eqemu/eq.html

And here is an example of the new format for doors and other objects. I didn't think it was going to work because the format is much different now. They now have OBJ in front of all object names and they also use underscores as well. Some of the new names are slightly longer than the old names, so the table might need to be adjusted to allow for longer names so it doesn't cut them off. Here is the list I made for Dreadspire:

OBJ_BDRM_LDOOR
OBJ_BDRM_RDOOR
OBJ_ARTIFACTS_DO
OBJ_BEAKER_A
OBJ_CAULDREN_A
OBJ_CENTER_PIECE
OBJ_DINE_LDOOR
OBJ_DINE_RDOOR
OBJ_DOORFACADE
OBJ_HIDDENDOOR
OBJ_LIBRARY_CASE
OBJ_LIBRY_HIDEDO
OBJ_LIBRY_LDOOR
OBJ_LIBRY_RDOOR
OBJ_LIBRY_SWITCH
OBJ_LIBRYSWTCHB
OBJ_MAINCASTLE_D
OBJ_MNGBOOKS
OBJ_RESEARCH_DOO
OBJ_RESEARCHDOOR
OBJ_SEEING_DOOR
OBJ_STAIRWELL_DO
OBJ_STUDY_BOOKSH
OBJ_STUDY_DOOR
OBJ_TORTURE_DOOR
OBJ_WHITEBLOCK

That worked perfectly.

If you have Navicat, you can copy the following and paste it into your table to view these doors. Just go to the loc near where the doors are:

Field Order:
ID DOORID ZONE NAME POS_Y POS_X POS_Z HEADING OPENTYPE GUILD LOCKPICK KEYITEM TRIGGERDOOR TRIGGERTYPE DOORISOPEN DOOR_PERAM DEST_ZONE DEST_X DEST_Y DEST_Z DEST_HEADING INVERT_STATE INCLINE SIZE BUFFER
You can easily adjust the ID number if needed in case the newer versions of PEQ have higher than that. This will just show an example of the doors. I plan to get them all in the right place as far as where I imagine they should all be. Once I have that done, I will post the table lines for them so everyone can add them as well.

'name' in table 'doors' is VARCHAR(16) - if you increase the size, the bigger name will be accepted in the database, but EqEmu still will not read past this restriction, so the object with exceeding characters will not apply.

Looks like many of the doors for the later expansions (using dreadspire as an example) are more than 16 characters. This may also be the case for other objects as well. But, I am only focusing on doors at this point.

So, I changed my table design to use 32 max characters for the door name field. And, it still wasn't working, so I started looking at the source and saw that it was set to 16 in many places there as well.

Every case that I found 16 set for door names, I changed it. After the following changes, all doors were gone when I started the server, so it must have messed something up lol. Here are the changes I made.

All code changes are marked in red:

zone/doors.cpp:



zone/doors.h:


zone/entity.cpp:


common/dbsharemem.cpp:


common/eq_packet_structs.h:


utils/schema.xml:


zone/zonedump.h:


common/patches/anniversary_structs.h:


common/patches/client62_structs.h:

common/patches/live_structs.h


common/patches/titanium_structs.h

So, I must have made some change that caused the doors to disapear. I will look into this more tomorrow, but if anyone can help out with fixing this, it would be appreciated! I plan to add in a Server Code Submission for this when it is done so it can get added to the source. If anyone else helps, they will get credit of course. I also plan to add this into my source and will post the completed source with these changes and the previous ones I have posted.

Any name you pull out of an .eqg file can be any size - apparently, SOE changed that with the newer eqg format, and is why a lot of things will not work.
It must complicated, as it looks like this is some sort of a hack to enable 16 over what was 10.

Maybe I accidentally changed something else door related in the source while I was making these changes. I will go through them all again tonight and make absolutely sure that nothing else was changed that might have caused it to get messed up.

What I did was search the source directory for all files containing the word "door" and then 1 by 1, I went through each file and looked to see if any of them had door name set to 16. I am pretty sure I got them all, but there is still the possibility I missed something. I don't see why this change would cause doors to disappear. Maybe there is some setting that limits the field to 16 that I am not aware of (maybe like a uint setting or something). I am not a coder, so I would really appreciate if a coder could have a quick look at this.

This might not seem too major, but as far as using zones from later expansions go, we will always be limited with objects until this is fixed. I imagine that the object table will probably need similar name updates as well. I think this is the final thing needed to allow all Titanium zones to be used fully. Sure, you can use them now without doors, but IMO, doors are required in many to complete the zone.

Now that I look at it, maybe my changes in utils/schema.xml are what caused the problem. I don't know much about that file and have never changed it before. Maybe this change is what broke it:

Maybe that still has to be set to 16. I notice that it says Params (parameter I suppose) and not anything about length of the column. Can anyone confirm how that is supposed to be set?

Here are the sections of code that I suspect one of them being the cause of doors disappearing when I change them. I changed all of the ones highlighted in red to 32 as shown in the earlier post. The red values here show the original values for coders to compare. All other changes above were all 16 to begin with.

dbmemshare.cpp: (note that this one was previously set to 10 and not 16 like all of the others. So, this leads me to believe that it either isn't used anymore, or maybe I need to leave it set to 10 for whatever reason...)


doors.cpp:

doors.h:

entity.cpp:

Well, I didn't get any code working for greater than 16 char door names yet, but I did get a new wiki page added. Noting it here since it is door related. I tested every opentype and created a nice reference list with descriptions for anyone wanting to create their own doors. Here is the completed list:

http://www.eqemulator.net/wiki/wikka.php?wakka=OpenType

I still want to get the 16 char limit raised in the source, but I think I may need more help with it.

The size of the door name appears to be set to 16 characters in the packet the server sends to the client, i.e. 16 characters is all the client will accept, in which case it can't be changed.

There are so many items that can be placed, but exist over the 16 character limit - would it be possible to upgrade the portion of source involving packets sent to the client?

I haven't had time to look into this a lot, but I noticed this:

So, if you change name to be name[32] I think it would be a good guess that the unknown0016[16] is actually the other half of the name. So... to keep from breaking the packet struct, you should remove the line that says /*0016*/ char unknown0016[16]; when you change the one above it to /*0000*/ char name[32];

Ahh, worth a shot! So, 2 parts of the packet would essentially become 1 but use the same space so that packet structure doesn't change?

I will see if I can get a compiler working on my windows pc so I can compile the source over and over testing each way without having to impact my players all night lol.

And to Derision; I think this should be adjustable because of the note in the comment below showing that it was previously set to 10 and it is now 16. So, if it can go from 10 to 16, it should be able to go higher.

What S2K said makes alot of sense to me. Basically it sounds like that unknown packet is just set there to fill the gap of the missing 16 chars from the size of the name that should actually be 32. I bet there is actually nothing at all in that space currently and that is why it was able to be adjusted in the past. I wish that note from Daeken was a little clearer lol. I wonder if he means "subtracted the 6 from the unknown below which was previously 22 and added that to the name so it went from 10 to 16".

We'll try this out in a while - tell ya what happened.

Trev, The DEV Kit will let you compile EQEMU. I've set it up on a machine and it works perfectly and you can register the Trial Version of VC++ Express 2005 for Free.

Here's the link. http://www.eqemulator.net/forums/showthread.php?t=25372

Ya, I got the dev kit and have used it and it seemed to work ok I think. I did get alot of warnings about not being able to find certain things from some of the lib files like the zlib, but I didn't get any errors.

I will probably try it out again and see if I can get a windows server just for me to test on maybe tonight. I know it works for me to run on a second server from the same IP, but I am the only one able to connect to it (due to no port forwarding for port 9000 since it is used by my Linux server). Which is perfectly fine for testing purposes.

Maybe I can write a batch file to move all of the required files for the emu to run from the dev kit directory to my normal eqemu directory so I don't have to move them all manually each time. Should be pretty easy and I didn't think about that until now hehe.

this works - I made all original changes posted here by trevius and Scorpious2k, including i removed all the extra "/*0016*/ char unknown0016[16];" i saw while changing the 32's.
So now we have a few fixes that WORK;

-the Azone fix
-the Flee fix
-and this newest door fix

Scorpious2k; are we going to get all this put into the source so everyone can try it out, or am I "pipe dreaming"? I ask you because it seems you're the "last Mohican" to these forums :)

BTW THANK YOU Scorpious2k and trevius!!!

Get me a concise list of the changes and I will get them in.

This was all the work of Trevius, he deserves all the thanks.

Woot, thanks for testing it Angelox! I wasn't able to get to it last night due to some other stuff I was working on with getting ready to leave for vacation tomorrow.

And even though I started the work on it, it certain couldn't have been completed without the catch from S2K! So, I certainly don't deserve all of the credit lol. Nice catch! Once you mentioned it, it made perfect sense that those 16 chars were there all along, but weren't being used for some reason, so they just stuck a filler in there to fill the gap (probably because they thought it was used for something else that was unknown). Should have been 32 from the start hehe.

I will get the fleeing code added and this doors fix into my next code release probably tonight and post a link in the same thread that I have been posting my unofficial 1110 updates in. This will be version 1110d when I get it done and include all of the prior code as well.

I can also add the azone patch if I can figure that out. Is that patch even used for anything on the server, or is it just a stand-alone utility for making the maps? I am just curious if that helps actually deal with the maps when the server is running or if it is completely separate.

You are more than welcome to review my post linked below and use any of them for the official code 1111 release if you want. I will leave the win32 compile up to the devs if they want to use my source version, mainly because I am a little iffy on how my windows compiles go with the setup I use. The post describes everything that has been added to the code. I have tested everything accept for the IP limiting and it all works and the server has no other bugs so far from any of the code changes.

I am certainly not a coder, but I can definitely add in updates that actual coders have submitted and test them pretty thoroughly since my server gets a decent amount of players relative to most servers (120+ at peak times).

I can't wait to get those doors changes in! I already have all of the <16 char doors placed in Dreadspire and will add the >16 char ones when I get this added. I will post the door table info for Dreadspire when I have it all done so anyone else can use it if they like.

Also, if anyone knows the sql to change the name field in the doors table from 16 char to 32 char, please post it so I can make note of that for anyone using the new 1110d code when I get it done. I always just use Navicat, so I am mysql illiterate lol. Otherwise, I will just explain how to do it in Navicat for anyone that wants to.

I forgot about that, here it is;
Azone patch is for the source, I don't think it compiles under windows - but need to have it there.

Instructions for compiling on for windows.
Make Derision's modifications "http://www.rama.demon.co.uk/azone.patch" to the original azone (Build 1110).
Does any one have the watermap patch? If so please PM it to me.

For Windows Compile, you will have to add files to the project (file.cpp, zon.cpp, ter.cpp, pfs.cpp)

Add to azone.cpp near #include "ter.hpp" (you many have to add the path to the project for zlib)

#ifdef WIN32
#pragma comment(lib, "Ws2_32.lib")
#pragma comment(lib, "zlib.lib")
#endif

Add to pfs.cpp near #include <string.h>
#ifdef WIN32
#include <winsock2.h>
#endif

Change global.hpp, put #ifndef around #include <netinet/in.h>
#ifndef WIN32
#include <netinet/in.h>
#endif

Move some variable definitions from wld.c to wld.h
unsigned short d6size;
char *encstr;
float f1, f2, f3, f4;

Build Azone, this will create Azone.exe (copy this to c:\temp)

Use this SQL to make a batch file, save the csv file to c:\temp\kopy.bat (run in mysql query browser, and save as csv. then delete all double quotes)

select CONCAT(CONCAT('copy \\umEQE\\', short_name),'.EQG c:\\temp') as name from zone union all select CONCAT(CONCAT('copy \\umEQE\\', short_name),'.S3D c:\\temp') as name from zone

make sure you change \\umEQE\\ to the directory of where you installed EQ Titanium (NOTE in mysql \\ means \ )
Save the Visual Basic Script as c:\temp\RunAzone.vbs

make sure the directory c:\temp exists and only has these files (kopy.bat, Azone.exe, RunAzone.vbs)

run kopy.bat (start, run, type "cmd", cd \temp, kopy)
run RunAzone.vbs (double click)
'copy the newly created map files to your server's map directory (you may want to back up first)

I would just move them to the top of the function, but other than that NICE WORK!!!

If you can get it to me in some kind of a package I will move it to live.

And where is this post? Am I missing something?

I believe he was referring to this one: http://www.eqemulator.net/forums/showthread.php?t=25391

Diff/patch files for door fix
 

Scorpious2k, I hope you can use this;

zonedump.h
Titanium_structs.h
schema.xml
Live_structs.h
eq_packet_structs.h
entity.cpp
doors.h
doors.cpp
dbmemshare.cpp

Client62_structs.h
Anniversary_structs.h
This was done against the current official 1110 source
If it's not right, tell me how it needs to look for you

This should all be in version 1111 which I updated last night.

Good work all!

These got left out of the 1111 update;


Titanium_structs.h
Live_structs.h

Client62_structs.h
Anniversary_structs.h

Got it, thanks. Should be there now with a couple of other changes.

Will update in a few minutes.

I still see one more for the door fix that's not changed yet;

LOL, when I put that list together, I did it mainly just by searching for doors and anything set to 16 for the name field. I am not even sure if that schema.xml is still used or what it is used for. But, the doors are definitely working great now, so might not be much reason to change it other than to keep consistency.