Hi there. Here is one of these top SM TASers and as it turns out, based on extrapolating, generalizing from older game crashes and wild shenanigans involving 2 chest wizards' spells to hit Arthur with such spell while already having been transformed shortly beforehand that have been found by others, and with help from Sniq, another SM TASer, to determine and confirm if ACE was reached, I've found ACE to be possible not only in the 2nd or the last stage, but already near the end of the 1st stage upon realizing that the potential for it could be there due to similar ACE-allowing behavior of glitches in other games and putting it to the test for SGNG. I then have been doing a good amount of theoretical and practical, near-optimized routing (comparison) work and tests for what the fastest approach would be to trigger ACE under TAS circumstances (as there is different chests and orders of opening them that are available for the ACE setup, and different chest weapons and from enemies' pots dropped weapons available for in-stage route strategizing, including their weapon magic with gold armor, but also RNG relevant for lag reduction as well as a rare, specific glitch at which fire demons can spawn as body parts of other enemies that may turn out to be relevant for lag reduction). Some information about that should be possible to find in the SGNG Discord server's discussion history.

I've also made a video of a compilation of various glitch investigation tests I did some years ago:

I'd have a bunch of further movie files, glitch detail notes and ideas for more tests to do that I though haven't put up anywhere so far, as I haven't been working on SGNG for a few years since that incompleted work on that TAS. Part of the reason for that is that the game is very laggy, and RNG playing an important role for that, too, but also that I have some more ideas for opening of pairs of chests for different item combinations from them and frame perfect collection or interaction with those items that (for me) would remain to be done just in case that among these options there may be another way to glitch out the game for then possibly even earlier ACE access which could obsolete a lot of the current work done for triggering ACE from the 8th or 9th chest's wizard spell in stage 1. But I'm also interested in researching many more SNES games and finishing other SNES game TAS projects before I'd feel inclined to continue working on SGNG TASing and glitch hunting. But yeah so there has been some work done on the game, but not that prominently, I suppose.

Okay here is an introduction into 3 genuinely really sophisticated general types of strategies (likely involving RAM search & watch and potentially disassembling/understanding the code related to RNG to find and figure out the behavior of RNG and how its values are mapped to outcomes at a critical event, figuring out a sufficient amount of bufferable movement branches up to such event from a suitable starting place and how to use them to maximize the probability of a favorable outcome at the event), so bear with me.

A different way to summarize what follows: A few potentially up to significantly probability of favorable pseudo-random outcomes increasing general methodologies for games with frame-based or CPU-cycle-based RNG, provided the RNG's sequence of future RNG values is fixed, or in some situations possibly even also input-based RNG (for when the ''RNG's path'' is directly input-dependent but there being restrictions to when player input timing affects it or the number of frame perfect required inputs being low).

Be aware that I'm not forcing anyone to read all this, so just see it as an invitational write-up (which also took its due time and effort) to the extent to which there may be interest in it by others. I'm mainly motivating myself to write down and share/spread these 3 general luck manipulation approaches further because I expect (but also hope) that at least some of these can still at least in principle find many applications across various games, where such applications may not have been discovered yet. While I'll be referring to ''movement'' being what is buffered, this approach is about any buffered activity via inputs and is not limited to games in which some character is moved around.

Explanation of the general problem type & setting: For some kinds of goals in games (like speedrunning or completing specific challenges with additional constraints to the gameplay) sometimes one may run into situations where a point in time during the gameplay comes up that has an event for which the outcome significantly depends on the value of a pseudo-random number (produced by a deterministic random number generator) to get a favorable outcome or not, and where it would be useful to have some kind of setup or approach for it that can increase the chances of getting the desired outcome. And in the following I'll try to explain a few methods that can be used for such purposes, but the applicability of these methods expectedly are very limited.

Note that throughout this write-up, whenever I'm using the term ''bufferable'' (or ''buffered''), I'm using a weaker (although still good enough) notion of it than the meaning that is commonly understood with the term, namely as ''input-wise bufferable'' where upon some initial frame in which one or more certain buttons are pressed, the configuration of which buttons are pressed and which aren't pressed on the input device stays constant until after passing the time of the event for which the effect of the input buffer was intended. In particular, by ''bufferable'' I'm referring to ''game-state-dynamic-preservation-wise bufferable'', or in better words: A given set of movements (or sequences of actions), that only deviate from each other in the timing of pressing or releasing inputs that occur in any frame and contain reasonably wide frame windows for each button press or release, represents and is in here referred to as 1 bufferable movement in this sense, if all cases start out with the same part of the whole game-state that ends up being relevant to an associated RNG-manipulation and if there exists at least 1 frame during the whole movement process upon which all in the movement set entailed movements coincide in the part of the whole game-state that from there on ends up being relevant to an associated RNG-manipulation, and correspond to the same input-wise buffered movement (i.e. coincidence in the commonly understood sense). This means that there can be intermediate deviations between such bufferable movements e.g. for when a button is pressed or released, as long as these differences in the input sequences don't lead to a specific RNG-manipulation failing when there is at least 1 case among them where it works. Investigating where the limits are for individual button press or release timings for such bufferable movement (in the weaker, but less restrictive sense) can be done using TAS tools (especially in case there may be subtle otherwise unnoticed differences such as lag differences leading to deviations, expectedly especially rather on consoles than emulators, in some cases due to the Sound Processing Unit), and concrete examples of such bufferable movement can be found in the bullet point list beneath.

Because of the nature of bufferable movements for RNG-manipulations these kind of approaches may in some cases be not useful for speedrunning purposes, e.g. if the bufferable movement just loses too much time over a faster alternative that doesn't allow as much to keep any kind of control over relevant parts of the game state development, so that foregoing bufferable movement would be preferable, and especially if any potentially required additional setup time involved in it is too much compared to the benefits that may come from it.

Also note that while I'm only going over button inputs for these approaches, they may also just as much hold for when control stick movement is involved, to the extent to which this is controllable.

Regarding what situations RNG-manipulation approaches start out with, in principle, these approaches may in theory at least potentially have a chance to work from any point at which one can start or continue the game (depending on how the game treats RNG values, and e.g. if there is frames at which a normalization of the RNG value occurs), but the preferable choice of the starting location typically depends on the goal of the RNG-manipulation, and the same for other parameters that may play a role. In particular if at saving the game the current RNG value or some change of its behavior is saved alongside other variable values, one may still be able to construct setups, either for specific saved RNG values or behaviors of it when the game is powered on again, but might rely on being able to save with the right RNG value conditions and maybe being able to identify somehow if this is the case, or one may even be able to construct a setup for any saved RNG value case to continue with.

Figuring out exactly which RNG values will lead to what outcome for a given RNG-dependent event as well as using lua scripts or other means to map this info onto the given advancement of the RNG for the buffered movement for the range of different RNG values it provides to arrive at the critical event that relies on certain RNG for a favorable outcome would be an own topic and would have to be figured out individually, but here is some links to pages from TASVideos that explain how to identify memory addresses associated to game variables in general ( http://tasvideos.org/MemorySearch.html ) and in particular RNG variables and explain common properties and behaviors of it: http://tasvideos.org/LuckManipulation.html

I. In the following I present a concrete example case (from which can be abstracted to carry this approach over to other games) of 1 kind of RNG-manipulation approach for a game in which this approach was successfully developed and tested, which hopefully helps making this more understandable:

Here would be a visualization corresponding to what is described below:

Game, start situation & (local area) setting: The game in question in this case is Super Metroid, the start situation when the game is turned on consists in its relevant parts of having 1 (of in total 3) save files prepared to the point that upon starting to play on this save file the introduction cut-scenes are skipped (which otherwise would just add significantly to the amount of not input-wise bufferable inputs required to advance past it) so the player would start with Samus automatically on her own riding down the elevator of Ceres Station (the game's introductory area). Ceres Station consists of 6 rooms in total, with this elevator room on the left end and an introduction boss, Ridley, being located at the other end in the final room to the right, with all other rooms lacking any noteworthy activity going on in them.

Goal of the approach: The specific goal in question in this case would be to make the odds of Samus entering and arriving at Ridley's room in Ceres Station such that the pattern of Ridley's attacks (of which there exist 3 different kinds) avoid 1 kind of attack (where Ridley directly accelerates towards Samus in a ram attack which is especially hard to dodge) for as long as possible as high as feasible, for the purpose of allowing the player to shoot 100 projectiles at Ridley during this time and end the boss encounter that way without taking any damage (which itself would be just a part of a game completion with least necessary damage taken). Note that the purpose here is to increase the odds of getting any good pattern, while no setup for it is required for a damage-less encounter, but in this case one might need much more time and might rely on many more attempts until successfully passing this boss encounter damage-less. And as side-effect, not only can this then help to get any good pattern of attacks, but can allow to identify mid-fight which particular attack pattern one currently is confronted with (namely as soon as it deviates from any attack patterns associated to RNG values for nearby frames at which the room could instead have been entered, to know from that point on exactly what to expect for the rest of the encounter, and not only that, but another side effect in this case is (and in general can be) that instead of practicing the boss encounter for various sufficiently long patterns, one can reduce the practice (or the need for preparedness) to an up to much smaller set of workable cases. With this written, I think an approach like this in some cases may also make the difference between some special ruleset category being barely accessible for speedrunning or more accessible.

RNG-dependent target event/behavior of the manipulation: Being able to get past Ridley without getting hit heavily depends on Ridley using a ram attack or not within the first roughly 5 to 7 attacks, with the 3 different attack options being (i) straight ramming Samus which is almost unavoidable, (ii) flying in a circle which is mediocrely dangerous since sometimes it amounts to taking a 50% bet on 1 of 2 spots that are usually safe from the tail that Ridley can whip Samus with, and then there is (iii) the fireball attack where 1 such attack consists of 2 fireball waves which is the most favorable option because it is easy to dodge and is most time-consuming for Ridley while shooting Ridley. As long as Ridley doesn't use the ram attack, Ridley's entire behavior including the attack pattern is fixed and in particular independent of what the player does once Samus is in the room and only depends on the RNG (Random Number Generator) value with which Ridley's room is entered, or (effectively equivalent to that) the total amount of time (in terms of the global amount of frames) that was needed to enter the room upon powering up the game. So the idea behind this particular approach to achieve this goal was to make sure that the RNG variable has a suitable value when Samus enters Ridley's room.

Obtaining an accurate, complete, ordered list of the available RNG value cases that the target event/behavior depends on: For the purpose of this goal Taco (a former Super Metroid TASer) made a lua script that allowed me to get a finite, chronologically ordered and complete list of fixed Ridley attack patterns always up to the 1st ram attack (from which on the pattern wouldn't be independent of Samus' movement in the room anymore) for all candidate frames for Samus' arrival at Ridley's room (or equivalently for all RNG values with which the room can be entered). Alternatively one could have used RAM Watch for the RNG on an accurate SNES emulator (like lsnes) to manually write down what patterns are encountered for different RNG values with which Ridley's room was visited, but this would have taken much more effort.

Evaluation of the obtained list of available potential RNG value candidates for the manipulation for the purpose of probability maximization of a successful outcome with the buffered movement approach: With and in this list I was able to locate the longest time interval (which was 4 frames in a row with by their associated RNG values determined suitable patterns) that consists only of those Ridley patterns where it would take Ridley long enough (in terms of time but also number of attacks) to be able to do a ram attack. This means that if one would practice just those few different patterns so that one can consistently survive them without taking damage, then the only remaining problem would be to make sure (with an as consistent as possible setup) that Samus arrives in that room within this small frame range.

Creation of one or more base approaches that are and represent types of bufferable movement (besides potentially existing not bufferable components) from a calibrated starting situation (e.g. powering on the game with fixed SRAM) up to the target event/behavior of the intended RNG-manipulation: What can be exploited once Ceres starts up, is the fact that there is a whole variety of easily bufferable (that means with long frame windows for player inputs where it doesn't matter if one is a frame off with input as long as the input happens within the respective frame window) manners in which one can make Samus move with consistently always the same amount of frames through Ceres Station up to Ridley (due to room geometry reasons, a variety of easily controllable buffered player character movement options, and the long duration of door transitions). This holds true at least for decent emulators, while for actual consoles there may be slight inconsistencies when a lag frame more or less may be present (typically due to synchronizing issues with the Sound Processing Unit, apparently), but it'd still be close enough in that case. In the following I'll explain the initially devised default bufferable movement (from which alterations were made to adapt the timing as necessary for aligning the advancement of the RNG values with entering Ridley's room) in this particular case through the rooms of Ceres Station. During the elevator ride by buffering Right Samus will walk off the elevator platform. Then starting to hold Left within a decently long frame window (for making any frame timing within there lead to these cases merging back into equivalent states later) while Samus is falling midair turns Samus around and aligns Samus against the elevator platform's edge and continues moving Samus to the left after Samus moves far enough down to pass the platform's edge while falling. Then the same (just in the other direction) done by starting to hold Right towards the left edge of the next lower central platform that Samus falls onto works analogously, and continuing aligns Samus at the opening door at the room's floor and leads to the next room. Then (while still holding Right) a full spinjump is started (by pressing & holding Jump for at least as long as it takes Samus' jump to reach its apex) but only once Samus fully walked off and down the at first diagonally sloped floor onto the even low floor but before walking into the even high grounds in the center to land there and continue holding Right to walk into the next room. Then one starts holding Left once Samus falls again (off the floor with the upper stairs) to change the movement direction just like it was done for the elevator room platforms, and finally the same except rightwards is done again by starting to hold Right once Samus falls off the floor yet again, and from there one just continues to hold Right to eventually enter Ridley's room.

Devising & gathering variations of one or more RNG-manipulation base approaches by which alternate, still bufferable movement can branch off from a base approach: The following bullet points describe a quick list of concrete examples for the main options that are available to change up in which (for the relevant aspects of the game state development) bufferable manner Samus moves through the rooms of Ceres Station. ° Adding any fixed amount of so-called armpumps (changes to the angle at which Samus' arm cannon is held) while Samus moves along the ground, as each of them moves Samus forwards exactly 1 pixel each time; ° Adding any fixed even amount of turnarounds to go backwards through any door transition (by holding Left or Right during door transitions to move to the backwards direction) to enter and move through any amount of previous rooms before turning around again analogously; ° Adding any fixed amount of starting to hold the Dash button during any transition to run instead of walk through the next room; ° Adding any fixed amount of releasing or starting to hold Dash in the middle of Samus' movement through a room safely while Samus is falling midair or just after Samus bonked into a door (which opens up on its own based on proximity, with a decently long delay after bonking against it); ° Adding any fixed amount of spinjumps with (easily bufferable) maximal jump height while making sure each of them safely (i.e. with sufficient frame window) starts at some given floor height specific to that jump and safely lands on another floor height specific to that jump, while moving in only 1 direction (rightwards or leftwards) throughout the whole jump (so that even though the sideways movement speed during the jump is different from the movement speed on ground, the total amount of time spent moving this way midair stays fixed, independent of jumping earlier or later).

Identifying/Determining the RNG value (or time, by the amount of frames) towards which the whole RNG-manipulation approach (with its bufferable and not bufferable components) shall be calibrated (by it being the most frequent occurring case in practice, in the end): In general, the longest amount of consecutive frames that correspond to favorable outcomes obtained with them might not necessarily be the best case to aim for with the bufferable component (and the degree of freedom that comes with it) of an RNG-manipulation approach, but depending on a player's personal probability distribution of relative arrival times at the target event of the RNG-manipulation, aiming for other arrival times (e.g. after having to rapidly mash buttons to advance past some menus) may be better. To go a bit into mathematical modelling for such a situation using probability theory, one could interpret it as follows: Let the positive real numbers p(-n), ..., p(0), ..., p(n) (with sum equal to 1) be a given and fixed probability distribution for arrival frames (from -n to n for some positive integer n, with central frame 0 being a chosen reference frame) at the target event of an RNG-manipulation, for a given person and the setup the person is using and the manner in which the person is approaching rapid button mashing to pass not bufferable components of the manipulation. Then for a given corresponding distribution (d(-n), ..., d(0), ..., d(n)) (which would represent the frame range to which one is calibrating the RNG-manipulation) of truth values (with 1 for true and 0 for false) for a useful or useless outcome occurring on the associated frames (assuming any useful outcome in there is equally good as any other), in order to maximize the chances of success one might want to maximize the sum p(-n)°d(-n) + ... + p(0)°d(0) + ... + p(n)°d(n). An example to illustrate how different situations would compare to each other based on this modelling approach: Let p(2 frames early) = 20%, p(1 frame early) = 20%, p(aimed for frame) = 20%, p(1 frame late) = 20%, p(2 frames late) = 20% hold. Then calibrating an RNG-manipulation approach around a longer interval of consecutive frames with useful outcomes by centralizing the approach around that, like e.g. with (d(-2) = 0, d(-1) = 1, d(0) = 1, d(1) = 1, d(2) = 0) with associated chance of success according to the model being 0°20% + 1°20% + 1°20% + 1°20% + 0°20% = 60%, which would contain a 3 frames long window of useful outcomes may nonetheless end up worse than centering such a setup elsewhere e.g. when there's nearby split up frame windows with useful outcomes, such as with (d(-2) = 1, d(-1) = 1, d(0) = 0, d(1) = 1, d(2) = 1) with associated chance of success according to the model being 1°20% + 1°20% + 0°20% + 1°20% + 1°20% = 80%. Furthermore, for rapid button mashing parts of an RNG-manipulation approach, in order to advance past menus in a game each time nearly as soon as possible, in some of those cases after a lot of practice and experience with what an early and what a delayed advancing past some menu screen looks or sounds like, with more detailed insight into recognizing these differences one may be able later on during the bufferable part of the approach to slightly compensate for such recognized deviations in order to nudge the pace at which one is approaching the target event of the manipulation in the right direction, back into the aimed for frame window, depending on if there exist options to slightly change the pace of the bufferable part of the approach. Using this abstract probabilistic modelling approach, a sequence of 4 consecutive RNG values was found that all provide usable Ridley patterns, which appeared to be the best scenario to aim for (with 1 exception of there being an earlier but possibly too early similar situation of 4 suitable RNG values in a row that was ignored).

Dealing with performing the (for this specific approach a rather straight forward case of) not bufferable components of the RNG-manipulation approach: The remaining task was to then figure out with manual attempts of different versions of the approach at which frame one arrives at Ridley on average (or rather the most frequently if there is no symmetry of the distribution of frequencies to be assumed) and to then figure out to what Ridley pattern (or associated timing or RNG value) each new iteration/version of the approach corresponds to and is calibrated to, within the ordered list of RNG values, and each time compare that to how far (and in what direction) that timing deviates from the target timing that one wants this average arrival frame at Ridley to be in the end (which should be some central frame within a cluster of frames with high local density of strictly good associated patterns) to know how many frames one needs to shift the arrival time forwards or backwards in time using the available controllable bufferable movement options that one has for going through the rooms. The tricky part though is that one has to start from power on or the RNG will not be predictable (as it keeps running on and on almost every frame and the current RNG value is usually unknowable and contained in a large set of possible RNG candidate values), and that there is then a few menus through which one has to advance the game in order to reach Ceres Station. So through these menus the only remaining working option (besides trying to aim for advancing past menus with single inputs, depending on what cues are available for doing so) would be to rapidly mash the Start and Jump buttons (in this game case the only available buttons to advance past the menus) as fast as possible, since the faster it is done the smaller the possible realistic range of frames becomes at which Samus arrives at Ridley, in order to make sure that the number of frames that it takes the player to reach Ceres Station takes always close to the same amount, with as little deviation as possible. And with this method, after having found a suitable version of buffered movement through Ceres Station, the rate of obtaining useful patterns among all samples was 13/30 (without trying to slightly change up the buffered movement as reaction to observing a too long delay before menus were advanced, and with slower button mashing in later samples for quickly advancing past the initial menus).

II. Special case scenario of caging the RNG into a tiny separate loop of RNG values, explained using an example from Super Metroid (for the purpose of subsequent RNG-manipulations): Super Metroid uses a broken version of a Linear Congruential Generator (LCG) ( https://en.wikipedia.org/wiki/Linear_congruential_generator ) in order to calculate a new RNG value based on the previous RNG value or the RNG seed value. Because of a slight deviation from a ''clean'' LCG process (that would just create 1 closed loop of RNG values within which the proceeding RNG would advance forever in 1 direction) for calculating new RNG values, the (directed) graph ( https://media.discordapp.net/attachments/396448200447361024/740000116643201096/Super_Metroid_RNG_graph.png?width=952&height=597 ) consisting of 1 unique vertex for each possible RNG value (which are the integers from 0 to 65535) and 1 directed edge from any vertex that represents some RNG value to another vertex that represents another RNG value if the former RNG value as input into the LCG produces the latter RNG value consists of 3 separate components ( https://en.wikipedia.org/wiki/Component_(graph_theory) ), each with their own loops (that the RNG is forced to run into and stay in eventually) of different lengths. Now there is certain rooms in the game that have certain kinds of enemies that will force the current RNG value to be set to always the same fixed RNG value specific to the kind of enemy in the room for 1 frame when the room is entered, from where the flow of future RNG values will continue. Furthermore, only for rooms that load or have lava or acid in them, during normal gameplay frames in those rooms, the high byte of the RNG value will be swapped with the low byte of the RNG value exactly once per frame (so that e.g. an RNG value VWXY turns into XYVW, with V, W, X, Y being placeholders for hexadecimal values from 0 to F each). This swapping effect is what allows the RNG to jump from 1 component of this RNG graph to another and can be abused to cage the RNG into the smallest graph component consisting of just 1 loop of 87 unique RNG value vertices. There exists a suitable room that is heated, has lava in it and has an enemy of the kind in it that will calibrate the sequence of RNG values to start out at a fixed RNG value at a fixed frame relative to entering the room, which with the right amount of energy and letting this be drained to 00 in an always consistent amount of frames allows to enter the game over screen (during which the swapping of the RNG value's high byte and low byte will not continue anymore) and load the game up at a previous save such that the RNG will be caged in this tiny loop due to the timing of entering the game over screen being chosen (by having the right amount of energy be drained by heat damage) in such a way that the last swap of the high byte and low byte that occurs to the the RNG makes it jump to an RNG value that is part of this tiny RNG value loop of the RNG graph. Now, such kind of approach to cage the RNG in a small and more controllable loop of RNG values may not be available in most games, but for games with similar behavior of the RNG and a small separate loop of RNG values for which there is specific ways for the RNG to enter it, this kind of manipulation may be possible.

III. Another conceivable theoretical approach that one could try to use for RNG-manipulations (in which the goal is to make some favorable RNG-dependent outcome occur) would be in advance developed but in real-time adaptive movement-buffer RNG-manipulation approaches that are branching off to suitable, still bufferable versions of them, based on throughout the buffered movement accumulated - and the RNG value at some chosen specific local reference frame piece-wise further and further specifying - information, allowing to identify what the particular RNG value was at some particular nearby earlier point in time (in that reference frame), or to significantly narrow down the list of RNG values to a concrete small set of remaining RNG values as candidates for what the RNG value could have been at that earlier particular point in time (in that reference frame). However, the applicability of this type of strategy is highly theoretical & speculative and may due to its nature be rather inaccessible to use in almost all cases, and I'm not aware of a single game for which such a strategy has been deployed.

I'd be interested in what other RNG-manipulation approaches of this kind exist already, especially the more convoluted, sophisticated cases. I'm so far besides this concrete case only aware of what I heard about Ninja Gaiden and what might be more of an accidental lucky lining up of for speedruns suitable enemy behaviors throughout the stages as long as the speedrunner keeps moving through the stages with certain strategies at a fast pace and without deviating too much from that pace by making execution mistakes. But I've also come to know a little about how similar RNG-manipulation approaches are utilized in Pokemon game speedruns.

Yes, Unbones, buffering an input through unpausing a game would also be included in this, but to quote my original post: ° Cases where an input needs to happen for only 1 frame but not longer, and in those cases pausing may allow to cut the active gameplay time off and allow to just press and hold that button input rather than having to release it after pressing it for 1 frame. This would also fall within the method I tried to describe, and in this case no input is held through unpausing the game (although admittedly one could also think of no input being held as also being a buffered kind of empty input).

And yes, while one may still use the name pause buffer for this, I frankly find the terminology ''pause buffer'' to be very vague, non-descriptive and non-explicit (and I don't think the whole ''spectrum of its applications'' is generally well-known yet even among experienced speedrunners, especially when there may be not many elaborate explanations that go into different cases covered by it). Hence I tried to think about other aspects that make up the differences between two (or more) qualitatively different versions of executing ''the same'' trick, where some versions involve pausing the game while others don't. Besides that, there is also games in which the gameplay can be halted by other means than pausing, or where there is multiple buttons that pause the game in different ways, so that is also why I tried to use a different wording, namely ''trading [or interchanging] frame perfect inputs'', before going more into the details and the goal that I had in mind, namely the avoidance of having to execute a trick in a manner that requires some inhuman hand movements.

Interesting, Lieutenant_Boo. I do have heard of super swim for Wind Waker HD speedruns, but didn't know very well about the specific execution of it, and yes that does appear to be an example of what I meant (although being related to a control stick, I guess, which I think is probably the most well-known type of pause buffer usage).

I also made a reddit post about this (in here https://www.reddit.com/r/speedrun/comments/hzqjdb/trading_frame_perfect_inputs_as_method_to_make/ ) and explained a bit more about it in a discussion over there, which may go over lesser known cases of using it.

Lieutenant_Boo and Timmiluvs, contrary to both of your (partly correct, but incomplete) understandings of what I attempted to explain, while the method I described does indeed also include certain cases of applications of the well-known pause buffering (namely those cases in which the direction, that is held with a control stick with 360° movement freedom, is for the gameplay instantaneously drastically changed, and only for those cases among these that otherwise would not be possible to be performed, namely without pausing the game), the method that I tried to explain is more general than that so this would only be a particular special case of it. In particular (and maybe I should have made this even more clear in my elaborate post), I am not referring to any pause buffer application cases that are doable without pausing the game already, which includes cases in which pause buffering is solely used for slower approaching of a critical gameplay frame in which a certain button needs to be pressed or released frame perfectly and in isolation from other potentially existing, for a trick necessary frame perfect inputs, because to release or press a button in the right frame (without there being other conditions about inputs that need to be made around the same time) does not require pausing the game for making such a trick humanly doable. The idea that I tried to explain is not just about turning a frame perfect input into an input with a larger input lenience window for successfully executing a trick by introducing a pause, but is focused on cases where introducing a pause is absolutely necessary (solely for reasons that lie within the limitations of the movement speed of the human hand) in order to perform a trick without tool-assistance. And Maybe this clears this up further, so that it is not confused as solely being that kind of pause buffering.

I'd like to explain a general but in most games probably at most restrictively applicable method to effectively ''trade frame perfect inputs'' [which may sound strange and questionable at first if one hasn't heard of that concept before, but I'll elaborate on it below] that can be involved in (speedrun) tricks, for the purpose of transforming bio-mechanically (in the sense of the physical and speed related limits to the human hand) impossible (or at least extremely difficult) to perform TAS-only input patterns required for in-game tricks into more realistic or even decently executable new versions of input patterns for those tricks. I guess one could see it as a separate, advanced step in the same direction in which theory crafting goes for constructing setups that calibrate or normalize various parameters to make performing certain tricks easier.

The idea for this method is to add a suitable frame perfect input for pausing the game to the execution of a trick in order to allow to either simulate a frame perfect immediate button press release (of another input part of a trick) or to be given more time to switch the held inputs up and buffer them through unpausing the game.

If this method can at all be used in a game may depend on the following factors, among others: ° How pausing works in a game: Namely if pressing the pause button halts gameplay instantly or if gameplay is interrupted after a short delay (and in this case what the game's lag behavior is), provided pausing even is an option in the situation or even just in the game in general. ° How the game treats a trick that involves a longer gameplay process when it is interrupted by a pause in the middle of it rather than without a pause (since in some cases the game may react to pausing and continue in terms of game mechanics different than how it would without it, so that pausing doesn't solely delay gameplay).

A rather simple but good example for this that was already independently of my own separate theory crafting found in another community would be Wario World Super Jumps ( ), in which normally about 8 frames after initiating a Dash with an input the jump button has to be pressed, then released in the next frame and pressed again (and then can be held) in the next frame of this 60 Hertz game (for NTSC), in order to get the most jump height out of this (rather than lower jump heights with further off input timing). And to make this trick doable in this case, the frame perfect release of the jump button is avoided and instead a frame perfect pause is introduced in the same frame as the first jump press to create a longer time gap between the first and the second jump press. And while this version of doing the trick stays equivalent in terms of the count of frame perfect inputs, the advantage comes from not being forced to move the finger fast enough anymore for the 2nd jump press in relation to the first and the button release in between, but just having to press it at the right time and in isolation from the first jump press; and this ''de-coupling'' of frame perfect inputs in a chain of inputs is the crucial point here.

More concrete distinguished situations that may be resolvable with this method might be cases like the following ones: ° Cases where one is required to press a direction button in 1 frame and one has to steer away or press another button to input the complete opposite direction in the very next frame (rather than having the lenience for it to take more frames, or especially in cases where one is using a control stick with ''analogue'' inputs, i.e. a fine input field within which joystick positions are polled, rather than just a binary check for e.g. each of 4 different directions for if the direction is held or not) and is not allowed for the input polling to happen anywhere within the process of moving the control stick from 1 side to the other, resulting in the signal sending a value for an intermediate control stick position. And this also includes cases in which an immediate direction switch has to happen again immediately afterwards. ° Especially cases in games that run at very high frame rates like 60 Hertz or 120 or more Hertz, it can make a big difference to break frame perfect input chains required for a trick up (e.g. in a simple case that may be just two different positions of a control stick with 360° movement freedom in 2 consecutive frames), by turning a situation in which one would otherwise need to steer the control stick into another direction at proper angle and inhumanly fast into a situation via pausing the game at the right frame ahead of time or together with the first directional input (depending on how the given game's pause mechanic works, if one can even pause at the time), and then buffering the 2nd directional input through the unpausing process. ° Cases where an input needs to happen for only 1 frame but not longer, and in those cases pausing may allow to cut the active gameplay time off and allow to just press and hold that button input rather than having to release it after pressing it for 1 frame. ° Cases where one has a chain of inputs that need to happen in rapid succession within few frames, where the input chain would be possible to be executed up to some frame but continuing with what follows wouldn't manually be possible when one is forced to execute the 2nd part immediately afterwards; and where one would be able to execute the 2nd part on its own as well, provided one wouldn't be forced to execute the 1st part of it and interruption-less chain that into this 2nd part (because in that case, introducing a buffer time inbetween may be able to resolve this).

Disambiguation: The purpose of the method I'm trying to help giving insights into - while it may also be closely related to other useful applications like providing audio cues or visual references for afterwards as side effect - is not about pausing for the purpose of gaining information or feedback from the game (that one then due to the game pause can actually process and react to in time for use of it later) e.g. to get a better orientation on one's position and surroundings while they are frozen in place or to know when (in relation to unpausing) the next inputs should occur, or if one should pause again (e.g. in a bufferable manner when possible) to let 1 or a few frames pass until one can unpause safely to be able to buffer the next input for a trick (outside of maybe the pause button presses involved in the trick, assuming the trick doesn't require pausing in and of itself, if perfect machine-like inputs are provided like in tool-assisted superplays). Neither do I mean to address cases where the pauseless execution of a trick was previously thought to be impossible but later turned out to be possible to be performed by someone else or with more practice, muscle memory, and different cues (without qualitatively changing the manner in which the trick is attempted to be done), or where the difficulty and associated inconsistency of getting a trick was just too high without pausing, for the plain purpose of separating the input chain (rather than for also getting visual or audible cues), which are their own separate cases. But instead, the sole point here is meant to address cases where the trick in question otherwise can manually just not be performed in general, for cases where this is due to the bio-mechanical limits of human hands, for example, where any amount of practice, cues, muscle memory or reaction times may lead to performances that may be close to successfully executing a trick but turn out to be still unsuccessful. This is the kind of ''dead end'' stuck situation I'm having in mind here, with this alternate method of approaching such situations.

In particular, while this ''input decoupling'' method, or ''frame perfect input trading for bio-mechanical benefits'' also involves pausing the game, it's purpose is not the same as for what's generally referred to as a plain Pause Buffer: ''Buffering a command out of a paused game. Runners can repeatedly pause a game to find the exact frame they want to execute an input on for frame perfect tricks''.

However, I think a method like this also presumably would only be worth considering (in a speedrunning context) for otherwise extremely hard or impossible to in real time execute tricks that at the same time would lead to significant time-saves by making a glitch/trick performable or making an extreme case of a speed-technique doable (like maybe certain backwards longjump setups in Super Mario 64 or something along those lines), e.g. in order to make a short-cut accessible, or to trigger ''game-changing'' effects that allow important new possibilities (like opening up a new category / speedrun branch for a game or making an existing one more extreme, for changes that aren't time-saves but change the category-defining limits of a category). Of course, a pause typically would also cost time and may in speedrunning contexts be part of the trade-off for making a trick possible and/or easier to execute.

For the game Super Metroid and a romhack of it there is in total (so far) 2 more situations for which I realized myself that this method can be very useful, and I'll go into one of them as example below:

Trick: Saturn Climb (named after a tool-assisted speedrunner): Here is a visualization (using the SNES TASing emulator lsnes) of the TAS inputs around the critical part of the trick (for which some of the inputs need to be as shown in the following screenshot, but not all): For Super Metroid (running at 60 Hertz) on NTSC there exists this tricky walljump that is highly precise in the vertical and horizontal sub-pixel range for Samus' positioning from where the walljump has to be executed, as well as extraordinarily precise in directional input timing and the rapid changes of that. The critical part that appears to be impossible to perform in this manner are two immediately consecutive required instantaneous direction switches (from holding Right to holding Left within 1 frame and only for 1 frame, and holding Right again immediately after that, as one can see in the screenshot at the frame rows from 49600 to 49602). Now (leaving out some details about previously also required frame perfect inputs which however would only need to happen in isolation from each other), by pressing Start about 1 second ahead of time (since in this game pressing Start doesn't pause it immediately) frame perfectly (which adds/introduces another frame perfect input that is not present normally), 2 new variants of this trick emerge from doing so, which would allow to overcome this rapid input hurdle: (i) Either the earlier Start press makes the game enter the pause menu in the frame 49601, meaning that the gameplay frames relevant to Samus' movement end with frame 49600 (before frame 49601), in which case the first (frame perfect) Right (>) press can be held into the menu (which takes out the otherwise required frame perfect release of the button press), and from there one can buffer Left (<) through unpausing the game and then is only anymore required to instantly switch to pressing and holding Right (>) in the correct frame [which is a type of execution that has been shown to be doable on SNES controllers before]. (ii) Or the earlier Start press makes the game enter the pause menu 1 frame later, namely in frame 49062, and in this case after pressing Right frame perfectly, one would have to instantly switch to pressing Left at frame 49601 and can hold it into the pause menu, followed by being able to buffer holding Right (>) throughout all of the unpausing process in order to continue.

Also, when it comes to making precise tricks possible to execute, while games where initiating a pause makes the game stop instantly may in some cases have the advantage that the pause input can be pressed together with another critical input for a trick, so that doing both at the same time may come close to just pressing 1 button frame perfectly; games where initiating a pause happens with a delay may in probably more rare cases have the advantage that a convoluted input pattern doesn't get even more condensed with a pause input having to happen in the middle of it, because the pausing input can happen in isolation beforehand.

What I would hope could come from this would be the revisiting of previously as impossible to perform thought of tricks in games that were thoroughly tested for the respective input windows involved in them, for which this approach makes the difference, but also the same for tricks that haven't been looked into yet regarding the actual difficulty of performing them and associated input lenience windows for success, but are known to exist (e.g. from tool-assisted speedruns) already.

I'm posting about this in here, because speedrunners presumably would mainly be interested in unusual or challenging variations of their speedrun games and probably are connected with their corresponding ROM hacking community members (to which some of these things might be forwarded) for games where it exists.

For a game that has had many ROM hacks by fans in the past that I know rather well, Super Metroid, over time various people have come up with sometimes silly, or challenging, or confusing but also interesting types of changes to the original game that are of such a fundamental nature that there is a good chance that many (although probably not all) of those ideas or concepts can be carried over to many other games. They can also lead to intriguing new unique gameplay experiences, and because of that, I think it would be good to mention these concepts in a place where they might be seen by the right people that could find interest in them, and sometimes changes like these can even lead to new discoveries. While I think that some of these concepts (like O.H.K.O.) are rather well-known and may be redundant to list as well, I think some others in this small list would be new to most people:

Basic visuals & graphics affecting changes: ° Blindfold: Turning either the screen into a black screen in general or turning almost all objects' and game elements' colours to black, leaving just a few coloured reference points. ° Colourless: Taking all colours on the whole screen out by reassigning them a grey tone between black & white. ° Transparency/Invisibility: Turning enemies, projectiles, items, the playable character and/or various other game objects transparent/invisible. ° Rainbow: Making the colour palettes used for displaying any object and game element on screen at any time change randomly at a suitable pace. ° Graphics corruption: Making the game read the content for objects' and game elements' graphics in a different format than intended to create corrupted and scrambled but not entirely random looks.

Basic input & controls affecting changes: ° Input lag: Making player inputs wait for a noticeable (e.g. 1 second) delay before they take effect in the game. ° Control inversion: Making the game interpret exactly those buttons as pressed that the player doesn't press and those that aren't pressed by the player as pressed, at any point in time, and for the parts of the controls where this is applicable. ° Control randomization: Making the game repeatedly and randomly permute which function/effect/action is assigned to which button (either at a slow rate or e.g. each time a new room/place is entered). ° Control swapping: Making the game repeatedly alternate (e.g. at a rate of 1 control switch per 1 second) from which of 2 or more controllers it is polling the inputs, for 1 playable character (e.g. for 2 or more players switching the control of 1 character repeatedly). ° Simulated doubled frame rate: Making the game simulate playing at doubled frame rate by having it run its main game loop twice per frame rather than just once. ° Equipment randomization: For all unique items/abilities (without ammunition count or other count associated to them) for which it only matters if they count as possessed or not, make the game randomly in every frame assign which subset of these items/abilities are possessed in any given frame. ° Low/High Gravity: Changing the gravity towards a much lower or higher value to make the playable character jump low & fall like a rock, or jump high & float like a feather.

Basic health points affecting changes: ° One Hit K.O.: Making the playable character die instantly upon taking any damage or getting hit by any damage source; alternatively taking a multiple larger than 1 of the normal damage from damage sources. ° Weaker attacking: Making the playable character's attacks do less damage to enemies (e.g. a half or a quarter of the normal amount), by a factor smaller than 1. ° Invulnerability: Making the playable character take no damage (and/or no knockback) from any and all damage sources. ° Health drain: Make the playable character's health drain constantly over time at suitable rates from the beginning on or upon an event. ° Harmful lag: Make the playable character instantly take adequate damage every time a suitable lag frame occurs. ° Death timer: Setting up a hidden timer that repeatedly counts down over time from random starting values (within a suitable range) and instantly kills the playable character each time it runs out. ° Death chance: Setting up a function that takes a random number each time the player enters a new room/place and uses the random number to decide (with suitable odds) if it should instantly kill the playable character. ° Death by collision: Implementing a function that constantly checks if the playable character is colliding with any object (sideways and/or vertically), and kills the character instantly as soon as that is the case. ° No invulnerability: Turning the playable character's invulnerability time down/off to simulate gameplay without any invulnerability time upon taking damage. ° Fall damage: Making the playable character each time die or take damage that grows according to the fall distance or speed with which the character lands. ° No drop refills: Making collectible drops provide no (or only very little) ammunition of health points upon collection.

Basic (speedrunning) practice affecting changes: ° Practice Info HUD: Designing a heads-up display that provides important information about inputs & address values & the amount of lag & real time & in-game time, and allows to make savestates as well as warping to different places and to choose different equipment loadouts etc.; like a debug mode. ° Blockades removal: Opening all doors & taking out all progression blockades at connections to every place in the game so that those are more accessible from the beginning.

I'm sure one could come up with more basic changes, especially ones that would be more specific to a given game and the parameters that the games uses to control or keep track of certain things, but I think this would already be a decent list and inspiration for more.

I made a reddit post about 3 weeks ago on this topic ( https://www.reddit.com/r/speedrun/comments/gl0oe7/concept_idea_lag_frame_creation_setups_to/ ), but I thought it would be a good idea to bring this up in here, too. And since I already made an elaborate explanation for that idea in my reddit post, I will just re-iterate it from there:

Here's a general concept idea that I had (someone that likes to research glitches and explore possibilities in certain games) and was wondering about. Namely in some for such approaches suitable game cases (preferably with accurate emulators for efficient identification of lag frames as well as of setups that may create them at consistent frames later in time, relative to such a setup, and even under variable circumstances) it may be possible to design setups (depending on how much & how easily a game can lag, and how the game handles inputs during lag frames, as well as what available options there are for a given concrete trick that one would like to make easier) that will make the game add 1 (or even more and then consecutive) lag frames just 1 frame before, after, or at the same frame in which normally a frame perfect input by the player/speedrunner would have to take place for successfully pulling off a trick. I guess there could be different kinds of such setups, e.g. cases where a game will as consequence of it lag every 2nd frame or setups that solely create 1 or a few lag frames just at the right time when they would be helpful. There's surely more to be said and thought about this, but for now that's beyond the scope of the purpose of this post.

There is a huge amount of games & competitive communities around them, which is why I thought it may be a good and maybe inspiring idea to mention this type of in my experience and expectation possibly novel general approach idea to a broader, suitable audience so that it maybe can be looked into and can find applications in some places.

What do others think about this? And is there maybe already setups (that were intentionally designed that way) of such a kind in use? At least to me such types of setups would appear to be in general rather inaccessible, may require sophisticated (general or game related) know-how, may be very restrictive in its range of applicability, and may be easily susceptible to instabilities/inconsistencies, so that together with me not having heard of such kinds of setups is in parts why I think it probably hasn't been looked into so much at this point, but maybe my impression of it is wrong.

In order to help avoiding misunderstandings of what I'm talking about, let me follow up with a disambiguation:

TASVideos has a description of the kind of lag frames that I'm referring to: ''Lag often refers to delays experienced in computing communications. In console games, lag is the effect experienced when the game runs slower than usually. Lag is caused by there being too much action for the CPU to calculate in the time of 1 frame, and thus more what was supposed to take 1 frame, takes 2 or more. Often, during lag, the game ignores the player’s input until the next frame. Objects usually also halt during the laggy frames. There might appear graphical anomalies, such as head-up displays appearing in wrong places.''

In particular, I'm not referring to input lag, i.e. the time that an electrical signal, induced by a button press or release, takes from that point on up to the earliest frame that is affected by it.

In the following, with ''input candidate frames'' (for successfully executing a trick) I'll be referring to exactly those frames that are for some given singular button press (that needs to happen for pulling off the trick) associated to it in such a way that the trick will work out then and only then if the pressing of said button occurs on one of those input candidate frames (so that for other frames the trick wouldn't work), while all other button inputs that may be involved in the trick would be considered to stay as they were. And solely those cases in which the total amount of input candidate frames increases as intended consequence of a setup that creates lag frames that get added to such input candidate frames is what I meant.

Now with this said, there's a few cases that were not part of the concept idea that I tried to explain, of which delaying the time at which those input candidate frames will occur (e.g. by possibly even repeated pausing and unpausing of the game while one is approaching those input candidate frames) is one of them. I also wasn't referring to splitting the set of input candidate frames apart (provided there is at least more than 1 such input candidate frame) e.g. again by pausing (and later unpausing) the game somewhere in between, while or provided that the total amount of input candidate frames stays preserved at the same total amount as what the amount of input candidate frames would be for the reference (or default) situation. And in more general terms, I don't mean any changes to the structure of the set of input candidate frames, i.e. if all those frames come in a consecutive manner (like in a typical input frame window, and provided it consists of more than just 1 frame) or if there is other frames in between them where an input in such a frame wouldn't work, or if there is multiple of such ''gaps'' in there and maybe with variable length; as long as the number of input candidate frames that (via the setup) contribute to the usable time lenience for making the input stays the same (or in particular, as long as it doesn't increase).

I am neither describing approaches in which pauses can be introduced between such input candidate frames in order to make a situation more controllable or in order to turn a situation that normally would demand a high rapid rate of inputs to occur within a short amount of real time into a situation that provides more time in between each input; nor the manipulation of the relative timing of critical inputs to each other in which they have to be executed, since sometimes it can be advantageous to turn a situation that demands certain inputs to be occurring in 2 frames that in real time are e.g. half a second up to a few seconds far away from each other into a situation in which these frames of critical inputs are much closer together. E.g. the situation in which 1 frame of critical input follows up immediately after the other, so that one can ''roll off'' both inputs in what may feel more comfortable or closer to being 1 motion rather than 2 motions that have to happen separately from each other but with fixed delay between them.

A theoretical example case situation that e.g. requires a frame perfect input at some critical frame that I could think of would be a case in which pausing and unpausing the game would cause a lag frame to occur at some fixed relative time after the game was unpaused, so that if one were to unpause the game in the right frame, it'd append a lag frame right after that critical frame so that the input can occur anywhere in the time period strictly after the last frame (and associated input polling) before that critical frame and up to the next frame after the critical frame (instead of only up to the critical frame).

But instead I am mostly referring to creating scenarios in which a whole lot of stuff is caused to happen simultaneously to make the game lag, in order to make input frame windows larger for a trick.

And I am also not describing other kinds of purposes for which the introduction of lag can be used, namely beyond the sole purpose of increasing the real time window within which an input has to occur, but for purposes that make a trick possible to begin with where it otherwise without the introduction of lag would have been impossible, which is relevant & interesting in and of itself as well, but is a separate topic.

''The mods for Super Metroid have stood on the game for a while.'' I'm not sure which of the 2 Super Metroid boards you're referring there, and yes for the main board, the Mods and Super Mods have been there for a longer time by now, but I'm talking about the extension board Super Mods, but I'll assume it is those that you are referring to aswell.

''and is only used for extreme cases where the games progress is hindered due to inactive mods + those mods cannot be contacted in anyway'' In this case here, the Mods can and have been contacted without positive results or even compromises, however the game's progress in certain category addition and definition aspects is hindered by them (as strange as that may sound, but unfortunately seems to be the case). The fact that their number grew already to a sizable amount doesn't help the problematic situation either.

''My opinion is inserting mods into games without any current mods consent or knowledge would likely just cause more issues than prevent.'' Again, this depends on the qualifications of initial Mods / Super Mods to begin with and has its roots from there, but yes I'd agree that such a situation would rather be a rare case than the average, so I understand your view of it. Afterall, being in a responsible position of a Mod / Super Mod or not doesn't change or influence on its own how familiar a person is with a game nor if decisions were conform to the game's community's standards (as examples, a few questionable categories listed there would be ''Grabbed by every Yapping Maw RTA'' or ''All Vileplumes RTA'', or ''100 Missile RTA'').

Well it looks like some of my other concerns from earlier stay unanswered, but some things were picked up.

Good. So then I'll wait for staff response about the matter.

Thank you, I fixed the contact information. I do have some runs for the game Super Metroid ( https://www.speedrun.com/user/AranJaeger ) which are listed there, so this should not be a relevant problem then, I assume. You said that I don't need Super Mod for discussion ideas, and yes in theory that is correct, but in practice it so far didn't work out, and it isn't solely about the discussion of ideas (as mentioned in my message above), but also being able to apply extensions to the board itself which otherwise would be impossible for me (just the way the existing Super Mods already apply such additions). It is not for my own runs, but rather for runs by others and for developing the board in general for its participants.

''You need a run pending in the game. Exceptions are made if the category doesn't exist as a result of a moderator's negligence, which is not the case you're raising here.'' Well yes there do exist extension-category runs (most of them are older by now and had no place to be submitted to back then either before this board existed) of to-be-added categories by a few community members that cannot be submitted due to there not existing respective category headers. I'm also not sure for what purpose I myself (in contrast to others) need a run that is pending in the game.

''The site staff won't mod a new user behind the existing mod's back. Can you imagine if that was how it worked?'' So site staff can do this for the 1st Mod candidate before any such existed already (since for a board, some Mod will always be the first Mod existing for the given board), but not for any subsequent ones (which then possibly depend on the choice of the initial Mod)? That sounds odd to me, since this seems to imply that any further Super Mods or Mods are delegated to be subject to an initial Super Mod's judgement, which makes the initial choice crucial and expected to be made in a thorough, careful manner. So is it then alright to make someone to be the 1st initial Mod or Super Mod behind the back of the corresponding entire community, but it is not alright to then afterwards (possibly when the core of a community's members get to know that such happened) add further Mods or Super Mods alongside those that had been put into those positions without a community knowing about it to begin with? Can you imagine if that was how it worked? And on this subject, as response to ''I'm afraid this'll come across as blunt, but your qualifications aren't really relevant for this topic.'', I'd for naturally arising reasons claim that some familiarity of a person with a game does absolutely matter for such a subject, wouldn't the speedrun.com staff agree? I'm not sure who is all part of the staff, but I'd then rather be interested in their thoughts and opinions on this.

Hello there, I'm lead to assume that this is the correct fitting place for the subject of my request. So I'm requesting (with substantial support and reasoning behind it) for the position of a so-called Super Mod with respect to the leaderboard that goes by the name ''Super Metroid Category Extensions'' ( https://www.speedrun.com/super_metroid_category_extensions ). And yes I'm aware of the suggestion ''If you want to be added as a moderator for an existing game, contact the current moderators for it instead. If the current moderators are inactive, please use this thread on the forums.'' as it is adviced/recommended from this general guidline page ( https://www.speedrun.com/requestgame ). However, the existing moderators (all aswell Super Mods at the board in question) seem to turn out to be inactive in this Super Mod qualification judgement/estimation/acceptance subject, which is why I'm requesting this here instead.

Regarding the general game (and the vast pool of hacks that exist for it) itself, within the Super Metroid community (which provides a plentiful source to gain feedback from in order to double-check questions on my following claims) it is a well-known fact that I have rather unique extensive knowledge and insights about the game's mechanics, possibilities and structure.

Regarding the concrete extension board and its categories content, experimentations and documented analysis that I did a long time in the past contributed significantly to the existence and in the end the appearance of some of the listed categories on the extension board. This would contain but not be restricted to ° research and development contributions to the category entry that is named ''RBMBO'' in which, with the support of heavy glitch abuse, bosses are defeated in reverse similarly to the more known ''RBO'' category, ° strategy experimentations and setup construction aswell as brain-storming for different applicable controllable movement maneuvers for ''Blindfolded Any%'' ° the creation and pioneering of the ''No Drops'' concept with further tests that go into estimations of ''No Drops Low%'', ° Investigations into the details that make out the ''True Completion'' branch, ° my initial idea of ''Zebes Escape'' as counterpart to ''Ceres Escape'' which was put up by other members that approved of the concept.

In a position as Super Mod w.r.t. the board in question alongside the current Super Mods, I would like to clear up and discuss rules (as parameters) that separate/distinguish different types of runs, and extend the board's content further to serve the wishes of the running participants from the community.

I'm optimistic and would hope that this expertise provides sufficient conditions for my request. Other than this, unfortunately, I wasn't informed (and hence wasn't aware) when this additional board was created a while in the past even though it has a large interest from my side. If there's uncertainty or questions about different aspects, I can help and provide further information depending on those aspects.