 Issue Data
|
|
||||||||||||||||||||||||||||||
Issue #22809: Unlocking doors from terminals causes delay
Related Issues: 22467
This is currently being investigated. It may fix the symptoms but we aren't sure yet whether it also fixes the actual cause.
For example, terminals DO NOT share the same scripts. They share the code, but are running separate instances (with their own sets of values for properties and variables). [same as the difference between base form and object reference, btw; i.e. with that logics applied, all refs to the same form would move in the worldspace if you move one of them]. Thus, since there is no communication between scripts on terminals that are not related to each other, it is unclear how modifications of one terminal would fix all others. It's more likely that there's something more fundamentally wrong.
For example, terminals DO NOT share the same scripts. They share the code, but are running separate instances (with their own sets of values for properties and variables). [same as the difference between base form and object reference, btw; i.e. with that logics applied, all refs to the same form would move in the worldspace if you move one of them]. Thus, since there is no communication between scripts on terminals that are not related to each other, it is unclear how modifications of one terminal would fix all others. It's more likely that there's something more fundamentally wrong.
No idea what role it plays in this, but the save attached to Issue #22712 lists the following Papyrus stack when the dps command is called:
As it happens, 001A4489 is the reference to the terminal at Federal Ration Stockpile.
I have the same stack dump in my own save.
[10/12/2017 - 01:56:53PM] Dumping stack 902435: [10/12/2017 - 01:56:53PM] Frame count: 1 (Page count: 1) [10/12/2017 - 01:56:53PM] State: Running (Freeze state: Freezing) [10/12/2017 - 01:56:53PM] Type: Normal [10/12/2017 - 01:56:53PM] Return register: None [10/12/2017 - 01:56:53PM] Has stack callback: Yes [10/12/2017 - 01:56:53PM] Has unbind object: Yes [10/12/2017 - 01:56:53PM] Stack trace: [10/12/2017 - 01:56:53PM] [ (000DEA36)].Fragments:Terminals:TERM_nativeSwitchDoorTermina_000DEA36.Fragment_Terminal_02() - "g:\_F4\Art\Raw\Scripts\Fragments\Terminals\TERM_nativeSwitchDoorTermina_000DEA36.psc" Line 26 [10/12/2017 - 01:56:53PM] IP: 392 Instruction: 8 Line: 26 [10/12/2017 - 01:56:53PM] [akTerminalRef]: [ObjectReference < (001A4489)>] [10/12/2017 - 01:56:53PM] [::temp7]: [Default2StateActivator < (00022117)>] [10/12/2017 - 01:56:53PM] [::temp10]: True [10/12/2017 - 01:56:53PM] [myDoor]: [Default2StateActivator < (00022117)>] [10/12/2017 - 01:56:53PM] [::temp11]: True [10/12/2017 - 01:56:53PM] [::nonevar]: None [10/12/2017 - 01:56:53PM] [::temp12]: [Default2StateActivator < (00022117)>]
As it happens, 001A4489 is the reference to the terminal at Federal Ration Stockpile.
I have the same stack dump in my own save.
Comment #2 Oct 12, 2017 4:06 pm
Edited by Arthmoor on Oct 12, 2017 4:24 pm
After testing the esp with the linkage fix, I have determined that it does in fact stop the production of continuous stack dumps for that security door. I can't tell if it's done anything to address the general feeling of delay when opening a maglock but at least now it won't be hogging up stack time in an endless loop.
The reason for this appears to be because the security doors all have a setting for a "native terminal" and most of them point back to nativeSwitchDoorTerminal. That terminal then points to the submenu terminal nativeTurretTerminalSubMenu. On that submenu terminal is where the script fragment resides. So it's entirely possible that the game is seeing this as a single terminal everywhere that controls doors. Once 00022117 got going it got caught in a linked list loop with 0002210D on the other side of the storage room. The doors would open but then it would just sit there on the stack pinging back and forth between the 2 security doors.
As soon as the endless linkage was broken, the script disappeared from the stack. Both doors will still open properly in the cell so this fix does in fact seem solid. It's quite likely most other door setups don't have a linked pair like this which is why it never showed up anywhere else.
The reason for this appears to be because the security doors all have a setting for a "native terminal" and most of them point back to nativeSwitchDoorTerminal. That terminal then points to the submenu terminal nativeTurretTerminalSubMenu. On that submenu terminal is where the script fragment resides. So it's entirely possible that the game is seeing this as a single terminal everywhere that controls doors. Once 00022117 got going it got caught in a linked list loop with 0002210D on the other side of the storage room. The doors would open but then it would just sit there on the stack pinging back and forth between the 2 security doors.
As soon as the endless linkage was broken, the script disappeared from the stack. Both doors will still open properly in the cell so this fix does in fact seem solid. It's quite likely most other door setups don't have a linked pair like this which is why it never showed up anywhere else.
Showing Comments 1 - 3 of 3