Author Topic: THREE THINGS I need to know about Attack Ship (ATTN: TOP PLAYERS, Wyst3r & Icy)  (Read 1861 times)

The man who trolled and lost everything

  • Posts: 19317
  • I'll be the backboost starring in your bad dreams
    • Goose
    • GE
    • PD
    • twitch
    • 2014CommunityContributor
    • http://www.twitch.tv/rwhitegoose
So I'm working on a video about Chuya's Attack Ship Agent 2:06, simply presenting the facts and asking the audience if they believe it's legitimate or fake.  Icy has painstakingly explained me the ending of the level, which I thank him greatly for.

I've started to do the math, but I need to know THREE more things in particular, with a SURVEY for TOP PLAYERS as the third question:

1) How long does it take from the Elvis TT (Elvis cracking the door at the end) for Elvis to reach the console on the bridge?  In other words, what is the shortest amount of time the first Skedar can uncloak, after Elvis cracking the door?

I estimated this to be "around 11 seconds" and in order for my math to work, I need this as "exact as possible."

The TAS cracks the Elvis door at 2:40.18 and fires a shot at the first Skedar at 2:51.31, a time of 11.13 seconds.

https://youtu.be/18jZHOwdYME?t=39m27s

Assuming the TAS has the Skedar uncloak at the first moment possible, then 11.13 (11 seconds and 4 frames?) is the number I'm looking for.

----

2) How long does it take for the 2nd Skedar, once uncloaked, to open the next door?

This is hugely important as this knowledge makes it possible for me to estimate when the 2nd Skedar uncloaked (sent out his clone.

in the TAS, the 2nd door does not get cracked until 2:54.80, a full 2.49 seconds after the first Skedar uncloaks.  Does this sound correct?  Does it really take about 2.5 seconds for this Skedar to reach the door and open it?  In this case, I would have to assume that the TAS also has the 2nd Skedar's clone uncloak at the very first moment possible (2:51.31) and it takes about 2.5 sec for this to take place.

By knowing how long this takes, I can reverse engineer when the 2nd Skedar uncloaked to figure out how likely this was.

For thought: Chuya's 2nd Skedar cracks open the door 2.23 seconds after the first one spawns.  This can be accounted for because the first one doesn't quite spawn at the "earliest" possible moment, but it means the 2nd Skedar spawned before the first one.  In Chuya's case specifically, the first Skedar spawns after about 2s, which would mean the second Skedar spawned after about 1.7s.

----

3) Top Players, how many runs in your career have you got to the end with a 1:46, 1:47 or 1:48 Elvis TT?

These don't have to be exact, just rough estimates are fine.  I simply want to paint a picture here and show "well there have only been x runs to the end at 1:47 ever, and Chuya got a 1/xyzqc luck ending, so..."

----

Thank you for your help!
« Last Edit: April 08, 2018, 06:20:23 AM by The man who trolled and lost everything »
~ S T A Y ❄ T R U E ~   |   ~ S T A Y ❄ B L E S S E D ~   |   Verax Maneret

The man who trolled and lost everything

  • Posts: 19317
  • I'll be the backboost starring in your bad dreams
    • Goose
    • GE
    • PD
    • twitch
    • 2014CommunityContributor
    • http://www.twitch.tv/rwhitegoose
1:46, 1:47, 1:48 estimates:

Karl: about 5 1:46s, 20ish 1:47s

Icy: None

Ace: total 147/148s is at least 50, could be more
147s around 20ish i guess
« Last Edit: April 08, 2018, 06:54:57 AM by The man who trolled and lost everything »
~ S T A Y ❄ T R U E ~   |   ~ S T A Y ❄ B L E S S E D ~   |   Verax Maneret

Icy

  • Posts: 1860
  • Don't overestimate me.
    • GE
    • PD
    • twitch
    • 2014SilverStar
    • 2015SilverStar

Wyst3r

  • Posts: 4139
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
1) How long does it take from the Elvis TT (Elvis cracking the door at the end) for Elvis to reach the console on the bridge?  In other words, what is the shortest amount of time the first Skedar can uncloak, after Elvis cracking the door?

I estimated this to be "around 11 seconds" and in order for my math to work, I need this as "exact as possible."

The TAS cracks the Elvis door at 2:40.18 and fires a shot at the first Skedar at 2:51.31, a time of 11.13 seconds.

https://youtu.be/18jZHOwdYME?t=39m27s

Assuming the TAS has the Skedar uncloak at the first moment possible, then 11.13 (11 seconds and 4 frames?) is the number I'm looking for.

Elvis reaching console is completely irrelevant, he shouldn't even have to be at the console for the uncloaking to start. As the facts topic post says, the only TT that actually matters is when you kill the last skedar on the bridge. Elvis opening the door is also irrelevant and inconsistent up to at least half a second, but since this is the TT that's been used historically, we'll continue using it here. This means:

1. From last bridge skedar kill -> First possible uncloak = 23.33 seconds.
2. From elvis opening door -> First possible uncloak = 23.33 - 12.39 (+- 0.21) = 10.94 (+- 0.21)

This fits well with your TAS timing.

2) How long does it take for the 2nd Skedar, once uncloaked, to open the next door?

This is hugely important as this knowledge makes it possible for me to estimate when the 2nd Skedar uncloaked (sent out his clone.

in the TAS, the 2nd door does not get cracked until 2:54.80, a full 2.49 seconds after the first Skedar uncloaks.  Does this sound correct?  Does it really take about 2.5 seconds for this Skedar to reach the door and open it?  In this case, I would have to assume that the TAS also has the 2nd Skedar's clone uncloak at the very first moment possible (2:51.31) and it takes about 2.5 sec for this to take place.

By knowing how long this takes, I can reverse engineer when the 2nd Skedar uncloaked to figure out how likely this was.

For thought: Chuya's 2nd Skedar cracks open the door 2.23 seconds after the first one spawns.  This can be accounted for because the first one doesn't quite spawn at the "earliest" possible moment, but it means the 2nd Skedar spawned before the first one.  In Chuya's case specifically, the first Skedar spawns after about 2s, which would mean the second Skedar spawned after about 1.7s.

My facts topic post states: "It then takes around 3.3 seconds before he opens the door (though slower is possible)."

---------------------

A bit more in-depth analysis of the TAS:

Last bridge skedar kill: ~2:27:68
Elvis opening door: ~2:40:05 (after 12.37 seconds, roughly 0.19 slower than fastest)
First skedar kill: ~2:51:31 (after 23.63 seconds, .3 slower than fastest possible)
Second door opening: ~2:54:80 (after 27.21 seconds, 3.88 seconds after earliest possible spawn, and if it takes at least 3.3 seconds to reach door after spawn, he must've spawned within 0.58 seconds)
Third skedar kill: ~2:55:36 (0.56 seconds after second, 4.35 seconds after spawning starts. In order words, the TAS is sub-optimal and loses roughly a second compared to a "perfect" ending, half a second on the 2nd skedar spawn, and another half a second on the 3rd)

This makes sense since Miikka didn't have the knowledge that we now do when making the TAS, and simply went for the fastest ending he could get (I wasn't involved since I stopped working on the TAS after Crash Site, and Miikka did the rest of the stages). The odds of an optimal ending (ignoring 1st skedar) is (if i'm not totally mistaken) (1/256)^2 = 0.001526%. We want 2nd skedar to spawn ASAP, which is 1/256. And since the 3rd skedar can't spawn until 2nd is shot, the outcomes of his first ~66 cycles ((~3.3 seconds * 60 frames per second) / ~3 frames per cycle) don't matter. Only the ~67th cycle matters which is again, 1/256.

« Last Edit: April 08, 2018, 08:30:15 AM by Wyst3r »

The man who trolled and lost everything

  • Posts: 19317
  • I'll be the backboost starring in your bad dreams
    • Goose
    • GE
    • PD
    • twitch
    • 2014CommunityContributor
    • http://www.twitch.tv/rwhitegoose
Thank you for this EXTREMELY useful info!

Are the odds of an optimal ending not *somewhat* dependent on the first Skedar though?  ie: if you get an instant 2nd Skedar, so he opens the door 3.3 seconds after he instantly spawns, you will need to be there, and be ready to shoot him immediately.  So this means you want at least a 2.8s or so first Skedar, so that you will have time to kill the first one, then turn over to kill the second?

So you need to base the odds of say, Chuya's ending, on "getting a first Skedar good enough to match the pace of his 2nd Skedar."  Which may have allowed him a little more forgiveness.

The third one obviously matters because he needs to spawn immediately, so you want to get the 1/256 byte check as soon as possible after the 2nd Skedar.

Also, are you sure it's 256 bytes?  I've been working with 1/255 instead of 1/256, based off what Icy said.  Not that it matters all that much.
~ S T A Y ❄ T R U E ~   |   ~ S T A Y ❄ B L E S S E D ~   |   Verax Maneret

Wyst3r

  • Posts: 4139
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
Are the odds of an optimal ending not *somewhat* dependent on the first Skedar though?  ie: if you get an instant 2nd Skedar, so he opens the door 3.3 seconds after he instantly spawns, you will need to be there, and be ready to shoot him immediately.  So this means you want at least a 2.8s or so first Skedar, so that you will have time to kill the first one, then turn over to kill the second?

So you need to base the odds of say, Chuya's ending, on "getting a first Skedar good enough to match the pace of his 2nd Skedar."  Which may have allowed him a little more forgiveness.

The third one obviously matters because he needs to spawn immediately, so you want to get the 1/256 byte check as soon as possible after the 2nd Skedar.

Correct.

Also, are you sure it's 256 bytes?  I've been working with 1/255 instead of 1/256, based off what Icy said.  Not that it matters all that much.

A byte can have a value ranging from 0-255. That means there are 256 possible values.


vitorr

  • Posts: 216
    • GE
    • PD
    • twitch
    • 2017RankingsDev
My 210 was high 147 iirc  :kappa: I was playing NTSC and because of that it'd take many hours to get one elvis completion (at least from the common belief Elvis would complete more on PAL). So that was probably the only one I had. Maybe I had one or two 148s (as I also completed 211) but not really sure.

Icy

  • Posts: 1860
  • Don't overestimate me.
    • GE
    • PD
    • twitch
    • 2014SilverStar
    • 2015SilverStar
Yeah, it's not entirely understood why, but Elvis essentially never completes on NTSC on fast runs, but almost always does on both PAL and Jap.

The man who trolled and lost everything

  • Posts: 19317
  • I'll be the backboost starring in your bad dreams
    • Goose
    • GE
    • PD
    • twitch
    • 2014CommunityContributor
    • http://www.twitch.tv/rwhitegoose
Henrik, I NEED to know/understand the following:

In the PD facts topic, you wrote:

"The timer is set to 300 frames (5 seconds), making this the upper limit for how long they can wait. In order to act earlier than this, the skedars need to seed a random byte equal to 0. This means that they have a 1/256 chance to act on any given loop iteration. As mentioned in Chapter 1, the game does not run scripts every frame. Instead, it's highly lag dependent, and on Attack Ship the frequency seems to be closer to one iteration every ~3 frames. Note that this number is based on emulator tests which may be more prone to lag than console. Icy was kind enough to make a spreadsheet based on this information, which shows the probabilities that a skedar will act after any given time. "

https://drive.google.com/file/d/0B_qzrv1WjgSsSXJHbGhLRGczd1E/view

1) Why do I sometimes see the first Skedar take more than 5 seconds (that being, more than 28.3 seconds after the last bridge Skedar is killed) to uncloak?  On both Green's SA 2:33 and Karl's Agent 2:09, he takes over 6 seconds to uncloak.  What explains this?

2) Icy's spreadsheet... is this written for information in 30 or 60 frames?  Are those 100 byte checks taking place in 5 seconds?  Is there no time limit at all, and the game will release the Skedar after 100 checks?  And those checks can take place any time, randomly, between 1 and 4 frames apart or something?

My understanding WAS that you could say the seed checks the byte every roughly 3 frames, which in a 30fps environment is roughly every 0.1 seconds.  This is a good enough number to approximate with.  But now, I don't know what to think.
~ S T A Y ❄ T R U E ~   |   ~ S T A Y ❄ B L E S S E D ~   |   Verax Maneret

Wyst3r

  • Posts: 4139
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
1) Why do I sometimes see the first Skedar take more than 5 seconds (that being, more than 28.3 seconds after the last bridge Skedar is killed) to uncloak?  On both Green's SA 2:33 and Karl's Agent 2:09, he takes over 6 seconds to uncloak.  What explains this?

                         Green 2:33    Karl 2:09
---------------------------------------------------
Last skedar kill:   02:00:4X       01:34.3X
Uncloak:             02:28:9X       02:03.2X
Diff:                   00:28:5X       00:28.9X

This is basically within the margin of error (I'm guessing Karl's is near the upper limit). The reason for the extra delay is mentioned in the facts topic post:

Quote
As always with GE/PD, the game doesn't check the timers every frame, so there's always going to be a slight delay beyond the 23.33 seconds. How often the game checks is mostly lag dependent so keeping lag low during this time is a good way to save a few frames. On emulator, I measured the delay to be .1 - .2 seconds, with roughly .1 saved by using full lookdown (might be less on console).

Note that you get a similar delay after the additional 5 seconds. Possibly also after killing the last bridge skedar. In any case, we should always expect to lose a couple of tenths due to these delays.

2) Icy's spreadsheet... is this written for information in 30 or 60 frames?

I always use 60 fps, since that's what the game uses internally for timers/logic.

Are those 100 byte checks taking place in 5 seconds?  Is there no time limit at all, and the game will release the Skedar after 100 checks?

The logic goes something like this:
Code: [Select]
start_timer()
while((timer < 5 seconds) AND (random_byte() > 0))
{
    sleep_for_a_few_frames()
}
uncloak()

So there is a time limit of 5 seconds. The ~100 byte checks is just the result of ((5 seconds * 60 frames per second) / ~3 frames per check) = ~100. If you for example had low lag and there was ~1 frame per check, you'd have ~300 byte checks.

And those checks can take place any time, randomly, between 1 and 4 frames apart or something?

Yeah.

Boss

  • Posts: 3968
    • GE
    • PD
    • twitch
Here's a run I did around when I got 2:08 that has crazy potential for Elvis.

https://www.youtube.com/watch?v=F2N7zWDlaqM

I reckon a high 1:44 Elvis was possible here just from how safe my first bridge skedar kill was and slightly better on the other kills.

wheatrich

  • Posts: 2846
    • GE
    • PD
    • twitch
lol, all that for goose's vid and we're back to the beginning, possible yet improbable that still isn't too much worse than some other WR's for RNG needed.

A lot of the nuances for the casual viewer who'd auto think fake (ie proof quality, not a community member) are obviously easily explained.

Whiteted

  • Posts: 79
    • GE
    • PD
https://github.com/whiteted-strats/AttackShip

This seemed a good place to post: I did a proper analysis of the ending of attack ship assuming 10 1/256 checks per second. This gives 1 in 1037 for the 2:06 pace ending, and suggests it's "not a lot luckier" than Boss' 2:08 which is 1 in 133.
Reading this thread I see the earliest spawn could be earlier and there could be more than 10 checks a second which would bring these probabilities down, especially the 2:06 one.

Wyst3r

  • Posts: 4139
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
Amazing effort, didn't expect a report like that. I haven't had proper time to review the pdf/scripts yet so my in-depth analysis will have to come at a later date. I did notice some errors though, some of which stem from Goose's video (if you haven't already, you should read my facts topic post) and others which seem to be slight misunderstandings of the mechanics involved. I could simply be misinterpreting your pdf of course so please correct me if that's the case:

1. The framerate assumed is 30Hz, while in reality it should be 60Hz. So the number of cycles before a forced spawn should be 100 instead of 50. The 10Hz would have to be doubled as well.
2. You seem to assume Skedar #2 spawn only comes after Skedar #1 is dead? While in fact they run their scripts in parallell (both 1st and 2nd can exist at the same time). It's only 2nd and 3rd that are dependent on each other. I would suggest calculating 1st and 2nd/3rd separately to simplify the problem.
3. I don't see any mention of the time it takes 2nd skedar to reach the door after spawning? The 'instakill' assumption doesn't work for 2nd skedar (it's fine for 1st and 3rd though).
4. "any events in the interval from the frame when an enemy spawns until the enemy is killed have no effect on the rest of the run" - Well, it matters if you hit the 1/256 check while the 2nd skedar is alive (see above point). Because that will reset the timeout for the 3rd skedar, which is probably crucial in determining the final probability.

Also you mention despawn times, which as stated in my facts topic post, are irrelevant. The moment the shot hits the Skedar is enough to consider him dead.

From the Python code, I like the idea of caching results as well as approximating the probability by running X trial runs. I tried writing a C++ program myself a while ago but the computational complexity of simulating all possible paths for 400+ cycles was obviously not feasible :p I guess if alot of paths reach the exact same state then the caching would be very powerful in bringing down the computation time. And running X trials obviously doesn't require much computing power at all, so I'd imagine that approach should always work.

Quote
I am not clear whether the earliest moment that the first enemy can spawn has been read out of the game's code or whether they have been deduced by many trials.

It's from the game's code :) The GE/PD game scripts are available via the Goldeneye Setup Editor.

Whiteted

  • Posts: 79
    • GE
    • PD
Thanks I will read your facts topic when I get the chance! It seems I have got the wrong end of the stick with a lot of the mechanics

1. I was thinking the framerate was 30Hz with checks every 3 - if it is roughly doubled that's good news for lower probabilities.
2. I also thought the Skedar #2 followed #1 but I see there's some symmetry to it.
3. I thought the distance from the 2nd skedar to the door wasn't far but I guess it should be included since the times we're dealing with are already very low.
4. Yeah since Skedars #1 and #2 are trying to spawn alongside each other it certainly does matter.

With despawn times I got the impression they were irrelevant from Goose's video but I wasn't sure - I did actually assume it for ease  :grinning:

Essentially I accept all of your points lol

The caching idea in the code looks like a hack but essentially it can be seen as working backwards from the success states towards the start state, so it is kind of neat. Python always makes it easy to hack rather than code properly  :angel:

Quote
It's from the game's code :) The GE/PD game scripts are available via the Goldeneye Setup Editor.

Wot.
I thought I was going to have to reverse engineer it and stuff. Do I literally get some kind of bytecode from it? I don't have much free time for another month yet :sad:


The man who trolled and lost everything

  • Posts: 19317
  • I'll be the backboost starring in your bad dreams
    • Goose
    • GE
    • PD
    • twitch
    • 2014CommunityContributor
    • http://www.twitch.tv/rwhitegoose
Here's another breakdown someone sent me:

https://www.sharelatex.com/read/pddbmvxwtbfv
~ S T A Y ❄ T R U E ~   |   ~ S T A Y ❄ B L E S S E D ~   |   Verax Maneret

Whiteted

  • Posts: 79
    • GE
    • PD
Okay I've worked out a new way to model all of the ending except for the interaction between Joanna moving towards the second door and Skedar #2 moving toward Joanna.

The main question I have is how far would Skedar #2 get if it spawned at the first 1/256 test and Skedar #1 only spawned on the 5 second timeout? It would be nice to say that Skedar #2 gets no further than the door, so that I can simplify things. Alternatively maybe we can say that okay it may get out of the door, but we will want to move across to the door before killing it, since we want line of sight on Skedar #3? In the standard strategy you stand tight to the frame of the left door, so I assume Skedar #2 can't shoot you before Skedar #1 spawns?

Basically what is Skedar #2's mechanics? Does it even know where Joanna is?

Are there any example videos of this late #1 - early #2 spawn happening? I did look at a sample of those listed in https://rankings.the-elite.net/perfect-dark/stage/attack-ship but didn't see any (also some of those videos are less watchable that Chuya's ouch).


Wyst3r

  • Posts: 4139
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
Ive seen examples of that case though I cant say where. I think it's okay to ignore that case for now and assume failure if first skedar doesnt spawn fast enough to get to the 2nd door the moment it opens. Alternatively we could assume 2nd skedar to be killed the moment you reach the door (as if he stayed still in the door opening).

Whiteted

  • Posts: 79
    • GE
    • PD
Okay the corrected model seems to be bug free :laugh: and gives quite a strange distribution, but it is actually reasonable with quite a bit of thought. The 208 jump here comes from Skedars  #2 and #3 running their timers down, plus 5 frames (0.25s) for you to kill Skedar #3. The 'foot' which Boss' 2:08 (165) is on is a bit of a mystery to me at the moment but it seems reasonable :)



The x-axis is time in frames, with 20fps (decision frames), and y-axis the probability of finishing the ending within that time, from earliest possible Skedar #1 spawn to Skedar #3 kill. The 2:06 is at 120, 2:08 at 165.

This gives a probability of just 1 in 119 for Chuya's ending (120 frames) , and 1 in 12 for Boss' 2:08 ending (165 frames). There's also an image of the function where I've log-ed the y-axis which shows that Chuya's 2:06 ending sits at quite a nice spot in terms of still being feasible.

I'll get all the details and clean code written up for scrutiny soon. I think I'll change my recommendation and encourage people to try and beat it  :p or atleast look into making the start more consistent.
« Last Edit: April 27, 2018, 07:27:13 PM by Whiteted »

Wyst3r

  • Posts: 4139
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
Cool, these numbers certainly sounds like they could be correct. I'll probably try to do some simulations of my own over the weekend to see if I get matching results.

Whiteted

  • Posts: 79
    • GE
    • PD
It turned out there were a few bugs which were essentially around not letting Skedar #2 move towards the door until Joanna moved, and constantly reseting Skedar #2's 'position' back to its spawn point.

With these corrections I get some actually surprising figures of 1 in 119 for the 2:06 ending and a mere 1 in 12 for the 2:08's.

It's all up on the github repository, but it's a bit beastly now. I've kept the report more concise but the C# code is 400 lines, and pretty hard to reason about, though hopefully well commented.

So yeah.. someone work out how to make that start more consistent.

Wyst3r

  • Posts: 4139
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
I wrote a quick C++ program to simulate 10000 runs, and the results were pretty much identical to yours. I didn't take kill times (t_kill) into account though so the resulting curve became somewhat translated giving lower times a higher probability (1 in 12 for 2:06 instead of 2:08). I think we can be fairly confident that the shape of the curve is correct at least. A good final step might be to collect some data from real runs to verify that the distribution matches reality.

Code: [Select]
#include <iostream>
#include <cstdlib>
#include <time.h>
#include <unordered_map>

class Skedar
{
public:
Skedar(bool canClone) : mTimeout(100), mDoor(70), mCanClone(canClone), mIsCloned(false), mIsUncloaked(false), mIsDead(false) {}

void Update()
{
mTimeout--;

if ((mTimeout == 0) || ((std::rand() & 0xFF) == 0))
{
if (!mIsCloned && !mIsUncloaked)
{
if (mCanClone)
{
Clone();
}
else
{
Uncloak();
}
}

mTimeout = 100;
}

if (mIsCloned && (mDoor > 0))
{
mDoor--;
}
}

void Clone()
{
mIsCloned = true;
mCanClone = false;
}

void Uncloak()
{
mIsUncloaked = true;
}

void Kill()
{
if (mIsCloned)
{
mIsCloned = false;
}
else
{
mIsDead = true;
}
}

bool ReachedDoor()
{
return (mDoor == 0);
}

bool IsUncloaked()
{
return mIsUncloaked;
}

bool IsCloned()
{
return mIsCloned;
}

bool IsDead()
{
return mIsDead;
}

private:
int mTimeout;
int mDoor;

bool mCanClone;
bool mIsCloned;
bool mIsUncloaked;
bool mIsDead;
};

class State
{
public:
State() : mCycle(0), mTravel(28), mLeftSkedar(false), mRightSkedar(true) {}

void Update()
{
mCycle++;

if (!mRightSkedar.IsDead())
{
mRightSkedar.Update();

if (!mLeftSkedar.IsDead())
{
mLeftSkedar.Update();

if (mLeftSkedar.IsUncloaked())
{
mLeftSkedar.Kill();
}
}
else if (mTravel > 0)
{
mTravel--;
}
else if (mRightSkedar.ReachedDoor())
{
if (mRightSkedar.IsCloned() || mRightSkedar.IsUncloaked())
{
mRightSkedar.Kill();
}
}
}
}

bool IsDone()
{
return (mLeftSkedar.IsDead() && mRightSkedar.IsDead());
}

double GetTime()
{
return (94.65 + 23.53 + ((mCycle * 3) / 60.0) + 1.0);
}

int GetCycle()
{
return mCycle;
}

private:
int mCycle;
int mTravel;

Skedar mLeftSkedar;
Skedar mRightSkedar;
};

class Distribution
{
public:
void Add(double time)
{
mOccurrences[(int)time]++;
}

void Dump()
{
int total = 0;

for (int i = 0; i < 300; i++)
{
total += mOccurrences[i];

std::cout << total << ";";
}
}


private:
std::unordered_map<int, int> mOccurrences;
};

void main()
{
std::srand(time(NULL));

Distribution distribution;

for (int i = 0; i < 10000; i++)
{
State state;

while (!state.IsDone())
{
state.Update();
}

distribution.Add(state.GetCycle());
}

distribution.Dump();

std::getchar();
}

Botched Movie Quotes

  • Posts: 4407
  • Frankly, my dear, I don't care
    • Karl
    • GE
    • PD
    • twitch
Are all these tested using 60fps? What does n64 run at that point and how does the frame rate affect the cycle rate/odds.
*Creator of 'waiting half a sec more cutscene' on b2 agent*
*Creator of 'bounce boost' on streets agent*
*Creator of 'strafe change laser skip' on inves*

Whiteted

  • Posts: 79
    • GE
    • PD
Nice :) I ran it for 1M trials and the shape is identical down to the near linear sections. If I have time this weekend I'll do a bit of thinking and maybe poking of my program to see if I can work out what causes each of them. The t_kill value is pretty critical and I really don't know how to set it: I was thinking it might be worth setting it differently for the different kills, as with Skedar #2 the door cracks so it's not really a reaction, and for Skedar #3 a lot of the time it will spawn at the 5s timeout, so I think we see in Boss' 2:08 he pre-empts the spawn. Skedar #1's t_kill is less important.

I'm still not clear when does the Skedar become vulnerable? Is it at the end of it's decloaking animation or the start?

If we could get people to give us whole sessions where they finish a large portion of runs then that would be pretty handy: We could get some ideas on the distribution of starts, decide what to do with t_kill and check the ending model matches reality. If things go wrong in the start do they go wrong early on or near the end?

Whiteted

  • Posts: 79
    • GE
    • PD
I've been assuming 20fps in terms of frames that spawns are made on, which comes from Henrik's post.

Are those 100 byte checks taking place in 5 seconds?  Is there no time limit at all, and the game will release the Skedar after 100 checks?

The logic goes something like this:
Code: [Select]
start_timer()
while((timer < 5 seconds) AND (random_byte() > 0))
{
    sleep_for_a_few_frames()
}
uncloak()

So there is a time limit of 5 seconds. The ~100 byte checks is just the result of ((5 seconds * 60 frames per second) / ~3 frames per check) = ~100. If you for example had low lag and there was ~1 frame per check, you'd have ~300 byte checks.

And those checks can take place any time, randomly, between 1 and 4 frames apart or something?

Yeah.


 Intuitively halving this should roughly half your chances of very fast times, since the main part when you want luck is an early Skedar #2 spawn. Thinking about it now creating lag after arriving at the right door might be a worthwhile tactic, because you don't want Skedar #3 to reset their timer until you kill Skedar #2. Now that would be a swag strat.

mw

  • Moderator
  • Posts: 194
    • GE
    • PD
    • twitch
Do these calculations take into account differences between PAL and English/Japanese? I know that PAL runs at a slower framerate, but does its clock that determines RNG also work at a different speed? I'd also be interested in knowing how an NTSC -> PAL converter would affect these numbers, if at all.
« Last Edit: April 29, 2018, 02:54:08 PM by mw »
PD Proof Moderator

Wyst3r

  • Posts: 4139
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
I mentioned this in the facts topic:

Quote
Also worth mentioning is that the number of iterations per second seems to be the same for PAL and NTSC (and JAP), despite the differences in system frequency.