Can you explain this a bit further:
"However, if you take away the frames that are lost due to emulator differences, you can see that this run basically saves 2 frames from better luck manipulation (which also depends on the core used)."
-If the core used is determined by what emulator is used, how is that frame saving/loss not also due to emulator differences?
-Would you have saved a similar amount of frames if you did this TAS on the same emulator as the current submission?
I think for a game as incredibly hard to optimize, hard to route, hard to optimize movement in and steadily being broken as this it would be acceptable to keep the TAS going even if improvements are found to earlier parts. Otherwise you get stuck in an infinite loop of fixing the first 10-20% of the TAS and get burned out.
Even from a technical perspective there is ambiguity as to when the game is considered beaten or not, because 'the game is beaten' is a psychological phenomenon. (Consider the debate over the recent pokemon yellow glitched run, which loaded the credits in a glitchy, unintended way)
CGF95, you will be continuing from abahbob's WIP or doing your own stuff? And be sure to post lots of yummy WIPs and try out Gohma Storage/bombs on Gohdan :3
I was wondering something...
How are you determinate DataType? I'm looking for those values (and the velocity) on a psx game and I didn't found anything for the moment. Could it be possible that those values are floating point instead of integer?
What kind of datatype a playstation use for this? Word or Dword? (Byte is clearly too small)
Many thanks in advance for help
Your first guess at data type will depend on the type of game as well as the platform it's for.
8-bit consoles like the NES will use one or two bytes.
16-bit consoles like the SNES are probably using two bytes.
Early 3D consoles (PS1, N64, etc) could go either way - they might be using floating points (likely 32 bit then) or 16 or 32 bit integers and still calculating position by fixed point arithmetic. If it's a 2D game, it gets more likely it's not using floating points, if it's a 3D game it gets more likely. Also, consider that angle+magnitude may be getting stored instead of x/y/zs for things like facing and velocity.
Anything past the PS1 era, floating point is now very likely.
There's a menu where you can view the badges you've collected, the recipes found, etc. It is like the enemy tattle log except with badges. So, I guess fill that up?
Edit: You can sell the badges and the log will still be there. You just need to at least have the badge once.
In oot 100% you can lose the shield to like-likes but you need to have it at the end for it to count. Should similar logic apply here?
What would be considered a 100% TAS of this game? Obtaining all badges, beating all bosses (such as Bonetail) and getting all partners?
Definitely required:
-all partners fully upgraded
-all 100 star pieces
Probably required:
-all crystal stars (can see arguments either way on this one)
Not sure about:
-all sidequests/bosses (they don't technically make you stronger to do unless they give you a unique item or ability)
-all badges (unlike in paper mario, many badges can be accumulated multiple times. so when do you have to stop? 1 or more of every unique badge? enough of each badge type to fill 99 bp?)
What if you require every lambda used to be registered with the Official Bureau of Lambda Organization, including
1) providing/pointing to a method to return a lambda with the same bytecode
2) exposing the context for serialization
I'm a bit hazy on how this would work, or if this is even a thing that makes sense, but clearly as you say you can't serialize and deserialize arbitrary bytecode, so you can only create bytecode from methods coded into the game and determine which bytecode you make by what the serialized version of the lambda says needs to be made.
Hello, i'm Qwerty6000
I am new here, do you know how i can upload a picture to my new submission?
You mean you want to upload screenshots from your run that show off good moments in it/that you want to suggest could be used for the submission screenshot?
The trick is everything before 9 seconds in the video. Rather than going back out the door, you'd continue down the stairs toward the final boss. I just go back out to show that the trigger zone is still there.
You should add an annotation to the video to make it clear. (I figured it out on the second watch through lol)
As someone who hasn't heard of this game before, it looks right from my newbie perspective. It doesn't seem like you go too far out of your way for any candy and you end on the dot with the right amount. Can't offer more than that atm, good luck with the TAS!
Hi, you should use http://dehacked.2y.net/microstorage.php to upload and share input files, it's designed just for that purpose.
Some things you should do, if you haven't yet:
1) Try all illegal d-pad combinations (L+R, U+D, L+R+U... seven in total) in all player states, menus and so on you can think of, to see if you can find any oversights/glitches.
2) Use RAM watch to find player X, player Y and (if they exist as RAM variables) player X velocity and player Y velocity. (Note that similar RAM addresses tend to be grouped close together, so you can try looking for hp, score or one position variable and peering around it in memory for other useful addresses)
3) Calculate how fast the character moves in every mode of movement you can think of (walking, jumping, uphill, downhill, are there any frames of movement lost when jumping/landing, etc)
The site has some excellent resources on how to use memory search/watch here: http://tasvideos.org/MemorySearch.htmlhttp://tasvideos.org/EmulatorResources/RamSearch.htmlhttp://tasvideos.org/EmulatorResources/RamWatch.html
