Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
andypanther wrote:
Can't we just accept B runs on their own, as long as they come with a verification movie that does whatever it takes in A to make B optimal, and ignore the A run? In the end, it's just like any run that requires a verification movie.
I agree with you.
Not to mention the whole issue of who is gonna even bother making 2 TASes of the same game just for a single submission? If you keep the categories separate at least you have a chance of seeing one of them get published.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
ALAKTORN wrote:
HHS wrote:
Ah, but it will advance the RNG once first. Every time it needs a random number, it advances the RNG, in addition to advancing it on every frame. So that needs to be taken into account.
Right, I thought I considered that by just advancing 1 step but that’s not what happens when you kill an enemy. In the intro I’m seeing 7 steps for the flying enemy thing, and randomly > 11 for the rotating blade… That makes it more complicated.
So I’m doing tests now. Freezing the RNG to 1114 always drops a Life Up, so even with those random advances from that enemy, the drop is consistent. It’s always 7 steps on the other enemy, so I tried advancing 1114 7 steps: 146014667. In hexadecimal this is 0x8B401CB. Based on HHS’s distribution #5, I’m looking for a 0x84 in the 3rd byte, here. I did it for all the steps, and none of them had 0x84, except for one: 2 steps = 1384400292, 0x528445A4. Bingo? So basically the item drop is the first thing that’s determined out of the RNG, I have no idea what the extra 5 steps (or even 10+ with the rotating blade enemy) are about, nor do I really care. (Also tested 1683597101 and 501745596, both have 0x84 3rd byte after 2 steps.)
Now I need a way to put this into a Lua so that I can manipulate drops with ease.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
I don’t think treating them all as a single thing would make sense. If you’re going for a speed record, each individual route will be its individual record, and you would try to optimize them individually. Why would you want to slow yourself down so that you can get some sort of feeling of “continuity”? Who cares? It’s a speed record, go for the fastest setup.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
HHS wrote:
Ah, but it will advance the RNG once first. Every time it needs a random number, it advances the RNG, in addition to advancing it on every frame. So that needs to be taken into account.
Right, I thought I considered that by just advancing 1 step but that’s not what happens when you kill an enemy. In the intro I’m seeing 7 steps for the flying enemy thing, and randomly > 11 for the rotating blade… That makes it more complicated.
HHS wrote:
If you want to look at the code, it is as 0x2032728 (thumb mode).
I don’t think I can understand that.
HHS wrote:
As for how I figured it out, I have an emulator with data breakpoints, but it hasn't been released to the public yet...
Huh… would probably be nice to have for the AWDS TAS. Not that I know much about using breakpoints.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
EEssentia wrote:
Yes, but I'm guessing the chances of that happening are pretty slim because we're adding and multiplying pretty big numbers.
But I’ve dumped the item drop from cheating the RNG to 0 up to 23k, and it goes through the items in sequential order. ( http://pastebin.com/acExBvgT )
Edit: I’ve tested advancing the RNG in my dump that gives a life up (such as 259 or 1114), and checked the 3rd byte in the resulting number, but it still doesn’t match up with any life up in any distribution posted by HHS. I’m confused.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
It shouldn’t be hard to find the RNG with RAM Search. Honestly it would probably help you a lot if you found it and did some basic maths to figure out its formula. I know nothing about the game but just because when saveloading you get the same results, doesn’t mean the RNG isn’t very random. When you save you save the RNG state, and when loading you load it back, so it’s gonna be the same as if you had just continued gameplay in many cases.
Anyway, are you sure A is the only button you can press to speed up animations and talk to NPCs? If you had a 2nd button for either you wouldn’t have to waste a frame of releasing the button each time you talk to an NPC.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
EEssentia wrote:
ALAKTORN wrote:
16–23 bits would be the 3rd byte, or the last bit of the 2nd byte plus almost the entirety of the 3rd byte?
Bits 16-23 is the 3rd byte unless we're using the unconventional belief that the first bit is bit 1.
Thanks. It just hit me but I don’t think this makes sense. If it only takes bits 16–23 for drops, wouldn’t that mean that any RNG number lower than 2^16 would result in the same drop every time? Because bits 16–23 are all 0?
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
16–23 bits would be the 3rd byte, or the last bit of the 2nd byte plus almost the entirety of the 3rd byte? If the latter that’s fucking weird and I don’t even know how I’d be able to calculate anything around it.
If the “distribution” as you call it depends on the enemy, it’s basically what I called a “table of item drops”… and I’ve only ever found 2 of them in the game. The hell do those other ones come from? #0 makes sense, some enemies never drop anything, but all others except for #4 (drop list B as I call it) and #5 (drop list A) don’t appear in the game as far as I know. #7 is particularly strange. What are those about?
How did you figure this stuff out, btw?
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
Damn. Thanks for the help. At first glance I’m confused about a few things, though.
HHS wrote:
When a value is needed, bits 16-30 are used.
That sounds ridiculous. That’s even less than 1 byte. You make a 4 bytes RNG just to use the last 5 bits of it? Actually not even last, 31 isn’t used. Also when you mention drops, you say it takes the first byte basically (which sounds wrong…). So that’s different to what you said before; when are bits 16–30 actually used?
HHS wrote:
So, for example, for distribution 5, the first value is 32, thus covering values 0-31, the second value is 12, covering values 32-43 and so on.
I also don’t understand this. I take it distribution 5 is “small ammo”, but what are the values about?
Edit:
HHS wrote:
which are listed at 0x20ddcfc as a list of tables of 8 halfwords each, giving the rate for each type of item (the range of values that cause this item to be dropped).
I just looked at this address and don’t get any of this either. That address starts off as 0000 0000 for me.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
AKheon wrote:
I don't agree with sacrificing real time in favor of in-game time (as seems to be the case here). I think whatever is the fastest way to manipulate should be used in every round, not only the one method that doesn't waste in-game time.
I think I agree. This is a nice proof of concept, and it could be linked in a published real time TAS, but I don’t think IGT should be preferable in this case.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
Alyosha wrote:
your resulting file only needs to have 1 number for each result, which won't result in a file bigger then 16 MB
Don’t understand what you mean.
Alyosha wrote:
And if you are only interested in 1-ups anyway you can just store those.
I guess but I’d still rather not have to map out the whole RNG.
Edit: Gave it a quick look, think I’ve found where the % 5699 falls apart.
2965 Nothing
2966 life up first 3 bytes: 0x96B or 0x960B idk
2967 big energy
778029 Nothing
778030 Nothing first 3 bytes: 0x2EDFB or 0x2EDF0B idk
778031 big energy
Don’t know what the fuck happens after that. For some reason the Life Up drop doesn’t match.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
I have a couple of scripts, but I think this one can be altered to log the 1 item per line output too: http://pastebin.com/BqzrJEm4
A month still sounds like a lot. I’ve found out that % 5699 stops working somewhere between 777959 life up and 778244 life up (2895 life up / 3180 big energy) which is between 5699 * 136 to * 137. Still WiP.
Another problem with having to map out the whole RNG is, where would I even dump it? So many MBs worth of text could actually be hard to store as a text file, if the file is too big I’ve had troubles opening it on my PC before. Also I’m not sure how it would work in terms of Lua look-up.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
Alyosha wrote:
Are you sure the cycle is 5699?
No. That was an observation based on a small sample. I guess with a bigger sample it may turn out to be wrong. If the true cycle is a far bigger value… Then coming up with a Lua to predict item drops will be problematic.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
Alyosha wrote:
You can test this yourself by simply using 2D A7 59 XX (the first three bytes from 1683597101)
That’s a weird definition of “first three bytes” to me…
1683597101 is 0x6459A72D, so instead of taking either 0x6459A7 or 0x59A72D, it takes 0x2DA759? Isn’t that like… looking at each byte individually? I’m pretty confused… I’ll have to look into that some.
Edit: Well if the calculation gives 5531, that doesn’t give a Life Up, so it’s still wrong…
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
Alyosha wrote:
EDIT:
Ok so all my testing was in the intro stage. I'm guessing this is an area that uses the other drop list you were referring to since I tried your RNG that should give a 1-up and got nothing.
Intro stage is actually correct. You have to freeze the RNG value to get the drop I’ve listed.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
^I like your avatar. What’s it from?
Joe wrote:
Curious how such a technique can kill your opponent before it does yoshimitsu. It really makes no sense when imagining that in practice.
He gets the kill because it’s a counter-hit. It requires AI manipulation to get the kill. Otherwise the damage is the same between Yoshimitsu and the opponent.
Experienced Forum User, Published Author, Player
(99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
Alyosha wrote:
When you calculated the table did you do it this way?
Calculated what now?
What you say sounds pretty weird… If it takes the first 3 bytes address-wise, that should mean that 0–255 should all give the same item drop (since it would be 00 00 00 00–FF address-wise), but as seen from my dumps and just by testing, that’s not the case.
Edit: Attempt:
1683597101 = 0x6459A72D first 3 bytes = 0x6459A7? = 6576551
6576551 % 5699 =
5604 = Big Energy
5602 life up
5673 life up
