Door near the smithy in the castle of the Old Camp is inaccessible

[AmProsius]

Describe the bug
The smith's door cannot not be opened, because it references a key that does not exist.

Expected behavior
The door near the smithy in the castle of the Old Camp is now accessible with the correct key which can now be obtained in Stone's cell in the dungeon of the Old Camp.

Additional context
The key to the smithy's door does not work because the door references a wrong key instance name: ITKEY_OB_SMITH_01 does not exist. It needs to be changed to ItKe_OB_Smith_01.

Implementation
This issue was merged with #47. We supply our own G1CP copy of the key instance to allow saving and loading. When removing G1CP the then invalid instance will automatically vanish on loading. If reinstalling G1CP the key instance will be re-added (given the conditions to do so are met).

Flowchart

flowchart TD
    A["Is door valid?\n(identified, locked,\nhas incorrect key instance)"]
    B["No such key instance exists\n(could have been added by a mod\nto fix the issue the other way around)"]
    C[Does the G1CP key already\nexist in the world?]
    D[Adjust the key instance\nof the door]
    E["return True\n(fix applied)"]
    F(" ")
    F1["return False\n(fix not applied)"]
    G["Can key be inserted?\n(waypoint exists)"]
    H["Is story progressed enough?\n(ExploreSunkenTower == True)"]
    I["Insert the key\n(in Stone's cell)"]
    J["Will story variable be set in expected function?\n(ExploreSunkenTower mentioned\nin B_Story_ExploreSunkenTower?)"]
    K[Hook after the story function\nto run this here function again\nand to insert the key then]
    M["Is door valid (identified, has\nupdated G1CP key instance)"]
    N[Adjust the key instance\nfor the door]
    O["return False\n(fix not reverted)"]
    P["return True\n(fix reverted)"]

    subgraph Revert
        M -- True --> N --> P
        M -- False ---> O
    end

    subgraph Apply
        A -- False --- F
        A -- True --> B
        B -- False --- F
        B -- True --> C
        C -- True --> D
        C -- False --> G
        D ----> E
        G -- False --- F
        subgraph Insert key
            G -- True --> H
            H -- True --> I
        end
        subgraph Implement later
            H -- False --> J
            J -- True --> K
        end
        I -- Success ---> D
        I --- |"Failed\n(unlikely)"| F
        J -- False --- F
        K ----- F
        F --> F1
    end

    style Apply fill:none,stroke-width:0.5px
    style Revert fill:none,stroke-width:0.5px
    style F fill:none,stroke:none,stroke-width:0px
    style F1 stroke-width:6px
    style E stroke-width:6px
    style O stroke-width:6px
    style P stroke-width:6px

(G1CP key vanishes automatically if loading a game save without G1CP active)

In short, the fix (i.e. adjusting the door) will only be applied if

1. the door has the incorrect key instance
2. there is no such key instance in the script
3. the story has progressed far enough

Would the story be changed somewhat (the variables renamed) the entire fix would not be applied.

[catalinstoian]

gothic-1-community-patch/scriptbase/_work/Data/Scripts/Content/Items/MissionItems_1.d

Lines 1132 to 1134 in 2164a25

	//SCHMIEDESCHLÜSSEL ERZBARONE
	INSTANCE ItKe_OB_Smith_01(C_Item)
	{

changed to

//SCHMIEDESCHLÜSSEL ERZBARONE
INSTANCE ITKEY_OB_SMITH_01(C_Item)
{	

[szapp]

Where is this item located in the world? Is it lying around somewhere or does an NPC have in their inventory?

It might be easier to leave the item untouched and change its name in the conditions of the door. Could you give some context about the key? (Does the player receive it? Is it story relevant? Which door exactly does it open? ...)

[AmProsius]

After digging into this I would suggest to close the issue without changing anything. The label doesn't occur as a bug to me as there are many keys that start with ItKe_. There's actually only one exception and that is ItKey_RB_01 (the Ricelord's key).

As far as I know the key doesn't spawn at all (see #47), so the smithy would remain locked for the entire game.

[szapp]

I think the name of this instance matters to work with the door it was made for. If the door specifies a different instance name, the key will not work.

What was the initial purpose of renaming the key? Does it not work on the door it is meant for? In that case, I would suggest to adjust the door-property.

[AmProsius]

I can't find any match for ITKEY_OB_SMITH_01 in the scripts. How can I check the property of the door?

[szapp]

@AmProsius That could be done with the spacer. That is quite tedious, however. I can have a look soon, by writing a script and checking in the running game. Could you tell me which is the door in question (a screenshot, waypoint or a rough description - any of those options should suffice)?

[AmProsius]

This is the door if I'm not mistaken. The Waypoint is OCC_STABLE_STAIRCASE_TOP.

[szapp]

This will be very similar to #52 with respect to adding and removing a certain property of a MOB in the world.

[szapp]

In the referenced PR, I decided to lock the door again when reverting the fix (but unlocking it again if it was unlocked before). This should be quite reliable. For details, see #167.

[Quintus24]

Hi, guys!

Again, I am sorry for spamming a closed issue.

I'm in Chapter 5 at the moment and I found the Iron Key in Stone's prison cell.
However, I still can't open the Smithy's Storage door.

My character simply stands still when I press and hold the "left mouse button".
The only thing I can do is move the camera up and down while performing this action.

What I observed so far:

• The character sees the door, as it becomes "focused" and the "Door" string is displayed.
• If the character is at a distance from the door but close enough to focus on it, he will shrug his shoulders.
• Lockpicking the door still works, but the usual strings are displayed (all over again / picklock has broken) since the key is mandatory.

I tried the "fix status 46" command in the console and it said "Fix # 46 is inactive".

Is it possible that the fix is not retroactive?

Best Regards,
Quintus24

[MarkusRamikin]

To be sure, do I understand correctly that the iron key that I find at Stone's feet in the dungeons is meant to open the door in the smithy, on the right side? Or did you guys give up on that?

If so, I also report that this doesn't work. In this savegame I have freed Stone and I have the key, but I cannot open that door: savegame3.zip

I don't really care that this be "fixed", I know there's nothing special behind that door, so it seems like much effort for no gain. I am merely asking to know the status of that door - is it currently meant to be openable with this patch or not.

[AmProsius]

Thanks for reporting this bug. We will reopen this for review, because the door should be fixed already.

[szapp]

If I am not mistaken, when saving and loading once acquired the key, the door’s key instance is no longer adjusted. I think the implementation doesn’t match the flow diagram in the issue description. So, it looks like we were aware of this, but the implementation missed this.

gothic-1-community-patch/src/Ninja/G1CP/Content/Fixes/Gamesave/fix046_SmithDoor.d

Lines 79 to 82 in 66e2fc2

	// Check if new key item already exists somewhere
	if (G1CP_IsItemInstantiated("G1CP_046_SmithDoor_Item")) {
	return FALSE;
	};

[AmProsius]

This should fix it if I'm not mistaken:

    // Check if new key item already exists somewhere
    if (!G1CP_IsItemInstantiated("G1CP_046_SmithDoor_Item")) {
        return FALSE;
    };

[szapp]

No quite the opposite actually. The code below that if-block creates the key if not present. What is incorrect in the script is that the key instance of the door is not adjusted and the function returns false, if the new key already exists.

[szapp]

@AmProsius The issue should be addressed in branch bug046. Would you be so kind and pull it to try:

1. Run the test once.
2. Pick up the key.
3. Save the game. *
4. Few variations:
   1. Do nothing and continue directly to step 5
   2. Load the just created gamesave
   3. Quit the game, restart it and load the gamesave
5. Run the test again.
6. Follow the on screen instructions of the test.

* In the zSpy you should find the fix being re-applied after saving is finished. This was not the case before the recent fix.

[AmProsius]

Confirmed. I will then close this issue.