MAXimum customizations [WIP]

Is there a way to pack two random numbers into one and than unpack them?

e.g. number from 00h to 7Fh + number from 00h to 7Fh
I need to pack 4 numbers like that into 2.
I can't remember if there was some match formula for it.

I have bug: items informations that I am sending are in the same packet as weapon/shield... there is some other space but I do not want to touch it (might be something else e.g. age/mix info or ring etc.). So weapon/shield writes on my items informations and vice versa. Result is that my items are sticking out of my head and all Hopys are turned into mechs without head that are attacking with respawn animation...

So would be nice if there is formula or else I will have to think about some other way (I do not want modify client that much).

0x00 - 0x7F is a single byte... so if you have a DWord, you can pack 4 of them into it via:-

Code:

---

Integer = (byteA << 24) & (byteB << 16) & (byteC << 8) & byteB;

---

Then reverse the process to get them back.

Is that any use?

Spoiler:

last one should be byteD not B

Not really sure about it. If you have DWORD than you splitting it into 4 BYTES

DWORD 0x11051A15

byteA 0x15
byteB 0x1A
byteC 0x05
byteD 0x11


I need something like this.
DWORD 0x11051A15

Code:

---

WORD 0x15 0x05
      +    +
    0x1A 0x11

---

and method to take out 4 original values and turn them back to DWORD.

I have space to send information as WORD but I need DWORD :/


__EDIT__
HM... I will try to mask them in bits.
Your posts are like massage to my brain... forcing me to think ;)

I am sure I wrote something... rollback?
Anyway I found myself good place in packet to send that extra information for now I don't see bugz, but maybe some packet experts can tell me if this spot is always 00 00 00 00.
By bugz I mean:

Spoiler:

http://oi51.tinypic.com/v61xqt.jpg

I really need to do all bloopers I had when I finish this project ;)

84 00 00 00 14 00 47 48 01 00 00 00 9b 09 00 00 74 00 00 00 13 00 47 48 66 2a 00 00 00 00 00 00 01 00 00 00 c0 00 00 00 a4 01 a4 01 00 00 00 00 03 00 02 00 00 24 00 00 64 f0 00 01 00 00 00 00 4c f6 0b 00 53 9b 00 00 61 8a c0 ff 10 54 00 00 00 00 eb 10 00 00 0b 00 8d 01 ff ff 09 00 00 00 00 00 00 00 20 00 00 00 e0 8a 47 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

So what you guys think is it safe?

what are you trying to do? If I remember well, 48470014 is the time packet...

I am sending items information in the "red" DWORD, just before it you have armor, weapon and shield information, also this packet contain informations about your position XYZ and angle (but this is in most of packets), I did not check rest.
This packet is perfect for me, but I am not sure about "place", I can't tell if anything is ever send in those 00 00 00 00.
I spend some time testing and for now players don't act strange, spasming without control or spinning in circles but I am afraid that something might be there, so thats why I am asking. :)
Is anything ever there?
I wonder whats 20 00 00 00 e0 8a 47 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00, but its not important, not as much as place before it.

the 4 bytes before the opcode is the packet size.

XX 00 00 00 14 00 47 48

it means a packet with opcode 0x48470014 and 0xXX size.

That missed the question Sheen. XD

I can't imagine that anything is transmitted which has no use, but I can imagine that some things are transmitted whos' use is depreciated to the point where it is mostly irrelevant.

Can I ask where you are writing this information into the packet?

Because, if you know where the packet is composed before encoding and then transmission, you could either modify the encoding of "wastefully stored" information, (a DWord that only needs a Word (and that happens) or you could possibly add a DWord to the "size" of the packet?

Either way, the only things I have suspected of being a buffer for packet encode and write are the general player stats, (savegame.dat) and I still suspect that of being copied to a new memory block and possibly modified a little before transmission.

Yeah Sheen you missed by 4 bytes, but thanks. Now I know to not touch packet size ;)


bobsobol find this sequence if commands:

Code:

---

MOV EAX,DWORD PTR DS:[ECX+387C]
MOV DX,WORD PTR DS:[ECX+19C]
INC EAX

---

1st function you get from top, I don't know when 2nd (similar) is executed.
I adding my code to the bottom. Packet information are scattered all over memory, its composed into one packet somewhere else, not sure where.

Those packets are not encoded or decoded, this is raw data, only name and packet size is coded since it don't make sense to me, you can simply add "bobsobol like pie" into packet and it will never be encoded, everyone can get that packet and say "I knew it" ;) At least player name is encoded.

The space I am using to send my DWORD is right after weapon and shield information and for me it look like puzzle piece for unfinished addition.


PS. anyone know author of code?

Code:

---

/****************************************************************
FindPattern bullshit. This has been C&P'd so many times that
crediting the author would be a pointless exersize.
 
I added a struct for this ok
****************************************************************/
BOOL DataCompare( PBYTE pbData, PBYTE pbMask, char * szMask ){
        for( ; *szMask; ++szMask, ++pbData, ++pbMask )
                if( *szMask == 'x' && *pbData != *pbMask )
                        return FALSE;
 
        return ( *szMask == NULL );
}

---

Very useful, but wherever I look nobody knows who wrote that.
So probably I will add "written by anonymous".

__EDIT__

PS.2 can we do something to speed up packet sending & receiving, (to 1ms ;))? PT is doing it too slow, can it have FPS speed? ;)

Sending and receiving items information on place that I pointed out is working:

‪MAXimum customization (sending & receiving informations TEST)‬‏ - YouTube

So far I don't see bugs, maybe one but you have to put item on and take another item really really fast (gloves, armlets, boots... armor is too far to do this bug) and it will be as you never send this information that you took off next item (only others will see it), Its hard to reproduce this bug so its hard for me to trace it, for now I will add it to KNOWN BUGS, hopefully it will fix itself ;).
Speed is good to, you would not see difference with naked eye, however PT is really slow with sending packets, maybe there is some way to speed it up, to shorten delay (probably server doing something, on client everything is fast)?

So stay tuned for more ;)

thats really good, when are you going to release a beta ver? is it done by dll or pure asm modifications?

Amazing !
No more words.

Quote:

---

Originally Posted by Vormav

PS.2 can we do something to speed up packet sending & receiving, (to 1ms ;))? PT is doing it too slow, can it have FPS speed? ;)

---

Okay... it took seeing your next post to understand that. You should note that both FPS and packet send is considerably reduced when PT is not they foreground window.

You can remove this limitation (I have done) but it would not be very advisable.

Check calls to GetForgroundWindow(). The routine in question checks the result against the clients main window handle (hWnd) and if they match, it uses Sleep() and (IINM) GetSystemTime() to delay the thread from updating.

This stops PT from hindering the responsiveness of the foreground window. It's not too bad if you've switched to Notepad or Calc, or even MSN... but if you've switched to another PT client, or are even playing Pac-Man while your Personal Shop is waiting to sell up, PT can considerably degrade the performance of the system running at full speed.

In short... I wouldn't worry about what you are seeing, unless that delay is too annoying even when you are using two PCs attached to your server.

At which point... the delay in the server processing your packet and passing the information on the the next player also comes into the equation, and what you do with the client won't make any difference.

I think the server does also take notice of the network speed setting that you can see in the clients launcher... and most of us never bother to set it on the server.

The default is middle-low I think. (one up from the slowest, and therefore two down from the fastest) But if you increase this, you also increase the bandwidth requirement of your server system, and degrade performance in high user situations. :wink:

I always hated that delay, now its gone *_* thank you bob :lol:
I just changed a JE to JMP acctualy :P

Yea... actually, I did "reduce" it, as something "in-between". I think that is in Butchered for some time. For example a 15 or 30fps cap for background window is neither here nor there when you aren't in combat. (I hope you don't MSN while fighting)

It's also enough to give other tasks a time-slice at least that frequently, and that's responsive enough not to see type-lag in Word. :wink:

33ms sleep will give approx 30fps max.