#size - minor but noticeable bug

[trevius]

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]

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]

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]

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]

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