Posts for FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
It depends on whether input.get can pick up the joystick.
gui.register(function ()
    local count= 0
    local keys= input.get()
    for k,v in pairs(keys) do
        count= count+1
        gui.text(1,count*10,k)
    end
end)
Run this. See if the joystick stuff makes text appear on screen. Seems doubtful, unless the JoyToKey I hear about works in this case.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Clearly, I missed the auto-hold function when first looking into the config stuff. That mistake shows here. There's still the sticky stuff I threw into the script, which provides a a different sort of convenience, since it only sticks for one frame. If nothing else, this helps to maintain some level of practice for me.
Post subject: Trying out something in lua.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
--===========================
local HoldKey= "space"
local ClearMouse= "Z"
--===========================
local ColorSticky= 0x00FF00FF  --green
local ColorHeld=   0xFFFFFFFF  --white
local ColorBoth=   0xFF0000FF  --red; Sticky and held together is unpressed
--===========================


local btn={"left","up","right","down","A","B","X","Y","L","R","start","select",
           "lid","debug"}
--*****************************************************************************
local function JoypadSet(inputs) -- Expects table containing keys
--*****************************************************************************
--I so wish FCEUX's "invert" option existed. This function mimics that.
--Best called from a function within emu.registerbefore
    local JoyWanted= joypad.peek()
    for i= 1, #btn do
        if type(inputs[btn[i]]) == "string" then
            inputs[btn[i]]= not JoyWanted[btn[i]]
        end
    end
    joypad.set(inputs)
end


local held, sticky= {}, {}
--*****************************************************************************
local function MessWithInput()
--*****************************************************************************
--For use with emu.registerbefore
--Checks for held and stickied keys and applies them
    local ThisInput= {}

    for i= 1, #btn do
        if sticky[btn[i]] then
            ThisInput[btn[i]]= not held[btn[i]]
        elseif held[btn[i]] then
            ThisInput[btn[i]]= "inv"
        end
    end
    JoypadSet(ThisInput)

    if sticky.x then
        stylus.set(     {touch= true, x= sticky.x, y= sticky.y} )
    elseif held.x then
        if not stylus.peek().touch then
            stylus.set( {touch= true, x= held.x  , y= held.y  } )
        end
    end

    sticky= {}
end
emu.registerbefore(MessWithInput)

local fc= emu.framecount()
local LastButtons= joypad.peek()
--*****************************************************************************
local function PeekAtInput()
--*****************************************************************************
--For use with gui.register
--Peeks at input if the emulation is paused, and handles stuff.
--Doubles as display for the input it messes with.
    local keys= input.get()

    local _fc= emu.framecount()
    if fc == _fc then
        local buttons= joypad.peek()

        for i= 1, #btn do
            if buttons[btn[i]] and not LastButtons[btn[i]] then
                if keys[HoldKey] then
                    held[btn[i]]= not held[btn[i]]
                else
                    sticky[btn[i]]= not sticky[btn[i]]
                end
            end
        end
        LastButtons= buttons

        buttons= stylus.peek()
        if buttons.touch then
            if keys[HoldKey] then
                held.x= buttons.x
                held.y= buttons.y
            else
                sticky.x= buttons.x
                sticky.y= buttons.y
            end
        end

    end
    fc= _fc

    if keys[ClearMouse] then
        held.x= nil
        held.y= nil
        sticky.x= nil
        sticky.y= nil
    end

    for i= 1, #btn do
        local color
        if sticky[btn[i]] then
            if held[btn[i]] then
                 color= ColorBoth
            else
                 color= ColorSticky
            end
        elseif held[btn[i]] then
            color= ColorHeld
        end
        if color then
            gui.text(1,10*i - 200, btn[i], color)
        end
    end
    if held.x then
        local color= 0xFFFFFFFF
        if sticky.x then color= 0xFF0000FF end
        gui.text(40,-185, held.x, color)
        gui.text(60,-185, held.y, color)
    end
    if sticky.x then
        gui.text(40,-170, sticky.x, 0x00FF00FF)
        gui.text(60,-170, sticky.y, 0x00FF00FF)
    end

end
gui.register(PeekAtInput)
This I call "sticky joypad". Save this into a .lua file and run it from DeSmuME's file menu, but if you needed me to tell you that, you probably need to learn a lot more about DeSmuME anyway. Pause emulation, tap a button, and it will be pressed when you finally frame-advance. This should help in making sure you don't overload the keyboard trying to press so darn many buttons at once. Also, hold space while pressing a joypad button, and it will act like the FCEUX-style auto-hold. This particular auto-hold can only be changed when emulation is paused, sorry about that. And whether you like it or not, running this script will also stick or hold stylus input. A key is assigned to clear the stylus input (how would one unclick the mouse effectively?), but change it to something other than Z if you wish. I sort of note a lack of a lua discussion thread, so I create my own topic to share my scripting stuff. Hope no one minds.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
It's not just the Rewinder.lua that's failing to update the input display, but Multitrack2.lua and this silly test script, too:
local stuff= savestate.create()
savestate.save(stuff)

gui.register(function ()
    if input.get().space then savestate.load(stuff) end
end)
EDIT: Also, the brand-new checkbox in Movie Options doesn't remain checked after I close and re-open the Movie Options window. Whether it has any effect, I did not check. This is from a fresh download of 2.1.4a, no prior .cfg file or anything like that. The DeSmuME-inspired change to the input display is definitely sweet, though.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Out of curiosity, how many (UE) submissions are there? I'm guessing that it calculated the time using NTSC from the frame count in the movie file (60.1 frames/sec), but then recalculated the frames from the time using PAL (50 frames/sec). But this is a guess. Is the site code calculating frames using time, in spite of the fact there's a frame count extracted from the movie itself?
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
At a glance at a few of the pages, I spot that FCEUX is listed as an emulator that doesn't accept hotkeys while paused. It's true that I didn't see input.registerhotkey in this emulator, but for some reason, FCEUX's gui.register is called repeatedly while paused. Odd as it may be, but the fact it's called at all while the emulation is paused will allow a way to catch a key and process it without advancing any frames. Should be good to know about when attempting to try this script on FCEUX. Try this bit of code in FCEUX:
function Fn()
    local T= input.get()
    local Count= 0
    for k,v in pairs(T) do
        Count= Count+ 1
        gui.text(1,8*Count,k)
    end
end
gui.register(Fn)
Pause FCEUX, and push various keys. The script should still react even though FCEUX is paused. I'm not sure what other emulators have a gui.register like this one, however, other than the fact Snes9x doesn't seem to. With this knowledge, it should be possible to create a variant of input.registerhotkey. It eats up gui.register, but it should hopefully allow one more emulator to deal with input for MacroLua while paused. Good to see us getting a new script to play around with. I'll be looking at this and see if I can get use out of it. Most likely yes. I'll try to be a source of ideas in case you need a few from me.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Bootman wrote:
I wonder how many other Bosses and mid-level Bosses the Force (Shield) as a weapon trick helps with.
If I had to guess, all of them. The level 2 boss? Sure, the fact it's inside the boss a ways is no problem. The level 5 boss? Who knows, but if possible, sure would be fun watching the ship dive recklessly into the boss in spite of its clear defenses. I'll be making attempts to Force-kill every boss and mini-boss, partly because it saves on lag-causing shots and, of course, it's a one-hit kill. And I can "store" up to four of these Force -- A player can have one active and collect another 6 power-ups in preparation to create another, and I have two players.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I saw this topic and thought, since FCEUX has a gui.register that can run while the emulation is paused, why not have a function that can act like input.registerhotkey?
local hotkeys= {}
local keys= input.get()  --Should have an initial value
local lastkeys= keys
--*****************************************************************************
local function luahotkey(hotkey,func)
--*****************************************************************************
-- To act in place of input.registerhotkey where gui.register can run while
-- emulation is paused.
-- Returns whatever function that once occupied the specified hotkey.

    local dumpedfunction= hotkeys[hotkey]
    hotkeys[hotkey]= func
    return dumpedfunction
end



--*****************************************************************************
local function scanhotkeys()
--*****************************************************************************
-- The actual function to process each registered key.
-- Use gui.register(scanhotkey) or something similar to let it work its magic.

    lastkeys= keys
    keys= input.get()
    for key, junk in pairs(keys) do
        if (hotkeys[key]) and (not lastkeys[key]) then
            hotkeys[key]()
        end
    end
end
gui.register(scanhotkeys)



-- Junk code. Just to test the hotkey formula.

luahotkey("space",function()   gui.text(1,1,"Space, the final frontier") end)
luahotkey("Z",    function()   gui.text(1,4,"That's a Z button.") end)

while true do
    gui.pixel(0,0,"clear")
    emu.frameadvance()
end
Run it. Pause emulation. Hit one of the two buttons I keyed up. Observe. It might help organize some of my scripts to something easier to read when I can package my hotkeys separate from my main gui.register code.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Psycho twin ships, go! I finally beat the first stage. The answer is that it won't save a single frame if I put my ships on the far right of the screen. After the "auto-pilot" takes over, it's takes a fixed number of frames for the next level to load regardless of where the ships happened to be positioned. Now, what is the question that fits the above answer? Yes, it's good to know that I haven't completely forgot this game. I'll be making slow progress, but progress should exist. Also, there are a few places where lazymode took over, but I don't feel like going back to them.
Post subject: Instant deaths are so fun when they actually work for you!
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
mklip2001 wrote:
Out of curiosity, though, it seems like you picked up some generals that you never used in battle, like Dan Fu. Why was that done?
Dan Fu, or Xu Zhe when we actually look at the party's names, is necessary to get in order to get beyond one city (Someone blocks a bridge). In addition, the existence of this character in the party means we have someone learning tactics, and thus we're getting MTP. Yes, the Dan Fu we pick up in the cave shows up as Xu Zhe in the party. It's not a mistake on the programmers' part -- There's a story-related reason or something. I saw the run. I will vote yes. You are badly outnumbered in some cases, yet you ignore things like strategy and just go All-Out. And win. You take two generals' heads, and they promptly join afterward. So nice seeing just how much the old run is obsoleted. A note about the damage. How much HP you have has some effect on damage. Or rather, how many digits are visible. It's why in the beginning Liu Bei was taking all the hits -- Guan Yu or Zhang Fei would be so much less effective after taking even a single point of damage. Also, weapons have a massive impact on damage. If one didn't equip the starter flails, one would deal roughly 1/3 of the damage with bare hands. A significant jump in damage can be seen when the Trident is finally obtained. Armor, not so much, until we get close to the endgame and get the nicer ones, but then we take heads and manipulate more luck, so who needs defense? Chi Tu Ma eats up a bit of time to pick up, and there's no obvious effect that Chi Tu Ma does anything, as he's not explicitly used as an item. The hidden agility stat of whoever holds Chi Tu Ma is increased 50%, making manipulation of turn order much faster. Yep, some random notes that I thought would be good to have.
Post subject: Exactly, my friend! With these, we can take over the world!
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Great to hear you're doing well with it. And even if the only use for the backup is the colors, letting you know what changed, you're still using an addition you requested. And it's certainly a good request, alright. It helps to have a different perspective on how to use this script. I myself (should) know every detail with this script and how it works (I created the darn thing!), which causes me to miss out on all the problems that an unfamiliar person would crash into. The path I traveled is certainly different from yours, and I am interested to see your view. You can also suggest how I should rearrange the options, if you think there is a way I can make it a bit more friendly, if you like. I recall my attempt on the Snes9x port. Thinking over it, I believe it wouldn't be too hard to implement a useful backup system even without the script running while emulation is paused.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Having trouble getting a fast enough brute-forcing bot to do the last 80 stages of Yoshi's Cookie in a timely manner. Ah well. In any case, I saw the latest WIP. Don't really have anything new to say (Definitely fun seeing things happen even faster, but this isn't something new to say), other than the fact I'm curious if waiting on Huang Zhong until after the Gullwing purchases is faster than dealing with the billeting message for Huang Zhong. ... On the other hand, it must be rather irritating if this means you end up redoing these parts again.
Post subject: Perhaps I should stick random messages here...
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Well, the backup feature is added in. Feels a whole lot less like a prototype than the one I sent by IRC. Still could do with better coloring and some useful instructions. Should be much easier to change some of the colors, so play around with them and see how they fit in. ... Alas, poor numpad. You sure take a heavy burden from my default button scheme.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Hmm, this feature, keeping a second list of input that is a backup of sorts, seems like it wouldn't be too complicated to implement. Recording to a separate list seems trivial. One tricky thing would be how to display it. Another is how to decide whether to transfer one to another. For recording, the function that catches the input can check for certain options or whether the backup even exists for the given frame. Should be rather easy to just copy what it sees to the backup. Displaying it... It can get a bit messy... In this case, there are technically four (or six, if you count the orange I use for list-disabled buttons) states of buttons: both off, main, backup, and main&backup. I have shades of blue completely unused, I can try seeing if mixing in cyan (main and backup) or purple (Backup, but not main) still keeps things intuitive. I can also have a line on the side indicating if there exists differences between main and backup, and possibly which one it's using. And how should I work at transferring one list to another? There's no mechanism in there to detect where the actual input begins (and it's possible, with various different savestates ready beforehand, to have several separate spots of input recorded). I'm thinking that transfers between the two lists will only take place at the frame you're at, since that's easiest on me, and I can see a fairly decent way I can deal with it. I'll mess around with things on my end, and let you know what I come up with. It seems like quite a good idea to try.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
At long last, questions! Beautiful, shining questions! ... Okay, now to actually answer them. A step-by-step tutorial on my script... Try running the script without any movies running. Savestate, play the game however you like, then loadstate. Let the game run without your interference. It should do stuff exactly as you did before your loadstate. And you're not even running a movie! Okay, loadstate again. Pick a key to hold down, then frame advance a few frames. If that button was red, it should turn green as you frame-advance. And if green, it will turn red again. It works with the joypad stuff by frame-advance (or when playing at any speed, but that hardly has the control you need), similar to what you should be doing when first creating a TAS like this. The script keys stuff are, by default, off. When on, tapping one of these keys should change the color of the related button, indicating that the script should press or ignore that button instead of what it had recorded. Meant for precise edits that you don't want to frame advance for yet, or when the keyboard simply doesn't allow so many buttons and FCEUX's auto-hold feels too inconvenient at the time. Eh, I'm not sure of a good tutorial. The script can keep track of the input by itself independent of what FCEUX is doing at the time.
dwangoac wrote:
What I'm experiencing is that the only way to make the button states take is to switch to read+write mode but this discards any existing keypresses on the frame advance edge which seems to conflict with the "toggle" behavior that's described.
This sounds like you think that Multitrack2.lua is closely linked with FCEUX. It's not, it simply records the joypad into its own independent list as the emulation plays out. When you play a movie on Read-Only as normal, it records this input into the same independent list. Loading a state in a movie's read+write will get rid of any and all input after that state, in the point of view of FCEUX. In the view of multitrack2.lua, it sees a list of input that the script itself recorded (which FCEUX promptly forgot), and will inject that list it sees to FCEUX, with possible modifications from you. The script can only record what the movie does in read-only mode -- FCEUX will not allow any other input, whether by player or lua script, to take place. In Read+Write, FCEUX promptly forgets all input that takes place after any given loadstate, but allows player and lua input. The lua is what's remembering the future input, and needs the Read+Write in order to do anything. The movie should playback in a sort of a pseudo-Read-Only, even though FCEUX is in Read+Write, but this type of pseudo-Read-Only allows player input. To me, Read+Write feels more like Write-Only. In any case, I have now made an attempt at explaining things. It's quite possible I ended up making more of a mess. Further discussion should take place here. (I should fix that up a bit...) I don't exactly want to flood this thread with something unrelated to the game at hand.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Fun watching the encode. The game is unfamiliar to me, so other than words of encouragement, I can't do a whole lot to show my support. Regardless, please take a "keep going" and a "I like what I see so far" from me. I have been noticing talk of TASEdit. An alternative is the Multitrack2.lua script that I have made. I'm pointing it out because, mainly, I worked on it and is pretty functional as it stands. It should be included as part of the latest FCEUX package. It does not record resets, swaps, or any of that other stuff, unfortunately, but one can start the script at any time, and it can work without needing to know what happened since the beginning. But use whatever is more convenient or familiar to you. Using the Multitrack2.lua script involves learning how to use a new tool, and that rarely goes smoothly at first.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Fun. In response to the rehashed zapper.read(), I hereby create a silly little script for it:
local PrettyColors={
0x0000FFFF, 0x0020FFFF, 0x0040FFFF, 0x0060FFFF,
0x0080FFFF, 0x00A0FFFF, 0x00C0FFFF, 0x00E0FFFF,
0x00FFFFFF, 0x00FFE0FF, 0x00FFC0FF, 0x00FFA0FF,
0x00FF80FF, 0x00FF60FF, 0x00FF40FF, 0x00FF20FF,
0x00FF00FF, 0x20FF00FF, 0x40FF00FF, 0x60FF00FF,
"#80FF00FF","#A0FF00FF","#C0FF00FF","#E0FF00FF",  -- Odd glitch with red
"#FFFF00FF","#FFE000FF","#FFC000FF","#FFA000FF",  -- when at least 128...
"#FF8000FF","#FF6000FF","#FF4000FF","#FF2000FF",
"#FF0000FF","#FF0020FF","#FF0040FF","#FF0060FF",
"#FF0080FF","#FF00A0FF","#FF00C0FF","#FF00E0FF",
"#FF00FFFF","#E000FFFF","#C000FFFF","#A000FFFF",
"#8000FFFF",0x6000FFFF, 0x4000FFFF, 0x2000FFFF}


while true do
    gui.pixel(0,0,0x00000000) -- Clears gui
    local Clr= PrettyColors[ ( movie.framecount()%36 )+1 ]
    local T = zapper.read()

    T.y= T.y-8

    if T.fire == 1 then
        gui.line( T.x ,   0 , T.x , 220 ,Clr)
        gui.line(   0 , T.y , 255 , T.y ,Clr)
    end
    emu.frameadvance()
end
... Odd, running this script when a movie ends from natural causes (let movie play out all its frames) causes FCEUX to crash here. Hrm...
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Aktan wrote:
It does show the password, you just need to wait a while (or fast forward). I found this out when playing around to see the differences between new and old PPU.
That... Shouldn't be possible. From what I know, the game requires a button press (start) before it will ever display the secret password. Just in case, I ran the emulator out to somewhere past frame 100000 with A still held down, and never saw the password show up. This was in New PPU. Only when I hit start do I see this message. So now I ask, did you press buttons at the ending, either accidentally or just playing around? I wish to confirm.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Hmm. Rejected. One reason I didn't have a strong case why the auto-hold should be allowed is because I also believe a movie shouldn't depend on a default button state other than null. Like what's said here, just dropping the controller and letting things happen without wedging buttons down would be when the movie should stop. Mainly, I was curious what the reaction would be for a novel concept where I do cause a well-timed event with nothing more than several straight minutes of a button wedged down after a short 3-second bit of input. Enjoyable to some, but I just couldn't see how this would fit within the standards here. Because of my belief that it won't work out with the standards here, I naturally picked a certain day to submit this. This movie has been sitting in my computer for around half a year.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
End at R2, S3 Started my attempt at mixing in my Yoshi's Cookie input to your run. (Did R2, S10) Though my own bot needs either better pruning or I somehow find a useful algorithm that can do nearly as well as brute-forcing every combination. The fairly plain brute-forcing I'm doing is certainly taking much longer than I hoped. So, keeping Yuan Shu alive longer really won't eat up 5 seconds worth of attacks and manipulation? Although, I suppose you would have fairly potent weapons by then, and other than being in another castle with better defense (not zero this time), isn't any more threatening. Things do appear more efficient. The second run through is certainly changing things. But other than my attempt to insert extra input, I don't really have anything important to say.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Ah, I remember reading all about it while still messing around with the password system in this game. The nice thing about that place is the fact it's so wildly random! It even breaks the "usual logic" of the game itself on occasion! The problem, however, is that there is no way to access this place without the right passwords. ... Then again, I never did explore the area much myself... To the extent of my knowledge, there are four ways to enter any given coordinate: - Appear by password (32 x 32 region) - Use the passage panels (takes you to adjacent room) - Walk to screen edge where there is no wall (different mechanics) - Use a glitch weapon (We need in the glitch areas to get it) A password-less run is going to have trouble getting off the map at all. Obviously, the expected playing area has no passage panels or screen edges that leads outside of the map, so forget those. Password is very out, as per definition of password-less run. And unless there's some way to corrupt memory without use of the wild glitch zones, we're not getting any glitch weapons, either. If we are going to use passwords, it would be a good idea to generate one that is quick to input, like the one in my submission. There's likely numerous stats we don't care about, like whether there's an item to be found here or there or what our rate of fire is. But I guess it depends on what our goal in particular is. Reaching the ending is an obvious end to our run, but there's different ways of getting there, each with their own merit. As for my progress on my own run... Uh, er... I'll point you over there while I make a subtle attempt at running away.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I've seen your submission. I would like to know what you've been doing so far since then. Plus, I still would like to see if I can sneak in a Yoshi's Cookie input somewhere in there. And hopefully I can finish my own bot for Yoshi's Cookie by then so I'm not inserting something suboptimal. Also, I'm still around in case you need further help on route planning, but having run through this game yourself recently, you probably have things covered anyway. If nothing else, I don't mind documenting a few things in an attempt to assist in subtitles and submission text.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Derakon wrote:
Speaking seriously, I don't agree with your take on "end of input" - when input ends, there should be no buttons pressed. The notional "player" should be able to just drop the controller on the floor (no casually trying to wedge any buttons down!) and let the game play out to its conclusion on its own.
I agree with you, in the fact I don't agree with my own take of when "input" should end. Part of the reason is that someone could take, say, one of the published movies here, shave off the last frame or two, then put in a note to put certain buttons on auto-hold. Mainly, I just wanted to try a crazy concept that allows for a ridiculously short input file length. I don't believe this concept I'm trying out, let the auto-hold finish, should ever be a standard, no matter how many minutes this shaves off. Again, I'm trying out the concept due to the fact I'm able to give a scant few seconds of movie for minutes of gameplay.
minglw wrote:
However, if you still have to press any button, I don't consider that as "end of input". You're still doing something to the input.
By that logic, then technically, since the auto-hold never ends, this movie's length is infinite. Which is likely a record time of all movies here. ... Unless you don't count the ending, where further input is almost meaningless.
mklip2001 wrote:
Edit: In fact, can't people also do this run quite easily on a normal console, given that they input the password correctly? All you need, it seems, is enough patience to hold the A button.
The unassisted person can also do this quite easily, albeit with the slower password input and menu transitions. As far as reaching the ending is concerned, this particular TAS has no real advantage over a console runner. However, there is luck involved in getting that beautiful twist ending. Set Old PPU or even delay my final start button press by a frame, and you'll get a much less impressive result. The console runner will have difficulties mimicking my wonderful ending. Although, this implies that I could very well have made attempts at manipulating luck and adjust my score enough so that I hit 0 life or close to it and still win, but this would likely extend the input file length.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
FractalFusion wrote:
Also, I don't get the score thing.
If I didn't have the right score, the twist ending wouldn't happen. Recall that there are games that gives score a useful function, at specific intervals or values. This is one of those games. I hit 2000000 points. TGL adds +1 max life, and fully restores life and CHIPs. I want the CHIPs in a dramatic manner. ... It's difficult explaining it without giving away the whole reason for the score before one views this run. I want to avoid spoilers! On the other hand, there is that nifty spoilers tag I could use...