Experienced Forum User, Published Author, Player
(56)
Joined: 4/6/2015
Posts: 5
MESHUGGAH wrote:
1. 1:38 Leaving Oil Can room: Is it possible to clip through the door (actor)?
After some check, it's not possible to clip through that door (and it's not listed in the worksheet I gave you as well).
Even if it would be possible, doing it might take more time than actually opening the door (or did you had something else in mind ?)
MESHUGGAH wrote:
2. 2:12 Going to the library through walls: wouldn't the room you just exited be next to the Talisman room? I'm unsure because of all the camera position changes.
edit: Going from the Matchbox room instead of from the Stairway hall room
It's not that simple :) Game loads one room at a time and the triggers enabled at that time can only load the adjacent rooms.
Because of that, you can't go out of bounds from one side of the floor and drop at the opposite side (far away).
MESHUGGAH wrote:
Thanks again for the informations and I hope I didn't wasted your time... speaking of it.... Some day would like to watch an encode of the room viewer tool running for this TAS.
I think you are going to enjoy this video that I made.
Experienced Forum User, Published Author, Player
(56)
Joined: 4/6/2015
Posts: 5
MESHUGGAH wrote:
1. Did you develop your own tools to make this TAS? Personally I really love the effort and work you put in your (first) TAS, god damn impressive!
Yes, I made those tools (including the room viewer). Those tools were initially made for improving NHG run and studying the game engine in general. This has also been used by Arnaud for his Time Gate runs. What you see on the left side is room viewer in action.
MESHUGGAH wrote:
2. Did you read NHG's notes about the route? He made a list of possible improvements to his run on this page:
I'm aware of those notes. By the way, those have been written by LotBlind, not NHG. You can see in the "Routing" section of this TAS which one I used.
The only tricks that I did not use are the ones that mention doors/inventory (not sure if it's applicable in this run or if it helps), and the one that mention E3R5. This one it not clear to me, I think it's related to another route.
MESHUGGAH wrote:
3. Would like to know a little bit more in-depth knowledge about going through walls.
Interestingly, the reason I got interest into that game about 10 years ago is same as you : I look at a run (NHG one) and was wondering how it was possible to go out of bounds.
TL;DR
This happen mostly in corners and it's dependent of the order of the walls (which is tighten to how it's stored in the game data).
Someone (don't remember who) has made a list of possible places for going OOB.
More detailed explanation :
You can clip through the walls because the naive approach the game handle collisions.
The way it works is simply by checking each wall against player next position and cancelling X or Y movement until there is no more collisions.
Cancelling X or Y movement is simple but it works because walls are always orthogonal. However, this might fail in corners where you have multiple walls.
Depending the order the walls are checked, you might still end up colliding with a wall after cancelling X or Y movement and the game to not detect this.
The effect of cancelling X or Y movement is to "push" you away from a wall. Unfortunately this might also push you into a wall you checked before (thus leaving you penetrating that wall).
There is more info in the guide.
Experienced Forum User, Published Author, Player
(56)
Joined: 4/6/2015
Posts: 5
alexheights1 wrote:
Can saving the game interrupt jump? Saving the game could be faster than dropping the item?
I have tried and it does not work (it does not interrupt the jump).
Dropping an item itself is not time consuming btw. Most of the time is spent for entering menus (which would also be needed for saving the game).
alexheights1 wrote:
With so many glitches is it not possible to corrupt a save file to trigger the ending?
Good question. I have been thinking recently about possibility to trigger the ending by loading a corrupted save (that would have been hex edited before, as a proof of concept)
Maybe it's possible to corrupt a save within the game by forcing too much items to be loaded in the inventory. There is 2 things that came to my mind : forcing VAR33 to be set to 1 (this would allow to use main doors without beating final boss) or arbitrary code execution (then you can do pretty much do anything).
The guide has many crashes documented but none of them where able to do something useful.
alexheights1 wrote:
Can you jump to move during the cutscene?
During the cutscene there is a flag being set that prevents you doing most things with the keyboard (including jumping). You can't enter inventory anymore which is required to jump after throwing or dropping an object.
alexheights1 wrote:
Can you not thrown the lamp first and then insert the talisman?
Good idea. I have tried quickly and wasn't able to do so.
The major issue is you will spend some time in the inventory (to drop the talisman) and once you exit it, the lamp will go forward by a big chunk (the same as the amount of time that elapsed in inventory), making the lamp hit the final boss before talisman is in place (one frame right after you exit inventory).
alexheights1 wrote:
Can you delay throwing the lamp so that you can open the door with the hook during the fire cutscene?
I have been thinking about throwing the lamp from far away but issue is you can only do that from a trigger that is near the final boss.
alexheights1 wrote:
The final battle against the tree looks like the most complex sequence of events in the whole run so maybe you could find some way to do it faster? Maybe walk backwards so that the knockback is useful?
I have tried that already. If you get knocked backwards, you get indeed get a push towards the exit but then you have to turn by 180 degrees to pursue the run and it takes a long time.
alexheights1 wrote:
Does the fireball hit the player's head? Looks funny!
Yes, but for whatever reason, she does not take any damage (probably because it occurs during a fall).
Experienced Forum User, Published Author, Player
(56)
Joined: 4/6/2015
Posts: 5
eien86 wrote:
Hi Tigrou, unfortunately I am not able to sync your movie.
Here is my INI file. Only cdrom_path and hdc_fn have been modified (compared to Early 90's config).
100 FPS is used. Here is the MD5 hashes calculated from my installation, should be the same as in annotations.
I have re-downloaded the movie I uploaded on tasvideos.org (just to be sure) and it play nicely to the end.
The file gd5430.bin ROM is different from what is suggested in tasvideos. I use 7138354ba08f606ba51df60c18015635 while tasvideos recommend d4ba691ce5e04d950ca7624050e6b409.
Tasvideos file is for pcem v16 rom set, here v17 is used. The one from tasvideos will produce visual glitches in text mode (visible during game installation). I discussed this with feos and he told me v17 was the right one to use. I have the old file (starting with d4ba691c) named as gd5430.bin1 in my rom folder. I don't think it has any consequences.
pb570.nvr : tasvideos mention 9228bf13f3fe46351b1885e073558b67 but I'm not sure from where it came from. The one I used is from the Early 90's package, which is 4c885df878a4c302e1050232f4b3c866. Is this the reason you can't sync it ? I wish I had seen that discrepancy before.
flash.bin : I use a script that delete the file .pcem/roms/pb570/flash.bin before any run. I have checked and it's not there (in case script wouldn't work).
Experienced Forum User, Published Author, Player
(56)
Joined: 4/6/2015
Posts: 5
CoolKirby wrote:
Is this due to the aforementioned FPS issue or is the (133MHz) processor too fast?
High FPS. This makes the player move in smaller increments. So small player often ends up touching the trigger (that goes back the other way) once the animation is over. Unlike many games, AITD doesn't use a fixed update loop (eg: the number of tics between frames is constant, regardless of FPS). Instead, it measures the elapsed time between frames and moves actors accordingly.
CoolKirby wrote:
If it's the latter, maybe the Late 80s config (or another processor between 16-133 MHz) would run the game better. Though, game setup might take much longer.
The main problem is that loading the resources will take much longer. There are +100 2D backgrounds loadings during the run and each of them take time (about 10 seconds in total). I don't know how long this would take on a 386, but it should be 40 seconds or more. The reason why it's so slow is those are stored in PAK archives which are compressed.
There have been some experiments using the most powerful tasvideos configuration (PII @450) to make loading even faster, but there are problems with running action. Running requires the up key to be released for a maximum of 3 frames. With such a configuration, the FPS skyrockets every 2 seconds, making it impossible to trigger running in some cases (even with frame advance). v17+st-2 does not have such issue (as FPS are limited) so it should be possible to use such a config.