Posts for FatRatKnight

Posted: 6/14/2017 8:17 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Stage 3 redone. I didn't feel like I was missing any weapon needed to save even one frame, so this stage is essentially floating as to where it can go in the stage order. Item drops are very important, so item manipulation may cost or save a few frames from a different internal frame count. For those keeping score, 1200 frames of savings versus Team 4 so far. 43547 is when this TAS gets to stage select after Stage 3. 44747 would be when Team 4 got there (equal route so far). In terms of Stage select, 3>2>5>6>END, 3>2>6>5>END, 3>6>5>2>END, and 3>5>6>2>END all take identical cursor frames. In terms of animation frame rules: +2 - 3>2 +3 - 3>5 +1 - 3>6 Probably should check other stage transitions as well. Did different stuff with boss to play around with the fact I had 5 hits left on the barrier, but otherwise matched Team 4's time. I blame dialog frame rule for any slowness here. EDIT: My notes:

END FC MOD 4 == 1  Stage entry
s2  FC MOD 4 == 0
s3  FC MOD 4 == 1
s5  FC MOD 4 == 3
s6  FC MOD 4 == 0

            s2 s3 s5 s6 EN  s2 s3 s5 s6 EN
s4 exit: 3   3  1  1  3 --  +1 +0 +2 +1 --
s2 exit: 0  --  2  3  2  2  -- +3 +0 +2 +3
s3 exit: 0   2 --  0  3  2  +2 -- +3 +1 +3
s5 exit: 1   0  1 --  3  1  +0 +0 -- +1 +0
s6 exit: 0   2  3  2 --  3  +2 +2 +1 -- +2

         IN >1 >2 >3 >4 >E To
45623E - +0 +2 +1 +2 +3 +3 11
43256E - +2 +0 +2 +0 +1 +2  7
43265E - +2 +0 +2 +2 +1 +0  7
43562E - +2 +0 +3 +1 +2 +3 11
43652E - +2 +0 +1 +1 +0 +3  7

Top block. Entering a stage depends on the animation frame rule. The numbers basically state that, internal Frame Count modulo 4, if we enter a stage when that is true, we lose zero frames to the frame rule. Middle block. Left column tells me that, on exiting the stage, what the game's internal frame count modulo 4 is (during the block of lag before selecting the stage). This is based on teams who beat the respective boss the fastest. Left block tells me frame count modulo 4 is when selecting the target stage (accounting frames needed to select the stage, of course). Right block tells me how many frames I'm wasting on frame rule. Bottom block. Routes shorthanded. The IN column is how many additional frames we spend on input for cursor movement. The rest are the frame rules we're losing frames to, and our total frame loss. Three routes to pick try apparently.

Posted: 6/13/2017 2:24 AM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

One more update to the script, and now it'll alert of any changes in CPU behavior, by recording what happened on that frame, and when you rewind back to before that frame and do different stuff, if they did different stuff. The ghost recording in the script is also changed a bit. Not been wanting to analyze much since my last post, so I'm giving script stuff to help that analysis instead.

Posted: 6/12/2017 4:54 AM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

So, basically spawning a CPU car really close behind the player, going fast enough to push us. And the movie does so repeatedly. There should be enough in the script to tell when this happens, by the fact there is a + where there was emptiness just a frame ago, and if that happened outside radar view, a major change in the segment watch. As for predicting or manipulating it in advance, I don't have any particular inspiration to follow to script that. I'm pretty sure it's a chain of spawns in the opening, though it is hard to tell from the video alone. EDIT: Now that I think about it, I can script up something similar to the ghost recorder, tracking every position other than the player, and giving an alert if there were any changes since the last time you got back to that frame. It still wouldn't predict, but it will notice even 1/256 pixel difference in behavior. If CPU drives different at all from player interaction outside of collisions, it might be useful to get this detection.

Posted: 6/11/2017 9:22 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

.bk2 I was messing with. Mostly what I want to ask is if this is the type of hit you want. One where we leave the collision with a high speed. The start itself isn't what I'm asking, but the part where we collide. Haven't seen any obvious speed changes on the Training CPU itself, however. It also briefly attempts some speed limiting in the following curves, to prevent that hysteresis from kicking in. Something else I experimented with when it caught my attention.

Posted: 6/11/2017 7:14 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

The ghost recording is a script thing that marks positions of the player while the red REC is visible. Turn this red REC off by holding M and frame advancing exactly once. Turn it back on by doing that again. With it on, the ghost will always be reported with the player, but with it off, the script will stop updating its internals and show what it has. Basically, have REC on, run some movie you've done, turn REC off, then try to TAS some improvements. The radar will report your old positions with the X. So, that whole "wallhit" thing where CPU seems to catch up faster... Trying to define what parameters I'm looking for. I can experiment a bit until I get a new effect, then do some searches, but I'll see what I can find.

Posted: 6/10/2017 11:32 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Okay, more stuff in script. Ghost recording for radars. The recorder has zero intelligence, and is generally there so you can more easily compare stuff you did not too long ago. Since I already have the framework, it wasn't hard to add in. Oh, and a frame timer letting you know how long until you land, at the longest. As for more scripting on other GBA F-Zero game, I will give no guarantee. If I do, consider it a bonus. I have memories of this game, but not the others.

Posted: 6/9/2017 8:24 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Changed up the script a touch. Hopefully it'll be easier to identify when mines appear.

Posted: 6/9/2017 6:35 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

I'm not entirely certain about the five numbers myself, other than they're probably related to the machines currently loaded. The game allows up to 5 machines (player occupies one of them), and they are colored to match the plus signs on the radar. I've selected those numbers to see if they're a good enough indication to tell if the machines are loaded. Haven't yet put in the time to analyze those machines, though. Mines are the ones you want to identify quickly, so I'll make my focus there. I have done a sync test, by getting a copy of your verification's first track and running it again after winning Pawn Expert. The copy worked flawlessly. This indicates a possibility that you can just work on later tracks and expect a sync after improving an earlier one. Just a possibility, though. Yep, I was reading too many bytes for the speed. Sorry about that.

Posted: 6/7/2017 2:55 AM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Dwedit wrote:

You killed the animals!

c-square wrote:

Didn't save the animals...

At least Samus didn't leave them behind. Never saw any visual indication she returned to the ship before the planet exploded. The ship itself is fine, obviously.

Posted: 6/5/2017 5:06 AM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Well, it gives me time to try some improvements to the script before you start. At least work out the interesting ideas I have, anyway. Still nothing yet on how things spawn. Although, I have rescaling displays and a few things that can tell me the moment things spawn, but how they do so is another question.

Posted: 6/3/2017 8:31 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

The way I envision the radar is to give positions from a birds-eye perspective, local to where you are. I can probably code something to orient it to what your facing is, or always orient north. I say rival radar because it sounds nice (contains alliteration), but I'd be looking for all objects, which hopefully mines count as objects. As for how those mines generate, that will be trickier. I have a verification movie that plays the game for me, so I can search for changes in RAM based on that. There isn't a lot in the Game Resources page at the moment. Generally detailed stats of each machine and locates some machine stuff in RAM. Populating it with useful tricks as we discover them might be useful. EDIT: Well, here's a script. My descriptions on the numbers are sparse, but if I don't need to explain them, then they are self-evident enough and good to go.

Posted: 6/3/2017 7:19 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Alright, someone who wants to try TASing this. Don't forget the Game Resources page: Wiki: GameResources/GBx/FZeroMaximumVelocity Something that probably should also be in the verification is going into the options to change controls (to Type 5 or 6). The defaults for boosting uses L+R buttons, but changing it so that Up triggers the boost means you're not spending 6 frames without that side movement. I'm not aware of anything Up does, not even in jumps. Is there anything you'd like from scripts? Visual compass indicating facing and momentum? Rival radar? RAM Watch alternatives? This is something I'm interested in giving support.

Posted: 6/3/2017 5:20 AM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

So I made a start on Stage 3. My route after falling through Segment 1 is not optimal. Taking advantage of a Fragile Barrier to shoot freely while protected means that I'm well ahead of the leading team, who didn't. The complexity of the next segment made it not very clear what was the fastest path through, but apparently, whatever I did up until the save platform was overall a good choice, then it quickly falls apart between there and the miniboss. I realize now that it can seemingly go through walls as long as the bottom pixel is on air blocks. My route had me on the ground, which wasn't high enough to spawn that enemy by walking back. Still, in case anyone wants to look through this stuff, I have this now.

Posted: 6/1/2017 8:36 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Stage 4 was looked over. The bests of three teams were used here (3,4,5). Careful item drop manipulation was required. At this point, our route opens up. Someone did Charge Swaps with the bubble barrier, which normally restricts weapon usage until 6 hits, but Charge Swap generally gets around that problem. This means we can use them in places where those needed 6 hits would have otherwise been a problem when we can't shoot for obviously required things like breaking certain walls, flying with Flame Charge, or beating up minibosses. Assuming no weapon in any of the later four stages are needed for any other of the later four stages, one would assume 4->5->6->2->3->END, as this requires only one frame of cursor movement each time to select the next stage. Problem here is that the stage entry can be delayed anywhere from 0 to 3 frames thanks to animation frame rule. This will need some analysis, though, but at least it looks like we're otherwise free to pick the order. Ah, anyway. Stage 4 is better optimized, so we should have fewer regrets poking at later stages at this point.

Posted: 6/1/2017 4:38 AM

Post subject: Precedents!

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

There are two precedents I can think of that might be relevant. [2215] SNES Claymates by quietkane in 15:21.92 This Claymates TAS triggers warps in a very similar fashion as seen in this TAS: Go to an arbitrary spot, and do this arbitrary action that normally wouldn't do anything special. Mind, the game tells the player about the warps when they get far enough and find the messages (they're not that hard to find), but there are enough warps to get close to the end of the game. Are they cheats? Are they methods for the player to return to later areas as an alternative to saves or passwords? Should they be treated like warps in Mario games? [348] NES Crystalis by TheAxeMan in 43:38.58 A rather old precedent, but this is a movie that used warps, and was later obsoleted by one that did not, even though the next one took longer. It is most likely a debug thing, as it uses the second controller and generally the game isn't really set up to deal with these sorts of warps. Even though these debug warps don't really skip huge parts of the game, like some accepted normal warps or even glitched warps of other games, it was still determined we shouldn't use the debug warps like this one in TASes. Just some runs that stick out in my memory. Hopefully these precedents give some guide posts to work from.

Posted: 5/27/2017 8:01 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Made a start here. Most of the changes are in the comments there. I'm generally putting aside ammo issues with the idea that I haven't planned ahead on changes to item drops. The main reason for Team 4's damage before the boss, during DTC, was so we can take the damage after the boss is in the dying state, giving our vertical motion 16 frames delay and letting us land on the terrain as it loads. Team 3 clearly didn't need that, so when I'm in more of a mood. I'll look at this spot and figure out the optimal strat. Then again, I lost 2 frames between two useful points of comparison. Could be the spot I paused in. Could be the invincibility 2-frame rule. EDIT: An attempt at handling the miniboss now. I strongly suspect there's a faster way, though.

Posted: 5/26/2017 5:32 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Those inflated multi-megabyte sizes are due to the fact a .tasproj (BizHawk) or .fm3 (FCEUX) keeps a whole bunch of save states in the file. Both emulators have an option in TAStudio (BizHawk) or TASEditor (FCEUX) to export to a .bk2 (BizHawk) or .fm2 (FCEUX), which do not dedicate many, many megabytes to save states. BizHawk -> TAStudio -> Load project file -> File>Export to Bk2 FCEUX -> TASEditor -> Load .fm3 -> ... I forget precisely, but look for export. You want .fm2 somehow That should produce a file of a much more reasonable size for submission. Just curious... Is it considered cheating when using something with cheat in its name, and with enough power to live up to its name, when it's handed to you in the course of normal gameplay? Well, normal within the realms of the hack anyway. I don't know what answer to really give, so I'll leave that to someone else to look at. I also recall some of the re-fights in that hack do change things since the original battle, but other than that, I don't have further comments.

Posted: 5/23/2017 1:09 AM

Post subject: All segments explained as I know it. End of edit spam.

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

I did a direct copy of Stage 4. Curiously, the 32-frame rule lined up perfectly, so Team 4's run synced without issue. I'll be explaining each segment as I see them. Hopefully my suggestions will spark some new optimization. s4 - Segment 0 Opener Team 1 is reported fastest, except they took the sub. Sure, it ends the segment early, but then we're stuck in an auto-scroller. Obviously, we'll want to break the auto-scroller to save a few thousand frames, instead of ending this segment a few dozen frames early. Teams 6 and 4 are otherwise reported fastest, but it might be better to find a different measuring point somewhere in the next segment, where it's clear dashing along the ground at that moment is fastest in all "universes". s4 - Segment 1 "Auto-scroller" segment 1 A complex segment. Point in case: Team 4 used the charge glitch to double up on flame charges at times, and Team 3 didn't. Yet, despite the apparent advantage of double flame charge, Team 3 is still snapping close to Team 4's time. I'm impressed. A reminder on the charge glitch: We need some sort of control lock, and the situation needs to allow us to shoot (shot cooldown prevents chaining the charge glitch off a flame charge). Still, a second flame charge without 60 frames of charging in between might be worth being slow for 16 frames plus one frame of going the wrong way, as each flame charge is around 64 frames long. Then again, if we could dash for most of those 60 frames of charge, then charge glitch isn't helpful. It's mostly when we're stuck in the air, mostly. But this segment is a lot of air- er, water. In any case, Team 3 clearly did something right even with the advantage of this glitch that Team 4 used frequently. Comparing these two teams closely might help further optimize this segment. s4 - Segment 2 Miniboss Team 4 is fastest here. This is mostly because they took damage just before the miniboss, allowing them to charge a laser without the 16 frames of delay from damage. This delay is shuffled into the prior segment, where it takes up dash time instead, but since the slow damage boost is used for forward progress, instead of flatly wasted on the miniboss, this is a few frames saved. I also recall tweaking with the miniboss timing a bit under Team 4, concluding that the lag depends on the 4-frame animation rule. Any improvements probably should use Team 4 to compare against, I can't think of much else to really add. s4 - Segment 3 Short right, after miniboss Teams 7 and 6 are fastest here. Except that Teams 4 and 3 set up Ghost Fall, and the results can be seen in the following segment. So the teams we should compare are just the two leaders. I've already taken a look. Team 4 lands after save platform, but must scroll the camera dashing back and forth. Headbonked at ladder. Team 3 lands on save platform, and did not need to dedicate dashing for camera scroll. Did not headbonk at ladder. s4 - Segment 4 Down segment Our two leaders did their Ghost Fall here. Ignoring terrain might be nice and all, but it doesn't guarantee identical times, as Team 3 avoids damage by shooting stuff, which Team 4 loses time on ouch frames. I did experiment a bit here after seeing Team 3's run. They do reach the next segment sooner, but with a worse camera than Team 4. A bad camera doesn't guarantee lost frames, as we still need to go all the way to the right for the ladder at the up segment near the end. s4 - Segment 5 Short right Team 4 is reported fastest here, but this is an illusion caused by the camera. As for player position, the two leaders should be pretty close together. Probably a better measurement point is somewhere in the next segment, probably on that ground down there, and comparing player position rather than camera position. The next segment is really complicated. In fact, that complexity begins staring from this segment, with Team 3 choosing the platform to dash on and Team 4 instead flame charges past it to land on the slope below sooner. So this is more of an extension of the next segment, and again, it's probably best to pick a moment in all "universes" where dashing is the fastest option. s4 - Segment 6 "Auto-scroller" segment 2 Once again, the two leaders are really close together, almost matching each other's reported time in this segment. Curiously, Team 5 spends the fewest frames in this segment, beating Teams 3 and 4. It's hard to tell if this is an illusion caused by setting up the fastest possible Segment 6 which loses time on the surrounding segments, but then again, this shows just how many "good" ways there are in rushing through this complicated segment. There just isn't enough information reported in the single number by my segment counter script. Finding good measurement points to tell how good you're doing is going to be real tricky in and of itself, so I expect difficulties in comparing every team on this. Still, we're going to want to crawl through them carefully for any inspirations. s4 - Segment 7 Short right, auto-scroller aftermath This is a new segment in and of itself. Like with Segment 3, it's supposed to catch the player as they exit an auto-scroller, but since we broke those, it just looks like an extension of the previous segment. And it definitely feels like one, right up until we get to that ladder. Times are all over the place, with Team 7 winning here. Could be as simple as the camera being in a good spot relative to terrain, and this says nothing about their position to the ladder. Once again, we have difficult comparisons to make. s4 - Segment 8 Up segment Up the ladder, basically. This is where camera positions come back and skew the reported values, as no matter what we do, we need to reach that ladder on the far right. Naturally, teams that didn't Ghost Fall are more to the left relative to camera, and therefore the reported values claim they are slower than the two leaders by a significant margin, which is basically an illusion as they merely loaded the segment sooner. As for Team 3's lead over Team 4, I sure thought I had a clever idea during the DTC, but 12 frames? Hard to say, but I don't think the camera differences alone between these two teams can explain that. s4 - Segment 9 Door segment A short dash left, a jump, walljump, and another dash to the right as we rush the door. Team 4's route probably should be taken. I can't think of a lot to say. Then again, they do take some damage I couldn't avoid during the DTC. Ideas would be nice. s4 - Segment 10 Boss Use optimal boss strat. Which is always hit boss on first frame we can, and with enough damage dealt to count every hit point. There's a reason the two leading teams have identical times.

Posted: 5/19/2017 8:21 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

In many cases, those turnarounds gain us a pixel, as we make a shorter jump.

Frame  - LoJump HiJump
f23657 - 221:+2 221:+2 -- Air
f23658 - 219:-2 223:+2 -- LoJump landed, must turn around to land
f23659 - 219: 0 225:+2
f23660 - 219: 0 227:+2
f23661 - 222:+3 227: 0 -- HiJump landed, no need to turn around
f23662 - 225:+3 227: 0
f23663 - 228:+3 227: 0
f23664 - 231:+3 230:+3 -- Point where it's basically decided who's faster
f23665 - 234:+3 233:+3
f23666 - 237:+3 236:+3

The point of the turnaround is so we make a lower jump. This lower jump will not land on the ledge unless we turn around and have the important pixel (our back foot) on the floor we need to get to. It is enough early that we can dash and make up for the lost pixels and a bit more. If we want to avoid the turnaround, we must hold A for one frame longer, as otherwise our important back foot wouldn't reach the floor, and because we're at the top of our jump, the +4 pixels takes a few frames to drop back down from. Long enough to lose to the turnaround shorter jump by one pixel. As for that horizontal section, loading the next segment to preserve our Screen X is important. Every frame we dash without unlocking the camera is another 3 pixels, and that's 3 frames at the door we can't get rid of, due to the fact the camera will always follow us if Screen X is between 80 and 104. We'll also need to jump on otherwise dashable ground to load the next segment, if I understand the situation right, so the losses stack up very quickly just so we avoid some flame damage. It is still worth checking to make absolutely sure, as each instance of damage takes 16 frames of hit-stun, during which we're moving 1 pixel/frame.

Posted: 5/18/2017 6:56 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

partyboy1a wrote:

It might be a good idea to create an encode without the level transitions, [...]

I agree. ~~So I created a script.~~ Actually, ignore that one. I created another script. Logic used is address 7E01FC == 0x56. Run it, run the movie, run the AV recorder. Any encoders? Quick math estimates over 13 minutes of transitions. EDIT: More detailed frame counting suggests 55694 frames of transitions. Something like 926.7 seconds, or 15 minutes and 26.7 seconds. Random thought includes setting the game to not play music, then adding in uninterrupted versions of the music played in the stages, but that means a lot more involved work with whoever does it. Transitions removed is already good enough on its own, for the sake of anyone else wanting to view this run minus transitions.

Posted: 5/15/2017 11:38 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

That one step back is now taken forward. Stage 7 properly complete now. I guess stitching in Stage 1 is next. I'm not aware of any tricks to do different from Team 4, so now's the time to chirp in with said tricks I'm not aware of. EDIT: Synced in Team 4's Stage 1. Did item stuff and despawn a flame stuff. Although we're ahead 8 frames by boss gate, we lose 4 frames somehow to the dialog frame rule, implying that I started Stage 1 on a different 4-frame rule that doesn't play nice with the 8-frame rule. In short, something's odd.

Posted: 5/14/2017 8:40 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Now all we need is to set up a loop of input that continues to rack up the score indefinitely. A looping input like what happened to Super Mario Bros. 2 (J) at some point. Nothing changes after the first 10 levels, I take it? I'm sure no one minds watching over 2.5 screens flipping through per second indefinitely. Definitely a fast run, in any case.

Posted: 5/13/2017 7:01 AM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Two steps forward, but one step back. We've got some more things to try and optimize out, such as the lag I ended up adding on the way to syncing in Team 4's run, and general ammo problems that came up as well. There are many enemies we can destroy on the way, but these options like to cause lag. At least Team 4's run mostly synced. Now's the time to iron out a few details and ensure we have every frame we can get, while still mauling the boss properly.

Posted: 5/12/2017 2:50 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Seems that soft resets weren't available due to a bug in emulation. We should wait for the fix before producing the final run, as the GBA BIOS takes a bit to wait through on hard resets. I haven't forgotten this game, don't worry. I've started Neil until Hole 11 of Marion to get a nice comparison against Ella. Stopped there because Neil apparently can't hole out in as few strokes as Ella can on that hole, and haven't wanted to continue from other things in life happening.

Posted: 5/9/2017 7:44 PM

Quote

FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)

Joined: 9/27/2008
Posts: 1085

Found another improvement, and fixed the boss. http://tasvideos.org/userfiles/info/38899122092553167 The boss should always be set up to sync. If it doesn't, adjust the gate delay until it does. The boss fight assumes the best dialog frame rule, and even if we redo the boss with a different frame rule sort of thing, we're not saving a frame anyway. The sync has to do with the interaction of the animation frame rule (4-frame, gate opening) and dialog frame rule (8-frame). The boss attack timing is dependent on how many frames it existed, and the boss does exist while the dialog does its thing. So, we (Team 4) didn't hit perfection here. Good to know that much, anyway. On a side note, I removed the stage select delay on the way to Stage 7. Its purpose was purely syncing the item drops, and is strictly a disadvantage to leave in the final product.