Packet Builder?

[U2_Caparzo]

Hi everyone.

I just want to ask you if the efficiency of the Packet builder is something that you have to worry, or it doesn't make any big diference, it's because i dk if i should give it a try(try to build one by my own) or take it from an existing source.

thanks in advance

[I don't have a username]

Data-structs and pointers is the way to go.

[KraHen]

Originally Posted by I don't have a username

Data-structs and pointers is the way to go.

Serialization anyone?

[InfamousNoone]

Serialization usually impedes too much on performance for me to say I'd ever use it. If it's in a case where how fast it perms isn't significant (i.e. loading settings from a file) I'd advocate the use of serialization (in this case XML serialization because the XML-file format is extremely easy to edit).

Structures (with pointers) are nice and all (hell I use to abuse them all the time back a few years ago; just look at CSV2) however, they're not maintainable.

What I mean by that is writing code targeted at various versions of something requires the ability to be changed very easily with little to no effort. For example, say a parameter exists a new version of Conquer, but doesn't on an older version? In terms of a data structure if the user were to ever assign to this instance-member updating the code to the suitable version would become quite tedious. The second problem with this method is that it does not account for dynamic packets with variance in length (such as chat packets, synchoro/userattr packets, etc.)

Today, I utilize a method similar to that of a stream (essentially, a packet builder). You can compare the functions I use to that of BinaryWriter and BinaryReader, but obviously my implementation varies. I would not advocate the use of MemoryStream's with packets either if you thought that's where I was going.

[KraHen]

I suppose you`re talking about the writer that overloads the > operator. I became a big fan of that (not just for packet building, operators rule), cheers.

[pro4never]

Originally Posted by InfamousNoone

Serialization usually impedes too much on performance for me to say I'd ever use it. If it's in a case where how fast it perms isn't significant (i.e. loading settings from a file) I'd advocate the use of serialization (in this case XML serialization because the XML-file format is extremely easy to edit).

Structures (with pointers) are nice and all (hell I use to abuse them all the time back a few years ago; just look at CSV2) however, they're not maintainable.

What I mean by that is writing code targeted at various versions of something requires the ability to be changed very easily with little to no effort. For example, say a parameter exists a new version of Conquer, but doesn't on an older version? In terms of a data structure if the user were to ever assign to this instance-member updating the code to the suitable version would become quite tedious. The second problem with this method is that it does not account for dynamic packets with variance in length (such as chat packets, synchoro/userattr packets, etc.)

Today, I utilize a method similar to that of a stream (essentially, a packet builder). You can compare the functions I use to that of BinaryWriter and BinaryReader, but obviously my implementation varies. I would not advocate the use of MemoryStream's with packets either if you thought that's where I was going.

I agree that that maintainability can be an issue but you can definitely write your packets in a way that the maintenance aspect is simpler.

I know dev was using such a system now where he still used pointers for all his packets but the offsets were all related to the offset of the previous value being written. As such you could simply insert a value in the middle of the writer and all future offsets would update.

That combined with the netstringpacker that TQ uses in their official servers makes accounting for variable length data much simpler then it might otherwise be.