Alone in the Dark (1992 DOS)

tigrou

Edit history:

tigrou: 2016-05-15 03:38:37 am

tigrou: 2016-05-15 03:38:25 am

tigrou: 2016-05-15 03:37:04 am

tigrou: 2016-05-15 03:36:38 am

tigrou: 2016-05-15 03:35:58 am

tigrou: 2016-05-15 03:35:29 am

tigrou: 2016-05-15 03:35:13 am

tigrou: 2016-05-15 03:34:59 am

tigrou: 2016-05-03 01:29:07 am

tigrou: 2016-05-03 01:27:42 am

tigrou: 2016-05-03 01:26:47 am

tigrou: 2016-05-03 01:26:34 am

tigrou: 2016-05-03 01:25:19 am

tigrou: 2016-05-03 01:24:52 am

tigrou: 2016-05-03 01:24:03 am

tigrou: 2016-05-03 01:23:22 am

tigrou: 2016-05-03 01:22:43 am

tigrou: 2016-05-03 01:22:09 am

tigrou: 2016-05-03 01:20:38 am

tigrou: 2016-05-03 01:20:03 am

tigrou: 2016-05-03 01:19:31 am

tigrou: 2016-02-26 12:17:25 pm

tigrou: 2016-02-26 12:17:06 pm

tigrou: 2016-02-26 12:16:25 pm

tigrou: 2016-02-26 12:09:07 pm

tigrou: 2016-02-26 12:00:27 pm

tigrou: 2016-02-26 11:59:09 am

tigrou: 2016-02-26 11:58:51 am

tigrou: 2016-02-26 11:58:37 am

2016-02-26 11:57:52 am

Thanks all for your hard work. I'm impressed. Here is some answers related to LotBlind post :

Quote:

... the library door ... it's clearly the only one that juts out when closed.

Unfortunately, I don't understand the last part of the sentence :S

Quote:

I can't get the bird to follow me outside the room. Must have been programmed to stay inside it.

Well it did not happen to me, he follows me everywhere I go. Could you maybe make a video of this ?

Quote:

on its N side, you'll get stuck on something that's right outside the window

That remark forced me to take a look at the game internals again and i discovered something :

If you remember, on 29/01 you told me there was some green boxes which has same place as colliders and that flickers. I thought it was a bug and choose to hide them in the viewer.

Actually its not a bug. It has really a use in the game. These green boxes are actors which does not have a 3d model attached to them (and are thus invisible in the game). Their only purpose (since they are invisible) is to attach them a script to apply some logic for the room. It is useful for applying logic to colliders or a triggers because they cannot be associated to a script, only actors can.

Some examples :
=> In the attic, on the piano collider, there is a green actor (it fully covers it). It checks if player has collided with the piano and then apply some logic (eg : give you jeremie script or say "nothing found here").

=> In the library, the wall collider with ID = 0 has also an actor on it. It is used to play random horror sounds (the one you hear sometimes in the mansion). Since that sounds must be played in lot of rooms that explain why that actor is active even when you are outside the library (as you reported).

=> In E2R3 there is a green box on the hearth. It manages logic for the whole room : collision with several colliders and it also allows to take the notes and it triggers the zombie chicken.
What is the role of the actor near the window in E2R3 ? To be honest I don't know. It has no script attached and no 3d model. Maybe it is placeholder to know where to summon the zombie chicken.

Here is the full piano script. I know you two guys are (probably) not programmers, but this is actually quite high level and not that hard to understand. I have put comments on the right side :

Code:

 0: IF COLLIDER == 1                   //is player touching piano?
12:     IF ANIM == 2                   //is player searching ?
24:         IF END_ANIM == 1
36:             IF POSREL(PLAYER) == 4 //is player at right side of piano?
48:                 SAMPLE 3           //play lock sound
54:                 IF OBJECT(15) == 0 //check that player does not have Jeremie letter
66:                     FOUND 15       //give Jeremie letter
70:                     GOTO 78
                    END
74:                 MESSAGE 100        //display "Nothing important!"
78:                 GOTO 86
                END
82:             MESSAGE 102            //display "Nothing here!"
            END
        END
    END
86: ENDLIFE

There is about 500 script like that in the game, each having a different purpose.
I modified the viewer in order to always display actors, even if they have no 3d model attached to them. Now you should understand why you get stuck by that invisible collider near E2R3. I also added more info when an actor is highlighted. Note : 3D models are called BODY in the AITD. Same for scripts which are called LIFE (because of the LIFE Engine). I also added two new keys : J and K. It allows to display/hide walls or actors. It is useful for viewing boxes when some are nested together.

Thanks all for your hard work. I'm impressed. Here is some answers related to LotBlind post :

[quote]... the library door ... it's clearly the only one that juts out when closed.[/quote]
Unfortunately, I don't understand the last part of the sentence :S

[quote]I can't get the bird to follow me outside the room. Must have been programmed to stay inside it. [/quote]
Well it did not happen to me, he follows me everywhere I go. Could you maybe make a video of this ?

[quote]on its N side, you'll get stuck on something that's right outside the window [/quote]
That remark forced me to take a look at the game internals again and i discovered something :

If you remember, on 29/01 you told me there was some green boxes which has same place as colliders and that flickers. I thought it was a bug and choose to hide them in the viewer.

Actually its not a bug. It has really a use in the game. These green boxes are actors which does not have a 3d model attached to them (and are thus invisible in the game). Their only purpose (since they are invisible) is to attach them a script to apply some logic for the room.  It is useful for applying logic to colliders or a triggers because they cannot be associated to a script, only actors can.

Some examples : 
=> In the attic, on the piano collider, there is a green actor (it fully covers it). It checks if player has collided with the piano and then apply some logic (eg : give you jeremie script or say "nothing found here").

=> In the library, the wall collider with ID = 0 has also an actor on it. It is used to play random horror sounds (the one you hear sometimes in the mansion). Since that sounds must be played in lot of rooms that explain why that actor is active even when you are outside the library (as you reported).

=> In E2R3 there is a green box on the hearth. It manages logic for the whole room : collision with several colliders and it also allows to take the notes and it triggers the zombie chicken.
What is the role of the actor near the window in E2R3 ? To be honest I don't know. It has no script attached and no 3d model. Maybe it is placeholder to know where to summon the zombie chicken.

Here is the full piano script. I know you two guys are (probably) not programmers, but this is actually quite high level and not that hard to understand. I have put comments on the right side :

[hidden][code] 0: IF COLLIDER == 1                   //is player touching piano?
12:     IF ANIM == 2                   //is player searching ?
24:         IF END_ANIM == 1
36:             IF POSREL(PLAYER) == 4 //is player at right side of piano?
48:                 SAMPLE 3           //play lock sound
54:                 IF OBJECT(15) == 0 //check that player does not have Jeremie letter
66:                     FOUND 15       //give Jeremie letter
70:                     GOTO 78
                    END
74:                 MESSAGE 100        //display "Nothing important!"
78:                 GOTO 86
                END
82:             MESSAGE 102            //display "Nothing here!"
            END
        END
    END
86: ENDLIFE[/code][/hidden]

There is about 500 script like that in the game, each having a different purpose.
I modified the viewer in order to always display actors, even if they have no 3d model  attached to them. Now you should understand why you get stuck by that invisible collider near E2R3. I also added more info when an actor is highlighted. Note : 3D models are called BODY in the AITD. Same for scripts which are called LIFE (because of the LIFE Engine). I also added two new keys  : J and K. It allows to display/hide walls or actors. It is useful for viewing boxes when some are nested together.

LotBlind

2016-02-26 12:56:18 pm

tigrou:

Quote from LotBlind:

... the library door ... it's clearly the only one that juts out when closed.

That means it's the only one that's not perfectly sunk into the wall, but visibly sticks out on the library side when closed, which is why you can get caught when running along the wall.

I think the reason why the bird (and other monsters) couldn't leave the room is because of this:
- monster pathfinding works like this: if the monster is in a different room, it will look for the trigger zone that causes it to reach the room you're in
- after it's in the same room, it will home in on you in a direct path
- if you're both in the same room, but you're OOB, it will move into any openings until it hits a trigger
- now it sees you as being in a different room, and so it turns around and re-enters the room that you're inside
- ad infinitum

This would imply the game can have different architecture loaded in for the monsters than the player... but I think that's not true. It's just that the monsters that are in a different room have been coded in a way that lets them reliably find the exit from any part of the room. Does this sound reasonable to you?

I'm not sure about this explanation myself, because the Vagabond only refused to pass through the secret door opening. When I had got it to follow me deeper OOB, it didn't mind entering the secret room loading zone from a different angle.

Video showing this happening with a zombie in the E3 kitchen.

Thanks for the viewer modifications! I'll keep reporting anything unusual...

NHG: I forgot that you could clip into the study from OOB, but I'll gladly leave that up to you to measure.

A random find: I noticed that you don't have to kill all the zombies in the dining room - E3R12 - if you have all of them aggravated and a certain one of them has to be dead. I think this is what causes the doors to unlock again. Or maybe it's waiting for long enough when the last guy is aggroed. tigrou: maybe you could look at the script for that room to see if there's some kind of shortcut? I'm not sure which zombie it is that has to die.

If you're bored just checking the scripts one by one to see if there's something interesting is a way to pass the time, right? Wink

tigrou:

[quote=LotBlind]
... the library door ... it's clearly the only one that juts out when closed.[/quote]

That means it's the only one that's not perfectly sunk into the wall, but visibly sticks out on the library side when closed, which is why you can get caught when running along the wall.

I think the reason why the bird (and other monsters) couldn't leave the room is because of this:
- monster pathfinding works like this: if the monster is in a different room, it will look for the trigger zone that causes it to reach the room you're in
- after it's in the same room, it will home in on you in a direct path
- if you're both in the same room, but you're OOB, it will move into any openings until it hits a trigger
- now it sees you as being in a different room, and so it turns around and re-enters the room that you're inside
- ad infinitum

This would imply the game can have different architecture loaded in for the monsters than the player... but I think that's not true. It's just that the monsters that are in a different room have been coded in a way that lets them reliably find the exit from any part of the room. Does this sound reasonable to you?

I'm not sure about this explanation myself, because the Vagabond only refused to pass through the secret door opening. When I had got it to follow me deeper OOB, it didn't mind entering the secret room loading zone from a different angle.

[url=https://drive.google.com/file/d/0B6VbXOZpnj6MMmcyM3o5d21rcDg/view?usp=sharing]Video[/url] showing this happening with a zombie in the E3 kitchen.

Thanks for the viewer modifications! I'll keep reporting anything unusual...

NHG: I forgot that you could clip into the study from OOB, but I'll gladly leave that up to you to measure.

A random find: I noticed that you don't have to kill all the zombies in the dining room - E3R12 - if you have all of them aggravated and a certain one of them has to be dead. I think this is what causes the doors to unlock again. Or maybe it's waiting for long enough when the last guy is aggroed. tigrou: maybe you could look at the script for that room to see if there's some kind of shortcut? I'm not sure which zombie it is that has to die.

If you're bored just checking the scripts one by one to see if there's something interesting is a way to pass the time, right? ;)

NHG

2016-02-26 01:04:39 pm

Shut up and go back to another earth

Quote from tigrou:

=> In the library, the wall collider with ID = 0 has also an actor on it. It is used to play random horror sounds (the one you hear sometimes in the mansion). Since that sounds must be played in lot of rooms that explain why that actor is active even when you are outside the library (as you reported).

Useless information but I'm proud to finally learn something to someone so...: That sound is an instrument. It is called waterphone x)

tigrou

Edit history:

tigrou: 2016-02-27 01:08:09 pm

tigrou: 2016-02-26 03:13:26 pm

tigrou: 2016-02-26 03:05:47 pm

tigrou: 2016-02-26 03:05:18 pm

tigrou: 2016-02-26 03:05:09 pm

tigrou: 2016-02-26 03:04:53 pm

tigrou: 2016-02-26 02:02:12 pm

2016-02-26 01:56:32 pm

@NHG : Thanks for the info , i know lot of instruments (including the theremin) but not that one ! I'd like to help you about your post related to angles but I did not understand anything Sad

@LotBlind : I already check the important ones (eg : the one that open main mansion door, or the one that is used for the boss) but i did not find anything special

AITD - the hidden scenes
(No offense intended, just some stupid joke)

what really happened that night

LotBlind

Edit history:

LotBlind: 2016-02-27 12:38:43 pm

LotBlind: 2016-02-27 12:37:38 pm

2016-02-27 12:35:39 pm

NHG: I didn't know the name of the instrument either. Cheesy

BTW, In English, you say "teach" someone something.

tigrou: He means that to get the PC to clip, you need to face walls at certain angles. There's a range of angles that works. The range is about 16° to 24° (but he says those are not exact) on both sides of the wall's tangent. When your angle is closer to the tangent, the "clip steps" are smaller, i.e. every step takes you a little bit to the side. When you're further away from it, the steps will be bigger but less frequent. In-between we have a sweet spot, the optimal angle to be facing to travel at maximum speed. What NHG is saying (and I can confirm) is that there seem to be discrepancies between how wide the range of angles is that the clip can occur at, and that even when you face the wall at a perfectly perpendicular angle, you might still move on one side!

NHG: the angles probably depend on how far away you are from the wall. Down to the sub-pixels. tigrou: are you able to use something like Cheat Engine to test different angles to make sure it really is just a about your distance from the wall? Because that can vary even when it looks like you're as close to the wall as you can get.

NHG also says that there's steps that happen every 1 second (the big ones) and those that happen 2 times a second (i.e. on every one of your PC's footsteps) and nothing in-between. I never noticed that there wasn't anything in-between, but I can believe it, because lots of things seem to be checked once at the end of some cycle such as the running animation. He also says that even if you start taking a "baby" step, you can move outside the normal range for baby steps and still get a "baby" step (2 per second) so as to make the movement slightly more efficient, so long as you then quickly return to the large step range.

I think by "zero point" NHG means an angle that you face so you don't move at all when running into the wall. Am I right? Is it possible that the game has sub-degree angles? That means there would have to be another variable that stores them... Because we know that when you're stood still, every time you press left or right you will rotate 3°. When you walk or run it's half of that. So 1.5°. This is why I think the game actually stores half-degrees, but maybe tigrou can answer that. Anyway that would explain why you might end up moving left: you're really 0.5° short (e.g. 179.5°) of what the viewer says but it's been rounded up. I don't understand how that's possible though because then the "whole degrees" part should show you 179, not 180. Tongue

Still I wouldn't be surprised if the angles just depend on how far exactly you are from the wall.

I just looked at the picture you created: that just reminds me of something Aqfaq might have posted. Tongue

NHG: I didn't know the name of the instrument either. :D BTW, In English, you say "teach" someone something.

tigrou: He means that to get the PC to clip, you need to face walls at certain angles. There's a range of angles that works. The range is about 16° to 24° (but he says those are not exact) on both sides of the wall's tangent. When your angle is closer to the tangent, the "clip steps" are smaller, i.e. every step takes you a little bit to the side. When you're further away from it, the steps will be bigger but less frequent. In-between we have a [i]sweet spot[/i], the optimal angle to be facing to travel at maximum speed. What NHG is saying (and I can confirm) is that there seem to be discrepancies between how wide the range of angles is that the clip can occur at, and that even when you face the wall at a perfectly perpendicular angle, you might still move on one side!

NHG: the angles probably depend on how far away you are from the wall. Down to the sub-pixels. tigrou: are you able to use something like Cheat Engine to test different angles to make sure it really is just a about your distance from the wall? Because that can vary even when it looks like you're as close to the wall as you can get.

NHG also says that there's steps that happen every 1 second (the big ones) and those that happen 2 times a second (i.e. on every one of your PC's footsteps) and nothing in-between. I never noticed that there wasn't anything in-between, but I can believe it, because lots of things seem to be checked once at the end of some cycle such as the running animation. He also says that even if you start taking a "baby" step, you can move outside the normal range for baby steps and still get a "baby" step (2 per second) so as to make the movement slightly more efficient, so long as you then quickly return to the large step range.

I think by "zero point" NHG means an angle that you face so you don't move at all when running into the wall. Am I right? Is it possible that the game has sub-degree angles? That means there would have to be another variable that stores them... Because we know that when you're stood still, every time you press left or right you will rotate 3°. When you walk or run it's half of that. So 1.5°. This is why I think the game actually stores half-degrees, but maybe tigrou can answer that. Anyway that would explain why you might end up moving left: you're really 0.5° short (e.g. 179.5°) of what the viewer says but it's been rounded up. I don't understand how that's possible though because then the "whole degrees" part should show you 179, not 180. :P

Still I wouldn't be surprised if the angles just depend on how far exactly you are from the wall.

I just looked at the picture you created: that just reminds me of something Aqfaq might have posted. :P

tigrou

Edit history:

tigrou: 2016-02-28 01:39:13 am

tigrou: 2016-02-28 01:38:36 am

tigrou: 2016-02-28 01:25:56 am

tigrou: 2016-02-28 01:25:28 am

tigrou: 2016-02-28 01:24:47 am

2016-02-28 01:23:25 am

@LotBlind : I understand that part perfectly now, especially that NHG send me another explanation in PM. Thank you both for your messages.

What i discovered : when you are walking, the player don't move at a constant speed. Instead it accelerate progressively and slow down again. You can verify this easily with the room viewer : start walking in a room with "follow camera" mode enabled : you will see it does not scroll at constant speed. This acceleration/deceleration seems to be synchronized with the foot step sounds. Same when you OOB : the steps / baby steps you are talking about seems to be synchronized with the foot step sounds. It think the OOB trick only happen when player is at his maximum speed, which only happen once every walk step. As you said, within a certain angle, it change the frequency.

Something about OOB that I really don't understand :
To OOB you need two things :
1) running almost perpendicularly against a collider (eg : a door)
2) having another collider on the left or right side (eg : a wall).

One example is the door at the top of E2R1 (the gallery) as seen on the speed run.
However, if you try to do this on the same door, but from E2R4, it wont work. It is exactly the same situation as before but for some reason I can't explain, it won't OOB.

@LotBlind : I understand that part perfectly now, especially that NHG send me another explanation in PM. Thank you both for your messages.

What i discovered : when you are walking, the player don't move at a constant speed. Instead it accelerate progressively and slow down again. You can verify this easily with the room viewer : start walking in a room with "follow camera" mode enabled : you will see it does not scroll at constant speed. This acceleration/deceleration seems to be synchronized with the foot step sounds. Same when you OOB : the steps / baby steps you are talking about seems to be synchronized with the foot step sounds. It think the OOB trick only happen when player is at his maximum speed, which only happen once every walk step. As you said, within a certain angle, it change the frequency.

Something about OOB that I really don't understand : 
To OOB you need two things : 
1) running almost perpendicularly against a collider (eg : a door)
2) having another collider on the left or right side (eg : a wall).

One example is the door at the top of E2R1 (the gallery) as seen on the speed run.
However, if you try to do this on the same door, but from E2R4, it wont work. It is exactly the same situation as before but for some reason I can't explain, it won't OOB.

tigrou

Edit history:

tigrou: 2016-06-22 12:35:44 pm

tigrou: 2016-06-22 12:35:31 pm

tigrou: 2016-06-22 12:34:43 pm

tigrou: 2016-06-22 12:34:01 pm

tigrou: 2016-06-22 12:33:11 pm

tigrou: 2016-06-22 12:32:55 pm

tigrou: 2016-06-22 12:30:02 pm

tigrou: 2016-06-22 12:29:21 pm

tigrou: 2016-06-22 12:24:07 pm

tigrou: 2016-06-22 12:22:48 pm

tigrou: 2016-06-22 12:22:36 pm

tigrou: 2016-06-22 12:21:01 pm

tigrou: 2016-06-22 12:20:45 pm

tigrou: 2016-06-22 12:10:59 pm

tigrou: 2016-06-22 12:10:46 pm

tigrou: 2016-06-22 11:48:36 am

tigrou: 2016-06-22 11:48:04 am

tigrou: 2016-06-22 11:44:54 am

tigrou: 2016-06-22 11:44:41 am

tigrou: 2016-06-22 11:44:19 am

tigrou: 2016-06-22 11:44:06 am

tigrou: 2016-06-22 11:43:19 am

tigrou: 2016-06-22 11:39:51 am

tigrou: 2016-06-22 11:39:04 am

tigrou: 2016-06-22 11:38:18 am

tigrou: 2016-03-12 03:32:15 pm

tigrou: 2016-02-28 02:38:15 pm

tigrou: 2016-02-28 02:34:46 pm

tigrou: 2016-02-28 02:33:27 pm

tigrou: 2016-02-28 02:29:13 pm

tigrou: 2016-02-28 02:25:48 pm

tigrou: 2016-02-28 02:22:52 pm

tigrou: 2016-02-28 02:20:10 pm

tigrou: 2016-02-28 02:19:03 pm

tigrou: 2016-02-28 02:18:39 pm

tigrou: 2016-02-28 02:17:39 pm

tigrou: 2016-02-28 02:16:29 pm

tigrou: 2016-02-28 02:14:27 pm

tigrou: 2016-02-28 02:10:25 pm

tigrou: 2016-02-28 01:57:43 pm

tigrou: 2016-02-28 01:57:23 pm

tigrou: 2016-02-28 01:56:25 pm

tigrou: 2016-02-28 01:53:07 pm

tigrou: 2016-02-28 01:51:56 pm

tigrou: 2016-02-28 01:49:57 pm

tigrou: 2016-02-28 12:40:02 pm

tigrou: 2016-02-28 12:37:01 pm

tigrou: 2016-02-28 12:33:21 pm

tigrou: 2016-02-28 12:32:47 pm

tigrou: 2016-02-28 12:29:28 pm

tigrou: 2016-02-28 12:28:21 pm

tigrou: 2016-02-28 12:26:53 pm

tigrou: 2016-02-28 12:26:23 pm

tigrou: 2016-02-28 12:25:13 pm

tigrou: 2016-02-28 12:25:05 pm

tigrou: 2016-02-28 12:16:58 pm

tigrou: 2016-02-28 12:15:21 pm

tigrou: 2016-02-28 12:14:29 pm

tigrou: 2016-02-28 12:13:34 pm

tigrou: 2016-02-28 12:12:54 pm

tigrou: 2016-02-28 12:10:45 pm

tigrou: 2016-02-28 12:10:19 pm

tigrou: 2016-02-28 12:10:12 pm

tigrou: 2016-02-28 12:06:58 pm

tigrou: 2016-02-28 12:06:25 pm

tigrou: 2016-02-28 12:04:35 pm

tigrou: 2016-02-28 12:03:55 pm

tigrou: 2016-02-28 12:03:36 pm

tigrou: 2016-02-28 12:03:06 pm

tigrou: 2016-02-28 11:42:06 am

tigrou: 2016-02-28 11:40:04 am

tigrou: 2016-02-28 11:39:29 am

tigrou: 2016-02-28 11:37:43 am

tigrou: 2016-02-28 11:34:42 am

tigrou: 2016-02-28 11:22:38 am

tigrou: 2016-02-28 11:21:37 am

tigrou: 2016-02-28 11:20:46 am

tigrou: 2016-02-28 11:20:22 am

tigrou: 2016-02-28 11:19:31 am

tigrou: 2016-02-28 11:19:09 am

tigrou: 2016-02-28 11:13:06 am

tigrou: 2016-02-28 11:09:55 am

tigrou: 2016-02-28 11:08:30 am

tigrou: 2016-02-28 11:07:21 am

tigrou: 2016-02-28 11:04:16 am

tigrou: 2016-02-28 11:04:00 am

tigrou: 2016-02-28 11:03:54 am

tigrou: 2016-02-28 11:01:43 am

2016-02-28 10:55:34 am

Wohoo! I took a deep look at the game and finally found HOW the OOB works.
It also answers some of NHG questions. It's a bit technical but it worth reading.
With this i'm now able to predict if a OOB will happen at a given place by just look at the game walls and doors position in the viewer.

The basic algorithm for moving the player is :

1) Take current player position (white square on the picture).
2) Compute where he will be after the move (the purple square), depending the current angle and speed
3) Check if there is any collision with walls (in gray).
=> If yes, push him vertically or horizontally to avoid the collision
4) Check if there is any collision with actors (in green).
=> If yes, push him vertically or horizontally to avoid the collision
5) Move player to adjusted the position

Here is examples (based on the E2R1 gallery) :

A) First case (first column)
1: initial state
2: predicted move: no collision at all, everything is fine
3: player is moved to the next position

B) Second case :
1: Player is walking.
2: The game has predicted that he will be touching the gray wall after moving.
3: To fix this, player is pushed player vertically
4: After that fix, the game has detected is colliding with an actor (the green door).
To fix this, player is pushed horizontally
5: Since both movements are ignored the player don't move at all (which is what is expected)

C) Third case (the glitch!) :
1: This is same as second case. The only difference is that player is now running. Because of this the purple box is further away.
2: Here is why the bug occurs : the player is moving fast, so fast that it's next position (purple box) won't be touching the gray wall anymore.
3: Because of this the game will only detect a collision with the actor and will only fix movement horizontally.
4: After the adjustment the player is (incorrectly) penetrating the wall : that is the OOB glitch.

D) Why it does not happen all the time :
1: This is the E2R1 door from E2R4 : the glitch is not likely to happen because the wall extends along the door.
2: The purple box will always touch both actor and wall, regardless speed.
A OOB glitch could only happen here if player would be moving very very fast (which is not possible since there is a speed limit in the game).

Why OOB displacement does not happen each frame ?
This is because when player is running against a wall, speed accumulate (player is stuck) and the predicted position is going further away with the time (until reaching a maximum).
Here is player accumulated speed (which affect predicted position) over the time (amber):

The displacement will only occurs when speed will be above a certain threshold (the red line)

Player displacement during OOB is directly related to player angle and speed :

Code:

displacement = sin(angle) * speed

The angle is not the global player angle but the angle relative to the wall you are OOBing against.

The bigger the angle, the biggest the OOB displacement (we already knew this!).
If angle = 0 degrees (perfectly perpendicular with the wall) displacement is zero (make sense)
If angle = 90 degrees (parallel with the wall) displacement is at its maximum

However, the biggest the angle, the lowest the probability there will be an OOB glitch.
Consider the following cases :

The purple line shows possible positions for the purple box for a given angle.

Angle = 10 degrees : OOB is very likely to happen, several times per foot step.
Angle = 45 degrees : OOB happen sometimes
Angle = 80 degrees : OOB stop happening: player new position always collide with the gray wall

That is why maximal displacement can only be achieved within a certain angle range (compromise between OOB chance of happening and how much it will move each time).

Wohoo! I took a deep look at the game and finally found HOW the OOB works.
It also answers some of NHG questions. It's a bit technical but it worth reading.
With this i'm now able to predict if a OOB will happen at a given place by just look at the game walls and doors position in the viewer.

[b]The basic algorithm for moving the player is : [/b]

1) Take current player position (white square on the picture).
2) Compute where he will be after the move (the purple square), depending the current angle and speed 
3) Check if there is any collision with walls (in gray).
=> If yes, push him vertically or horizontally to avoid the collision
4) Check if there is any collision with actors (in green).
=> If yes, push him vertically or horizontally to avoid the collision
5) Move player to adjusted the position

Here is examples (based on the E2R1 gallery) :

[img]http://s16.postimg.org/fst9whufp/Untitled_2.jpg[/img]

A) First case (first column)
1: initial state
2: predicted move:  no collision at all, everything is fine
3: player is moved to the next position

B) Second case : 
1: Player is walking.
2: The game has predicted that he will be touching the gray wall after moving.
3: To fix this, player is pushed player vertically
4: After that fix, the game has detected is colliding with an actor (the green door).
To fix this, player is pushed horizontally
5: Since both movements are ignored the player don't move at all (which is what is expected)

C) Third case (the glitch!) :
1: This is same as second case. The only difference is that player is now running. Because of this the purple box is further away.
2: Here is why the bug occurs : the player is moving fast, so fast that it's next position (purple box) won't be touching the gray wall anymore.
3: Because of this the game will only detect a collision with the actor and will only fix movement horizontally.
4: After the adjustment the player is (incorrectly) penetrating the wall : that is the OOB glitch.

D) Why it does not happen all the time :
1: This is the E2R1 door from E2R4 : the glitch is not likely to happen because the wall extends along the door.
2: The purple box will always touch both actor and wall, regardless speed.
A OOB glitch could only happen here if player would be moving very very fast (which is not possible since there is a speed limit in the game).

[b]Why OOB displacement does not happen each frame ?[/b]
This is because when player is running against a wall, speed accumulate (player is stuck) and the predicted position is going further away with the time (until reaching a maximum).
Here is player accumulated speed (which affect predicted position) over the time (amber):
[img]http://i.imgur.com/bpdiiLW.png[/img]

The displacement will only occurs when speed will be above a certain threshold (the red line)

[b]Player displacement during OOB is directly related to player angle and speed :[/b]
[code]displacement = sin(angle) * speed[/code]
[img]http://s10.postimg.org/jam2hxfwp/Untitled_22.jpg[/img]

The angle is not the global player angle but the angle relative to the wall you are OOBing against.

The bigger the angle, the biggest the OOB displacement (we already knew this!).
If angle = 0 degrees  (perfectly perpendicular with the wall) displacement is zero (make sense)
If angle = 90 degrees  (parallel with the wall)  displacement is at its maximum

However, the biggest the angle, the lowest the probability there will be an OOB glitch.
Consider the following cases :

[img]http://s15.postimg.org/ojn0sc84r/Untitled_3.jpg[/img]
The purple line shows possible positions for the purple box for a given angle.

Angle = 10 degrees : OOB is very likely to happen, several times per foot step.
Angle = 45 degrees : OOB happen sometimes
Angle = 80 degrees : OOB stop happening: player new position always collide with the gray wall

That is why maximal displacement can only be achieved within a certain angle range (compromise between OOB chance of happening and how much it will move each time).

LotBlind

2016-02-28 03:42:38 pm

Well that's why it works then. Smiley

Did you find out why I can get outside the dining room sometimes without having to kill every zombie from the script? I think what I'm doing is getting all of them aggroed, then the last one (the one with ID 196) has to die which unlocks the doors. Am I right?

When you have multiple zombies active at the same time, it creates lag that seems to affect movement: you can no longer clip in places where it used to be possible. Can everyone see the same?

tigrou

Edit history:

tigrou: 2016-03-01 12:56:58 am

tigrou: 2016-03-01 12:56:36 am

tigrou: 2016-03-01 12:56:22 am

tigrou: 2016-03-01 12:56:12 am

2016-03-01 12:55:35 am

I quickly check script in the dining room but it looks quite complex, there is a lot of subscripts called and variables involved. I was not able to grasp the main idea.

About angle imprecision you both reported : internally, the game store angles using a number between 0 and 1023. (eg : north, east, south, ... are respectively at 0, 256, 512, ....). In the viewer, I map that 1024 units range to 360 degrees to make it easier to read. However this imply some loss of precision. When I will have some time, I will change the viewer so that both angles are shown (the one in degrees and the one using game internal format) .

About OOB : did you already finish to check all possible OOBs in the floors above the ground ? I know we have a Excel for that but when i found a new OOB it took a lot of time to check if it has already been found. It would be easier if we would have a map with all possible OOB (eg : marked by a cross) or at least if we had room references (eg : ExRx) in the Excel.

LotBlind

2016-03-01 12:31:48 pm

About the OOBs: sorry, I didn't know you were doing that too... You could have been doing the underground portion. I was going to include the room codes as part of the table later, but I'll just do that now. I'm 95% done with E0-E3.

Just let us know what you're working on to avoid redundant work.

I can see some weird collider in the ballroom (E3R3) with ID 0 on the E wall of the room. However you can't collide with it... The collider that gives you the pirate key also has ID = 0, which is probably why you can't collide with the other one, but I'd like to know what it's doing there. Maybe it's to prevent the dancers from going too far?

Don't go to the pirate while OOB, I tried to fight him with the sabre and it caused this weird softlock that also made DosBox freeze up in a big way. The pirate has caused plenty of crashes before...

NHG

Edit history:

NHG: 2016-03-01 01:52:56 pm

2016-03-01 01:40:46 pm

Shut up and go back to another earth

LotBlind: Yeah teach, not learn. God my english is so rusted sometimes x/ I feel ashamed.

Tigrou: Really interesting, so now we know how it works, and we can predict where OOB is possible or not, just by watching the map closely most of the time. The idea of the map with OOB spots instead of a list seems really good (and now that we have accurate maps thanks to you it is very conceivable). If we're planning to do such a thing I think it could be a good idea to establish some dissociation (by color ?) between different sorts of clips. I don't really know how proceed to have a logical dissociation though. Maybe clips allowing to reach into OOB, clips from a room to another one and clips through items/desks ?

Also, clip is indeed about probabilities influenced by walls (map) arrangement and player position in some situations (Lotblind Library trick for instance). Measurements that I took seems variable and now that you explained how clip works I'm pretty sure it's because I am not EXACTLY in the same position into the wall (wich is still measurable with the viewer though). About baby-steps, I guess it depends on that too and some other things really complicated to observ. Just earlier I was "Baby-steping" with an huge angle, something like 18°. I retried after a load and it was only 12°, even the whole clip radius itself wasn't the same one. The only thing I can say for sure(and who, once again, seems logical with all we know about clipping) is that baby-step is always inferior to "classical step", it probably also keeps the same proportion compared to the whole clip radius.

Considering all you said, Tigrou, is it stupid to think that right foot and left foot don't have the same speed ? I mean we understand that the game predicts a position wich, in a certain condition, makes you clip if you exceed "oob glitch minimum speed". If we think about baby-steps, it means two possible things:

-Both steps aren't equals in speed, their maximum speed isn't the same, wich explain why baby-steps work with a tiny angle (who decreases the oob gllitch minimum speed if I do not make any mistake). If the angle is too large, only the "best" step is quick enough to pass the red line. In this case it's probably better to consider two running steps as a single "movement cycle" with 2 peaks (or climax ? ) wich aren't equals. My idea would be easier to explain with a draw like yours but I have not your skill x) Just imagine that the orange line's highest point is slightly inferior every two peaks.
-If we consider that my assumption up above is not good, then both steps have the same speed and the highest speed is always the same. So in this case, the only way to explain baby-steps is that right step and left step don't make the same prediction about futur player position. It means that the game is precise enough to understand that both feet do not make the player knock the floor at the same spot, wich is frankly a crazy idea.

What do you think about that ?

Edit: After some tries, it seems that when you make a clip with classical steps, it is always the right foot who makes clip regardless of the direction. It contradicts the 2nd assumption (because if it was about future position prediction, it would mean that one of the feets is best placed into the wall than the other, so logically it'll change depending if you clip to the right or to the left). It also means that the quickest step is the 2nd one, or the one with the right foot. Emily always begin a run with the left foot first and it is during the end of right foot animation that she will clip. So I'm pretty sure it is my first assumption wich is correct: left step speed is slightly slower than right step speed... But I still want your opinion about that x)

LotBlind: Yeah teach, not learn. God my english is so rusted sometimes x/ I feel ashamed.

Tigrou: Really interesting, so now we know how it works, and we can predict where OOB is possible or not, just by watching the map closely most of the time. The idea of the map with OOB spots instead of a list seems really good (and now that we have accurate maps thanks to you it is very conceivable). If we're planning to do such a thing I think it could be a good idea to establish some dissociation (by color ?) between different sorts of clips. I don't really know how proceed to have a logical dissociation though. Maybe clips allowing to reach into OOB, clips from a room to another one and clips through items/desks ?

Also, clip is indeed about probabilities influenced by walls (map) arrangement and player position in some situations (Lotblind Library trick for instance). Measurements that I took seems variable and now that you explained how clip works I'm pretty sure it's because I am not EXACTLY in the same position into the wall (wich is still measurable with the viewer though). About baby-steps, I guess it depends on that too and some other things really complicated to observ. Just earlier I was "Baby-steping" with an huge angle, something like 18°. I retried after a load and it was only 12°, even the whole clip radius itself wasn't the same one. The only thing I can say for sure(and who, once again, seems logical with all we know about clipping) is that baby-step is always inferior to "classical step", it probably also keeps the same proportion compared to the whole clip radius.

Considering all you said, Tigrou, is it stupid to think that right foot and left foot don't have the same speed ? I mean we understand that the game predicts a position wich, in a certain condition, makes you clip if you exceed "oob glitch minimum speed". If we think about baby-steps, it means two possible things:

-Both steps aren't equals in speed, their maximum speed isn't the same, wich explain why baby-steps work with a tiny angle (who decreases the oob gllitch minimum speed if I do not make any mistake). If the angle is too large, only the "best" step is quick enough to pass the red line. In this case it's probably better to consider two running steps as a single "movement cycle" with 2 peaks (or climax ? ) wich aren't equals. My idea would be easier to explain with a draw like yours but I have not your skill x) Just imagine that the orange line's highest point is slightly inferior every two peaks.
-If we consider that my assumption up above is not good, then both steps have the same speed and the highest speed is always the same. So in this case, the only way to explain baby-steps is that right step and left step don't make the same prediction about futur player position. It means that the game is precise enough to understand that both feet do not make the player knock the floor at the same spot, wich is frankly a crazy idea.

What do you think about that ?

Edit: After some tries, it seems that when you make a clip with classical steps, it is always the right foot who makes clip regardless of the direction. It contradicts the 2nd assumption (because if it was about future position prediction, it would mean that one of the feets is best placed into the wall than the other, so logically it'll change depending if you clip to the right or to the left). It also means that the quickest step is the 2nd one, or the one with the right foot. Emily always begin a run with the left foot first and it is during the end of right foot animation that she will clip. So I'm pretty sure it is my first assumption wich is correct: left step speed is slightly slower than right step speed... But I still want your opinion about that x)

tigrou

Edit history:

tigrou: 2016-06-22 12:32:15 pm

tigrou: 2016-06-22 12:31:26 pm

tigrou: 2016-06-22 12:31:09 pm

tigrou: 2016-06-22 12:27:00 pm

tigrou: 2016-06-22 12:15:38 pm

tigrou: 2016-06-22 12:15:02 pm

tigrou: 2016-06-22 12:14:42 pm

tigrou: 2016-06-22 08:38:26 am

tigrou: 2016-03-05 05:04:27 am

tigrou: 2016-03-05 05:03:33 am

tigrou: 2016-03-05 05:03:25 am

tigrou: 2016-03-05 05:02:35 am

tigrou: 2016-03-05 05:02:16 am

tigrou: 2016-03-05 05:00:51 am

tigrou: 2016-03-04 04:53:11 pm

tigrou: 2016-03-04 04:47:42 pm

tigrou: 2016-03-04 04:41:48 pm

tigrou: 2016-03-04 04:35:45 pm

tigrou: 2016-03-04 04:31:31 pm

tigrou: 2016-03-04 04:29:40 pm

tigrou: 2016-03-04 01:15:43 am

tigrou: 2016-03-04 01:15:12 am

tigrou: 2016-03-04 01:14:48 am

tigrou: 2016-03-03 07:40:33 am

tigrou: 2016-03-03 07:40:22 am

tigrou: 2016-03-03 07:05:05 am

tigrou: 2016-03-03 06:45:41 am

tigrou: 2016-03-03 06:45:36 am

tigrou: 2016-03-03 06:45:15 am

tigrou: 2016-03-03 06:36:49 am

tigrou: 2016-03-03 06:36:33 am

tigrou: 2016-03-03 04:17:41 am

tigrou: 2016-03-03 04:17:28 am

tigrou: 2016-03-03 04:10:21 am

tigrou: 2016-03-03 04:10:04 am

tigrou: 2016-03-03 04:09:33 am

2016-03-03 04:09:21 am

@LotBlind : about the "weird" collider in E3R3 , do you mean the blue one along the E wall ? If yes, it does not belongs to ballroom but to pirate room (pressing H will reveal this).
That blue collider is used as a placeholder to create a green actor nearby. The script attached to that green actor is doing this : it checks if you have the underground key and, if you have it, it deletes any dancer which is not in spinning (aka ghost) state. That actor seems only active when you are in the pirate room.

You can try it yourself by doing the following : go to pirate room. You will notice the 3 dancers are there. Then go to ballroom (no need to kill pirate). Grab the underground key (for example awake the dancer in the middle, make sure he don't touch you and take the key). Now go back to pirate room : the two other dancers will be deleted (but the spinning one is still there).

@NHG : Based on what you posted, it seems you correctly understood what I wrote about OOB. Congrats Smiley

Here is what I found :
First, there is not one but two speed per foot step! (I didn't know that). A small one, then a bigger one. Also, the second speed is slightly bigger for one feet (as you suggested, so it was not stupid at all!).

Basically you have this :

Code:

==Step sound 1==
444 (this is player max speed)
570
==Step sound 2==
444
591
==Step sound 1==
444
570
==Step sound 2==
444
591
==Step sound 1==
...

Amber line is player (accumulated) speed (when player is running against a wall)
Yellow one is limit for OOB glitch (which get lower/higher depending the angle or wall configuration)
Green one is foot steps sounds. I am not sure if those steps occurs exactly at that moment, they might occurs slightly before or slightly after. The period/frequency shown should be correct.

This might explain why, depending the angle, you move once every foot step, or once only every two foot steps (only with right or left feet). I did not checked which feet (left or right) gives the fastest speed. Also : the first speed (444) is probably always too small to cause a OOB glitch, regardless wall configuration or player angle. The data shown here is when player is running. The values are probably different when walking, pushing, etc...

EDIT : just for the fun, I would like to try to feed the game with inputs like : "up arrow, nothing, up arrow, nothing, ..." at 60 HZ or different frequencies and see what happen. It could be great if it would make the player to move faster than it should or create other glitches (although we would not be able to use it for the speed run).

@LotBlind : about the "weird" collider in E3R3 , do you mean the blue one along the E wall ? If yes, it does not belongs to ballroom but to pirate room (pressing H will reveal this).
That blue collider is used as a placeholder to create a green actor nearby. The script attached to that green actor is doing this : it checks if you have the underground key and, if you have it, it deletes any dancer which is not in spinning (aka ghost) state. That actor seems only active when you are in the pirate room.

You can try it yourself by doing the following : go to pirate room. You will notice the 3 dancers are there. Then go to ballroom (no need to kill pirate). Grab the underground key (for example awake the dancer in the middle, make sure he don't touch you and take the key). Now go back to pirate room : the two other dancers will be deleted (but the spinning one is still there).

@NHG : Based on what you posted, it seems you correctly understood what I wrote about OOB. Congrats :) Here is what I found  :
First, there is not one but two speed per foot step! (I didn't know that). A small one, then a bigger one. Also, the second speed is slightly bigger for one feet (as you suggested, so it was not stupid at all!).

Basically you have this :

[code]
==Step sound 1==
444 (this is player max speed)
570
==Step sound 2==
444
591
==Step sound 1==
444
570
==Step sound 2==
444
591
==Step sound 1==
...
[/code]

[img]http://s28.postimg.org/6vtifsu4t/xxx.png[/img]
Amber line is player (accumulated) speed (when player is running against a wall)
Yellow one is limit for OOB glitch (which get lower/higher depending the angle or wall configuration)
Green one is foot steps sounds. I am not sure if those steps occurs exactly at that moment, they might occurs slightly before or slightly after. The period/frequency shown should be correct.

This might explain why, depending the angle, you move once every foot step, or once only every two foot steps (only with right or left feet).  I did not checked which feet (left or right) gives the fastest speed. Also : the first speed (444) is probably always too small to cause a OOB glitch, regardless wall configuration or player angle. The data shown here is when player is running. The values are probably different when walking, pushing, etc...

EDIT : just for the fun, I would like to try to feed the game with inputs like : "up arrow, nothing, up arrow, nothing, ..." at 60 HZ or different frequencies and see what happen. It could be great if it would make the player to move faster than it should or create other glitches (although we would not be able to use it for the speed run).

LotBlind

Edit history:

LotBlind: 2016-03-04 12:46:55 pm

2016-03-04 12:24:09 pm

You don't have to list clips that don't skip anything IMO. There's too damn many of them... That's why I specifically removed all of those from the big list.

tigrou: Are you sure the dancers don't also get removed when you exit the ballroom to the W, the arboretum?

EDIT: Hahaha... try alerting the dancers when you're in the pirate room OOB. If you stand somewhere to the West they should not be able to get you...

Have you checked how the acceleration looks like for Edward just in case we've missed something interesting there?

If you do the clip through the library door (to R2), but stop before you're through, you can then turn and clip against the knight. When you do that you move along the wall ultra-fast because your predicted position is virtually always not colliding with the wall you're inside... so in situations like that (I don't know of any others yet), you CAN move even faster than 2 times per cycle.

Mashing "up" at 60hz is usually required to get the character to run :P.... but have you gotten your JPC-RR ready yet? Are you going to run tests there? Ofc you could find something.

EDIT 2: If you're in E3R0 OOB and you go and open the front door, the gray trigger that's normally right behind the door isn't in place. Opening the door will summon the jelly as per usual though. Couldn't get anything interesting to happen though you can still outrun the jelly easily.

You don't have to list clips that don't skip anything IMO. There's too damn many of them... That's why I specifically removed all of those from the big list.

tigrou: Are you sure the dancers don't also get removed when you exit the ballroom to the W, the arboretum?

EDIT: Hahaha... try alerting the dancers when you're in the pirate room OOB. If you stand somewhere to the West they should not be able to get you...

Have you checked how the acceleration looks like for Edward just in case we've missed something interesting there?

If you do the clip through the library door (to R2), but stop before you're through, you can then turn and clip against the knight. When you do that you move along the wall ultra-fast because your predicted position is virtually always not colliding with the wall you're inside... so in situations like that (I don't know of any others yet), you CAN move even faster than 2 times per cycle.

Mashing "up" at 60hz is usually required to get the character to run :P.... but have you gotten your JPC-RR ready yet? Are you going to run tests there? Ofc you could find something.

EDIT 2: If you're in E3R0 OOB and you go and open the front door, the gray trigger that's normally right behind the door isn't in place. Opening the door will summon the jelly as per usual though. Couldn't get anything interesting to happen though you can still outrun the jelly easily.

tigrou

Edit history:

tigrou: 2016-03-05 05:05:16 am

tigrou: 2016-03-05 02:02:35 am

tigrou: 2016-03-04 04:53:03 pm

tigrou: 2016-03-04 04:52:51 pm

tigrou: 2016-03-04 01:51:41 pm

tigrou: 2016-03-04 01:51:18 pm

tigrou: 2016-03-04 01:51:11 pm

tigrou: 2016-03-04 01:33:05 pm

2016-03-04 12:59:23 pm

Yes the dancers get removed if you exit the ballroom to the arboretum because there is an actor at the center of that room (with ID = 155). It has a script that have exactly same logic as the one in the pirate room. So once you got the key, no matter which side you exit the dancers get removed. You have to hide walls in the arboretum to view that actor.

Up key : yep the controls of that game are a mess, this is something they fixed up in RE1 game (it use a separate key to make the player run)
I did not planned to use JPC-RR but that's a good idea. If anyone try something there let me know.

EDIT : you finally added the room location codes to the Excel worksheet, that's great. Don't forget to update your room viewer version if you can, it contains many small improvements/bug fixes.
EDIT2 : from where do you clip to be pirate room OOB ?
EDIT3 : moves from Edward seems to be : 413, 531, 413, 550, ... so slightly less than Emily. It confirms that Emily runs faster than Ed.

LotBlind

Edit history:

LotBlind: 2016-03-31 11:59:29 am

LotBlind: 2016-03-05 11:40:20 am

2016-03-05 10:32:22 am

Quote from tigrou:

Up key : yep the controls of that game are a mess, this is something they fixed up in RE1 game (it use a separate key to make the player run)
I did not planned to use JPC-RR but that's a good idea. If anyone try something there let me know.

AitD 2 fixed the movement and it works just fine. JPC-RR is notoriously difficult to use, much harder than any normal emulator... so good luck! Cheesy

Ilari at TASVideos.org can answer questions and they have the basic instructions for using it too.

Quote from tigrou:

EDIT : you finally added the room location codes to the Excel worksheet, that's great. Don't forget to update your room viewer version if you can, it contains many small improvements/bug fixes.

Will do today.

Quote from tigrou:

EDIT2 : from where do you clip to be pirate room OOB ?

Get OOB from the E3 landing (against stairs S side), then trigger R0 so you're in the wall to the N, then R1 so you're in-between the two triggers (for R0 and R2). Now you can roam about basically anywhere.

Quote from tigrou:

EDIT3 : moves from Edward seems to be : 413, 531, 413, 550, ... so slightly less than Emily. It confirms that Emily runs faster than Ed.

It'd be funny if this small difference meant Edward can't do the new library strat. Smiley

If that was the case you could argue for another category for him after all, but I don't know if one difference is quite enough. The boss room works slightly different too but still not enough in my mind.

About the model viewer: what do you mean by "z-fighting"? You mean "z-lighting"? Also what do you mean by "noise is not supported on doors"?

I just noticed some of the models are less detailed when you're holding the item in your hand. Take #13-15 for instance (the rifle). Also Emily's eyes are hanging in the air! And you can see how they made doors etc. rotate: they just placed their center at the axis of rotation instead of the center of the object.

Looks like the Danse Macabre has tombstones on the cover... never noticed. #232-233 why two versions of the boulder? #258-261 looks like two fireballs... probably there can only be two of them in the air at any given time, and the script alternates which one it spawns. #264 - what's this? Is this what they look like on the sarcophagus? They look like they're wearing VR goggles Cheesy

#270 What's this cone thing doing?

What does actor "life" mean? I see "body" refers to its model.

When I hover the mouse over the front door objects, it flashes between FLAG = 8 and FLAG = 12. What's going on there?

I see that you can clip through the lobby (E3R1) door towards the smoke room from the right side (W side) of the door in addition to the middle. This doesn't always work, it requires good sub-pixels as it seems but you can take a brief step backwards to manipulate it... There may well be other spots where we've missed clips because of this. This is another reason why TASing or using Cheat Engine to test more places would be interesting if you want to do that tigrou. So you can set you exact coordinates and angles. I'd still wait to hear which doors NHG or me are particularly interested in instead of testing every single one.

Something else you could do in an emulator with autofire is see if you can really give the PC tons of health by:
- going into the smoke room and dying to the smoke
- drinking a potion
- interrupting the animation with space bar so it never finishes

You keep losing 5 hp every time.

Finally, I noticed that if you wait for the smoke to hurt you but just before it does, go to the inventory and start frame-advancing by buffering enter and esc alternately, you take 10 damage instead of 5. So far I couldn't find any other places where this bug occurs.

[quote="tigrou"]Up key : yep the controls of that game are a mess, this is something they fixed up in RE1 game (it use a separate key to make the player run)
I did not planned to use JPC-RR but that's a good idea. If anyone try something there let me know.[/quote]

AitD 2 fixed the movement and it works just fine. JPC-RR is notoriously difficult to use, much harder than any normal emulator... so good luck! :D Ilari at TASVideos.org can answer questions and they have the basic instructions for using it too.

[quote="tigrou"]EDIT : you finally added the room location codes to the Excel worksheet, that's great. Don't forget to update your room viewer version if you can, it contains many small improvements/bug fixes.[/quote]

Will do today.

[quote="tigrou"]EDIT2 : from where do you clip to be pirate room OOB ? [/quote]

Get OOB from the E3 landing (against stairs S side), then trigger R0 so you're in the wall to the N, then R1 so you're in-between the two triggers (for R0 and R2). Now you can roam about basically anywhere.

[quote="tigrou"]EDIT3 : moves from Edward seems to be : 413, 531, 413, 550, ... so slightly less than Emily. It confirms that Emily runs faster than Ed.
[/quote]

It'd be funny if this small difference meant Edward can't do the new library strat. :) If that was the case you could argue for another category for him after all, but I don't know if one difference is quite enough. The boss room works slightly different too but still not enough in my mind.

About the model viewer: what do you mean by "z-fighting"? You mean "z-lighting"? Also what do you mean by "noise is not supported on doors"?

I just noticed some of the models are less detailed when you're holding the item in your hand. Take #13-15 for instance (the rifle). Also Emily's eyes are hanging in the air! And you can see how they made doors etc. rotate: they just placed their center at the axis of rotation instead of the center of the object.

Looks like the Danse Macabre has tombstones on the cover... never noticed. #232-233 why two versions of the boulder? #258-261 looks like two fireballs... probably there can only be two of them in the air at any given time, and the script alternates which one it spawns. #264 - what's this? Is this what they look like on the sarcophagus? They look like they're wearing VR goggles :D #270 What's this cone thing doing?

What does actor "life" mean? I see "body" refers to its model.

When I hover the mouse over the front door objects, it flashes between FLAG = 8 and FLAG = 12. What's going on there?

I see that you can clip through the lobby (E3R1) door towards the smoke room from the right side (W side) of the door in addition to the middle. This doesn't always work, it requires good sub-pixels as it seems but you can take a brief step backwards to manipulate it... There may well be other spots where we've missed clips because of this. This is another reason why TASing or using Cheat Engine to test more places would be interesting if you want to do that tigrou. So you can set you exact coordinates and angles. I'd still wait to hear which doors NHG or me are particularly interested in instead of testing every single one.

Something else you could do in an emulator with autofire is see if you can really give the PC tons of health by:
- going into the smoke room and dying to the smoke
- drinking a potion
- interrupting the animation with space bar so it never finishes

You keep losing 5 hp every time.

Finally, I noticed that if you wait for the smoke to hurt you but just before it does, go to the inventory and start frame-advancing by buffering enter and esc alternately, you take 10 damage instead of 5. So far I couldn't find any other places where this bug occurs.

tigrou

Edit history:

tigrou: 2016-03-05 12:30:02 pm

tigrou: 2016-03-05 12:24:25 pm

tigrou: 2016-03-05 12:23:10 pm

tigrou: 2016-03-05 12:21:26 pm

tigrou: 2016-03-05 12:21:13 pm

tigrou: 2016-03-05 12:20:51 pm

tigrou: 2016-03-05 12:20:22 pm

tigrou: 2016-03-05 12:20:08 pm

tigrou: 2016-03-05 12:19:29 pm

tigrou: 2016-03-05 12:18:21 pm

tigrou: 2016-03-05 12:17:58 pm

tigrou: 2016-03-05 12:17:46 pm

tigrou: 2016-03-05 12:17:17 pm

tigrou: 2016-03-05 12:17:01 pm

tigrou: 2016-03-05 12:15:58 pm

tigrou: 2016-03-05 12:15:26 pm

tigrou: 2016-03-05 12:15:02 pm

tigrou: 2016-03-05 12:14:54 pm

tigrou: 2016-03-05 12:14:30 pm

2016-03-05 12:13:31 pm

Quote:

JPC-RR is notoriously difficult to use

Indeed : I get bored very quickly and throw it away after 5 min. Even when you got it work it is not as good as usual TAS tools. I used my own techniques for injecting inputs to the game. It did not gave anything interesting. As soon as the up key is no more hold, player stop running and switch to walk mode.

About 3D model viewer : I'm happy someone finally took a look at it. Especially that I put a great amount of effort on it. It could be fun to 3D print some of those models, so you could have some of them at home, on your desktop (for real fans only!) .

Quote:

what do you mean by "z-fighting"?

see here : https://en.wikipedia.org/wiki/Z-fighting
Noise : play the game in low quality and watch the doors. If you still didn't noticed a difference, look at them again in high quality.

All those small differences/problems are because the real game use a custom software renderer which allows all sort of tricks/hacks during filling/sorting triangles. Those are difficult to emulate accurately on modern hardware (even using pixel shaders).

Quote:

#270 What's this cone thing doing?

Looks a early draft of #260.

Quote:

What does actor "life" mean? I see "body" refers to its model.

LIFE means script ID. It is the identifier of the script actually running for that actor. It can change over the time, usually depending actor status. At a given moment there is only one script running for an actor.
I used same naming conventions as in the original game although it looks a little bit confusing (someone could believe LIFE is life points or something like this).

Quote:

Something else you could do in an emulator with autofire is see if you can really give the PC tons of health by:

If I remember well, NHG explained it is possible in AITD2 but not AITD1. Yes it would be really fun, imagine this : it would resurrect the player while laying on tombstone. After the wake up you would place the talisman, throw the oil ramp and go (but I really doubt in feasibility of such a glitch)

[quote]JPC-RR is notoriously difficult to use[/quote]
Indeed : I get bored very quickly and throw it away after 5 min. Even when you got it work it is not as good as usual TAS tools. I used my own techniques for injecting inputs to the game. It did not gave anything interesting. As soon as the up key is no more hold, player stop running and switch to walk mode.

About 3D model viewer : I'm happy someone finally took a look at it. Especially that I put a great amount of effort on it. It could be fun to 3D print some of those models, so you could have some of them at home, on your desktop (for real fans only!) .

[quote] what do you mean by "z-fighting"?[/quote]
see here : https://en.wikipedia.org/wiki/Z-fighting
Noise : play the game in low quality and watch the doors. If you still didn't noticed a difference, look at them again in high quality.

All those small differences/problems are because the real game use a custom software renderer which allows all sort of tricks/hacks during filling/sorting triangles. Those are difficult to emulate accurately on modern hardware (even using pixel shaders).

[quote]#270 What's this cone thing doing?[/quote]
Looks a early draft of #260.

[quote]What does actor "life" mean? I see "body" refers to its model.[/quote]
LIFE means script ID. It is the identifier of the script actually running for that actor. It can change over the time, usually depending actor status. At a given moment there is only one script running for an actor. 
I used same naming conventions as in the original game although it looks a little bit confusing (someone could believe LIFE is life points or something like this).

[quote]Something else you could do in an emulator with autofire is see if you can really give the PC tons of health by:[/quote]

If I remember well, NHG explained it is possible in AITD2 but not AITD1. Yes it would be really fun, imagine this : it would resurrect the player while laying on tombstone. After the wake up you would place the talisman, throw the oil ramp and go (but I really doubt in feasibility of such a glitch)

NHG

2016-03-06 04:29:58 am

Shut up and go back to another earth

As far as I know, it is indeed impossible to use the same "infinite health" method in Alone 1 because there's not any item who works the same way. In Alone2, there's a bottle of wine you have to poison. Once it is done, you can still drink it but, because it is a key item, it is not consumed in the inventory. In theory it is not really a problem because you're supposed to die (with something like 500 damages) but if you hold ENTER it'll open the inventory before the game launches the death animation. Then you just have to drink it again and again until the health comes back to an huge positive number.

But there may be another way to have infinite health in Alone 1. If the smoke room method works the way I understood, it's technically possible but it'll take a long long time.

Good to have a proof by numbers that Emily is slightly faster ! Well we already kinda knew that but numbers really are reassuring x) The way speed works (two accelerations by step) is really odd though.

LotBlind: In theory I agree to not enumerate only "useful clips" but in this case we have to be absolutely sure that useless clips are indeed useless, wich is more conceivable now that we understand the clip system, I admit that. I'll ask you wich floor isn't checked yet when I'll finish the game I'm actually playing so I'll give a hand. Then I think it'll be time for me to begin training.

As far as I know, it is indeed impossible to use the same "infinite health" method in Alone 1 because there's not any item who works the same way. In Alone2, there's a bottle of wine you have to poison. Once it is done, you can still drink it but, because it is a key item, it is not consumed in the inventory. In theory it is not really a problem because you're supposed to die (with something like 500 damages) but if you hold ENTER it'll open the inventory before the game launches the death animation. Then you just have to drink it again and again until the health comes back to an huge positive number.

But there may be another way to have infinite health in Alone 1. If the smoke room method works the way I understood, it's technically possible but it'll take a long long time.

Good to have a proof by numbers that Emily is slightly faster ! Well we already kinda knew that but numbers really are reassuring x) The way speed works (two accelerations by step) is really odd though.

LotBlind: In theory I agree to not enumerate only "useful clips" but in this case we have to be absolutely sure that useless clips are indeed useless, wich is more conceivable now that we understand the clip system, I admit that. I'll ask you wich floor isn't checked yet when I'll finish the game I'm actually playing so I'll give a hand. Then I think it'll be time for me to begin training.

tigrou

Edit history:

tigrou: 2016-03-06 12:05:04 pm

tigrou: 2016-03-06 09:19:40 am

tigrou: 2016-03-06 08:12:24 am

tigrou: 2016-03-06 07:37:18 am

tigrou: 2016-03-06 07:36:59 am

tigrou: 2016-03-06 07:34:27 am

tigrou: 2016-03-06 07:33:36 am

tigrou: 2016-03-06 07:33:02 am

tigrou: 2016-03-06 07:29:49 am

tigrou: 2016-03-06 07:29:40 am

tigrou: 2016-03-06 07:28:24 am

tigrou: 2016-03-06 07:26:23 am

tigrou: 2016-03-06 07:26:17 am

tigrou: 2016-03-06 07:26:04 am

tigrou: 2016-03-06 07:25:44 am

2016-03-06 07:25:34 am

Hi there,

A little bump to tell you I have slightly updated room viewer :
- As requested long time ago by LotBlind, it is now possible to view current room and rooms nearby in transparent. This is useful when you are OOB and want to know where you will end up after touching a trigger. To enable this, just press H as usual.
- It is now possible to drag the rooms using the mouse (eg : like in google maps)
- When DOSBOX mode is enabled, the angle relative to the wall you are trying to OOB from is shown. Actually this is the shortest angle from the 4 cardinal directions (N/S/E/W). This is useful when trying to see what is the best angle to maximize steps (usually this seems to be around 20 degrees).

LotBlind

Edit history:

LotBlind: 2016-03-07 12:35:15 pm

LotBlind: 2016-03-07 12:22:01 pm

LotBlind: 2016-03-07 12:21:42 pm

2016-03-07 12:16:51 pm

Hahaha... 3D-printing. I didn't think of that but if the game ever gets run in a marathon, that would make a great donation incentive. Well, if someone has access to such a printer.

Okay I see about the Z-fighting. I'm not sure if I'd call those random textures "noise" unless you're saying that's an actual computer term. I'd call it maybe just roughness. It's a rough surface.

Tigrou, you misunderstood me. I found a method of getting infinitely low health in AitD1 by using the method I wrote out; it will take a long time and no-one will want to do it if no-one wants to set up an autofire tool (I don't see it as that interesting myself). BTW we already know (or I do in any case) that you CAN have positive HP when you're on the sarcophagus, but all it does is this. You can't access your inventory either. I normally don't report this kinda stuff unless I see any potential.

About the model viewer: it's pretty nice ofc! Just from a speedrunning POV it's not that interesting. However, later when you're no longer developing the tool, we'll share it with the people watching the AitD Wiki and elsewhere and I'm sure they'll be very interested.

The latest updates to the room viewer sound very useful! Thanks! I had actually been thinking of the mouse drag option... That's generally always going to improve usability. Wow, you're really making it a pro-level piece of software now Cheesy

NHG: Do you think the game lags less when you switch to low graphics quality? I feel the inventory scrolls faster for me. Maybe this is worth exploring a bit more.

Yeah, I've stopped listing clips that only take you into the corners of rooms behind objects because I've never seen any use coming from it.

EDIT: Speaking of the alternating flags (8 and 12) I mentioned earlier, looks like the other lobby door also has those. I guess any entity can have multiple flags? Can you make them be listed instead of flashing? If you like, you could include a short explanation of what each tag means in the readme. I see you found new ones too.

Another suggestion: you could make it so that when you click on something, it puts its information in a separate box on the side. The idea is this way you could follow changes in the various values: speed, life, etc. It's very difficult to hover over a moving object.

Hahaha... 3D-printing. I didn't think of that but if the game ever gets run in a marathon, that would make a great donation incentive. Well, if someone has access to such a printer.

Okay I see about the Z-fighting. I'm not sure if I'd call those random textures "noise" unless you're saying that's an actual computer term. I'd call it maybe just roughness. It's a rough surface.

Tigrou, you misunderstood me. I [i]found[/i] a method of getting infinitely low health in AitD1 by using the method I wrote out; it will take a long time and no-one will want to do it if no-one wants to set up an autofire tool (I don't see it as that interesting myself). BTW we already know (or I do in any case) that you CAN have positive HP when you're on the sarcophagus, but all it does is [url=https://drive.google.com/file/d/0B6VbXOZpnj6MTDlPWjVYZ2lVWkk/view?usp=sharingl]this[/url]. You can't access your inventory either. I normally don't report this kinda stuff unless I see any potential.

About the model viewer: it's pretty nice ofc! Just from a speedrunning POV it's not that interesting. However, later when you're no longer developing the tool, we'll share it with the people watching the AitD Wiki and elsewhere and I'm sure they'll be very interested.

The latest updates to the room viewer sound very useful! Thanks! I had actually been thinking of the mouse drag option... That's generally always going to improve usability. Wow, you're really making it a pro-level piece of software now :D

NHG: Do you think the game lags less when you switch to low graphics quality? I feel the inventory scrolls faster for me. Maybe this is worth exploring a bit more.

Yeah, I've stopped listing clips that only take you into the corners of rooms behind objects because I've never seen any use coming from it.

EDIT: Speaking of the alternating flags (8 and 12) I mentioned earlier, looks like the other lobby door also has those. I guess any entity can have multiple flags? Can you make them be listed instead of flashing? If you like, you could include a short explanation of what each tag means in the readme. I see you found new ones too.

Another suggestion: you could make it so that when you click on something, it puts its information in a separate box on the side. The idea is this way you could follow changes in the various values: speed, life, etc. It's very difficult to hover over a moving object.

tigrou

Edit history:

tigrou: 2016-03-14 09:54:05 am

tigrou: 2016-03-14 09:22:53 am

tigrou: 2016-03-14 09:22:48 am

tigrou: 2016-03-14 09:22:47 am

tigrou: 2016-03-14 09:22:34 am

tigrou: 2016-03-14 09:21:16 am

tigrou: 2016-03-14 09:05:39 am

tigrou: 2016-03-14 09:04:54 am

tigrou: 2016-03-14 07:35:39 am

2016-03-14 07:33:09 am

Just as info :
I have tried to calculate the (theoretical) maximum step angles, when you are doing the LotBlind OOB trick in the library :

Edward :

Code:

maximum (two steps) = acos(532/570) = 21.03 degrees
maximum (one step)  = acos(532/591) = 25.81 degrees

Emily :

Code:

maximum (two steps) = acos(570/611) = 21.11 degrees
maximum (one step)  = acos(570/633) = 25.77 degrees

I might have done a mistake, but after some tests using the room viewer it seems to be right. To reach such angles the player need to fully touch the inner walls of the library. There should not be any blue space in between.
Edward and Emily have sensibily same steps angles. Edward run slower, but since his hitbox is smaller he can go closer to the wall (regarding the center) and thus he need lower speed to achieve OOB steps.

I have to admit it is not terribly useful. However if using a tool would be allow during the speedrun we could imagine the following :
During the gameplay the room viewer receive focus. He would thus receive keyboard input and would relay it to the DOSBOX process (so if you press "A" on room viewer it sends a "A" to DOSBOX).
This would allow all sort of tricks : eg : pressing shift would send keys one frame by two, thus allow to rotate player very precisely. Or a key for instant run (instead of double smashing up arrow like crazy). Or even better : a OOB assist tool (like self parking cars) : the viewer would send the right key presses during OOB or fix yours (eg : to optimize angle steps). But I guess this is cheating.
Another idea : to wrote a list of instructions that would be interpreted by room viewer and send to the game :

Code:

WALK 13200, 5000 // go to attic stairs
WAIT 4000        // wait 4 seconds for anim to be done
WALK 16000, 2000 // go to E1R0 door
WAIT 1200        // wait for the door to be open
...

The run would be then re-playable and we could optimize it as much as possible.
Again, this is (probably) a cheat.

@LotBlind :
some information about flags : the number shown in FLAGS is used to represent the state of several boolean (ON/OFF) flags.
Each flag is defined using of a power of two number :

Code:

FLAG0: 1
FLAG1: 2
FLAG2: 4
FLAG3: 8
FLAG4: 16
...

So when you see FLAGS = 12, it actually means that FLAG 2 and FLAG3 are active (because 4 + 8 = 12).
In the lobby, when you see the door FLAGS attribute switching very fast between 8 and 12 it actually means FLAG2 is turned on and off each frame alternatively.
I am not sure what cause this (is it done by a script or by the engine itself). It seems it only occurs when player is above a certain distance from the door.

The meaning of flags for actors is unknown. There is probably one flag for indicating if the actor can/cannot collide with other COLLIDERS (eg : the purple monster in library or the arrow) and one flag that indicate if actor is active/dormant.

For colliders :

Code:

FLAG0(1): almost all colliders have this one. there is some exceptions 
          (eg : the bottom left pillar in the attic, where you place the mirrors, ... ). not sure if it is used.
FLAG1(2): colliders related to the floor (eg: E5 and E6 underground floors)
FLAG2(4): colliders above doors. not sure if it is really used by the game.
FLAG3(8): interaction with player is enabled (blue boxes)

In practice, for triggers, only FLAGS=0 (room switch), FLAGS=9 (special trigger) or FLAGS=10 (floor switch) seems to be used.

Just as info :
I have tried to calculate the (theoretical) maximum step angles, when you are doing the LotBlind OOB trick in the library :

Edward : 
[code]maximum (two steps) = acos(532/570) = 21.03 degrees
maximum (one step)  = acos(532/591) = 25.81 degrees[/code]
Emily : 
[code]maximum (two steps) = acos(570/611) = 21.11 degrees
maximum (one step)  = acos(570/633) = 25.77 degrees[/code]

I might have done a mistake, but after some tests using the room viewer it seems to be right. To reach such angles the player need to fully touch the inner walls of the library. There should not be any blue space in between.
Edward and Emily have sensibily same steps angles. Edward run slower, but since his hitbox is smaller he can go closer to the wall (regarding the center) and thus he need lower speed to achieve OOB steps.

I have to admit it is not terribly useful. However if using a tool would be allow during the speedrun we could imagine the following : 
During the gameplay the room viewer receive focus. He would thus receive keyboard input and would relay it to the DOSBOX process (so if you press "A" on room viewer it sends a "A" to DOSBOX).
This would allow all sort of tricks : eg : pressing shift would send keys one frame by two, thus allow to rotate player very precisely. Or a key for instant run (instead of double smashing up arrow like crazy). Or even better : a OOB assist tool (like self parking cars) : the viewer would send the right key presses during OOB or fix yours (eg : to optimize angle steps). But I guess this is cheating. 
Another idea : to wrote a list of instructions that would be interpreted by room viewer and send to the game :
[code]WALK 13200, 5000 // go to attic stairs
WAIT 4000        // wait 4 seconds for anim to be done
WALK 16000, 2000 // go to E1R0 door
WAIT 1200        // wait for the door to be open
... [/code]
The run would be then re-playable and we could optimize it as much as possible.
Again, this is (probably) a cheat.

@LotBlind : 
some information about flags : the number shown in FLAGS is used to represent the state of several boolean (ON/OFF) flags.
Each flag is defined using of a power of two number :

[code]FLAG0: 1
FLAG1: 2
FLAG2: 4
FLAG3: 8
FLAG4: 16
...
[/code]

So when you see FLAGS = 12, it actually means that FLAG 2 and FLAG3 are active (because 4 + 8 = 12).
In the lobby, when you see the door FLAGS attribute switching very fast between 8 and 12 it actually means FLAG2 is turned on and off each frame alternatively.
I am not sure what cause this (is it done by a script or by the engine itself). It seems it only occurs when player is above a certain distance from the door.

The meaning of flags for actors is unknown. There is probably one flag for indicating if the actor can/cannot collide with other COLLIDERS (eg : the purple monster in library or the arrow) and one flag that indicate if actor is active/dormant.

For colliders :
[code]
FLAG0(1): almost all colliders have this one. there is some exceptions 
          (eg : the bottom left pillar in the attic, where you place the mirrors, ... ). not sure if it is used.
FLAG1(2): colliders related to the floor (eg: E5 and E6 underground floors)
FLAG2(4): colliders above doors. not sure if it is really used by the game.
FLAG3(8): interaction with player is enabled (blue boxes)[/code]

In practice, for triggers, only FLAGS=0 (room switch), FLAGS=9 (special trigger) or FLAGS=10 (floor switch) seems to be used.

LotBlind

Edit history:

LotBlind: 2016-03-17 12:49:07 pm

2016-03-14 06:19:27 pm

old notes:

The viewer now shows your angle relative to the walls but it will show you the absolute difference without taking into account the direction. May I suggest you make it give angles that are slightly below the perpendicular as negative numbers so it's easier to follow when you've passed from one side to the other?

tigrou: can you tell how fast Emily and Edward move when they're jumping? Is there any point in trying to OOB somewhere by jumping? I don't think it works simply because I've never seen anywhere where it's possible.

----

in response to latest tigrou post:

So there shouldn't really be any difference between which clips the two characters can do? Just a tiny difference between who moves faster when clipping? Who is it btw, still Emily?

What you're describing with the movement tools sounds to me like TASing again... nothing wrong with it but it's only interesting to us if it allows us to find new potential tricks that the speedrunners can then practise. So far the only thing we might have missed that I can see is some clipping opportunity somewhere that requires very precise pixels, as I mentioned earlier. That and actually using a monster (like the white spider in E5R9) to do new skips. I just spent some time trying to use the spider to clip right into E6...

What you're saying about a series of inputs is as close to being a TAS without being a TAS as you can get... at that point it's going to get scrutinized on a TAS level instead of speedrun. I don't know if the game actually allows you to do that, because won't you also have to somehow force RAM state? Well, the game doesn't seem to have any randomness, but you might have to be able to detect lag frames and compensate won't you? Anyway that's outside my field of expertise, or at least of direct interest.

Thanks for explaining the flags!

EDIT: Is it possible to make the viewer not unhook you if you enter the model viewer?

E5R2: this extra corridor is actually pretty weird... there literally just isn't a piece of wall where you walk through... then the room changes, and for some reason only the SW corner allows you to clip out again. If you walk through, trigger the room (R2) without entering it fully, then run back out you might fall down a little ways.

Okay I just found a usage for this that allows getting OOB in E5. Here's how. When you enter R2 you have to hug the N wall, then also face a little bit towards the N when clipping back out to the previous room. Then you just clip against the wall until you get to the point shown. After that it's a bit tricky, you have to face an angle that's about 45 degrees out (which is why I take some time to set it up) and simply walk ahead so it gets Emily climbing. This should place you far enough into the corner that you can then just run right through.

It won't ever save any time I suspect but more importantly you might be able to use the same technique to get OOB elsewhere, or even to get back in-bounds, e.g. in E6E6. I'll report more findings if they come.

old notes:

The viewer now shows your angle relative to the walls but it will show you the absolute difference without taking into account the direction. May I suggest you make it give angles that are slightly below the perpendicular as negative numbers so it's easier to follow when you've passed from one side to the other?

tigrou: can you tell how fast Emily and Edward move when they're jumping? Is there any point in trying to OOB somewhere by jumping? I don't think it works simply because I've never seen anywhere where it's possible.

----

in response to latest tigrou post:

So there shouldn't really be any difference between which clips the two characters can do? Just a tiny difference between who moves faster when clipping? Who is it btw, still Emily?

What you're describing with the movement tools sounds to me like TASing again... nothing wrong with it but it's only interesting to us if it allows us to find new potential tricks that the speedrunners can then practise. So far the only thing we might have missed that I can see is some clipping opportunity somewhere that requires very precise pixels, as I mentioned earlier. That and actually using a monster (like the white spider in E5R9) to do new skips. I just spent some time trying to use the spider to clip right into E6...

What you're saying about a series of inputs is as close to being a TAS without being a TAS as you can get... at that point it's going to get scrutinized on a TAS level instead of speedrun. I don't know if the game actually allows you to do that, because won't you also have to somehow force RAM state? Well, the game doesn't seem to have any randomness, but you might have to be able to detect lag frames and compensate won't you? Anyway that's outside my field of expertise, or at least of direct interest.

Thanks for explaining the flags!

EDIT: Is it possible to make the viewer not unhook you if you enter the model viewer?

E5R2: this extra corridor is actually pretty weird... there literally just isn't a piece of wall where you walk through... then the room changes, and for some reason only the SW corner allows you to clip out again. If you walk through, trigger the room (R2) without entering it fully, then run back out you might fall down a little ways.

Okay I just found a usage for this that allows getting OOB in E5. [url=https://drive.google.com/file/d/0B6VbXOZpnj6MZjdRaFpuLUhwbnc/view?usp=sharing]Here's how[/url]. When you enter R2 you have to hug the N wall, then also face a little bit towards the N when clipping back out to the previous room. Then you just clip against the wall until you get to the point shown. After that it's a bit tricky, you have to face an angle that's about 45 degrees out (which is why I take some time to set it up) and simply walk ahead so it gets Emily climbing. This should place you far enough into the corner that you can then just run right through.

It won't ever save any time I suspect but more importantly you might be able to use the same technique to get OOB elsewhere, or even to get back in-bounds, e.g. in E6E6. I'll report more findings if they come.

tigrou

2016-03-15 04:12:24 am

Quote:

give angles that are slightly below the perpendicular as negative numbers ...

Good idea, it can be done easily, I would suggest to do the same for angles at the other sides :
north or south left : negative. north or south right : positive

Quote:

won't you also have to somehow force RAM state?

no, all methods I described would just send key inputs to the game. writing to RAM is never allowed, even in TAS.
by writing to RAM, you could just finish the game in a few frames :
teleport player from attic to lobby, switch dead boss variable to 1, make it touch the main door and voila Smiley

Quote:

can you tell how fast Emily and Edward move when they're jumping?

could you give me the actor ANIM value of Edward and Emily when they are jumping (should be the same value for both)

Quote:

Is it possible to make the viewer not unhook you if you enter the model viewer?

It's technically possible but it would be hard to do because the way it's implemented in Unity. There is no easy fix for this.

[quote]give angles that are slightly below the perpendicular as negative numbers ...[/quote]
Good idea, it can be done easily, I would suggest to do the same for angles at the other sides : 
north or south left : negative. north or south right : positive

[quote]won't you also have to somehow force RAM state?[/quote]
no, all methods I described would just send key inputs to the game. writing to RAM is never allowed, even in TAS.
by writing to RAM, you could just finish the game in a few frames :
teleport player from attic to lobby, switch dead boss variable to 1, make it touch the main door and voila :)

[quote]can you tell how fast Emily and Edward move when they're jumping? [/quote]
could you give me the actor ANIM value of Edward and Emily when they are jumping (should be the same value for both)

[quote]Is it possible to make the viewer not unhook you if you enter the model viewer? [/quote]
It's technically possible but it would be hard to do because the way it's implemented in Unity. There is no easy fix for this.

LotBlind

2016-03-15 04:19:45 pm

I didn't mean writing to RAM, I meant when you launch the game in Windows under DosBox, does the memory DosBox use always have the same state so your inputs actually give the same outputs consistently? If not how do you force an initial RAM state for things like system clock? The reason I'm kinda suspicious of this is I don't understand why I've never seen a DosBox demo file then, seeing as someone must have come up with the idea before. I don't think AitD has randomness but it's those lag frames that I'm worried about, unless DosBox can detect those itself somehow.

I confirmed that both characters have the same jumping animation and it's #270.

I just noticed that because Edward has that smaller hitbox, there's a few places where he might be able to squeeze through somewhere Emily cannot. Gotta remember this for later.

Here's an application to the OOB I showed in the last post. This gets you straight to the maze, right at the door. It does currently involve a bit of blindedness... but I didn't check if you can get more camera transitions or not.

I didn't mean [i]writing[/i] to RAM, I meant when you launch the game in Windows under DosBox, does the memory DosBox use always have the same state so your inputs actually give the same outputs consistently? If not how do you force an initial RAM state for things like system clock? The reason I'm kinda suspicious of this is I don't understand why I've never seen a DosBox demo file then, seeing as someone must have come up with the idea before. I don't think AitD has randomness but it's those lag frames that I'm worried about, unless DosBox can detect those itself somehow.

I confirmed that both characters have the same jumping animation and it's #270.

I just noticed that because Edward has that smaller hitbox, there's a few places where he might be able to squeeze through somewhere Emily cannot. Gotta remember this for later.

Here's [url=https://drive.google.com/file/d/0B6VbXOZpnj6McVk0Z3pxc0RXbnc/view?usp=sharing]an application to the OOB[/url] I showed in the last post. This gets you [i]straight[/i] to the maze, right at the door. It does currently involve a bit of blindedness... but I didn't check if you can get more camera transitions or not.

tigrou

Edit history:

tigrou: 2016-03-16 05:12:40 am

tigrou: 2016-03-16 05:02:28 am

tigrou: 2016-03-16 04:56:14 am

2016-03-16 04:55:24 am

Aha, now I understand what you mean about memory. Yes, sending key inputs to the game from a stored sequence (as it is done in TAS) requires that sequence to be perfectly synchronized with the game (at frame level) and to force memory to be in an initial given state. This would only be possible with JPC-RR or hacked version of DOSBOX. This is not what I intended to do with viewer.

Instead, the idea would be for the viewer to have a list of goals to meet (eg : player has to be at position 1200,200,1500) . The viewer would read player position from DOSBOX memory (as it is done now) and based on that, it will calculate (real time) the required key inputs to meet the goal. It is like a closed feedback loop. It's only when a goal is meet that it would switch to next goal and so. Because of this, there is no possible "unsync". There is no need to write anything to RAM, just read values from memory and send key inputs. Like a regular player, which, based on what he see, press keys (with a list of goals in mind).

About jump animation : it contains 8 keyframes (while running contains 4).
Here is the values :

Code:

0, 338, 313, 416, 416, 492, 417, 0 (Edward)
0, 362, 336, 446, 446, 527, 447, 0 (Emily)

AFAIK, the movements are too small to be useful for OOB. They are smaller than the respective bounding boxes for each character which are 532 and 570.

By "keyframes" I mean this (of course, the game interpolates between keyframes so the movement appears smooth)

Aha, now I understand what you mean about memory. Yes, sending key inputs to the game from a stored sequence (as it is done in TAS) requires that sequence to be perfectly synchronized with the game (at frame level) and to force memory to be in an initial given state. This would only be possible with JPC-RR or hacked version of DOSBOX. This is not what I intended to do with viewer.

Instead, the idea would be for the viewer to have a list of goals to meet (eg : player has to be at position 1200,200,1500) . The viewer would read player position from DOSBOX memory (as it is done now) and based on that, it will calculate (real time) the required key inputs to meet the goal. It is like a closed feedback loop. It's only when a goal is meet that it would switch to next goal and so. Because of this, there is no possible "unsync". There is no need to write anything to RAM, just read values from memory and send key inputs. Like a regular player, which, based on what he see, press keys (with a list of goals in mind).

About jump animation : it contains 8 keyframes (while running contains 4).
Here is the values :
[code]0, 338, 313, 416, 416, 492, 417, 0 (Edward)
0, 362, 336, 446, 446, 527, 447, 0 (Emily)[/code]

AFAIK, the movements are too small to be useful for OOB. They are smaller than the respective bounding boxes for each character which are 532 and 570.

By "keyframes" I mean [url=http://viz.aset.psu.edu/gho/sem_notes/animation/gifs/tiger_keys.gif]this[/url] (of course, the game interpolates between keyframes so the movement appears smooth)

LotBlind

Edit history:

LotBlind: 2016-03-18 09:27:50 am

LotBlind: 2016-03-18 08:28:23 am

2016-03-18 08:26:22 am

Okay and now I get what you meant to be doing with the viewer... it sounds like botting except it doesn't produce an optimal path between the two places necessarily. I see you suggested to get precise turning from this... It does sound somewhat more convenient than what I'm doing now, but to get something like a 0.1 degree turn, I think you have to move backwards or forwards a bit to manipulate the animation or whatever. I wouldn't say it's necessary to finish the speedrun because I've never found anything that requires such precise angles... as we know the range is usually more than 10 degrees... and as for optimization, as you say, it almost doesn't help you at all to know what exact number of degrees is optimal because you'd also have to learn to manipulate that angle in real-time without any aids. Still, if you feel like messing around with it, I will at least try to see if I can find some use for it when playing.

Do you think there's any way to automate finding spots where you can clip? The viewer would have to be able to detect corners and measure distances and ...? Do we have the exact understanding now that we need? It looks like the only reason it fails in most corners is because they made the walls overlap. In fact you can see this pretty easily when the walls are shown transparent, because the overlapping parts are brighter. That's largely all I need to see. When they're not transparent, hovering over them when you're zoomed out far enough shows you the corners that don't highlight, which means the same.

When I tried doing some more wrapping around with all objects visible, I noticed that some of them look like they're beyond the wrapping point completely, i.e. I can't get to their coordinates. Is this just the way the viewer is rendering the game?

What I said earlier about monsters being in a different room in the game is true - for them, the architecture of that room IS loaded in, I can tell because I'm looking at a deep one (frog guy) running into a wall that I can pass through. So the game must have more than one room in the RAM after all, just a different part of RAM. Is my logic right?

I also want you to help me analyse, if you can, what happens when I do the OOB I showed earlier. Specifically what happens when you climb up a thing? I think it just nudges you forwards instantaneously at the very end of the animation (which is #267 when jumping up, then #268 for one frame). I'd forgotten I can just pause the game and buffer ESC every time to get it to advance one frame at a time. Cheesy

I presume #268 gives you a forwards boost, so how big is it?

Actually I think what's happening is this: the game does a projection of where the player will end up if they're allowed to climb up from where they're at. If the projection doesn't put them into a wall, they're allowed to climb. However, normally you're not stuck anywhere and the game will take into account your sliding along the wall (?) that you're facing during the actual jump. When I did the special climb, my movement parallel to the wall was being checked and so maybe that's the difference somehow. I'm trying to use a deep one in E5R7 to act as the "stopper" when getting on the jetty and I can sometimes make it work, but sadly it doesn't put me inside the corner I'm next to. Maybe because after I've climbed above its height, I'm no longer being checked from moving along the wall. I just end up on top of the monster instead.

Have you guys noticed this game has a pause button? Shocked

Just press 'P' to freeze it and Space/INS to unfreeze. Jesus, I don't think I've ever tried using that with anything... If you pause, then release and depress 'p' again before hitting space, you can get a frame advance without entering the menu or inventory. It only works during regular gameplay, not when picking something up or in the menu or inventory. Only downside is you'll force the character to do whatever action they have selected.

Okay I found something hilarious AND potentially useful for speedruns. Just go down to E5 via study and jump into the stairs trigger. Hahaha. (Save file if you need it). You can also drink the potion during the transition without having to wait for the animation for that. This works anywhere except you have to use e.g. the rifle's recoil so you have time to select the flask while moving towards the trigger. Otherwise you have to be very precise and drink the potion right before you lose control.

Someone might think this is of some use as well... I think NHG already found it at one point, but he just didn't know how to use it back then. I used the "hover mouse" method to find it BTW, proving that it works! The best part about it is the boulder will be removed when you return! You also can just run over the bridge which is left intact. Maybe getting the study key and sabre is better after all? Tongue

NHG will have one helluva time testing all of this.

I think I'll just post this right now so you can read what I've written so far...

EDIT:

Aaaaannd here's a faster way to get to the boss room. It's easy with the room viewer...

Okay and now I get what you meant to be doing with the viewer... it sounds like botting except it doesn't produce an optimal path between the two places necessarily. I see you suggested to get precise turning from this... It does sound somewhat more convenient than what I'm doing now, but to get something like a 0.1 degree turn, I think you have to move backwards or forwards a bit to manipulate the animation or whatever. I wouldn't say it's necessary to finish the speedrun because I've never found anything that requires such precise angles... as we know the range is usually more than 10 degrees... and as for optimization, as you say, it almost doesn't help you at all to know what exact number of degrees is optimal because you'd also have to learn to manipulate that angle in real-time without any aids. Still, if you feel like messing around with it, I will at least try to see if I can find some use for it when playing.

Do you think there's any way to automate finding spots where you can clip? The viewer would have to be able to detect corners and measure distances and ...? Do we have the exact understanding now that we need? It looks like the only reason it fails in most corners is because they made the walls overlap. In fact you can see this pretty easily when the walls are shown transparent, because the overlapping parts are brighter. That's largely all I need to see. When they're not transparent, hovering over them when you're zoomed out far enough shows you the corners that don't highlight, which means the same.

When I tried doing some more wrapping around with all objects visible, I noticed that some of them look like they're beyond the wrapping point completely, i.e. I can't get to their coordinates. Is this just the way the viewer is rendering the game?

What I said earlier about monsters being in a different room in the game is true - for them, the architecture of that room IS loaded in, I can tell because I'm looking at a deep one (frog guy) running into a wall that I can pass through. So the game must have more than one room in the RAM after all, just a different part of RAM. Is my logic right?

I also want you to help me analyse, if you can, what happens when I do the [url=https://drive.google.com/file/d/0B6VbXOZpnj6MZjdRaFpuLUhwbnc/view?usp=sharing]OOB I showed earlier[/url]. Specifically what happens when you climb up a thing? I think it just nudges you forwards instantaneously at the very end of the animation (which is #267 when jumping up, then #268 for one frame). I'd forgotten I can just pause the game and buffer ESC every time to get it to advance one frame at a time. :D I presume #268 gives you a forwards boost, so how big is it?

Actually I think what's happening is this: the game does a projection of where the player will end up if they're allowed to climb up from where they're at. If the projection doesn't put them into a wall, they're allowed to climb. However, normally you're not stuck anywhere and the game will take into account your sliding along the wall (?) that you're facing during the actual jump. When I did the special climb, my movement parallel to the wall was being checked and so maybe that's the difference somehow. I'm trying to use a deep one in E5R7 to act as the "stopper" when getting on the jetty and I can sometimes make it work, but sadly it doesn't put me inside the corner I'm next to. Maybe because after I've climbed above its height, I'm no longer being checked from moving along the wall. I just end up on top of the monster instead.

Have you guys noticed this game has a pause button? :o Just press 'P' to freeze it and Space/INS to unfreeze. Jesus, I don't think I've ever tried using that with anything... If you pause, then release and depress 'p' again before hitting space, you can get a frame advance without entering the menu or inventory. It only works during regular gameplay, not when picking something up or in the menu or inventory. Only downside is you'll force the character to do whatever action they have selected.

Okay I found something hilarious AND potentially useful for speedruns. Just go down to E5 via study and jump into the stairs trigger. Hahaha. ([url=https://drive.google.com/file/d/0B6VbXOZpnj6MVlZTZTZ6N3gtdE0/view?usp=sharing]Save file[/url] if you need it). You can also drink the potion during the transition without having to wait for the animation for that. This works anywhere except you have to use e.g. the rifle's recoil so you have time to select the flask while moving towards the trigger. Otherwise you have to be very precise and drink the potion right before you lose control.

Someone might think [url=https://drive.google.com/file/d/0B6VbXOZpnj6MSDBfeDBMU0t4UGM/view?usp=sharing]this[/url] is of some use as well... I think NHG already found it at one point, but he just didn't know how to use it back then. I used the "hover mouse" method to find it BTW, proving that it works! The best part about it is the boulder will be removed when you return! You also can just run over the bridge which is left intact. Maybe getting the study key and sabre is better after all? :P NHG will have one helluva time testing all of this.

I think I'll just post this right now so you can read what I've written so far...

EDIT:

Aaaaannd [url=https://drive.google.com/file/d/0B6VbXOZpnj6MZzFGN2wtb1FScjA/view?usp=sharing]here's[/url] a faster way to get to the boss room. It's easy with the room viewer...