The following problem actually exists since a very long time, but I never
realized until now that it may not be a client bug:

We noticed that when you change the color or the model# of a mobile,
then the statbar and paperdoll for this mobile close for all other players
who have currently opened them.

We work quite a bit with color mods, e.g. when players are poisoned
we give them an unhealthy skin color... of course in a situation like this
it's especially important for party members to still have the character's
statbar open, so they can see that he was poisoned.

I analyzed the packets and found out, that on changing the color or
the model#, the POL server sends a 0x1D (RemoveObject) packet
and then a 0x78 (SendAddCharToScene) for this mobile to all other
people. This of course has the same effect as if the mobile was
teleported away and back, and explains why statbar and paperdoll
are closed.
Now I'm wondering, instead of packet 0x78 there also exists a packet
0x77 (Update Player), which seems to be made exactly for cases like
this, and which also contains color and model# as values, so it seems
they can be updated by using this packet. So the question is... is there
some reason that mobiles are completely removed and resent, instead
of using this update packet? If not, then I think this is something that
should be fixed...

Thanks,
Xandros

This is more of a feature request, not a bug. The core works as coded, and designed on that aspect, therefore it is not a bug.

Moving post to feature requests.

Maybe instead of that, try creating your own 0x77 packet in the script and sending it to everyone within 16? tiles.

CWO wrote:Maybe instead of that, try creating your own 0x77 packet in the script and sending it to everyone within 16? tiles.

I really need to change the color/model value of the mobile, because if I
don't, as soon as someone walks out of the screen and comes back, he'll
see the affected mobile in it's old color/model.
The problem is, because of that I would also have to somehow block the
0x1D and 0x78 packets that are sent by the core in this case. And to do
that in a reliable way is nearly impossible, I think.

Xandros

I quote you, this behaviour should be changed, I often change mobs color too and that statbar and paperdoll closing is annoying

The only problem there is, that is the most secure and accurate way of handling this really. And it IS doable via hooks via checking cprop made by the script that changes it, blocking the outbound, then fire a script to create the update packet. That would be a very easy way of doing it script based.

If I remember correctly, there was issues with using the update packet for certain things with the older clients, which is why it was left out intentionally. If you could do some testing to prove me wrong, would take another look at it possibly.

I'll build a script to test the update packet with our current 4.x client.

If it works with newer clients, maybe an option in uoclient.cfg would be
possible, so the core handling of such situations can be improved for
newer clients, just like the already existing EnableFlowControlPackets
option?

I still think a hook might cause problems... let's say I set a cprop to
check this and change the mobiles color, and the core sends the Remove
and AddChar packets related to this change, which are blocked by the
hook. But at the same time some char walks out of or into the screen, and
the core should send a Remove or AddChar packet, which is completely
unrelated to the color change, and needed in this case, but it's blocked by
the hook... this would be a problem.

Xandros

Again, that can be handled in the hook. Hooks are critical, so you can check distance and so forth in the packet and it be real-time.

Ok, I understand, I'll write a hook.

Xandros