bRO maintenance 2012 05 09

[Pawel]

This is great. Thanks.
Keep up the good work.

[SkylorD]

also, to whoever wants it, i made a generator for future updates (sometimes this generator needs to have the keysextract.pl updated)

It's because of the keys are changing ?

If you want, i can post a tutorial for to catch these Keys.

[uPantcho]

also, to whoever wants it, i made a generator for future updates (sometimes this generator needs to have the keysextract.pl updated)

It's because of the keys are changing ?

If you want, i can post a tutorial for to catch these Keys.

is not a problem to update, is just that when it happens there will be a need for an update

im going to put this as complement:

Code: Select all

is not hard to update yourself, if you look into the keysextract.pl there are some comments that should help to understand how it works. the numbers that are printed after the keys are used by the keys.pl when he is checking if the recvpackets.txt lines have the same packet sizes


what i could see was that when the code before the keys change, the recvpackets also changes and so the 2 numbers printed after the keys needs an update.

[SkylorD]

uPantcho, can you please explain this part of script :

($index-$delta) == 788

Where did you find this number ? And how you know... ! ?
=)

the resulting files of this script are svn incompatible because i couldnt remove the carriage returns (\r),

I do not understand. All apparently is perfect.

[uPantcho]

uPantcho, can you please explain this part of script :

($index-$delta) == 788

Where did you find this number ? And how you know... ! ?
=)

the recvpackets are always on the same order, so 788 is the line number 788 (or a little more, depending on the delta)

i just got a working file and saw the lines where the packets were located. the deltas were added as new exe versions were released.

I do not understand. All apparently is perfect.

im not sure if that happens only here but what i see on the resulting file is a DOS formatted text file

that means that on the end of each line you are going to have the carriage return code followed by the new line code (\r\n) while the SVN version has unix format that contains only the new line (\n)

this makes every line a "changed line" and would change the default svn unix format to DOS...

[EternalHarvest]

the recvpackets are always on the same order, so 788 is the line number 788 (or a little more, depending on the delta)

It's fine while it works, but keep in mind that it may change, too.

im not sure if that happens only here but what i see on the resulting file is a DOS formatted text file

that means that on the end of each line you are going to have the carriage return code followed by the new line code (\r\n) while the SVN version has unix format that contains only the new line (\n)

Yeah. And we have a convention that everything should be with Unix line endings.

[Don Delavitto]

the recvpackets are always on the same order, so 788 is the line number 788 (or a little more, depending on the delta)

It's fine while it works, but keep in mind that it may change, too.

How do you find if they change? I saw few changes like one line but its easy to figure out where they go and what they, just comparing the sizes of the packets. What if they do a major change how to find out what they do or where they are?

[uPantcho]

How do you find if they change? I saw few changes like one line but its easy to figure out where they go and what they, just comparing the sizes of the packets. What if they do a major change how to find out what they do or where they are?

when the recvpackets change, the code used to extract the keys will change too. that will make the extractor unable to find the keys (and the deltas used to match the correct lines on the recvpackets) and then the keys.pl is going to generate an error (cause i put a check for every packet size).

if an error is found, the line of the recvpackets where the packetsize didnt match the expected size is going to be printed on the dos screen of keysgenerator.bat