Posts for FatRatKnight

Posted: 8/29/2013 10:06 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

http://tasvideos.org/userfiles/info/8936028298677215 This is my own little start. I'll post a few more details in the other thread. You might want to know about it. However, I have no plans on finishing it up. ... If you don't see the post in the other thread yet, I haven't typed it up yet. Give me an hour, alright?

Posted: 8/25/2013 9:36 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

Huh... Interim svn2974 didn't have that cool highlighting. Would like to see it for myself at some point. I haven't been able to focus my time, but while watching a certain set of numbers I recognize as a type of ID number (addresses 0x317 to 0x335), the big ones that are in the way of the paths are ID 0x97, but this one shows up as ID 0xA4. This implies that this one is unique and may very well act differently from ID 0x97. Nothing certain, yet, but I saw this one as 0xA4 in my prior attempts, yet didn't seem to move then. Which means it might not be a glitch, but intended for an enemy, identical in appearance, to move unlike the other ones. It is a comfort to hear that this event does happen on the console itself. Regardless, when I can get the time, I'll take a closer look.

Posted: 8/23/2013 8:07 PM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

http://tasvideos.org/userfiles/info/8812040509984293 Uh... What. Is. Going. On...? I saw this like, just now. When I first saw it, I got scared and wanted to end it quick. Something glitched the big enemy into moving as though of its own will. The stationary big enemy is moving!! It's supposed to be stationary! But it's moving! ... Let's not end it quick. If I can glitch other ones into moving like this insanity here, the fact I'm lacking time bombs will not be an issue slowing me down. Anyway, initial reaction is over, it's time we make a thorough analysis. If it comes down to being an emulator glitch, I'd like to know. Really. Uh, what is going on? On a side note, thanks for the YouTube encode.

Posted: 8/22/2013 8:57 PM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

http://tasvideos.org/userfiles/info/8790394280676009 In case you're worried about whether progress exists. I am saving several frames here and there while also killing enemies from way off screen. I even realized I had fuel to spare when it comes to that second big enemy, so I used the terrain as nature's brakes instead of using pause-invincibility to bounce a little higher than I like. Also note how those big enemies spit out five smaller enemies really close together. The power of 2P can do that. 219 out of 375 gained from enemies. Considering how much is left of the planet, it looks like I will get the remaining 156 without too much difficulty. If I had also gotten that one enemy I missed, worth another 28, that would be just 128 left instead. But something messed with my Y speed when I tried that, and doing the exact same actions with an identical RNG caused a desync when I was 30 subpixels up from the original route, thus interfering with the "nature's brakes" I was using. In any case, the crystal-free route already has enough money gained by enemies to play around with the idea of anti-gravity without impacting my other purchases. Might only save a tiny amount of frames, including the minimal time spent purchasing it, but the possibility is there.

Posted: 8/22/2013 6:44 PM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

Looking back on it, I guess it's sort of a tangent, but thanks for your thoughts on my movie. Non-null default input is an extra specification, something most controllers don't leave themselves in without something wedging the button down. It also uses a password to get a state that can't be replicated without a password.

AnS wrote:

FatRatKnight wrote:
I can always modify my argument to instead pick unchanging input rather than blank input, if you prefer. I'm sure you know where I'm going by now.
I'm not sure I do, so I would like to hear the modified version.

I will copy and modify pieces of my older post. It's largely the same argument. To keep it more terse, I'm skipping parts that won't have significant enough differences. Why is locking a controller in an unchanging state a special method that doesn't need to be counted as part of the movie's time? Why is leaving it in a final state a desirable thing, when further changes can reach the credits faster? Is it because the input movie length is shorter? If one is looking to find a game completed as fast as possible (as currently known), the default input where further changes could do it faster denies such fastest completion. I consider all frames (aside from the user idly messing with the keyboard) after your input list to be a part of any run, just as much as if you had actually padded your movie file with them. Just because there is unchanging input after the end of my input doesn't mean that this unchanging input isn't part of the resulting movie. After all, people are going to watch it. Well, it's a modification where I replace a few words. I really can't think of a different way to explain it, so I'll just make it obvious and make no attempt at hiding that it's a direct modification to my argument.

AnS wrote:

If we modify our emulators to make them immediately start generating random input every time a movie ends, [...]

An interesting way to help enforce the "fastest game completion" goal, by encouraging the TASer to produce a movie where further input can't prevent the ending. There are still a few cases where even when the game won't accept further input that the ending can be extended or reduced a little. Super Mario World comes to mind: Mario and the princess needs to go next to each other before the rest of the ending plays, and this would have different times depending on Mario's position when you defeat Bowser. Then again, the ending is, rest assured, reached. If there's an overall strong desire to shift the standards around, this would be a decent start. I don't hate the current method of stopping input short, but I prefer the fastest end rather than the shortest input. I don't expect standards to change that easy, as people are used to it and seem to really hate when something changes. But it's a good test for the runners that, with my preference, want the fastest end.

Posted: 8/22/2013 6:10 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

Patashu wrote:

IIRC the only thing it changes is money, and you have infinite money anyway.

List of effects of difficulty: - Starting cash - Chance of disasters - Transit maintenance - Money gained from taxes - Effect on RCI-meter by taxes - The I portion of RCI-meter, beyond the taxes effect ... A lot of these wouldn't affect the TAS. The RCI-meter just needs a more strict ratio of zones, and the disasters can be manipulated away. Money-related things would have no real effect due to money trick. I haven't seen other effects of difficulty.

Posted: 8/21/2013 10:34 PM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

AnS wrote:

Actual state does not matter. The thing that matters is that the state is final and does not change anymore, but the game still finishes on its own.

This does imply that my April Fools' TAS is indeed just a little over 3 seconds long, as I do specify a final state other than empty where the controller no longer changes. The fact it uses a password makes things more questionable, but it technically completes a game faster than the King's Bounty TAS with that definition. For this line of thought, now I'm curious what you think of my April Fools' TAS. With the information we're discussing now, should it be published for the concept of finishing a game with a really short input file? (There might be other reasons for rejection -- One stat I use might be seen as a debug value rather than a glitch value, considering the effects) Mainly, I asked about a controller with no buttons pressed primarily because that is used as a standard here for ending a movie, by my impression. Technically, many movies published here can be "improved" by doing everything up to the last frame, then have the following frames hold the non-null default state in order to complete the movie, but I believe if such an "improvement" TAS shows up, judges will reject it for not actually doing anything new (or significantly different) compared to the old TAS. But that's an extreme example. I can always modify my argument to instead pick unchanging input rather than blank input, if you prefer. I'm sure you know where I'm going by now. Again, I only picked blank input as that's the standard I believe is used here, and that I also believe it is most widely understood around here.

AnS wrote:

Well, since I like playarounds more than pure speedruns, and I often support speed-entertainment tradeoffs, therefore I don't see any problem in delaying the game completion for the sake of showing some neat trick.

As for speed-entertainment tradeoff, I'm fine with those, should the runner choose to have a few. I'm less fine if the runner makes a significant point about avoiding speed-entertainment tradeoff but then proceeds to delay the game completion for the sake of a shorter input list. Though, I do understand the argument for a shorter input list, as that's the most consistent thing we can measure by.

Posted: 8/20/2013 8:04 PM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

I'm perfectly willing to help more directly. You don't need to TAS things alone, an advantage of being able to share progress with a partner. We can be co-authors, with my knowledge and your eagerness to get things done, we might actually have a better run done. But it's fine if you prefer to try it yourself, but I will still give a few test movies for you to look at. I'm also quite happy that you'll take constructive criticism with cheer. I was afraid of the opposite, but it seems the fear was unnecessary. Hope to see an improved run soon!

Posted: 8/20/2013 5:30 PM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

Arnold0 wrote:

What do you mean by "It is not good" ? [...]

By that, I mean I see clear ways to improve this run, under an identical goal that you've used. Between the fast camera pans while building stuff, you can take just one frame to move the cursor. This will help to build a lot of things faster, as well as speed up construction around the edges by a good amount. I'm curious if it's faster to just switch to the Police Departments while placing R-zones, rather than going through later to put them in. It also looks like an unnecessary amount of Police Departments. You might even be able to replace a few of the more inner ones with C-zones, which would be faster to select with the proposed method, and it doesn't appear that Land Value is dangerously low in those places (but I'm not positive about this). R-zones have a proper destination either way. This puts this submitted run on a poor outlook, with known potential improvements. I wanted to avoid stating this, as I hate to discourage anyone, especially when I'm looking for any potential partner in TASing. I know a lot from my earlier attempts, but knowing my habits, I won't make use of them alone. I believe if I have someone to work with, no matter the difference in skill level, it will help to keep me focused, as long as the partner shows willingness to keep trying. I do want to see a highly optimized SimCity run, after all.

Posted: 8/20/2013 4:55 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

Here's how the $999999 trick works... The automatic tax screen comes up and attempts to ensure that the maintenance percentages will not take more money than you have. The actual effects of maintenance will only happen one "clock tick" later, after you close the window. Holding any button prevents this "clock tick" from passing. The usual method, at this point, would have too little money to pay for maintenance and the auto-tax reduces the maintenance percents to fit. So it manually goes back into the tax screen to raise the maintenance again. This manually opened tax screen has no such safeguards in place to stop you from raising the maintenance. The method used here instead has enough money to pay for maintenance, so the auto-tax doesn't mess with your maintenance. However, while making sure that next "clock tick" doesn't happen, spend more money until you can't normally pay the maintenance. Now let time pass. Since the maintenance assumes the auto-tax did its job (a good assumption only if the player couldn't affect maintenance or money between these events), it takes your money, whether or not you have it. Thus, it sends the money to negative, then the game thinks it's a really big positive value, and clamps it to $999999. Someone wanted the trick explained, there you go. It's my interpretation, anyway. After all, I knew of the new method a few months ago. As someone who attempted to TAS this game, but lost motivation to do so... I will withhold my opinion unless someone specifically asks me to give it. It is not good, I will say that much for now.

Posted: 8/19/2013 9:55 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

I will ask one thing: Why is a controller with no buttons pressed a special state that doesn't need to be counted as part of the movie time? I do have an April Fools' TAS where I pick a default state other than null input, in order to cut down on the movie time. I didn't expect acceptance, hence the timing of submission. I don't disagree with its rejection, but this post isn't about the fact that a nonstandard default controller state was used. Rather, it's about the fact that ending a movie short is relying on some default controller state to finish the game, no matter how much it extends the time, simply because we're looking for a number that has nothing to do with the game itself. Why is leaving buttons unpressed a desirable thing, when further input can reach the credits faster? Is it because the input movie length is shorter? While we may feed a shorter list of input to the emulator, the game's completion is delayed. If one is looking to find a game completed as fast as possible (as currently known), the null input where non-null could do it faster denies such fastest completion. I suppose the biggest problem here is: How do we automate time to game completion? We can measure the length of the movie file, but not the length it took to get to the ending or credits, at least automatically. What puts time to game completion even further behind in consideration is the fact that the number of input frames is used and displayed as time taken in just about everywhere. Do we take the ease and automation of a length of a file as the one stat to focus on? When the game gets to the credits isn't a direct result of how long the input file is. It's a result of the run leading up to it. The games we run doesn't make the distinction of input file length. I consider blank frames after your input list to be part of any run, just as much as if you had actually padded your movie file with them. So far, most of my published TASes required some input that had a direct and immediate effect to reaching the ending or credits, and there really wasn't an opportunity to make a decision on whether to shorten the input time or the time to reach credits. But I still have a strong preference to what I want to aim for in the end, should I be given the choice from the games I run. I want to beat the game as fast as possible. If I can add further input to make it so, I will do so. Just because I have enough input to coast to the end doesn't mean that said coasting is the fastest path, I will look for a way to speed things up. Just because there is null input after the end of my input list doesn't mean that null input isn't part of the resulting movie. After all, people are going to watch it. That is how I view things.

Posted: 8/18/2013 1:20 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

If you have any desire for it, we can co-author a run. I find it helps me get stuff done when I have an active partner to work with. And hey, you're new. I'd like to help encourage more TASing from you, and you do want a more optimal run, right? I prefer lsnes, but I don't have any aversion to BizHawk if you want to stick with that, aside from certain lua functions I really want to use. I would like you to try lsnes for a bit, at least. And if you really don't like it, I'll shift over to BizHawk myself for this run, but I really want to have certain lua functions that lsnes has. I prefer the goal of shortest in-game time. That is, what's the earliest year and month in the game that we can get to 600k population. Mostly, I feel this encourages a crazier layout and unusual plans, as well as abusing another glitch or two. The wait until 600k population after input stops for a "shortest input time" run takes a long, long time. Letting you know my preferences. I'd like to know your thoughts about this.

Posted: 8/9/2013 8:17 PM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

Dragging wormholes in Planet 13 looks potentially beneficial. Using the published TAS for counting fuel cells, I could drag the wormhole towards fuel cell #3, then continue dragging it towards fuel cell #4, bypassing the need to climb all the way to that other wormhole. Planet 12, on the other hand, will only benefit minimally at best. On a quick estimate, the total time saved is really close to how much is lost on spinning the crystal. ... Hmm... That big thing in Planet 13 looks difficult to bypass on the return trip. I'll be experimenting for a bit to see if I can get by weaponless, but if not, that thing serves as a very tough wall. I'll optimize the RNG for money intake, but it's hard to say if I'll get enough. I also just experimented a bit with Double Strength Thrusters. Alas, they're not double as advertised, but rather quadruple strength -- I'm getting four times the acceleration with them equipped. Now that I'm finally experimenting with decent engines, I'm really feeling the strength of them. Wow, it's different. EDIT: While poking about in one enemy spawner routine, I have discovered that a particular enemy will spawn if either one of these happen: - Every 1024 frames, at a 50% chance - Every 256 frames, after three spins with the crystal However, at least one of the first three enemy slots must be empty, or that particular enemy won't ever spawn, with or without crystal spins. Judging from a time where this enemy successfully spawned, I am led to believe that this particular piece of code would spawn an enemy that drops a 25 chest. The enemy itself is worth another 3, so every one I spawn, I get 28. Before my third crystal spin, judging purely from the timers, I had a chance at spawning seven of those enemies. Then another six chances while wrapping up my spinny crystal attempt, then finally one more on the way to the wormhole. Assuming I can manage to shoot all these things without slowing down for an inch and also allowing them to spawn without other enemies taking up the needed slots, as well as the routine I was looking at does, indeed, spawn the enemy I'm thinking of, I can pull together 392 just from these things. This is above the 375 I require for the budget, and therefore theoretically enough, if I put strong effort into making that mess happen. The various value-5 enemies along the way I need to shoot as well does help slightly, of course. To help in manipulation, I can always abuse P2. I'd like to avoid that just so I can say, I did it with only one controller. Also, smaller file size. But if I absolutely need that extra manipulation to save even a single frame, I will, of course, go straight for P2 to do so, but I'd like to see if I can do it without P2.

Posted: 8/8/2013 9:37 PM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

http://tasvideos.org/userfiles/info/8480117589615625 I spin the crystal in this attempt. Over 1000 frames slower, however. All this just so I can drag wormholes around. The spin itself is quite smooth for the most part, but the fact I crash into walls more frequently suggests the increased difficulty of keeping it going. My fuel ran completely out just before getting it refilled the second time, as one more frame of thrusting would destroy the pod. Another trick that I haven't looked too deeply into yet, is the fact that I can apparently use some thrusting power without affecting the momentum of the tethered object. This involves alternating between using or idling the thrusters every not-lag frame. The basic thrusters are already very weak, but carrying an object as well as only using the thrusters half the time just makes it feel almost as though they don't exist. ... But I need to study that trick further. I only just saw some potential with it. Then again, I also need to study the tethering mechanics. I've only TASed this by intuition -- I haven't even bothered to look for the important RAM addresses for the tether or any of the code behind it. Does it look like I'm spinning the crystal fast enough? Okay, good enough! ... That will need some examining. We still need to get some estimates on any potential route where dragging wormholes is beneficial. We might not need time bombs, as there aren't any particular enemies in the way, except for the repelling orbs, but I'm not sure I can even reach them with bombs. But now we have a baseline for pulling together 8775 from a crystal. Optimizations still need to be done, if my explanations in this post are any indication.

Posted: 8/8/2013 12:42 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

http://tasvideos.org/userfiles/info/8460679018803471 Got through Planet 7. I need a baseline for the case where I don't spin the crystal, so that's why I haven't done that yet. The weight of the Golden Ship Part is ridiculous. I thrust downwards, and instead I'm getting pushed upwards. May as well make use of this quirk to get the part in that wormhole in a timely manner. Since it's getting more important to work out my shopping list, I think it's time I experiment with Star Bullets and see how useful a weapon it is. I might just stick with time bombs, but who knows? Two Double Strength Thrusters look to be ideal. One will be lost when I destroy a jetpod for a shortcut back. I've already sunk 2000 right there. Time bombs are the cheapest weapon, and I will likely want something to enhance my offense, so now the total equipment budget is taking 2150. Nothing else really looks necessary. I can probably manipulate a small amount more if I want to also pick up Anti Gravity. Maybe that will help. Crystal spinning in an attempt to get a jetpod to drag wormholes around might be nice, but to pay the 12150, I need to manipulate 375 from random enemies (difficult, by my impression), or hold off on some purchases until Planet 12. It takes a while to select either the thrusters or an upgraded jetpod, so it's best if I can just get them all right away. ... But I still have some things to optimize on Planet 7, as well as take a look at how long it'll take to spin the crystal around.

Posted: 8/2/2013 12:11 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

http://tasvideos.org/userfiles/info/8327020010578242 I very carefully tweaked with my velocity and positioning. I finally have a nice result I like, faster by a decent margin compared to before. Well, I do ricochet off something... But I make the game think it's the flat portion of the ceiling. This cuts my Y speed in half without affecting the X speed. In addition to rapid tether/untether of the fuel cell, there is a strange property of Y speed. When your thrusters are enough to cross over the zero point, it apparently applies your thrusters' force a second time, effectively doubling its Y power for that frame. Once I managed to stop descending, this error in calculation kept my pod up for that last bit until I clear the last spike. It can maintain height indefinitely, even in Planet 12, as each frame, if your thrusters cause your speed to cross over a zero point for whatever reason, the game messes up its calculations. There is a reason why I'm saying 'speed' instead of 'velocity'. The game uses a single bit in some byte to determine which direction in the axis you're going, and an always positive number for how fast. I say the game uses speed and direction instead of velocity, and insist that 'speed' is the proper terminology here due to internal storage. I took my sweet time on this one single part largely because of other stuff getting in the way of my TASing. Sorry about that.

Posted: 7/26/2013 12:31 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

http://tasvideos.org/userfiles/info/8171939460986207 Well, I am now successful in bypassing that big enemy. I don't see any obvious ways of doing it faster, as trying to have motion going to the right at the moment of impact is just bouncing me back out. Probably why I had trouble earlier. I've been throwing fuel at various bounces through the area. This might cause trouble when it comes time for the second big enemy. There is a spare pod in a decent spot later on, so I can lose the pod after getting the fuel cells without huge time loss. Then again, there's also a can of fuel also in a somewhat convenient spot after the second big enemy. Money... I am guaranteed 3000 by Planet 8: 1000 as beginning money, and 2000 from that crystal collection game. Crystal spinning gives another 8775 at some cost to time, but I'll have 11775 to throw around. I can probably manipulate 225 from various enemies for a nice, round 12000. More seems possible. I prefer concentrating on the parts leading up to the orange crystal before I try to come up with some future decisions. The Planets 8 and 12 shops might be worth looking through for this planning, but I'm focusing my time on this tunnel for now.

Posted: 7/25/2013 2:50 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

Ah, good. A successful attempt gives me some clue in what to try to get things to work. It was clear the sort of troubles I was having, so hopefully I'll get through this part soon. http://tasvideos.org/userfiles/info/8143796602738354 This here is my latest attempt where I kill the darn thing. The time it takes to get past this thing is the time to beat. Judging from the bypass you made, that shouldn't be a tough time to beat if optimized well. There's still the tunnel ahead that looks tricky to navigate well, especially with this weight heavier than the basic thrusters can lift. Most of the terrain below are rather less than ideal to bounce off of, but we'll see how good the angle is after trying the bypass. As for my shopping list, it looks like I will want the double-strength thrusters. If Planet 12's gravity is anything to go by, having less thrust than what is needed to lift my own pod will not let me get far. I don't know the exact benefits of an upgraded jetpod, other than the cheaper one can drag wormholes around and the more expensive one can use them to warp elsewhere.

Posted: 7/24/2013 12:38 AM
(Edited: 10/9/2022 7:47 AM)

Post subject: Huh, more data.

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

I took a look at the disassembly of the game, trying to figure out what makes the RNG tick.

Language: asm6502
;Function $00:920A
LDA $005A
AND #$48   ; Get XOR of bits $40 and $08 from address $005A
ADC #$38
ASL
ASL       ; Now it's in our carry bit.
ROL $005C ; And shifted into the big-endian RNG bytes at $005B and $005C
ROL $005B ; Upper bit that's shifted out is thrown away
INC $005A ; +$01
LDA $005A ; Many things are added to $005A...
ADC $0018 ; P1 immediate - Mirror of controller state
ADC $0019 ; P1 pressed - Bits are set if pressed now, but not held before
ADC $001A ; P2 immediate
ADC $001B ; P2 pressed
ADC $005D ; Frame timer low-byte
ADC $005E ; Frame timer high-byte
ADC $005F ; ? Unknown. Looks to be always zero so far...
ADC $0060 ; ? Unknown. Looks identical to $005D MOD 8
ADC #$0D ; +$0D
STA $005A
RTS

There is a two-byte shifter at address 0x005B that merely shifts its bits to the left. It is big-endian in its shifts, for whatever reason. The upper bit that gets shifted out looks to be thrown away, as the following INC instruction messes with the carry bit (unless I missed some detail in 6502 assembly in an embarrassing manner). The low bit that gets shifted in is an XOR of 0x005A bits 0x48. If 0x40 and 0x08 are different (01 or 10), we shift in a 1; If the same (11 or 00), we shift in a 0. Seeing as it doesn't feed back into the RNG, I must assume its used elsewhere, such as spawning position of enemies or something. As for what feeds 0x005A, it looks to be a sum of controller data and timers, plus an extra 14. The carry bit is always added in every time, with a constant added in the end, so the effective period of 0x005A is 255, not 256. Can't get 255 with carry set, and can't get 0 with carry clear, so with the constant added, we'll never get a result of 13 sitting in 0x005A. Controller data includes what's being held at the moment and whether or not you just now pressed it and not have done so before this frame. Updates to the controller addresses are, of course, skipped during lag frames. The game intentionally inserts a lag frame following every normal frame for speed consistency, so half the frames come up lag according to FCEUX. Even so, every frame, both normal and lag, uses the controller data for RNG purposes, and since I only have control every other frame, this slightly reduces my RNG-controlling abilities. As for other addresses of note, 0x005D is a two-byte little-endian frame timer that resets to zero whenever a new area is loaded. 0x005F looks to be always zero so far. 0x0060 is a frame timer that simply runs from 0 to 7 then resets to zero. All these timers run every frame, both normal and lag. It looks like most of these have a variety of purposes to the game in some fashion. I'll have to figure out the timer, since I've spotted in one spawning routine, that it looks for a very particular time before letting it spawn. In any case, with P2, I should be able to control the RNG very nicely, as it's simply added in along with all the other stuff, giving access to a wide range of possible values for address 0x005A. Other, less-RNG-related things that come to mind: The X and Y axis of your ship's speed are limited independent of one another. In other words, it's a rectangular restriction rather than a circular one. You can max out your speed (3.0 pixels/frame) in one axis before dealing with the other axis, and this will not slow you down one bit. This is the reason why I point exactly to the right at the start of planet 7 for a bit before facing straight up to maintain height. While your thrusters and the gravity are limited in how fast you can move, the game forgets to apply this limitation when a tethered object drags you along. This means your X-speed can exceed 3.0 pixels/frame for an extended period as long as you do not thrust with any force to the left or right. You can thrust straight up or straight down without losing the boosted speed. Motion downward or upward often has gravity often getting in the way, so except for tiny fractions of 1/256, a boosted Y-speed isn't happening when gravity is affecting you. In other news, I haven't yet put the effort into bypassing that big enemy. So it's still a wall to me. But I have been spending time optimizing the route through the start of planet 7, and get myself walled by that same enemy several frames earlier as well as picking up a little extra cash from shooting stuff. So at least I'm richer by the time I get stuck.

Posted: 7/23/2013 2:00 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

I've been taking a look at the RNG of this game. Nothing major, yet, but I have a few suspicious addresses: 005A - Apparently incremented by controller stuff 005B - "Upper half" of the RNG(?). Bits are left-shifted once per frame 005C - "Lower half" of the RNG(?). Bits left-shifted out of this are shifted into 005B The RNG controls a variety of enemy actions and spawning. Of which, I have not analyzed. So I have very little to give here. However, button presses do affect the RNG. The game is directly reading from the controller to change the RNG in some fashion. As if this wasn't enough, it'll also read from player 2, who serves no other purpose whatsoever. In short, I have a full manipulation controller independent of all activities with the game, should I choose to use P2. I suppose it's time we figure out how to spawn enemies like crazy... As for that barrier at the enemy I'm stopped by, my plans involve spawning seemingly-infinite enemies to see if it stops the barrier. As my prior attempts, slipping through cracks both through the left and the right, have ended in failure, I'm hoping that spawn-crazy gets around the problem. But first, the RNG needs further analysis before that happens.

Posted: 7/22/2013 12:58 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

Well, maybe not all that terrible a percentage in loading, but I know someone who was bothered by it. Regardless, it's just a request. I'll appreciate it if someone does go through with it, but I can understand if there isn't a large need for an alternative that skips the loading.

Posted: 7/22/2013 12:40 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

Oh, hey! Thanks for the encode! Will watch the run. Though, I'll request an encode that skips loading screens. The main part of the TAS is in the gameplay itself, not the wait of loading. I'm pretty sure viewers won't mind an alternative encode where it goes to the next level much faster. Like, say... Just a few frames of black. There's a lot of downtime between levels. Skipping this downtime wouldn't take away from the viewing of this nice run. Unless you can somehow convince everyone that watching the loading screens are necessary to the flow of the game and allows the viewer time to contemplate things like "what did I just watch" and "the answer to life, the universe, everything", I'm pretty sure that having an alternative video with the loading screens edited out will go appreciated. Still, thanks for this encode now. Wonder if there's a convenient memory address to read that would suggest loading screens to make it easier to skip them all automatically. Now I'm curious what percent of the video involves loading.

Posted: 7/21/2013 9:42 PM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

http://tasvideos.org/userfiles/info/8080525146486850 Warps route. I've distracted myself on this game again. I've managed to improve on my own warp by a few more frames, which is on display in the movie. What's also on display is my trouble at that first big enemy after picking up the first fuel cell. I can't seem to slip past it without the enemy's destruction. Makes me wonder if I'm doing something wrong or if it's region specific. Maybe I should hunt down the (E) version and see if it's easier there. In any case, for planet 1, Preludon, I figured out that ricocheting off that wall is slightly faster than my earlier direct approach. In fact, it was too fast horizontally -- I needed to avoid thrusting to full speed after the ricochet in order to begin thrusting upward sooner. The warp was reached pretty quickly, I believe. As for other tricks, apparently there's a spot near the top of the level in the sky where gravity changes. I sit in a spot where it's minimal to save on fuel, though most likely trivial amounts. Rapidly disconnecting and reconnecting the tether to the fuel cell (rapid-fire down) causes its weight to be ignored completely, as well as pulling the object closer to your ship. Understandably, thrust works better when weight isn't being noticed by the game. The pull has limits on how fast you can go, but you've likely built up the momentum to tether the object normally without being so sluggish. I still have no clue how to get past that enemy without shooting it, though.

Posted: 7/20/2013 10:10 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

I just realized my editor capabilities. Something I had for years, in fact. So, I just did the edit myself. Hopefully this fits better.

Posted: 7/20/2013 9:54 AM

Quote

FatRatKnight

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

Joined: 9/27/2008
Posts: 1085

Movie description needs to be updated, rather than a copy/paste of the obsoleted. This movie, in fact, does not win money in a limits casino by rolling dice, but rather a generously given ticket. Also, I have only one complaint about the run itself: It does not use an exclamation point for the final message. Other than that, short, sweet run showing what intense luck can bring in minutes, and a good improvement over the prior run. Not much else for me to say.