[TheKazeblade]

I'm attempting to edit one of Generations challenge acts in Sonicglvl (#ghz202.ar.00) but for some reason it won't load terrain collision or objects. Typically it asks if I want to load terrain but with this specific stage it doesn't bother. I've attempted in both sonicglvl and libgens-sonicglvl but the results are the same.

Most of the other challenge acts I've attempted to load seem to behave strangely compared to the main modern stages, making me wonder if there's an additional step needed to loading challenge acts. Even so, ghz202 is the only one that behaves like this specifically. I'd be grateful for any advice

[Strike]

Does anyone know where I can find Chip's data in Unleashed? He doesn't have his own AR file.

[BoardAvenger]

This is kind of a crap first post but it's irritating me that I don't have the knowhow to work it out myself...

I've written a customised build of Sonic 3 Complete to a couple of M27C160 EEPROMs to solder into a cartridge once a suitable one arrives but one of the EEPROMs appears to be faulty in a very specific and minute way: it is refusing to allow one single nibble to be written properly, perhaps because it isn't erasing it properly, which means that instead of getting a D0 at that offset I'm getting a D4. Specifically, if I read the entire rom back off the EEPROM, reassemble it and then reverse the byte-swapping process, this erroneous D4 sits at offset $380278.

So here's my question: what does the D0 byte at offset $380278 in a customised Sonic 3 Complete ROM actually do?

I'd simply rewrite it to a fresh EEPROM if I could, but I don't have one that isn't knackered and they're not the sort of thing I can simply walk into a shop and buy (only got 2 left, this is one of them and the other flat out refuses to even write to a different address). What I figure is, this single byte being written as a D4 rather than a D0 might not make a damn bit of difference to me playing the game, given that there's a whole bunch of code in Sonic 3 Complete that I will never, ever use. For instance, if it turned out to be part of one of the Sonic & Knuckles Collection music files, that would be totally immaterial because I don't use them. Or it could be part of the level layout for the original release version of Flying Battery, which I don't play because I prefer the "prototype". You get the idea. I'm trying not to waste an EEPROM, essentially, if this isn't going to cause an issue for me. I've booted up the reassembled ROM (i.e. written to EEPROM incorrectly, read back off EEPROM and reassembled) in Bizhawk and in Kega Fusion, and have not thus far found anything obviously amiss in either but obviously it's such a teensy imperfection that it will presumably require a very specific scenario in which to bump into whatever job that byte does and potentially encounter a catastrophe.

The standard ROM doesn't even contain this offset because the file isn't as big so doesn't extend that far, but it's there in every file the customiser spits out when I whack in some options. It isn't specific to my preferred custom options, either, because I tried to isolate it a very tedious manual way by changing every single option I'd modified in the customiser to see if any of them modified that offset but it doesn't matter what settings I use and what IPS patches are getting applied, this byte always downloads as a D0 (despite it not even being present in the un-customised 130810 ROM). I can't see what difference it makes if it's a D4.

There might be a better place to ask this, in which case feel free to let me know. It's a very small thing I'm asking about but it requires some explanation so sorry about the length of the post; I was a bit nervous of starting a whole new topic for something so trivial. I dunno if maybe Neo might be my guy here, but I don't want to immediately show up and then PM him asking a question about a project that appears to have essentially ended some time ago.

[Neo]

BoardAvenger, on 06 January 2019 - 05:46 PM, said:

So here's my question: what does the D0 byte at offset $380278 in a customised Sonic 3 Complete ROM actually do?

1C A9 27 00 BF 0A D0 F4 D0 F8 1D F4 1E 00 2B 4C

Assuming I checked the right build, that address lands right in the middle of the the Kosinski-compressed 128x128 chunk definitions for Launch Base Zone 2. Now, I have no clue what the implications of a random corrupted bit in a compressed archive are, but I'm pretty sure something will be wrong.

[BoardAvenger]

Neo, on 06 January 2019 - 08:36 PM, said:

BoardAvenger, on 06 January 2019 - 05:46 PM, said:

So here's my question: what does the D0 byte at offset $380278 in a customised Sonic 3 Complete ROM actually do?

1C A9 27 00 BF 0A D0 F4 D0 F8 1D F4 1E 00 2B 4C

Assuming I checked the right build, that address lands right in the middle of the the Kosinski-compressed 128x128 chunk definitions for Launch Base Zone 2. Now, I have no clue what the implications of a random corrupted bit in a compressed archive are, but I'm pretty sure something will be wrong.

Woah, thank you so much! I guess I'll be redoing that EPROM instead of soldering it in anyway, then. Damn.

... I now want to play LBZ in emulation and see if anything nuts happens though.

(I just now realised the obvious dumb flaw in what I said about that offset only being in customised builds: the offset will presumably just change because stuff got packed into the start of the file, so this code is still in the standard build except at a different offset. Sleep has value...)

I really appreciate everything you're doing with Sonic 3 by the way, I've been following the Unlocked blog for a wee while. It's extremely helpful to see you breaking stuff down like you do!

[Moon Alien]

Sorry if this is a stupid question,

I was trying to fix up Sonic 2 before I make any kind of hack of it, and one of the bugs was the broken one way barrier in Chemical Plant and Death Egg. I spent a while on it and believe I'm stuck.

It says here that the object subtype of the barrier should be $02 and not $00 (for Nemesis art decompression I presume) : https://tcrf.net/Son...ehog_2_(Genesis)#CPZ.2FDEZ_Door

The problem is that I cannot find that subtype property anywhere :

; ===========================================================================
; loc_116AC:
Obj2D_Init:
	addq.b	#2,routine(a0)
	move.l	#Obj2D_MapUnc_11822,mappings(a0)
	move.w	#make_art_tile(ArtTile_ArtNem_HtzValveBarrier,1,0),art_tile(a0)
	move.b	#8,width_pixels(a0)
	cmpi.b	#metropolis_zone,(Current_Zone).w
	beq.s	+
	cmpi.b	#metropolis_zone_2,(Current_Zone).w
	bne.s	++
+
	move.w	#make_art_tile(ArtTile_ArtKos_LevelArt,3,0),art_tile(a0)
	move.b	#$C,width_pixels(a0)
+
	cmpi.b	#chemical_plant_zone,(Current_Zone).w
	bne.s	+
	move.w	#make_art_tile(ArtTile_ArtNem_ConstructionStripes_2,1,0),art_tile(a0)
	move.b	#8,width_pixels(a0)
+
	cmpi.b	#death_egg_zone,(Current_Zone).w
	bne.s	+
	move.w	#make_art_tile(ArtTile_ArtNem_ConstructionStripes_1,1,0),art_tile(a0)
	move.b	#8,width_pixels(a0)
+
	cmpi.b	#aquatic_ruin_zone,(Current_Zone).w
	bne.s	+
	move.w	#make_art_tile(ArtTile_ArtNem_ARZBarrierThing,1,0),art_tile(a0)
	move.b	#8,width_pixels(a0)
+
	bsr.w	Adjust2PArtPointer
	ori.b	#4,render_flags(a0)
	move.b	#4,priority(a0)
	move.w	y_pos(a0),objoff_32(a0)
	move.b	subtype(a0),mapping_frame(a0)
	move.w	x_pos(a0),d2
	move.w	d2,d3
	subi.w	#$200,d2
	addi.w	#$18,d3
	btst	#0,status(a0)
	beq.s	+
	subi.w	#-$1E8,d2
	addi.w	#$1E8,d3
+
	move.w	d2,objoff_38(a0)
	move.w	d3,objoff_3A(a0)
; loc_1175E:
Obj2D_Main:
	btst	#0,status(a0)
	bne.s	+
	move.w	objoff_38(a0),d2
	move.w	x_pos(a0),d3
	tst.b	routine_secondary(a0)                ; check if barrier is moving up
	beq.s	++
	move.w	objoff_3A(a0),d3
	bra.s	++
; ===========================================================================

I tried changing zeroes to twos here and there (even in the object's hex file), changing the position of some lines of code, but all it did was either change the palette, glitch up the graphics of the barrier, or freeze completely going down the slope at the beginning of CPZ2 (because the barrier loads in that area). I don't see any disassembly notes about fixing the barrier either, whereas other glitches are described in detail in the disasm.

I'm very new to assembly, so excuse me if the answer is super obvious.

[MainMemory]

Normally you'd fix the object's subtype by editing the object layout data with SonLVL/SonED2. You can fix it in code, if you find the parts relevant to CPZ and DEZ, and insert the line: move.b #2,subtype(a0)

[Moon Alien]

MainMemory, on 12 January 2019 - 07:02 PM, said:

Normally you'd fix the object's subtype by editing the object layout data with SonLVL/SonED2. You can fix it in code, if you find the parts relevant to CPZ and DEZ, and insert the line: move.b #2,subtype(a0)

Thank you very much. So by changing the CPZ and DEZ sections like so :

	cmpi.b	#chemical_plant_zone,(Current_Zone).w
	bne.s	+
	move.w	#make_art_tile(ArtTile_ArtNem_ConstructionStripes_2,1,0),art_tile(a0)
	move.b	#8,width_pixels(a0)
	move.b #2,subtype(a0)
+
	cmpi.b	#death_egg_zone,(Current_Zone).w
	bne.s	+
	move.w	#make_art_tile(ArtTile_ArtNem_ConstructionStripes_1,1,0),art_tile(a0)
	move.b	#8,width_pixels(a0)
	move.b #2,subtype(a0)

It fixed the door! : https://imgur.com/a/xwz06BT

[Moon Alien]

Excuse me for poking my head in again, but the door fix missed one door. This is the second door after Metal Sonic : https://imgur.com/gallery/rHM7siB

I presume this particular door is part of some sort of sequence data rather than object data.

There are many reasons I come to this conclusion, first, there is no SonLVL data about this 2nd door, it just ends up being a blank space in the editor. Then, I removed the subtype line of code for Death Egg and flipped all the doors around, didn't help (which of course, since i checked the original game after and that one door was always broken). And finally, I realized that this one door works differently to the other doors, in the sense that it doesn't go up immediately upon arrival like all the other doors, it only opens after Eggman does the scared face for a second which is in turn triggered by the arrival at the door.

Of course, the reason why I'm here is because I can't find this sequence data anywhere in the assembly, probably because the door is a completely different object than obj2D in this instance or it's something else that's either more cryptic or way too obvious.

Anyways, thanks again for the advice.

[MainMemory]

That door in particular is spawned as a sub-object of object C6, Eggman. It has its own mappings in objC6_b.bin, so you'll have to edit that to fix it.

[Moon Alien]

MainMemory, on 13 January 2019 - 06:49 PM, said:

That door in particular is spawned as a sub-object of object C6, Eggman. It has its own mappings in objC6_b.bin, so you'll have to edit that to fix it.

SonMapEd did the trick : https://imgur.com/a/TWTb7vQ

I think those barriers gave me the most headaches, I pretty much fixed every other major issue accordingly, so I think I almost have a bug-fixed version of Sonic 2 I'm satisfied with, in order to start doing the fun stuff.

Grateful for the advice.

[Prototype]

So, I've been looking to mod Mania Plus to refresh it a little. The game is super fun, but I want a bit more variety. I'm not entirely sure how to go about that, though. Is there a simple mod loader or something like that? Where do I start?

[MainMemory]

Here's the mod loader: https://gamebanana.com/wips/48996
If you need help, the GameBanana community or Discord server would be good places to start.

[Prototype]

Thanks! I haven't had a chance to check it out yet, but I will soon. One thing I gotta ask, because I'm clueless, when it comes to modding Mania, can you outright add content like more levels, etc.? Or is it more a case of replacing the existing level slots with custom data and recreating levels. I'm not really sure how the data structure works.

I don't know if it's ever been done, but it would be pretty neat to just add ALL the classic Sonic levels and essentially recreate the S123k trilogy as a coherent package.

[TheInvisibleSun]

It's kind of being done:



I think they might do more.