Gopher Popcorn Stew Beta (BTSD replacement) [Updated!] - Resource & Tool Releases

A small thing I noticed.

asar.dll from asar 1.50 doesn't work with the lastest GPS release, it shows a message advising to redownload the tool.

Oh yeah, I wanted to update the dll while I was at it... Oh well.
Anyway, here is a version that accepts asar 1.50's dll. I haven't really tested if there are any compatibility issues though.

I'm not really sure what the cause of this is but GPS suddenly doesn't work right after using it on my SA-1 rom a second time. It took me a while to figure out but it started writing my blocks into the game's original code instead of freespace. What could possibly make that happen?

Download

So... here's something that came up a few days ago in the discord: Being able to assign the same file to multiple blocks in the same line.
No idea if this feature/format is useful to anyone but I had fun coding so *shrug*

This version also uses Asar 1.50 instead of Asar 1.37 which the currently submitted version still uses.

The format of the list is:

Code

# Assigning a single block (Same as GPS's original format)
<map16>[:acts like] <file>

# Assign all blocks between
<map16 1>-<map16 2>[:acts like] <file>

# Assign a rectangle of blocks (Pretty much the same with LM's remap feature)
R<map16 1>-<map16 2>[:acts like] <file>

# Examples:

# Block 200 with acts like 25 and file "file1.asm"
200:25 file1.asm

# Blocks 201, 202, 203 and 204 with acts like 130 and file "file2.asm
201-204:130 file2.asm

# Blocks 210, 211, 220 and 221 without acts like and file "file3.asm"
R210-221 file3.asm

<> - required
[] - optional

While I was at it I also added comments to the list. As shown above if a line starts with "#" it's treated as a commented and will be skipped by GPS.

As for all the sa-1 issues. I applied a few blocks and couldn't recreate any of the issues mentioned so I can't really look into that.

Any chance you could make this able to replace blocks in Map16 pages 0 and 1 like the old Blocktool?

Kinda in hibernation for a while. I hope to be back in full swing soon.

Oh yeah, this thread exists.

Btw, new update
Most important change is compatibility with the new map16 area.

Feel free to report all bugs I missed.

Quote

Any chance you could make this able to replace blocks in Map16 pages 0 and 1 like the old Blocktool?

I could but there are various reasons why it shouldn't be done. It really isn't difficult to just copy paste a map16 tile in pages 2+ and unless you use objects you can always use the remap feature to remap already existing tiles.
If you really want it though it's a matter of changing a single number so here you go I won't make this anything official though.

I guess I should keep this thread up to date.

A new version of GPS has been submitted.

It fixes the description bug some people mentioned in this thread as well as SA-1 ROMs sometimes breaking when using GPS.

It also fixes the rainbow_shatter_block routine and adds a layer 2 routine which is hopefully useful for making blocks more compatible with layer 2.

If there's anything you still want to see or a bug this version didn't fix yet post about it here and I'll try to fix it.

I'm sorry this took so long, anyway, this update finally fixes the "The End" screen bug and various other bugs in GPS itself and it's routines.

This version also supports big level layouts so have fun.

Download

Thanks for the update. I found that change_map16.asm may not work properly in a vertical level; LDA $99 : CMP #$02 should be done as original, instead of being compared with $13D7 in this case. It didn't seem to generate a tile properly at the right side of a vertical level as a consequence.

Alright, thanks for reporting that. It'll be fixed in the next GPS/PIXI update.

Feature suggestion: Allow lines to start with tab character.

I'm working on improving my tile list to use indentation to make it easier for seeing for my screen scrolling pipes:

Code

;1-way pipe caps
	;Vertical caps
		;Vertical pipe cap upwards travel
			0404:0130		SSP_Tiles\caps\exit_only\top_vertical_pipe_cap_L_exit.asm
			0405:0130		SSP_Tiles\caps\exit_only\top_vertical_pipe_cap_R_exit.asm
			0414:0130		SSP_Tiles\caps\enterable\default\bottom_vertical_pipe_cap_L.asm
			0415:0130		SSP_Tiles\caps\enterable\default\bottom_vertical_pipe_cap_R.asm
		;Vertical pipe cap downwards travel
			0406:0130		SSP_Tiles\caps\enterable\default\top_vertical_pipe_cap_L.asm
			0407:0130		SSP_Tiles\caps\enterable\default\top_vertical_pipe_cap_R.asm
			0416:0130		SSP_Tiles\caps\exit_only\bottom_vertical_pipe_cap_L_exit.asm
			0417:0130		SSP_Tiles\caps\exit_only\bottom_vertical_pipe_cap_R_exit.asm

Would be really nice if this format is allowed.

Give thanks to RPG hacker for working on Asar.

how has nobody seen the above post yet? it's such an easy change too.
https://drive.google.com/file/d/1ERUIJgkyLPJ4rnuGPNxoMzR8oEPBQgNb/view?usp=sharing
here, this should work ok. this is source code; someone will have to compile it for windows.

I have seen it, considered it and while I personally don't agree with that being more readable I would've probably added it in the next version anyway. I don't need to use it after all.

I haven't really been in the mood to work on figuring out the softlock though so unless someone else submits that as an update, the line thing'll have to wait until then.

On a side note, if you do edit gps source and release it I'd prefer if you changed the version string as well so in case someone has issues with it people know which version it is. Doesn't really matter in this case since it's just source and no executable but still.

I'm getting a pretty significant bug with GPS. Sprites don't interact with slopes properly; they sort of "jerk" up or down the slope, or treat it like a stairway, instead of walking smoothly up/down it. I have a patch that shows what I mean. Nothing else has been applied to the ROM except Lunar Magic's ASM hacks.

While we're on the subject, my other custom blocks haven't been working either ever since I ported to a new ROM. Some of them do something but not what they're supposed to, such as spawning the wrong sprite or spawning one with the wrong position and settings.

Also, it would be useful if future versions would store the current block's tile number somewhere. I have a subroutine to do it, but it's not normally something easily accessible ($03 and Y only contain the acts-like setting, not the actual Map16 tile number).

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.

Since I can't reproduce it myself with the latest GPS version I'd prefer a bit more information on what you're doing before I look deeper into it.

What version of GPS are you using? Is it clean?
Which LM hacks have been installed? Just the standard ones you get when editing levels?
Does it happen if you don't apply any custom blocks?

As for your other issues, can't really say much about them, don't see why the update would've broken any of that.

And lastly, $03 does contain the map16 number of the block that's running the code, that one was never the acts-like setting, if that's not what you're looking for I'm not sure what is.

Originally posted by TheBiob

What version of GPS are you using? Is it clean?

1.4.21, and I don't see why it wouldn't be.

Originally posted by TheBiob

Which LM hacks have been installed? Just the standard ones you get when editing levels?

Presumably level and overworld.

Originally posted by TheBiob

Does it happen if you don't apply any custom blocks?

Yes.

Originally posted by TheBiob

And lastly, $03 does contain the map16 number of the block that's running the code, that one was never the acts-like setting, if that's not what you're looking for I'm not sure what is.

Really? I tried using $03 that way, and it didn't work.

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.

Hm, I guess I'll try and take a look again, always hard to tell if I can't reproduce it myself.

Originally posted by imamelia

Really? I tried using $03 that way, and it didn't work.

Yes, if it's definitely not what you want then I'd need more details on what you're doing/what it gives you/what you expect it to give you.

edit: Alright, I looked at it. Your GPS isn't clean. Please at least provide the correct information.

I even went as far as confirming that the changes that aren't in GPS but in your ROM are actually the cause of your issues and yes, they are. Use an unedited version of GPS or confirm that the edits you made actually work.

Originally posted by TheBiob

Originally posted by imamelia

Really? I tried using $03 that way, and it didn't work.

Yes, if it's definitely not what you want then I'd need more details on what you're doing/what it gives you/what you expect it to give you.

Well, I have tile 1092 set to act like 024A, and the value of $03 is #$024A, not #$1092.

Originally posted by TheBiob

edit: Alright, I looked at it. Your GPS isn't clean. Please at least provide the correct information.

I even went as far as confirming that the changes that aren't in GPS but in your ROM are actually the cause of your issues and yes, they are. Use an unedited version of GPS or confirm that the edits you made actually work.

Well, how was I supposed to know that? I did say "I don't see why it wouldn't be", not "It definitely is". Do you know what the changes are? I did add a routine to store the Map16 number to $07 (which I forgot to mention), but I did try it without that and still had the bug.

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.

Originally posted by imamelia

Well, how was I supposed to know that? Do you know what the changes are?

I asked if your installation of GPS was clean and you said "I don't see why it wouldn't be." but it's clearly edited with code that isn't from GPS, so it's not clean.

And yes, I did see what the changes are.

fe:

Originally posted by imamelia

I did say "I don't see why it wouldn't be", not "It definitely is" [...] (which I forgot to mention), but I did try it without that and still had the bug.

Well, editing the source is definitely a reason that makes it not clean and something people usually remember. Stuff like that is very important to know when debugging which is why I asked that question in the first place.
I'm sorry if my wording came of as a bit aggressive though, it wasn't meant to be.

And fair enough if you tried it without, it probably just wasn't applied correctly then. It worked perfectly fine on my end once I NOP'd out the JSR that was added.

Originally posted by imamelia

Well, I have tile 1092 set to act like 024A, and the value of $03 is #$024A, not #$1092.

Alright, I see the issue then,

$03 contains the map16 tile of the block that executes the code, not the one you touched, that's correct. Unfortunately that's not something that's in GPS' realm but Lunar Magics. LM provides the information, GPS just uses it. $03 isn't provided by GPS either.

I assume that's what you tried to fix using the changes that broke it?

Either way, if you want the block that started the acts-like chain then you'll have to ask FuSoYa if there's any way, or fix your code.
If you really need to I'd go for the latter and move the code from GPS' source to a routine you can call whenever you actually need it. The way it's implemented right now the code gets that information for every single interaction that runs on that frame, when 99% of the time it's not needed or the same as $03 and discarded anyway. It also uses $98-$9B which doesn't even work for sprites (which is also the reason why sprites acted that way on slopes, they don't use $98-$9B. Instead they use scratch ram that you overwrote in that routine).

Though I'm curious, why are you using acts-like chains anyway? You can just use the same file for multiple blocks in GPS' list file which is the better option in every single scenario I can think of right now.

Originally posted by TheBiob

Originally posted by imamelia

Well, I have tile 1092 set to act like 024A, and the value of $03 is #$024A, not #$1092.

Alright, I see the issue then,

$03 contains the map16 tile of the block that executes the code, not the one you touched, that's correct. Unfortunately that's not something that's in GPS' realm but Lunar Magics. LM provides the information, GPS just uses it. $03 isn't provided by GPS either.

I assume that's what you tried to fix using the changes that broke it?

Either way, if you want the block that started the acts-like chain then you'll have to ask FuSoYa if there's any way, or fix your code.
If you really need to I'd go for the latter and move the code from GPS' source to a routine you can call whenever you actually need it. The way it's implemented right now the code gets that information for every single interaction that runs on that frame, when 99% of the time it's not needed or the same as $03 and discarded anyway. It also uses $98-$9B which doesn't even work for sprites (which is also the reason why sprites acted that way on slopes, they don't use $98-$9B. Instead they use scratch ram that you overwrote in that routine).

Though I'm curious, why are you using acts-like chains anyway? You can just use the same file for multiple blocks in GPS' list file which is the better option in every single scenario I can think of right now.

Yeah, that's what I ran into, and I did eventually remember that $0A-$0D are used for sprite->block interaction. I changed the scratch RAM to $45 instead, which seemed to fix the problem. I could probably make it a separate subroutine, but I feel like I tried that and had issues?

And I prefer to keep all my custom blocks on one Map16 page, or two if I need them. I would assume that inserting them on multiple pages takes up more ROM space anyway because of all the unused pointers in between used blocks.

Thanks for looking into it, anyway.

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.