I'm not a fan of VBA's interface. If this were a different emulator, I'd be using a built-in memory viewer, Lua, blah blah blah... You're going to have to verify them yourself using whatever memory viewer you use, but hopefully these are the addresses you're looking for.
Soma's X and Y coords (both 16-bit):
03007CE4
03007CF4
Soma's X and Y speeds (probably 8-bit):
03007DC6
03007D52
Edit: Added the X speed addy. Thanks, Eternaljwh.
That code was to give you the basic function, but I wouldn't advise trying to build upon it. Here's something more usable:
--ff2macro.lua
function frameadvance(frames)
for i = 0, frames or 1 do
joypad.set(1, joy)
FCEU.frameadvance()
joy = {}
end
end
function press(button, frames)
joy[button] = true
frameadvance(30)
end
joy = {}
FCEU.speedmode("maximum")
for loop = 1, 100 do
press("down")
press("down")
press("A")
frameadvance(20)
press("A")
press("A")
frameadvance(55)
press("B")
end
FCEU.speedmode("normal")
This script selects the topmost spell in a character's magic collection, targets something with it, cancels the next character's turn, and repeats.
As you can probably guess, the "press" function taps any button, and waits for a half-second. A half-second is usually enough of a delay to let the game get ready for more input, but sometimes you need to add more delay with 'frameadvance'.
You should be able to use these functions to construct a wide variety of macros. Don't forget to comment out the speedmode("maximum") line when testing.
I'd use Lua scripting for that. You'll need a recent version of FCEUX, if you don't have one.
I understand what the sequence "a, a, b" is for, so I wrote a script to generate the inputs:
--ff2grind.lua
function frameadvance(frames)
for i = 0, frames or 1 do
joypad.set(1, joy1)
FCEU.frameadvance()
joy1.A = nil
joy1.B = nil
end
end
joy1 = {}
for loops = 1, 100 do
FCEU.speedmode("maximum")
joy1.A = true
frameadvance(8)
joy1.A = true
frameadvance(42)
joy1.B = true
frameadvance(45)
FCEU.speedmode("normal")
end
Run it in battle and the guy will target an enemy, then the next person cancels. This repeats 100 times, as requested.
Awesome. I forgot about that thing that happens at the end.
I definitely enjoyed it and there are no glaring errors... I suppose someone should try to hex in any known improvements, but it's publishable in either case, IMO.
7.8|?
Limited bane sword was a plus. Lots of surprises. Interesting strategies, too, with the undead grinding and whatnot.
Open question: are there any other runs worth doing now that the any% TAS and worst possible party have been done?
Gunty has actually applied quite a few smaller scale Lua scripts to his latest Lufia II WIPs. I think automating a few small, especially tedious input sequences is the more practical way of botting, rather than having a bot TAS the game for you... which is actually what I've been doing with The 7th Saga. :D
It's true that brute forcing large problems is impracticable, but I've found that genetic algorithms work reasonably well at solving difficult problems. For example, my bot is designed to solve battles to find the shortest tree of attack/defend/item decisions, and uses a genetic algorithm instead of exhausting the entire space, because the entire problem space is potentially infinite! Applying the same technique to everything, solving an entire game via Lua is actually less conceptually difficult than I'd imagined; all you have to do is isolate all the types of operation that the bot needs to do, and "atomize" them as functions. Smaller functions coalesce into larger functions, which are then looped to test different inputs and/or randomness.
The hard part is accounting for irregularity in the game. Like when your "enemyHP" memory address fails for one particular boss halfway into the game. The harder it is to model the behavior of the game you want to TAS, the more work you have to put into writing an all-inclusive set of automations. Ultimately, writing very general bots is exponentially more difficult than writing small bots, but still practicable if you're willing to do a lot of testing, and write a lot of tedious code for a lot of special cases.
...Also, I should disclaim this little rant as being the sum of what I've observed so far, and that I haven't produced anything of actual value yet.
leandroff5:
Thought I'd fixed that, but I'm not surprised to hear that it's still an issue. In the near future, I plan to overhaul the part of the code that is likely responsible for your crashing, so hopefully that'll fix it.
Xipo:
Customizable hotkeys are the other top priority at the moment. I guess I could also bump up "memory watch" and try to get it into the next release. :)
Pretty simple: take mystate.fca, put it in a string, then put that string in one of Lua's normal, enumerated savestates- preferably one you don't use much. I'd wrap it in a function that takes the statename as an argument and returns a savestate object, or something like that.
Hm. I must have broken something if FBA official doesn't crash. I did mess with some of the graphics code, and the ROM loading, so it's reasonable that there could be unexpected side-effects.
I won't be able to work on this again for awhile yet, unfortunately, but I'll definitely look into this when I get back to it.
Thanks for the feedback.
It's a platformer/beat-em-up. There's a shopping system for getting new equipment, which may or may not be useful to a TAS. Treasure is cached throughout the game in out of the way places, and gathering it may or may not save time overall. It's 2-player simultaneous, which is always nice.
So here's a test run of level 1, using warrior-dude and the broad with the katana.
I think it would make a good TAS. Damage boosting is possible. Fall damage was negated at one point, apparently because the player had left the play area. Simultaneous death might possibly be used to avoid backtracking.
In the test run, I accidentally made it look like jump-slashing does more damage; it probably doesn't, but I could dig up some memory addresses to verify, as well as to watch boss HP. Oddness with my keyboard made it seem as if there were an invisible wall to cap player 2 from getting more silver. There isn't; it's possible to afford a force field at the end of the level- the most expensive item- assuming there were a reason to get one that justified the sidetracking I did.
Later, I might do a better/full test, and maybe some address hunting.
...Has anyone even heard of this? :p
I just watched the TAS again, and had a couple ideas. Sorry in advance if these have already been considered and/or are obviously wrong.
Is it possible to save time by killing a couple scientists in the Silo, thus making them throw their goodies at you? Likewise with hostages in the Frigate- maybe murder the last one so they're all considered to have "escaped" sooner?
Have you seen the Family Feud topic? That game actually awards points for ridiculous garbage.
Granted, most of my answers in that demo are lame (regardless of what the digital family thinks) but... I think you get the idea.
I didn't like the ending either. It seemed like a desync rather than a glitch. :/
On the other hand, if I had been watching the published AVI, it probably would have been funny. The guy dies, and then the movie just cuts out.
I liked the improvements, anyway. 7.8|WTF
Oh, sure. Jump to the right side of the trampoline thingy, and let the bee hit you so that you fly onto the platform.
I hadn't considered earlier, but if there are penalties for getting hit (like at the end of the level) or a frame-rule, they would probably negate the damage boost.
Hrm. I watched a few minutes and intuited that the precision was lax, so I banged on it a little and- if I'm not mistaken- saved a couple frames by damage-boosting over the springboard in the first level.
I'll have to watch the rest later.
IMO, entertainment in a beat-em-up comes from seeing hordes of enemies quickly disposed of, so I'd say that 2 players is better in all cases. Besides the extra damage output, you get more options for AI manipulation, death abuse, and silly behavior. Probably less monotony as well, just because there's more going on on the screen. Monotony is what people usually cite as a reason to dislike beat-em-up TASes.
I don't believe it would make or break the run by any means, but I definitely see 2-players as a big win, as far as entertainment is concerned.
Terse:
What Aqfaq said.
Long:
I preferred this run over the any%. I'm not sure why. Maybe just the deviation from what was relatively monotone platforming?
Anyway, 7.7/abstain.
Heh. No kidding. It strikes me every time I watch a movie of this game how ear-bleedingly bad the music is.
Having watched the other submissions, I can readily see how deranged the game is becoming under the increased glitchiness. High ratings, here.
Yeah, it's pretty hard to avoid getting hit, which would make a pacifist TAS interesting in theory. Healblade has a point though- watching someone dodge stuff and rarely fight back could get old fast. Not a good thing for a +20 minute run.
I felt like playing Level 2's venom stage, and arbitrarily decided to do it pacifist style. I kinda like the result.
Maybe a low% run of Level 2 would be an interesting deviation from the Level 3 TAS? Just throwing it out there, in case it hadn't been considered.
You're right, that is what it was doing, but after changing it to look for 0 or 1 I still couldn't get the eels to drop anything. But that's kind of irrelevant now. :p
Wow. It really shows. Looks like you removed a lot of lag in 7-3, too. I'm looking forward to the rest of it.
As you may be able to discern from this uncommented blob of Lua code linked below, the highest bit of the lobyte (00de) is set when the 2nd bits of both bytes are inequal. That is, it XORs the two bytes together after ANDing them with the number 2. Not much you could have done to predict that without a debugger. To be honest, I'm astonished you've figured out as much as you have if you really aren't using a debugger to trace the code.
Anyway, I've been working on a script that predicts flashy meat, partly for my own edification and partly because it would probably be really handy.
The script is basically done now. It's not pretty, but I think it'll serve its purpose. I used to it to manipulate flashy meats off of jellyfish and those green slug things, but not the eels... I don't know what that's about. It might need some tweaking, or maybe the eels are just jerks.
The script shows an array of numbers, each counting down to the next frame upon which, if killed, a given monster type will drop a flasher. The top number is for slugs, the second, jellyfish, etc. It only captures the four values you cited. If it turns out there's a monster that only drops on "flash MOD 192" or something like that, you can add more values to the "modnum" table, and the script will watch for those, as well.
Also, there are two modes: accuracy mode, which takes a lot of CPU, and casual mode, which will become inaccurate over time, as the RNG seems to advance when enemies need to "think". You can toggle the mode with player 2's A and B buttons.
If you want to use the script, you'll need DeHackEd's version of Snes9x with embedded Lua interpreter.
I was surprised the Phoenix couldn't kill that damn spinning eyeball boss any faster, but you obviously would have tried that...
All in all, it was easily one of the best TASes I've seen all year. Loaded with moments of astonishing WTFitude. Great job.