Posts for FatRatKnight

1 2
6 7 8
43 44
Posted: 9/28/2017 4:51 AM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
ThunderAxe31 wrote:
No, it looks like there is really no way to hinder the enemy for long enough.
I do not believe this statement. That is all.
Posted: 9/26/2017 10:19 PM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Part of the unloading terrain includes a chunk of wall. What I'm curious about is whether this gives the enemy more room to wander toward us, or if it'll respect the old segment and turn around at the old spot despite the fact it is no longer loaded. Apparently, External Radar isn't working in this almost latest BizHawk. Oh, frustration. In any case, this off-screen madness is just alluring. The skip would be so nice! EDIT: Apparently, the enemy does approach more once the prior segment goes away, if it is still moving right before its ouch delays. I was using my hitboxes script, a "secret" feature to adjust its scaling on the fly so I can use it to see off-screen hitboxes. So that leaves a few questions: Whether we can delay the enemy long enough to make use of this expanded space, and secondly, what we can use to reach this spot. There's still no way to make it actually enter the room onscreen, as there are legitimately loaded solid tiles in the way, but can we use this small edge at all?
Posted: 9/26/2017 12:03 PM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Some notes on s13 Boss Skip: * There is a ground enemy we can spawn from the door. * The enemy has 5 HP. * If it stays at the right wall, it keeps existing while boss loads. * Its movement is to bounce left and right rather fast. It won't want to stay. * We can delay the enemy by shooting it. * We have 0-damage projectiles available, including spikeball rebound sprites. * Most projectiles will not continue to exist, such as spikeball rebound sprites, when taken as far off-camera as the enemy when boss loads. We are close, but this is a nasty puzzle where we might just not have any way of actually keeping the enemy there. I don't have a lot of ideas left at this point. The only thing left I can think of is the interaction of this enemy and unloaded terrain. Basically one test to try is to pick a spot to hit the enemy, then cheat its ouch timer to hold it in place, then release it once the boss segment loads and the prior terrain goes away. If there's any favorable movement in unloaded terrain, we'll probably need to make use of that when we stop cheating.
Posted: 9/23/2017 5:07 AM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Completed making Stage 2 boss more entertaining. EDIT: This one ends better. I have managed the constraints of "no lag" and "no damage" in the movie. Over IRC, I've concluded that ThunderAxe31 can leave the ammo management against bosses up to others. Getting that laser ammo in the stage while keeping within the dialog rule must not have been easy.
Posted: 9/22/2017 3:35 AM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
ThunderAxe31 wrote:
Fragile Barrier: 1 damage / 3 ammo = 0.3 ratio (there are no situations to use this aganist bosses)
Challenge accepted. I will find a situation to use this against the Stage 2 boss. ... Well, I am working on trying to make the s2 boss entertaining. I will end up needing a heap of what I call "overflow damage" to make up for the 1 damage. In any case, the worst a mismanaged ammo usage has on us is we spend extra pauses using Ammo Tanks. All this ammo planning is so we save like 8 frames. We just got to make sure not to waste more than that on ammo drops for each pause we avoid. EDIT:
ThunderAxe31 wrote:
About the ammo management, I didn't implement the modify by lapogne36 as well. I think it's early for going extreme with ammo management on bosses, since we should use all the spare weaponry to improve entertain as most as possible. Still, thanks for the contribute, it may come useful later.
The problem here is that we don't have much spare weaponry to start with. Using what you apparently think is "all the spare weaponry" is what I think is "resources we can't spare." Our perceptions here are very different. Knowing ahead of time what weapons we will have available or otherwise means we won't crash into the problem of running down one stage and, oh, no Star ammo for the s14 boss skip. Go back, save a Star and... Oh, no Star ammo for the s15 skip. Go back, and... Oh, no Star ammo for the s16 boss. Why did we use so many Stars in the first place? There is no getting around using up 8 ammo off our Star, purely on skips. Even if we have 9 now, it won't be 9 later. Refilling it is a notable problem when Flame is our go-to stage weapon and Laser is desperate to refill whenever it's feasible. We will not see the end without a pause walking away from the s11 boss on 4 Star ammo, not while these two weapons are gulping down all our drops. There are small amounts of other weapon usage in other stages, though. I seem to recall something about Whirlwind, but I need to check the last movie we have that actually reached the end. Barrier is almost certainly another big one we use, so not many Bubbles left once we're done ignoring damage. All this is why I put an importance in planning our ammo now. Though, what blunts the edge of importance is the fact we can always go back and re-do bosses, so we don't really lose any progress in TASing later stages, but that means we're spending time going back to said bosses on lack of foresight. If you still don't think it's important, then I would advise putting minimum effort on the s9, s11, and s13 bosses (if we can't skip them), just enough to get hits on the earliest moments, just to see what ammo we will need later. We have a prior TAS to refer to for what things we'll likely need already. Keep track of the ammo we use on not-bosses.
Posted: 9/20/2017 11:34 PM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I've said it before, but without refilling certain weapons, we're rather limited on ammo on some of them. Only use them if you find you can refill them more conveniently than other weapons. Tentative use of them is fine, since we can just go back and use different weapons without losing sync. Flame - Used, refilled, and used constantly. Hard to say whether we can use it for bosses, though I'd like to say we can. Whirlwind - I don't recall much stage use. Mostly useful just for bosses. Dirt - So fancy, getting lag-free hits with the meteors. Needed a shot in s11, though. Bubble - I recall using 3 barriers. I also recall using a normal shot in a stage portion. That leaves 1 ammo. Missile - I don't recall much stage use. Mostly useful just for bosses. Star - We spend 8 ammo on skips alone, leaving only 3 ammo for other things. Spikeball - We've commonly used this thing on bosses before, so their use on bosses is obvious. One shot is used on a skip, but it isn't certain if we can just use another weapon. Laser - Lock break is a must for skips, and to mildly speed up non-skip intros. Ammo is difficult to acquire. Fixed the s8 entertainment. Restoring a less entertaining action, we no longer lose a frame to a mysterious transition lag following s7. I still blame the Program Counter being in some kind of bad spot. s2 boss doesn't look easy to work through, though.
Posted: 9/17/2017 9:23 AM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085 
Language: lua
local actorMove= {}

actorMove["Dies"]= function(x)
    -- ...
end

actorMove["Damage"]= function(x,damage,reason)
    -- ...
end
Doing it like this might work. Create the table first, then stuff it with the functions, rather than define the functions in the table constructor. As I understand lua variables, a variable defined on the spot can't refer to itself. Having local a= a, for example, will have the script look for a different variable a within scope to put into the local a you're defining right there. In your case, since the table isn't finished being constructed for the local variable you're making, any references to that name isn't looking for that local definition on that spot. It's looking for another actorMove that may have been defined earlier, or even a global one, anything within scope other than itself, essentially. Mostly going off of memory here, but just in case, create a function SelfAware() print(type(actorMove)) end and see what it gives you in your structure, and if you were to try my suggestion.
Posted: 9/16/2017 11:08 AM
Post subject: CamX, ScrX... I'm confusing myself, too.
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
We removed those 2 delay frames. But apparently there was a miscount of frames? Or was there a delay frame I missed? I noted we're at 7/8 delay at the door. Took a different route just before door to save the remaining regular frames, of which we needed only 1 of the 4 we got from the route, but it hits us with 3 lag frames. So, aside from retrying boss, what else can we do at this point? EDIT: No need for save platform now. Had a moment of inspiration when thinking about the door. There's a lot of constraints when it comes to touching the door optimally. Our dash hitbox is pretty wide, and if we're anywhere further right relative to camera than X 80, the scrolling has to get by an extra pixel, which is enough to delay the door animation, and that is on a 4-frame rule. So being on ScrX81 means the door takes 4 more frames than being at ScrX80. Of course, being at ScrX80 isn't enough. We're dashing 3 pixels at a time. On the frame we touch the door, we can be 1, 2, or 3 pixels inside the door hitbox. Anything less than 3, and that means the screen takes an extra frame in exactly the same fashion as a sub-optimal camera position of 81, and that one frame translates to four, as above. In addition, touching the door also hits this same frame rule. As it turns out, our non-platform route was just barely early enough in touching the door on the good side of the animation frame rule. Unfortunately, we were a pixel short. We were inside the door by 2 pixels, not three. The usual plan of walking a frame or two to fix our pixel alignment fails here, due to the fact we lose an animation frame rule on touching the door. So, we lose a frame rule because we are one pixel short, or we lose a frame rule because we are one frame late. There was one detail that annoyed me. Running my scripts, I saw that, when scaling the wall under the save platform, we actually had one pixel gap in our ascent. Since we're one frame short of meeting the dialog rule, and fixing the door rule would give us four frames, I would see if sacrificing frames here to align ourselves work. Yes, it gives us a pixel, but at an unforgivable cost! We're far enough left that the camera stopped following us, and we're now in an odd X position. Motion in the air moves us in steps of two pixels, and therefore we can't stop at ScrX80. So I ended up dashing to the door on ScrX81, eliminating any possible savings. The door frame rule is a vicious one. It may be every 4th frame it lets us through, but... it's not global. The reason why I've been making delays when the door is out of sight is because the frame rule is based on when it spawns. We ascend by wall jumps at 6 pixels per frame. Is it possible, perhaps, that we just hit a bad Y position? Yes. We had hit a bad Y position. I delayed the final wall jump up by two frames. Yes, we scale the wall slower, but this incremental change let me move to the right a frame later, but spawned the door two frames later. This key difference meant that, while I still have that bad pixel position as before, in addition to losing a frame, the door's schedule is delayed two frames, and that means I have the frame I can use to fix it and reach the door just in time. A sacrifice of two frames for want of a single pixel, for want of an animation frame rule, for want of a dialog frame rule. Door animation frame rules are important.
Posted: 9/16/2017 9:22 AM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I have created a function that I've relied on in a few scripts for exactly this. 
Language: lua
local keys,lastkeys= {},{}
local function UpdateKeys()
    lastkeys= keys
    keys= input.get()
end
local function Press(k)
    return keys[k] and not lastkeys[k]
end

while true do
    UpdateKeys()
    if Press("A") then
        --Triggered once whenever you press A
        --Insert generous amounts of code here
        --Wait, try to keep the code readable...
    end
    if keys["J"] then
        --Triggered repeatedly while holding J
        --Insert other sorts of code here
    end
    emu.frameadvance()
end
No need for a deep copy here. Just reassign the tables you get. Just make sure you assign the old table to the old variable before you get the new table. We don't need to properly copy every individual element, as input.get keeps spitting out a new table each time, and each table already holds all the information on the keys. However, I'm not entirely familiar with BizHawk's functions. Since I used emu.frameadvance(), the script isn't re-running the code while emulation is paused, so one might want to look over the function list for a better fit.
Posted: 9/15/2017 7:55 AM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
External links to the code mentioned in the submission text and the publication text are no longer working. Error 404. Requesting new public access to the code. I would like the pathfinding, battle planner, and run planner not to be lost to time.
Posted: 9/11/2017 9:21 PM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I prepared a file where we lose the 8 frames, in a rather obvious delay, in case we can't re-route without losses. The sync was easy enough. Still, generally the point is to move the saved frames as far forward into the movie we can. At least they are closer to the end spot than lost unclaimed in the middle, so later improvements won't have to look as hard. If any were ever to show up, anyway. I don't have any ideas on how to keep the one frame rule. If you're ready to move on, there's the file.
Posted: 9/11/2017 2:01 AM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085 
for key, val in pairs(Actor) do
	roomData[currentRoom][2].key = val
end
As an aside, using .key in this case more literally translates to ["key"], as in you're specifically selecting the element indexed by the string "key" over and over again, as opposed to the key value you wanted, which could be other sorts of things, and most certainly not just a repetition of "key" over and over. More appropriate for the loop would be: roomData[currentRoom][2][key] = val But things are cleared up anyway.
Posted: 9/11/2017 1:18 AM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085 
30244 .....2.5...52....2X..5....5....2  9 ammo
30319 .....2.5...52....2...5....5.X..2  8 ammo
30378 .....2.5...52....2...5..X.5....2  6 ammo
30419 .X...2.5...52....2...5....5....2  6 ammo
30439 .....2.5...52....2...X....5....2 11 ammo (from 6)
30480 .....2.5...52....2...5....5...X2 11 ammo
30582 ....X2.5...52....2...5....5....2  9 ammo
30702 .....2.5...52....2...5....5.X..2  7 ammo
30941 .....2.5...X2....2...5....5....2  9 ammo (from 4)
31154 X....2.5...52....2...5....5....2  5 ammo
31281 .....2.5...52....2...5....5....X  5 ammo (from 3)
31593 .....2.5...52....2...5.X..5....2 -1 ammo (not possible)
Our luck manipulation field. The frames we make our kills, where we are in our item cycle when the kill is made, and our resulting ammo after the kill. We need at least 4 ammo on our way out of 31593 kill. Note I had to cheat to get the last entry, as we're bone dry on ammo by then, and couldn't make one more flame charge. We can't charge on 1 ammo, but if we could, we would have -1 after the fact. I'm not optimistic. We can't store more than 11 ammo, so we really need to manipulate stuff after 30480. It does not look feasible to make lossless changes in kill timings for a lot of these in our route (heavy, heavy use of Flame Charge just to go places). If we do hard delays, losing parts of our 8 frames to do so, keep in mind it also delays all later kills. We can theoretically delay 1 frame, then 2 more, on the 30582 and 30702 kills, but then we lose the +5 at 30941. I'm not sure of any re-routes we can do to get through this segment. The path we're on is pretty rigid. We can intentionally lose 7 frames on the 31154 kill, then one more frame on the next kill, to match what we've got previously. This, however, would be basically admitting we can't preserve the 8 frames, losing them all to bad RNG, and only walking away with a single lag frame saved. Incidentally, here's our previous RNG route: 
30252 .....2.5...52....2...5....X....2 11 ammo (from 9)
30327 .....X.5...52....2...5....5.X..2 11 ammo (from10)
30386 X....2.5...52....2...5....5....2  9 ammo
30427 .....2.5.X.52....2...5....5....2  9 ammo
30447 .....2.5...52....2...5....5..X.2  9 ammo
30480 .....X.5...52....2...5....5....2 11 ammo (from 9)
30558 .....2.5...5X....2...5....5....2 10 ammo (from 8)
30710 ....X2.5...52....2...5....5....2  8 ammo
30937 .....2.X...52....2...5....5....2 10 ammo (from 5) +Lag
31163 .....2.5X..52....2...5....5....2  6 ammo
31290 .....2.X...52....2...5....5....2  9 ammo (from 4)
31602 .....2.5...52....2...5....5....X  5 ammo (from 3)
Posted: 9/9/2017 8:00 PM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I like the part where J.B.Crystal slammed into you. And the part J.B.Crystal slammed into you, followed by the part where J.B.Crystal slammed into you. Geez, these rivals sure like to keep up! I am worried about your power. The Jet Vermillion may be durable, but starting your third lap out of five with scarcely more than half your health remaining makes me worry you're going to get less out of your 5th lap boost from critical damage. In any case, that's a pretty fast lap.
Posted: 9/8/2017 10:41 PM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
roomData[currentRoom][2] will contain the same reference as Actor, and modifying elements within Actor elsewhere will also change elements within roomData[currentRoom][2], as they point to the same object. Creating a copy of a table, as opposed to simply assigning another reference, is a little more involved.
Posted: 9/8/2017 10:28 PM
(Edited: 9/10/2017 11:15 PM)
Post subject: movie tag? Er, make that userfile tag. Embarrassing.
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Added Stage 1 boss antics. Not a lot I can do if the goal is avoiding camera movements, but here it is. As much trial and error it was to reduce lag with the script, imagine figuring things out lag minus the script. Next is Stage 4. I don't know if it's possible to maintain the 8 frames with different item drops there. I somehow got enough drops to avoid pauses, and even one Ammo Tank used will eat all the savings.
Posted: 9/7/2017 8:31 PM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Oh, now that's an interesting page. What's this metatable thing? I'll admit there's a few things I still don't know. Well, I get the impression you want to do something like this: Enemy[1].HP_Now Enemy[6].Attack This would require another table. In this sense, you can do a for loop to create each thing. Making it shouldn't be too rough. 
Language: lua
local function GetStats(addr,o)
    o= o or {} --Construct a table if we didn't get one
    o.HP_Now= memory.read_u16_le(addr+0x00)
    --... And so on
    return o
end

local Enemy= {}
for i= 1, 6 do
    Enemy[i]= GetStats(0x8000 + i*0x60)
end
Reading it wouldn't be too hard, either. 
Language: lua
for i= 1, #Enemy do
    local Cur_Enemy= Enemy[i]
    if Cur_Enemy.HP_Now > 0 then SomeKindOfCode() end
end
This is sort of what I'm thinking of. Is this the right sort of direction you want? Or would you prefer full-blown class style treating each table like a full object?
Posted: 9/5/2017 8:00 PM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
As a standard policy here, anything game specific doesn't belong in Tool-assisted laboratory. It belongs in the appropriate game thread. Second, this is how we currently handle the 1st key. Review the method if you haven't already. Finally, an explanation on loading zones. (We might need to link explanations everywhere the TAS goes) The castle area is broken into several areas: * Outside castle front * Main lobby area * Boo's garden * Underground area * Upper areas The only way to transition from one of these areas to another is through some sort of loading trigger. All such triggers in the castle are by opening doors. The reason the Backward Long Jump (BLJ) works from entering lobby to Bowser in the Dark World is because that hallway is loaded along with the lobby. That type of door is merely a transition of position, not areas. We can already change position with the BLJ, so we skip the door object in our way. Same for Bowser on the Fire Sea, and on the way up after getting through the key door on the way to Bowser in the Sky. Or any of the star doors between us and any of the worlds. Both key doors are triggers for area transitions, an entirely different type of door. If we glitch through them, we do not trigger the proper opening animation. Without this opening animation, we don't trip a loading trigger. As a result, the next area remains unloaded, and all we achieved was trapping ourselves in a tiny chamber behind the door. There's no trigger for Mario to walk into, he has to physically open the door, and only a key can do that. The ground floor of the castle is trivial to enter, I don't feel the need to list them. Basement has two known access points: * Key door * Moat door Technically, it has more access points, in the form of dying or collecting a star in each of the courses it contains, but there hasn't been any known way of reaching those without first reaching the basement. The moat door has the advantage of not needing the key, so Mario can open it without first needing to beat a Bowser. The key door is the only other access point, and there is no way to get through that door without the key, as explained above, it's opening the door itself that gets our transition, not glitching past it. To reach the upper floors: * Key door Other than the courses contained up there, we have no other way of getting a transition there. The BLJ is decidedly obvious with the nearby terrain, but thanks to the fact opening the door is itself a trigger, we would only throw ourselves into a small chamber and can't advance any further. You apparently intuited this, or perhaps had another reason, or else this suggestion might have come up instead. The same reason applies to the basement key door. I hope this detailed explanation helps you understand why your suggestion fails.
Posted: 9/3/2017 3:51 AM
Post subject: Wait, it's not "ignore Dexterity". It's just -2 Initiative.
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Came up with a script to count RNG calls. Just a call counter that runs the copy of the RNG algorithm and sees how many rolls it needs to make to get the new game state. 22-26 calls - Combat start of first battle by walk-fight (preferred method due to distance) 18 calls - Combat start of first battle by menu-fight (not making extra checks to fail Hide) _4 calls - Kobold killed by melee attack _1 call - Magic Missile cast _3 calls - Kobold killed by Magic Missile _1 call - Kobold acts (generally two calls, one for each "half" of the turn) _4 calls - Party member hit by Attack of Opportunity _4 calls - KO'd party member hit by other Attack of Opportunity The difference between Walk-Fight and Menu-Fight is that apparently your party is surprised and has less time to react when walking straight into a fight. Walk-Fight: * Enemies get +2 Initiative * Individual party members check Listen (DC 10). If that fails, check Spot (DC 10). If that also fails, -2 Initiative Menu-Fight: * Party gets +2 Initiative Dialog-Fight is identical to Walk-Fight. Walk-Fight is preferred purely because there are almost no situations where you can Menu-Fight while next to an enemy group. The close distance means no movement is necessary. Melee attacks (on hit, not miss): 1) Chance to hit 2) Damage 3) Fluff 4) Fluff Casting Magic Missile: 1) Casting the spell 2) Fluff 3) Damage 4) Fluff Kobold action: 1) Thinking Walk-Fight: 01) P1 Initiative 02) P1 Listen Check DC 10 +02) P1 Spot Check DC 10 03) P1 Hide DC 20 04) P2 Initiative 05) P2 Listen Check DC 10 +05) P2 Spot Check DC 10 06) P2 Hide DC 20 07) P3 Initiative 08) P3 Listen Check DC 10 +08) P3 Spot Check DC 10 09) P3 Hide DC 20 10) P4 Initiative 11) P4 Listen Check DC 10 +11) P4 Spot Check DC 10 12) P4 Hide DC 20 13) K1 Initiative 14) K1 HP 15) K2 Initiative 16) K2 HP 17) K3 Initiative 18) K3 HP 19) K4 Initiative 20) K4 HP 21) K5 Initiative 22) K5 HP Just about ready to determine battle start. So, that's what Spot and Listen does, I originally thought they did nothing. Listen is checked first, and if that fails, Spot is then checked (changing RNG rolls of later stuff). If they both fail, -2 Initiative, making it less likely to go first. I do not know about Feat bonus (+4 by Improved Initiative; +2 by Thug), but they probably still apply. Snap, now we have to take into account Wisdom, and whether we shoveled points into Listen on character creation. Another facet of manipulation to complicate our machinery. EDIT: Real quick, here's our bonuses: Garon: +5 Listen, +3 Spot Wobby: +2 Listen, +1 Spot Fodder: Unknown, as follows: * -4 to +4 - Wisdom rolls * +2 - Alertness Feat (if taken) * +2 - Skill ranks (if taken) * Racial Bonuses: . o Moon Elf: +2 Listen, +2 Spot . o Lf. Halfling: +2 Listen . o Half-Elf: +1 Listen, +1 Spot . o Rock Gnome: +1 Listen So Garon getting a roll of 4 or less on the Listen check will trigger an extra RNG roll at combat start. Wobby might trigger this extra roll on a roll of 7 or less. The two fodder are... Unknown, since I can theoretically pick a number of options like Hide or Improved Initiative, to say nothing of the random stat rolls. We can theoretically get a bonus of +10 at the start for our fodder, though +9 is needed to guarantee avoiding the extra RNG roll. If necessary, we can get +6 for taking Alertness and picking Listen for our skill points, and I predict more potential cases for either Moon Elf or Lf. Halfling for quick suicide in the first battle. Note that the game rolls 4d6 for each stat, taking the top three dice and discarding the lowest one, to determine stats, so low Wisdom is unlikely. Don't expect a 3 Wisdom to show up.
Posted: 9/2/2017 7:35 AM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Found a somewhat old script. It doesn't work because none of its parts are fully intact to work with. Essentially a Work-In-Progress I have abandoned a long while ago. The script wasn't designed correctly for ambiguous stats, anyway. I will continue to ask for help simulating this, as I clearly haven't met success when I was trying back then.
Posted: 9/2/2017 6:47 AM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
That little glitch gave me an idea for a miniboss skip, but without success. Well, this is Stage 8, where we don't have Miniboss Skip done. You have the spiky wheel enemy following you for a while. Any chance we can lure that to the next segment? I jump the wall after the spikes. The enemy doesn't disappear. Cool. I continue further right. Enemy gets stopped by something down in that area long before the next segment loads. Snap. If I can't lure that spiky wheel enemy, maybe I can find another? External Radar has spawn points included in it, so I can find them rather readily. Right at the start of Segment 3 (down segment), there is a spawn point for the spiky wheel enemy, but to spawn it, we just need to scroll the camera down a touch, then back up. Not really a problem. Now, can I send this thing off the left side of the camera, and lure it down a ways? No. Enemy will not travel left past the camera edge in that segment. I hate it whenever I'm trying to make the game act wrong, it turns out to act right enough to avoid this wrong thing. EDIT: Something from ThunderAxe31. We're trying to save a frame in Stage 8, got one before the miniboss, but hit a different frame rule somewhere between the ladder after the miniboss and the bullet an enemy shoots. https://filebin.net/m1u9uybxp5a3kp4j/ZM_s0_touchups_3.tasproj
Posted: 9/2/2017 4:23 AM
Post subject: Copy/paste from IRC!
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
[21:15:16] <dwangoAC> Someone want to update the AGDQ thread to note that we're on the schedule for Battletoads and SMBall2 tomorrow at some odd time? Just transmitting a message from IRC.
Posted: 8/30/2017 5:14 PM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Well, the problem with intro miniboss is that any vertical movement scrolls the camera, which means we'd have to limit our jumps. Which are rather required to make any hits. Taking a second look at it full speed, I do see what you mean. We'll want to limit it to whatever jumps are necessary to hit, and to avoid being hit. This does mean we will only have one dimension of movement to entertain with, for the most part. I do like how quiet the first half of the intro is, then suddenly we get a lot of extra lives padding out that one visible counter. If we need Ammo Tanks, beyond our starting three and any extras we accidentally pick up in later stages, you'll know where to go to get more. As for the one frame desired in Stage 8, we can prepare later stages for when we do get that frame. Just insert 24 frames at the next stage select, then re-manipulate those items. If we then get that frame, we'll have a movie file prepared ahead of time that all we need to do is combine the 8 frames saved with the 24 frames we intentionally delayed and have a complete sync thanks to the 32 item cycle. EDIT: Stage 0 miniboss has fewer jumps now. Hopefully the reduced amount of camera scrolling helps things. Oh, and before I forget, I do like the actions around the flying enemy while we wait. Apparently we're glued to the platform trying to jump repeatedly. We also weave around bullets, yay! The last short hops make me think "come on, fly over here already, you can do it."
Posted: 8/30/2017 2:28 AM
Post subject: Re: Maybe skipping boss 5 re-fight.
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
ThunderAxe31 wrote:
Edit 4: I improved the entertaining in Stage 0, except for the miniboss. I don't feel inspired for that, sorry. I also need help for the miniboss in Stage 8.
Added: Senseless jumping patterns. Minibosses are kind of a big thing for entertainment. Bosses are kind of the other big thing, by the way. Here's what I could come up with for the first two minibosses.
Posted: 8/29/2017 2:18 AM
Quote
FatRatKnight
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Stage 8 frame improvement sync, I believe. According to my measurements, we're delayed 7 frames out of 8. One more frame, if it exists anywhere...
1 2
6 7 8
43 44