I would like to know if it's possible to get the old nasty statut bar from older version ex.: 2.0.3 with newer client AND if it's possible to disable the toolbar from newer client.

You can hide the menu bar in the options. The old status window you can't get back though unless you use an older client that had it.

I think the last part is not exactly true.

E.g. Razor has an option called "Use Pre-AOS Status Window" which forces the client to
use the old status bar. So there might be a way to tell the client to use gump 0x802 instead of 0x2a6c. Maybe you can find out where it is by using e.g. WinHex2 and compare the memory of two clients running once with razor+"Use Pre-AOS Status Window" and another with that razor option deactivated. Maybe a nice feature for UOCH

A long time ago i copied GUMPID 0x802 to 0x2a6c (gumpart.mul). I don't know if that worked anymore. But you can hook packet 0x11 to cut off useless information for that pre-AOS status bar.

Perhaps Razor does a mix of both in memory. I don't know

I looked into this with old status gumps, and tried that with Razor.

Razor with or without "use PreAOS Status" activated did always show the new status bar. ( seems like this only worked at the time there was the big GRAY status bar, not the latest compact one )

The easiest solution for this one is to replace the latest status bar gump in gumpart.mul and then fix the packet 0x11 with a packethook. ( Not sure that will work though, because that's exactly what Razor does. )

Well I'm not yet really familiar about how to establish packet informations for GetInt's method. So I I'll deal with my situation. Thanks a lot for your help. I will surely take the time to train myself with packets one day .

I had the same feeling when I first saw the v4 status gump. We were happily on the v2 one and it was compact and looked good and we were all used to it. Then along comes this huge thing that made us hate it at first sight and not only that there wasn't anywhere to put it on the desktop!

But then we trimmed off the extra bits of the gump and got used to it. So along came v5 with its much smaller version and we all decided we could cope with it and even have a bit of fun with it - throwing out statcaps and luck and putting in player level and XP in the clilocs.

So in the end I guess we got used to the bigger gump and found room for it. I hope you can cope with it too

Wait a minute. Your telling me you renamed the luck and statcap?

Edwards - the tooltips for mouse hovering over the gump are in the clilocs. That's all I did visually, although I know Luth actually played around with editing the gump itself to make better pictures too. You can do a lot with the status gump!

Tomi wrote:Razor with or without "use PreAOS Status" activated did always show the new status bar. ( seems like this only worked at the time there was the big GRAY status bar, not the latest compact one )

I normally didn't use razor but for me that option worked exept the newest client. Perhaps this needs a razor update. But i admit i just did a quick test with 3 clients:

Razor v1.0.11
Use Pre-AOS Status Window option activated:

Client 6.0.1.1 : shows the old status bar
Client 6.0.5.0 : shows the old status bar
Client 6.0.13.0 : don't show the old status bar

*Edwards wrote:Well I'm not yet really familiar about how to establish packet informations for GetInt's method.

Well in this case it's quite simple. You just need to alter the length of the packet
because it contains less information than Pol sends with the status information flag (5) and set this flag to 1 which means it stops at the weight.

Looks like that. I just leave the GetInt...lines inside for better viewing. You just need the 2 packet.Set...lines.

statusbar.src uopacket.cfg
When you copy the old gump over the new one it should work.

I simply don't know how to read it:

ex.:
How do you determine packet.GetInt32(3) ?


Edited: Nevermind...
http://forums.polserver.com/viewtopic.php?f=7&t=2344

I was obviously unable to understand. I did re-read again and again. I'll make some test this weekend.

I'll try to explain:

Therefor the status info packet 0x11 is send by the server only, you have
to modify/intercept what the server has calculated which is done by
the packethook i've posted above.
The packet is back engineered so you know which byte/s means what as you can
see inside the packet list.

If you put a
print("Statbar Packet calculated by the pol server: " + packet);
as first line inside the exported function Statbar()
you'll see the packet pol has calculated to send to the client.

This packet looks e.g. this way:

11005b00242ad3456477617264730000000000000000000000000000000000000000000000
003c003c000500003c000a000a0009000a000a000a000000000001001200fa0000e1000000
0000000000000000000003000f00000000

Awesome right I'll try to get through step by step the first few bytes:

byte 1: 0x11 the command byte of the packet
byte 2+3: 0x005b the length of the packet (91 bytes)
byte 4-7: 0x00242ad3 the character serial of the char to whom the packet is send
byte 8-37: the char name (in this case Edwards)
byte 38-39: 0x003c the char.hp (60)
byte 40-41: 0x003c the char.maxhp (60)
byte 42: 0x00 no name change allowed
byte 43: 0x05 ML Stattype flag, means there comes more info
byte 44: 0x00 Sex: 0 means male
etc.

Back to your question. What means
var playerserial := packet.GetInt32(3);

Therefor the command byte (identifier) of the packet doesn't count
GetInt32(3) means in clear text:

Go and get me 4 byte (32 bits therefor GetInt32) starting at position
3 of the packet. Remember 1st byte doesnt count, so the list for
getting or setting the values looks this way:

byte 1+2: 0x005b the length of the packet (91 bytes)
byte 3-6: 0x00242ad3 the character serial of the char to whom the packet is send
byte 7-36: the char name (in this case Edwards)
byte 37-38: 0x003c the char.hp (60)
....

which leads to a playerserial value of 2370259 (Cint(0x00242ad3)).

If you want to know the stat type flag, which is only 1 byte long,
you'll type:

var stattypeflag := packet.GetInt8(42);

Go and get me 1 byte (8 bits therefor GetInt8) starting at position
42 of the packet.


Because you don't want to look at these values, you only need
to change the length and the stattype flag:

packet.SetInt16(1, 66); or packet.SetInt16(1, 0x42);
packet.SetInt8(42, 1);

This means set the new length of the packet which is two bytes long to 66
at position 1 of the packet. And the 1 byte flag at position 42 to 1 (pre-AOS).

To confuse you a little bit, you could also use:

packet.SetInt8(2, 66); or packet.SetInt8(2, 0x42);
packet.SetInt8(42, 1);

The new modified packet send to the client now looks in both cases:

11004200242ad3456477617264730000000000000000000000000000000000000000000000
003c003c000100003c000a000a0009000a000a000a0000000000010012

If you understood my explains you should know why both versions work.

PERFECT! I do understand really good now! ...

I barely understand the theory.. The things I do not understand correctly is how you separate each bytes ( you did define byte 1: 0x11 .. how? ) the packet info only tells what each byte does.

After Reflexion: HUm... maybe I got the answer it's a kind of binary code so I guess a byte represent 2 characters... the first 2 charater = byte 1, the third and fourth = byte 2, ... You did represent the hexa number of it like 0x + 11 for byte 1...

I still don't get how to define GetInt..

After Reflexion: I still don't get hoe to define GetInt.. Cannot find any clue.

Headache...

After Another Reflexion:

packet: BYTE[1] Command -- 11
BYTE[2] Length -- 005b --- it doesn't means THE second byte but 2 bytes after 1 ( I did just catch it now... )
BYTE[4] Player Serial --- 00242ad3 -- because it is the next fourth byte after in this case 3 bytes...

Great !

Then the hard part... GetInt32(3); : after 3 bytes you take 32 bits. What is a bits? (Sorry if my english isn't clear ). After reflexion I would say it's every single character... that would be 00242ad3456477617264730000000000. It's not normal you say character serial is 4 to 7. How you get it? No informations anywhere. Packet info only say BYTE[4] Player Serial then BYTE[30] Player Name so I would say 4-29. Ok I'm taking a break... Correct me if I'm wrong somewhere lol...

I barely understand the theory.. The things I do not understand correctly is how you separate each bytes ( you did define byte 1: 0x11 .. how? ) the packet info only tells what each byte does.

You don't need to define the command/identifier byte in this case 0x11 for the status info packet. Pol does that already. You just intercept that packet in this case.
If you want to define it on your own, perhaps in a complete other script, you would do something like:

var packet := CreatePacket(0x11, 66);

But Pol already created that packet. You just want to change it in this case.

HUm... maybe I got the answer it's a kind of binary code so I guess a byte represent 2 characters...

Yes these are all hex numbers. You read it like:
0x11 0x00 0x5b 0x00 0x24 0x2a 0xd3 .....

BYTE[2] Length -- 005b --- it doesn't means THE second byte but 2 bytes after 1 ( I did just catch it now... )

Byte[2] just means that the length value of that packet is 2 bytes long (size) 0x005b. So the 2 in brackets is just the length reserved. This is to avoid more complex descriptions like word and dword
Like Byte[30] for the name, means just that the name is within those 30 bytes. If you take
your Name Edwards it uses 7 bytes of those 30. The other 23 bytes are zero. These 30 bytes are always reserved for the name. Even if in your case 23 are not used
It's kind of static or reserved. Whatever you like to call it.

Then the hard part... GetInt32(3); : after 3 bytes you take 32 bits. What is a bits?

1 byte is 8 bits. This command is perhaps confusing here. It reads the next 4 bytes on the given position. Could be easier named as GetInt4 if you talk about bytes. But its called GetInt32

GetInt8(position) - reads the next 1 byte from this position on
GetInt16(position) - reads the next 2 bytes from this position on
GetInt32(position) - reads the next 4 bytes from this position on

Example on that:

11 00 5b 00 24 2a d3 45 64......

GetInt8(2) would read 0x5b (91) as result. One byte at position 2 of that packet.
Therefor the packet identifier/command (0x11 here) doesn't count, it's 0x5b.
GetInt8(6) would read 0xd3 as result (211 because its converted to decimal).
GetInt16(3) would read 0x0024 as result (36 because its converted to decimal).
GetInt32(3) would read 0x00242ad3 as result (2370259 because its converted to decimal).

Finallly!
Great thanks Pierce. I can see clear now . I only need to practice it!