Zone Customization - Scenery Objects

[Shendare]

I have made great progress in my personal project of trying to add static scenery objects to customize my zones.

Adding a static scenery object to a zone is very easy once you know how.

Step 1: Know the model name for the object you're adding (look for per-zone object model inventories in an upcoming new version of my EQ Model Inventory program)

Step 2: Add a record to the "doors" table in your EQ database with the following field settings:

id = Unique number for this record
doorid = Unique number within the doors list for this zone
zone = Zone nick
version = Instance version number (0 for default)
name = Model name from Step 1
pos_x/y/z = Location to place object
heading = Direction object faces (0 - 511)
opentype = 9 (makes object non-solid) or 31 (makes object solid)
dest_zone = NONE
size = 100

Everything else = 0

Step 3: Leave and re-enter your zone and see your new object(s)!

Note: If you make changes to the database and the zone is still running in the zone server, you'll have to do a "#zoneshutdown ZoneNick" before zoning back in, to clear the cache, or your changes won't take effect. A hotkey works well.

This technically adds the object to the zone as a door, but opentypes 9 and 31 contain no animation or sound effect, so nothing happens when the user clicks on them. They're just like static scenery objects, except you can place them wherever you want!

Opentype 9 actually makes objects -mostly- non-solid. I tried looking for a fully non-solid opentype, but the partial that 9 gives appears to be the best we can get. Each object will have a few surfaces that are solid, but most become walk-through.

Opentype 31 makes objects fully solid unless the object was specifically designed to be walk-through, which I've mostly seen in chairs.

I plan to make plenty of use of this ability in my own customized server.

Now, if anyone can figure out a way to repop a zone's door list without requiring a zone-out, #zoneshutdown, and zone-in, that'd be way cool.

[Shendare]

If you're eager to see it in action real quick, I've generated a .txt file that lists all of the models available in all of the *_obj.s3d and *.eqg files as of SoF.

http://www.jondjackson.net/eq/emu/fi...lInventory.zip

NOTE 1: If you want to add objects to a zone for use, simply add the model source filename to ZoneNick_assets.txt. For example, to add 'obj_ctent' from 'live_event_objects.eqg' to the zone 'felwithea', create a file in your EQ directory called 'felwithea_assets.txt' containing the line 'live_event_objects.eqg' (omitting the single quotes wherever they're shown here for emphasis).

NOTE 2: Global object models are those in files listed in Resources\GlobalLoad.txt.

NOTE 3: Object names are always in upper case (e.g., IT66, OBJ_CTENT).

NOTE 4: Do NOT use the _assets.txt file to import an actual zone S3D or EQG file! This will load the actual zone geometry into your zone, not the objects! Stick to *_obj.s3d and any EQG files that are not race model sources or zone files.

Example:

1. Create felwithea_assets.txt with the line "live_event_objects.eqg" in it.

2. Add the following record to your doors table:

INSERT INTO doors VALUES (61001, 101, 'felwithea', 0, 'OBJ_CTENT', -5, -5, 0, 256, 31, 0, 0, 0, 0, 0, 0, 0, 0, 'NONE', 0, 0, 0, 0, 0, 0, 0, 150, 0);

3. Zone into felwithea and take a look at your new tent!

Enjoy.

[Shendare]

Of course, you don't have to import any object models to add a customized object to your zone. Just ignore the ZoneNick_assets.txt step and use the model name for an object already inside your zone, such as 'FELBED' in felwithea in the example above.

[Shendare]

Technically, the best thing to do to utilize this availability without cluttering up the doors table with non-door objects would be to create a new table:

CREATE TABLE `static_objects` (
  `id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  `zoneid` INTEGER UNSIGNED NOT NULL DEFAULT 0,
  `version` INTEGER UNSIGNED NOT NULL DEFAULT 0,
  `x` FLOAT NOT NULL DEFAULT 0,
  `y` FLOAT NOT NULL DEFAULT 0,
  `z` FLOAT NOT NULL DEFAULT 0,
  `heading` FLOAT NOT NULL DEFAULT 0,
  `size` SMALLINT UNSIGNED NOT NULL DEFAULT 100,
  `incline` INTEGER NOT NULL DEFAULT 0,
  `model` VARCHAR(32) NOT NULL,
  `solid` TINYINT UNSIGNED NOT NULL DEFAULT 1,
  PRIMARY KEY (`id`),
  INDEX `idx_staticobjects_zoneid`(`zoneid`),
  INDEX `idx_staticobjects_version`(`version`)
)
ENGINE = InnoDB;

Then piggy-back static object loading in the door spawns of the entity_list.

File: zone.h, Line 111 - Class Zone

...
  void LoadZoneDoors(const char* zone, int16 version);
+ void  LoadZoneStaticObjects(int32 zoneid, const char* shortname, int16 version);
  bool LoadZoneObjects();
...

File: zone.cpp, Line 698 - new function Zone::LoadZoneStaticObjects()

void Zone::LoadZoneStaticObjects(int32 zoneid, const char* shortname, int16 version)
{
  if ((!zoneid) || (!shortname))
  {
    return;
  }

  LogFile->write(EQEMuLog::Status, "Loading static objects for %s ...", shortname);
  
  int32 maxdoorid = 1;      // If there aren't any doors for this zone, start with #1
  int32 maxid = 2000000000; // Way out of range of normal use

  char errbuf[MYSQL_ERRMSG_SIZE];
  char query[256];

  MYSQL_RES *result;
  MYSQL_ROW row;
  
  sprintf(query, "SELECT MAX(doorid) FROM doors WHERE zone='%s' AND version=%u", shortname, version);
  if (database.RunQuery(query, strlen(query), errbuf, &result))
  {
    if (row = mysql_fetch_row(result))
    {
      maxdoorid = atoi(row[0]) + 1;
    }
    
    mysql_free_result(result);
  }

  sprintf(query, "SELECT MAX(id) FROM doors");
  if (database.RunQuery(query, strlen(query), errbuf, &result))
  {
    if (row = mysql_fetch_row(result))
    {
      maxid = atoi(row[0]) + 1;
    }
    
    mysql_free_result(result);
  }

  sprintf(query, "SELECT x, y, z, heading, size, incline, model, solid FROM static_objects WHERE zoneid=%d AND version=%d", zoneid, version);
  if (database.RunQuery(query, strlen(query), errbuf, &result))
  {
    Door newdoor;
    Doors* door;
    memset(&newdoor, 0, sizeof(Door));
    int32 r = 0;
    int32 c;

    strncpy(newdoor.zone_name, shortname, 16);
    memcpy(newdoor.dest_zone, "NONE", 5);

    for (r = 0; row = mysql_fetch_row(result); r++)
    {
      c = 0;
      newdoor.db_id = maxid + r;
      newdoor.door_id = maxdoorid + r;
      newdoor.pos_x = atof(row[c++]);
      newdoor.pos_y = atof(row[c++]);
      newdoor.pos_z = atof(row[c++]);
      newdoor.heading = atof(row[c++]);
      newdoor.size = atoi(row[c++]);
      newdoor.incline = atoi(row[c++]);
      strncpy(newdoor.door_name, row[c++], 32);
      switch (newdoor.opentype = atoi(row[c++]))
      {
        case 0:
          newdoor.opentype = 9;
          break;
        case 1:
          newdoor.opentype = 31;
          break;
      }

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

    mysql_free_result(result);
  }
}

File: zone.cpp, Line 954 - Zone::Init()

...
  zone->LoadZoneDoors(zone->GetShortName(), zone->GetInstanceVersion());
+ zone->LoadZoneStaticObjects(zone->GetZoneID(), zone->GetShortName(), zone->GetInstanceVersion());
  zone->LoadBlockedSpells(zone->GetZoneID());
...

And it works!



If you're wondering why I'm sticking it in doors, instead of the zone objects table, it's because I couldn't figure out any way to use the zone objects system that didn't involve an openable tradeskill container or pickable ground spawn item.

Anyway, forget adding records to the doors table. Much better to use this new static_objects table!

[So_1337]

Another stunning customization miracle you've worked up! Bravo! I can definitely see some potential in using this to help build future zones as well, marvelous.

[Yeormom]

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.

[Shendare]

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

What methods were you using to play with static objects?

[Kayen]

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.

[GeorgeS]

Shendare, this is brilliant!

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

GeorgeS

[trevius]

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.

[Shendare]

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.

[Shendare]

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()

...
    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

[trevius]

One thing that might be a possibility would be to see if we can get objects like that to spawn in real-time when they are created. I know for sure that any model can be set on an item and dropped on the ground to simulate a static object. It should just be sending an object packet to do that. With that being the case, we should be able to use a command to place a fake item on the ground where ever we want just by having the command send the packet for it. Now, that alone might not sound too useful, but by using a little trick, we might be able to make good use of it. Since any object would be clickable as you said, we could probably set those objects so when you click them, they disappear. This would allow you to move around adjusting the position of an object until you are at the perfect positioning for it. Then, once you have the perfect position, you add something to the end of the command like "perm" to make the next one get added to the database. Any of the ones added without perm would just be temporary and used only for finding the right positioning. By using the perm option, it would still generate a fake object in the zone like it was previously doing, but this time it would create an actual entry in the database. Instead of having it enter the object into the objects table, it could put them into the doors table. There could even be an option to chose which table you want it to be permanently added to, so you could place tradeskill containers this way. If this idea worked like I think it should, this would make adding/placing doors, tradeskill containers and any static object a piece of cake.

Another nice use for a command like this would be that you could examine each object/door type that a zone has available without having to zone each time to do so. The zoning part is the biggest pain when manually populating zones with objects and doors.

I have never tried it, but it may be possible to spawn a door in real-time without having to zone as well. I don't see why it wouldn't work, but I have just never tried it. The main reason I suggest spawning them as an object is because it is easy to be able to remove them by clicking on them. The client thinks that the object was picked up if it is set correctly. I don't know of any way to remove a door in a zone without having to zone first.

That is something to think about while expanding the possibilities with objects and doors, anyway. I will try to look the code over that you posted, Shendare. Hopefully I can get it added tomorrow night if I have time to check it out and stuff.

[Shendare]

Coding doors and objects as a ground spawn item for moving them around until the user is satisfied with their placement is an intriguing idea.

My first thought had been to be to look into sending the DoorSpawn or ObjectSpawn packets in real-time when using a #door create or #object create command. The command would send the client a message containing the ID of the door/object it created, and the user could use a #door move or #object move command, passing the ID.

However, this hinged on the ability to send a DoorDespawn and ObjectDespawn packet as well, and I haven't looked yet to see if it looks like a DoorDespawn opcode and struct are available, or whether it's simply a toggled switch in the DoorSpawn opcode and struct.

Further investigation is needed, but there's certainly promise.

[ChaosSlayerZ]

I have actualy been playing with this for a while. I mean original Doors table is full of things which not actualy doors. It has tents, barrels etc.
Of course geting them to sit just right was a little bit a pain =)

Here some of my tents and fires in West Karana