Solved Scrambled ar data

[Kyraie]

Hey, so I’ve been trying to pass data through ar but the data received gets scrambled on the receiving end, not sure what I’m missing. Would love to know what went wrong or a page where I can read up on this and learn it properly.

The data received gets scrambled, but when sending the data it’s in correct order but when receiving the variable data isn’t correct.

I tried with ar.Read()/ar.Write() and ar << and ar >> but it’s the same result.

Sending data

Please login and(or) register to see this awesome content today.

Receiving data

Please login and(or) register to see this awesome content today.

 

[Fliperworld]

What Version of the source code are you using?

You are sending a MONSTERDATA struct/type and reading it as a MonsterInfo .

I do not recommend using:

Please login and(or) register to see this awesome content today.

but instead something like:

Please login and(or) register to see this awesome content today.

A similar process for receiving data needs to be implemented.
The best approach is always use same struct/data type.

Can you also provide these 2 structures/types?

 

[Kyraie]

What Version of the source code are you using?

You are sending a MONSTERDATA struct/type and reading it as a MonsterInfo .

I do not recommend using:

Please login and(or) register to see this awesome content today.

but instead something like:

Please login and(or) register to see this awesome content today.

A similar process for receiving data needs to be implemented.
The best approach is always use same struct/data type.

Can you also provide these 2 structures/types?

The struct is the same on both ends, just the name changed, i added the header file into the receiving part now so the struct is useable there.

Please login and(or) register to see this awesome content today.

So i tried your attempt, same struct name still the data is scrambled anyways.

 

[Fliperworld]

Maybe "m_Snapshot.ar" is being overrride somewhere before is sent to client?
If is just MONSTERDATA vector that is being scrambled this should works:

Please login and(or) register to see this awesome content today.

If any other data is being recivied wrong, probally you need to use a clean CAr.
Did your version has BEFORESENDSOLE and SEND macros defined? I allways use those macros.(with a new CAr).

 

[Kyraie]

I managed to solve it earlier after checking your post, just finished testing. I moved the receiver part directly into DPClient.cpp instead of the WndDungeonUI.cpp, the data is being passed through perfectly, i think the issue was that i was calling a function with the ar data passed into the function and it didn't like that, however it's solved now and i appreciate your help! Thanks a lot!

 

[Kia]

I moved the receiver part directly into DPClient.cpp instead of the WndDungeonUI.cpp, the data is being passed through perfectly, i think the issue was that i was calling a function with the ar data passed into the function and it didn't like that

That shouldn't necessarily be the issue -- it really matters on how the data was being processed because the CAr being passed as a reference, none of the internal cursor / buffer positions would have been changed, so it'd be completely valid to handle within another class.


Some things to mention from reading thread.
Struct names don't matter, all that matters is same type, same position, same packed structure.

And it's fine to write &it->second, sizeof(MONSTERDATA) or sizeof it->second or sizeof decltype(YourMapName)::value_type as in this case it'd all be the proper size.

If you update to C++20 and newer, map's get something called insert_or_assign which is better for when you need to (as the function says).

Also, there's no reason for you to run the find() call within the client when you're receiving the network packet. This is because, you clear the map above, and then if you're getting a duplicate from the server, the server implementation or code is fucked up to let that happen -- shouldn't matter on the client. When you think about the loop it becomes

O(n ⋅ (log n ⋅ 2)) -> simplified -> O(n ⋅ log n)

this is because big oh notation doesn't care for factors, but i think it's good to see just how much the size will affect things.

 

[Kyraie]

That shouldn't necessarily be the issue -- it really matters on how the data was being processed because the CAr being passed as a reference, none of the internal cursor / buffer positions would have been changed, so it'd be completely valid to handle within another class.


Some things to mention from reading thread.
Struct names don't matter, all that matters is same type, same position, same packed structure.

And it's fine to write &it->second, sizeof(MONSTERDATA) or sizeof it->second or sizeof decltype(YourMapName)::value_type as in this case it'd all be the proper size.

If you update to C++20 and newer, map's get something called insert_or_assign which is better for when you need to (as the function says).

Also, there's no reason for you to run the find() call within the client when you're receiving the network packet. This is because, you clear the map above, and then if you're getting a duplicate from the server, the server implementation or code is fucked up to let that happen -- shouldn't matter on the client. When you think about the loop it becomes

O(n ⋅ (log n ⋅ 2)) -> simplified -> O(n ⋅ log n)

this is because big oh notation doesn't care for factors, but i think it's good to see just how much the size will affect things.

I believe there is a function called insert_or_assign, switched over to that function instead. Also removed the find call, clearly didn't read properly when adding it. You're correct in this case, it's unnecessary since the map is cleared before processing the data anyways. Thanks for your input!