Posts for BoursinBurger


BoursinBurger
He/Him
Experienced Forum User
Joined: 12/18/2008
Posts: 33
Location: SC
BoursinBurger
He/Him
Experienced Forum User
Joined: 12/18/2008
Posts: 33
Location: SC
BoursinBurger
He/Him
Experienced Forum User
Joined: 12/18/2008
Posts: 33
Location: SC
Ultima: Exodus has spent enough time being ignored. I'd like to see someone take a shot at it. Previous discussion threads: One and Two.
BoursinBurger
He/Him
Experienced Forum User
Joined: 12/18/2008
Posts: 33
Location: SC
I agree on entertainment taking the forefront of this TAS. I think unorthodox and humorous, yet quick solutions is the best path to take. The U-Boat for rescuing the kitty is a great example of that. The wave for cleanup is quick and hilarious. More exotic animals for the farmer rather than three cats. The airvent on the flowers was great though because it requires TAS precision to complete. Be obscure and diverse in your choices. Empanada is going in that direction. Take advantage of the huge dictionary available.
BoursinBurger
He/Him
Experienced Forum User
Joined: 12/18/2008
Posts: 33
Location: SC
Hilarious! Seeing that makes me really want to see Norimaru + Dan in a run.
BoursinBurger
He/Him
Experienced Forum User
Joined: 12/18/2008
Posts: 33
Location: SC
I think a lot of the gray area can be simplified by drawing equivalents to emulation as we already know it.
honorableJay wrote:
Scenario 1.) The game is loaded with the DOS environment variables required for normal play. During testing, it's found that by issuing a game save then resetting 3 frames into the save, it is possible to put garbage data into memory which can then be used to manipulate the best weapon at the start of the game and unlock characters required to immediately jump to the ending. Scenario 2.) By choosing a certain sound device, the game becomes unstable and allows the user to pass through walls and obtain items seemingly out of thin-air. Apparently the sound device accesses areas of memory that are mapped for the game engine itself. Using this knowledge, the runner can manipulate his items by entering certain areas so the game loads a specific music file, writing the item in question directly to his inventory. Scenario 3.) It is also found that a brute force method can be used to force the game to load without the correct DOS environment memory settings. Since the programmers never thought this could happen, and there are no in-game checks, the game barely plays like it was intended. Levels don't work as they should, walls can be passed through, the screen can be scrolled from one level to another and back again, enemies die seemingly from nothing. The ending is reached and the game completed in record time, being the only spot that plays like it normally would.
Scenario 1: Resetting an emulated file system in the middle of a write is probably not going to produce the same result as pulling the plug on an actual computer in the middle of a write. I would surmise that the former would be a bit more graceful in its approach. Scenario 2: This is the equivalent of using a buggy sound plugin for an emulator. Think of the emulation of DOS as an emulator for the game itself. Modifying the operating system or its drivers is modifying a part of the emulator outside the game and shouldn't be permissible. Emulation strives for accuracy. Scenario 3: Again, hacking the OS is like hacking the emulator playing the game and should not be allowed. Also, modifying the file system behind the game is the same as using a hacked ROM. Configuring the software within the game, its loader apps, or for INI files that are intended to be edited is fine, though. That's like an options menu. Now what if you put something in the INI that the game didn't anticipate and it causes havok? Well, back into the gray area we go. I didn't claim to solve all the potential issues, just to simplify them.
BoursinBurger
He/Him
Experienced Forum User
Joined: 12/18/2008
Posts: 33
Location: SC
Delurking! I was watching the first pass intently because I've been a fan of DOAE for years. Now this second pass is even more mind-blowing. Stuff I thought was nice touches on the second pass: - Picking up Han Zhong earlier instead of waiting till time to build the bridge. Might as well make some more use of him as an extra attacker before killing him. - Getting Chi Tu Ma. Even if just for sentimental reasons, but good to see that its agility boost helps the run. - Picking up Wen Hun after 2-shotting him looked effortless and badass. - In the final fight against Yuan Shao, it looks like he said you killed Yuan Shu even though you let him go earlier. 5 seconds later Yuan Shu dies in one shot. Fitting. - Completely humiliating Ma Chao by shutting down his entire army and then seeing him whine about it afterward. Looking forward to the rest!
BoursinBurger
He/Him
Experienced Forum User
Joined: 12/18/2008
Posts: 33
Location: SC
Long time lurker, first time poster. The first thing I want to say is that this had better be an April Fools' joke. If not, then I see all of this defeatism as an extremely severe overreaction. Several points come to my mind... 1) Emulation has never been perfect. It has always been an approximation. There's a nice debate in the Mega Man 1 thread comparing PPUs to determine whether or not a glitch is admissible because the question came up whether it was an artifact of the game, or the emulator. That kind of debate is fine, and leaning on the side of accuracy with regard to the console is preferred. But the understanding must remain that it will never be perfect. Which brings us to the issue at hand... 2) Programmers are lazy and flawed. Using uninitialized memory is a no-no if you want your programs to be consistent, but what if you don't care? What if you want a random event and you don't have a decent source of entropy? Read from something you've never written to and see what it is! Sure, why not? It gets the job done. This I see as the fault of the programmer, and not one of the site or the emulator. However... 3) Emulation provides a controlled environment. It doesn't matter if the real hardware is seeding new bits of randomness constantly. What you care about is that one bit the instant you plug it in, and that will be the bit used by the emulator on game startup. Assume a null state, begin with all zeroes for the registers, agree upon that as the standard, and move on. Because... 4) If the movie syncs, it is admissible. I assume for Blades of Steel and similar games the emulator starts with the same memory initialization every time, so movies made should sync. This renders the randomness issue moot. You assume the same initial state each time, the same input each time, and you will therefore reach the same conclusion each time. The Turing machine never lies. So if you're taking this hardware glitch seriously, don't. I refuse to see this site disappear on a trifling technicality. This site provides a great amount of inspiration, entertainment, and nostalgia. The TASers are truly artists in their craft of breaking algorithms and discovering shortcuts.