Could you post your code?
confusion of controlling 2 players adds about as many rerecords due to screw-up as anything else
(Left) Running the bot looks approximately like this.
(Below) Much to my surprise, the bot actually yielded results.
I got the two refills I hoped for in that place. I got a third refill with the same method in Wily2.
So I can say that part of this movie is played by BisqBot.
Anyway, I've now completed Wily3, starting Wily4, but before playing Wily4, I'll keep a little break.
I made an AVI of the progress so far for myself, and I'll analyze it.
I don't want to rush the end like I did the last time.
I'm not publishing a WIP either, for whatever reason.
Because I haven't taken the timings carefully for the v4 movie in the Wily stages, I don't exactly know how much I've gained/lost in each period of the game, but overall at the beginning of Wily3 battle, I was 2931 frames (49 seconds) ahead the v4 movie.
EDIT: Oh, and if someone is interested of the luckbot's source code... here's the most relevant part of it. Goes to drivers/pc/input.c.
It won't do anything by itself. It requires some monitoring code in x6502.c and the bindings to keyboard commands.
The monitoring code:
The keyboard command code and the joypad update code:
Sorry Gorash to steal your 10-3 cheaply (I used my program to get the optimal solution)
a rerecords/seconds stats?!
Some days it walks right up to you.
wow, this should help you out alot
It goes just before the "b1=RdMem(_PC)" line in x6502.c. For every frame, it prints what bonus the game would give if an enemy spontaneously died at that frame.
It works perfectly.
Analyzing the output, I see that the "temp" variable changes less than I thought. If there are no other objects on screen and Rockman stands still, the "temp" variable keeps a steady 0x7C value. When Rockman climbs, it keeps a steady 0x03 value.
However, when there is even one "flea" jumping around, the number changes once every few frames. It seems, for the most part, to always contain values that are evenly divisible by 4, but not really always.
If the value didn't change, I could predict the bonus drops for hundreds of frames ahead, but when it changes, I can predict nothing because it works in a bit similar way as the CRC calculation works: tiny ripples change everything.
But I keep trying to find ways to abuse it.
Curiously, sometimes there are situations where you wouldn't get a big weapon drop no matter how many frames you waited. The RandomSeed can enter a short loop of unhelpful values. The loop can only be broken by influencing the TempVar.
I was thinking of looking for the energy drop algorithm when I was skimming a Metroid disassembly somebody linked me to
First of all, how big is the chance that an enemy will drop an item? Do stronger enemies have a bigger chance to drop an item?
And how do you manipulate what item the enemy drops, is this framebased or are there more factors in this?
Incredible. . . How in the world did you figure this out?
tag -- I used the Japanese double-width space character for indentation, unicode value U+3000.> At the boss, could you switch weapons on the way down on the right side of the guts block? It looks like it takes a while before you can pick it up anyway, and it's only vertical motion. That's a good idea! I'll do that. (I recall this idea is not new, but somehow I had forgot it.)
Perhaps you could hold the jump button for more upward speed, and kill it to 0 with grab-release on the ladder there to get a new jump sooner.
There definitely wasn't a single spot in the run which could be done faster, atleast to my knowledge.
If the battle was 3 frames slower than the previous one, shouldn't you correct that and make it atleast +-0? Or was this only an example (yes, I didn't bother to check my self :) ).
One thing I've been wondering about, how do you make any sense out of the timing tables on your Rockman page? I can't understand how they're supposed to work.
was my guess of max length beams correct?
