Basic Questions & Answers thread NEWBIES: Start here!
Posted 21 May 2011 - 05:43 PM
Do understand that you're sacrificing a lot of power over your designs this way. Cross paths, while not impossible, are much more difficult with only one collision path, and zones like Chemical Plant are dependent on them. I highly suggest you grab these and replace your SonED2 object definitions for Sonic 2 with them. These will give you visuals for path swappers, showing you 0/1 collision path changes and low/high sprite art changes. (Note that while not shown, a mirrored pathswapper will nullify path changes but keep art changes). With this, you can see how each swapper works without having to check each one's properties individually. Follow paths with your finger, and use Q/W/E/Y/U to toggle paths and art settings.
Posted 22 May 2011 - 08:44 PM
Awesome, Thorn, thanks! These made working with swappers a lot less annoying for me, no more trial and error and building and deleting to see what works, lol.
Posted 23 May 2011 - 01:44 PM
The scripting language I'm using is decidedly not the best for this task, mostly because it loads binary files as strings. It can convert them into hex, which basically doubles the size. So I'm not confident in my ability to find my way around the data.
I'm working with Sonic 3 & Knuckles (Yeah, pretty sure I should have started with Sonic 1 or 2... it was the easiest to get to when I started. No sense in changing games after I've gotten into it, right?)
I've been able to track down basic variables all fine and well. I'm a little worried that the address I got for the master level trigger appears to be a byte off from where the guides say it should be, but the number of rings collected is right (I blame the method I'm using for looking at the data).
Where I'm hitting problems is level layout things. I've read the Nemesis guide and the more updated SCHG guide on this several times. I've found what could be the layout header, but I can't make sense of what comes after that.
I don't need anything related to the appearance of things—tracking downs objects, identifying them, and giving their position is the most of it.
Pretty sure this has been done, since level editors exist. Those don't help me much, though.
It looks like one of three things, here. 1, I'm completely lost with how I'm doing this (is layout data even saved in a save state?); 2, the method I'm using to examine the data is screwing with the offsets; 3, I'm just really confused by how level layouts are handled (pointers and different-sized block-mappings all over the place are hard to keep straight with my lack of experience).
I'm kinda hoping it's 3, as in that case I could probably just show my numbers and see if anyone can tell me what I'm doing wrong.
Right now, I'm looking for layout header data at $8000 and $A478. To find where my script put them, I multiply by 2 and convert to decimal. So the indeces my program checks internally are 65536 and 84208. If it helps, the program looks for rings internally at 148786, and it looks like the MLT is at 144624-144625.
(I'm rather confused by how well this scripting language I'm using works with hex. Hopefully it'll let me enter hexadecimal values so I don't have to convert all the time.)
... So... any idea what I'm doing wrong? :-/
Posted 24 May 2011 - 06:49 PM
Posted 27 May 2011 - 03:13 AM
I've been working with the object status table, and am not sure how to identify objects (other than player1 and player2). It sounds like there's a pointer somewhere to entries in those lists (sonic3/knuckles), but is this associated with the object's status in ram? This looks like the easiest way to identify an object.
I notice a lot of objects with dimentions of 0 or 1. I don't know what these could be (I'm working with AIZ at the moment).
Posted 09 June 2011 - 04:17 PM
For the Hill Top Zone, it's at loc_CA92:
I haven't checked it, but I'm pretty sure they are identically for ARZ and MCZ.
Posted 11 June 2011 - 09:18 PM
Would anybody be able to explain how/why this happens in the game? Would be awesome to fix.
Posted 13 June 2011 - 09:52 AM
The first problem I had was when I had to make new mappings. I went and did what Chimpo's guide explained, and when I imported my sprite over it, it actually covered the tiles, and they stayed there. So I had Mighty sitting on this background made of random colors. I learned I could fix this by using edit>tiles>remove pixels of selected tiles, then importing my sprite. I followed the guide, and everything seemed to go well. I ended up with this:
(Excuse the blurriness, currently searching for a better image host)
So I go to the disassembly, and I use the buildsk.exe. But then I get this error:
What the heck is going on? I go to SonMapEd again and find an answer... sort of.
What am I doing wrong? I'm very confused right now. I'm not an experienced hacker, obviously, so any help would be appreciated.
And if this question is complicated enough to warrant its own topic, let me know. I'm trying to learn and I need some help.
EDIT: After messing with SonMapEd a bit, I've found yet another error that popped up when I tried to assemble it.
Posted 15 June 2011 - 08:55 PM
The second error (symbol undefined) happens because SonMapEd overwrites General/Sprites/Map/Sonic pattern load cues.asm and General/Sprites/Map/Map - Sonic.asm and discards the labels that were originally in the file. Moreover, it didn't even load all the PLCs and all the mappings, so when you saved them, it completely discarded the Super Sonic DPLCs and mappings. The issue here is that there are 2 sets of DPLCs and mappings together and some of them share some data, but SonMapEd doesn't support working with that. If you want to continue using SonMapEd, you'll have to make 2 DPLC files and 2 mapping files, one for Sonic and one for Super Sonic.
Posted 18 June 2011 - 09:56 AM
Posted 18 June 2011 - 10:25 AM
You can't put too many numbers after a dc.b
According to your screenshot, right now in your "Sonic pattern load cues.asm" file you have this line:
dc.b 0, $12, 0, $2F, 0, ... and many other numbers separated by commas
You can't have more than 20 of those numbers on each of those lines that start with a dc.b
So you have to split them up by creating another line which starts with dc.b
To do this, you have to open the "Sonic pattern load cues.asm" file in notepad or any other text editor
And you have to turn this:
dc.b 1, 2, 3, 4, 5, 6, 7, 8
dc.b 1, 2, 3, 4
dc.b 5, 6, 7, 8
(of course this is just an example, you don't need to split them up if there are less than 20 numbers)
Since it turns out that the "Sonic pattern load cues.asm" file is written automatically by SonMapEd, you will probably need to perform this operation every time you'll edit said file in SonMapEd (I can't tell since I never used SonMapEd in my life so I'll go by FraGag's words).
I hope this is clear.
Posted 20 June 2011 - 02:04 PM
I imported Sonic's Sonic 3 tiles, mappings etc into SonMapEd from the ROM, and did the same for his Sonic 2 stuff in another SonMapEd window. I've reordered most of the Sonic 3 sprites, but in Sonic 2, the Super Sonic tiles are included with the rest of Sonic's tiles, whereas in Sonic 3 they're seperate location. What's the best way to get the Super Sonic sprites with the rest of the Sonic 3 sprites?
And on top of that, how can I get them to display right in SonMapEd? no matter which pallete, mappings, and loading cues I use, the Super Sonic sprites look garbled.