Posts for JoselleAstrid

1 2
Posted: 7/30/2014 2:19 AM
Quote
JoselleAstrid
She/Her
Experienced Forum User
Joined: 9/9/2013
Posts: 35
Just wanted to point out that the script doesn't seem to work in OpenGL (with Dolphin 4.0-1997). The closest thing I've found to the "Textures created" string is an address that has all the stats text starting from "xtures created"... but at least from what I tried, I couldn't find a static address or static pointer for this. I'll have to stick to older versions (which support D3D9) if I want to use this script, since D3D11 is just too laggy for me with Mario Galaxy.
Posted: 3/24/2014 10:21 PM
Quote
JoselleAstrid
She/Her
Experienced Forum User
Joined: 9/9/2013
Posts: 35
I was trying to help someone use a variant of this Lua script, but upon trying to run the script, he got: "Error:Failure determining what Dolphin.exe means" Any idea what could cause this? It seems that he already had Dolphin.exe open in Cheat Engine, although it's also possible that there was some confusion (since the Lua engine's error console doesn't clear itself when you re-run the script...). EDIT: He got the script to work now, so it might've been that. Oh, but while I'm here again, I'd also like to say that this script has been immensely helpful. I've been using it a lot for testing things in F-Zero GX and Super Mario Galaxy 2.
Posted: 9/29/2013 11:51 PM
Quote
JoselleAstrid
She/Her
Experienced Forum User
Joined: 9/9/2013
Posts: 35
Hey got4n, thanks for the offer. I don't personally have plans to work on a full TAS or individual level TASes right now, though. My current goal is to develop real-time speedrun strategies as much as possible in the next 3 months, for a live run at Awesome Games Done Quick (speedrun marathon event in early January). About position and velocity values, I've found pointers for those. Basically, the values change location whenever you go to a different level (Sky Station star 1, Yoshi Star star 1, Yoshi Star star 2, and the Starship all have different locations for it). However, there are pointers that you can use to track the moving position and velocity values. But the pointers (well, at least the one I use) also move depending on whether you're Mario or Luigi. So I found a pointer to one of those pointers, which can be used to track the position and velocity values whether you're Mario or Luigi. Here's a Lua script you can run in Cheat Engine to display these values (based on Masterjun's script in the Dolphin subforum): http://pastebin.com/7AU6txZg However, these speed and position pointers may not be the most stable ones out there. There are some locations (like the pipe room in Fluffy Bluff galaxy, behind the tree) where occasionally, the speed goes to 0 and the position fails to update for a frame. This can be annoying when doing frame by frame testing. For example: Position 3000 | Speed 15 Position 3000 | Speed 0 Position 3030 | Speed 15 This is how I would expect it to go: Position 3000 | Speed 15 Position 3015 | Speed 15 Position 3030 | Speed 15 I'm not sure if it's the values themselves or the pointers that become unstable. It would be good to investigate this more. More things that could be quite useful - finding values that correspond to: (1) The direction of Mario's velocity (2) The direction Mario is facing (3) The direction of Mario's gravity Also, I've been working on learning about the speed, distance, and timing properties of Mario's (and Luigi's) various moves. Here is a folder with the findings so far: https://drive.google.com/folderview?id=0B96ZPjx3B1RqRUlhcjQ3WmNDUms&usp=sharing Here is the most general, info-packed document - a bunch of speed and timing info: https://docs.google.com/document/d/1Se76mcQjJtO-A5aCscW1z2SmeheoMkDxnoeNxnxZQNc/edit?usp=sharing There's still much more that can be looked into, but I think I'm done for the time being (going to work on level specific strategies now). Feel free to look into anything I haven't covered; I'd really appreciate it!
Posted: 9/23/2013 6:41 PM
Quote
JoselleAstrid
She/Her
Experienced Forum User
Joined: 9/9/2013
Posts: 35
Patashu wrote:
Is it correlated with... -Mario's position? -The kind of surface Mario is on? -What frame of animation Mario is currently in? -Some global timer?
None of these, as far as I can tell. I've been testing at the beginning of Beat Block star 1, where it's just flat ground; and I've tested just standing still on the same spot, just crouching multiple times in a row. Often, Mario would quick crouch (i.e. in 1 frame) the first time, and then slow crouch on the second time, third time, etc. Actually, this might be a decent lead: After some testing, there was one time where the quick crouch (i.e. in 1 frame) always happened on the first crouch I did after doing a backflip, or after doing a spin pound. But never the second crouch, third crouch, etc. After testing some more, this no longer happened, but I would occasionally get the quick crouch on the second crouch after a backflip or something (I don't remember exactly what I did). After testing some more, neither of the above happened, and I couldn't trigger any quick crouches at all. ...Well, after more testing, Mario's occasionally doing the quick crouch when I'm just sitting here crouching and uncrouching. Doesn't have to be the first or second crouch after anything. I still don't think it's animation related, since I think I'm getting quick and slow crouches on the same number of frames after uncrouching; but I could be wrong.
Posted: 9/23/2013 7:33 AM
Quote
JoselleAstrid
She/Her
Experienced Forum User
Joined: 9/9/2013
Posts: 35
So there's this thing that's been annoying me during basic testing, and it would also annoy anyone trying to remotely optimize Galaxy TASes at all: When I press Z, Mario crouches either 1 or 2 frames later. The problem is, I have no idea when it's 1 frame and when it's 2 frames. 2 frames is the more common case, but 1 frame would obviously be more useful. This affects the timing of inputs required to execute long jumps and backflips. If anyone feels like helping out with Galaxy TASing/Dolphin testing, investigating this would be a big help.
Posted: 9/17/2013 1:30 AM
Quote
JoselleAstrid
She/Her
Experienced Forum User
Joined: 9/9/2013
Posts: 35
I get an "Access Violation" dialog in Cheat Engine sometimes, even when just working with Cheat Engine's address list. Maybe it's the same thing you're experiencing? I'm not at all certain about when it happens, but it seems to happen often after I change my dual-monitor display settings (or disconnect/connect my external monitor from my laptop). It fixes itself if I just close and re-open Cheat Engine.
Posted: 9/14/2013 8:07 AM
Quote
JoselleAstrid
She/Her
Experienced Forum User
Joined: 9/9/2013
Posts: 35
Whoops, I forgot that Hybrid Wiimote was a control option. Well, that indeed works for the most part, as I can now see the accelerometer numbers and Wiimote button displays when I use a real Wiimote. It seems that Nunchuk input doesn't work on the real controller (only the emulated controller) when I use Hybrid Wiimote, though, so I can't see the real Nunchuk's control stick or accelerometer input. Still, it works for my purpose right now, which is seeing the accelerometer input during a real controller shake. It'd be ideal if I could record a real-controller recording and then replay it with frame advance, but instead, I used a separate screen-capture program to capture my Dolphin window (with input display and all) and output an .mp4. Then I frame-analyzed that with a video editing program. And yes, after thinking about how to do accelerometer or IR sensor input on a real controller with frame advance, I agree that actual TASing with a real controller would be a bad idea.
Posted: 9/14/2013 6:42 AM
Quote
JoselleAstrid
She/Her
Experienced Forum User
Joined: 9/9/2013
Posts: 35
Hey, so I've started to do some SMG2 testing in Dolphin to help develop real-time speedrun strategies. I've been working on trying to understand midair rock jumps (here's a demo video). Up to now, we've only known how to do a double rock jump (i.e. one midair jump) with somewhat good consistency; no one's known how to do three or more rock jumps with any consistency. And more to the point, we've just never really known how these rock jumps work. Here's a Google doc of my findings after a few days of testing. So far, I've gotten some good info on how the jumps work, and I'm pretty sure this means a TAS can easily do an infinite rock jump. But there aren't any groundbreaking real-time strategies yet. There's two methods to do double rock jumps fairly consistently (both were already more or less known). More notably, there's one method for a triple rock jump, but it's still difficult and random (I tried for about 15 minutes, and got it 8 times). There isn't a method for four jumps and beyond besides just mashing A and hoping. One major problem is the lack of an exact pattern as to what frames the rock spins actually come out on. This is what the timing of the A presses is based on, unfortunately. If anyone is interested in continuing my work, I've made a spreadsheet with a bunch of tests that I did. Perhaps someone else can notice relevant pattern(s) in the spin timings that I didn't see.
Posted: 9/13/2013 7:57 AM
Quote
JoselleAstrid
She/Her
Experienced Forum User
Joined: 9/9/2013
Posts: 35
Hmm, okay. Well, hope to see it sometime, I guess. Precise control stick input isn't a pressing need for me at the moment, though it could be pretty useful for testing Yoshi flutters in detail. Two other things relating to Real Wiimote input, which would actually be really useful for my purposes: (3) Is there an Input Display for Real Wiimotes? Graphics -> Advanced -> Show Input Display works to display input for Emulated Wiimotes, but not Real Wiimotes. (4) Is there a way to record input with Real Wiimotes? When I tried, the frame counter stayed at 0 throughout the recording, and the recording playback just showed Mario crouching in place the entire time. At least it didn't get a fatal desync or anythiing (since I disabled the GC controller ports), but the recording basically didn't work at all, either. My reason for wanting this: I want to see how many frames I shake the Wiimote when I actually do a spin with a real Wiimote. There is at least one trick (rock jumping) that is quite sensitive to how long the Wiimote is shaken.
Posted: 9/9/2013 11:36 PM
Post subject: Wiimote inputs and frame advance
Quote
JoselleAstrid
She/Her
Experienced Forum User
Joined: 9/9/2013
Posts: 35
Hi, I'm pretty new to emulator / frame advance testing, and I'm aiming to work on developing Super Mario Galaxy 2 tricks and strategies. Might work on full level TASes at some point, too, but that'll likely be at least a few months later. It's been going okay so far - I can now do basic frame advance testing without major issues, in Dolphin 3.5-2302 x64 (updated yesterday, 2013 September 8). But I have a couple of questions on how to make this nicer. (1) Is there a way to use frame advance with a "Real Wiimote" control configuration? When I try with a real Wiimote, Dolphin usually (but not always) ignores my inputs when I repeatedly tap the frame advance button. It tends to be more responsive to inputs when I hold the frame advance button, but that defeats the purpose of frame advance testing. I don't have such problems with an Emulated Wiimote, but of course that's more awkward to use when I'm used to playing the game with a Wiimote. (2) Does Dolphin's TAS Input tool (accessible from Emulation -> TAS Input) have a variation that works for Wiimote-based control schemes - Wiimote, Wiimote+Nunchuk, or Wiimote+Classic? It seems that the tool only works for games that use Gamecube controllers. Galaxy 2 requires Wiimote+Nunchuk.
1 2