[Help] Updating flyff packet (ar.h and ar.cpp) issue

09/26/2022 12:01 Cadenzatb#1
I'm facing the issue in sending a packet that's <vector>
I've noticed that in my ar.h and ar.cpp is an old version
that doesn't contain <vector> type of operator as seen below

Old version of packet operator
Code:
   // insertion operations
    CAr& operator<<(BYTE by);
    CAr& operator<<(WORD w);
    CAr& operator<<(LONG l);
    CAr& operator<<(DWORD dw);
    CAr& operator<<(float f);
    CAr& operator<<(double d);

    CAr& operator<<(int i);
    CAr& operator<<(short w);
    CAr& operator<<(char ch);
    CAr& operator<<(unsigned u);

   // extraction operations
    CAr& operator>>(BYTE& by);
    CAr& operator>>(WORD& w);
    CAr& operator>>(DWORD& dw);
    CAr& operator>>(LONG& l);
    CAr& operator>>(float& f);
    CAr& operator>>(double& d);

    CAr& operator>>(int& i);
    CAr& operator>>(short& w);
    CAr& operator>>(char& ch);
   CAr&operator>>(unsigned&u);
compare to a newer version of many sources they tend to use these kind of operator
Code:
   template<typename T, size_t N>
    CAr & operator<<(const T(&t)[N]);
    template<typename T>
    CAr & operator<<(const T & t);
    template<typename T>
    CAr & operator<<(const std::vector<T> & v);
    template<typename T, typename U>
    CAr & operator<<(const map<T, U> & m);

    template<typename T, size_t N>
    CAr & operator>>(T(&t)[N]);
    template<typename T>
    CAr & operator>>(T & t);
    template<typename T>
    CAr & operator>>(vector<T> & v);
    template<typename T, typename U>
    CAr & operator>>(map<T, U> & m);
If I want to update my ar.h and ar.cpp, can I just replace my old ar.h and ar.cpp with the new one from newer version?
I've tried that already but seem like there's some packet that my client cannot recieve after the update (for example: player cannot recieve buff from BuffPang successfully)

I wonder that maybe if I want to update the packet system. Are there somewhere more in the code that I have to update?


I tried debugging and kind of assume that
the problem might come from SNAPSHOT sending and receiving
not PACKET

Seem like some SNAPSHOT is not corrected as seen in the debugging picture below

[Only registered and activated users can see links. Click Here To Register...]

as you can see the 'hdr' value in the bottom left of the picture is = 65280 which is way too high for SNAPSHOTTYPE_DOAPPLYUSESKIL which normally has the value of = 215 or (WORD)0x00d7

that means some how with the new ar.h and ar.cpp packet is effect and cause the packet to get change from 215 to 65280 along the way before receiving in Neuz.exe client

I'm not sure where should I dig next to find where the packet got changed. Please help.
09/26/2022 18:22 Wanetrain#2
You need to understand how "Snapshots" work.

If something in the snapshot is wrong, you gonna fuck up every snapshot behind.

Example:

Quote:
SNAPSHOTTYPE_EXAMPLE_1
int32_t Value1
int32_t Value2
int32_t Value3
SNAPSHOTTYPE_EXAMPLE_2
int64_t Value1
int64_t Value2
int64_t Value3
If we gonna read that:

Quote:
2 Bytes
4 Bytes
4 Bytes
4 Bytes
-------
2 Bytes
8 Bytes
8 Bytes
8 Bytes
So now if you gonna read it in the first snapshot like that:

Quote:
2 Bytes
4 Bytes
4 Bytes
8 Bytes (Example as int64_t)
-------
6 Bytes
8 Bytes
8 Bytes
Now you already see what happens, the first snapshot should have no real issue except for value3 what might be wrong, we don't care about that at first. The next snapshot would try to fetch the next 2 bytes, what is a broken value1, that result in a kinda shitty number.

You maybe know what i wanna tell you by now. :)