does PCSX support lua ? If not it might be a good idea to try to implement that. It would be easier to make some custom scripts.
Unfortunately, mz already said he's not doing that a page or two ago. I don't blame him, since that would probably be a lot harder than it seems for an emulator as complicated as PCSX.
He was right about hacking a bot into the emulator, though- it's shouldn't be that difficult for any competent C coder... provided you can actually compile and run the emulator on your platform.
Nudge-nudge wink-wink. :p
But not Kefka, because while he has a party-value, he doesn't work, afaik.
You are clearly not acquainted with the magical genie that is Lua. :p
It would be harder to implement than switching one byte, but I doubt there's any serious problem stopping Kefka from being a (kayfabe) playable character.
As for Mario-only, I don't think there are any in-battle auto-revives- but I don't think you can attack your own side, either, making it a tad trickier to fix up.
Like I was saying, Lua can kill off unwanted characters the instant they come back to life for any reason. We could probably blot them out of existence altogether, but that would more than likely complicate things unnecessarily.
I always find that "solo" challenge in RPG is just silly
Kind of a silly thing to say in a thread called "solo character run", but more power to you. ;)
I thought I'd just point out here that a little bit of Lua hackery can get around whatever temporary class/character restrictions the game throws at you. When soloing FF6 using Terra, for example, we could swap in Terra during the parts where she's not normally in the party.
The consequences of having this kind of power are possibly even more interesting: you could conceivably solo the game with General Leo if you know enough about how the memory is organized.
In the end I think the number of rerecords is appropriate for a movie of this kind.
It is. On the MovieStatistics page, the rerecord ratio is calculated as rerecords/movie-length-in-seconds. The ratio for this movie is about 17, and the average ratio Mitjitsu posted is about 19. Being neither a platformer with crazy zip physics nor an RPG requiring buttloads of manipulation, I don't see what the issue is, here.
I liked Josh L./Superhappy's (canceled) Puzzle Bobble TAS from awhile back, and this looks to be a more condensed version, with a few extra twists. No obvious problems with execution, which the rerecord ratio corroborates. Looks like a solid submission.
Yes vote.
"Heart of Vlad" from the SotN remix album "Resurrection".
Probably old news to most people here, but it's an awesome album so if you don't know what it is, go get it.
I think it would be a testament to tool-assisted power if you can make it all the way to and then defeat Smithy using only Mario in SMRPG.
I don't think that's possible. You need to pick up other characters as part of the story, they are automatically added to your parter, and any dead characters are automatically resurrected for the next battle. Even just defending with the other characters every time does not achieve the same effect.
I was thinking, since a solo TAS doesn't need to be published here anyway, why not use Lua to "cheat" and prevent the auto-revive? One can record while running the script, and as long you run the script while replaying, it should play back perfectly.
Below is how the script would look. The question marks are values someone would have to determine with memory search. There could be syntax errors, since I haven't tried running it. I've never hacked SMRPG, so my assumptions could be wrong.
Lots of games use a "display" HP variable that's different from the one used in calculations, so that's another pitfall someone would want to avoid if they tried to plug the right values into this script. I tried something like this in Chrono Trigger years ago, and had a hard time with it because of how finicky the game is about detecting a dead character.
I think I've explained enough that anyone who knows hex and has used an emulator before could fill in the blanks, so I'm just going to leave this here for whoever.
--Solo Mario RPG script: Keeps non-Mario characters KO'd
--[[We need a few memory addresses for each of the characters.
Finding the "character" address will probably require a savestate
where at least four characters are available.]]
local character = 0x??????
local hp = 0x??????
local status = 0x??????
--[[character data is usually stored in blocks. In FFIV, I think they were sized
0x80. Hence, if 0x7e1000 is the HP of the top-slot character, 0x7e1040 could
be the second slot's HP, etc.]]
local OFFSET = ?
--[[RPG characters are usually enumerated, and the first character
is usually represented as a 0. Terra=0, Cecil=0, etc. ]]
local MARIO = 0
--[[Status ailments (poison, dead, etc) are usually stored bitwise,
so the value 0xFF or 0 will usually set them all to ON, and since death overrides
the others, turning them all on is probably good enough.]]
local DEAD = 0xFF
--main loop
while true do
for i = 0, 2 do
if memory.readbyte(character + i * offset) ~= MARIO then
memory.writebyte(hp + i * offset, 0)
memory.writebyte(status + i * offset, DEAD)
end
end
end
Me either. I stream videos through a shell script instead of actually following the links. There was nothing to suggest otherwise in the submission text, so I assumed the double KO was the ending.
I'm glad it wasn't though, because we get to see Cammy. :p
To be honest, I don't really understand why a simulation of relativity would be interesting to implement in a game or what that would look like, but judging from a quick Google search, it looks like a graphical demo of the physics may already be done. You'd be free to add game-like interactivity on top, assuming any of these projects are the kind of thing you're talking about.
Edit: Light Speed! wrote:
When an object accelerates to more than a few million meters per second, it begins to appear warped and discolored in strange and unusual ways, and as it approaches the speed of light (299,792,458 m/s) the effects become more and more bizarre.
There are a lot of improvements that already can be made, but I just wanted to see how people feel about the game so far rather than continuing with it if no one finds it entertaining.
I think the sliding destroys the entertainment value, kinda like using the cape in Super Mario World to fly over everything. Doing it glitchless might be good... or just slow. It's hard to say. :/
Pretty much what OmegaWatcher said: there was more style, and less infinite juggling. Moreover, MVSF is clearly a game better suited for TASing than the SFA series, with its tag system and faster-paced action. This submission blows away the other SF TASes, IMO.
Yes vote.
I seem to recall once seeing a Linux game that basically looked like a Mario clone with a penguin subbing in for Mario. This would've been a good five-six years ago, though, and I don't remember what it was called.
He can't knock down a wall, but he can withstand an explosion that does knock it down. Hooray for Nintendo logic! :D
...Aw, dangit. Desynced a few minutes in. What I saw was pretty good though, so I'll be waiting for the encoding.
And how about the one I provided? I did aim to meet the publication rules.
Thanks for that, Dammit.
I had the same "your cpu is too slow!" warning again, but this time -framedrop isn't dropping a noticeable number of frames. I guess MKV needs 3D acceleration. (Linux and my crappy ATI don't mix.)
Also, the aspect ratio is 1.71 in Dammit's and 1.33 in chaosv1's movie, even though both are the same resolution. I don't know which is correct or why they are different.
The encoding for this movie gets pretty badly desynced (desunc?) starting on the first cycle, third stage or thereabouts. Unfortunate.
Same. MPlayer is reporting that my machine is too slow. It's a Celeron D 3.2ghz and hasn't had this problem with any other video I've downloaded in the last two years, so I figure that's probably not the case. Turning on -frameskip "solves" the problem by running at about 45 FPS. This is with the latest SVN of MPlayer, FFmpeg, and x264. Converting the video to another format didn't seem to help at all.
Well, looks like I've gotten into a problem too difficult for me. I should start working on pointers instead, and I can pick this up later (by the end of summer, perhaps?). Also, I must stop posting so much in this thread.
By the way, Warp: is
for(int i = 0;;)
even legal C?
It is in c99, but not in earlier standards.
I think this is what Warp was alluding to...
Warp wrote:
(although making it C89-compatible is completely trivial).
I have to admit I wasn't expecting much from a soccer game, but that was pretty damn good. I think it could be publishable as a concept demo, but you'd have to finish the match for it to be considered.
Hopefully the game has an "exhibition mode" where you go back to the main menu after the match ends, because it's bad if the movie ends while still in normal gameplay.
Nice run. Leveling took a bit too long, but the rest of the run is fine.
Off-topic, but I noticed something odd with the FM2 conversion in FCEUX. I converted the fcm to an fm2 file on the latest official FCEUX(2.1.0a), and the FM2 file was almost 4.20 megabytes big. Is this normal?
Mine is 4.36. Weird, but I think the devs are already aware of this issue.
Edit: That is, assuming that this is actually an issue rather than your figure being caused by Windows' rounding, compression and general bogotification of data. Assuming you're on Windows.
The FM2 format is plaintext, whereas FCM was binary and often compressed, so it's naturally going to be quite a bit bigger.
The biggest problem I see with that approach is that the times being bandied about could make for absolutely massive movie files when uncompressed (and possibly even when compressed, depending on the format for the file).
Blip used compression (huffman encoding, IIRC) in the movie recording code. I don't think the file would be very large.
right that's how it would normally be done but most arcade games don't use saves and even for games that do save highscores and stuff fba doesn't emulate that
Frick.
Sorry. I think I disabled SRAM in FBA as the simplest possible way to ensure that it wouldn't pollute the game state when recording from power-on. Didn't know it was actually useful for anything TAS-related. You could ask mz to put it back in, or wait an indeterminate number of months for the redesigned version of FBA I'm working on.
There was a similar thread where some speculation was made. Nobody really knows, but collectively we can probably flesh in the list of ideas quite nicely.
The sad story is, after he encoded the video, he lost the SMV due to tas-movie-editor's mess. So he cannot prove how the trick is achieved for now. Currently, he and some anonymous guys in 2ch are trying to reproduce the glitch, but no one has made it yet.
Sounds like someone should just bruteforce it with Lua. With a rough idea of how Samus is to be positioned and what inputs are reasonable, it wouldn't take that long to test all possibilities.
(I'd try, but as I am on Linux, it's not really feasible.)
