The forums and IRC channel are frequented by people of all ages, and thus, content posted should consider the possibility of younger readers. While adult-themed conversations are not prohibited, they should be mature, purposed, and limited. In other words, don't be dirty simply to be dirty.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Expert player
(2100)
Joined: 10/12/2010
Posts: 1187
Location: Germany
Invariel wrote:
If I am remembering correctly, in the SMW case, death should be counted as negatively as possible (fitness = -MAX_INT) as dying saves no time in the game.
Experienced Forum User, Published Author, Site Developer, Expert player
(2100)
Joined: 10/12/2010
Posts: 1187
Location: Germany
creaothceann wrote:
Add a RAM check if a dialog box is open, if so spam the A button and skip the main part of the script.
While you're at it, you might also want to spam the B button for a bit when you didn't move for like 2 seconds.
And also why don't you also press the B button when there is an enemy right in front of you. It will make it more efficient!
See, here are the addresses:
Address Length Type Description
$7E:0094 2 bytes 3 Player X position (16-bit) within the level
$7E:00E4 12 bytes 2 Sprite X position, low byte.
$7E:14E0 12 bytes 2 Sprite X position, high byte.
$7H:L0L0 42 bytes yes Read this address to get the winning value!
But seriously, creaothceann, do you understand the concept of a self-learning AI?
It has to learn to either avoid the message box or get used to it (the message box is a sprite, so it can detect that).
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Oops, I'm sorry. For some reason I missed that.
pirohiko wrote:
TASVideoAgent wrote:
$0643: An Arithmetic Shift Left is done so that the Carry is 1 if B was held, else the Carry is 0.
$0644: This will branch forward if A was not held (since A is now the MSB), but if A was held then we go to:
Because the order of the key is "RLDUTSBA", I suppose that the explanation of $ 0643 and $ 0644 became alternate.
When A=0x80 was pushed, ASL turns on a carry flag.
When B=0x40 was pushed, ASL turns on a negative flag.
Indeed, thank you. I mixed up SNES and NES, because in SNES the first bit is B.
I mapped A of the NES to the same key on my keyboard as B on the SNES, so I thought it was the same. Silly me!
Fixed in the submission text.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Expert player
(2100)
Joined: 10/12/2010
Posts: 1187
Location: Germany
eternaljwh wrote:
So...did you [try] writing a faster intermediate code-loading routine after you achieved the first, like the Pokémon ACE TASes did?
Nope, I wrote the whole code in the same way.
eternaljwh wrote:
illegal opcode
Please, they're undocumented instructions.
Wikipedia mentions illegal opcodes first so I win.
An instruction consists of an opcode and an address mode. I use the term illegal opcode because I want to focus on the actual opcode, not the whole instruction.
Yes, alright, I worded it bad in the submission text...eternaljwh wrote:
what IS it doing during the extended wipe transition, anyway? Why does it do that rather than just start the ending sequence? (Must one bankswitch to L9's bank to access the ending routine, and level-transition is the easiest way to provoke that and still include "go to end"?)
It actually is the ending sequence, only the timer for the fading isn't set correctly. It starts decreasing at 0x00 so it wraps over to 0xFF, which is a bit longer than intended. The reason for the crazy graphics is probably because other values weren't set correctly.
And yeah, the credits are loaded with Level 9, so I had to switch to that first.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Expert player
(2100)
Joined: 10/12/2010
Posts: 1187
Location: Germany
Kurabupengin wrote:
It's a file selection screen where you name Link. Label it as a password would be weird...
It "would be weird"? Why would it be weird? Try to use arguments to support your opinion.
I think a password is just a word that lets you access some place, which fits this game.
Uses a password, let's just keep it at that.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Expert player
(2100)
Joined: 10/12/2010
Posts: 1187
Location: Germany
Oh and btw, there were previousattempts at ACE that unfortunately were slower than manually glitching to zelda.
But at least we got the jump to the credits by using another code (an indirect jump), so it's all good :D
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Expert player
(2100)
Joined: 10/12/2010
Posts: 1187
Location: Germany
Don't put the memory.registerexec in the while true loop. You only have to call it once (not every frame) for every address.
Also, in some emulators you can specify the number of bytes you want to look at, for example:
Language: lua
memory.registerexec(0xC000, 0x0FFF, function ()
--stuff
end)
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Expert player
(2100)
Joined: 10/12/2010
Posts: 1187
Location: Germany
Maybe you get some people interested if you do some research yourself? I mean you seem to like this game a lot...
I bet you can find at least some information somewhere in the internet.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Expert player
(2100)
Joined: 10/12/2010
Posts: 1187
Location: Germany
Oh yeah, this kind of situation happens a lot when TASing.
Pressing a button 3 frames after [dialog box, animation, etc.] appears, seems to be always the fastest way!
After you test that a bunch of times at different locations and it indeed looks like it is always the fastest way, you have two ways to continue:
Assume that it is always the first possible frame and continue TASing that way without stopping at each situation like this
Always test the frame before the "fastest" frame to really make sure you actually optimized that situation without a doubt
If I only have a visual indication I usually go with the second way.
If I have an actual RAM address of some sorts then I often go with the first way, to speed up my TASing a bit.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Expert player
(2100)
Joined: 10/12/2010
Posts: 1187
Location: Germany
sockfolder wrote:
From $0602, it executes some instructions based on the note in the music (I think), and tends to hit a JMP $0000 instruction (after some side effects).
At $0000, there are a bunch of mostly fixed values (i.e. fixed instructions). It executes a couple of instructions based on Link's X, Y. Then it moves into a chaotic section that I don't know how to manipulate yet and in the movie, jumps to $EC6E and from there, back into the normal game play without any side effects other than the game being totally screwed up.
I can confirm that. To be more specific, Link's X position is the address of an ASL instruction, and the Y position is a new instruction (might be useful).
The "chaotic section" that you are talking about is probably the area from $0018 to $0024 which looks like RNG. The bits for the 13 bytes are just shifted to the right and the leftmost bit (MSB of $0018) is determined by XORing bit 6 of the first byte and bit 6 of the second byte together (which is done before the shifting):
Executing music data seems like it would be really unlikely to always execute the JMP $0000, but it actually isn't that unlikely, because there is always a 4C 00 00 (JMP $0000). The code just has to survive to there, which isn't too unlikely. The fact that a code that makes the game continue was executed IN THE RNG (or whatever those crazy addresses are) is really unlikely... (well, due to the shifting of the crazy addresses, the JMP $EC6E does indeed pop up at 11 different times, but still, actually getting those values in the first place is unlikely...)
Edit: Oh and of course... the JMP $EC6E which is 4C 6E EC in bytes isn't actually 4C 6E EC to begin with. It is actually 4C 6E F6, but the UNDEFINED instruction (1F) at $0614 actually shifts $0021 one bit to the left, which happens to be the F6 which is shifted to EC... wow.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Expert player
(2100)
Joined: 10/12/2010
Posts: 1187
Location: Germany
The Movie Rules state that movies of games that are not emulated well should not be submitted.
You also aren't allowed to use tools that manipulate the ROM.
It might be possible to accept a run that syncs on both the original game, and a modified sound-enabled game.
Else, if the game doesn't work quite as well with hourglass, you will have to wait for an emulator that emulates the game better.
Also, don't use spoiler tags where there isn't actually a spoiler!
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Executing music data seems like it would be really unlikely to always execute the JMP $0000, but it actually isn't that unlikely, because there is always a 4C 00 00 (JMP $0000). The code just has to survive to there, which isn't too unlikely. The fact that a code that makes the game continue was executed IN THE RNG (or whatever those crazy addresses are) is really unlikely... (well, due to the shifting of the crazy addresses, the JMP $EC6E does indeed pop up at 11 different times, but still, actually getting those values in the first place is unlikely...)
Edit: Oh and of course... the JMP $EC6E which is 4C 6E EC in bytes isn't actually 4C 6E EC to begin with. It is actually 4C 6E F6, but the UNDEFINED instruction (1F) at $0614 actually shifts $0021 one bit to the left, which happens to be the F6 which is shifted to EC... wow.