#size - minor but noticeable bug

kedobin · #1 03-31-2008, 06:37 PM

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

**AndMetal** · #2 03-31-2008, 07:37 PM

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.

kedobin · #3 03-31-2008, 08:50 PM

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

**trevius** · #4 03-31-2008, 11:08 PM

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.

**AndMetal** · #5 03-31-2008, 11:54 PM

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.

kedobin · #6 04-01-2008, 01:07 AM

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.

kedobin · #7 04-01-2008, 11:25 AM

Quote:

Originally Posted by kedobin

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.

kedobin · #8 04-02-2008, 04:18 PM

Quote:

Originally Posted by kedobin

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.

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