 |
| 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 |
|
| | ||
| 0 users currently in SMW Hacking. |
| User | Post |
| Smallhacker Posts: 521/832 |
Finally.  |
| SnifflySquirrel Posts: 42/80 |
You might not be able to tell from the screenshot, but I've found the data that defines the "block trains" used in Roy's and Larry's castles. PC address $195A4 is the start of the "submap" block train data (originally used in Larry's Castle), and $195EF is the start of the "main map" data (originally used in Roy's Castle). The data is stored as a series of bytes, in the format: llll??dd l = length (if this is 1, it will move 1 tile...I'd advise against using 0) d = direction (0 = right, 1 = left, 2 = down, 3 = right) When you jump onto a block train, it automatically moves to the right one tile before beginning to follow the directions defined by the above data. The data is terminated by an FF byte; when the "creating" block of the train reaches this point, it will disappear (after creating a block at that location), and the "eating" block will follow suit when it reaches the same point (after removing the block). One last note: the "eating" block of the train glitches up if there is ever a block other than a blank tile, brown block, or lava surface (not the tileset-specific kind) directly above, below, or to the sides of it. Be sure to design block train paths accordingly. I'm currently working on a way to define block trains on a per-level basis (it shouldn't take too long). |
