 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by Alchemic |
| User | Post | ||
Alchemic               Since: 11-17-05 Last post: 6021 days Last view: 5907 days |
| ||
| TCP port 443 is used for HTTP over TLS/SSL, according to the IANA port list.
The ETag header is described in RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19 I'm not quite sure what it's used for from that description, though. |
|||
|
Alchemic Since: 11-17-05 Last post: 6021 days Last view: 5907 days |
| ||
| It works as if the stats were using two bytes, stored in little-endian form - except the six highest bits are used for something else. Specifically:
Byte 4, bit 0: HP max +256 if set Byte 4, bit 1: HP max +512 if set And likewise for the other stats. |
|||
|
Alchemic Since: 11-17-05 Last post: 6021 days Last view: 5907 days |
| ||
Originally posted by Dragonsbrethren Actually, it does - text search for (bh:00), with the parentheses replaced by angle brackets. (If you use this for other hex values, letters MUST be lowercase if present.) (edited by Alchemic on 07-13-06 01:03 AM) |
|||
Alchemic Since: 11-17-05 Last post: 6021 days Last view: 5907 days |
| ||
| I haven't looked into the recompression process yet, but this may be useful in decompressing by hand...
The compressed data has a four byte header: the first byte is always 0x10 (which I think specifies LZ77), and the remaining three are the length of the data when decompressed, stored in little-endian form. This is followed by a repeated pattern of one flag byte and eight "blocks", until "length" bytes have been decompressed. The flag byte is read starting from the most significant bit. If the current bit is 0, an uncompressed block follows, which is just one uncompressed byte. If the current bit is 1, a reference to past data follows. It takes two bytes - here's what it looks like on a bit level: [aaaabbbb bbbbbbbb] The "a" part is related to the number of bytes to copy - add 3 to this value and that's how many bytes will be decompressed out. The "b" part is how far back to go. The byte before this reference to past data is considered 00, the one before that is 01, and so on back. And example may be useful at this point - I'll use the map for "Cleanup", located at 1C7528. [10] - LZ77 indicator? [2E 01 00] - 0x12E, the length of the decompressed data (302 bytes). [08] - The first flag byte. 0x80 bit: 0. Uncompressed byte. [0F] 0x40 bit: 0. Uncompressed byte. [0A] (Note: the length values are compressed like the rest of the data - there's nothing special about them from a compression point of view.) 0x20 bit: 0. Uncompressed byte. [2A] <-- considered "01" back by what follows 0x10 bit: 0. Uncompressed byte. [00] <-- considered "00" back by what follows 0x08 bit: 1. A reference to past data: [10 01]. Copy 1+3 (4) bytes from "01" ago, so [2A 00 2A 00]. 0x04, 0x02 and 0x01 bits: 0. Uncompressed bytes. [28], [00], [87]. [0D] - The next flag byte. And so on out, until the length value is reached. |
|||
|
Alchemic Since: 11-17-05 Last post: 6021 days Last view: 5907 days |
| ||
| I found this archive (copy attached for posterity) on this page; would it happen to be what you are looking for?
(Other features of the system from using those files: [0C XX] is a textual delay for XX units, and [4X] causes the next X bytes to be parsed differently - I think as just plain ASCII.) |
|||
Alchemic Since: 11-17-05 Last post: 6021 days Last view: 5907 days |
| ||
| The words that ETG posted are based on two-byte pointers at 0x7528 - to convert these to the corresponding in-file location, subtract 0x5FF0. The first one corresponds to [60] mathematically (but [60] has a different usage, explained below). The pointers end with 0x761F, which is part of the pointer to [DB].
There's also a dictionary of compressed phrases. The associated two-byte pointers are at 0x7883, and convert to the in-file location the same way as the words. Usage: [60 nn] in text, where 0x7883 + (2*nn) is the pointer. [60 00] may break if used, seeing as its pointer is [00 00]; haven't tried it. The pointers end with 0x78E4, which is part of the pointer to [60 30]. Also, [F2] seems to be a single newline, whereas [F3] is the double-newline used in nearly all of the game's text (an exception: the Fortune Teller's prophecy, which results in five lines of text per window instead of three). Above [E0] seems to be text control codes of various sorts; there seem to be pointers at (0x3A6AA to 0x3A6BB) and (0x3A6C1 to ?) that lead to the code for these, but I haven't looked at them extensively. |
|||
Alchemic Since: 11-17-05 Last post: 6021 days Last view: 5907 days |
| ||
| I don't post particularly often, but I've found something I'd like to post in this topic.
Specifically, some code located at 0x32851 that appears to be related to critical hits: 06/A841: CD 5E 68 CMP $685E 06/A844: 90 0B BCC $A851 If you change that branch to NOPs, both Sargon and your enemies get critical hits on every attack. My other past work consists primarily of finding and documenting data tables, formats and locations. Some samples: Kickle Cubicle level data locations Text dump of Shadowrun (SNES) Pointer listing to the ASM behind the EarthBound control code system |
|||
|
Alchemic Since: 11-17-05 Last post: 6021 days Last view: 5907 days |
| ||
| There's some code located at 0x32851 that appears to be related to critical hits:
06/A841: CD 5E 68 CMP $685E 06/A844: 90 0B BCC $A851 If you change that branch to NOPs, both Sargon and your enemies get critical hits on every attack. |
| Acmlm's Board - I3 Archive - - Posts by Alchemic |
