Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
Glitchless is hard to define in Sonic, because very common actions (such as landing from a jump) have the potential to cause effects that look glitchy to a casual viewer; what's actually happening is that minor glitches end up happening all the time but normally end up cancelling themselves out (looking obviously glitchy only when the effect makes a noticeable amount of progress in the level).
I think that, for this game, it would make sense to instead ban a particular category of glitch outcomes, e.g. "no leaving collision on a different side from the side on which it was entered, no level wrapping" would end up banning the majority of obviously glitchy gameplay whilst still being possible to define objectively.
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
I guess the question is: if this run is accepted, would it be obsoleted by a hypothetical run that uses a different (faster) game-end glitch, and does not corrupt the save file?
If it would be, then according to the publisher guidelines feos linked above, the correct tag would be "game end glitch, no save glitch" as that is the category for the run; the run is not defined by what it's doing, but what it's not doing. (In particular, performing the Coin Case glitch is not essential to the goal; it just happens to be the fastest way to reach it.)
If it wouldn't be (meaning that the Coin Case glitch is essential to the goal), then the category would be "Coin Case glitch".
I think it would/should be, though.
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
feos wrote:
The full run doesn't reset during save either, and that's not an explicit in-game feature, so it should only be mentioned if all branches have the save reset except one.
The only reason this category exists is to avoid a reset during save, though.
Resetting during a save would make the full-game run faster, if the resulting glitchy state were used for something other than immediately ending the game. However, this would presumably be disallowed due to the full-game run being, effectively, "no game end glitch", as we typically disallow suboptimal uses of glitches. So "no reset during save" is the only thing that makes this category different from the regular game-end glitch category, and it would not have an effect in any other game-completion category (because game-end glitches more generally would be banned).
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
Ah, in that case I think "game end glitch, no reset during save" would be the best description of the category in terms of obsoletion, but maybe not in terms of what a viewer should expect.
In terms of entertainment, I haven't watched this specific run, but I'm aware of the category in general (and have seen runs of it), and don't think it has all that much to add compared to a glitchless run; the two start very similarly, so any additional entertainment has to come from the glitch itself. I find knowing the technical details behind these glitches to be interesting, but because the setup for this glitch is (in effect) very straightforward, the main interest typically comes from the bootstrap and how it's entered. That isn't something that can easily be seen from an encode, and based on the submission text, it's somewhat simpler than it would be for a typical ACE glitch.
In general, though, the TASvideos format is not very good at handling categories which have a lot of gameplay in common. If you were making a video to show off this glitch, rather than to show off a completion of the game, it'd probably highlight the parts of the run that differed from normal play rather than showing the whole thing.
It should be noted that in most cases I derive more entertainment from submission text than from an encode anyway, which tends to make the question in the poll hard to answer ("movie" is ambiguous).
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
For what it's worth, I think the fundamental difference between reset-during-save runs and the Coin Case run is one of legitimacy.
The Coin Case glitch is, IMO, obviously legitimate, and it is the fastest category which is obviously legitimate.
Meanwhile, reset-during-save glitches are more debatable with respect to legitimacy, as they cannot be accessed entirely using controller input. (In a way, this defeats the main goal of a TAS, which is to beat a game entirely with controller input, no cheating or hardware modification or anything involved.) If I remember correctly, Pokémon disables the reset chord (A+B+Start+Select) during a save, thus the only way to get a save-glitched run is to cut the power to the console (e.g. using the physical power switch on a Game Boy Color). The game also outright tells you that doing this is a bad idea, implying thtat it can corrupt the game.
So I don't think the "save glitch" is actually a glitch at all. It isn't something that the programmers failed to think about, and it isn't something that exploits a mistake that they made when programming. It's basically a case of using the game's power switch (not the controller) in a way that the developers were aware was possible, were aware could break the game, but were also aware that they couldn't guard against. If anything, it's an exploit of the console rather than the game (because the console gives the game no way to override the behaviour of the power switch).
TASvideos has historically allowed runs that rely on oddly timed physical resets, but there's a case to be made that it shouldn't (and to me, it isn't interesting to see a game being beaten like that, because it's basically an exploit that I would expect to exist in any given game because there's only a limited amount a game can do about unless it greatly increases its SRAM usage). That argues that "fastest run without abusing physical resets" should be a legitimate category, probably more so than the fastest run that does.
For what it's worth, the category of this run should be "no reset during save", "controller input only", or something similar. What matters in terms of obsoletion is not which glitches are used, but which glitches are not used.
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
I voted No, not because I think the warping is necessarily disqualifying (that's more an issue with the encode than with the run), but because the run looks suboptimal; if it is optimal, it's only because the category has been carefully defined to make it optimal. In particular, I still disagree with the way in which input was ended (which is logically part of the category definition).
I'm also not convinced that the correct strategy is being used for the only mandatory battle in the game, even given the chosen category; this is the sort of thing that, being pretty much the only non-autoscroller in the run other than RNG manipulation, should really be optimised right down to the frame level by comparing a range of possible strategies.
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
By "overkill", I mean having much more damage potential than you need to win the fight, in the hope that the extra damage allows the use of a less precise strategy and therefore allows ending input earlier via just leaving the entire fight on autofire.
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
I'm not sure it makes sense to end input early in cases where that causes the use of a suboptimal strategy for the fight. It's delaying the end of the run by a substantial amount, and is saving very little in terms of ending the input (I'm not sure, but most likely it's a few frames of luck manipulation).
(I also wonder if sufficient amounts of overkill might make it so that you don't have to resync the Flak, and thus save time when it comes to ending input, too.)
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
The encode isn't a good way to watch the run.
Could you produce a transcript, or some similar guide to what events you're hitting and what happened in each of them?
There is an exploit that allows you to fire more weapons than you have power for, when you have a Pre-Igniter; it involves leaving the previous beacon with some weapons fully charged but deactivated and other weapons activated (but not necessarily fully charged). When arriving at the new beacon, all the weapons will be fully charged; you can then charge the activated weapons and quickly switch to the deactivated weapons before they lose too much charge. There are several properties of the Flagship that mean it may be hard to save time like this; however, it's worth looking into seeing if this leads to an improvement. (I think it might be possible to set the exploit up against phase 2 and use it against phase 3?)
An alternative way to speed up phase 3 would be using either Hacking, or additional drones, to take down the (regular) enemy shields; this would allow four of the Flak shots to damage the hull rather than being spent against the shields. You could also use Zoltan Shield Bypass, along with some cheap-in-power bombs, to bomb the regular shields while your main weapons are taking down the supershield, although I'm not sure if this would give you enough additional damage given the fairly slow reload time of that sort of bomb.
Also, on the subject of no other augments being helpful: not even Automated Reloaders? Those should directly save time in any fight that involves multiple volleys (such as your current flagship stage 3 fight).
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
goldenband wrote:
Very interesting, thanks. What properties of these numbers make them so effective as RNG seeds? Is it something about how they respond to bitshifting operations and XORs, or something else?
With any LCRNG multiplier, if you take a group of consecutive outputs, treat them as a coordinate in some number of dimensions, and plot them on a graph, all the resulting points will be on one of a finite number of lines/planes/hyperplanes. So there's a relationship between groups of consecutive numbers. When there are a lot of lines of this nature, the relationship hardly matters in terms of randomness because it doesn't give you much information. When there are only a few such lines, though, it can cause notable issues in the quality of the resulting numbers. A good multiplier will reduce this effect as far as possible by maximizing the number of lines and thus minimizing the information gained from the relationship between groups of consecutive numbers. (If you're interested, Wikipedia has an article on the spectral test for finding low-quality random number generators.)
RetroEdit wrote:
I'd be curious to know what examples you have for using the multiplier you mention, or maybe there's a list somewhere already that can be linked to?
The multiplier in question is presented as part of an example rand() implementation in the C standards, so it's found its way into a lot of C standard libraries over the years (and into some other languages too, which often borrow standard libraries from C).
A quick search of the TASvideos forum gives the following list of games whose RNG was discovered to use the 1103515245 multiplier here on TASvideos:
* Skies of Arcadia Legends
* Phantasy Star Online Episode 1 & 2 Plus
* every game using the PSX's built in random-number generator
* Paper Mario: The Thousand-Year Door
* and two games where someone asked for help with an RNG without saying which game they were working on
GBA games tend to use some other RNG algorithm than this one, though. Perhaps the toolchain for GBA doesn't have a built-in random number generator, so each developer has to come up with their own. (There are some exceptions, e.g. the 1103515245 value appears in GBA Pokémon games, and some of the earlier DS games, too. Perhaps they copied the formula from Pokémon Stadium, which uses the same RNG algorithm.)
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
CoolHandMike wrote:
2) Perhaps there are certain common RNG seed values that would indicate the game uses randomization. Perhaps exclude if found.
In games from the era that TASvideos normally cares about, a search for the constant 0x41c64e6d (1103515245 in decimal) within the ROM is likely to find the RNG routine approximately half the time. Finding good constants for use in RNG algorithsm is hard, and 1103515245 has been known to be an acceptably good multiplier value for 32-bit RNGs for a long time. (Bear in mind that many consoles will reverse the bytes in a number, so it might appear in the ROM as 6D 4E C6 41.)
This won't find RNGs with a size other than 32 bits, nor RNGs that use a nonstandard algorithm, but most developers are happy to just use a stock RNG algorithm, and many of those use the constant 1103515245 for some purpose or other.
(Note that 1103515245 isn't technically a seed value – it's a multiplier value – but it's nonetheless a strong indication that an RNG routine is in use, because there isn't much reason to use the number in question otherwise, and it's too large to be likely to appear by chance.)
For what it's worth, the most commonly seen 64-bit equivalent of 1103515245 is 6364136223846793005 (in hexadecimal, 0x5851f42d4c957f2d, or 2D 7F 95 4C 2D F4 51 58 when its bytes are reversed), but this is a much rarer number than its 32-bit counterpart; it may also be more likely to be swapped out for an alternative constant (this isn't the best known value, just the most common, and developers who care enough about their RNG to use a 64-bit algorithm may also care enough to look up improved constants for it).
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
This run was enough to make me watch both regular speedruns, and Let's Plays, of the game, to appreciate what was meant to happen. After doing that, though, I really appreciate the TAS.
I think you have to know what's going on for the run to be entertaining – a commentated version might be worthwhile in that respect – but once you do, it's one of the better TASes on the site.
The submission message could do with more information on the tricks used, and on the route (in particular, mentioning which items/spells/skills/relics/etc. are collected/equipped and why; it goes past so fast in the TAS that it's hard to tell by watching). Was the main form of movement just based on Charlotte's speed-increasing spell (that you made a detour for early)? Or was something else going on on top of that?
It might also be worth mentioning how you managed to kill the bosses so quickly; again, the action in those sections goes past too quickly for it to easily be seen by a viewer without separate commentary. Many of the bosses simply appear to be a case of "endgame item vs. early-game boss" but that can't apply to all of them.
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
The 2002-turn plan doesn't work as written: you can't command-repeat displace a monster. If using numpad controls, there's no way to give the command (because "n digit digit" would be interpreted as a two-digit repeat count, not a movement command, and none of "n digit g digit", "n digit G digit", "n digit M digit" displace). Switching to vikeys controls makes it possible to express the command, using a digit followed by a movement letter, but nomul() is called immediately before displacing the monster, so we won't be in command-repeat mode afterwards.
I don't think we could "oLS-cancel any of the other actions, either?
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
This wouldn't provide determinism; it'd only hide the lack of determinism. It means that when a movie desynced, you wouldn't notice it immediately, only when starting again from the start.
It's better to at least be notified that there's a problem when it happens, rather than much later when you've finished the TAS.
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
Given that there's no feedback yet other than votes, I think it's worth explaining my No vote.
I tried to watch this run but got bored pretty quickly. I understand the objective of the game, but the missions tend to be very slow and cutscene-heavy, and the nature of the map is that a lot of time there isn't much happening. It's also hard to figure out where the monkey ball is aiming much of the time, and there isn't an obvious route, so you can't really appreciate whether the TAS is doing ridiculous skips or cutting corners or just following the intended route quickly. (Compare a run of a more normal Monkey Ball game, where you can typically see the goal right from the start of the level and see the path to get there, and it's often clear why a shortcut works as soon as it happens.)
The run does seem pretty well-made and I think it would make a great addition to the Vault, but I don't think it's entertaining enough to be in Moons.
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
I'd suggest going as simple as "max score runs are only vaultable in games where there's a hard limit to the score". Most games have some way to infinitely grind score, but in those that don't, it's a goal that's defined objectively enough to make for a good target. (Often this would become the 100% definition for the game, but it might have a separate definition: Wario Land 4 is a good example, with a concrete maximum score on each level but a 100% definition that doesn't require it. Of course, maximum score on Wario Land 4 would be unvaultable because you can infinitely grind score by playing levels more than once.)
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
A "max score" movie reaching higher score than its predecessor can only obsolete it if it loses no time over it.
This makes "max score" no different from "fastest completion", because a fastest completion run can't be obsoleted by a run with higher score unless it completes the game at least as fast.
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
theripper999 wrote:
I would argue that this is almost certainly Arbitrary Code Execution. It uses this hardware glitch to get it into a state that allows them to do damn near whatever they like with the game. It looks like it has some major inconveniences with limited inputs limiting opcodes, but there are workarounds as shown and it allows the programmer to input what they wish...so ACE. If I am wrong I am curious as to why.
I suspect this technique can be used to gain ACE, yes.
However, it isn't a hardware glitch. The code that's exploited is in the game cartridge, not the NES. There is a hardware glitch, but it's not directly relevant to the run, and the run would work the same way without it; the only reason it's mentioned is that the likely reason that the exploitable code is in the game is that it was probably an attempt to fix the hardware glitch in software. (So the game contains code to work around a hardware glitch; the glitch isn't relevant to the run, but the workaround code is buggy and the workaround code is what the run exploits. Even when using a NES that doesn't have the hardware glitch, the buggy software workaround still exists on the game cartridge and is still exploitable.)
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
I looked at the code, and it seems to work (the game does indeed seem to overwrite the timeout). I haven't tested it in-game, though.
Actually finding a monster action where the monsters could hit us is difficult, but either of the first two actions on turn 2001 seem viable. (The latter would require a shopkeeper polymorphed into a xan, but we've done weirder things in the run already.)
This improvement allows us to enter the sanctum manually, or polymorph manually, on our last action of turn 2000. That decreases the number of traps on the vibrating square level that we need to be able to hit on monster turns, making it much more probable that there's a seed that works (hitting two traps is way easier than hitting three because the probabilities multiply).
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
Chamale wrote:
This is the platonic ideal of an Arbitrary Code Execution run - a second of button mashing, a byte of RAM rewritten, and the game is over. It's a huge programming accomplishment, but it's not gameplay. I vote yes on this run and I think it belongs in Moons, hopefully with an accessible explanation of how this is possible. However, I don't think there's much benefit from producing more ACE videos for other NES games.
What if we had a rule that any% runs can't enter more than one input per frame? Would that break any runs other than ACE? We could still have a category using whatever controller port inputs break the game as quickly as possible, but whenever we use TAS tools to enter thousands of inputs per second its only use seems to be extreme abuse of ACE.
You don't choose when to enter inputs. The game chooses when to read inputs, and will look at what buttons are held on the controller at that point. So you have no direct control at all over how often inputs are entered.
As such, you'd need to word the rule more like "You can only change input once per frame", but then things get awkward because the game doesn't necessarily request input at the same time each frame. You could go for the old standby "You can only change which inputs are pressed at the start of vblank", which is what many emulators implement because it's convenient, but it's really arbitrary and doesn't have much resemblance to how the hardware works.
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
feos wrote:
Warp wrote:
When the encode of the run could just as well be simply a screenshot of the ending screen, perhaps some fine-tuning of the definition could be in place.
I'd hate for TASes to just consists of ending screen screenshots and a note that "it can be achieved in 0.12 seconds". It would suck everything that makes speedrunning cool to watch out of it.
That reminds me of NetHack. IIRC the movie of it would be unwatchable in real time. Of course it would have lots of in-game actions and "traditional gameplay", but measuring it by real time alone can be misleading.
I think the NetHack TAS is comparable to the Sonic TASes that outrun the camera. "Traditional" gameplay's there, it's just happening so fast that the screen can't keep up (in the case of NetHack, because we can send input many times per frame, so even on frame advance you miss part of the action). Just like Sonic games can use a camhack to become watchable, we can use a hack to draw the "gameplay between the frames" (combined with slowing down the encoded) to make NetHack watchable.
For this run, the equivalent of the camhack/slow encode is the game's memory watch (Masterjun put the memory watch in the video linked from the submission for a reason). Viewing that on frame advance lets you see the puzzle that's being solved; it's not the puzzle that the developers intended to be solved, but it's a game in its own right that's present on the (game cartridge, NES) combination.
I used to play Pokémon competitively. The generation 4 Pokémon games use a 32-bit RNG for most of their random number generation. That means you can generate a lot of random numbers (e.g. by listening to the pitch of Chatot's cry, which is randomized), put them into a brute-forcing program, and discover what the RNG seed is. Then you can start planning out from there to try to end up with competitively powerful Pokémon; the RNG seed is stable enough to be manipulated in realtime. Is that intended gameplay? No, it isn't (the Pokémon Company International became aware of the technique when people started using it competitively, and gave the strong impression that they disapproved of its use in tournament preparation but couldn't figure out a way to ban it, as it was achieved entirely via normal controller inputs and could in theory happen by chance). Despite being unintended, is it gameplay? I'd argue it is; after a while I was having more fun with that than with the intended gameplay of the games, plotting out an RNG route to make the best use of your random numbers without hours of waiting was a puzzle in its own right and a game of its own (and it also ended up providing a use for many lesser-used Pokémon). Is it something that's watchable from an unmodified encode? No, it isn't, you basically need a separate screen listing what random results will generate in the near future to make pretty much any of my actions while doing it explicable.
I'd argue that the situation here isn't much different. There are multiple games on the cartridge, some of which are intended, some of which aren't. The unintended games, being unintended, have a pretty terrible user interface, so a traditional encode isn't an entertaining form in which to watch them. I think it is possible to make an entertaining encode (although it'd be a lot longer than just playing through the game in realtime), just like the existing submission text is already entertaining.
I think it might be a good idea to update the rules for Moons to permit runs that are entertaining when displayed in the correct way, even if a traditional view of what's happening on screen isn't enough to appreciate how they work. That would solve the problem with this game, too (and sidestep any questions about whether any categories are completed and whether gameplay is involved).
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
A thought experiment: suppose a game cartridge has multiple modes (say, 1-player and 2-player play), but you have an ACE glitch that can be done anywhere, even the title screen. Is this a completion of the 1-player or 2-player game mode? Does it matter if you ACE the relevant bits of memory to specify which game mode you're playing?
I think what this run is demonstrating is that there's a conceptual problem with the whole notion of completing a game. The game has internal rules for determining whether it's complete or not, but we're using glitches to go outside the internal rules of the game entirely, and as a result the game's definition of when it's completed or not doesn't make sense.
With a general-purpose ACE glitch like this, we can say confidently "no matter how you define completing the game, no matter how you define what game mode we're in, it doesn't matter, we can do anything from anywhere". So a demonstration of the glitch starting from the title screen is sufficient to show that we can pull off the same glitch while actually playing the game.
FWIW, I see problems with ThunderAxe's definition, too: suppose the game stored a value representing the game mode somewhere which was inevitably executed as part of the glitch, and suppose that the game mode for the title screen happened to correspond to an instruction that crashes the NES. In that case, we wouldn't have ACE from the title screen (the NES would just crash) – but we would have ACE as soon as the game started normally! I don't think that situation is any conceptually different from this one, but it would lead to a different outcome under ThunderAxe's definition, which implies a mistake in the definition.
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
How should I interpret the "Did you find this movie entertaining?" question on the workbench?
In particular, if I found something about the submission entertaining that wouldn't be visible in an encode (e.g. the submission notes, or the memory watch during the game), but nothing visible in an unmodified encode is entertaining, should the vote be Yes or No?
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
kuja killer wrote:
umm, is the emulator your using one that allows all 255 opcodes ??
because NES does "not" have STX and STY.... not until SNES at least :|
There are 256 possible bytes that can be interpreted as instructions. Some of them are undocumented/disallowed but they will nonetheless do something on an actual NES.
Some of the opcodes in question are unusable (due to having an effect on an actual NES that's useless or actually harmful). Some of them are unstable (they won't act reliably across different NESes, or sometimes even on a single NES). However, some of them, by chance, happen to do something useful. So you can use them for ACE if you want to.
All that said, 86 STX and 84 STY are official, documented, supported opcodes; I don't think any undocumented opcodes are used in the payload of the TAS. Perhaps you had the NES confused with a different console?
Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1022
It depends on what the timer is like for loss with a full column. It seems plausible that after a sufficiently long time has passed, you wouldn't be able to form the match in a column quickly enough after it unburns (especially if this is happening in multiple columns at once); it's got to take at least three frames to move a meteo (tap old location, tap new location, release), and you have to move two meteos in the worst case, so that's six frames per column. Now do that somewhere like Hevendor, which has a large number of columns and doesn't let you make any hovering-meteo barriers to make it safe to not bother with a column for a while; you'd have to continuously rotate through the columns, making sure that no two columns ever unburned at once (or that if they did, you could manipulate a horizontal match involving them), as I'm pretty sure the late-game death timer is too short to make matches separately in every column.
If it's possible to max out the score counter on Hevendor, it'll almost certainly take a lot of luck manipulation to do so.