EarthBound

__sdfg

2014-10-16 10:16:10 pm

D:

Nice! Looking forward to seeing the whole game manipulated someday. Tongue

andyperfect

2014-10-21 10:12:33 am

So it turns out to be a reliable route that I've created, even through Giygas. I routed Giygas when Ness had high offense, 42 guts, and Jeff had 44 hp (the main variables that would influence RNG during the fight). I had a run, on console, where Ness had 43 guts, lower offense, and Jeff had 33 hp. It still worked out perfectly -- I just had to change my strategy slightly that when Jeff takes mortal damage, mash through so he dies at the same point during the battle.

I did a no-reset run where a few days ago where I died to Frank, failed the Underworld manipulation once, failed the Magicant manipulation once, and forgot to equip the magicant bat for the Giygas fight (his Smash did 1 damage :D) and I still PB'd by over a minute (1:31:xx)

andyperfect

Edit history:

andyperfect: 2014-10-25 11:29:48 pm

2014-10-25 11:07:07 pm

So here's the newest PB of mine -- it's faster than Nemi's stairs glitched run by about 35 seconds, but includes two unnecessary resets -- one in the Sea of Eden (I messed up my movement and got attacked by a Kraken requiring a reset) and Jeff had a new hp amount at Giygas I hadn't encountered before, 38. As a result, I messed up the manipulation at Giygas and had to reset but nailed it on the second try.

In essence, this run includes new RNG manipulations for Ness's Nightmare and Giygas. Still grinding for that sub 1:20 Cheesy

SpeedyMisty

Edit history:

SpeedyMisty: 2014-11-15 08:33:05 pm

2014-11-13 02:41:19 pm

Speed Running in Robotnik's Basement

I'm just a random Jo off from the side of the street, and I am not sure if this question has been asked yet. I don't have nearly enough money for a ~~N64~~ SNES version of Earthbound, but I own the Wii U version.

Does any of the glitches work on Wii U? Can a speedrun be done on it? Or am I wasting my breath? Sorry for wasting your time.

philosoraptor42

2014-11-14 09:08:10 am

Dapper as fuck.

Pretty sure they do. I can verify for sure that glitching up cliffs and the check area glitch work on VC. I haven't tried the stairs glitch though.

andyperfect

Edit history:

andyperfect: 2014-11-14 08:27:39 pm

2014-11-14 08:23:23 pm

Other than some of the animations being changed because of seizure concerns, I believe that the game is identical, glitches and all. Nobody has ever done timing comparisons against the two different versions, though.

Also note that Earthbound is for SNES, not N64 happy

SpeedyMisty

2014-11-15 08:26:45 pm

Speed Running in Robotnik's Basement

Did I seriously type N64? I feel like such a moron now. I knew it was SNES, I even saw one at a Flea Market once (He didn't let me touch it) But I guess my brain thought N64. Hate it when that happens.

But thank-you with the quick responsive.
Do you think it would be worth it trying to run it for the VC? It'd make running the game easier for other players to do, too, seeing as it is still a little expensive. (Though...looking at eBay at least...it seems to have gone cheaper since the VC came out. I remember just the BOX, alone being a nice 300 some odd dollars once. The previously mentioned Flea Market had it around that price, too)

__sdfg

2014-11-16 11:35:17 am

D:

We may want to do some investigation of whether there are timing differences, but for now, the two versions are considered equivalent. Even if differences are discovered in the future, the absolute worst case is that the two versions would be treated as separate categories. I don't think that's likely to happen, though. So, I see no reason not to go for it. thumbsup

Have fun!

SpeedyMisty

2014-11-16 06:28:43 pm

Speed Running in Robotnik's Basement

That makes me really...REALLY happy.

And I bet a lot of others will be, too, seeing as (as mentioned before) the game is not that cheap.

Thank-you, and good luck to all of you. And thank-you so much for answering so quickly.

__sdfg

2014-12-08 09:22:39 pm

D:

I was able to manipulate the RNG up through the Captain Strong fight earlier tonight. I have an explanation of the RNG route here: http://www.twitch.tv/uusdfg/c/5646112. I've also attached a BizHawk movie of the route in case anyone wants to play with specific parts of it. I recorded it in BizHawk 1.8.4 -- let me know if there are desyncs with other versions, or if there are ROM differences to watch out for.

After finishing the route, I decided it might actually be faster to deathwarp from Giant Step than to walk back. Previously, I had thought manipulating the cop fights without Rockin would cost more time than the walk back (I am pretty sure healing with Frank after the deathwarp would make it slower than walking back, so I assume Ness will not have enough PP to use Rockin after dying). However, I'm not sure when I would have time to produce another complete route to test that hypothesis. >_> So, I'll probably have to leave that as a project for anyone interested to pick up. In the meantime, this route is good for a 19:20-ish Captain Strong kill.

Also, since I haven't seen discussion of it in the past, I should mention that while I was working on this, I found that the 16-bit address at 7E4A7A contributes to changes in the RNG. It seems like that value is incremented by 5 when crossing a (64-pixel) tile boundary, at least some of the time. I haven't investigated enough to say if it is incremented for all tile boundaries or only certain ones. Also, updates to it appear to be disabled while enemy spawns are disabled, which is likely why it didn't seem to come up for anyone while routing to Starman Junior.

Anyway, changes to 7E4A7A sometimes trigger changes in the RNG, so the consistency of that value needs to be taken into account when forming RNG routes. Otherwise, it is possible to get into weird situations where the RNG changes unexpectedly because of a misstep earlier in the run. For example, while routing this, I found that the RNG's behavior inside the drugstore depended on how I entered the door, even though the RNG always had the same value for me going into the door (it turns out the door is right by two tile boundaries). Fortunately, it seems like it is possible to make the value behave predictably by avoiding paths where Ness might accidentally cross or fail to cross a tile boundary.

Hopefully, there are no more unknown components to the RNG's behavior. <_<

I was able to manipulate the RNG up through the Captain Strong fight earlier tonight.  I have an explanation of the RNG route here:  [url]http://www.twitch.tv/uusdfg/c/5646112[/url].  I've also attached a BizHawk movie of the route in case anyone wants to play with specific parts of it.  I recorded it in BizHawk 1.8.4 -- let me know if there are desyncs with other versions, or if there are ROM differences to watch out for.

After finishing the route, I decided it might actually be faster to deathwarp from Giant Step than to walk back.  Previously, I had thought manipulating the cop fights without Rockin would cost more time than the walk back (I am pretty sure healing with Frank after the deathwarp would make it slower than walking back, so I assume Ness will not have enough PP to use Rockin after dying).  However, I'm not sure when I would have time to produce another complete route to test that hypothesis. >_>  So, I'll probably have to leave that as a project for anyone interested to pick up.  In the meantime, this route is good for a 19:20-ish Captain Strong kill.

Also, since I haven't seen discussion of it in the past, I should mention that while I was working on this, I found that the 16-bit address at 7E4A7A contributes to changes in the RNG.  It seems like that value is incremented by 5 when crossing a (64-pixel) tile boundary, at least some of the time.  I haven't investigated enough to say if it is incremented for all tile boundaries or only certain ones.  Also, updates to it appear to be disabled while enemy spawns are disabled, which is likely why it didn't seem to come up for anyone while routing to Starman Junior.

Anyway, changes to 7E4A7A sometimes trigger changes in the RNG, so the consistency of that value needs to be taken into account when forming RNG routes.  Otherwise, it is possible to get into weird situations where the RNG changes unexpectedly because of a misstep earlier in the run.  For example, while routing this, I found that the RNG's behavior inside the drugstore depended on how I entered the door, even though the RNG always had the same value for me going into the door (it turns out the door is right by two tile boundaries).  Fortunately, it seems like it is possible to make the value behave predictably by avoiding paths where Ness might accidentally cross or fail to cross a tile boundary.

Hopefully, there are no more unknown components to the RNG's behavior. <_<

Attachment:

Onett RNG manipulation.bk2

andyperfect

2014-12-09 02:40:33 pm

__sdfg, you've done a great job putting this together. What made me smile the most was how easy it looks to get the two bomb drops in Giant step. I know it probably took a TON of time to make it look that easy but the result just looks so good. I'm definitely going to be playing with this route so major props for all the work you put into it.

The additional counter memory value you've found is EXTREMELY intriguing. I've run into a ton of problems in the any% route getting the correct rng in a couple places consistently and I'm excited to plug this value in and start replaying different sections. May I ask how you came upon this address? I'd be interested in digging a little deeper into the code just to be 100% sure there is nothing else that contributes to RNG. If you feel you already dug pretty deep though, I'll probably just leave it alone.

Also intriguing is the fact that the police fights result in identical rounds even when changing the RNG multiple times. It makes me wonder if there is yet another RNG value influencing battles we're not aware of?

Lastly, I think I'm going to toy with doing the death warp out of Giant Step. The funny thing is that when I started running this game, we were deathwarping out to begin with. After timing it though, there's just enough RNG in that area that it makes dying to antoids just long enough on average that it's faster to just walk out. Interesting how theses routes change Smiley

Once again, I love the work you've put into this. Thanks for putting this video together thumbsup

__sdfg, you've done a great job putting this together. What made me smile the most was how easy it looks to get the two bomb drops in Giant step. I know it probably took a TON of time to make it look that easy but the result just looks so good. I'm definitely going to be playing with this route so major props for all the work you put into it.

The additional counter memory value you've found is EXTREMELY intriguing. I've run into a ton of problems in the any% route getting the correct rng in a couple places consistently and I'm excited to plug this value in and start replaying different sections. May I ask how you came upon this address? I'd be interested in digging a little deeper into the code just to be 100% sure there is nothing else that contributes to RNG. If you feel you already dug pretty deep though, I'll probably just leave it alone.

Also intriguing is the fact that the police fights result in identical rounds even when changing the RNG multiple times. It makes me wonder if there is yet another RNG value influencing battles we're not aware of?

Lastly, I think I'm going to toy with doing the death warp out of Giant Step. The funny thing is that when I started running this game, we were deathwarping out to begin with. After timing it though, there's just enough RNG in that area that it makes dying to antoids just long enough on average that it's faster to just walk out. Interesting how theses routes change :)

Once again, I love the work you've put into this. Thanks for putting this video together :thumbsup:

__sdfg

2014-12-09 06:15:41 pm

D:

Quote from andyperfect:

What made me smile the most was how easy it looks to get the two bomb drops in Giant step. I know it probably took a TON of time to make it look that easy but the result just looks so good.

The bomb drops are actually one of the easier things to manipulate once you get slugs on both the top and bottom levels. I used a modified version of a script pirohiko posted to TASVideos to show me where bomb drops would occur in the future (script is attached). In this version of the script, if the game polls the RNG to decide if there should be a drop when the white line is immediately to the left of a light blue line, the slug drops a bomb.

For an instant win, I believe the drop is decided right after Ness gains the experience. For Attack Slugs, this is 42 RNG positions after you start the fight (or 43 positions ahead of the light blue line). It doesn't seem to be possible to get a bomb if you level on an instant win, though.

You can also use the dark blue lines and the full-height light blue lines to predict smashes (the game polls shortly after the "Ness attacks!" text).

Quote:

The additional counter memory value you've found is EXTREMELY intriguing. I've run into a ton of problems in the any% route getting the correct rng in a couple places consistently and I'm excited to plug this value in and start replaying different sections. May I ask how you came upon this address? I'd be interested in digging a little deeper into the code just to be 100% sure there is nothing else that contributes to RNG. If you feel you already dug pretty deep though, I'll probably just leave it alone.

I noticed that the RNG changed at apparently random places as I walked around the drugstore and police station. Since I didn't understand why this was happening, I captured a CPU trace for a few frames around one of the places where the RNG changed. I noticed that just before the RNG was updated, the game checked the value of 7E4A7A, so I put that in RAM Watch and then guessed the rest of the behavior just from observation.

I have not done very much investigation, so you could try doing something similar if you see places where the RNG is acting funny in the any% route. Interpreting CPU traces when you don't know what most of the memory addresses are for is kind of overwhelming, though. >_>

I've attached the trace I used in case you want to take a look at it.

Quote:

Also intriguing is the fact that the police fights result in identical rounds even when changing the RNG multiple times. It makes me wonder if there is yet another RNG value influencing battles we're not aware of?

I don't think there's another value involved. I always get the same behavior for a given RNG seed. The weird thing is that sometimes, different seeds give the same behavior, and furthermore advance to the same seed on the next round

My guess is that there's a loop in the battle engine that causes the RNG to advance up to a value meeting some condition before the game goes ahead with whatever action is selected. This could be confirmed with a CPU trace, but I'm not feeling up to combing through the disassembly for that right now...

Quote:

Lastly, I think I'm going to toy with doing the death warp out of Giant Step. The funny thing is that when I started running this game, we were deathwarping out to begin with. After timing it though, there's just enough RNG in that area that it makes dying to antoids just long enough on average that it's faster to just walk out. Interesting how theses routes change Smiley

Yeah, definitely give it a shot. I think the "Not enough PP!" trick should hopefully make it possible to manipulate the behavior you need without losing too much time. I just don't want to spend another few hours producing a new route right now, when I could be practicing this one (or Whizz >_>).

Quote:

Once again, I love the work you've put into this. Thanks for putting this video together thumbsup

Thanks!

[quote="andyperfect"]What made me smile the most was how easy it looks to get the two bomb drops in Giant step. I know it probably took a TON of time to make it look that easy but the result just looks so good.[/quote]
The bomb drops are actually one of the easier things to manipulate once you get slugs on both the top and bottom levels.  I used a modified version of a script pirohiko posted to TASVideos to show me where bomb drops would occur in the future (script is attached).  In this version of the script, if the game polls the RNG to decide if there should be a drop when the white line is immediately to the left of a light blue line, the slug drops a bomb.

For an instant win, I believe the drop is decided right after Ness gains the experience.  For Attack Slugs, this is 42 RNG positions after you start the fight (or 43 positions ahead of the light blue line).  It doesn't seem to be possible to get a bomb if you level on an instant win, though.

You can also use the dark blue lines and the full-height light blue lines to predict smashes (the game polls shortly after the "Ness attacks!" text).

[quote]The additional counter memory value you've found is EXTREMELY intriguing. I've run into a ton of problems in the any% route getting the correct rng in a couple places consistently and I'm excited to plug this value in and start replaying different sections. May I ask how you came upon this address? I'd be interested in digging a little deeper into the code just to be 100% sure there is nothing else that contributes to RNG. If you feel you already dug pretty deep though, I'll probably just leave it alone.[/quote]
I noticed that the RNG changed at apparently random places as I walked around the drugstore and police station.  Since I didn't understand why this was happening, I captured a CPU trace for a few frames around one of the places where the RNG changed.  I noticed that just before the RNG was updated, the game checked the value of 7E4A7A, so I put that in RAM Watch and then guessed the rest of the behavior just from observation.

I have not done very much investigation, so you could try doing something similar if you see places where the RNG is acting funny in the any% route.  Interpreting CPU traces when you don't know what most of the memory addresses are for is kind of overwhelming, though. >_>

I've attached the trace I used in case you want to take a look at it.

[quote]Also intriguing is the fact that the police fights result in identical rounds even when changing the RNG multiple times. It makes me wonder if there is yet another RNG value influencing battles we're not aware of?[/quote]
I don't [i]think[/i] there's another value involved.  I always get the same behavior for a given RNG seed.  The weird thing is that sometimes, different seeds give the same behavior, and furthermore advance to the same seed on the next round

My guess is that there's a loop in the battle engine that causes the RNG to advance up to a value meeting some condition before the game goes ahead with whatever action is selected.  This could be confirmed with a CPU trace, but I'm not feeling up to combing through the disassembly for that right now...

[quote]Lastly, I think I'm going to toy with doing the death warp out of Giant Step. The funny thing is that when I started running this game, we were deathwarping out to begin with. After timing it though, there's just enough RNG in that area that it makes dying to antoids just long enough on average that it's faster to just walk out. Interesting how theses routes change :)[/quote]
Yeah, definitely give it a shot.  I think the "Not enough PP!" trick should hopefully make it possible to manipulate the behavior you need without losing too much time.  I just don't want to spend another few hours producing a new route right now, when I could be practicing this one (or Whizz >_>).

[quote]Once again, I love the work you've put into this. Thanks for putting this video together :thumbsup:[/quote]
Thanks!

Attachments:

Counter thing.zip

pirohiko rng script.lua

nemi

2015-01-20 01:36:24 am

I had to try all the new RNG manipulation in the stairs glitch run:

1:05:09 SDA time
1:06:17 SRL time

This run is full of mistakes--most notably a failed Summers glitch--but I guess it works for showing how close we can get to the TAS route. I think the only remaining significant difference is that the TAS doesn't use a 2nd save file. Forgoing the use of a 2nd file would probably require manipulating through invaded Onett and the Cave of the Past, but I'm not sure how practical or how fast that would be on console.

Also, I'm not sure if these are known, but I noticed a couple of things that might be useful in a glitchless run. First, there is a route through the graveyard in Threed that usually despawns the No Good Flies that appear in front of the 2 zombies that block the ladder to Grapefruit Falls. Walking above the top row of gravestones and then walking below the last large gravestone seems to despawn the No Good Flies most of the time.

Second, stutter-walking over a spawn trigger can sometimes cause a spawned enemy to immediately despawn. This worked for me at 14:28, where I cross a trigger that would cause a Rowdy Mouse to appear if I didn't stutter-walk. Whether this works or not depends on where exactly the enemy spawns within its spawn tile, but it might sometimes help on triggers that are 2 or 3 tiles away from the spawn.

I had to try all the new RNG manipulation in the stairs glitch run:

http://www.youtube.com/watch?v=89RjTyzUNyc

1:05:09 SDA time
1:06:17 SRL time

This run is full of mistakes--most notably a failed Summers glitch--but I guess it works for showing how close we can get to the TAS route. I think the only remaining significant difference is that the TAS doesn't use a 2nd save file. Forgoing the use of a 2nd file would probably require manipulating through invaded Onett and the Cave of the Past, but I'm not sure how practical or how fast that would be on console.

Also, I'm not sure if these are known, but I noticed a couple of things that might be useful in a glitchless run. First, there is a route through the graveyard in Threed that usually despawns the No Good Flies that appear in front of the 2 zombies that block the ladder to Grapefruit Falls. Walking above the top row of gravestones and then walking below the last large gravestone seems to despawn the No Good Flies most of the time.

Second, stutter-walking over a spawn trigger can sometimes cause a spawned enemy to immediately despawn. This worked for me at 14:28, where I cross a trigger that would cause a Rowdy Mouse to appear if I didn't stutter-walk. Whether this works or not depends on where exactly the enemy spawns within its spawn tile, but it might sometimes help on triggers that are 2 or 3 tiles away from the spawn.

__sdfg

Edit history:

__sdfg: 2015-01-20 10:17:32 pm

__sdfg: 2015-01-20 10:16:44 pm

2015-01-20 11:24:11 am

D:

Quote from nemi:

I had to try all the new RNG manipulation in the stairs glitch run:

1:05:09 SDA time
1:06:17 SRL time

Quote:

Also, I'm not sure if these are known, but I noticed a couple of things that might be useful in a glitchless run. First, there is a route through the graveyard in Threed that usually despawns the No Good Flies that appear in front of the 2 zombies that block the ladder to Grapefruit Falls. Walking above the top row of gravestones and then walking below the last large gravestone seems to despawn the No Good Flies most of the time.

I've been doing something like this for a while. I go above the top row of gravestones, then go down to the top of the tree to the left of the gravestones, then go back up. This path skips the spawn tile that produces the flies (same principle as skipping the Gruff Goat in Winters), and usually despawns any flies that appear while walking to the left.

IIRC I started doing this because you suggested it in my chat. >_>

Quote:

Second, stutter-walking over a spawn trigger can sometimes cause a spawned enemy to immediately despawn. This worked for me at 14:28, where I cross a trigger that would cause a Rowdy Mouse to appear if I didn't stutter-walk. Whether this works or not depends on where exactly the enemy spawns within its spawn tile, but it might sometimes help on triggers that are 2 or 3 tiles away from the spawn.

That's... interesting. Will have to take a look after work.

EDIT: Is the spawn/despawn with that mouse consistent? I have no idea why that would happen. :/ I guess your theory is the mouse is far enough away that it despawns if you just stop right after you cross the tile?

Also, really good run. Not sure what could be done with the route from here other than trying different RNG manipulation methods or seeing if there's a way to clip through Winters with Jeff.

[quote="nemi"]I had to try all the new RNG manipulation in the stairs glitch run:

http://www.youtube.com/watch?v=89RjTyzUNyc

1:05:09 SDA time
1:06:17 SRL time[/quote]
:o

[quote]Also, I'm not sure if these are known, but I noticed a couple of things that might be useful in a glitchless run. First, there is a route through the graveyard in Threed that usually despawns the No Good Flies that appear in front of the 2 zombies that block the ladder to Grapefruit Falls. Walking above the top row of gravestones and then walking below the last large gravestone seems to despawn the No Good Flies most of the time.[/quote]
I've been doing something like this for a while.  I go above the top row of gravestones, then go down to the top of the tree to the left of the gravestones, then go back up.  This path skips the spawn tile that produces the flies (same principle as skipping the Gruff Goat in Winters), and usually despawns any flies that appear while walking to the left.

IIRC I started doing this because you suggested it in my chat. >_>

[quote]Second, stutter-walking over a spawn trigger can sometimes cause a spawned enemy to immediately despawn. This worked for me at 14:28, where I cross a trigger that would cause a Rowdy Mouse to appear if I didn't stutter-walk. Whether this works or not depends on where exactly the enemy spawns within its spawn tile, but it might sometimes help on triggers that are 2 or 3 tiles away from the spawn.[/quote]
That's...  interesting.  Will have to take a look after work.

EDIT:  Is the spawn/despawn with that mouse consistent?  I have no idea why that would happen. :/  I guess your theory is the mouse is far enough away that it despawns if you just stop right after you cross the tile?

Also, really good run.  Not sure what could be done with the route from here other than trying different RNG manipulation methods or seeing if there's a way to clip through Winters with Jeff.

Aurilliux

2015-01-22 05:52:22 pm

Only thing I could see is doing RNG manipulation in Winters, so that you can just walk right through the winters cave, and possibly set yourself up for duck/proto skip in the maze. Might be possible to keep RNG after Magicant, and go right into Onett by teleporting (and eliminating the town map from the run). I had a lot of trouble keeping the RNG counter while teleporting out of Saturn Valley, but I'm not prepared to say it can't be done.

If you're willing to head even closer to the TAS route and do the OOB to summers -> lost underworld -> magicant -> meteorite sequence all one segment, without saving & resetting. It makes Cave to the Past a lot harder if you can't OOB to skip all the enemies, and it might be tough to keep RNG walking to the entrance of the cave. Not too sure how feasible this would be, but I think it'd be the next place to try.

This run has practically everything I wanted to do with any%!

nemi

2015-01-24 01:44:38 am

Quote:

I've been doing something like this for a while. I go above the top row of gravestones, then go down to the top of the tree to the left of the gravestones, then go back up. This path skips the spawn tile that produces the flies (same principle as skipping the Gruff Goat in Winters), and usually despawns any flies that appear while walking to the left.

Sorry, I should've been more clear: I avoid walking to the tree with this route. I stay right next to the gravestones. I walk down to the tree only if the No Good Flies remain.

Quote:

Is the spawn/despawn with that mouse consistent? I have no idea why that would happen. :/ I guess your theory is the mouse is far enough away that it despawns if you just stop right after you cross the tile?

The despawn is very consistent--it never failed in a run attempt. I also tested it multiple times on emulator with a save state, and it never failed unless I tried to rush the stutter-walking.

I'm guessing it has to do with how far away the enemy spawns because for triggers that are 2 tiles away from a spawn, stutter-walking has a chance of working only if the enemy spawns near the back of the spawn tile. For triggers that are 3 tiles away (which is the case for the Rowdy Mouse in my run), the spawn location might not actually matter.

Quote:

If you're willing to head even closer to the TAS route and do the OOB to summers -> lost underworld -> magicant -> meteorite sequence all one segment, without saving & resetting. It makes Cave to the Past a lot harder if you can't OOB to skip all the enemies, and it might be tough to keep RNG walking to the entrance of the cave. Not too sure how feasible this would be, but I think it'd be the next place to try.

Yeah, that's what I was thinking of looking into next. It's going to be difficult, though, because that's a lot of manipulation to plan, and I'm not sure if it'd even be much faster, especially if we need to reset to keep the RNG consistent after Magicant.

[quote]I've been doing something like this for a while.  I go above the top row of gravestones, then go down to the top of the tree to the left of the gravestones, then go back up.  This path skips the spawn tile that produces the flies (same principle as skipping the Gruff Goat in Winters), and usually despawns any flies that appear while walking to the left.[/quote]

Sorry, I should've been more clear: I avoid walking to the tree with this route. I stay right next to the gravestones. I walk down to the tree only if the No Good Flies remain.

[quote]Is the spawn/despawn with that mouse consistent?  I have no idea why that would happen. :/  I guess your theory is the mouse is far enough away that it despawns if you just stop right after you cross the tile?[/quote]

The despawn is very consistent--it never failed in a run attempt. I also tested it multiple times on emulator with a save state, and it never failed unless I tried to rush the stutter-walking.

I'm guessing it has to do with how far away the enemy spawns because for triggers that are 2 tiles away from a spawn, stutter-walking has a chance of working only if the enemy spawns near the back of the spawn tile. For triggers that are 3 tiles away (which is the case for the Rowdy Mouse in my run), the spawn location might not actually matter.

[quote]If you're willing to head even closer to the TAS route and do the OOB to summers -> lost underworld -> magicant -> meteorite sequence all one segment, without saving & resetting.  It makes Cave to the Past a lot harder if you can't OOB to skip all the enemies, and it might be tough to keep RNG walking to the entrance of the cave.  Not too sure how feasible this would be, but I think it'd be the next place to try.[/quote]

Yeah, that's what I was thinking of looking into next. It's going to be difficult, though, because that's a lot of manipulation to plan, and I'm not sure if it'd even be much faster, especially if we need to reset to keep the RNG consistent after Magicant.

__sdfg

2015-01-24 07:56:40 am

D:

Quote from nemi:

Quote:

I've been doing something like this for a while. I go above the top row of gravestones, then go down to the top of the tree to the left of the gravestones, then go back up. This path skips the spawn tile that produces the flies (same principle as skipping the Gruff Goat in Winters), and usually despawns any flies that appear while walking to the left.

Sorry, I should've been more clear: I avoid walking to the tree with this route. I stay right next to the gravestones. I walk down to the tree only if the No Good Flies remain.

Yeah, I saw that in the run. That'd definitely be useful in glitchless. Cool find.

Quote:

Is the spawn/despawn with that mouse consistent? I have no idea why that would happen. :/ I guess your theory is the mouse is far enough away that it despawns if you just stop right after you cross the tile?

The despawn is very consistent--it never failed in a run attempt. I also tested it multiple times on emulator with a save state, and it never failed unless I tried to rush the stutter-walking.

I'm guessing it has to do with how far away the enemy spawns because for triggers that are 2 tiles away from a spawn, stutter-walking has a chance of working only if the enemy spawns near the back of the spawn tile. For triggers that are 3 tiles away (which is the case for the Rowdy Mouse in my run), the spawn location might not actually matter.

This could actually do a ton for glitchless, depending on how it works. From what I saw when I was playing with the spawn script... last year? yeah, last year now... <_< anyway, I remember the enemies in some annoying locations like Pink Cloud sticking around if I just barely triggered their spawn tile and then stood still for a while. So, it's possible this only works with certain types of enemies or when the spawn tile is at a certain location relative to the player (like if the tile is due east vs. due south or something). However, since I didn't try stutter-stepping, it's possible that it's more widely usable than that. Definitely needs more investigation in other parts of the game.

[quote="nemi"][quote]I've been doing something like this for a while.  I go above the top row of gravestones, then go down to the top of the tree to the left of the gravestones, then go back up.  This path skips the spawn tile that produces the flies (same principle as skipping the Gruff Goat in Winters), and usually despawns any flies that appear while walking to the left.[/quote]

Sorry, I should've been more clear: I avoid walking to the tree with this route. I stay right next to the gravestones. I walk down to the tree only if the No Good Flies remain.[/quote]
Yeah, I saw that in the run.  That'd definitely be useful in glitchless.  Cool find.

[quote][quote]Is the spawn/despawn with that mouse consistent?  I have no idea why that would happen. :/  I guess your theory is the mouse is far enough away that it despawns if you just stop right after you cross the tile?[/quote]

The despawn is very consistent--it never failed in a run attempt. I also tested it multiple times on emulator with a save state, and it never failed unless I tried to rush the stutter-walking.

I'm guessing it has to do with how far away the enemy spawns because for triggers that are 2 tiles away from a spawn, stutter-walking has a chance of working only if the enemy spawns near the back of the spawn tile. For triggers that are 3 tiles away (which is the case for the Rowdy Mouse in my run), the spawn location might not actually matter.[/quote]
This could actually do a ton for glitchless, depending on how it works.  From what I saw when I was playing with the spawn script...  last year?  yeah, last year now... <_<  anyway, I remember the enemies in some annoying locations like Pink Cloud sticking around if I just barely triggered their spawn tile and then stood still for a while.  So, it's possible this only works with certain types of enemies or when the spawn tile is at a certain location relative to the player (like if the tile is due east vs. due south or something).  However, since I didn't try stutter-stepping, it's possible that it's more widely usable than that.  Definitely needs more investigation in other parts of the game.

lltemple

Edit history:

lltemple: 2015-02-17 01:53:34 pm

2015-02-17 01:52:09 pm

Quote from __sdfg:

Quote:

Is the spawn/despawn with that mouse consistent? I have no idea why that would happen. :/ I guess your theory is the mouse is far enough away that it despawns if you just stop right after you cross the tile?

The despawn is very consistent--it never failed in a run attempt. I also tested it multiple times on emulator with a save state, and it never failed unless I tried to rush the stutter-walking.

I'm guessing it has to do with how far away the enemy spawns because for triggers that are 2 tiles away from a spawn, stutter-walking has a chance of working only if the enemy spawns near the back of the spawn tile. For triggers that are 3 tiles away (which is the case for the Rowdy Mouse in my run), the spawn location might not actually matter.

This could actually do a ton for glitchless, depending on how it works. From what I saw when I was playing with the spawn script... last year? yeah, last year now... <_< anyway, I remember the enemies in some annoying locations like Pink Cloud sticking around if I just barely triggered their spawn tile and then stood still for a while. So, it's possible this only works with certain types of enemies or when the spawn tile is at a certain location relative to the player (like if the tile is due east vs. due south or something). However, since I didn't try stutter-stepping, it's possible that it's more widely usable than that. Definitely needs more investigation in other parts of the game.

ive been toying with the stutter step despawing in winters cave as well. combined with andy's "progressive despawning" technique, it seems to work fairly consistently.

on a side note, ive been thinking about putting together an updated, and furthermore optimized, purchase list for all the items bought in the glitchless run. we could maybe trim the fat off things that arent really needed (exact big bottle rocket/super bomb numbers etc). i know there has been much debate over skip sandwich dx numbers, so it would be good to really crunch the data and see exactly how many are necessary. ideally this list would run down each purchase and also serve as a guide for newer runners as well. let me know what you guys think or if this is an exercise in futility.

[quote="__sdfg"]
[quote][quote]Is the spawn/despawn with that mouse consistent?  I have no idea why that would happen. :/  I guess your theory is the mouse is far enough away that it despawns if you just stop right after you cross the tile?[/quote]

The despawn is very consistent--it never failed in a run attempt. I also tested it multiple times on emulator with a save state, and it never failed unless I tried to rush the stutter-walking.

I'm guessing it has to do with how far away the enemy spawns because for triggers that are 2 tiles away from a spawn, stutter-walking has a chance of working only if the enemy spawns near the back of the spawn tile. For triggers that are 3 tiles away (which is the case for the Rowdy Mouse in my run), the spawn location might not actually matter.[/quote]
This could actually do a ton for glitchless, depending on how it works.  From what I saw when I was playing with the spawn script...  last year?  yeah, last year now... <_<  anyway, I remember the enemies in some annoying locations like Pink Cloud sticking around if I just barely triggered their spawn tile and then stood still for a while.  So, it's possible this only works with certain types of enemies or when the spawn tile is at a certain location relative to the player (like if the tile is due east vs. due south or something).  However, since I didn't try stutter-stepping, it's possible that it's more widely usable than that.  Definitely needs more investigation in other parts of the game.[/quote]

ive been toying with the stutter step despawing in winters cave as well. combined with andy's "progressive despawning" technique, it seems to work fairly consistently.

on a side note, ive been thinking about putting together an updated, and furthermore optimized, purchase list for all the items bought in the glitchless run. we could maybe trim the fat off things that arent really needed (exact big bottle rocket/super bomb numbers etc). i know there has been much debate over skip sandwich dx numbers, so it would be good to really crunch the data and see exactly how many are necessary. ideally this list would run down each purchase and also serve as a guide for newer runners as well. let me know what you guys think or if this is an exercise in futility.

__sdfg

2015-02-17 02:19:24 pm

D:

Quote from lltemple:

ive been toying with the stutter step despawing in winters cave as well. combined with andy's "progressive despawning" technique, it seems to work fairly consistently.

Makes sense. I'm guessing anything like that where you're going left/right and the enemies stand still should work. Just need to figure out the exact spots to stutter.

Quote:

on a side note, ive been thinking about putting together an updated, and furthermore optimized, purchase list for all the items bought in the glitchless run. we could maybe trim the fat off things that arent really needed (exact big bottle rocket/super bomb numbers etc). i know there has been much debate over skip sandwich dx numbers, so it would be good to really crunch the data and see exactly how many are necessary. ideally this list would run down each purchase and also serve as a guide for newer runners as well. let me know what you guys think or if this is an exercise in futility.

This would also be cool. I tried to keep that in mind when writing the route for the KB page, but I think I threw in an extra rocket/bomb/sandwich in several places in case of bad luck. So, it's likely possible to optimize it more. It would at least be useful if there were something somewhere that explained how to derive the purchasing in the route from the actual requirements.

I used to have a spreadsheet for figuring that out, but it's probably out of date now, and I furthermore don't know how well what I think should be used syncs up with what everyone else is doing now. :/ So I don't know if it's useful anymore.

[quote="lltemple"]ive been toying with the stutter step despawing in winters cave as well. combined with andy's "progressive despawning" technique, it seems to work fairly consistently.[/quote]
Makes sense. I'm guessing anything like that where you're going left/right and the enemies stand still should work. Just need to figure out the exact spots to stutter.

[quote]on a side note, ive been thinking about putting together an updated, and furthermore optimized, purchase list for all the items bought in the glitchless run. we could maybe trim the fat off things that arent really needed (exact big bottle rocket/super bomb numbers etc). i know there has been much debate over skip sandwich dx numbers, so it would be good to really crunch the data and see exactly how many are necessary. ideally this list would run down each purchase and also serve as a guide for newer runners as well. let me know what you guys think or if this is an exercise in futility.
[/quote]
This would also be cool.  I tried to keep that in mind when writing the route for the KB page, but I think I threw in an extra rocket/bomb/sandwich in several places in case of bad luck.  So, it's likely possible to optimize it more.  It would at least be useful if there were something somewhere that explained how to derive the purchasing in the route from the actual requirements.

I used to have a spreadsheet for figuring that out, but it's probably out of date now, and I furthermore don't know how well what I think should be used syncs up with what everyone else is doing now. :/  So I don't know if it's useful anymore.

__sdfg

Edit history:

__sdfg: 2015-02-20 07:32:50 am

__sdfg: 2015-02-20 07:31:55 am

2015-02-20 12:45:45 am

D:

Okay, I think this spreadsheet is postable now. Still not sure it matches what most people are doing, but I think at least all the formulae work and it matches what's on the KB.

Everything to the left of the thick border is supposed to be edited by you. The stuff on the right is supposed to be calculated automatically. Inserting/deleting rows sometimes messes with the cell references in the automatic columns, so you might have to drag down from one of the earlier rows to fix things. >_> But anyway, this is what I've used for route planning in the past. Hope it's helpful to someone.

Also, this assumes you're doing the RNG manipulation in Onett. I don't have notes anymore on how to manage your experience/money if you don't do that manipulation. It should be pretty easy to put the other route back together if anyone needs that, though...

EDIT: I've also put a copy on Google Sheets. It looks like the only thing that broke during the conversion was the conditional formatting, which was easy to fix. Scrolling in it in Firefox is super slow, though. :/ PM me if you'd like edit privileges...

Okay, I think this spreadsheet is postable now.  Still not sure it matches what most people are doing, but I think at least all the formulae work and it matches what's on the KB.

Everything to the left of the thick border is supposed to be edited by you.  The stuff on the right is supposed to be calculated automatically.  Inserting/deleting rows sometimes messes with the cell references in the automatic columns, so you might have to drag down from one of the earlier rows to fix things. >_>  But anyway, this is what I've used for route planning in the past.  Hope it's helpful to someone.

Also, this assumes you're doing the RNG manipulation in Onett.  I don't have notes anymore on how to manage your experience/money if you don't do that manipulation.  It should be pretty easy to put the other route back together if anyone needs that, though...

[b]EDIT[/b]:  I've also put a [url=https://docs.google.com/spreadsheets/d/1vlPrhs_BoatPRdaZTO91wvGLZgPMeo-LQYcXfa3z5B0/edit?usp=sharing]copy on Google Sheets[/url].  It looks like the only thing that broke during the conversion was the conditional formatting, which was easy to fix.  Scrolling in it in Firefox is super slow, though. :/  PM me if you'd like edit privileges...

Attachment:

EarthBound glitchless route notes.ods

lltemple

2015-02-23 02:00:22 pm

Quote from __sdfg:

Okay, I think this spreadsheet is postable now. Still not sure it matches what most people are doing, but I think at least all the formulae work and it matches what's on the KB.

Everything to the left of the thick border is supposed to be edited by you. The stuff on the right is supposed to be calculated automatically. Inserting/deleting rows sometimes messes with the cell references in the automatic columns, so you might have to drag down from one of the earlier rows to fix things. >_> But anyway, this is what I've used for route planning in the past. Hope it's helpful to someone.

Also, this assumes you're doing the RNG manipulation in Onett. I don't have notes anymore on how to manage your experience/money if you don't do that manipulation. It should be pretty easy to put the other route back together if anyone needs that, though...

EDIT: I've also put a copy on Google Sheets. It looks like the only thing that broke during the conversion was the conditional formatting, which was easy to fix. Scrolling in it in Firefox is super slow, though. :/ PM me if you'd like edit privileges...

great stuff, as usual, sdfg. over the next week or so im going to run all this info by the other guys in the community and see what numbers we can all agree on. then hopefully get a nice solid reference file made. thanks for sharing the info!

[quote="__sdfg"]Okay, I think this spreadsheet is postable now.  Still not sure it matches what most people are doing, but I think at least all the formulae work and it matches what's on the KB.

Everything to the left of the thick border is supposed to be edited by you.  The stuff on the right is supposed to be calculated automatically.  Inserting/deleting rows sometimes messes with the cell references in the automatic columns, so you might have to drag down from one of the earlier rows to fix things. >_>  But anyway, this is what I've used for route planning in the past.  Hope it's helpful to someone.

Also, this assumes you're doing the RNG manipulation in Onett.  I don't have notes anymore on how to manage your experience/money if you don't do that manipulation.  It should be pretty easy to put the other route back together if anyone needs that, though...

[b]EDIT[/b]:  I've also put a [url=https://docs.google.com/spreadsheets/d/1vlPrhs_BoatPRdaZTO91wvGLZgPMeo-LQYcXfa3z5B0/edit?usp=sharing]copy on Google Sheets[/url].  It looks like the only thing that broke during the conversion was the conditional formatting, which was easy to fix.  Scrolling in it in Firefox is super slow, though. :/  PM me if you'd like edit privileges...[/quote]

great stuff, as usual, sdfg. over the next week or so im going to run all this info by the other guys in the community and see what numbers we can all agree on. then hopefully get a nice solid reference file made. thanks for sharing the info!

__sdfg

2015-02-23 05:07:37 pm

D:

Cool, glad to help.

I can think of a few things I do in my route that I don't think anyone else does, so lemme know if you run into anything where nobody can figure out why I'm buying/not buying something.

__sdfg

2015-05-17 08:27:54 pm

D:

I had a little free time and I've been feeling bad seeing runs end in the police station, so I found a different setup for that part of the RNG route: . I haven't really tested it enough to say if it's more consistent than the old method, but I think it leaves fewer opportunities for enemies to move unexpectedly or for Ness to accidentally cross a tile boundary, so I'm hoping it's more consistent.

The tile counter thing changes differently on the right side of the police station than it does on the left, so this might mess up any RNG routes that go past the fight with the police. I didn't see a good way to fix that, unfortunately.

nemi

Edit history:

nemi: 2015-09-27 03:14:28 pm

2015-09-27 03:02:15 pm

Quote from __sdfg:

I made a Lua script for detecting enemy spawns. It is attached to this post. The way the script works is pretty simple:

Places where the game can randomly spawn enemies are highlighted by blue squares.
If you trigger a potential spawn, but the game chooses not to spawn an enemy there, the script draws a white label indicating what type of enemy group was triggered.
If you actually do spawn an enemy, the script draws a red label instead.

My intent in writing the script was to help find paths that prevent the game from even trying to spawn enemies, thus removing some randomness from the game. Unfortunately, I spent about three hours playing around with the script and didn't find much. There's probably stuff I didn't find, though. I plan to go through that highlight tomorrow and post timestamps for anything that seems interesting.

You can also use the script to learn where enemy spawns are likely to be triggered and where the enemies usually appear. I'm probably never going to put that much effort into running the game, but it's an option. Tongue

The script requires BizHawk 1.6.0a. Due to a bug in that release, though, you need to do some configuration within the script to make the blue squares show up. Please see the comments at the top of the script for information. The bug should be fixed in the next BizHawk release; assuming it is, I'll post another version of the script that doesn't require the extra config when that release is available.

I also recommend using at least 2x zoom so the screen isn't completely covered in text.

Please report any issues with the script here (or PM me).

This is a really good script, and I tried to go through as much of the game as I could with it. The attached zip file contains screenshots of spawn skips I managed to find. Some of these skips are already known, but I thought it might be helpful to have screenshots.

Some of these skips aren't helpful--e.g. they skip low-rate spawns, or the enemies are avoided with Teleport or Skip Sandwiches anyway--but it might be good to be aware of them. Some of the more helpful ones:

PRV: A few skips at the beginning, middle, and along the stream after crossing the second bridge.
Gold Mine: Couple of skips of 30% spawns near the middle of the mine.
Stonehenge: Skip a couple of 60% spawns in the 5th room.
Lumine Hall: Skip a couple of Fobby spawns before the Rabbit's Foot.

While I was using this script, I noticed a few things about spawns in general:

Spawn triggers to the left of a spawn are 3 tiles away from the spawn. Hence, stutter-stepping has some chance of working on most spawns if you approach from the left.
Triggers above a spawn are also 3 tiles away from the spawn. Stutter-stepping has some chance of working across these triggers as well, but the enemy needs to spawn farther away compared with when approaching from the left.
Triggers to the right or below a spawn are 2 tiles away.
When walking left or right across a vertical trigger, it activates when the front of Ness's sprite touches the trigger.
When walking down through a horizontal trigger, it activates when the top of Ness's head moves down across the trigger.
When walking up through a horizontal trigger, it activates when the bottom of Ness's feet moves up across the trigger.
Triggers can randomly not activate, but I don't know what causes this. This causes 100% spawns to occasionally not spawn anything.

[quote="__sdfg"]I made a Lua script for detecting enemy spawns.  It is attached to this post.  The way the script works is pretty simple:
[list]
[li]Places where the game can randomly spawn enemies are highlighted by blue squares.[/li]
[li]If you trigger a potential spawn, but the game chooses not to spawn an enemy there, the script draws a white label indicating what type of enemy group was triggered.[/li]
[li]If you actually do spawn an enemy, the script draws a red label instead.[/li]
[/list]
My intent in writing the script was to help find paths that prevent the game from even trying to spawn enemies, thus removing some randomness from the game.  Unfortunately, I spent [url=http://www.twitch.tv/uusdfg/c/3851950]about three hours playing around with the script[/url] and didn't find much.  There's probably stuff I didn't find, though.  I plan to go through that highlight tomorrow and post timestamps for anything that seems interesting.

You can also use the script to learn where enemy spawns are likely to be triggered and where the enemies usually appear.  I'm probably never going to put that much effort into running the game, but it's an option. :P

The script requires BizHawk 1.6.0a.  Due to a bug in that release, though, you need to do some configuration within the script to make the blue squares show up.  Please see the comments at the top of the script for information.  The bug should be fixed in the next BizHawk release; assuming it is, I'll post another version of the script that doesn't require the extra config when that release is available.

I also recommend using at least 2x zoom so the screen isn't completely covered in text.

Please report any issues with the script here (or PM me).[/quote]

This is a really good script, and I tried to go through as much of the game as I could with it. The attached zip file contains screenshots of spawn skips I managed to find. Some of these skips are already known, but I thought it might be helpful to have screenshots.

Some of these skips aren't helpful--e.g. they skip low-rate spawns, or the enemies are avoided with Teleport or Skip Sandwiches anyway--but it might be good to be aware of them. Some of the more helpful ones:
[ol]
    [li]PRV: A few skips at the beginning, middle, and along the stream after crossing the second bridge.[/li]
    [li]Gold Mine: Couple of skips of 30% spawns near the middle of the mine.[/li]
    [li]Stonehenge: Skip a couple of 60% spawns in the 5th room.[/li]
    [li]Lumine Hall: Skip a couple of Fobby spawns before the Rabbit's Foot.[/li]
[/ol]

While I was using this script, I noticed a few things about spawns in general:
[ul]
    [li]Spawn triggers to the left of a spawn are 3 tiles away from the spawn. Hence, stutter-stepping has some chance of working on most spawns if you approach from the left.[/li]
    [li]Triggers above a spawn are also 3 tiles away from the spawn. Stutter-stepping has some chance of working across these triggers as well, but the enemy needs to spawn farther away compared with when approaching from the left.[/li]
    [li]Triggers to the right or below a spawn are 2 tiles away.[/li]
    [li]When walking left or right across a vertical trigger, it activates when the front of Ness's sprite touches the trigger.[/li]
    [li]When walking down through a horizontal trigger, it activates when the top of Ness's head moves down across the trigger.[/li]
    [li]When walking up through a horizontal trigger, it activates when the bottom of Ness's feet moves up across the trigger.[/li]
    [li]Triggers can randomly not activate, but I don't know what causes this. This causes 100% spawns to occasionally not spawn anything.[/li]
[/ul]

nemi

2015-09-27 10:47:59 pm

Sorry, made a small correction to one of the screenshots, and it doesn't seem like I can update the attachment on the previous post.

Attachment:

spawnSkips.zip