Author Topic: The Perfect Dark Facts Topic  (Read 7898 times)

Icy

  • Posts: 1907
    • GE
    • PD
    • twitch
    • 2014SilverStar
    • 2015SilverStar
Re: The Perfect Dark Facts Topic
« Reply #50 on: August 27, 2016, 04:10:13 pm »
Awesome Henrik! Thanks for all your hard work with this!

Some small Qs for doing some analysis with this: How long into the 23.33s does Elvis open the door (from which we "time" our endings), and is he consistent?

And to make sure I'm understanding this right, the clone takes his 3.3s to open the door, and during that time is 3.3 seconds of the 5 second cycle for the uncloaking of the original (the one we need to kill)? In that case assuming that the RNG does not trigger the uncloaking (much more common than to do so), he would take at most 1.7s to uncloak? That's actually not too bad.

Wyst3r

  • Posts: 4164
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
Re: The Perfect Dark Facts Topic
« Reply #51 on: August 27, 2016, 04:20:20 pm »
Quote
Some small Qs for doing some analysis with this: How long into the 23.33s does Elvis open the door (from which we "time" our endings), and is he consistent?

He's teleported to that room halfway into the 23.33 seconds, so 11.66 seconds. Add 1-2 seconds to that to get the actual time. Given what we now know though, we should probably scrap the Elvis door timing and use the death of the last bridge skedar instead. While i don't think Elvis is inconsistent, there's always a chance he might be?

Quote
And to make sure I'm understanding this right, the clone takes his 3.3s to open the door, and during that time is 3.3 seconds of the 5 second cycle for the uncloaking of the original (the one we need to kill)?

Yup.

Quote
In that case assuming that the RNG does not trigger the uncloaking (much more common than to do so), he would take at most 1.7s to uncloak? That's actually not too bad.

In theory, yes. Though more testing to confirm this is probably necessary.

Luke

  • Posts: 6445
  • Zero-Time P.O.M.
    • Luke
    • GE
    • PD
    • twitch
Re: The Perfect Dark Facts Topic
« Reply #52 on: August 27, 2016, 08:50:17 pm »
for the layman, could someone please translate above into simply what % odds there are for a chuya ending?
LAS

#TeamLevelRotation

Icy

  • Posts: 1907
    • GE
    • PD
    • twitch
    • 2014SilverStar
    • 2015SilverStar
Re: The Perfect Dark Facts Topic
« Reply #53 on: August 28, 2016, 01:05:47 am »
Edit: The probability calculations, assumptions, and approximations are a giant mess; disregard.
« Last Edit: August 28, 2016, 08:50:06 am by Icy »

Wyst3r

  • Posts: 4164
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
Re: The Perfect Dark Facts Topic
« Reply #54 on: August 28, 2016, 05:31:57 am »
Quote
-It takes 12.9s from Elvis opening the door to the beginning of Skedar spawning

It's the other way around no? 12.9 secs before he opens the door, then around 10.3 until spawning starts. Assuming this 1.3 secs from teleport -> door opening is correct.

Edit: A few quick tests showed that Elvis is actually pretty inconsistent. I got door openings ranging from 12.18 - 12.60 seconds. There's no way we can use this for reliable timings...
« Last Edit: August 28, 2016, 05:47:28 am by Wyst3r »

Icy

  • Posts: 1907
    • GE
    • PD
    • twitch
    • 2014SilverStar
    • 2015SilverStar
Re: The Perfect Dark Facts Topic
« Reply #55 on: August 28, 2016, 08:52:13 am »
Ahh that sucks. On top, I realized this morning I made a major calculation error by assuming cycle resets always give the worst possibility, rather than using all the possibilities. :nesquik:

I don't think there's really any way to get nice estimates as we could for the FR or Frigate hostages unfortunately.

Azarokkusu

  • Posts: 3
    • twitch
Re: The Perfect Dark Facts Topic
« Reply #56 on: June 02, 2017, 11:49:43 am »
Same deal as with GE etc...

G5 Building: "Instant Obj 1 Complete" Glitch

I figured it was time to de-mystify this glitch once and for all. When watching Speedruntrainer's vid yesterday, I was pretty sure this glitch had something to do with the default position of the camspy, i.e. it's position values given during level-load, before it's actually been used for the first time. If this position was somehow set to a location within the trigger zone for the cinema, the glitch would probably the triggered. After some memory searching i found the position values for the camspy and decided to try and force them to a value inside the trigger zone for the obj 1 cinema. Indeed i got the same results as in videos of this glitch.

However, when looking at the default position when starting the level i noticed that it was actually a position in the very beginning of the level, nowhere near the cinema trigger zone. I wasn't sure how this value could possibly be changed, or what action might cause it to change. It turns out that it's actually changed automatically every time you reset the level. Each default position also corresponds to a different "preset". What's a preset you ask? It's a pre-determined position within a level. The PD version of Goldeneye Setup Editor shows where each of these are located. When i looked at the list of presets in the editor, i noticed that the order was identical to the pattern i was getting when i kept reseting the level over and over. I.e. every reset incremented the index in this list by 1. After some more memory searching i managed to find this index value as well.

So the theory behind the glitch is this:

1. Every time you start the level, the camspy's gets a default position based on the current index in the preset-list. During the level-load, the index gets incremented by 1 (it's starting value from power-on is 0).
2. If the default position happens to be within the trigger-zone for the cinema, the glitch happens.

There are 7 presets located within the trigger zone, with the following index values:

#133
#149
#226
#227
#228
#229
#230

You can see where they are located here (they're the blue cubes/rectangles):



So if you reset 132 times, you get the glitch. If you reset another 16 times, you get the glitch again. Then after 225 resets you get it 5 times in a row. Since the index is 1 byte, it resets after 255, going back to 0. So eventually you'll get the glitch again if you keep reseting.

The index value is not unique to G5 Building. It's shared by all levels where you start out with a camspy/drugspy (and it doesn't matter which difficulty you play on). I.e. Investigation, G5, Air Base and probably MBR (i don't have this level unlocked on my emulator file, so i couldn't check it). The way default positions for camspy works is also the same for all these levels, although G5 is the only level that has a camspy trigger zone that can cause a glitch (as far as i know).

So instead of playing G5 132 times, you can play Air Base PA 15 times, Investigation SA 117 times, then play G5 A/SA/PA and you'll get the glitch.

Hope this clears things up  :)

Links to other posts:

Escape: Alien medpack: http://forums.the-elite.net/index.php?topic=19067.msg395238#msg395238
Deep Sea; Cinema glitch: http://forums.the-elite.net/index.php?topic=19067.msg395689#msg395689
Attack Ship: Ending: http://forums.the-elite.net/index.php?topic=19067.msg439221#msg439221

I know this thread is a tad old now but, the memory address for number of levels loaded (the index value mentioned in the OP) is, as far as I can tell, 0x623A3, in case anyone wants to do anything with that ever. Though, I imagine most stuff has already been done at this point. I might actually explore the addresses for more stuff in the game and make a thread at some point if someone hasn't already done an address dump somewhere.

edit: nope, it doesn't seem to  be consistent, maybe it tracks it for each level and uses the total, or just increments for levels that use the index, or something? I'll have to investigate more eventually. I suspect the latter, only increments for levels that use the index, though it's interesting how much less... pseudo-random it makes things.
« Last Edit: June 02, 2017, 12:06:02 pm by Azarokkusu »

Botched Movie Quotes

  • Posts: 4422
  • Frankly, my dear, I don't care
    • Karl
    • GE
    • PD
    • twitch
Re: The Perfect Dark Facts Topic
« Reply #57 on: November 08, 2017, 01:34:06 am »
for the layman, could someone please translate above into simply what % odds there are for a chuya ending?

this was never answered, pls help?
*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*

--

  • Posts: 19353
  • I'll be the backboost starring in your bad dreams
    • Goose
    • GE
    • PD
    • twitch
    • 2014CommunityContributor
    • http://www.twitch.tv/rwhitegoose
Re: The Perfect Dark Facts Topic
« Reply #58 on: April 04, 2018, 04:30:41 am »
https://drive.google.com/file/d/0B_qzrv1WjgSsSXJHbGhLRGczd1E/view

Can I get this chart deciphered for 392 rupees please?

Does this mean that there is a small chance the Skedars will activate on the first 100 frames, and if not, then they'll 100% activate on the 101st frame?
~ S T A Y ❄ T R U E ~   |   ~ S T A Y ❄ B L E S S E D ~   |   Verax Maneret

Icy

  • Posts: 1907
    • GE
    • PD
    • twitch
    • 2014SilverStar
    • 2015SilverStar
Re: The Perfect Dark Facts Topic
« Reply #59 on: April 04, 2018, 08:03:57 am »
That's not frames, it's cycles of when the script is checked, which is usually 2-4 frames depending on lag and other factors. I'd suggest not using that as Henrik said the level is not smooth enough where simple math is precise in timing the ending.

--

  • Posts: 19353
  • I'll be the backboost starring in your bad dreams
    • Goose
    • GE
    • PD
    • twitch
    • 2014CommunityContributor
    • http://www.twitch.tv/rwhitegoose
Re: The Perfect Dark Facts Topic
« Reply #60 on: April 04, 2018, 10:40:17 am »
I need to simplify it enough for a Youtube audience when talking about "the odds of Chuya getting the 19 second ending."

Perhaps we can chat on Discord about this sometime soon.
~ S T A Y ❄ T R U E ~   |   ~ S T A Y ❄ B L E S S E D ~   |   Verax Maneret

Boss

  • Posts: 3977
    • GE
    • PD
    • twitch
Re: The Perfect Dark Facts Topic
« Reply #61 on: April 06, 2018, 10:13:32 pm »
Hey Henrik, could you look into how the programmer moves around when unloaded on Defection PA, particularly after he goes up the lift and before the uplink part? Does the pratrolling guard affect how fast he is when unloaded in any way on some runs? Does it matter how fast you go around Cass' office or any part after that? It's really a critical part now with the programmer running strat in place. For some reason I can't seem to get fast programmers if I just close the lift directly on him. My fastest programmers are when I get ahead of him a few sec before the lift closes (these are even still 2-3s slower than just following him and keeping him loaded also). It would be greatly appreciated.
« Last Edit: April 06, 2018, 10:19:48 pm by Boss »

Wyst3r

  • Posts: 4164
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
Re: The Perfect Dark Facts Topic
« Reply #62 on: April 07, 2018, 10:53:51 am »
The patrolling guard is definately a big factor when it comes to programmer speed upstairs. They pretty much always compete for space in the long stretch before the uplink room, which can lose you alot (since he becomes loaded basically have to walk the same distance twice). I'm pretty sure that closing the lift loses time for you because it makes the programmer faster which makes him bump into the patrolling guard at a worse time.

Fortunately it's really easy to fix this. I'd say there are two options:
1. Step into the elevator quickly just after skipping the last programmer message, to let the patrollilng guard see you (and then close the lift on the programmer).
2. Delay the patrolling guard by opening the door on the floor above as you walk up the stairs. This will load him (since he's standing right outside) and make him rewalk the fairly long segment outside the lifts. You might need to wait a sec or two before opening the door though, but waiting to close the lift manually might do that anyway.

With option 2, the programmer will be slightly ahead of the patrolling guard. As long as he's ahead you shouldn't lose time, but it's close enough that I can't guarantee he'll win the race. I'd say go for option 1, since that removes the patrolling guard completely.

After alot of experimenting with Cass office, I think I found a good method to speed him up. The idea is to keep him loaded for a bit longer after leaving Cass' office by staring at the floor below for a few secs. Once he gets around the corner into the long corridor, he will create a very long segment leading all the way into the uplink room. He will only do this if he remained loaded for long enough to get around the corner though, otherwise he will create a bunch of shorter segments to get there, which is slower. You should be able to leave at around ~41 secs (Assuming you have enough time to get to the uplink in time). The best programmer I've managed to get is 54 (several times though). High 53 might be possible but I doubt it can go any lower than that.

« Last Edit: April 07, 2018, 11:29:04 am by Wyst3r »

mw

  • Moderator
  • Posts: 240
    • GE
    • PD
    • twitch
Re: The Perfect Dark Facts Topic
« Reply #63 on: July 22, 2018, 09:16:17 pm »
Because of how the scripts are written, if you shoot the president on Air Force One after the special cutscene plays, Objective 1 instantly completes. (Although, because he has 0 hit points until a certain point, he instantly dies.)
PD Proof Moderator

Whiteted

  • Posts: 126
  • AF1 51 or bust
    • GE
    • PD
Re: The Perfect Dark Facts Topic
« Reply #64 on: November 18, 2018, 09:58:15 am »
Lifts, logic & Lag
Disclaimer: all of this is based on the final lift in Maian SOS on NTSC, but should hold generally. I was going to check PAL but I need to unlock my emu cart by playing through SA it seems.

Key points:
  • Lag during the actual up/down motion of lifts (elevators) between floors has very little effect, and stable background lag will have a net effect of 0 (needs checking)
  • Counter-intuitively, high background lag while the doors are unloaded will likely speed up the door opening and closing a little. It can speed it up a lot, or probably slow it a little, depending on """luck""":
  • The effect of lag is only random in the sense that the 'unloaded' doors update infrequently. Depending on how these updates coincide with the lift arriving at the floor, and with the "stay open" timer expiring, determines how much time the lag saves. Lag only has a bad effect in making the doors 'overshoot' closing/opening, wasting time. Lag accelerates the doors faster, and may skip the deceleration.
  • Loaded lift doors might be manipulate-able by a big lag spike.
  • Neither doors nor elevators can be zoomed in the sense that their max speed cannot be exceeded
By background lag I mean consistent lag, rather than lag spikes.


Lift components & updates & movement
Lifts consist of the actual box which moves up and down (the lift) and the sets of doors. These are very separate. Crucially the elevator always updates regularly (20Hz), whereas when 'unloaded', the lift doors update irregularly. The final lift on Maian SOS updates around 5 times a second in low lag while unloaded. Interestingly gaps between updates alternate between larger and smaller.

The movement of both is from 0 to a max speed (which is respected unlike with hoverbots), with constant acceleration. However like described by VHGS, the speed is updated first, and then this (terminal) speed is used for the movement step. e.g. suppose:
    6 ticks (1/60ths of a second) have passed since the last update, and our lift updates.
    the speed is 0 and it wants to start moving.
    the acceleration is 2.
Then the speed is calculated as 0 + 2*6 = 12. Then the distance to move is calculated as 12 * 6 = 72. This is 'wrong' since it should have used the average speed, 6.

Both decelerate smoothly as they finish. Lift doors in particular really slow up as they finish, but not when updating irregularly it seems. My theory is that during deceleration the initial speed is used rather than the final speed, but it needs testing.


Logic when the lift is stationary
The most interesting bit is the doors. The order of events is this:
  • The doors update, staying shut.
  • Lift arrives, and sets a flag in the doors.
  • The doors update again (not triggered by step 2, just periodicly)
    They move as described above, using t = current_time - prev_update_time. Again this is 'wrong' since the lift may have raised the flags only 2 ticks ago, whereas the doors could have updated more than 0.5s ago. As such, expect lag here to directly save time
  • The doors move, updating only a couple of times to reach fully open. The end of this needs a bit more looking into, as lag can cause it to overshoot, wasting time, but may also cause it to skip the deceleration, saving some time.
  • The doors are fully open, and a timer is started (properly; it is 0 when the doors have just opened)
  • The time passes.. (5s for the final lift on main)
  • The door updates. But again movement is based on the previous update, so effectively the timer will be less than 5s. Lag saves time again.
  • The doors close, again skipping acceleration and potentially overshooting. Flags are updated in the doors' memory
  • Lift sees those flags, starts moving

Conclusions!
Consistent, slightly-slow lifts should be easy enough where we can keep lag low during opening & closing.
Fast lifts will be trickier, and rely on """chance""", but we can actually give ourselves a look in by focusing on raising lag during opening / closing. If lag is low there is no chance of good manipulations. The timing of this lag doesn't need to be too precise which is nice.

But what use is a faster lift if we can't get to it in time?  :thinking:

Wyst3r

  • Posts: 4164
  • Train Strat Master
    • Henrik
    • GE
    • PD
    • twitch
Re: The Perfect Dark Facts Topic
« Reply #65 on: November 18, 2018, 11:44:14 am »
Disclaimer: all of this is based on the final lift in Maian SOS on NTSC, but should hold generally. I was going to check PAL but I need to unlock my emu cart by playing through SA it seems.

You can unlock every level by poking some regions in memory:

0x800A2220 - NTSC
0x800A27C0 - PAL

(You can also find these by searching for a value of 0x3AAEEFF1, which occurs three words before the region)

Two bytes per star, so just fill it up with 0xFF's.

Whiteted

  • Posts: 126
  • AF1 51 or bust
    • GE
    • PD
Re: The Perfect Dark Facts Topic
« Reply #66 on: November 18, 2018, 12:55:47 pm »
Quote
You can unlock every level by poking some regions in memory:

0x800A2220 - NTSC
0x800A27C0 - PAL

Godsend :) thanks Henrik. I used the setup editor for NTSC but it doesn't like PAL unfortunately.

Whiteted

  • Posts: 126
  • AF1 51 or bust
    • GE
    • PD
Re: The Perfect Dark Facts Topic
« Reply #67 on: November 18, 2018, 02:17:39 pm »
Maian SOS facts

I thought it best to separate the facts out, and add a few relevant general facts + a bit of AF1 too:
  • There is no pad between the two doors that the lured guards open & we shoot through. As such guards can't warp the first door and then open the second. The closest to this is psychosis-ing the warped guard to head back and open the near door from our side ("psy-strat", probably not viable).
  • The 'room' around the pad on the guard's side (pad #0121) is loaded when we cross the back of the yellow & black line in the main corridor, pictured here. This confirms Karl's idea (from his tutorial) that how fast you get there is important. Specifically, if we are relying on the speed of an unloaded guard, we want to cross the line before they begin their 'segment' to this pad (early, probably ~ the pace of Karl's 152 when using that strat), or just after they arrive at it (much later). The previous pad in the path is surely still unloaded, but I haven't actually checked.
  • Pause buffering makes the guards open the first door fast much more consistently. Once it's open they still seem to loiter for a second.
  • Guards between the pair of doors update regularly (see below) when the player is in the start of the long room (boundary pictured in cyan), which saves pause buffering. But the guards don't have much trouble with the near door so this is a small time saver at best.
The last two are demonstrating here: https://youtu.be/hum5o4MfluU
And no pause buffering with various setups is here: https://www.youtube.com/watch?v=mH4iNEs2LB8

PD gems
General ideas which this brings up:
  • Guards (and most objects which move*) update their position irregularly when they are "far away". The precise condition for when guards update regularly isn't quite clear to me, but it is definitely relating to 'rooms'. On AF1 I thought it was:
       "Am I in a room which neighbours one that is partially visible to the player" (with this visibility ignoring doors)
    Because 'rooms' can be very small, the guard doesn't always need to be far away, or unloaded.
  • When we pause, guards update their position in the pause (unless they've just updated it).
  • Rooms (and guards) seem to load / unload based solely on the room that the player is in, rather than where they look. I'm assuming these rooms to load have been hard-coded by a developer who has thought about which rooms are visible from where. As a result, we may be able to watch a guard warping a door (you can almost see the guard warp when standing on the yellow & black line described above).

Guard scripts also run irregularly when you are 'far away', and can be manipulated using pauses but only to run a certain amount of time after the pause. Irregularly can mean less often that once a second under heavy lag.

A big use which I see for this is making unloaded guards finish their segments cleanly. When unloaded guards overshoot their target pad, however much they overshot by is just forgotten. If you pause buffer around the end of a segment this won't happen. Unfortunately we can't afford to do that much, but I'm planning a few for AF1 (where the combat boost vastly supresses the waste at the end of a segment, but also makes it identical every single run: just over 0.5s is wasted).

* noteable exceptions are hoverbot and lifts