Wait, if you are going to have more than enough parks, would it be faster to put it on a harder mode so you run out of money faster so you get the $999999 faster? I'm pretty sure it wouldn't, but that could still be something to consider...
runs out of money faster,increases population slower though.Considering the objective is the population,it should be better to hurry the ends than the means.
I want all good TAS inside TASvideos, it's my motto.
TAS i'm interested:
Megaman series, specially the RPGs! Where is the mmbn1 all chips TAS we deserve? Where is the Command Mission TAS?
i'm slowly moving away from TASing fighting games for speed, maybe it's time to start finding some entertainment value in TASing.
Ok, first of all, yes I know. And yes, really.
This is in fact a request I was asked to do, long story short, I pick MisterK pattern and improve it TAS-wise. The goal is to create the most perfect pattern and let the game roll until you get 500.00 population (which is the last stage your city can improve to, Megalopolis).
I suggest you watch SDA run, or MisterK speedrun from SGDQ 2012, to get the idea of what you're supposed to do. My first problem is that you HAVE to wait a whole year for the money glitch, and I get bankrupted within a month (which you have to be in order to get the money glitch). If anyone has any idea of what I could do while waiting for the tax window to pop up, I'll be very interested (and yes I'm considering drawing dicks with the cursor if that doesn't slow down the timer).
The whole pattern is the have an outer circle of industrial zones, a middle-circle of commercial and police departments zones, and an inner circle of residential zones. Fill holes with stadium, airport, fire department and nuclear plants.
Map# is 61, which gives the least water tiles.
My first goal is to at least get something done (not aiming for a whole pattern optimization first, but just shenanigans), even if it's not submittable (because obvious optimizations, etc). I'll post my WIP today if some people are interested.
Woaw, I actually looked for it and didn't see it, I'm sorry folks. Going to read it whole...
EDIT: Ok I got the good pattern (well, most of it), I wasn't even aware there was something at 600.000 population. So that's what we're aiming at now.
I think I'll try to do standard "speedrun", aiming for optimized zones to get the best pattern (or most of it, shenaningans). I'll post WIP for those interested.
And I'm looking forward for your run FatRatKnight, looks awesome.
Building stuff off the screen is effectively memory corruption. How far into RAM can you go with that glitch? I think it'd be nice to make a video that directly hacks the population counter by writing to the top left of the map.
Quite hilarious would be building 65816 assembly code out of your city design then glitching the game into jumping to it.
I don't actually know the limits of the off-map glitching. But I don't think it is possible to corrupt the stack into having the game jump into an area of memory where you have your city in.
Regardless, here are the mechanics I am aware of:
- You can only place Roads, Power Lines, or Mass Transit in the black gunk.
- Such tiles are in the East-West version, regardless of adjacent tiles.
- East-West Roads are value 0x32, East-West Power Lines are 0x62, East-West Mass Transit are 0x72
The spot in memory where the city begins is at address 0x7F0200. Each tile is a two-byte value somewhere in the range of 0x0000 to 0x03FF. Some of the upper bits are used, but the purpose is currently unknown.
If you want greater control, there is a map stat that is tracked by individual bits. Starting at address 0x7FA598 is a bit-array containing which tiles are currently powered. Although in order for the power to go from one tile to another, you need connecting Power Lines or buildings. You can instead substitute power plant centers if the break in Power Lines is that important. Even so, you don't have absolute perfect control, but it should be enough to produce a nice function, especially with 1500 bytes to do so with. You also need the money somehow for multiple power plants.
That leaves breaking the stack, or other pointers to jump into our creation. I can't confirm this as possible. since I have made one attempt earlier in glitching my money but failing to do so. There's probably a two-byte boundary that our lovely off-map glitch can't get past, so we're probably stuck somewhere in 0x7F0000 to 0x7FFFFF. This is a guess, though.
The only spots in that range I don't have in my RAM map are 0x7F0000 to 0x7F01FF, and 0x7FF8F4 to 0x7FFFFF. Everything else in there is definitely taken by map stats. There's still plenty of stuff to look at before 0x7F0000, but I'm not sure we can glitch that.
It's open to further research, that much is certain. But I'm not entirely hopeful.
All right, we finished a sort-of WIP (which took way waaaaay too long to make), thanks to Kilaye which helped (read: did 80% of the actual work) making it. It creates an almost-optimized city (we left two 9x9 I blocks out) with some weird choices, which still achieves the 600.000 objective.
It was made on BizHawk 1.1.1b (because that was the version that was available when I started making this... like 8 monthes ago?) there: http://rayas.shinra.fr/SimCity_final2.bkm
We don't think we'll improve it, and we don't think it's polished enough for TASvideos (played on Easy, we add two rails section in order to spend the money faster because why not, we put at least 2 useless electric pole). Movie ends as soon as the last I section is put in place because you don't need any input to get through taxes and goals menus, they just disappear after some time. Yet, it achieves the goal at around frame 210000.
It's way less ambitious than what FatRatKnight envisioned, still, it manages to get the city done. This game is horrendous to TAS, it was a nightmare. Glad it's done.
This has been a great reminder that, yep, this one exists. Also gave a great idea to actually say some things I know, as things unsaid won't be useful. ... I left them unsaid for this long. Whoops.
I realized a faster way to do the money trick. No, I can't skip the in-game year, but I can avoid the extra trip to the taxes screen and not need to set maintenance back to 100%. You still need some maintenance to pay. Don't use up all your money. In fact, leave enough to pay for all expenses. Once the taxes screen shows up automatically, hold either L or R as normal for the trick (to freeze time) and back out. Now spend the rest of your cash. Then release your buttons.
Using the in-game pause will help to reduce in-game months, as this gives the game permission to handle the various map statistics (such as the essential power) without forcing it to handle a week passing and the city growth from that in between the various stats. It's one discovery that reduces the damage done whenever you load a game. Yes, we'd go faster by slowing down the game.
I took a look at the TAS you went and posted. It's the simple layout, isn't it? Not as grand as my plans, but my plans mean nothing if I never used them. While you were building the city, I spotted a few R-zones that weren't 100% satisfied with transportation. As a result, they are unstable and will sometimes shrink. Just that there is a line of rail that ends at some water doesn't also have a C-zone at said end.
Syncs fine on BizHawk 1.4.0, by the way. In-game time to 600k: 1904 JUN.
My goal, though, is to produce the fastest in-game time, most likely manipulating luck while the city is growing. Will probably prioritize speedy growth of R-zone small housing so as to get to the larger stages sooner. I'm questioning myself on whether to build Parks first for the theoretical "sticky" Land Value that might exist for a few weeks. Might be better to get to work on a small city first. Though zone development may interfere with glitching away tiles on the southern border, as the population history stops being zero, and is what's "below" the south border.
The off-map glitch relies on empty tiles 2 tiles south and 16 tiles east (or 3 tiles south and 104 tiles west) of whatever tile you're replacing with a power line, road, or mass transit. History is zero on many things if you have no population, corresponding with empty tiles.
Yes, the game does work on weeks. Four weeks per month, really. Of course, you don't see the individual weeks.
Now... If I can just set aside the time to actually do my goal...
If it won't be submitted, I'd love to see an encode of Rayas & Kilaye's run made, polished or not it's fun to see this game get busted open.
FatRatKnight that sounds amazing, I'm really looking forward to seeing what you do with it.
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.
http://tasvideos.org/userfiles/info/8936028298677215
I said I would provide a few test movies somewhere, regardless of whether I'm co-authoring. This is one.
Some bits of menu stuff to think about. You go through more digits going up from 0 to 6 than you do going down. Though you do need to move the cursor more, the wait between digits is very significant.
Also, sometimes you can push B while also pressing in some direction. Might save a frame on occasion.
As for the game itself, lag happens likely because the game is trying to advance time. If you keep at least one button held at all times, no time will advance, and thus less lag. I have a button held during the fade-in so that the game doesn't have it take a long time due to also advancing time with the fade-in.
Note that while I'm moving the cursor around in the menu, I'm also fast-panning the camera. The menu cursor will move for a few frames at a time, which won't be interrupted by the fast-pan.
Then the rail building. There's a reason why down-building is a different pattern from up-building. When moving the cursor, the game thinks it's immediately in a new position when going upward, but takes a few frames when going downward. Therefore, a different pattern is used when I'm trying to move the cursor while building.
I suspect the down-build can be done slightly faster, however. I just wanted a quick test out. Nevermind that the rerecords I put into it is over half of the submission's count.
Joined: 12/8/2012
Posts: 706
Location: Missouri, USA
Any progress on this one?
"But as it is written, Eye hath not seen, nor ear heard, neither have entered into the heart of man, the things which God hath prepared for them that love him." - 1 Corinthians 2:9
Was it ever settled if a Vault run for this game should aim for "early last input" (leaving the game to complete itself a magnitude of frames later, as Arnold0 did in his submission), or "fastest real time to ending screen"?
Was it ever settled if a Vault run for this game should aim for "early last input" (leaving the game to complete itself a magnitude of frames later, as Arnold0 did in his submission), or "fastest real time to ending screen"?
As far as I can tell, the tasvideos documentation does not make a statement on whether 'end input as soon as possible' or 'bring about the ending state as soon as possible' is preferred, so do whichever you think makes a more interesting TAS.
EDIT: But Spikestuff notes that a 'shortest input' TAS was going to be accepted to tasvideos, but it was cancelled due to known inputs. So that is a safe bet if you want to get a TAS on the site.
I was looking at this run, and there's a lot to be improved. For starters: all the building can be sped up to ~14 frames per 5 tiles of railroad. That is instead of the 15 frames used now. That's a 6.6% speedup on the rail section. It uses a combination of Fast panning (Y+dir) and slow panning (dir). That's pretty good just to start with and will shave a few seconds.
But it also has the benefit of moving the cursor closer to the edge of the map at no frame cost. This means that the un-submitted TAS can be improved because you don't need to backtrack to cover the bottom of the map, you can get it in the first pass. That'll save at least another couple seconds because you'll have to pan over the map at least 1 less time.
If I'm remembering right, that run was around 6 minute 42 seconds. I think with better camera/movement optimizations you could get the time close to 6 minutes. That's a nice start, of course. It's really annoying because it's a lot of very precise button presses. Probably you'd want to write a script to produce the right button press sequence just so you don't go crazy.
And of course, there is that obnoxiously slow 1st year to trigger the money glitch.
Another thing is the use of Map 61. Since it's a TAS, why not just use map 00? Surely with the money glitch, we hardly care about which map as long as it wins eventually right? That should save another few seconds of load time.
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.
It was also mentioned that the camera location is at 0x01BE.
But surprisingly, no one seems to have pointed out that this means you can actually overwrite the camera/cursor location.
The problem is, we actually want to overwrite 0x0BD0 (or somewhere near there). That's around where money/population seems to be stored. For instance, if we could give ourselves infinite money, even if we did absolutely nothing else using the black area, then we could avoid the entire first year of waiting around for the money glitch.
Can we scroll all the way left, and eventually get to 0x0BD0? Mmm I don't think so. However, I think that the out of bounds glitch has not been explored enough.
List of things I was able to do by writing to random spots between 0x0000 and 0x0200:
Reset back to title screen (music still plays, but accepts no input, Ram reinitialized).
Overwrite camera location (maybe useful for re-positioning it somewhere useful?)
Graphical glitches
Sound glitches
Lock game (permanent)
Lock game (until enough time has passed)
Lock game (as long as buttons are held + a few seconds)
Open the Build menu (when it was closed)
etc.
Probably a lot of those glitches are not very interesting, but resetting to the title screen was quite unusual. It almost makes me think that perhaps a jump *did* end up getting executed.
This seems like something that could be really cool (execute a city as code), but I'd be satisfied if there was a way to just scroll to the population or money counter to overwrite it.
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.
> where the camera and other stuff at the 0x0000-0x01FF range is in the 7E bank.
True, I don't have it right in front of me at the moment, but I can assure you by scrolling left on the first line, you can overwrite the camera.
This has the effect that you can use fast panning (Y+dir) without snapping back into the playable space, allowing you to quickly scroll through memory locations. That also has the effect that you can no longer snap back into the playable space, because normally the fast pan would have returned the cursor to the play area (some sort of bound checking on fast scrolling near the edge, which is broken when the camera is no longer "near the edge"). So it's kind of a double edged sword.
I'm thinking of a new trick: Ok, so all the stats are in various places in memory. You can certainly write into almost all of them (for sure anything above 0xA000).
Population Density is located at 0x7F8E28 - 0x7F99E0
So, if I understand correctly, it might be possible to write telephone wires into those memory addresses to increase the population of the city, right? It might get re-calculated at certain steps, of course, but this seems like a viable way to affect the population without figuring out the Arbitrary Code. I feel pretty confident about that, I'll try it later today (or soon, will update thread with findings).
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.
Ok I tested some more. I agree, changing the population density did not increase the population (I did not test whether you can build a R/C/I on top of the artificially increased pop density to get any benefit). That's maybe something to consider for a follow up test (build a bunch of R, then artificially raise the landvalue?).
One interesting thing is that using this, you can create land in the middle of water, which has a very high land value. It definitely does build in the info layers (you can view the info map and see random dots of green added wherever you built in memory). Regardless...
Things I found:
The formula appears to be:
offset = (CameraX+(CursorX/8))*0x02 + (CameraY+(CursorY/8))*0xF0) % 0x10000
memoryLocation = offset + 0x10200
So what's actually happening here is a rollover from 0x1FFFF to 0x00000. At least, that's what it looks like to me. (FatRatKnight is calling it bank x7E0000 and x7F0000, but I'm just calling it x00000 and x10000 because that's how it renders in BizHawk's hex viewer and I'm lazy).
However, when I was playing around with it, this did *not exactly* match up to what I was seeing.At one point I was offset by 0xE000 from where I thought I was writing, but still restricted to the same memory I could write before anyway. Regardless, it appears to be close enough to accurate for me. You can assume that you can't write beyond x001FF. It always jumps back up to x10200 if you go higher.
Ok, so what else did I find?
x0134 freezes the game
x00AA or 0x00AC will reset the game as soon as the player releases all buttons they are holding. The game will no longer accept input, but the music will play. It will never finish initializing the game.
x0006 plays a sound depending on the value written. It's mostly just annoying
x00D8 will freeze the game
For example, if the user holds LEFT when building on x134, the game will continue to run as if the player is holding LEFT, but it will no longer respond to pressing or releasing buttons. Doesn't reproduce if holding a different direction.
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.
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?
I tried various tools, it seems none of them will work except in the normal build area (approximately ~0x10200 to 0x16000).
However, I discovered something actually useful too.
Memory location 0x03200, as well as before and after it, all represent (drumroll please): the viewable map tiles! (Well, more or less, at least). It's not exactly a 1 to 1 mapping. For instance, it seems like it pre-loads some tiles outside of the viewable space.
"black" space is represented by "0103". (I forget the byte order) Grass/Forest/Water/Coast all have different value ("A506" is grass I think) etc etc. What does this mean?
It means a jump to 0x3200 or anywhere nearby should result in arbitrary code execution, based on what tiles are currently cached in the map rendering area of memory. It just so turns out that 0032 is the value we can write using Roads... So! If you're thinking what I'm thinking, then all we need is for the control to jump to 0x3200 and it's GG.
Step 1: Escape into the black area
Step 2: Overwrite the Camera X position to allow fast scrolling
Step 3: Fast scroll left, and down, viewing a render of the city
Step 4: Build the city/bytecode (To be determined exactly what)
Step 5: Use fast/slow scrolling to keep the city on the screen, but manipulate the exact "write" location as necessary)
Step 6: Write a road at 0xAA, to cause the stack to return control to 0x3200? (Unclear if this is right?)
Result: Win?
Edit: Actually I was wrong, I was looking at 0x13200. Jumping to 0x3200-0x8000 is a block of (mostly?) BRK(00) instructions. Re: the post below this, it's probably because it's an open bus, and I can't see what's there. If I recall, there was non-00 values somewhere around 0x4100, however this doesn't seem practical to use since it's hard to determine what's written there?).
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.
