Skip to content

Red Brinstar Fireflea Room: low energy spark to block - #2972

Open
dragonsinth wants to merge 5 commits into
vg-json-data:masterfrom
dragonsinth:rbfleaspark
Open

dragonsinth wants to merge 5 commits into
vg-json-data:masterfrom
dragonsinth:rbfleaspark

Conversation

@dragonsinth

@dragonsinth dragonsinth commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Copilot AI lite review requested due to automatic review settings September 9, 2026 02:07

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The changes are self-contained data additions with consistent schema usage (new strats without IDs, notable added with updated nextNotableId) and no detected structural issues.

Pull request overview

Adds a new “Low Energy Spark to Block” technique/strat option for Red Brinstar Fireflea Room, expanding the room’s shinespark routing logic to account for intentionally low-energy horizontal midair sparks.

Changes:

  • Added two new strats for reaching the block via a low-energy midair horizontal shinespark when entering shinecharged or shinecharging.
  • Added a corresponding notable (“Low Energy Spark to Block”) and advanced nextNotableId.
File summaries
File Description
region/brinstar/red/Red Brinstar Fireflea Room.json Adds new low-energy shinespark strats and a notable to document/enable the technique.
Review details
  • Files reviewed: 1/1 changed files
  • Comments generated: 0
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@kjbranch kjbranch left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs a much more detailed description.

  • where to spark from
  • mention that being higher gives more wiggle room when falling

{"shineChargeFrames": 42},
"canHorizontalMidairShinespark",
{"resourceAtMost": [{"type": "RegularEnergy", "count": 99}]},
{"shinespark": {"frames": 70, "excessFrames": 4}}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think with these excess frames, you would need to start in a different position, which is then canControllShinesparkEnd.

Suggested change
{"shinespark": {"frames": 70, "excessFrames": 4}}
{"shinespark": {"frames": 70, "excessFrames": 0}}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I was testing this out, I was normalizing the start position to be close to the ceiling, and 2-3 tiles right of the end of the platform. So then from that start, with 95-99 hp I was close enough to the block to fall into it by holding left or right. So this line was me trying to reflect what I tested, but I'm not dogmatic about it, we could just say you need exactly 99.

@dragonsinth dragonsinth Sep 9, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-testing, at 95 you need a pretty big jump forward. So I think your inclination to just normalize at 99 is probably right. With 99 energy, the startup position is incredibly lenient, anywhere from directly over the last platform tile, up to 6 tiles out, works as long as you're close to the ceiling.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically there's a 7-tile window that works, because ending the spark anywhere from -3 to +3 allows you to fall onto to the block.

@dragonsinth

Copy link
Copy Markdown
Contributor Author

This needs a much more detailed description.

  • where to spark from
  • mention that being higher gives more wiggle room when falling

True, in my head I was imagining that it's paired with a video; but I'll call this out in more detail.

@dragonsinth

Copy link
Copy Markdown
Contributor Author

Updated the description, removed the excess frames.

@dragonsinth

Copy link
Copy Markdown
Contributor Author

@osse101

},
"requires": [
{"notable": "Low Energy Spark to Block"},
{"shineChargeFrames": 42},

@blkerby blkerby Sep 15, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
{"shineChargeFrames": 42},
{"shineChargeFrames": 30},

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How'd you get a number that low? @kjbranch told me I should come in with 0 momentum.

https://videos.maprando.com/video/10995 I measured 174 - 131 - 1 = 42

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it makes a difference, I had Spark Booster no Blue.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can spark from closer to the door. Updated the suggestion to 30 frames after messing with it a bit more. The randomizer has leniency on shinecharge frames so it won't end up being expected to be done this tight except on the highest difficulties.

https://videos.maprando.com/video/11003

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay true. I was shooting my video to show the optimal positioning more than the minimum frames. So you'd only have to get it that tight on insane; on "normal" settings the shinespark leniency will be fine.

Updated all comeInShinecharging strats from 1 to be 5, 0, and all the ones from 2 to be 4, 0.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I didn't realize openEnd: 1 on the end of the charge meant falling off the block, I assumed it just meant you had like half a block more because there wasn't an immediate wall.

@blkerby

blkerby commented Sep 15, 2026

Copy link
Copy Markdown
Contributor
  • The strats should end at node 3 rather than node 2.
  • I would remove the part of the note about using the Waver for i-frames, as there are several possible options to progress from node 3 to node 2 which are covered in other strats.
  • The comeInShinecharging should have length: 5 (door shell isn't included on entry since Samus spawns past it) and openEnd: 0 (since we don't want to include sliding off the runway). It looks like this was an error in the existing 1->2 strat (id: 10), which could also use a correction if you don't mind.

@dragonsinth

Copy link
Copy Markdown
Contributor Author
  • The strats should end at node 3 rather than node 2.

Whoops, fixed.

  • I would remove the part of the note about using the Waver for i-frames, as there are several possible options to progress from node 3 to node 2 which are covered in other strats.

Done.

  • The comeInShinecharging should have length: 5 (door shell isn't included on entry since Samus spawns past it) and openEnd: 0 (since we don't want to include sliding off the runway). It looks like this was an error in the existing 1->2 strat (id: 10), which could also use a correction if you don't mind.

Fixed, but I should note that in this room, all of the comeInShinecharging strats from node 2 are inconsitent with each other. It looks like they should all be length 4, openEnd 0? Although-- I don't know enough about spikesuit / x-mode to know, maybe the intent is to fall onto the spikes.

@blkerby

blkerby commented Sep 17, 2026

Copy link
Copy Markdown
Contributor

Fixed, but I should note that in this room, all of the comeInShinecharging strats from node 2 are inconsitent with each other. It looks like they should all be length 4, openEnd 0?

Right, I think the node 2 ones should all be length 4, openEnd 0. At best, sliding off would make you take an extra spike hit which isn't modeled.

The way it works in general:

  • for a spikesuit you could slide off as long as you can be fully morphed before you reach the spikes. At node 2, I doubt there would be enough vertical space to make that work (though I haven't tested it), and even if somehow possible it would be need higher tech requirements, so making it openEnd: 0 should be right either way. At node 1, I think you could slide off into a spikesuit with no problem since there's lots of space.
  • for an X-mode blue suit, you need to bounce before the X-mode, so sliding off would mean the bounce happens on the spikes, meaning you would need to take an extra spike hit. I would probably just shorten the runways to make them openEnd: 0 rather than trying to add an alternative with an extra spike hit.

But yeah, looks like node 1 also has other strats done inconsistently. We could probably use another pass through the whole game's logic to see if there are more inconsistencies like this (there probably are).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants