Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Database/World Building

Development::Database/World Building World Building forum, dedicated to the EQEmu MySQL Database. Post partial/complete databases for spawns, items, etc.

Reply
 
Thread Tools Display Modes
  #1  
Old 07-06-2009, 01:07 PM
Yeormom
Discordant
 
Join Date: Apr 2004
Location: 127.0.0.1
Posts: 402
Default

I played with static objects back in March and had very good luck with them as well. There we're a few instances where models took extra modifications to get working, as they created invisible walls of death.

I definitely don't recommend using the doors table however.
__________________
Yeorwned
Bane of Life [Custom Classic/PvP]
Reply With Quote
  #2  
Old 07-06-2009, 01:25 PM
Shendare
Dragon
 
Join Date: Apr 2009
Location: California
Posts: 814
Default

Yeah, using a different table is definitely the way to go.

What methods were you using to play with static objects?
Reply With Quote
  #3  
Old 07-06-2009, 01:45 PM
Kayen
Developer
 
Join Date: Mar 2009
Location: -
Posts: 228
Default

I have used this method in the past to add objects to zones. Has always worked well, just a pita searching through the files and figuring out what everything is.
Reply With Quote
  #4  
Old 07-06-2009, 02:52 PM
GeorgeS
Forum Guide
 
Join Date: Sep 2003
Location: California
Posts: 1,474
Default

Shendare, this is brilliant!

I am playing with this now, and I'll see what I can do with this.

GeorgeS
__________________
Your source for EQ database tools
Toolshop is open for business


http://www.georgestools.chrsschb.com//
Reply With Quote
  #5  
Old 07-07-2009, 05:03 AM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

Instead of having a 3rd table for objects in zones, couldn't we just add 1 more field to the current zone objects table that would let us toggle if we want it to be sent as a normal object or as a non-clickable door? Then, just adjust the object code to send those type of objects as a door instead with some default values? The zone objects table is already under-utilized due to this limitation, so it would be nice to have the option for this without having to use the misleading doors table for it. For the cases of static objects like this, you should just need the name, the zone, the loc and then set the toggle field to 0 or 1 (whichever means non-clickable) to finalize it and the rest would get ignored. Instead of adding a new field for it, we could even define a certain setting in one of the existing fields to cause it to make the switch. Something like setting the type to 999 should work fine.

I think the reason why that stuff is currently done in the doors table is because that is how they send it on Live. So, we try to duplicate that as close as possible. For the purpose of the packet collectors, it is easiest to handle the DB the same way that Live sends the information. It wouldn't be bad to have another table for it for adding custom stuff in and making it a little easier, but the existing tables already work for that so it isn't really a requirement. If you really wanted to make adding static objects easier, you could make a command that lets you add them in-game by simply typing something like "#objectadd static|door|tradeskill <Object Name>" at the location you want to add the item. Then, after re-zoning, you just adjust the table as needed to make sure it is placed exactly how you wanted it. I am not really apposed to another table for it, though.
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!

Last edited by trevius; 07-07-2009 at 01:18 PM..
Reply With Quote
  #6  
Old 07-07-2009, 09:59 AM
Shendare
Dragon
 
Join Date: Apr 2009
Location: California
Posts: 814
Default

Utilizing the existing objects table with an update to support static objects is a very good idea, and I'd love to try out making an in-game command.

I'll get to work on it.
Reply With Quote
  #7  
Old 07-08-2009, 02:08 AM
Shendare
Dragon
 
Join Date: Apr 2009
Location: California
Posts: 814
Default

Okay, thanks for the sanity check, Trev.

Ignore all of the code posted in the thread up to this point.

After some real trial and error work, I was able to whittle things down to the point that static object loading now works perfectly straight out of the existing object table and with only the single following code addition:

File: zone.cpp, Line 181 - LoadZoneObjects()
Code:
...
    while ((row = mysql_fetch_row(result))) {

    // -- New Code Start

      if (row[9][0] == '0')
      {
        // Type == 0 - Static Object
        const char* shortname = database.GetZoneName(atoi(row[1]), false); // zoneid -> zone_shortname

        if (shortname)
        {
          Door d;
          memset(&d, 0, sizeof(d));

          strncpy(d.zone_name, shortname, sizeof(d.zone_name));
          d.db_id = -1; // Client doesn't care if multiples end up with the same id's
          d.door_id = -1; // For either of these
          d.pos_x = atof(row[2]); // xpos
          d.pos_y = atof(row[3]); // ypos
          d.pos_z = atof(row[4]); // zpos
          d.heading = atof(row[5]); // heading

          strncpy(d.door_name, row[8], sizeof(d.door_name)); // objectname
          // Strip trailing "_ACTORDEF" if present. Client won't accept it for doors.
          int len = strlen(d.door_name);
          if ((len > 9) && (memcmp(&d.door_name[len - 9], "_ACTORDEF", 10) == 0))
          {
            d.door_name[len - 9] = '\0';
          }
          
          memcpy(d.dest_zone, "NONE", 5);
          
          if ((d.size = atoi(row[11])) == 0) // unknown08 = optional size percentage
          {
            d.size = 100;
          }

          switch (d.opentype = atoi(row[12])) // unknown10 = optional request_nonsolid (0 or 1 or experimental number)
          {
            case 0:
              d.opentype = 31;
              break;
            case 1:
              d.opentype = 9;
              break;
          }

          d.incline = atoi(row[13]); // unknown20 = optional model incline value

          Doors* door = new Doors(&d);
          entity_list.AddDoor(door);
        }

        continue;
      }

    // -- New Code End

      Object_Struct data = {0};
      uint32 id = 0;
...
Notes:

- To classify an object record as a static object, set the type to 0. The client doesn't consider 0 a valid object type, so we'll never use it for a valid tradeskill object anyway.

- itemid, charges, and icon are ignored for static objects

- unknown08 serves as the optional Size field, a percentage from 1 to 32767%. Leaving it at 0 renders at normal size (100%).

- unknown10 serves as the optional Request_NonSolid field. If set to 1, the object is rendered as opentype 9, which for some smaller models (e.g., chest1) makes them mostly walk-through. Mileage will vary on a per-model basis.

- unknown20 serves as the optional Incline field, tilting the rendered model along the y axis. Not likely to be used... ever, really, but it's there if someone wants it.

- all other unknown## fields are ignored

I don't know about any limit on the number of static objects the client is willing to take. It lets us use the same door_id value for all of the static objects, so we're not limited by the fact that door_id is a signed 8-bit field, which was my initial concern with adding the objects as doors.

I tried everything I could to get the static objects to send to the client as actual objects, sending all sorts of different values for various fields in the Object struct being sent to the client, but no matter what, the client would always open the player's inventory when the object was clicked on. It's just the way it's wired for objects.

It doesn't seem to matter much, though, since they seem to work quite nicely as nonfunctional doors.

Anyway, give it a try and see if it looks ready for committing, Trev. Seems to work very well now. Thanks again for steering me back to the objects table. It really works out better this way.

Now to work on the in-game command for it.

- Shendare
Reply With Quote
Reply


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

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

Forum Jump

   

All times are GMT -4. The time now is 11:36 AM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3