Posts for someog

Posted: 12/20/2015 9:15 PM
Quote
someog
Experienced Forum User
Joined: 2/6/2011
Posts: 9
Quick encode: https://vid.me/ca1d
Posted: 12/20/2015 12:24 PM
Quote
someog
Experienced Forum User
Joined: 2/6/2011
Posts: 9
Hi all, I started this a few weeks, and since it's my first TAS, I'm starting from scratch. Can any of you give feedback on the quality of my WIP? I've done the first two stages so far. http://wikisend.com/download/373448/shinobi-13.fbm So far, I see two or three places where I could probably do it faster, so I'll definitely try improve those before I'd call these levels done.
Posted: 12/12/2015 5:52 PM
Quote
someog
Experienced Forum User
Joined: 2/6/2011
Posts: 9
nvm, figured it out. Apparently savestate.save is ineffective in the emu.registerbefore handler (creates a nonfunctional file), but is effective in emu.registerafter.
Posted: 12/12/2015 4:10 PM
Post subject: FBA lua: can't get savestate.load to work.
Quote
someog
Experienced Forum User
Joined: 2/6/2011
Posts: 9
Hi all. I'm trying to automate my saving/loading code. Per this doc https://code.google.com/p/fbarr/wiki/LuaScriptingFunctions, at some point in my attempts to tas, I'm using lua to call: savestate.save(savestate.create(1)) I've also tried savestate.save(1) This creates a savestate file in the expected older, but when I load that file, the emulation is unaffected. The game continues as if I had not loaded anything. What am I doing wrong?
Posted: 12/11/2015 5:54 PM
Quote
someog
Experienced Forum User
Joined: 2/6/2011
Posts: 9
Much obliged!
Posted: 12/7/2015 5:01 AM
Quote
someog
Experienced Forum User
Joined: 2/6/2011
Posts: 9
Many thanks so far for the replies! Alyosha, I have a crude version of that up and running. Very grateful. £e Nécroyeur, 00FFC04E was among the candidate locations I had found, but after much experimentation I'd not been able to make it behave differently than 00FFC0AE or 00FFD774. How did you know that was the one? Any more Shinobi-specific knowledge to share?
Posted: 12/6/2015 10:14 PM
Post subject: [FBA] RAM Search only works for big-endian values?
Quote
someog
Experienced Forum User
Joined: 2/6/2011
Posts: 9
I need to do a RAM Search for something that's encoded as little-endian, but as far as I can tell, the FBA RAM Search tool assumes big-endian. I see no option I can change. Any ideas?
Posted: 12/6/2015 8:41 PM
Post subject: Many n00b questions about FBA and TAS techniques. Did RTFM.
Quote
someog
Experienced Forum User
Joined: 2/6/2011
Posts: 9
Never made a TAS before, but I'd love to TAS Arcade Shinobi. I have several questions. 1. Is there a tool like FCEU's TASEditor that will work with Final Burn Alpha? 2. Any decent FBA tutorials out there? Youtube has a few, but they're very hard to get info from. 3. I'm attempting to find things like x/y speed using RAM search, but I keep getting about a dozen possible values. As in, I'll move a few pixels to the right and search for memory locations higher than before, then move a few pixels to the left and search for memory locations lower than before, and I come up with about a dozen locations that all seem to correspond to my x position. Any tips on narrowing that down? 4. Does input happen between frames, or ON a frame? For example, if FBA displays the frame counter as frame 9, and I frame-advance while holding the "jump" button, should I expect my character to be jumping on frame 10, or on frame 11 (having registered the input on frame 10). 5. If I "start recording from power-on" and press "OK", the screen goes black. Am I looking at frame 1, or is this some initial state such that I could conceivably enter input on or before frame 1? 6. Is lua scripting generally useful for FBA TASers? Any tutorials you could recommend? FWIW, I am a programmer by trade, so if that informs your recommendation, all the better. Thanks all!
Posted: 2/6/2011 6:13 PM
Quote
someog
Experienced Forum User
Joined: 2/6/2011
Posts: 9
The "Takes no damage" category is incorrect. Damage is taken due to a blocked special in both rounds vs Jarek. The fights were reasonably entertaining, but I was surprised to see so few fatalities. In this genre, being faster than the current publication shouldn't be considered a good thing. I think runs in this genre should really only be playarounds, since an actual attempt at a speedrun would have no fatalities, and every fight would probably be endless luck-manipulated repetitions of whatever move yields the maximum damage per unit time. Meh (not that I can vote).