Alone in the Dark (1992 DOS)

tigrou

Edit history:

tigrou: 2016-03-19 04:25:22 pm

tigrou: 2016-03-19 04:24:16 pm

tigrou: 2016-03-19 06:53:37 am

tigrou: 2016-03-19 06:51:54 am

tigrou: 2016-03-19 06:50:23 am

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

tigrou: 2016-03-19 06:46:11 am

tigrou: 2016-03-19 04:02:54 am

tigrou: 2016-03-19 04:02:42 am

tigrou: 2016-03-19 04:02:05 am

tigrou: 2016-03-19 03:57:55 am

tigrou: 2016-03-19 03:55:49 am

tigrou: 2016-03-19 03:54:35 am

tigrou: 2016-03-19 03:50:36 am

tigrou: 2016-03-19 03:49:48 am

tigrou: 2016-03-19 03:26:20 am

tigrou: 2016-03-18 04:26:48 pm

tigrou: 2016-03-18 01:02:33 pm

tigrou: 2016-03-18 10:30:50 am

tigrou: 2016-03-18 10:30:22 am

tigrou: 2016-03-18 10:28:54 am

2016-03-18 10:28:21 am

@LotBlind : I already answer some of your questions. I will probably EDIT later and add more Smiley

Quote:

it sounds like botting except it doesn't produce an optimal path between the two places necessarily.

Yes, exactly, it is like a bot that do the speedrun for you. The path might or might not be optimal depending the steps you ask him to do. The bot is dummy: for example it does not try to find OOB. He just follows your orders : "go here, do a OOB here, take that object, do another OOB here...". If you ask the bot to go to position 1 then position 2, it will interpolate them by a straight line (which is, by definition, the shortest path between two points). You just have to make sure there is no collliders between those two points.

Since the game controls are simple (tank controls) it is probably feasible for such a bot to achieve similar performance as the one of a human player. In contrast, it would be very difficult (if not impossible) for a bot to be as good a human in a Quake speedrun.

Quote:

I see you suggested to get precise turning from this...

That was another approach : to not "autopilot" the game but have a list of key shortcuts to use to make the speedrun easier. Running by pressing a single key is one of them. I think Diablo3 players do this with AutoHotkey.

Quote:

Do you think there's any way to automate finding spots where you can clip?

Yes it would be possible in theory (but not easy). However you will probably get a lot of false positives. The real question is: will it be really useful ? I think you almost checked 99.9% percent of all the corners in E0-E4. The only remaining places are now in E5-E6. How much is left there ?

Quote:

I also want you to help me analyse, if you can, what happens when I do the OOB I showed earlier

Could you please send me a video of the room viewer during the glitch (with orthographic camera) ? it will be a lot easier to understand.

Quote:

Actually I think what's happening is this: the game does a projection of where the player will end up

You can summary OOB like this : first player need to be in contact with at minimum two boxes : eg : one actor and one collider, two colliders, ...
Then you have to think about the position where player will end up. This is in same direction as player angle and about same distance as player bounding box.
Then check which are the colliders for that new position : if there is only one (instead of two) then chance are there will be an OOB. The missing collider (the one that you were in contact before) will be the wall you will penetrate.

The order in which you check the boxes is very important. First you need to check the walls, then the actors. That order is important because the engine will fix/update player position if necessary between checks.

Quote:

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?

I'm not sure to fully understand what you mean. Do you mean that above a certain boderline your player position get clipped and you cannot reach some actors ?
In that case the explanation could be this : each actor (including player) store its position using 16-bit variables (thus only -32767 32768 range is possible)
That position stored in memory is not the actor global position (relative to the whole floor) but a local position, relative to the current actor room (so at 0,0,0 the actor should be near room center).

It might explain why some actors clip before some others (they has to be in different rooms btw).
Note that the player position shown in the viewer (in the up right corner) is the global position not the local one. It's done like this to have a easy way to reference any player position, regardless current room.

Quote:

Have you guys noticed this game has a pause button?

We know this since a long time, its written in the wiki Smiley

Quote:

What I said earlier about monsters being in a different room ...

You are right. I already explained that to NHG in a private discussion (in french) :

=> all rooms of a given floor are loaded in memory.
=> there is a notion of "active room" per actor. For a given actor, collisions against walls are checked only for the active room of that actor.
=> all actors are not loaded to memory. only actors which are in the same room as the actor referenced by CURRENT_TARGET (a global variable) are loaded to memory. By default CURRENT_TARGET is PLAYER. It mean actors are loaded depending where player go. Same for camera which is targeted on player. But the game can temporary change that variable (eg : when zombie poulet goes trough the window, or arrow in the gallery). So when CURRENT_TARGET = ARROW it's the arrow which decide which actors are loaded and the camera image to be set (depending the room where the arrow is).

Quote:

Just go down to E5 via study and jump into the stairs trigger. Hahaha.

LOL, mega jump!

@LotBlind : I already answer some of your questions. I will probably EDIT later and add more :)

[quote]it sounds like botting except it doesn't produce an optimal path between the two places necessarily.[/quote]
Yes, exactly, it is like a bot that do the speedrun for you. The path might or might not be optimal depending the steps you ask him to do. The bot is dummy: for example it does not try to find OOB. He just follows your orders : "go here, do a OOB here, take that object, do another OOB here...". If you ask the bot to go to position 1 then position 2, it will interpolate them by a straight line (which is, by definition, the shortest path between two points). You just have to make sure there is no collliders between those two points.

Since the game controls are simple (tank controls) it is probably feasible for such a bot to achieve similar performance as the one of a human player. In contrast, it would be very difficult (if not impossible) for a bot to be as good a human in a Quake speedrun.

[quote]I see you suggested to get precise turning from this... [/quote]
That was another approach : to not "autopilot" the game but have a list of key shortcuts to use to make the speedrun easier. Running by pressing a single key is one of them. I think Diablo3 players do this with AutoHotkey.

[quote]Do you think there's any way to automate finding spots where you can clip?[/quote]
Yes it would be possible in theory (but not easy). However you will probably get a lot of false positives. The real question is: will it be really useful ? I think you almost checked 99.9% percent of all the corners in E0-E4. The only remaining places are now in E5-E6. How much is left there ?

[quote]I also want you to help me analyse, if you can, what happens when I do the OOB I showed earlier[/quote]

Could you please send me a video of the room viewer during the glitch (with orthographic camera)  ? it will be a lot easier to understand.

[quote]Actually I think what's happening is this: the game does a projection of where the player will end up[/quote]
You can summary OOB like this : first player need to be in contact with at minimum two boxes : eg : one actor and one collider, two colliders, ...
Then you have to think about the position where player will end up. This is in same direction as player angle and about same distance as player bounding box.
Then check which are the colliders for that new position : if there is only one (instead of two) then chance are there will be an OOB. The missing collider (the one that you were in contact before) will be the wall you will penetrate.

The order in which you check the boxes is very important. First you need to check the walls, then the actors. That order is important because the engine will fix/update player position if necessary between checks.

[quote]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?[/quote]

I'm not sure to fully understand what you mean. Do you mean that above a certain boderline your player position get clipped and you cannot reach some actors ?
In that case the explanation could be this : each actor (including player) store its position using 16-bit variables (thus only -32767 32768 range is possible)
That position stored in memory is not the actor global position (relative to the whole floor) but a local position, relative to the current actor room (so at 0,0,0 the actor should be near room center).

It might explain why some actors  clip before some others (they has to be in different rooms btw).
Note that the player position shown in the viewer (in the up right corner) is the global position not the local one. It's done like this to have a easy way to reference any player position, regardless current room.

[quote]Have you guys noticed this game has a pause button?[/quote]
We know this since a long time, its written in the wiki :)

[quote]What I said earlier about monsters being in a different room ...[/quote]
You are right. I already explained that to NHG in a private discussion (in french) :

=> all rooms of a given floor are loaded in memory.
=> there is a notion of "active room" per actor. For a given actor, collisions against walls are checked only for the active room of that actor.
=> all actors are not loaded to memory. only actors which are in the same room as the actor referenced by CURRENT_TARGET (a global variable) are loaded to memory. By default CURRENT_TARGET is PLAYER. It mean actors are loaded depending where player go. Same for camera which is targeted on player. But the game can temporary change that variable (eg : when zombie poulet goes trough the window, or arrow in the gallery). So when CURRENT_TARGET = ARROW it's the arrow which decide which actors are loaded and the camera image to be set (depending the room where the arrow is).

[quote]Just go down to E5 via study and jump into the stairs trigger. Hahaha.[/quote]
LOL, mega jump!

LotBlind

2016-03-19 05:09:51 pm

E5 and E6 are nearly done as well, using the method of just "reading the map" it's easy and I consider it reliable too. I'm still manually checking exceptional places.

You can reproduce the OOB yourself (I have no convenient way to record on this computer), here's the instructions again:
- save file
- just run forwards and left so you hug the North wall of R2 and move slowly inside it
- when R2 has loaded, you should be inside the wall
- now turn to face the NE (100 degrees should work) and run through
- you should now be in R5 again but you fall through the wall; you're a bit N of the corner so you can turn around and start clipping towards the N
- clip clip clip until you can't go any further
- turn to face NW (225 degrees) and just tap forwards
- Emily should be inside the corner

"You can summary OOB like this" - sorry I was talking about the same OOB climb trick, not OOB in general. I think I fully understand the OOB.

Wrapping: yes I meant that I'm wrapping around the level. I forgot that the full map shown in the room viewer is not actually showing the actors in their in-memory locations. Yes that explains it.

What's written in the wiki is irrelevant. :| To be fair, I didn't know about the frame advance trick (and other potential uses) when I first found it so it wouldn't have seemed relevant.

E5 and E6 are nearly done as well, using the method of just "reading the map" it's easy and I consider it reliable too. I'm still manually checking exceptional places.

You can reproduce the OOB yourself (I have no convenient way to record on this computer), here's the instructions again:
- [url=https://drive.google.com/file/d/0B6VbXOZpnj6MaF9pdk5GWGVDb2c/view?usp=sharing]save file[/url]
- just run forwards and left so you hug the North wall of R2 and move slowly inside it
- when R2 has loaded, you should be inside the wall
- now turn to face the NE (100 degrees should work) and run through
- you should now be in R5 again but you fall through the wall; you're a bit N of the corner so you can turn around and start clipping towards the N
- clip clip clip until you can't go any further
- turn to face NW (225 degrees) and just tap forwards
- Emily should be inside the corner

"You can summary OOB like this" - sorry I was talking about the same OOB climb trick, not OOB in general. I think I fully understand the OOB.

Wrapping: yes I meant that I'm wrapping around the level. I forgot that the full map shown in the room viewer is not actually showing the actors in their in-memory locations. Yes that explains it.

What's written in the wiki is irrelevant. :| To be fair, I didn't know about the frame advance trick (and other potential uses) when I first found it so it wouldn't have seemed relevant.

tigrou

Edit history:

tigrou: 2016-03-21 05:28:35 am

tigrou: 2016-03-20 04:04:38 pm

tigrou: 2016-03-20 03:59:37 pm

tigrou: 2016-03-20 10:28:21 am

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

tigrou: 2016-03-20 10:11:24 am

tigrou: 2016-03-20 09:32:16 am

tigrou: 2016-03-20 09:27:15 am

tigrou: 2016-03-20 08:51:01 am

tigrou: 2016-03-20 08:50:39 am

tigrou: 2016-03-20 08:49:27 am

tigrou: 2016-03-20 08:48:50 am

tigrou: 2016-03-20 08:46:57 am

tigrou: 2016-03-20 08:45:57 am

tigrou: 2016-03-20 08:44:40 am

tigrou: 2016-03-20 08:43:24 am

tigrou: 2016-03-20 08:37:53 am

tigrou: 2016-03-20 08:37:45 am

tigrou: 2016-03-20 08:37:33 am

tigrou: 2016-03-20 08:37:02 am

tigrou: 2016-03-20 08:26:32 am

tigrou: 2016-03-20 08:26:05 am

tigrou: 2016-03-20 08:25:55 am

tigrou: 2016-03-20 08:06:44 am

tigrou: 2016-03-20 08:05:50 am

tigrou: 2016-03-20 08:05:02 am

tigrou: 2016-03-20 07:58:29 am

tigrou: 2016-03-20 07:57:45 am

tigrou: 2016-03-20 07:23:37 am

tigrou: 2016-03-20 07:15:35 am

tigrou: 2016-03-20 07:15:07 am

tigrou: 2016-03-20 07:02:07 am

tigrou: 2016-03-20 06:59:19 am

tigrou: 2016-03-20 06:58:27 am

tigrou: 2016-03-20 06:57:36 am

tigrou: 2016-03-20 06:56:28 am

tigrou: 2016-03-20 06:56:06 am

tigrou: 2016-03-20 06:55:28 am

tigrou: 2016-03-20 06:55:19 am

tigrou: 2016-03-20 06:54:07 am

tigrou: 2016-03-20 06:49:46 am

tigrou: 2016-03-20 06:49:34 am

tigrou: 2016-03-20 06:47:10 am

tigrou: 2016-03-20 06:15:21 am

tigrou: 2016-03-20 06:13:36 am

tigrou: 2016-03-20 06:13:30 am

tigrou: 2016-03-20 06:13:04 am

tigrou: 2016-03-20 06:11:56 am

tigrou: 2016-03-20 06:10:32 am

2016-03-20 06:09:38 am

I was able to reproduce the OOB. It's not easy thought. Great finding !
Also : the save file you provided does not work with floppy version of the game. loading it simply crash the game with a "out of memory". I had to use the CD version.

Here is (incomplete) explanation for some parts (there is many things you probably already know) :

- You can pass trough the wall that separate R2 and R5 because it belongs to R2 (which is not loaded at that time)
- Then since you are stuck in the wall the only possibility is to run (to NE). When running the predicted position is totally outside the wall and it teleport you there.
- What I don't understand is why you fall after (you are still at same level as the floor) and also why didn't you fall fully to water level ? You seems to be stuck in between (blue is water level, i explicitely move the floor block to be able to see the player).
- After that you are stuck (because colliding with the floor).
- Turning to the N and pressing up will make you climb because AFAIK the game logic is this : if player touch a collider with FLAGS = 3 and player height (Y position) is lower than height of the collider, climb on that collider. Note that you have to face that collider to make it happen.
- After that you use the left wall to clip to the N as much as possible. The game does not make you slide smoothly against that wall it as it would do usually because you are still colliding with the floor (the collider with FLAGS = 3).
- Once you reach the top, you turn to face NW and press forwards. Normally, you should just climb on the collider. However while climbing up, for a reason that i don't know you will get pushed against that collider. Because of this all the forward movement of the climbing is converted in lateral movement (as in OOB glitch) and you end up in the walls of the corner (see picture). If you go to the N or NE (not NW) you will successfully climb up : see this. Notice how the gap (in red) is small. When climbing up, it seems the collider only push you if predicted climbing position will collide with some walls.

As you said, when climbing, there is two animations : 267 and 268
Here is the movement values :
267: 0, 0, 238, 0, 0, 0, 819 (the climbing animation itself, 7 frames in total, not sure if it is forward or up movement)
268: 57 (one frame only. is it the small gap I was referring before ?). EDIT: It seems to be, player bounding box is 570 and that red line looks like 1/10 of it

EDIT : why did you throw away Strauss's "Blue Danube" disc in the water ? it's a fine piece of music Cheesy

I was able to reproduce the OOB. It's not easy thought. Great finding !
Also : the save file you provided does not work with floppy version of the game. loading it simply crash the game with a "out of memory". I had to use the CD version.

Here is (incomplete) explanation for some parts (there is many things you probably already know) :

- You can pass trough the wall that separate R2 and R5 because it belongs to R2 (which is not loaded at that time)
- Then since you are stuck in the wall the only possibility is to run (to NE). When running the predicted position is totally outside the wall and it teleport you there.
- What I don't understand is why you fall after (you are still at same level as the floor) and also why didn't you fall fully to water level ? [url=http://s15.postimg.org/wxhxr2n3f/222.png]You seems to be stuck in between[/url] (blue is water level, i explicitely move the floor block to be able to see the player).
- After that you are stuck (because colliding with the floor).
- Turning to the N and pressing up will make you climb because AFAIK the game logic is this : if player touch a collider with FLAGS = 3 and player height  (Y position) is lower than height of the collider, climb on that collider. Note that you have to face that collider to make it happen.
- After that you use the left wall to clip to the N as much as possible. The game does not make you slide smoothly against that wall it as it would do usually because you are still colliding with the floor (the collider with FLAGS = 3).
- Once you reach the top, you turn to face NW and press forwards. Normally, you should just climb on the collider. However while climbing up, for a reason that i don't know you will get pushed against that collider. Because of this all the forward movement of the climbing is converted in lateral movement (as in OOB glitch) and you end up in the walls of the corner (see [url=http://s30.postimg.org/5aua18stt/111.png]picture[/url]). If you go to the N or NE (not NW) you will successfully climb up : [url=http://s18.postimg.org/5xdqq0589/444.png]see this[/url]. Notice how the gap (in red) is small. When climbing up, it seems the collider only push you if predicted climbing position will collide with some walls.

As you said, when climbing, there is two animations : 267 and 268
Here is the movement values : 
267: 0, 0, 238, 0, 0, 0, 819 (the climbing animation itself, 7 frames in total, not sure if it is forward or up movement)
268: 57 (one frame only. is it the small gap I was referring before ?). EDIT: It seems to be, player bounding box is 570 and that red line looks like 1/10 of it

EDIT : why did you throw away Strauss's "Blue Danube" disc in the water ? it's a fine piece of music :D

LotBlind

Edit history:

LotBlind: 2016-03-23 01:10:29 pm

2016-03-20 03:00:25 pm

I guess you get bumped back into the wall because of that one frame with 819 movement: it's enough to take you past the wall collider and so it's exactly the same as an OOB. That super-high value might allow something else cool, will think about it more later.

My theory for why you only fall a little ways into the floor is this: the game will only check for z-collisions during the fall when you pass certain heights, because there's only a few different planes on which the floors can be laid on.

LotBlind

Edit history:

LotBlind: 2016-03-23 01:12:35 pm

2016-03-23 01:10:06 pm

Lol the Blue Danube SHOULD be in a body of water! Cheesy

I think it was to test if objects disappear in the water.

You can do the quick turn off a climb. Just let go of forwards.

Whenever you're OOB and you re-enter a room in E5 or E6, if you place yourself carefully along one of the seams between the floor blocks, you can usually then continue to clip along the seam. I just don't see how to utilize this because most of the time you wanna stay OOB for as long as you've reached your destination.

I actually found some more OOB spots! The first 5 are from E5R8 and some of them look kinda promising for the escape part of the run maybe. The 6th one NHG will be happy about as well, so long as he can pull it off, but if it's faster, it's still a helluva lot easier than the long OOB starting from E5R0. The long OOB skips having to go around the bend in the tunnel though... both ways the boulders will be gone. The 7th is not very useful probably but cool nonetheless, because it uses the same technique as in the difficult R5 OOB from before. The last one is just to show off a technique where you use seams between the floor blocks to move around the room. I wrote them all into the clips table as well with instructions so check those out if you like.

Lol the Blue Danube SHOULD be in a body of water! :D I think it was to test if objects disappear in the water.

You can do the quick turn off a climb. Just let go of forwards.

Whenever you're OOB and you re-enter a room in E5 or E6, if you place yourself carefully along one of the seams between the floor blocks, you can usually then continue to clip along the seam. I just don't see how to utilize this because most of the time you wanna stay OOB for as long as you've reached your destination.

I actually found [url=https://drive.google.com/file/d/0B6VbXOZpnj6MbkVkc3NDd0NkZkU/view?usp=sharing]some more OOB spots[/url]! The first 5 are from E5R8 and some of them look kinda promising for the escape part of the run maybe. The 6th one NHG will be happy about as well, so long as he can pull it off, but if it's faster, it's still a helluva lot easier than the long OOB starting from E5R0. The long OOB skips having to go around the bend in the tunnel though... both ways the boulders will be gone. The 7th is not very useful probably but cool nonetheless, because it uses the same technique as in the difficult R5 OOB from before. The last one is just to show off a technique where you use seams between the floor blocks to move around the room. I wrote them all into the clips table as well with instructions so check those out if you like.

tigrou

Edit history:

tigrou: 2016-03-24 10:22:51 am

tigrou: 2016-03-24 10:22:46 am

tigrou: 2016-03-24 10:22:40 am

tigrou: 2016-03-24 10:22:30 am

tigrou: 2016-03-24 08:41:09 am

tigrou: 2016-03-24 06:57:47 am

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

tigrou: 2016-03-24 06:06:39 am

tigrou: 2016-03-24 05:54:43 am

tigrou: 2016-03-24 05:53:58 am

tigrou: 2016-03-24 05:53:51 am

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

tigrou: 2016-03-24 05:51:35 am

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

tigrou: 2016-03-24 05:50:46 am

tigrou: 2016-03-24 05:46:58 am

2016-03-24 05:30:33 am

These are great findings. It's great that you continue working on this. Everything combined, the next speedrun will be crazy. Hope NHG will come back soon (he seems to be sleeping those days Smiley

)

Something that I never talk about (not directly speedrun related) : there is a AITD engine port called Free In The Dark (FITD). It was started by some guys around 2003 and it seems to be discontinued since 2009. AITD1 is supported but also 2 and 3 (only partially).

Project source : https://github.com/somaen/fitd-residualvm (README)
You can download a build here : http://www.oldgames.sk/en/game/alone-in-the-dark/download/1698/

Unfortunately, I only discovered that project very late (in mid february). It would have been very useful to me when I was trying to decipher AITD game data. However it was useful for making the model viewer and understanding how some parts of the game works.

If you want to try it : pressing enter to skip the intro seems to make it crash. I had to wait for the intro to be finished to play the game. Other than that it works. The code seems to be a direct decompilation of the original game and thus is pretty faithful to the original (expect some graphical/sound issues). The OOB glitch as we as we know it is working.

These are great findings. It's great that you continue working on this. Everything combined, the next speedrun will be crazy. Hope NHG will come back soon (he seems to be sleeping those days :) )

Something that I never talk about (not directly speedrun related) : there is a AITD engine port called Free In The Dark (FITD). It was started by some guys around 2003 and it seems to be discontinued since 2009. AITD1 is supported but also 2 and 3 (only partially).

Project source : https://github.com/somaen/fitd-residualvm ([url=https://github.com/somaen/fitd-residualvm/blob/master/README]README[/url])
You can download a build here : http://www.oldgames.sk/en/game/alone-in-the-dark/download/1698/

Unfortunately, I only discovered that project very late (in mid february). It would have been very useful to me when I was trying to decipher AITD game data. However it was useful for making the model viewer and understanding how some parts of the game works.

If you want to try it : pressing enter to skip the intro seems to make it crash. I had to wait for the intro to be finished to play the game. Other than that it works. The code seems to be a direct decompilation of the original game and thus is pretty faithful to the original (expect some graphical/sound issues). The OOB glitch as we as we know it is working.

LotBlind

2016-03-25 01:02:22 pm

That engine port... what's the point? I don't quite get why people make those, but maybe it was before DosBox achieved full compatibility or something. Anyway it isn't of any interest to me because we can't speedrun it Smiley

So once and for all, to do a quick turn, you have to have the turn key held down first, then performing an action with space. You can also do this while climbing. You then have to let go of space (with good timing) and it should happen.

I found YET MORE OOBS. OOBs for days... The common theme is getting right next to an adjacent collider and a corner while being on the floor right below so you can climb up. The angle to face to get far enough into the corner is about 60 degrees away from the direction of clipping (so the viewer will show 30). Sadly surviving some of them requires a flask. I don't think any of these ones are useful.

So basically looks like you can use any solid object to clip into virtually any convex corner as demonstrated here. It's also easy to clip into openings (like in the last clip), by which I mean open walls that lead into the next room, in such a way that makes you appear inside the wall. This makes a whole lot of new OOBs available, but luckily most of them take too long to set up and don't have to be documented really. It does have another (terrifying) implication: you can use any monster in the game to clip into any convex corner or through an opening, but dammit with the stupid range on their attacks... will probably have to stun them first.

I haven't been able to clip through at spots like this even if I try to align the seams perfectly (between the N side of the chest and the S end of the jetty). I think that's simply because of the way the clipping works.

A small thing: could you make the default mode in the room viewer be the one that shows you only the walls and camera angles for the room you're currently inside with transparent walls elsewhere? It's not just for me, I think that's also the least confusing mode for anyone messing around with it later on.

Found 1-2 ways to get inside the boss room slightly more efficient than before.

Is the script for the boss death like this: if player is in R6 and lantern hits collider with id 1 (and talisman is in place), trigger death?

Gonna take a break from AitD now.

That engine port... what's the point? I don't quite get why people make those, but maybe it was before DosBox achieved full compatibility or something. Anyway it isn't of any interest to me because we can't speedrun it :)

So once and for all, to do a quick turn, you have to have the turn key held down first, then performing an action with space. You can also do this while climbing. You then have to let go of space (with good timing) and it should happen.

I found [url=https://drive.google.com/file/d/0B6VbXOZpnj6MeS1TclFuWXF5elU/view?usp=sharing]YET MORE OOBS[/url]. OOBs for days... The common theme is getting [u]right next[/u] to an adjacent collider and a corner while being on the floor right below so you can climb up. The angle to face to get far enough into the corner is about 60 degrees away from the direction of clipping (so the viewer will show 30). Sadly surviving some of them requires a flask. I don't think any of these ones are useful.

So basically looks like you can use any solid object to clip into virtually any convex corner as demonstrated [url=https://drive.google.com/file/d/0B6VbXOZpnj6MUlpjcTRycWZ5Q3M/view?usp=sharing]here[/url]. It's also easy to clip into openings (like in the last clip), by which I mean open walls that lead into the next room, in such a way that makes you appear inside the wall. This makes a whole lot of new OOBs available, but luckily most of them take too long to set up and don't have to be documented really. It does have another (terrifying) implication: you can use any monster in the game to clip into any convex corner or through an opening, but dammit with the stupid range on their attacks... will probably have to stun them first.

I haven't been able to clip through at [url=https://drive.google.com/file/d/0B6VbXOZpnj6MbnZmdDRmYmxvUGs/view?usp=sharing]spots like this[/url] even if I try to align the seams perfectly (between the N side of the chest and the S end of the jetty). I think that's simply because of the way the clipping works.

A small thing: could you make the default mode in the room viewer be the one that shows you only the walls and camera angles for the room you're currently inside with transparent walls elsewhere? It's not just for me, I think that's also the least confusing mode for anyone messing around with it later on.

Found 1-2 ways to get inside the [url=https://drive.google.com/file/d/0B6VbXOZpnj6MdFNacFZiUDJROHc/view?usp=sharing]boss room[/url] slightly more efficient than before.

Is the script for the boss death like this: if player is in R6 and lantern hits collider with id 1 (and talisman is in place), trigger death?

Gonna take a break from AitD now.

tigrou

Edit history:

tigrou: 2016-04-25 09:14:23 am

tigrou: 2016-03-28 08:25:44 am

2016-03-28 08:17:13 am

Hi there,

I have some announcement to make : the source code of the room viewer is now available on GitHub !
Check here : https://github.com/tigrouind/AITD-roomviewer

It mean that other developers can take a look at it, improve it etc... and more importantly that source won't be lost.
I have also done the following small changes (from LotBlind suggestions):
- Cardinal angles are now shown as negative/positive
- Right-clicking on a actor (or a box) will display a small static info box in the bottom right. It's useful for checking some info while the actor is moving.
- Default view is transparent one

Like LotBlind : i'm going to take a break from this now and probably won't develop the viewer further. It has been a lot of fun developing that viewer btw. I will keep having an eye on the topic. Hope all that hard work (it concerns everybody) will allow you to make a new crazy speedrun of that game.

Quote:

Is the script for the boss death like this: if player is in R6 and lantern hits collider with id 1 (and talisman is in place), trigger death?

As far as I remember (I checked this long time ago) yes it's like that.

Hi there,

I have some announcement to make : the source code of the room viewer is now available on GitHub !
Check here : https://github.com/tigrouind/AITD-roomviewer

It mean that other developers can take a look at it, improve it etc... and more importantly that source won't be lost.
I have also done the following small changes (from LotBlind suggestions):
- Cardinal angles are now shown as negative/positive 
- Right-clicking on a actor (or a box) will display a small static info box in the bottom right. It's useful for checking some info while the actor is moving.
- Default view is transparent one

Like LotBlind : i'm going to take a break from this now and probably won't develop the viewer further. It has been a lot of fun developing that viewer btw. I will keep having an eye on the topic. Hope all that hard work (it concerns everybody) will allow you to make a new crazy speedrun of that game.

[quote]Is the script for the boss death like this: if player is in R6 and lantern hits collider with id 1 (and talisman is in place), trigger death?[/quote]
As far as I remember (I checked this long time ago) yes it's like that.

LotBlind

2016-04-03 12:50:43 pm

Okay I guess I'll post this now. Thanks for your great input tigrou! Have fun with whatever you do next... I'll be making the segmented run for sure after testing a few more things and then starting to calculate how long it takes to get to places.

Can you make another small change to the viewer maybe? At current the angle you're ahead of or behind one of the cardinal directions moves in an opposite direction to how the angles change in general... I'm not sure it's logical. Another suggestion: making the objects be prioritized so they never get covered up with other colliders - reason is because you can basically guess where the colliders are but the script-containing objects are often hidden. Also the viewer sometimes fails to highlight certain colliders when hovered over (namely walls that are in the same location as the adjacent room's walls).

Found a possibly faster way to clip out the boss room. This one's definitely non-SS because not only is a large part of it blind, you also have to have good sub-pixels to clip against the boss room door.

Looks like when you s/l while opening doors, you can end up being inside the door object. Not sure how to abuse.

E1: Here's another way to get OOB using what I call an entrance OOB (because you do so at the entrance to the next area). Definitely slower but cool.

So I took a look at what causes crashing exactly when you pass through where E1R4 is in R1 OOB. It looks like if you just HANG AROUND that general area for long enough, the viewer will lose track of every object including you (suggesting either DosBox memory is being corrupted or it has something to do with the shutdown routine) and the game will hang. Jesus! It's like it's really cursed. Bermuda rectangle. If you get the compulsive creep (movement you can't stop) and hit the window it crashes. If you run into the area right above the E4 room trigger it may hang then as well, but I'm starting to think it's not hitting any specific spot. If you skirt right next to that trigger it seems it's safe to just run through, tackle the stool through the wall (!) and get to the zone trigger.

If you hit the window from the N side it doesn't seem to hang. Afterwards I still got the creep and it hung a little later without me touching anything. Touching from the W it hung after a very short time. E side: smashed it and it didn't hang, but going around the window in circles got it to hang a little bit later.

I don't think there's anything to worry about so long as you don't stay in front of the window for too long. It hasn't hung at all whenever I just skirted right by the R4 box after activating R1. If you're coming from the E this means you have to time the little dip towards the S to hit the R1 trigger carefully but afterwards you just set the course due W and you should be able to clear the room. If you're counting the steps you could improve your consistency a lot.

Hmm... It does something hang when even kinda far from the window itself, whenever crossing the horizontal plane that it's on, but again, this gets avoided.

E2: If you could quickly get the knight to follow you you could lead him to the convex corner right next to him and use him to clip through faster. I think I know how to get him to do that: just let him hit you the first time he swings. It's the part that follows that's fun Wink

He has an attack that you basically can't interrupt. I think you could just right about squeeze through the wall (it works in principle) but the precision is hilarious. Either that or you s/l when you've clipped once and abuse the little interruption this creates to have just the time for a second step. I just managed to do it, so I guess I was right, but too much time is wasted luring the knight over I think.

Speaking of which it seems the s/l causes that interruption that I mentioned - maybe useful for avoiding getting hit somewhere else. I also just now noticed that you can apply the s/l trick to speed up collecting items from objects with animations, like chests or cabinets, which is great though not surprising news for segmented runs! Speeds up stuff like getting the sabre a bit.

I think there's something special about the Vagabond... When you run against it you can't slide at all, it cuts off all movement if you run into him at all. I'm thinking this might be because the way he clips around the place himself... maybe they found the player would easily clip into places when trying to run away from him and so they changed his properties without affecting anything else. Hahaha, something ironic about that. Anyway I can only use him for clipping for one clip step which probably requires pixels to align. I didn't see any real uses for it anyway.

I also considered doing this: get the knight's attention. Clip into OOB (fastest way) and enter library. Open the W doors to let the knight in. Now lure him towards the convex corner towards the N. After frolicking with the Vagabond and the knight for long enough I was able to get the knight to be in position to let me clip against him in the same way as before without the spectre messing shit up. The clip can be done with a s/l as I suggested but I don't think you can avoid triggering R2 because the gap is so small... possibly as Edward you could. If you could that's only the second way I know of to get OOB from the library...

I just realized you could exit the secret room a bit more efficiently when taking the OOB exit route like this: instead of collecting the talisman and running back to the door, just clip right back through and get to the secret room OOB, because you can pick it up through the wall just as well. This also makes routes that collect the study key a bit faster.

I now understand why the arrow sometimes wanders off erratically. It happens when it's moved into a different room from where you're at. It triggers the same room triggers that the PC does. This is why it's difficult or impossible to get it to enter the secret room without you yourself being in the library at the time. It'd have to first hit the library trigger "by accident" and then the secret room trigger, again, by accident while trying to home back inside the gallery where it sees you being. The problem with that is the triggers just aren't placed in such a way as to make that possible AFAICS. When monsters move from room to room, there's a specific spot they want to get to that's right through the door or entrance. So no matter which way the arrow hits the library trigger, it'll instantly veer clockwise (if it hit it from the S) or anti-clockwise (coming from the N) to get back to the gallery.

When it gets stuck in the North part of E2, that's because there's so many room triggers in there. Anyway, this is all good to know if someone wants to try an in-bounds run later.

Going to edit this until the next poster comes along.

Okay I guess I'll post this now. Thanks for your great input tigrou! Have fun with whatever you do next... I'll be making the segmented run for sure after testing a few more things and then starting to calculate how long it takes to get to places.

Can you make another small change to the viewer maybe? At current the angle you're ahead of or behind one of the cardinal directions moves in an opposite direction to how the angles change in general... I'm not sure it's logical. Another suggestion: making the objects be prioritized so they never get covered up with other colliders - reason is because you can basically guess where the colliders are but the script-containing objects are often hidden. Also the viewer sometimes fails to highlight certain colliders when hovered over (namely walls that are in the same location as the adjacent room's walls).

Found a [url=https://drive.google.com/file/d/0B6VbXOZpnj6MRWQ1cC1McTlKSDg/view?usp=sharing]possibly faster way[/url] to clip out the boss room. This one's definitely non-SS because not only is a large part of it blind, you also have to have good sub-pixels to clip against the boss room door.

Looks like when you s/l while opening doors, you can end up being inside the door object. Not sure how to abuse.

E1: Here's another [url=https://drive.google.com/file/d/0B6VbXOZpnj6MbVpqLTFDaFdBWlk/view?usp=sharing]way to get OOB[/url] using what I call an entrance OOB (because you do so at the entrance to the next area). Definitely slower but cool.

So I took a look at what causes crashing exactly when you pass through where E1R4 is in R1 OOB. It looks like if you just HANG AROUND that general area for long enough, the viewer will lose track of every object including you (suggesting either DosBox memory is being corrupted or it has something to do with the shutdown routine) and the game will hang. Jesus! It's like it's really cursed. Bermuda rectangle. If you get the compulsive creep (movement you can't stop) and hit the window it crashes. If you run into the area right above the E4 room trigger it may hang then as well, but I'm starting to think it's not hitting any specific spot. If you skirt right next to that trigger it seems it's safe to just run through, tackle the stool through the wall (!) and get to the zone trigger.

If you hit the window from the N side it doesn't seem to hang. Afterwards I still got the creep and it hung a little later without me touching anything. Touching from the W it hung after a very short time. E side: smashed it and it didn't hang, but going around the window in circles got it to hang a little bit later.

I don't think there's anything to worry about so long as you don't stay in front of the window for too long. It hasn't hung at all whenever I just skirted right by the R4 box after activating R1. If you're coming from the E this means you have to time the little dip towards the S to hit the R1 trigger carefully but afterwards you just set the course due W and you should be able to clear the room. If you're counting the steps you could improve your consistency a lot.

Hmm... It does something hang when even kinda far from the window itself, whenever crossing the horizontal plane that it's on, but again, this gets avoided.

E2: If you could quickly get the knight to follow you you could lead him to the convex corner right next to him and use him to clip through faster. I think I know how to get him to do that: just let him hit you the first time he swings. It's the part that follows that's fun ;) He has an attack that you basically can't interrupt. I think you could just right about squeeze through the wall (it works in principle) but the precision is hilarious. Either that or you s/l when you've clipped once and abuse the little interruption this creates to have just the time for a second step. I just managed to do it, so I guess I was right, but too much time is wasted luring the knight over I think.

Speaking of which it seems the s/l causes that interruption that I mentioned - maybe useful for avoiding getting hit somewhere else. I also just now noticed that you can apply the s/l trick to speed up collecting items from objects with animations, like chests or cabinets, which is great though not surprising news for segmented runs! Speeds up stuff like getting the sabre a bit.

I think there's something special about the Vagabond... When you run against it you can't slide at all, it cuts off all movement if you run into him at all. I'm thinking this might be because the way he clips around the place himself... maybe they found the player would easily clip into places when trying to run away from him and so they changed his properties without affecting anything else. Hahaha, something ironic about that. Anyway I can only use him for clipping for one clip step which probably requires pixels to align. I didn't see any real uses for it anyway.

I also considered doing this: get the knight's attention. Clip into OOB (fastest way) and enter library. Open the W doors to let the knight in. Now lure him towards the convex corner towards the N. After frolicking with the Vagabond and the knight for long enough I was able to get the knight to be in position to let me clip against him in the same way as before without the spectre messing shit up. The clip can be done with a s/l as I suggested but I don't think you can avoid triggering R2 because the gap is so small... possibly as Edward you could. If you could that's only the second way I know of to get OOB from the library...

I just realized you could exit the secret room a bit more efficiently when taking the OOB exit route like this: instead of collecting the talisman and running back to the door, just clip right back through and get to the secret room OOB, because you can pick it up through the wall just as well. This also makes routes that collect the study key a bit faster.

I now understand why the arrow sometimes wanders off erratically. It happens when it's moved into a different room from where you're at. It triggers the same room triggers that the PC does. This is why it's difficult or impossible to get it to enter the secret room without you yourself being in the library at the time. It'd have to first hit the library trigger "by accident" and then the secret room trigger, again, by accident while trying to home back inside the gallery where it sees you being. The problem with that is the triggers just aren't placed in such a way as to make that possible AFAICS. When monsters move from room to room, there's a specific spot they want to get to that's right through the door or entrance. So no matter which way the arrow hits the library trigger, it'll instantly veer clockwise (if it hit it from the S) or anti-clockwise (coming from the N) to get back to the gallery.

When it gets stuck in the North part of E2, that's because there's so many room triggers in there. Anyway, this is all good to know if someone wants to try an in-bounds run later.

Going to edit this until the next poster comes along.

NHG

2016-04-03 01:21:05 pm

Shut up and go back to another earth

Hoy there !

I wasn't here for few weeks, busy with boring real life stuff. I kept reading the posts though and saw that LotBlind found some new improvments, again. Not sure to understand wich one are useful/can be used without the viewer. I'm gonna begin to play hard I think, but before that I need to be sure of what things I have to add and/or change comparing to my last run.

Let's see...

-The clip in the attic
-New talisman path of course (gotta try to exit it by using the method you explain up above but I don't understand why it would be faster =o )
-Clip to the right in the maze
-Use faster way to reach Pregzt room

So far I don't remember if there is anything else. With everything LotBlind showed, I didn't quiet see if there was an efficient (faster and without viewer) way to reach the maze by OOB. Is there ? Am i missing something else ?

LotBlind

Edit history:

LotBlind: 2016-04-03 01:32:20 pm

2016-04-03 01:30:03 pm

If you s/l while throwing something it doesn't make the animation last a shorter time, because a corresponding delay is added to the animation. Similarly if you try to s/l while getting something like the rifle from the chest in the loft, while it will skip ahead in the animation of the lid lifting, there's still the same delay before it gives you the item pick-up prompt.

I noticed when you open the medicine cabinet in E1, you have control over the character during the door opening and can rotate, making getting the flask a bit faster.

NHG: please don't rush this okay? Tongue

We have to consider sabre routes etc. before thinking about what's SS and what's segmented-only. I can't think of anything else to do with the game at this point so I guess I'm ready to start timing stuff. If you want to help me with that, I'll start a new ~~Google sheets file~~ some kind of workflow chart and give you alternatives that you can time, but I'm ready to do all of that myself as well. BTW I just rediscovered a new way to OOB in E3, it's the one listed last. Better than some alternatives but not sure if best.

Another reason not to rush it is you really have to work to make stuff work in the blind - specifically there might have been camera transitions along the way that you could trigger from OOB and make it more reasonable that way.

You missed the best way to enter E6 - the one whose explanation starts "clip E until you're in R9, then turn to clip back W". It's very tough to get the positioning right but perhaps not impossible. I think it's a huge time save, surely. Enough to justify having to try 2-3 times.

If you s/l while throwing something it doesn't make the animation last a shorter time, because a corresponding delay is added to the animation. Similarly if you try to s/l while getting something like the rifle from the chest in the loft, while it will skip ahead in the animation of the lid lifting, there's still the same delay before it gives you the item pick-up prompt.

I noticed when you open the medicine cabinet in E1, you have control over the character during the door opening and can rotate, making getting the flask a bit faster.

NHG: please don't rush this okay? :P We have to consider sabre routes etc. before thinking about what's SS and what's segmented-only. I can't think of anything else to do with the game at this point so I guess I'm ready to start timing stuff. If you want to help me with that, I'll start a new [s]Google sheets file[/s] some kind of workflow chart and give you alternatives that you can time, but I'm ready to do all of that myself as well. BTW I just rediscovered a new way to OOB in E3, it's the one listed last. Better than some alternatives but not sure if best.

Another reason not to rush it is you really have to work to make stuff work in the blind - specifically there might have been camera transitions along the way that you could trigger from OOB and make it more reasonable that way.

You missed the best way to enter E6 - the one whose explanation starts "clip E until you're in R9, then turn to clip back W". It's very tough to get the positioning right but perhaps not impossible. I think it's a huge time save, surely. Enough to justify having to try 2-3 times.

NHG

2016-04-03 02:04:55 pm

Shut up and go back to another earth

Enter E6 => Isn't it the thing that I ask about ? The efficient way to reach the maze by OOB ? The one where you clip in E5R7 ? If it is not, yes indeed I missed that x)

Sabre path ? Even after watching everything you found, I did not have the feeling that such a path was profitable even with the viewer to light the path =o But if you say so, maybe I underrated some clips, and of course I'm ready to test with you. I should be totally available for the 2 next weeks so, just give me things to record/time x)

It may be sad to say but I really hope there won't really be any long"blind-tricks" potentially conceivable in SS; I won't have fun at all trying to learn a path blindly x/ Anyway, let's time everything first ^^

LotBlind

Edit history:

LotBlind: 2016-04-03 03:09:44 pm

LotBlind: 2016-04-03 03:09:19 pm

2016-04-03 03:05:55 pm

tigrou: Hey if you want to help us more, would it be easy for you to do the maths for turning 180 degrees? I mean that it's probably fastest to completely stop so you can rotate at 2x speed, start running somewhere slightly past the 90 degree point, but how far exactly? Doing a max quick-turn and just continuing to run from there is the fastest ofc but it's not always possible to utilize.

need to test:
- what's the exact technique for quick turning (especially in cases like the lantern where you just run into the thing, do you need to have open/search selected?), how much time saved in a 180 turn compared to standstill rotation and then running: here's a clip of me doing it but is this really the fastest in such situations? It's not 100% optimized I think.
- s/l saves how much time per door (I can test all the s/l tricks)?
- how much time lost per changing actions
- how much time per changing views, is it constant?
- how much time to select and use an object (average, range)

For my run, what I'll do is use the viewer to grind out perfect execution in the blind to see how fast something could potentially be done. Then I'll aim for something like 95% as good in my actual segments. This is the only way to really test two closely matched routes as well, but ofc if one is really consistent and the other one not at all, you'll already know which one you're doing and so it doesn't concern you.

I'm creating a flow chart now, here's some of the early stuff. When paths converge, we have to take into account that the last part of the different alternatives to get to a certain point might leave you facing a different direction or be a little closer or further from the next goal so that has to be accounted for whenever two routes are almost matched. Also if you see that a path is considerably slower than the fastest alternative without getting anything in return, getting a very exact time on it isn't as important.

"+ action" means time taken for switching actions there (same everywhere) and -oil means the same without getting the oil (i.e. the "answer" is e.g. -5 seconds)

tigrou: Hey if you want to help us more, would it be easy for you to do the maths for turning 180 degrees? I mean that it's probably fastest to completely stop so you can rotate at 2x speed, start running somewhere slightly past the 90 degree point, but how far exactly? Doing a max quick-turn and just continuing to run from there is the fastest ofc but it's not always possible to utilize.

need to test:
- what's the exact technique for quick turning (especially in cases like the lantern where you just run into the thing, do you need to have open/search selected?), how much time saved in a 180 turn compared to standstill rotation and then running: here's a [url=https://drive.google.com/file/d/0B6VbXOZpnj6Md3NNVm1ETDhuV0k/view?usp=sharing]clip of me doing it[/url] but is this really the fastest in such situations? It's not 100% optimized I think.
- s/l saves how much time per door (I can test all the s/l tricks)?
- how much time lost per changing actions
- how much time per changing views, is it constant?
- how much time to select and use an object (average, range)

For my run, what I'll do is use the viewer to grind out perfect execution in the blind to see how fast something could potentially be done. Then I'll aim for something like 95% as good in my actual segments. This is the only way to really test two closely matched routes as well, but ofc if one is really consistent and the other one not at all, you'll already know which one you're doing and so it doesn't concern you.

I'm creating a flow chart now, here's [url=https://drive.google.com/file/d/0B6VbXOZpnj6MclUzZHg4aXcxeVU/view?usp=sharing]some of the early stuff[/url]. When paths converge, we have to take into account that the last part of the different alternatives to get to a certain point might leave you facing a different direction or be a little closer or further from the next goal so that has to be accounted for whenever two routes are almost matched. Also if you see that a path is considerably slower than the fastest alternative without getting anything in return, getting a very exact time on it isn't as important.

"+ action" means time taken for switching actions there (same everywhere) and -oil means the same without getting the oil (i.e. the "answer" is e.g. -5 seconds)

NHG

2016-04-05 09:35:46 am

Shut up and go back to another earth

I'm not sure to understand some of the things you want to test here =o "time per changing actions/hanging views/select and use an object" ? I mean, what's the point to know that if, at the end, we still need to do those actions anyway ? Isn'it faster to just theorize at first all possible routes (wich seem promising), time them and finally compare ?

Also, "-oil means the same without getting the oil", why would we time such an alternative ? Isn't the oil needed to degeat Pregzt ? Or probably I misunderstood what you said

tigrou

2016-04-06 02:00:33 am

@LotBlind : what do you mean by "do the maths for turning 180 degrees". What do you think could be calculated in order to improve the understanding the quick turn ?
Could you explain that trick again (how to reproduce it) ?

LotBlind

2016-04-06 09:38:50 am

Do you like the chart format? Because I'm thinking I should just make maps instead for simplicity. In fact I've started taking screenshots today. tigrou: I'm wondering if you could implement completely detaching the viewer camera so it's never repositioned when I change rooms? That would help me get perfect room-by-room shots to stop there being a kind of jarring effect.

NHG: testing for how long exactly the view changes last is important so we know how much time we save by going OOB and avoiding camera transitions... save for changing actions: how are we supposed to know if a route is viable if it has a different number of action changes to another one? The thing is, you might want to change the routes a little bit later on to account for something you didn't think of before (the game is so short that it might not happen but still), and you don't want to have to do the same exact difficult test again just with that one little difference like changing actions. The most important thing for me is how much time I'm saving with each s/l door animation skip - I can just remove that time from whatever any real-time tests have shown. In any case it's not a big effort dude Tongue

You probably just forgot that there's another can of oil (and matches) elsewhere in the game, if you do the library in the dark. So no you're not going to be doing it.

tigrou: okay so there's places where we're going to be doing an OOB and then hitting a trigger for some room. If we then need to do a full 180, you could either:
1) Do a quick turn. This is not going to be any faster than normal standing rotation though if you don't simultaneously use it to pick up some item or something like that.
2) Stop. Do a 180. Run. This, however, will probably be wasting time because in reality you will want to start moving before you've covered a full 180, maybe something like 110 degrees. This is why I'm asking you if you can work out what that fastest angle is (i.e. when should you start running). In case you've forgotten, rotation is slower when running and so the angle is not 90 degrees. Furthermore the earlier you start to run, the further you're veering off to the side which increases the total length of the path you're covering. I know that a lot will depend on the specifics of each turn, e.g. if there's a wall right next to you the optimal angle will be different, but having some basic numbers in front of you helps to plan your movements anyway.
3) Keep running. This is mostly bad because a) you're moving in a direction you don't want to be moving in and b) you're rotating slower and c) you're veering off course. Sometimes after a transition the game will have so much lag though, that it becomes super difficult to get Emily to run again, which is why NHG might have to do this somewhere.

I hope that makes it clearer.

Do you like the chart format? Because I'm thinking I should just make maps instead for simplicity. In fact I've started taking screenshots today. tigrou: I'm wondering if you could implement completely detaching the viewer camera so it's never repositioned when I change rooms? That would help me get perfect room-by-room shots to stop there being a kind of jarring effect.

NHG: testing for how long exactly the view changes last is important so we know how much time we save by going OOB and avoiding camera transitions... save for changing actions: how are we supposed to know if a route is viable if it has a different number of action changes to another one? The thing is, you might want to change the routes a little bit later on to account for something you didn't think of before (the game is so short that it might not happen but still), and you don't want to have to do the same exact difficult test again just with that one little difference like changing actions. The most important thing for me is how much time I'm saving with each s/l door animation skip - I can just remove that time from whatever any real-time tests have shown. In any case it's not a big effort dude :P

You probably just forgot that there's another can of oil (and matches) elsewhere in the game, if you do the library in the dark. So no you're not going to be doing it.

tigrou: okay so there's places where we're going to be doing an OOB and then hitting a trigger for some room. If we then need to do a full 180, you could either:
1) Do a quick turn. This is not going to be any faster than normal standing rotation though if you don't simultaneously use it to pick up some item or something like that.
2) Stop. Do a 180. Run. This, however, will probably be wasting time because in reality you will want to start moving before you've covered a full 180, maybe something like 110 degrees. This is why I'm asking you if you can work out what that fastest angle is (i.e. when should you start running). In case you've forgotten, rotation is slower when running and so the angle is not 90 degrees. Furthermore the earlier you start to run, the further you're veering off to the side which increases the total length of the path you're covering. I know that a lot will depend on the specifics of each turn, e.g. if there's a wall right next to you the optimal angle will be different, but having some basic numbers in front of you helps to plan your movements anyway.
3) Keep running. This is mostly bad because a) you're moving in a direction you don't want to be moving in and b) you're rotating slower and c) you're veering off course. Sometimes after a transition the game will have so much lag though, that it becomes super difficult to get Emily to run again, which is why NHG might have to do this somewhere.

I hope that makes it clearer.

tigrou

Edit history:

tigrou: 2016-04-08 01:26:20 pm

tigrou: 2016-04-08 12:46:06 pm

tigrou: 2016-04-08 12:45:56 pm

tigrou: 2016-04-07 03:56:30 am

tigrou: 2016-04-07 03:56:12 am

tigrou: 2016-04-07 03:55:46 am

tigrou: 2016-04-07 03:55:35 am

tigrou: 2016-04-07 03:55:22 am

tigrou: 2016-04-07 03:22:09 am

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

2016-04-07 03:10:32 am

Yesterday i tried the "quick turn" trick : I pressed right turn key, then while turn key was down, I held space bar (current action was fighting) then I released the space bar .
what it does : when space bar is down, it freeze player rotation animation. when released, player model suddenly rotate.
it is like when space bar is down, 3D model stop rotating but in memory, player continues to rotate. when press bar is released, 3D model is updated again.
However it does not seems faster to me than normal rotation. maybe i missed something.
Same about rotating player when running : not sure its really slower. Again, I might be wrong.

EDIT : I have uploaded a new version with camera changes you suggested.

NHG

2016-04-08 04:16:40 pm

Shut up and go back to another earth

Oil can => Yup, totally forgot, I'm not even abble to remember where it is now ahah I am soooo stuck in the actual item path... Where is the other can ? Kitchen or something like that ?

Okay so I feel like I just misunderstood what you asked earlier, but I'm still not sure about how I have to proceed to do the tests. I mean, for exemple you want me to time the action "open menu=>Actions=> Search" ? Wont it be the same time averytime (depending of runner hability of course) ? Same thing for items, the time'll always be the same depending of its position in the list. I think you know that so my best conclusion is that I don't understand your expectations xD So instead of asking you tons of stupid questions, let's try this: Just describe me what you want me to record/time, I mean with the precise context of the sequence.

For exemple, I don't know: "Start E3 stairs=>go kitchen=> take soup=> OOB in E3R13, stop when you reach the room"

If you order me such a list of things to try it wont be possible for me to misunderstand you and do sh*t x)

Tigrou: I think what you describe can be observed when you open a door or do some other actions (climbing). For exemple I know as a matter of fact that when I open a door I always release Right/left button before touching it because if I don't, the game kind saved how much the player was supposed to turn. Player wont turn during the animation of door opening but once it's finished, player rotation saved before'll be loaded and he'll execute an instant rotation. It is very disturbing when it happens and it often made me miss a move when I played the game. Especially two spots: E1R5 door (as I turn right it makes me enter the room instead of running the the clip angle) and E5R10 when I climb for the 2nd time (most of the time this one makes me fall into water x) ). It's kinda hard to predict how much you "stock" a rotation when it happens though, with E1R5 door I really had the feeling that the "unseen" rotation is a lot faster than if you actually turned during a classic run move. If you want I can try to record a sequence with the thing happening.

Oil can => Yup, totally forgot, I'm not even abble to remember where it is now ahah I am soooo stuck in the actual item path... Where is the other can ? Kitchen or something like that ?

Okay so I feel like I just misunderstood what you asked earlier, but I'm still not sure about how I have to proceed to do the tests. I mean, for exemple you want me to time the action "open menu=>Actions=> Search" ? Wont it be the same time averytime (depending of runner hability of course) ? Same thing for items, the time'll always be the same depending of its position in the list. I think you know that so my best conclusion is that I don't understand your expectations xD So instead of asking you tons of stupid questions, let's try this: Just describe me what you want me to record/time, I mean with the precise context of the sequence.

For exemple, I don't know: "Start E3 stairs=>go kitchen=> take soup=> OOB in E3R13, stop when you reach the room"

If you order me such a list of things to try it wont be possible for me to misunderstand you and do sh*t x)

Tigrou: I think what you describe can be observed when you open a door or do some other actions (climbing). For exemple I know as a matter of fact that when I open a door I always release Right/left button before touching it because if I don't, the game kind saved how much the player was supposed to turn. Player wont turn during the animation of door opening but once it's finished, player rotation saved before'll be loaded and he'll execute an instant rotation. It is very disturbing when it happens and it often made me miss a move when I played the game. Especially two spots: E1R5 door (as I turn right it makes me enter the room instead of running the the clip angle) and E5R10 when I climb for the 2nd time (most of the time this one makes me fall into water x) ). It's kinda hard to predict how much you "stock" a rotation when it happens though, with E1R5 door I really had the feeling that the "unseen" rotation is a lot faster than if you actually turned during a classic run move. If you want I can try to record a sequence with the thing happening.

LotBlind

2016-04-09 10:47:46 am

tigrou: quick turn: yeah I knew all that already... it's faster in situations where something happens in-between starting the action (e.g. item dialogue pops up) because during that time you're not normally able to rotate. Really I'm looking for deeper insights about all this stuff, on the level of code or mathematics, if you're able to provide any. I don't know how to explain it any clearer though. Maybe I'll draw a picture later.

Rotation when running or walking is twice slower than when standing still.

Thanks for the extra camera mode! I'll take a new set of shots when I'm less ill.

NHG: The other oil can can be quickly OOBd through the kitchen if your route goes there. Just read all the OOB clip stuff and you'll know. Ask me if there's questions left.

Otherwise, you should test to see how long it takes every time you perform certain repeatable actions - e.g. just tell me how fast it's possible to perform changing actions. This will depend on which action you choose, so test it for the 1st option (fighting) and also for the last option (5th one in caverns) and we'll have a range of times that this action can take. This allows us to take an existing route, modify it slightly and "time it" again by just adding or subtracting the correct length of time without having to do any additional tests. It's smart.

Also test for how fast you can select an item that's the first in the inventory, and one that's further down (maybe 10th) which will, again, give us a range.

Then test for how long a door opening animation takes until you have control again. Does it depend on your exact positioning?

Then: when you've started the open/search animation, the script says (as tigrou found out) that it will wait until the animation has went through one cycle before actually doing anything, e.g. opening the chest. For this reason it's actually slightly better not to run all the way to the thing you're about to interact with but rather right next to it so when you touch it is around the same time as the end of the animation (something I'll try to optimize every time). Anyway, you could test how long that wait is. Then test how fast you can select "pick it up" or "leave it" during the dialogue.

Then how long does the game pause for when you move from one view to another. Does this vary? Test at least 10 different view changes on a few different floors. If there's variations try to figure out what they correlate with. I don't think we'll need this information necessarily but it's more professional to have tested it nonetheless, and will maybe help you with some future game.

I know some of these things will take just frames longer or shorter than otherwise, but it helps to get in the habit anyway. You might pick up some patterns, and it makes your runs feel much smarter cause you can say you thought about everything. It can also put things into proportion - e.g. how much time are you really losing if you do something that stops your running somewhere? You'll have to use a program that lets you see frame-by-frame, e.g. VLC has that feature, but it doesn't show you which frame you're looking at. Actually it doesn't matter, just frame advance to get a frame count, these things don't last that long. The game seems to have a frame rate of around 25... so one frame lasts some 0.04 seconds. Here's how to find the feature in VLC.

I just posted a clip with the quick turn already Tongue

BTW did you think of using the door quick turn to your benefit anywhere or is the rotation always too big?

tigrou: quick turn: yeah I knew all that already... it's faster in situations where something happens in-between starting the action (e.g. item dialogue pops up) because during that time you're not normally able to rotate. Really I'm looking for deeper insights about all this stuff, on the level of code or mathematics, if you're able to provide any. I don't know how to explain it any clearer though. Maybe I'll draw a picture later.

Rotation when running or walking is twice slower than [i]when standing still[/i].

Thanks for the extra camera mode! I'll take a new set of shots when I'm less ill.

NHG: The other oil can can be quickly OOBd through the kitchen if your route goes there. Just read all the OOB clip stuff and you'll know. Ask me if there's questions left.

Otherwise, you should test to see how long it takes every time you perform certain repeatable actions - e.g. just tell me how fast it's possible to perform changing actions. This will depend on which action you choose, so test it for the 1st option (fighting) and also for the last option (5th one in caverns) and we'll have a range of times that this action can take. This allows us to take an existing route, modify it slightly and "time it" again by just adding or subtracting the correct length of time without having to do any additional tests. It's smart.

Also test for how fast you can select an item that's the first in the inventory, and one that's further down (maybe 10th) which will, again, give us a range.

Then test for how long a door opening animation takes until you have control again. Does it depend on your exact positioning?

Then: when you've started the open/search animation, the script says (as tigrou found out) that it will wait until the animation has went through one cycle before actually doing anything, e.g. opening the chest. For this reason it's actually slightly better not to run all the way to the thing you're about to interact with but rather right next to it so when you touch it is around the same time as the end of the animation (something I'll try to optimize every time). Anyway, you could test how long that wait is. Then test how fast you can select "pick it up" or "leave it" during the dialogue.

Then how long does the game pause for when you move from one view to another. Does this vary? Test at least 10 different view changes on a few different floors. If there's variations try to figure out what they correlate with. I don't think we'll need this information necessarily but it's more professional to have tested it nonetheless, and will maybe help you with some future game.

I know some of these things will take just frames longer or shorter than otherwise, but it helps to get in the habit anyway. You might pick up some patterns, and it makes your runs feel much smarter cause you can say you thought about everything. It can also put things into proportion - e.g. how much time are you really losing if you do something that stops your running somewhere? You'll have to use a program that lets you see frame-by-frame, e.g. VLC has that feature, but it doesn't show you which frame you're looking at. Actually it doesn't matter, just frame advance to get a frame count, these things don't last that long. The game seems to have a frame rate of around 25... so one frame lasts some 0.04 seconds.[url=http://www.ehow.com/how_8291171_frame-frame-vlc.html] Here's how[/url] to find the feature in VLC.

I just posted a clip with the quick turn already :P BTW did you think of using the door quick turn to your benefit anywhere or is the rotation always too big?

LotBlind

2016-04-13 11:02:31 am

tigrou: I think there's a bug - when you hit "f" to get free camera, it changes it back to follow rooms mode afterwards. I don't know why but the first time I launched 0.99 it looked like it worked fine.

If you're going to make the next version 1.00, may I suggest you add just two things: a button you can hit to show/hide all the key commands in the viewer itself, and a brief notification up top to tell you what you just did. It makes a lot of sense to call the next revision v. 1.00 because it will be the first public one. I'd like to suggest we publish/announce everything at once - the Single Segment run, the Segmented run, and the Viewer. I will also want to make an extra video showing some weird and goofy things in the game. We can talk about commentaries etc. once the speedruns are finished.

Speaking of, here's a complete set of screenshots! I will be using these from now on to show routes. I wonder if I can get them hosted directly on the site...

tigrou: I think there's a bug - when you hit "f" to get free camera, it changes it back to follow rooms mode afterwards. I don't know why but the first time I launched 0.99 it looked like it worked fine.

If you're going to make the next version 1.00, may I suggest you add just two things: a button you can hit to show/hide all the key commands in the viewer itself, and a brief notification up top to tell you what you just did. It makes a lot of sense to call the next revision v. 1.00 because it will be the first public one. I'd like to suggest we publish/announce everything at once - the Single Segment run, the Segmented run, and the Viewer. I will also want to make an extra video showing some weird and goofy things in the game. We can talk about commentaries etc. once the speedruns are finished.

Speaking of, here's a [url=https://drive.google.com/folderview?id=0B6VbXOZpnj6MZDROa1g4Vld4bXc&usp=sharing]complete set of screenshots[/url]! I will be using these from now on to show routes. I wonder if I can get them hosted directly on the site...

LotBlind

2016-04-14 10:50:31 am

I just randomly did the quick turn getting the lantern on the first try, and I can now say for sure that you do NOT have to use space at all. It is as I suspected, just a question of timing it. I think it's important to let go of forwards right before you get the item dialogue.

I used the screenshots to make this. Feedback? Luckily there shouldn't be too too many viable OOB routes so I only have to make so many of them.

tigrou

Edit history:

tigrou: 2016-05-01 09:50:10 am

tigrou: 2016-04-25 06:01:43 am

tigrou: 2016-04-15 04:24:15 am

tigrou: 2016-04-15 02:06:26 am

tigrou: 2016-04-15 02:00:46 am

2016-04-15 01:58:23 am

Hi there !
I took at look at quick turn. Here is what I found out :

Rotation :
- When standing still, player rotate at 180 degrees per second.
- When walking/running, player rotate at 90 degrees per second (half the speed).
- Rotation is immediate, there is no acceleration or deceleration. It is like a on/off button. If you watch player 3D model rotating, it seems like player is not moving at same speed (especially up and bottom body parts). However its only a part of the model animation. If you watch the arrow in the viewer you will see its moving at constant speed.

Quick turn :
- Max rotation angle you can achieve during a quick turn is 90 degrees.
- The final rotation angle depends of two things :
1) the amount of time that elapsed between the moment you start pressing left (or right) arrow and space bar.
2) the amount of time you hold space bar before releasing it.

The quick turn glitch/feature is due to how the game interpolates angles to make sure the player rotates at same rate regardless the computer speed. There is a short passage in the GDC12 video when Frederick Raynal talks about that.

To summarize, in order to maximize quick turn angle you should :
1) press left (or right) arrow
2) immediately press space bar after
3) wait 0.5 second or more (the time needed to rotate 90 degrees).
4) release space bar

Something that I found out : if you press space bar while having the bow in your hand, player will rotate very slowly.

About the room viewer :
"F" is no more a on/off option. It has now three possible states. See readme for details.
I agree that the actual way of setting options in the viewer could be improved.
Maybe it would be great to create some kind of menu with differents options (eg: switch to model viewer, settings, exit etc...), like in video games.

The maps with OOB path alternatives you posted are great. They allow to understand OOB paths without having to read big blocks of text.

Hi there !
I took at look at quick turn. Here is what I found out :

[b]Rotation : [/b]
- When standing still, player rotate at 180 degrees per second.
- When walking/running, player rotate at 90 degrees per second (half the speed).
- Rotation is immediate, there is no acceleration or deceleration. It is like a on/off button. If you watch player 3D model rotating, it seems like player is not moving at same speed (especially up and bottom body parts). However its only a part of the model animation. If you watch the arrow in the viewer you will see its moving at constant speed.

[b]Quick turn : [/b]
- Max rotation angle you can achieve during a quick turn is 90 degrees.
- The final rotation angle depends of two things :
1) the amount of time that elapsed between the moment you start pressing left (or right) arrow and space bar.
2) the amount of time you hold space bar before releasing it.

The quick turn glitch/feature is due to how the game interpolates angles to make sure the player rotates at same rate regardless the computer speed. There is a short passage in the GDC12 video when Frederick Raynal talks about that.

To summarize, in order to maximize quick turn angle you should :
1) press left (or right) arrow
2) immediately press space bar after
3) wait 0.5 second or more (the time needed to rotate 90 degrees).
4) release space bar

Something that I found out : if you press space bar while having the bow in your hand, player will rotate very slowly.

About the room viewer :
"F" is no more a on/off option. It has now three possible states. See readme for details.
I agree that the actual way of setting options in the viewer could be improved.
Maybe it would be great to create some kind of menu with differents options (eg: switch to model viewer, settings, exit etc...), like in video games.

The maps with OOB path alternatives you posted are great. They allow to understand OOB paths without having to read big blocks of text.

LotBlind

2016-04-15 06:25:14 am

I think you're still getting confused with walking and standing still Smiley

You meant "when standing still" it's 180/s, when walking or running, it's 90/s.

quick turn: sounds about right. So it's ½ second for 90 degrees? And 90 is the max? good to know. Pick-up dialogues etc. last longer than that so the limiting factor becomes something else though.

Soooo much code for something so simple Cheesy

That's why I'm not in programming. Not entirely sure what I've learned from it actually, you can easily see the effect in-game (and it wasn't difficult to notice the correlation between how long you held space and the rotation). Not that it matters in the slightest, but your code seems to have fixed 4 quadrants instead of defining the 90 degree turns based on the starting angle of the rotation.

I'm sorry I made you spend time on that - to be perfectly honest it's not quite what I was asking you about, but at least I hope it wasn't too much effort for you.

Shiiiitt, I've been a bloody fool. You do NOT let go of forwards when grabbing the lantern.
1) Run towards the table, start turning to the left.
2) When the dialogue pops up, you can freely let go of both keys so you can give the correct input (in this case space).
3) After giving the input, you hit forwards and left again, and no matter how long they were left undepressed, you WILL get both a quick turn and get to keep running.

The same technique applies elsewhere. If you have to use space in-between to issue a command, just make sure you've held down both keys before hitting space and they'll get "stored". Now I think I finally get this thing. I still don't think you can preserve a run or get a quick turn when descending stairs.

What's more difficult, and I'm not sure if it's doable, is to get less than 90 degrees during a dialog if you wanted that. NHG: how do you do a quick turn when opening doors (without using space to do that?)

Note to self: if you're already holding down movement keys when hitting 'p' for pausing, it unpauses when letting go of 'p' without having to hit the action key.

Note to self: you can open doors at angles that immediately place you against the door for clipping.

For the record you can also get the game you interpolate forwards/backwards stuff in the exact same way. However, I don't think this can be exploited (the underlying physics checks are probably still running) because surely we would have seen something like that many times by now. It does mean if you needed to get, say, the book off the E2R7 table, then run to the clock, you could start turning towards the clock and just slightly brush against the table to get the book while getting a bit of extra forwards distance from it. On the other hand that's exactly how we would have done that anyway Tongue

I think the slow rotation applies to all weapons as I remember.

tigrou: I understand what the new 'F' does, I'm just saying it's got weird logic that's difficult to follow. I think it's because when you hit PGUP/PGDN it cause it to start snapping to rooms even when it's technically supposed to be following Emily. When you hit 'F' the first time after doing that it gets the focus on Emily, then hit it again and it freecams correctly. Maybe could you make it so when you have follow player on and you switch rooms it'll switch rooms [and focus on them] but when you move the PC in-game it shows her location again? I'm not quite sure. In any case if it had indications of what mode you're in this wouldn't be a problem I'm sure.

Another OOB diagram.

I think you're still getting confused with walking and standing still :) You meant "when standing still" it's 180/s, when walking or running, it's 90/s.

quick turn: sounds about right. So it's ½ second for 90 degrees? And 90 is the max? good to know. Pick-up dialogues etc. last longer than that so the limiting factor becomes something else though.

Soooo much code for something so simple :D That's why I'm not in programming. Not entirely sure what I've learned from it actually, you can easily see the effect in-game (and it wasn't difficult to notice the correlation between how long you held space and the rotation). Not that it matters in the slightest, but your code seems to have fixed 4 quadrants instead of defining the 90 degree turns based on the starting angle of the rotation.

I'm sorry I made you spend time on that - to be perfectly honest it's not quite what I was asking you about, but at least I hope it wasn't too much effort for you.

Shiiiitt, I've been a bloody fool. You do NOT let go of forwards when grabbing the lantern.
1) Run towards the table, start turning to the left.
2) When the dialogue pops up, you can freely let go of both keys so you can give the correct input (in this case space).
3) After giving the input, you hit forwards and left again, and no matter how long they were left undepressed, you WILL get both a quick turn and get to keep running.

The same technique applies elsewhere. If you have to use space in-between to issue a command, just make sure you've held down both keys before hitting space and they'll get "stored". Now I think I finally get this thing. I still don't think you can preserve a run or get a quick turn when descending stairs.

What's more difficult, and I'm not sure if it's doable, is to get less than 90 degrees during a dialog if you wanted that. NHG: how do you do a quick turn when opening doors (without using space to do that?)

Note to self: if you're already holding down movement keys when hitting 'p' for pausing, it unpauses when letting go of 'p' without having to hit the action key.

Note to self: you can open doors at angles that immediately place you against the door for clipping.

For the record you can also get the game you interpolate forwards/backwards stuff in the exact same way. However, I don't think this can be exploited (the underlying physics checks are probably still running) because surely we would have seen something like that many times by now. It does mean if you needed to get, say, the book off the E2R7 table, then run to the clock, you could start turning towards the clock and just slightly brush against the table to get the book while getting a bit of extra forwards distance from it. On the other hand that's exactly how we would have done that anyway :P

I think the slow rotation applies to all weapons as I remember.

tigrou: I understand what the new 'F' does, I'm just saying it's got weird logic that's difficult to follow. I think it's because when you hit PGUP/PGDN it cause it to start snapping to rooms even when it's technically supposed to be following Emily. When you hit 'F' the first time after doing that it gets the focus on Emily, then hit it again and it freecams correctly. Maybe could you make it so when you have follow player on and you switch rooms it'll switch rooms [and focus on them] but when you move the PC in-game it shows her location again? I'm not quite sure. In any case if it had indications of what mode you're in this wouldn't be a problem I'm sure.

[url=https://drive.google.com/file/d/0B6VbXOZpnj6MenFwclh4RE9HVHc/view?usp=sharing]Another OOB diagram.[/url]

tigrou

Edit history:

tigrou: 2016-04-16 02:24:25 pm

tigrou: 2016-04-16 02:23:38 pm

tigrou: 2016-04-16 02:22:04 pm

tigrou: 2016-04-16 02:20:54 pm

tigrou: 2016-04-16 05:18:33 am

tigrou: 2016-04-15 11:39:07 am

tigrou: 2016-04-15 09:00:08 am

tigrou: 2016-04-15 08:59:51 am

tigrou: 2016-04-15 08:58:49 am

tigrou: 2016-04-15 08:58:35 am

tigrou: 2016-04-15 08:47:03 am

tigrou: 2016-04-15 08:16:18 am

tigrou: 2016-04-15 08:16:07 am

tigrou: 2016-04-15 08:15:30 am

tigrou: 2016-04-15 08:14:34 am

tigrou: 2016-04-15 08:11:06 am

tigrou: 2016-04-15 08:07:41 am

tigrou: 2016-04-15 08:06:42 am

tigrou: 2016-04-15 08:05:42 am

tigrou: 2016-04-15 08:05:26 am

tigrou: 2016-04-15 08:04:44 am

tigrou: 2016-04-15 08:03:52 am

tigrou: 2016-04-15 07:42:05 am

2016-04-15 07:41:51 am

Quote:

your code seems to have fixed 4 quadrants instead of defining the 90 degree turns based on the starting angle of the rotation.

This is like that because this how the game works. Internally, it also has those quadrants. Those quadrants explain why sometimes, after a quick turn your rotated less than 90 degrees (despite you held SPACE for a long time).

If you want to see them in the real game, you can try the following : decrease the number of CPU cycles in DOSBOX to something very low like 500 cycles. Then press left or right. The player should now only move by big chunks of 90 degrees. You will also realize that those quadrants are not especially aligned with cardinal directions. They "slide" when LEFT or RIGHT key get down.

Quote:

I'm sorry I made you spend time on that

Well, at least now, quick turn should have no more secrets.

'F' key : OK, maybe there is a bug/improvement to be made there, i will check that when I will have time.

EDIT : I have put a new version with a upgraded interface which should make the setup of options easier. I have also took a look at problems with F key and camera (there is now two separate options for this). Please give it a try if you can. Feedback and suggestions are welcome.

[quote]your code seems to have fixed 4 quadrants instead of defining the 90 degree turns based on the starting angle of the rotation.[/quote]
This is like that because this how the game works.  Internally, it also has those quadrants. Those quadrants explain why sometimes, after a quick turn your rotated less than 90 degrees (despite you held SPACE for a long time).

If you want to see them in the real game, you can try the following : decrease the number of CPU cycles in DOSBOX to something very low like 500 cycles. Then press left or right. The player should now only move by big chunks of 90 degrees. You will also realize that those quadrants are not especially aligned with cardinal directions. They "slide" when LEFT or RIGHT key get down.

[quote]I'm sorry I made you spend time on that[/quote]
Well, at least now, quick turn should have no more secrets.

'F'  key : OK, maybe there is a bug/improvement to be made there, i will check that when I will have time.

EDIT : I have put a new version with a upgraded interface which should make the setup of options easier. I have also took a look at problems with F key and camera (there is now two separate options for this). Please give it a try if you can. Feedback and suggestions are welcome.

NHG

Edit history:

NHG: 2016-04-21 04:07:38 pm

2016-04-21 12:48:29 pm

Shut up and go back to another earth

Quick door turn: Just reaching a door while pressing right or left, then keep pressing it during the animation. To answer your question, I did not try to use this trick simply because it's perfectly useless with all of the doors I interact with during the run (wich is something like 6, probably a lot less with the next one). I mean, when I open a door either I clip in the corner (and yes, if you come to the door with an angle, it'll put you directly in the clip corner) and I don't need a phantom rotation, or I have to pass the door and in this case a rotation'll be as useless just because... Well because even if there was a bend after the door, I first have to... Pass the door before turning x). As I said, when it happens I have the feeling the phantom turn is really quick. Sometimes I kept pressing a rotation button during less than 0.5 sec and still I'll make an huge rotation.

I'm not sure to have good programs to time THAT precisely but I'll give a shot. Sony Vega can play frame per frame so it should be fine with that. I am doing it tonight. Still not comfortable with the idea though, as I have the feeling that the time difference between two possible paths'll be huge enough to not considerate those micro-sequences as something who could make a difference *-) But anyway, your wish my lord xp

I also tested some of the new shortcuts you found in E5&6. Did not test the "complicated OOB way" to reach E6R0, only the easy way from E5R7. At first I did not understand how it worked but when I did, I found it really clever: use wall vanishing to pass under it before the room is loaded. You are a sneaky man mr. Blind ! Still a chance to screw up before reaching the maze by loading E5R9 at the wrong place but it should be okay with a spacious turn. The faster way to reach boss room is more complicated though, at least without the viewer. Maybe I can use some cameras to make it simpler, or simply remember a piece of wall as a point of entrance, I'll watch that tonight too.

So if I understand what you explained, the quick turn should be in fzct really easy to use, good new x)

Edit: Is there a way to reach the key in R7 starting from R8 ? I tried the "complicated path" in E5 and I managed to do it without the viewer (still hard though) but this path only worth it if it's possible to grab the key without a big detour (or being abble to reach R11 fastly without the key)

Quick door turn: Just reaching a door while pressing right or left, then keep pressing it during the animation. To answer your question, I did not try to use this trick simply because it's perfectly useless with all of the doors I interact with during the run (wich is something like 6, probably a lot less with the next one). I mean, when I open a door either I clip in the corner (and yes, if you come to the door with an angle, it'll put you directly in the clip corner) and I don't need a phantom rotation, or I have to pass the door and in this case a rotation'll be as useless just because... Well because even if there was a bend after the door, I first have to... Pass the door before turning x). As I said, when it happens I have the feeling the phantom turn is really quick. Sometimes I kept pressing a rotation button during less than 0.5 sec and still I'll make an huge rotation.

I'm not sure to have good programs to time THAT precisely but I'll give a shot. Sony Vega can play frame per frame so it should be fine with that. I am doing it tonight. Still not comfortable with the idea though, as I have the feeling that the time difference between two possible paths'll be huge enough to not considerate those micro-sequences as something who could make a difference *-) But anyway, your wish my lord xp

I also tested some of the new shortcuts you found in E5&6. Did not test the "complicated OOB way" to reach E6R0, only the easy way from E5R7. At first I did not understand how it worked but when I did, I found it really clever: use wall vanishing to pass under it before the room is loaded. You are a sneaky man mr. Blind ! Still a chance to screw up before reaching the maze by loading E5R9 at the wrong place but it should be okay with a spacious turn. The faster way to reach boss room is more complicated though, at least without the viewer. Maybe I can use some cameras to make it simpler, or simply remember a piece of wall as a point of entrance, I'll watch that tonight too.

So if I understand what you explained, the quick turn should be in fzct really easy to use, good new x)

Edit: Is there a way to reach the key in R7 starting from R8 ? I tried the "complicated path" in E5 and I managed to do it without the viewer (still hard though) but this path only worth it if it's possible to grab the key without a big detour (or being abble to reach R11 fastly without the key)