EQEmulator Forums - #size - minor but noticeable bug

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Development::Bug Reports (https://www.eqemulator.org/forums/forumdisplay.php?f=591)

- - #size - minor but noticeable bug (https://www.eqemulator.org/forums/showthread.php?t=24776)

#size - minor but noticeable bug

Sorry if this is mentioned elsewhere, I couldn't find anything relevant when I searched.
At this point in time, I'm away from my computer that has my emu files, so I can't give specifics on which file versions I'm using, though I'm pretty sure I'm using the binaries included with EQOffline 1.03c, and I have a version of projectEQ's databases that provides data for both Ykesha and PoP.

Anyway, I've noticed that using #size restricts the user to only using integers.
Ex: #size 5 - size becomes 5
#size 100 - size becomes 100
#size 5.5 - size becomes 5

I checked the database, but the size field's datatype is a float. I have some emu source at my emu computer, but haven't looked enough to be able to find where it handles size.

I'm assuming that either the datatype in the source is set to something like int or short, or that the code that processes the size stops at the first non-numeric character (decimal point in this case).

First of all, I always find the CVS Browse feature on Sourceforge.net AWESOME for researching stuff like this. A direct link to the main stuff for the Emu can be found here.

It looks like the data type in the packet is a float.

common/eq_packet_structs.h:

Code:

  199 struct Spawn_Struct {

  200 /*0000*/ uint8 unknown0000;

  201 /*0001*/ uint8  gm;             // 0=no, 1=gm

  202 /*0002*/ uint8 unknown0003;

  203 /*0003*/ int8   aaitle;       // 0=none, 1=general, 2=archtype, 3=class

  204 /*0004*/ uint8 unknown0004;

  205 /*0005*/ uint8  anon;           // 0=normal, 1=anon, 2=roleplay

  206 /*0006*/ uint8  face;                  // Face id for players

  207 /*0007*/ char     name[64];       // Player's Name

  208 /*0071*/ int16  deity;          // Player's Deity

  209 /*0073*/ uint16 unknown0073;

  210 /*0075*/ float    size;           // Model size

Here is the code for the command itself:

zone/command.cpp

Code:

 2273 void command_size(Client *c, const Seperator *sep)

 2274 {

 2275         if (!sep->IsNumber(1))

 2276                 c->Message(0, "Usage: #size [0 - 255]");

 2277         else {

 2278                 float newsize = atof(sep->arg[1]);

 2279                 if (newsize > 255)

 2280                         c->Message(0, "Error: #size: Size can not be greater than 255.");

 2281                 else if (newsize < 0)

 2282                         c->Message(0, "Error: #size: Size can not be less than 0.");

 2283                 else

 2284                         if (c->GetTarget())

 2285                                 c->GetTarget()->ChangeSize(newsize, true);

 2286                         else

 2287                                 c->ChangeSize(newsize, true);

 2288         }

 2289 }

atof() should be converting it from a string to a float, so it looks like the problem is farther down the chain. Unfortunately, I have no idea where ChangeSize() is defined.

I downloaded the source and did some searching. I mention this below, too, but it looks like size gets casted into an int as it's placed as a parameter into SendAppearancePacket().

Found it in mob.h
As taken from mob.cpp:

Code:

 1157 void Mob::ChangeSize(float in_size = 0, bool bNoRestriction) {

 1158         //Neotokyo's Size Code

 1159         if (!bNoRestriction)

 1160         {

 1161                 if (this->IsClient() || this->petid != 0)

 1162                         if (in_size < 3.0)

 1163                                 in_size = 3.0;

 1164 

 1165 

 1166                         if (this->IsClient() || this->petid != 0)

 1167                                 if (in_size > 15.0)

 1168                                         in_size = 15.0;

 1169         }

 1170 

 1171 

 1172         if (in_size < 1.0)

 1173                 in_size = 1.0;

 1174 

 1175         if (in_size > 255.0)

 1176                 in_size = 255.0;

 1177         //End of Neotokyo's Size Code

 1178         this->size = in_size;

 1179         SendAppearancePacket(AT_Size, (int32) in_size);

 1180 }

It looks like it's being casted as an int once it calls SendAppearancePacket.

This also exists in mob.h

Code:

 1117 void Mob::SendAppearancePacket(int32 type, int32 value, bool WholeZone, bool iIgnoreSelf, Client *specific_target) {

 1118         if (!GetID())

 1119                 return;

 1120         EQApplicationPacket* outapp = new EQApplicationPacket(OP_SpawnAppearance, sizeof(SpawnAppearance_Struct));

 1121         SpawnAppearance_Struct* appearance = (SpawnAppearance_Struct*)outapp->pBuffer;

 1122         appearance->spawn_id = this->GetID();

 1123         appearance->type = type;

 1124         appearance->parameter = value;

 1125         if (WholeZone)

 1126                 entity_list.QueueClients(this, outapp, iIgnoreSelf);

 1127         else if(specific_target != NULL)

 1128                 specific_target->QueuePacket(outapp, false, Client::CLIENT_CONNECTED);

 1129         else if (this->IsClient())

 1130                 this->CastToClient()->QueuePacket(outapp, false, Client::CLIENT_CONNECTED);

 1131         safe_delete(outapp);

 1132 }

Following in_size, which turned into value, we go to appearance, which is a spawnappearance_struct, located in common\eq_packet_structs.h

Code:

  445 /*

  446 ** SpawnAppearance_Struct

  447 ** Changes client appearance for all other clients in zone

  448 ** Size: 8 bytes

  449 ** Used in: OP_SpawnAppearance

  450 **

  451 */

  452 struct SpawnAppearance_Struct

  453 {

  454 /*0000*/ uint16 spawn_id;          // ID of the spawn

  455 /*0002*/ uint16 type;              // Values associated with the type

  456 /*0004*/ uint32 parameter;         // Type of data sent

  457 /*0008*/

  458 };

Lastly, though it doesn't look like it would be involved, the mentioned OP_SpawnAppearance occurs in common\eq_opcodes.h, where it defines opcodes for zone.exe's login sequence.

Code:

#define LiveOP_SpawnAppearance 0x012F // Sets spawnid/animation/equipment

Not to derail this thread, but I am curious why you would want to adjust size in more increments than normal integers? Unless mobs are standing shoulder to shoulder, you would probably not be able to notice anymore difference than the current available size options.

If you had mob size 1 standing next to 2 and 2 standing next to 3 and so on, after about 10, the difference is barely noticeable.

The only reason I can think you might even want this would be if you wanted to go smaller than 1.

It seems to me that setting this would mean slightly more work for the server. Not much, but probably not worth it to most people.

Also, I don't think that this could be considered a bug. Unless there is #size works differently in EQOffline than it does in the normal eqemu code. This is a pretty standard feature that duplicates how it worked on eqlive.

Maybe I am misreading your post.

I believe the issue is more or less that, when a mob is spawned from the DB, it uses a float value for the size, but it doesn't when you manually change the size using #size. It should really be one way or the other. I think kedobin and myself are of the opinion that both should be floats.

The thing that I'm noticing is that the SpawnAppearance_Struct uses an integer instead of a float because I assume it is multipurpose (hence the type field). Because that's the structure of the packet that's sent to the client, it looks like there's going to be a limitation with the client.

I agree that it's not a big deal - that's why I consider it a minor bug. I'm not looking to make something size 3.141529 - I'm merely wanting to have increments in tenths - any smaller may be overkill.
I consider it noticeable because if I remember correctly, in EQLive there is more variation in size among the player races. Right now I either feel like a giant, or a midget in the emu at times.

I successfully changed and compiled the code so that it refers to the data as float rather than int or uint32. However, in practice this actually 1: makes the target disappear; 2: if it's a player, he/she cannot move (acts as if rooted). Looks like there may be more to it than it first appears.

Quote:

Originally Posted by kedobin (Post 145742)

I consider it noticeable because if I remember correctly, in EQLive there is more variation in size among the player races. Right now I either feel like a giant, or a midget in the emu at times.

Just thought I'd comment on this. After I gave up on this last night and started playing, I discovered why I felt sizes weren't right after taking a Vah Shir into Shadeweaver's Thicket. It turns out that either player races are too small, or NPCs are too big, as my Vah Shir was only about shoulder-height to the Vah Shir NPCs.

Quote:

Originally Posted by kedobin (Post 145757)

This is beginning to go off-topic, but just correcting my correction... *sigh*
The missized characters are the bots. Standard npc sizes and standard player sizes match, but at least some, if not all, of the bots are missized (not fully tested, but I'm assuming all are too small).

Returning to the original topic, a quick summary on #size treating input as integers...
Yes, datatypes in the database for size are float.
Yes, datatypes in the code for size begin as float, but are cast into int.
No, it doesn't look so straightforward that you could merely change the datatypes into float and be done with it - after some changes I made, using the #size command in this setting results in the target disappearing and being unable to move, though it still exists and can be targeted. It's almost as if the #sized target is both invisible and rooted.
No, I don't have much time to look into it, though if it gets on my nerves again someday, I might see what else I can try and break while trying to fix it :smile: