Recent Posts

Pages: [1] 2 3 4 5 ... 10
GoldenEye 007 / Re: Best Eliter Twitch Quotes
« Last post by Elite Top 5s on Today at 06:09:49 pm »
Perfect Dark / Re: PD Strategy Discussion Topic
« Last post by Whiteted on Today at 04:00:28 pm »
Maian SOS : single guard lure

First up (and something that can be used straight away once the timing is worked out) is pause buffering the far door as described in my facts thread post, and shown kinda poorly here (read the description)

But the big save will be if we can pull pace like this off:
I came up with the idea midway through testing my psy-strat out (get psychosis gun at a time loss of just over 1s, get a guard to warp and turn them back around to open the near door), so ignore the start.

The full idea is:
  • Start like Karl's 152.
  • Take a line closer to parallel with the glass, to fire the 8th shot by the wall as late as we possibly can, so as to lure only the 2nd guard.
  • Pace to the door, to get it open and alert the guards, generating lag.
  • The lured guard loads, takes a long 'jump' close to the other guard, who then gets in the way of their new target (the other side of the lab door). This delays them enough to unload before they open the door.
  • The guard keeps it's higher speed from when it was loaded, and goes like the clappers.

But the big issue is getting the lured guard stuck on the other. We need lag otherwise the guard just turns and misses him. If he opens the door then all is really lost, because rather than unloading with high speed he unloads with extremely low speed. He can also do a little triangular loop inside the lab sometimes, which usually leads to him opening the door and going extremely slowly again. Even reproducing it in emu isn't easy. Examples: (the very slow guard luretm) (probably the fastest current strat, showing the triangle) (doing the triangle but still being fast)

Alternatively there may be some wizardry in the way I alert the other guard afterwards in that video, since I've not tried that again yet. It certainly looks like the first-lured guard teleports back to his pad, but that may be a hiccup in the PD map (it is brilliant but it is also a bit buggy).
Perfect Dark / Re: The Perfect Dark Facts Topic
« Last post by Whiteted on Today at 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:
And no pause buffering with various setups is here:

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
Perfect Dark / Re: The Perfect Dark Facts Topic
« Last post by Whiteted on Today at 12:55:47 pm »
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.
Perfect Dark / Re: The Perfect Dark Facts Topic
« Last post by Wyst3r on Today at 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.
Perfect Dark / Re: The Perfect Dark Facts Topic
« Last post by Whiteted on Today at 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

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:
General Chat / Re: Post The Bands / Artists You Have Seen Live!
« Last post by Slugg Christ on Today at 07:51:58 am »
Tyler, The Creator (7/10)
The Internet (7/10)
The Tradgically Hip (9.5/10)
Snoop Doggy Dog (6/10)
Insane Clown Posse  :rollin: :rollin: :rollin: (1/10)
Joji (9/10)
Jazz Cartier (6.5/10)
Solange (2/10)
Imagine Dragons (2.5/10)
Marshmallow (6.5/10)
Russ (7/10)
Foster the people (6/10)
Cage the elephant (9/10)
The Shins (6/10)
Flume (4/10)
Danny Brown (8.5/10)
Rag 'n' bone man (7/10)
Frank Ocean (8/10)

GoldenEye 007 / Re: Best Eliter Twitch Quotes
« Last post by Selenium Webdriver on Today at 07:09:54 am »
(made by Glover and posted on Discord)

GoldenEye 007 / Re: Post New WR's here
« Last post by mw on Today at 12:24:20 am »
Jimbo Cradle Agent 0:33

(He asked me to do it for him)
GoldenEye 007 / Re: Best Eliter Twitch Quotes
« Last post by MrSanguineous on Yesterday at 09:36:34 pm »
Pages: [1] 2 3 4 5 ... 10