RunUO Community

This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

new Packets 0xF6 0xF7 and related mods

nibbio

Sorceror
new Packets 0xF6 0xF7 and related mods

i've just started today to find and collect infos about new multi system ( and related boat system ).

I've seen that two packets are now used:

0xF6 for smooth movement of boats
0xF7 ( i haven't check it yet )

0xF3 is changed with + 2 bytes in tail, but i don't know their utility ( most of results show that they are sets at 0x0 all the time, except rare cases ).

I've seen from a rapid check in logs ( with spyuo ) that all 0xF3 packets for multi are sent with tiledata option, and not with multidata; the server send all F3 packets for draw boats, tile at tile, maybe for support colorized boat, but i don't know if it's true.

If anyone has infos about multidata option in HS, please post for clarify doubts... thanks

If also anyone has infos about new indexing system for multis, please can post what he knows about it? thanks in advance.
 

Pure Insanity

Sorceror
I know that they allow you to use boat hues with the new expansion, so you're probably right about how that's how hued boats work.
 

Jeff

Lord
Ya i believe its a hue, I had to work with the new file format for Revelation's new multis. Had to modify UO Fiddler to export to the new format. Was not sure what the new value was in the file, so just wrote 0 for the time being. Perhaps I should look into this, would be cool to hue some of the houses on Revelation.
 

nibbio

Sorceror
ok i've just checked 0xF7 Packet.
It is a itemlist for draw a multi correctly:

now i show it's structure with a small boat data example:

byte packetID = 0xF7
word PacketLength (in little endian format ) = 0x87 0x00 -> 0x87 -> 135

( my interpretation is correct because with a new galeon ( one for example ) packet length is 1149 and it's represented by 0x7D 0x04 that combined are 0x47D = 1149)

byte fixed = 0x0
byte list length = 0x5

begin list:
each list entry is a normal F3 packet ( 26 bytes, hs format ):
F3 00 01 02 43 0B 15 53 00 02 00 00 01 00 01 0D AD 0A 91 FB 00 00 00 00 00 00
F3 00 01 00 43 0B 15 52 3E 4B 00 00 01 00 01 0D AD 0A 8D FB 00 00 00 20 00 00
F3 00 01 00 43 0B 15 4B 3E B9 00 00 01 00 01 0D AD 0A 95 FB 00 00 00 00 00 00
F3 00 01 00 43 0B 15 44 3E D5 00 00 01 00 01 0D AB 0A 91 FB 00 00 00 00 00 00
F3 00 01 00 43 0B 15 3C 3E B2 00 00 01 00 01 0D AF 0A 91 FB 00 00 00 00 00 00
end list

the packet is finished.

F3 entry data types:
- 0x02 : single entry of the list is from multidata, itemId took from multidata ( small boat in the example )
- 0x00 : single item ( itemId from tiledata )
- 0x01 : npc, itemId is bodyvalue ( userd for tilerman on galleon, and in new mouse boat system for player )

last question: why osi send this F7 packet AND normal F3 packets for draw tillerman and all others items that are dinamic on the boat?
 

nibbio

Sorceror
0xF6 is the smooth movement packet ( again, small boat example):

byte packet Id = 0xF6
byte packet length = 0x4E
byte fixed = 0x0
dword serial multi
byte delay = 0x04 ( speed of animation )
byte movement direction = 0x02
byte boat direcion = 0x02

short x
short y
byte unknown = 0xff ( alway set 0xff, but i don't know if it has an utility )
sbyte z

byte fixed = 0x0
byte list length = 0x6

each entry is composed by:
int serial
short x
short y
byte unknown ( alway 0xFF but .... again....)
sbyte z

packet ends here....

- Direction flag is the same of the old system
- velocity flag:
0x4 = fast movement ( verbal and mouse )
0x2 = slow movement (mouse)
0x3 = slow movement ( verbal )
0x1 one tile movement ( verbal )

the boat has 3 velocity ( fast 0x4, "normal" 0x3, slow 0x2 ) and one tile movement.
i think that osi uses 0x3 and 0x4 for changing max velocity of galleons, because there is one galleon that is slower than others.

- boat direction: it represent the direction of the boat multi:

0x0 north
0x2 east
0x4 south
0x6 west

it is different from direction because when you move the boat with mouse ( slow / one ) or with vocal command, you can go in different direction; also there aren't multis for mixed directions

that's all for now.
I'll check other things....

if anyone has new infos please post them here...
 

nibbio

Sorceror
new infos:

packet 0xBF subCommand 0x33 is the boat movement request with mouse

it is composed by:

byte id = 0xBF
word length = 12 ( fixed )
word subCommand = 0x33
dword multi_serial
byte movement direction
byte movement direction ( this time is duplicated )
byte velocity

the packet is finished...

pay attention: velocity is not the same value that 0xF6 send to client for animation delay, but it is half value of its.

slow = 0x1, fast = 0x2, stop = 0x0.
 

Ryan

RunUO Founder
Staff member
I'm sticky'ing this thread... this is a great start to sharing information for High Seas :)
 

nibbio

Sorceror
thanks for having highlighted this topic.

But i am the only that provide new infos?

btw i'll check others packets and related multi system.

is in you intention develop new multi system for runuo or ( as you said ) you stop develop at ML stuffs?

HS file format was published in previous topic, i'll check if i can find new infos about unknown bytes.

i'm waiting you answer.
 

Ryan

RunUO Founder
Staff member
RunUO already has support for the new formats in the SVN and we're working on items greater than 0x3FFF as well as concurrently supporting the new and old worlditem packets. In short yes we will be moving forward and completing RunUO up to and including High Seas on the classic client side.

Thanks,
Ryan
 

Thilgon

Sorceror
Ryan;868403 said:
RunUO already has support for the new formats in the SVN and we're working on items greater than 0x3FFF as well as concurrently supporting the new and old worlditem packets. In short yes we will be moving forward and completing RunUO up to and including High Seas on the classic client side.

Thanks,
Ryan

About items higher than 0x3FFF, i would gladly offer my support about it, since on Orb we managed that fine for SA... Moving on to HS is a little more difficult, and except the infos from nibbio, with my knowledge i don't think i can be of much help... Yet, i can simplify the dev team work by telling you all the places i've spotted to place the mods for SA/HS, since (except further mods given by HS to file format) the mods needed to manage extended ItemID are roughly the same...
Only thing i couldn't accomplish was make the mods retrocompatible...
 

Ryan

RunUO Founder
Staff member
Thilgon;868529 said:
About items higher than 0x3FFF, i would gladly offer my support about it, since on Orb we managed that fine for SA... Moving on to HS is a little more difficult, and except the infos from nibbio, with my knowledge i don't think i can be of much help... Yet, i can simplify the dev team work by telling you all the places i've spotted to place the mods for SA/HS, since (except further mods given by HS to file format) the mods needed to manage extended ItemID are roughly the same...
Only thing i couldn't accomplish was make the mods retrocompatible...

We've already done this part... but feel free to share in this thread anything you'd like.

One thing to note... I don't want to be disparaging but I want to be honest... I don't bother with Orb. It's unstable and has never been something that I can count on.

I would suggest as we're essentially reinvigorating RunUO (thanks in part to excitement over High Seas) those kinds of work be contributed here.

Thanks,
Ryan
 

Thilgon

Sorceror
Ryan;868534 said:
We've already done this part... but feel free to share in this thread anything you'd like.

One thing to note... I don't want to be disparaging but I want to be honest... I don't bother with Orb. It's unstable and has never been something that I can count on.

I would suggest as we're essentially reinvigorating RunUO (thanks in part to excitement over High Seas) those kinds of work be contributed here.

Thanks,
Ryan

Actually, the work on SA has gone a bit further and is quite stable, using client 7.0.8.2...
Orbsydia is the home of the project, but you can find the project itself at https://sa-project.googlecode.com/svn/trunk/ (it includes ML by Malganis, however... i never understood why the dev team didn't took advantage of it... oh well, not my problem :) )
Each mod is being commented with region markers (maybe some escaped me, but, almost all are clear)... The core works fine, and seems to be pretty stable (i haven't heard stability issues lately).
SA support is mostly complete, missing basicly only Imbuing.
 

Ryan

RunUO Founder
Staff member
Thilgon;868535 said:
Actually, the work on SA has gone a bit further and is quite stable, using client 7.0.8.2...
Orbsydia is the home of the project, but you can find the project itself at https://sa-project.googlecode.com/svn/trunk/ (it includes ML by Malganis, however... i never understood why the dev team didn't took advantage of it... oh well, not my problem :) )
Each mod is being commented with region markers (maybe some escaped me, but, almost all are clear)... The core works fine, and seems to be pretty stable (i haven't heard stability issues lately).
SA support is mostly complete, missing basicly only Imbuing.

Keep in mind all development we do is tested on Demise, Revelation or Hybrid before it goes into the SVN for RunUO so it's known to be stable with hundreds of players online... local tests or small scale tests are great but we prefer to test in our production shards with large user bases to ensure everything is working...

I'm pretty confident that we'll be pushing some large scale testing over to those shards this weekend and then rolling those changes to the svn after that.
 

Pure Insanity

Sorceror
Think you could post here the kind of changes you're adding to those shards that you'll be testing, when you roll them out? So we have an idea on what to expect in the svn next.
 

Revolved

Wanderer
I am with Ryan...

I have re-registered to have a degree of saftey (hiding!) because I dont want my name known...

I have lost countless hours of information due to the 50 times Orbsydia has gone down/up/down/up.... I will not even bother with that site any more...
 

Jeff

Lord
Revolved;868672 said:
I am with Ryan...

I have re-registered to have a degree of saftey (hiding!) because I dont want my name known...

I have lost countless hours of information due to the 50 times Orbsydia has gone down/up/down/up.... I will not even bother with that site any more...

Not to mention Khabel seems more concerned with redo-ing his site every 10 minutes.
 

Ryan

RunUO Founder
Staff member
Let's not turn this into a thread to bash Orb :)

Let's just keep it to the point of this thread... we're breaking the Code of Conduct!
 

Pure Insanity

Sorceror
Well, to get a bit more on topic...

What is the time range of expected updates for eras that RunUO is currently missing? Could we possibly see support for the tiles in the svn soon...ish? Is development on the svn expected to increase compared to how it's been lately? I'd really like to see some improvements to support ML fully and possibly SA. Although not that important, I'm currently running the SA svn and it's bug free, I haven't had any issues with it at all. Some things I'd like to see in RunUO in the near future are things like the new AI, and other neat new features...the HS boat stuff would be lovely.
 

nibbio

Sorceror
ok, new infos about hs packets:

new world item packet 0xF3:

byte id 0xF3
word 0x01 (fixed)
byte datatype ( 0x00 tiledata, 0x01 bodyvalue, 0x02 multidata )
dword serial
word itemID
byte direction ( or itemId offset, is the same if using tile direction system by osi )
word amount
word amount
word x
word y
sbyte z
byte lightlevel ( use only with tiledata )
word hue
byte flag ( 0x20 show props , 0x80 hidden )
byte 0x00 (fixed)
byte itemfunction

this last byte has two values: 0x00 and 0x01

0x00 is sent when an item is draw on client in normal way ( entered in player screen )
0x01 is sent when an item is draw by other ways:

- the item is dropped by player
- the item is moved by player
- the item is updated (open door, change item amount, change use remains etc )

to summarize, the 0x01 is sent when an existing object in screen is updated ( even if it is in backpack and is dropped by a player)
 

nibbio

Sorceror
new infos, hs, multi system: mouse movement

like i've said in previous post, for multi movement with mouse, client send commands with 0xBF.0x33 and server answer with 0xF6 for smooth movement.

now i show how infos about the entire system works:

premise: this system is only for multi boat system on OSI, house system is not mentioned for now.

1) a boat enter in player's radar range
- server sends 0xF7 packet, for draw boat correctly in radarmap

2) a boat enter in player's screen
- server ( that has previous send 0xF7 ) sends a list of:
0xF3 new item world packet
0xDC PropertyListInfo packet

server sends these two packets for every item that is dynamic on boat:
for old boat for example tillerman, plank, hold
for new boat for example every piece that can be colored, tillerman ( npc ), ropes etc

3) player go on boat
- server resend all packets for draw multi in client screen and radar and resend player props:
- set light level 0x4F
- set personal light level 0x4E
- for every boat in client's radar send 0xF7
- for every boat in client's screen send 0xF3 + 0xDC ( same of point 2 )
- refresh player status ( stats, etc ) 0x34 client, 0xD6 server etc...

4) player request to drive boat with mouse:
- client sends packet 0x06, doubleclick, on tillerman ( for old boat ) on wheel ( for new boat )
- server do some work:
a) add boat to player's mount layer with packet 0x2E with related 0xDC propertylistinfo
b) invalidate player properties, resend all infos to client, force player position:
- set light level 0x4F
- set personal light level 0x4E
- move player in direction of bow of boat with 0x20
- for every boat in client's radar send 0xF7
- for every boat in client's screen send 0xF3 + 0xDC ( same of point 2 )
- force player's animation to "stand" with 0xBF.19.05.FF ( see at the end of this post for more infos )
- refresh player status ( stats, etc ) 0x34 client, 0xD6 server etc...

5) player leave mouse mode:
- client sends 0x06 doubleclick, on tillerman ( for old boat ) on wheel ( for new boat )
- server send remove entity 0xD1

NOTES:
----------------------------------------------------------------------------------------------
the packet 0xBF.19.05.FF is a little different from before:
it was used in past for statue positions, and for new bonded status; in this case is the same as statue position plus 2 bytes in tail:

byte id 0xBF
word size in little endian 0x13 0x00
word command id 0x00 0x19
byte sub command id 0x05
dword serial
byte fixed 0x00
byte fixed 0xFF
byte status 0x00 fixed
word animation 0x00 0x00 fixed
word frame 0x00 0x00 fixed
byte unknown1 0x00 fixed
byte unknown2 0x00 fixed
-----------------------------------------------------------------------------------------------
when 0xF7 is sent to draw boats, it contains a lis of items that IN THAT MOMENT are on boat.
as previous post 0xF7 contains ever:
one multidata entry ( multi base boat )
a list of dynaimic items ( tillerman + hatch + plank etc for old boat, every piece of boat that can be colored plus ropes etc for new boats )
one bodyvalue entry for new boat only ( tillerman npc )

plus of this list, 0xF7 contains every mobile and item that IN THAT MOMENT is on boat, for example another player, horse, item on ground, cannons etc etc.

when one player go on a boat ( case 3 ) the 0xF7 contains also him and his mount if it is on boat.
------------------------------------------------------------------------------------------------
the list of properties that server sends in case 3 and 4 are the similar ( maybe the same ) as when one player go on mount.
the boat indeed is considered as a normal mount when player drives it with mouse.
 
Top