At this point, it seem that no-no people would think that register are still part of the states, but since it seem we can't simply provide a verification movie this get a bit awkward. Yet it seem weird to me, that we aren't talking about the fact the the game use a patch(why this isn't in the description???) to bypass the game over screen since the submited movie doesn't "complete" the game without it.
Meanwhile, yes-yes people use the bad board arguments, since the register are just random anyway. So this make this submission kinda creative in his own way, even if there's no special TAS trick related. I see nothing wrong with that, but I'm not sure if this is the way to go if the site want to promote entertainement.
Now, the judge are probably going to accept it, since there is some reasonable/legitimate arguments(the game use a non standard cartridge), but I'll say this should directly fallback into the hack category, since a patch is required in order to complete the game.
If you guys want to obselete the game, there should be a special therm somewhere that specify that any improvements over the patchless game with a standard state would have no reason to not be accepted for publication.
edit: fixed some text
Next up: the ambitious task of improving the algorithm.
Your explanation about the complicated algorithm sound very interesting. Using probability to enhance performance of the guesswork to aim for the minimal input should be handful.
So far, in order to use some advanced math in Lua, I've only found lua-gsl, that might do the work if you don't want to manually implement all the function you need. But since you have to install GSL throught cygwin and generate your own alien dll for windows, I'm not sure if the script would be easily portable.
An another idea would be to use the R programming language to do the math work and use the TCP/IP Rserve server as an network API with this lua client, but I'm not sure either how well it actually work.
Bobo the King wrote:
I had a lot of trouble deciding what would definitively show that the game had been beaten. I decided to use a few RAM addresses corresponding to Mario's x position and the camera's x position, evaluated at frame 20,000, well after the end of the movie. I once again optimized the input one or two levels at a time. I probably spent 3 hours total optimizing the input.
Yeah, at some point when you can't find obvious memory addresses such as flag for a specific "checkpoint/endgame goal" you might use trick like x/y camera position, but at this point you might as well use screenshot to compare if this sync fine, just as AnS mentioned(for 2D games with static sprite+camera).
Also, once you minimize some more movie, I'll suggest you ask to an encoder to produce a couple of comparaison encode to highlight the best of what the script can do.
comparing screenshots and thus not always requiring RAM addresses (sure, optionally providing them would allow the script to finish faster).
Yep, comparing screenshot can be quite fast, but it would be much more faster if emulator provided an inbuilt way to hash the screenshot value with a lua function for it.
Thought, if you want to get rid of "artistic" value of a movie in favor of minimal input, you might prefer using the golden addresses. Ex: The game has some waiting time, so the player use this time to mess around, even thought he could just stay idle while the game prepare more gameplay.
I guess this might be an interesting use case to check later, once the script is good solid enough.
edit:
If you compare the whole RAM, that shouldn't be that long if you directly grab the state of the savestate instead of using memory.readbyte for each addresses.
If an image can have several tags, the easy way around is to use a table that map the path for the image and a tag(2 column). For each tags, you simply add one more entry. All the image and tags can be mixed together, so you simply use the WHERE clause of your favorite DBMS to select the list of tags.
Later, if you want to modify the list of tags for an image, this should be a lot easier.
If you dislike adding that single additionnal table, it's possible to use a NoSQL database such as MongoDB, but I wouldn't recommand trying it before getting more confortable with SQL-like database at first.
I'll prefer to see the run starting from clear ram and watch the run doing a couple of random reset until the ram registers get dirty enough to see this happening.
How many reset from clear ram registers would be required to see the trick working with the current setting of the emulator, anyway? I guess it can't be completely random either, even with different game console, they should have a similar pattern, so we can extract some metric out of this.
That said, I'm not a fan of any kind of reset spam behavior and I wouldn't like to see some good title getting owned this way.
edit: fixed ram to register
Main issue:
- in kkapture you need to have it as 30fps
> The plugin was half scaling the speed, so by putting it on 60fps you're making it go double speed.
<MUPEN Logic
Yeah, kkapture is bit picky but once you get something working, I guess it work just fine. Now the big question would be how well pete plugin+sound workflow behave or should we separe completly video capture from sound.
Don't hesitate to report any issue, I might not be able to fix this stuff right now, but maybe I can help.
First, I'm very pleased to see such topic, since I stumbled myself with so many overhead while trying to hack/experiment a way to get PSX encoding done with better sound. Sadly this little project, need yet an another real redesign for making it work better with the OO way(possibly with the help of the Koneki IDE instead of using my average text editor[Sublime Text2] and adding proper Luadoc that somehow enable extra autocomplete feature, but hey I guess it's not important here and nobody care), so I can push the process even further with better handling of more complex case such as disc switch, get better overall maintenance, etc.
Thought even if you manage to get Lua OO right, you are still bound to get some more headache for trying to figure advanced some advanced stuff like making a third-party library for multithreading to work with Lua. Particularly if you intend to give some work to your CPU and these queue these item. Personally I just feel like coding such thing in Lua isn't fun and usualy there aren't any kind framework to help for such issue. Thought, maybe it isn't that bad when know exactly what you're doing, while you keep relaying on other people library and you got a good grasp of the best OO pattern for Lua.
But yeah, enough with my issue and back to the subject. Does a reasonable passerelle between Lua and your favorite code language exist?
Derakon wrote:
Sockets might well be your most straightforward option, since it seems like you're going to have to have some inter-process communication. You might want to look up ways to do remote procedure calls (RPCs) in Lua; there's at least one library that can do it. That would save you from having to manually interact with sockets, as well as from having to devise your own protocol.
Even if this is bit slow on the long run and you might have to write a parser in both Lua and your favorite language. That really sound like the easiest way to go.
There's also the Windows named pipe that might work with the lua module winapi, but I doubt it's any faster either.
That said, a more radical solution would be to directly add an extra API next to Lua implemention for your favorite emulator. Then this API would probably support one of the fastest IPC implementation(credit to Nach for pointing this out to me, some month ago), but I guess that using socket or RPCs would still be the way to go and in such case, you wouldn't save much performance from handling communication with Lua.
feos wrote:
And yes, there are lua hashing functions :)
Yes, you can easily hash any string in Lua without problem. But I'm kinda unsure about the actual performance for grabbing the whole memory state from? I mean can you simply use memory.readbyterange(0x0, [max_length_memory]) and get the string quick enough and hash it? That would probably need some test, but if it work I guess it's all fine!
Yeah, I guess the TAS show with RealMyop & CoeurDeVandale is of great, as long as you speak/understand french(I do!). Not so long ago, I kinda disliked their new affiliation with jeuxvideo.com community tags. But I guess it's alright if they manage to get somekind of paid(and popularity) from it, in order to help them with their work continuation.
That's said, would these kind of monthly nicovideo count as a show?
If that's the case, would anyone be willing to *fan-translate* those, if the original author is ok with it?
I tried to mess around with the no$gba debugger and his breakpoint feature(I know it's already possible to "break" over memory access with lua, but I doubt you can see all assembler operations, the stacks, etc...). And yep, I got some data for those enemy block.
If that may help, here's a script that show some enemy info when the crossair appear(or when the enemy hp-bar appear at the top-right). I didn't figured yet how to directly get all enemy pointer for any battle.
Ok, en effet ça sync correctement avec la v24.
Petit truc mineur, à 8:20 et 14:50, il est possible de sauter sur l'échelle.
Côté ram watch, as-tu trouvé quelques adresses intéressantes?
Vite fait, j'ai trouvé ces adresses(unsigned-2bytes) pour l'hp des ennemis, mais j'ai l'impression que le jeu recycle l'utilisation de la mémoire à mesure...
0x02032C88 mob1
0x020329C8 mob2
0x0203271E mob3
0x02032C48 mob4?
...
Ah et sinon, j'en ai déjà une petite idée, mais pourquoi avoir choisi "Halloween Town" en premier? :)
edit: typo
J'ai pas réussis à synchroniser avec vbarr-svn480(desync juste après la cutscene du début). Mais d'après ce que je peux voir sur la vidéo, ça semble très bien. Beaucoup d'attaque combo et même un petit glitch graphique à la fin du premier boss!
Question: comment fonctionne la chance pour obtenir les bonnes cartes/rares? Est-ce avant que le combat commence ou pure manipulation durant le combat?
Depend of which Lunar game you're talking about...
-Lunar 1 : Silver Star Story (Genesis)
-Lunar 1 : Silver Star Story Complete (PSX) [Remake of Lunar 1]
-Lunar Legend(GBA) [Re-remake of Lunar 1]
-Lunar: Silver Star Harmony (PSP) [Rere-remake of Lunar 1]
-Lunar 2 Eternal Blue (Genesis)
-Lunar 2 : Eternal Blue Complete (PSX) [Remake of Lunar 2]
-Lunar Walking School (Game Gear) [Lunar 1 spin off]
-Magic School Lunar! (Saturn) [Remake of Lunar Walking School]
-Lunar: Dragon Song/Genesis (DS) [Complete other game]
Anything, on Genesis, GBA, Game Gear and possibly DS should run fine. As for PSX, a testrun with psxjin might be required, to make sure you won't have any bad surprise. As for PSP+Saturn, definitely not yet.
Yep that's a pretty good work, particularly I loved those dodging move.
Oh and I also think that an alternative encode without load screen would be more than welcome.
Now, what about these advanced campaign "Beyond the Dark Portal", any plan to do them? :)
Yeah now I remember. Making that gpu plugin work with lua graphic tool pretty much mean a full night(or more) of debugging just to understand what's going on with the graphic buffer pointer, etc... Then you need to make some kind of adapter for that particuliar plugin to get this working. I really doubt anyone would be motivated to fix this.
At some point, I wonder if it would be possible to make a hud from an "external transparent windows" where you simply put it over the emulator windows. Then this external would simply read a file containing the data to draw and show some line or rectangle according to them.
Maybe this(RAM search tab) ressource may help you for the job :)
So far, we can probably do some work with the (x,y) position of Abe and adjust the hitbox as he crouch, etc.
BadPotato,
I get the following error with the above script:
lua:2 unexpected symbol near ' '
The code posted above should work with a build from the "feos&Nach" repo, because of this. If it doesn't work, make sure you use a build from this repo.
Since I don't know how to package them can I request one please, I want to test this out too.
Here's the svn r624 revision. According to the feos commit message that should do the job for encoding, but we should definitly add a checkbox setting somewhere so people can keep TASing in sync/efficiently when loading a savestate.
As for the fullpackage, I'll try to work on it soon. There's an almost finished UI(kind of optionnal though) and some code clean left to do.
Now it looks like the detect application launched by sync script doesn't use TASspu, since there is a desync at EVERY frame, and it is not fixed by loading checkpoints..
It's kind of weird as the detect instance still fixe the first desync, but then it just give up. Anyway, in that case you'll need to follow these extra step:
BadPotato wrote:
-The sync script will launch an another instance of pcsxrr using the detect script with a switch plugin feature.
The last time I tried(some month ago) it used to work, but now for some reason, now I encounter a desync fest around the first few kill.
To fix that:
*Restore your backup folder(or restart from the very beggining if you didn't used a backup)
*Start the sync script using the Eternal plugin.
*Close the second instance using the detect script.
*Manualy launch a new pcsxrr instance using the detection script and the TAS sound plugin.
And that's it, no more desync fest.
As I said, these additionnal step might be required as long as I/we didn't figure what's up with the switch plugin feature that may or not work sometime. Just make sure to at least test without these step for your first time.
Dans Gens tu peux aller dans Tools>Ram Search
À partir de là, vu que les contextes changent beaucoup, on peut dire que chacun à sa technique pour trouver une valeur dans la RAM.
En gros, à partir de cette fenêtre, il te faut trouver un moyen de réduire le nombre de possibilités pour trouver la valeur que tu cherches:
Par exemple ici, on a 36864 possibilités de valeur quand on clique sur "Reset"
Vu qu'on ne va pas regarder chaque valeur une à une, je te conseille de faire quelques recherches simples. Ex: Faire des recherches avec 2bytes, vu qu'on cherche un chiffre assez gros et qui descend à fur et à mesure qu'on prend des coups. Bien entendu, il est possible que le développeur du jeu ait utilisé un autre pattern plus complexe pour enregistrer l'HP, mais il vaut mieux vérifier d'abord si l'hypothèse la plus simple n'aurait pas été utilisée.
Donc, une fois en jeu on appuis sur Reset, tout en laissant gens avancer "frameadvance". Puis on cherche des valeurs similaire à notre HP précédent. Si notre perso mange des coups, on cherche des valeurs plus basses à celui du passé, etc... ainsi de suite jusqu'à ce notre liste se raccourci assez pour les inspectés à l'oeil.
Si la valeur à du sens, on la prend en note, sinon on recommence ou essaye d'autres idées pour trouver la valeur.
Pour ma part, j'ai trouvé 0xFF083E pour l'HP. Les ennemis du début font environs 20-30dmg ou plus par attaque.
Si t'as besoins de plus d'info sur le sujet, il devrait y avoir un article ici sous l'onglet "RAM Search".
For the record here's the fix:
https://dl.dropboxusercontent.com/u/1682902/PcsxrrEncodeWofkflowV6.01.7z
I just tested this and it seem you'll need to do some temporary additionnal step to get it work:
-First, once collecting is done by phase1(by using the TAS sound plugin), make a backup of your encode folder(should be "BB2 slash mode 6443 dammit.pxm")
-When you're ready to start the the sync script make sure to use the Eternal plugin
-The sync script will launch an another instance of pcsxrr using the detect script with a switch plugin feature.
The last time I tried(some month ago) it used to work, but now for some reason, now I encounter a desync fest around the first few kill.
To fix that:
*Restore your backup folder(or restart from the very beggining if you didn't used a backup)
*Start the sync script using the Eternal plugin.
*Close the second instance using the detect script.
*Manualy launch a new pcsxrr instance using the detection script and the TAS sound plugin.
And that's it, no more desync fest.
As I said, these additionnal step might be required as long as I/we didn't figure what's up with the switch plugin feature that may or not work sometime. Just make sure to at least test without these step for your first time.
That said, thanks for reporting anything that might help me.
L'émulateur fonctionne bien en général si on se fie à la compatibility list. Par contre, d'après ce que j'ai pu tester il y a souvent des petits glitch ici et là.
Techniquement tu peux faire une demande sur leurs git repo(ou sur leur forum) pour savoir si l'émulateur serait TAS-friendly.
Yeah, at some point crypted data isn't good enough.
Well, I checked quickly what's up in your Bitbucket repo and it seem that you already use a "command pattern" to handle must of your stuff.
Why not use more of these command object instead of using some pointer function?
Then I guess you can handle what kind/inherited of command should be allowed when you load a savestate. Basically, only function that deal with the current game should be accepted, right? I don't think it would make any sense if the game start adding/removing random value in the score board or mess with the some other io files.
Par exemple ici, on a 36864 possibilités de valeur quand on clique sur "Reset"