Posts for FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
So, my TAS was obsoleted. I'd complain about losing (or hiding, rather) a notably differing content, but then that TAS was poorly rated. Since the Vault doesn't have room for a diverse set of runs, and the notably differing content isn't all that entertaining to begin with, the conclusion is fine for the site. Regardless, I did a ctrl+F for "region" under the Vault rules and got nothing. Requesting clarification in that page for same game ported to different regions. They are, technically speaking, different programs, even if there are differences in some implementation, even if that leads to a significantly different route. On that thought, should my obsoleted TAS get demoted to Vault? By no means was there any intention other than fastest time through known methods in that run.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
So, the contents of this any% is identical to the 100% run, except the movie is cut short to display credits. I expect a discussion of site rules. I have a preference for runs of differing content.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
That's a fast cursor! Now we're good. It's great to see that you went straight to work on getting an improvement ready, and came out with this. I don't have any doubts about the quality of this TAS now, apart from entering the final boss's floor with a frame or two of delay and seeing if it gives a different teleporter RNG. At least there it would only change the end of the run, and it isn't even certain the game will throw a better pattern. If you want to investigate that, don't cancel this submission, not until it's beyond doubt. Of note, I didn't do any of that testing in my run. so that suggestion is actually beyond what I did myself back then. I'm just now only thinking about it as a possibility. I am curious as to whether this would obsolete my TAS. Both the same game, albeit different regions, and both are any% in their respective regions. And my TAS has a rather shaky rating at the moment.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Staff here can replace submissions with a new file directly. You could cancel and resubmit as well, if you want to go that route, or just ask them to delay judgement here until you get that new file ready and available for them. Since you've already posted about this likely improvement, and that you are most likely working on it now, they're probably going to wait some time for the results anyway. It's nice to see you looking over your run for further improvements. Apparently my memory did miss a few details on cursor movement, but was enough intact to still reveal a few frames there. I also wonder about the RNG for the final battle. Getting there sooner will probably mean a different pattern of those teleporters or something.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
In case it is needed... [2833] SNES Brandish by FatRatKnight in 38:42.41 Somehow, my run is Moons. Okay. If it's determined to fall into the Vault from its rating, then I don't see any way for it to fit alongside this run, given the tight rules that Vault fits in. Even though the two regions give a vastly different experience (due to a presence of a glitch), if it's the same game ported across different regions, then they count as the same game. I don't know what counts as 100%, but I can say I certainly aimed for any% in my USA run, confirmed in this submission text as the fastest known strategy there. Watching this, I pretty much understood what was happening, probably because knowledge from TASing that run made it much easier for me on this one. A few details in execution comes to mind. I recall whenever I was using Warp Magic that the fastest cursor movement for getting to a corner quickly was something like: Right+Up Right Right+Up Up Right+Up ... And so on Watching the video, although not carefully confirming it in emulator, I didn't spot this pattern. Mind, my recollection isn't perfect, either. I also recall occasionally getting two hits against the final boss in between some of the steps. Curious why two swings were never made between any of the steps. Outside of those details, nothing else strikes me as odd. Appears to be decent execution.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Huh, so 5 min doesn't allow you to instantly trigger waves. Okay. You made a full demonstration rather than describing it in text. You definitely put in effort. In general, input ends when it's enough to reach credits or some sort of ending. It would feel less of a closure if it only sits at a level completion screen. The "ending" isn't triggered by gameplay, right? If the credits can be selected from the menu, have that be the last action. If there really isn't any sort of closure you can select, then the best would be that level completion screen, I suppose. Even a submission isn't precisely set in stone. If it turns out the opinions of the board strongly suggest that you should have done something else to end the run, you can make some change, upload it somewhere, and have a judge replace it. The most questionable mode is that 5 min one, so if you leave that for last, you'll have the least amount of trouble changing it later, as then you wouldn't have to worry about syncing later modes. In any case, take what I say as mere suggestions, tempered by my opinions, not what the site as a whole expects. I like what I've seen so far, so more of whatever that is, keep it up.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
After taking some time to sit on the thoughts for a day, I'm now making a post. The run's objectives: * Clear 48 tracks * All 1st * All items On the first objective, it has been determined that the game has no further content, in both the field and difficulty, after track 48. Well, the field already begins repeating at 24, but the situation is different, in that the difficulty is cranked up a ways, providing a challenge unseen in the prior tracks. Furthermore, the appearance of the trophies would also suggest this, as the 49th trophy outright replaces the 25th trophy should the run have continued. As the TASVideos standard of endless games is to pick a stopping point where beyond it would simply revisit old content, this would be a natural point to expect of a run that completes a game, and therefore has no need for an explicit branch. So, no need to mention 48 tracks. As for all first place, that is some kind of maximum. It is clearly visible as well, as the trophy screen fills with gold trophy after gold trophy. All first places is simply a means to which the effect is gold trophies, and in lieu of a run which uses scoring techniques to improve score, "maximum score" is more appropriate than "maximize scoring actions." As well, there is strong and reasonable evidence that not going after all gold trophies is faster for an any% oriented goal, by the fact races end the instant *anyone* hits the finish line, and the yellow car can be triggered to dash at 127 MPH fairly regularly. So, "all gold trophies" sounds more appropriate than "all 1st." And definitely not leave it blank, as any% would certainly be different than what's here. Finally, the goal which was determined not to be "critical." Picking up all items generally should be obvious enough, although apparently we still got a post questioning why I'm getting items. Aside from score and ammo, after the player car is completely maxed out, items have no lasting impact beyond the tracks they are found in. While I was aiming for a 100% style goal, I apparently overshot and did what many would argue is "too much." Such a goal, then, would be outside of the Vault criteria and make the run unacceptable to that tier, as there isn't anything such items are maximizing, aside from player car status, which hit its maximum before track 24. As it's not a Vault-eligible goal, it can be viewed as a lesser goal to all gold trophies. The fact remains, however, that this TAS explicitly goes for all items, and will differ from one that doesn't. Aside from time wasting animation of the letter pick-ups after the first two sets, the projected time difference of this goal is actually minimal. For what it's worth, eschewing pick-ups would mean some more levels end up identical to a theoretical any%, although it's not like two standards must maximize differences between each other. I'm on the fence about omitting "all items," but it's definitely a smaller impact than "all gold trophies." On a side note, any% would have a pretty good excuse for play-arounds waiting for yellow "mad-dash" car to finish already, while all gold trophies is limited to clearing those races quickly.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
If this is how you're going to introduce yourself, you've done it right. I have passing familiarity with tower defense games, and this definitely looks like ridiculous precision far beyond anything I could humanly do. Lovely, it is. Please, keep going. There will likely be joy when you finally submit a finished TAS. If it's "practically impossible to make a TAS that's fully optimized," then that gives a lot of room to show just what can be done. I don't know this game in particular, but about that "5 min" mode... how would it look if it was taken normally? Well, by "normally", I mean TASing through it without the glitch, trying to maximize score or something. And, uh... with the glitch, and input ends early, will it look at all interesting?
Post subject: Added: Frame data of each track.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
GJTASer2018 wrote:
Not to mention in this game aggressively attacking the computer opponents is a quick way to make it impossible, even with tool assistance, to get first place in a race at all - the yellow car can speed up to several times your car's possible max speed!
I've never seen anything exceed 127 MPH, however. Yes, early on, this would be a quick way to switch on the super nasty mode of the yellow car, but early in the second loop, all CPU cars hit their 127 MPH cap and stay there all the way to track 48. They get "tamed" again at 49, resetting back to the level 25 difficulty. Regardless, sounds like it's worth a test to be certain. After all, in this run, I let a CPU ram my back as a way to get some kind of boost on a few tracks in the second loop.
GJTASer2018 wrote:
FatRatKnight wrote:
[...] Releasing the accelerator while on a speed arrow tweaks with the sub-speed values, [...]
Do you think there is a significant time/frame loss from not utilizing the trick over the course of the whole run?
Nothing major. We're tweaking with sub-speed values where the MPH will drop rather sharply once we're off the arrow. At best, we'd keep an 8 MPH threshold for another frame or two, and there are a few thresholds on the way back to normal speed. Starting at 72 MPH top speed, we would need 9 threshold-frames worth of savings for a real frame. With a higher top speed, we'd need more threshold-frames as we simply travel a greater distance each frame naturally, but at the same time, we also lose less speed from 127 MPH each frame. I would guess an average of 0.9 frames are lost for every arrow I didn't do this trick on. Basically, I don't even know if it would save a frame for every instance there's an arrow. But once I was aware, there wasn't really any reason to skip this minor trick. EDIT: Found my script. Well, more up to date than this one. EDIT2: Ran script for frame data:
Track 01: 1292    Track 25:  924
Track 02: 1215    Track 26:  899
Track 03: 1615    Track 27: 1275
Track 04: 1338    Track 28: 1115
Track 05: 2004    Track 29: 1584
Track 06: 2401    Track 30: 2062
Track 07: 2411    Track 31: 2023
Track 08: 4461    Track 32: 3700
Track 09: 1904    Track 33: 1624
Track 10: 1107    Track 34:  892
Track 11: 1335    Track 35: 1198
Track 12: 3174    Track 36: 2859
Track 13: 2601    Track 37: 2259
Track 14: 1607    Track 38: 1436
Track 15: 2283    Track 39: 2095
Track 16: 4034    Track 40: 3747
Track 17: 1844    Track 41: 1668
Track 18: 1022    Track 42:  947
Track 19: 3089    Track 43: 2949
Track 20: 1415    Track 44: 1365
Track 21: 2758    Track 45: 2708
Track 22: 2760    Track 46: 2758
Track 23: 1268    Track 47: 1258
Track 24: 8321    Track 48: 8272
Of note, Track 48 has its input end early. If I hadn't, the number would be 8238. It should also be interesting to note that both 24 and 48 involved a completely maxed out car, yet the times are notably improved the second time around. It's that CPU push player effect.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
dave_dfwm wrote:
why did you not use your bombs on level 48 to blow up the cars when they got behind you?
It's faster not to bomb them. Actually, because of just how blazingly fast they are, it's obvious they can pass me. I drive in their way as this actually pushes me forward. Bombing them means they're not around to push me. Of note, getting in their way in realtime is nearly impossible. The game actually pushes your center away from the rival's center with the most direct line possible. This in itself has negative stability. Furthermore, CPUs will try to drive side to side to avoid ramming the player in this fashion, so even if a magic spot is found, the rival will invalidate that magic spot in a few frames. I also recalled another trick I did later in the TAS I didn't take advantage of earlier. Releasing the accelerator while on a speed arrow tweaks with the sub-speed values, so when I realized its potential, from then on, I tried to maximize the sub-speed as I leave each speed arrow.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
c-square wrote:
When you left an item behind, did you have to drive around the whole track to find out if an opponent had taken it?
The only items I'm aware of they can take are the roll cages / shields / color-flashy-make-others-spin-out-on-contact-power. Everything else looks to be player exclusive. I generally listen to the game sounds to detect whether a rival took something. Even if not that, I also wait long enough to see if the CPU is flashing different colors, which definitely tells me one of them picked up a roll cage. Again, I never worried about them taking any other item, and I never observed those items missing on my next lap.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I seem to recall finding some option to change how many pixels vertically to display in FCEUX. Not as though this would solve the underlying issue, but it might let us display the lower part with an unusual resolution. For that matter, the upper eight pixels we normally don't see are apparently also used by this game. As for why I pick up everything: This is an all items TAS. I pick up all items. That is part of the specified goals.
Post subject: Oh, right. The pass time step.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Okay, plan of attack: * Start game in any difficulty, it shouldn't matter too much (although Hard would be tight on cash) * Build rows of power lines. We are writing a bootstrap code, with each tile representing one bit. * Build power plant, maybe two, to power these lines we just placed * Wait long enough for the game to calculate the power * Build Mass Transit (rails) tile on 0064 (206 tiles left of the normal top-left corner) * Build Roads on 0090 (184 tiles left of that same corner) * Spam-build over the timers at 012C (106 tiles left), 12E (105), and 12F (104) for great justice * Build Roads on 00AA * ACE achieved. Now press buttons several thousand times faster than normal humans. Well, I'm hoping this plan is simple and effective. It should, at least, give something concrete to try out as opposed to simply hand waving possible ideas around. About the spam-building for great justice step: There are a few two-byte timers we can corrupt and abuse to our liking. Whenever we build over one of these, we set the upper byte of one timer to one of three values (0x32, 0x62, or 0x72, depending on tool) and zero out the lower byte of another. The timers tick down every frame, so zeroing out the low byte will effectively decrement the upper byte. We can simply zero out the low byte multiple times to adjust the high byte as needed, and pick a different timing on when we zero out that low byte for the last time to line up the values of different timers. I took a look at moving the cursor off the top edge of the map. Judging from where it's corrupting stuff, it's probably just taking the effective Y position you would be building on, modulo 256. This would modify 7FF110 for going one tile up, and will never reach the 7E0000 region we want to modify. I'm thinking we're stuck with moving the cursor to the left a ways. As the width of the map is 120 tiles, and we are guaranteed to be able to have two functioning rows of power lines for purposes of ACE, we can get ourselves 30 easy bytes of bootstrap code in the power array. If it's necessary, we can probably get more bytes by adding more rows, but we start to lose precision control on how we set the individual bits as we need some continuous connection to every power line. The more 1 bits in your code, the less of a problem this would be, though. On the other hand, 30 bytes of bootstrapping with absolute control over every byte of this 30 really should be a dream compared to getting an ACE in something like Super Mario World. But once we hit ACE, what then? Fix the stack, and any critical memory we ruined along the way, then run the 600k population message routine? Well, that would seem like a really basic way to achieve the "ending". Use it as a shortcut to glitch our money? But then we're not actually using the full power to get to the "ending" as soon as possible. Something... Interesting? A bit outside what I'd do myself, but snap, it would be awesome if someone has ideas and can execute those. I, for one, would like to see someone bulldoze a tornado. Or the plane, it keeps crashing on nice buildings even on Easy. In any case, I feel as though I have 99% confirmation that ACE is possible. My method was basically running a debugger and doing direct memory edits on spots we should be able to corrupt as the Program Counter was getting close. To my knowledge, the spots I wrote over do not refresh so long as you don't enter any menus, and apparently don't have critical function for reads, apart from the final step of corrupting the stack. Finally, we have a LOT of room in the 7F bank. Well, a lot of it is dedicated to the 120x100 building area, but after that is the History stats and the various map stats. Since we should have ACE, we can simply prevent the game from ever recalculating what the stats should be, possibly by convincing it the calculation was already done.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Okay, I have a small plan now. It isn't much, but hopefully the setup gets the game executing stuff we want. 0064 - Place a Mass Transit tile here. Some of the graphics will likely get screwy. Just a sign things are working! Well, if we leave this alone, we get a long jump right back to before this spot, giving us an undesired loop we won't escape. Placing 000072 as our destination at least lets us jump ahead a little. We can also place something at 0062 instead for what is more likely a bigger graphical mess. 007C - Some kind of timer. Its speed is adjusted by whether you have buttons pressed. Might be helpful to keep in mind, although its range of possible values is limited. 0091 - If this stays 0x40, we may get an RTI, which could easily put a stop to our plans. It looks safe to corrupt, as it's related to menus, and unused in build mode, so placing roads on 0090 means we avoid this mess. 00A9,2x - One of the stack addresses. 00AB,2x - The other stack address. 00AA - Once we're ready to break the game, we place something here. Probably a Power Line or something. 00C7 - Looks "random". I hope it doesn't get us into trouble after carefully aligning the timers. 00D1 - A frame timer. Counts up to FF, then wraps back to 00 to start over again. I'm not sure if we can corrupt 00D2, but if it sticks, it shouldn't cause problems. An easy jump ahead by 0032 would get us past a few addresses, and make it easier to reach 012D, although whether the timer lines up nicely with what we're doing is another question. 012D - Frame timers are here! Well, there's one at 012B, but it's used for something else and will not have the values we need. However, 012D, 012F, and 0131 are each two-byte timers that tick down every frame. It should be pretty safe to corrupt them, then wait for the right instructions to turn up. A string of bytes like 5C 98 A5 7F would produce JMP $7FA598, right into our power map stat, which we have almost complete control over with normal gameplay. We might prefer an address a dozen or so bytes after, as we can control the power in the middle of the map better than the top edge only. 01BD - Our camera takes up the four bytes at this location. It's notably farther away than 012D, but it is the alternative thing to try to give ourselves the arbitrary jump we might like. I haven't analyzed the stuff between 012D and here, though, as I'm more attracted to the idea of making the timers work. These are the most interesting notes that come to mind at the moment. The more I look at this RAM, the more optimistic I feel that ACE is possible. There's a lot of 00 bytes, which are safe thanks to the BRK instruction giving us an RTI bouncing us back to where we were. And yet, through all this, I haven't actually asked about the exact process of moving the cursor and camera to allow for overwriting these addresses. Probably just as simple as going off the top edge or left edge and placing something in that black gunk, but I figure I should ask anyway. Exactly where does the cursor end up relative to the top-left corner of the map for this sort of targeted corruption?
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Okay, I am equipped with knowledge of opcodes! Been studying the RAM a touch. It helps that, if the game encounters a BRK, we get an immediate RTI, so execution continues from where it left off.
0000 * 0002: Unused in build mode?
0003 - 0007: Sound related. Zeroes out every frame.
0008 * 0011: Not used during build mode. Part of it apparently used for menus.
0012       : Used for something. It won't get in our way, at least.
0013 * 003F: Not used during build mode. No reads, no writes. Anything in the way can just be corrupted right out. Something in there is used for menus, though.
0040 - 0041: Apparently tested for specific IDs. Normally zero.
0042 * 0055: More unused stuff in gameplay.
0056 - 0057: Tested for something. Not sure.
0058 * 005E: Looks unused.
005F - 0072: Most of the stuff here is transferred to 0x002100 region. Not precisely sure how the game would look when this is corrupted. It helps that no matter how badly we ruin this, it won't stop us from further corruptions.
... Still more to look over. I just want to get this bit of information out and relax from trying to analyze what's here, for a time. Whatever the exact details may be, 007C looks like a small timer, 00D1 looks like a single byte incrementing frame timer, and the thing we really want to reach is 01BD as that's where our camera position is, something we might have full control over.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I took a moment to study the stack for a bit. Unfortunately, I'm terrible at locating online sources, but I did some experiments with a debugger in hopes that is good enough to work from. The stack works at bank 00. From what I understand: 0x0000 - 0x1FFF shares the same bytes as bank 7E (same physical memory) 0x2000 - 0x7FFF looks to be mostly open bus, so we won't see whatever shows up at 0x7E3200 0x8000 - 0xFFFF hooks into some stuff in ROM (I think) So, we corrupt the stack with our off-map building, and we throw the stack pointer to 0x3200, 0x6200, and 0x7200. This is in the open bus, as there isn't much there at bank 00. After a short disassembly, the game calls a function and it later returns using an RTS. Since the stack pointer isn't pointing at any sensible physical memory, the function call couldn't push a return address, so when it comes to the RTS, it'll go wherever the open bus says to go. I did some single-stepping with this debugger, and apparently it'll keep RTS-ing to the same spot in memory, executing code at 0x006061, and sit there popping return addresses off the stack still in open bus. So, the stack pointer is moving two at a time upward in hopes of getting out of this trap. There is something slightly interesting somewhere in 0x004000 the stack will reach from 0x003200 after enough returns, though I don't know how to analyze that. Part of it is probably the memory mapped multiplier and divider on the SNES structure. After that, it's basically open bus until 0x008000. The first two bytes there would mean the program jumps to 0x00FB18, which is stuff we can't modify, and we're probably stuck from there. On the other hand, we could break the stack by zeroing out the lower byte instead, setting the stack pointer to 0x1F00. The function call would be able to push its return address, the RTS would work, then it goes on to the rest of the code, which pops a bunch of values and does an RTI. Judging from the memory there, it looks like it would be mostly zeroes, so we'd jump to 0x000000, which maps to 0x7E0000, and we know some of the values there, and can even modify them directly with... Well, we're kind of limited with our tools to modify those, and it tends to break the game in ways. So far, I haven't come up with much. Lots of complicated stuff, and still more to look. I definitely wouldn't mind someone who knows more about SNES architecture to point me in the right direction.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I edited my last post in some finding involving the memory we're modifying. I was poking in the disassembly of the game to find out we're essentially messing up some pointer necessary for the game to function with your construction to 0x00AA or 0x00AC. I'm guessing you haven't been able to use any other map tool. None of the 3x3 or larger ones or the bulldozer, I take it?
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
If you remove enough of the water, you will reduce the Land Value in the area. It may well be possible to glitch up the Land Value for a few game months at a time to promote growth, then the game recalculates and you have to glitch it again. There is a 4x4 map stat the "pretty tiles" are based on, the presence of water, forests, parks, and especially gifts affects that. Glitching it would be affecting Land Value more quickly than the actual Land Value stat, as Land Value works in 2x2 tiles. Again, glitching it is temporary, as the game will recalculate eventually, but at least R-Zones and C-Zones will benefit for a time. R-Zones need some minimum Land Value (adjusted by demands) to avoid shrinking, while C-Zones will never shrink as long as they have maxed demand. So glitching Land Value will have some use in boosting up C-Zones in areas otherwise difficult to get anywhere near a TOP, then they can stay that way. R-Zones need that Land Value maintained somehow, although some areas will always have enough. So, the region you can affect is essentially: 0x7E0000 to 0x7E01FF 0x7F0200 to 0x7FFFFF That is news to me. I want to see if I can help develop a RAM map of the relevant area. For reference, Roads should write 0x0030, Mass Transit should write 0x0070, and Power Lines should write 0x0060 to whatever address you're messing up. The "freeze the game" ones seem interesting. Wonder what makes them important to the game... EDIT: Well, I've started on the RAM map. 7E00A9 and 7E00AB are stack pointers. Smashing them by building stuff over that location would certainly mess up the game. Hopefully I'm not mixing up the little/big endian values, but we can corrupt the stack pointer to 0x3000, 0x6000, or 0x7000, or around that area. What this implies, I'm not certain. The game does make a function call shortly, and I'm not exactly certain what regions the stack shouldn't be in for anything resembling sanity. In any case, it's probably worth poking around this area of memory for other useful sanity-breaking logic around here.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
The real effect on population are the building center tiles. The population density map stat is simply a stat on the map. Actually, it is possible to have crime going on in places with absolutely zero population in the map. It's also possible to have pollution, police coverage, fire coverage, and land value with not a single person around. Population Density is a map stat that is occasionally recalculated based on existing zone centers. Its effects include allowing R-Zones to expand past the small housing stage, and to increase crime in the area. If Population Density has an impact on your population count, then placing a zone at the corner of the map would offer less population than one placed closer to the center, simply because some of the density was "diffused" off the map and no longer accounted for. Actually, most of the map stats don't actually have direct impact on the population: - Pop. Density allows R-Zones to grow beyond small housing, and ups crime - Police Coverage reduces crime - Crime has no effect, except on complaints and, at a specific threshold, reduce Land Value by 20 - Traffic changes Roads tiles to light or heavy traffic versions, but itself doesn't affect any other stat aside from complaints. The transformed tiles do pollute, however - Pollution drops Land Value one-for-one - Land Value affects crime, tax income, and growths of C- and R-Zones - Complaints have zero effect on gameplay, other than pass/fail of scenarios R-Zones, C-Zones, and I-Zones, their very existence, affects population whenever the game needs to recalculate it. Actually, it's the center tile of each of these zones that matter, but basically the zones need to grow somehow. I don't quite have things set up on my end for testing quickly. I'm thinking I should try a few things myself soon, so I can get a more direct feel for what's going on.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I have been contacted by ThunderAxe31 for my own thoughts on the branch naming. Over on IRC, this is the conclusion I feel we left with: Published movie: Change branch from blank to "map glitch" (or, more generically, "warp glitch", although I prefer the more specific branch) This submission: Set branch as "no phone numbers" For the "glitched/unglitched" branching, it's my impression we generally name the glitched one if it basically defies the structure of the game, and name the unglitched one if the glitches involved leave the game somewhat intact. Of our Final Fantasy TASes, the fastest one is marked with "stairs glitch", while the usual any% run that forgoes this glitch has no branch name. Among the Zelda II TASes, we've named the faster glitched branch and the slower unwarped branch, and the middle "any%" is the one left blank. So it's clear to me that the run with the map glitch should be called out as such. As the phone numbers, while they do break the game challenge, do not break the game's basic structure, are much, much smaller than the effects of the map glitch, so leaving the name as "map glitch" (or something indicative of a major glitch) would be suggested. As for phone numbers, that's actually a bit fuzzier. In a sense, the game comes with its own password system to give yourself some sort of advantage. Using it does give a large enough advantage to essentially defeat all challenge in the game, but unlike a password system intended to restore progress within a game, that by itself doesn't drop the player at the endgame. It's more akin to trading in some powerful trained up Pokémon to a fresh game and crushing its challenges (and exactly that does happen a bit into this TAS, although part of the time was training up such a fighter). When in doubt, refer to whatever speedrunning community the game has. Unfortunately, I'm not aware of much of one. When still in doubt, more description is better than less, and saying "no phone numbers" may help to inform the viewer there is a mechanic in the game that can give the runner a sizeable advantage that we avoid. If there are plenty of speedrunners who would think avoiding phone numbers should be standard, then a blank branch is appropriate, but with an absence of such, I would err toward including the "no phone numbers" conduct as a branch name. In any case, I am firmly of the opinion that we should name the published glitched TAS, perhaps "map glitch" or something like that, and originally was leaning slightly to leaving this submission blank. I have been swayed to thinking "no phone numbers" is the appropriate branch name for this one, although I still don't feel firmly about it. This post is my take on the results of our IRC discussion.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Meerkov wrote:
However, I'm currently not investigating this because I'm really curious about building in the black area. By going out of bounds, you can start writing to certain areas of memory that you're not supposed to. For example, it was remarked in this thread that you can write between 0x0000 and 0x0200. But surprisingly, no one seems to have pointed out that this means you can actually overwrite the camera/cursor location.
Hold it. The map data is in the 7F bank. Most of the pertinent stats are in the 7E bank. Doing the off-screen mess can't actually mess up anything in the 7E bank to my knowledge, so you're only corrupting something in the 0x0000-0x01FF range of the 7F bank, where the camera and other stuff at the 0x0000-0x01FF range is in the 7E bank. It is possible to scroll upward. Theoretically, this would get you faster access to stuff before 0x7F0200, as one tile up should count as 120 tiles to the left. But again, I don't recall success corrupting cash on hand somewhere in the 0x7Exxxx location. So, we would be able to hit 0x7F0000, but then probably wrap to 0x7FFFFF and not actually get to 0x7EFFFF. I agree the black should be explored more. Locking the game with your experiments suggest it may be worth looking at the 0x7F0000-0x7F01FF block. If Arbitrary Code Execution is possible, that would be the most likely spot. We definitely need more information, and even my statements about the 7E / 7F banks could be tested (I'm writing based on rather old memories at this point). My old scripts do have a good amount of the RAM map of the 7F bank. I don't recall exploring the 7E bank much, though. The 0x0BD0 location in the 7F bank is just some tile on the map.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Bobo the King wrote:
((Final Fantasy Legend stuff))
One more detail to add. I remember, rather distinctly, on the actual GBC hardware, if I mess around with the D-pad during the logo startup, changing the color scheme, the delay this causes also gave a different starting RNG. The color scheme change is a legitimate feature of the GBC pertaining to older GB games that don't use more advanced functions, and may potentially be an RNG manipulation tool, as in the case of Final Fantasy Legend. In any case, if there's no way for the divider to "wander" relative to CPU instructions, even by changing platforms, we won't get access to other offsets in our important RNG addresses. Our soft resets in our earlier TASing attempts are basically just giving a different "start up timing" to get access to RNG values we want, and we've studied soft resets a lot. If the only thing another platform gives is a different start up timing, it's not giving us access to new RNG values we can't already get by soft reset. If it did get us new RNGs, then we'd have a case where there was no intended feature exclusive to one platform, but by some "accident" of RNG, some random elements, particularly strong ones (we're talking usable instant-death against bosses), are flat-out unavailable on one platform but are accessible in another. But based on what I'm reading, and off of my own memories, Final Fantasy Legend isn't going to crack open our stone gaze any time soon, whatever hardware we use. Still, we have an RNG manipulation case based on changing platforms. After all, a different start-up timing could seed the RNG differently. Is this case to be disregarded as not important enough to allow a submitted run on an undesired platform if the reason provided is RNG? As for the proposed rule set, my short-hand interpretation of the proposal: * GB game - GB mode only * SGB game - GB or SGB * GBC game - GBC mode only With exceptions based on features provided by the individual game, should a run use such features. Mostly, just trying to clarify things. Is my interpretation fine?
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Add me to the list of those who do not wish for their work to be republished to YouTube. TASVideosChannel is already a plenty good spot. Asking here in this topic specifically for anyone to respond whether they want to restrict republishing, in an "assume it's okay except if the person opts out" will have you catch an awful lot of works where the persons were either no longer here on this site or simply weren't even aware this topic existed. I would much, much prefer "assume it's a bad idea except if the person opts in" instead, as then you are guaranteed that all works you do republish are not unwanted, as each person has, indeed, opted in, before you did your thing. There are probably plenty out there who just republishes without saying a word here. Thanks for making a post here with your intent, although beyond supporting communication and discouraging the intent here, I do not have much further to say here.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Is it just me, or was Bond trying very hard to avoid OoB-ing straight through his own seat as he was driving around? I have a mental image of him, after sinking through walls and floors everywhere else, of falling through the vehicles he's sitting in. It has proven to be a fun watch.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Terse definition of "Demo Glitch": Letting the game's demo run, then using it's unintended controls or side-effects to skip ahead or gain other advantages. That should capture the intended meaning in a single sentence. I'm all for a standardized branch name for this sort, or at least a tag.