Zone Customization - Scenery Objects

[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

[Shendare]

Awesome!

Once the object table based placement goes live, you would be able to migrate your objects out of the doors table with a couple of SQL commands if you wanted.

INSERT INTO object (zoneid, xpos, ypos, zpos, heading, objectname, `type`, unknown08, unknown10, unknown20)
SELECT zoneidnumber, pos_x, pos_y, pos_z, heading, `name`, 0, 1 - ((opentype - 9) / 22), size, incline
FROM doors
INNER JOIN zone on zone.short_name = doors.zone
WHERE doors.opentype IN (9, 31);

Then when you're confident they're all now in objects correctly...

DELETE FROM doors WHERE opentype IN (9, 31);