[Opinion] Do you like how these Packet Structures work?

[bone-you]

Originally Posted by Korvacs

@Bone, actually in my original post i said that it works well for everything except to packets which dont work because of the need for variable sized arrays, and you came back with of course it can be done with dynamic values, so im not being hostile, im just being correct, you cannot do it thats the end of it. You can work around it using constructs which of course can be done, sadly its alot less elegant and requires more processing and cpu time. But that is a work around to something that they should have more sense about when designing the language.

Just being correct? You make it sound like you've searched the internet from 0 to -1 and have come to the conclusion that there is absolutely no way to accomplish said task.

As for constructs, dur. They will never be as "elegant" as a straight struct, but it's at no cost of processing because it has to be done anyway. No matter how you look at it, you're still having to build the packet piece by piece whether you call a construct function to do it for you or do it manually per packet in the app itself (which is totally bad practice and messy). You're doing it anyway, might as well do it in a more efficient manner.

And to "sense", lol. Do I even need to comment on that? You do not know what goes on at the low-level. You use C# explicitly. Unfortunately, as much as C# will wipe your program's ass for it and feed it automatically, it is not the god of all languages and was designed to be a more RAD java+vb+c++ and it maintains many of the same limitations and features. Sure, as said maybe in the future it will be possible, but it's not entirely practical on a .NET coding level. Just to do it they (microsoft) will have to add so many checks and shit for dynamic sizes of structs. All the struct is now, in a managed sense (typedef var[]) is just a pointer to C#. It is exactly the same as C++. Difference is, C# does not expose the pointer sense to you completely and tries to encapsulate it in the struct to make it seem as one, but it still holds the same limitations of a pointer. Hell, you could probably get around it with built in C# functions of doing foreach on the types and finding what is a pointer and copying it to a premade buffer. Now THAT would be highly inefficient processing wise and would be accomplished the same on a .NET level if it was implemented. Your best bet is to know beforehand what you are dealing with and coding it as such. Any time you try to make something dynamic you are almost always sacrificing processing time to make it possible.

[Korvacs]

Originally Posted by ImmuneOne

This method works very well for every auth/game packet I use.

Give your chat packet a try and output the Message with a small string and see what happens.

@Bone, you cannot create a struct with dynamic values in it without the use of a construct, it, cannot, be, done, in, C#.

You seem to be under the impression that the more you continue to throw explanations for various aspects of programing at me, that eventually it will stop being impossible...?

[bone-you]

Originally Posted by Korvacs

Give your chat packet a try and output the Message with a small string and see what happens.

@Bone, you cannot create a struct with dynamic values in it without the use of a construct, it, cannot, be, done, in, C#.

You seem to be under the impression that the more you continue to throw explanations for various aspects of programing at me, that eventually it will stop being impossible...?

You know what? I'm going to say it. Stop being a fucktard. You need to stop, READ, UNDERSTAND, then make a valid reply. I never said it was possible in C# to use a DYNAMIC STRUCT. Please quote where I say it is possible to do that. PLEASE. I WANT TO SEE IT.

All I said was that it WASN'T possible WITHOUT a construct function, but you'd have to either construct it within the packet class, or outside the packet class. Either way you are constructing it so you might as well do it the more efficient way. Is that REALLY so hard to understand? Holy shit.

You need to stop trying to be right about everything. I've have not said anything that is untrue in this post regarding structs and how to use them to make packets, yet you seem to think all my posts are false.

Originally Posted by Korvacs

You seem to be under the impression that the more you continue to throw explanations for various aspects of programing at me, that eventually it will stop being impossible...?

You seem to be under the impression the more times you say "x is not possible" the more my explanation about "y" will eventually be about "x".

[_tao4229_]

Originally Posted by Korvacs

Again, that doesnt work for dynamic length strings, i explored that but what your doing there is assigning the string a fixed length in memory, so if the string is say 4 bytes long, then when you assign the data from the pointer to the struct you read a further 12 bytes into invalid memory, because the packet you assigned only have 4 bytes of data at that location.

When and where do you read into "invalid memory"?

If you assign it a fixed 16 bytes in the struct, those 16 bytes will always be valid, they just wont have any (useful) data beyond the 4 (5 actually) bytes of string data.

[bone-you]

Thanks for the second infraction caused by your actions buddy. You are a true proper mod Korvacs.

[Korvacs]

Originally Posted by _tao4229_

When and where do you read into "invalid memory"?

If you assign it a fixed 16 bytes in the struct, those 16 bytes will always be valid, they just wont have any (useful) data beyond the 4 (5 actually) bytes of string data.

Receive a chat packet, and using a pointer assign it to that chat packet structure like so:

MessagePacket* Packet = (MessagePacket*)Pointer;

If the received chat packet has a message which is less than 16 bytes long, and the over all chat packet is shorter than defined then you will read past the end of the packet and into random memory, you might think that you wont have anything useful beyond it, but that doesnt mean you will receive a nice neat trimmed string you will just continue to read into the memory beyond what was assigned.

Ive tested it at lengths and honestly it doesnt work.

Also if you receive a message which is longer than 16 bytes you will only receive the first 16 bytes because thats all you assigned.

[ImmuneOne]

Again, I have tested this method numerous times.. and I just tried it again. It just works fine, and by the way you weren't talking about receiving a chat packet. It was about serializing one in the first place.

[Korvacs]

Originally Posted by ImmuneOne

Again, I have tested this method numerous times.. and I just tried it again. It just works fine, and by the way you weren't talking about receiving a chat packet. It was about serializing one in the first place.

Well every time ive ever tested it, it doesnt work how you would think, a prime example is the character info packet and the character name and spouse name, if you set it in the way that you do and use a short character name then you receive 16 bytes, not the 7 bytes you were expecting for the name.

I was talking about receiving...thought that was obvious from my whole discussion about using a pointer to assign the struct?

[_tao4229_]

Originally Posted by Korvacs

Receive a chat packet, and using a pointer assign it to that chat packet structure like so:

MessagePacket* Packet = (MessagePacket*)Pointer;

If the received chat packet has a message which is less than 16 bytes long, and the over all chat packet is shorter than defined then you will read past the end of the packet and into random memory, you might think that you wont have anything useful beyond it, but that doesnt mean you will receive a nice neat trimmed string you will just continue to read into the memory beyond what was assigned.

Ive tested it at lengths and honestly it doesnt work.

Also if you receive a message which is longer than 16 bytes you will only receive the first 16 bytes because thats all you assigned.

That line of code doesn't read any memory at all. It just assigns one uint into another uint. Unless you're trying to read the 16 fixed bytes then I guess that's bad, but you shouldn't be. You should only read as far as the length you get.

I don't disagree, just saying.

As for the second statement, if you're using the MessagePacket* you can actually keep reading on past where the structure ends. Fixed strings such as fixed sbyte[16] are just pointers to the location thats fixed.

I don't do my packets like that (except the auth packet, where the username/password are actually fixed length) where they require dynamic strings. Dynamic length strings inside a struct without outside help (assigning to a buffer, etc) aren't possible in C# or C++. You have to go the long way around because they're dynamic, the definition of dynamic prevents it from being in a fixed location such as a struct.

[bone-you]

Originally Posted by _tao4229_

That line of code doesn't read any memory at all. It just assigns one uint into another uint. Unless you're trying to read the 16 fixed bytes then I guess that's bad, but you shouldn't be. You should only read as far as the length you get.

I don't disagree, just saying.

As for the second statement, if you're using the MessagePacket* you can actually keep reading on past where the structure ends. Fixed strings such as fixed sbyte[16] are just pointers to the location thats fixed.

I don't do my packets like that (except the auth packet, where the username/password are actually fixed length) where they require dynamic strings. Dynamic length strings inside a struct without outside help (assigning to a buffer, etc) aren't possible in C# or C++. You have to go the long way around because they're dynamic, the definition of dynamic prevents it from being in a fixed location such as a struct.

Careful. You're disagreeing with Korvacs. Infraction imminent.

Funny how that was all my explanations were about, how it was impossible without a construct function. Is Korvacs going to say you're wrong too? Or will he agree with you because you're not me?

[_tao4229_]

Originally Posted by bone-you

Careful. You're disagreeing with Korvacs. Infraction imminent.

Funny how that was all my explanations were about, how it was impossible without a construct function. Is Korvacs going to say you're wrong too? Or will he agree with you because you're not me?

I've been banned 3 times already for disagreeing with the admins (not mods, Lowfyr and his crew). I could care less if I get banned again/IP banned.

[bone-you]

Originally Posted by _tao4229_

I've been banned 3 times already for disagreeing with the admins (not mods, Lowfyr and his crew). I could care less if I get banned again/IP banned.

It's just funny that he HAS to be correct in each of his posts and you're always wrong no matter how you explain the correct way. I think every single one of my posts said exactly what you just said but my posts were all wrong.

I'm at a total loss as to what to say really lol.

[_Emme_]

Originally Posted by Korvacs
If you don't know what your talking about, then stop talking.

Btw, Jack, Immune's piece of code works

[Basser]

Do you guys realize you have wasted my thread?
Not that I care, this discussion is sort of funny.
On one hand, Korvacs is right, I clearly understood he was talking about reading into memory, not writing?
On the other hand, I think all of you are making a pointless discussion worse and worse, cmon people, all of you look like me now.

So either you pick all of you are correct, or all of you are wrong.

The big winner is Tao anyway, as he only pointed to facts.

EDIT:
Besides, I don't want to pick sides, but Korvacs, if you just explained wdf you were trying to say correctly, you would've been right.

[Korvacs]

Originally Posted by ImmuneOne

Again, I have tested this method numerous times.. and I just tried it again. It just works fine, and by the way you weren't talking about receiving a chat packet. It was about serializing one in the first place.

Just decided to have a go with your packet and this:

MessagePacket* Packet = (MessagePacket*)Pointer;

Does not compile, go figure.

So i went ahead and modified it so that it would atleast compile using fixed sbyte buffers:

    [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)]
    public unsafe struct MessagePacket
    {
        public ushort Lenght;
        public ushort Type;//0-4
        public uint Msg_Color;//4-8
        public uint Msg_Type;//8-12
        public uint Msg_ID;//12-16
        public ulong Unknown;//16-24
        public byte String_Count;//24-25
        public byte String_From_Length;//25-26
        public fixed sbyte String_From[16];//26-27 + pos
        public byte String_To_Length;//27 + pos - 28 + pos
        public fixed sbyte String_To[16];//28 + pos - 29 + pos
        public byte Blank;//29 + pos - 30 + pos
        public byte String_Message_Length;//30 + pos - 31 + pos        
        public fixed sbyte String_Message[16];//31 + pos - 32 + pos
    }

And then i sent a chat packet and used this method to demonstrate the issues with it, its not exactly clean but its a valid way of doing it:

                        MessagePacket* Packet = (MessagePacket*)Pointer;

                        Console.WriteLine("[ChatPacket] From {0} To {1} : {2}", new string(Packet->String_From), new string(Packet->String_To), new string(Packet->String_Message));

And this is the outcome:



Now honestly, i dont pretend to be an expert, but that doesnt work does it. As far as i can tell theres nothing especially wrong with my implementation of it unless someone else can suggest a more appropriate method?