Some thoughts on HP packets

[Wiz]

If you've ever played EQlive, you'll know how much of a bitch the HP bars are. They move slowly, update slowly, and in some cases don't update at all.

I was thinking of how much faster EQemu HP bars are, which obviously is related to HP packet sending. Then I thought of why VI would make it so.

The only reasonable conclusion would really be to reduce the lag induced by 30 people meleeing something. If 30 people meleed with 20 delay weapons and 100% haste, the amount of hp packets sent to each one of them would be enormous, and a very probable lag-inducing cause.

So, I'm wondering - is this one of the reasons uberend fights wouldn't work on EQemu? Is there any way to work around it?

[DeletedUser]

Could always put hp updates on a timer....

The packet isnt that big:

/*
** Spawn HP Update
** Length: 12 Bytes
** OpCode: b220
*/
struct SpawnHPUpdate_Struct
{
/*00*/ int16 spawn_id; // Id of spawn to update
/*02*/ int16 shu_unknown1; // ***Placeholder
/*04*/ sint32 cur_hp; // Current hp of spawn
/*08*/ sint32 max_hp; // Maximum hp of spawn
};


12 bytes... your connection (if you were 56k) is 56000 bytes/second.

I highly doubt this is the problem :)

[Wiz]

It's that tiny? Won't be a lag problem at all then, even in the above situation.

Speaking of that, with mob roaming, what exactly is causing the server strain? The amount of NPC's "in movement"?

[DeletedUser]

I think it has to do with them having nice OC3's and we are running off of DSL's, I believe that they may not send all attack packets, they obviousely have smoother npc pathing ( I would believe that would mean they send more packet updates ).

[Wiz]

Yeah... but position updates aren't that much bigger, are they? And animations can't be that bad.

[mByte]

The all add up eventually