Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Killap's crowbar/trap code for locked doors isnt working properly #61

Closed
Question2 opened this issue Jan 4, 2021 · 8 comments · Fixed by #65
Closed

Killap's crowbar/trap code for locked doors isnt working properly #61

Question2 opened this issue Jan 4, 2021 · 8 comments · Fixed by #65
Assignees

Comments

@Question2
Copy link

Using v18 RPU with sfall v4.2.8.

I noticed that Killap added code to many locked doors to allow you to force them open with a crowbar or trap them with dynamite/plastic explosive, however I also noticed that this doesnt appear to work properly.

For example, when trying to use a crowbar on the locked door in the klamath rat caves leading to the fuel cell regulator, you only get the message "this does nothing". The same happens if you attempt to use dynamite on it.

For reference, this is from KSCVDOOR.ssl :

procedure use_obj_on_p_proc begin
   variable Tool;

   Tool:=obj_pid(obj_being_used_with);


    if (LOCK_STATUS == STATE_STANDARD_LOCK) then begin
       if (Tool == PID_LOCKPICKS) then begin
           script_overrides; //added by killap
           if (local_var(LVAR_Locked) == STATE_ACTIVE) then begin
               call Lockpick_Lock;
           end
           else begin
               call Set_Lockpick_Lock;
           end
       end
       //added by killap
       else if (Tool == PID_EXP_LOCKPICK_SET) then begin
            script_overrides; //added by killap
            if (local_var(LVAR_Locked) == STATE_ACTIVE) then begin
               call Super_Lockpick_Lock;
            end
            else begin
               call Super_Set_Lockpick_Lock;
            end
       end
       //end added by killap
   end

   else if (LOCK_STATUS == STATE_ELECTRIC_LOCK) then begin
       if (Tool == PID_ELECTRONIC_LOCKPICKS) then begin
           script_overrides; //added by killap
           if (local_var(LVAR_Locked) == STATE_ACTIVE) then begin
               call Lockpick_Lock;
           end
           else begin
               call Set_Lockpick_Lock;
           end
       end
       //added by killap
       else if (Tool == PID_ELEC_LOCKPICK_MKII) then begin
           script_overrides; //added by killap
           if (local_var(LVAR_Locked) == STATE_ACTIVE) then begin
               call Super_Lockpick_Lock;
           end
           else begin
               call Super_Set_Lockpick_Lock;
           end
       end
       //end added by killap
   end

   else if (Tool == PID_CROWBAR) then begin
       script_overrides; //added by killap
       call Pry_Door;
   end

   else if ((Tool == PID_DYNAMITE) or (Tool == PID_PLASTIC_EXPLOSIVES)) then begin
       script_overrides; //added by killap
       call Set_Trap;
   end

end

The last two blocks with the crowbar and dynamite never get called at all. I tried moving those two to the top of the procedure and it did work though, i was able to use a crowbar to bust open the lock and i was able to attempt to trap the door with dynamite. For some reason, the dynamite simply dissapeared from my inventory when i failed to set the trap, im not sure if this is intended as it never dissapears when you arm it in your inventory, even if you have very low trap skill. The only way you can fail to arm dynamite is the risk of premature detonation.

So for example changing the procedure to this will allow the crowbar/dynamite code to work :

procedure use_obj_on_p_proc begin
   variable Tool;

   Tool:=obj_pid(obj_being_used_with);

   if (Tool == PID_CROWBAR) then begin
       script_overrides; //added by killap
       call Pry_Door;
   end

   else if ((Tool == PID_DYNAMITE) or (Tool == PID_PLASTIC_EXPLOSIVES)) then begin
       script_overrides; //added by killap
       call Set_Trap;
   end

   else if (LOCK_STATUS == STATE_STANDARD_LOCK) then begin
       if (Tool == PID_LOCKPICKS) then begin
           script_overrides; //added by killap
           if (local_var(LVAR_Locked) == STATE_ACTIVE) then begin
               call Lockpick_Lock;
           end
           else begin
               call Set_Lockpick_Lock;
           end
       end
       //added by killap
       else if (Tool == PID_EXP_LOCKPICK_SET) then begin
            script_overrides; //added by killap
            if (local_var(LVAR_Locked) == STATE_ACTIVE) then begin
               call Super_Lockpick_Lock;
            end
            else begin
               call Super_Set_Lockpick_Lock;
            end
       end
       //end added by killap
   end

   else if (LOCK_STATUS == STATE_ELECTRIC_LOCK) then begin
       if (Tool == PID_ELECTRONIC_LOCKPICKS) then begin
           script_overrides; //added by killap
           if (local_var(LVAR_Locked) == STATE_ACTIVE) then begin
               call Lockpick_Lock;
           end
           else begin
               call Set_Lockpick_Lock;
           end
       end
       //added by killap
       else if (Tool == PID_ELEC_LOCKPICK_MKII) then begin
           script_overrides; //added by killap
           if (local_var(LVAR_Locked) == STATE_ACTIVE) then begin
               call Super_Lockpick_Lock;
           end
           else begin
               call Super_Set_Lockpick_Lock;
           end
       end
       //end added by killap
   end

end

I can still use lockpicks on the door as well.

Save in the rat caves if you want to test it :

SLOT03.zip

@burner1024
Copy link
Member

This likely calls for larger overhaul and code unification encompassing most/all doors.

@burner1024
Copy link
Member

burner1024 commented Jan 5, 2021

Ugh, the doors are such an ugly pile of copy-paste... This is going to a huge undertaking.

@burner1024 burner1024 transferred this issue from BGforgeNet/Fallout2_Restoration_Project Jan 5, 2021
burner1024 added a commit that referenced this issue Jan 5, 2021
burner1024 added a commit that referenced this issue Jan 5, 2021
burner1024 added a commit that referenced this issue Jan 6, 2021
burner1024 added a commit that referenced this issue Jan 10, 2021
burner1024 added a commit that referenced this issue Jan 10, 2021
burner1024 added a commit that referenced this issue Jan 10, 2021
@burner1024
Copy link
Member

phew, this is taxing

burner1024 added a commit that referenced this issue Jan 20, 2021
burner1024 added a commit that referenced this issue Jan 20, 2021
burner1024 added a commit that referenced this issue Jan 20, 2021
burner1024 added a commit that referenced this issue Jan 20, 2021
burner1024 added a commit that referenced this issue Jan 20, 2021
burner1024 added a commit that referenced this issue Jan 20, 2021
burner1024 added a commit that referenced this issue Jan 20, 2021
@burner1024 burner1024 mentioned this issue Jan 20, 2021
@burner1024
Copy link
Member

wanted to add magic hands animations on trapping the door, but it doesn't work great ref rotators/Fo1in2#70

burner1024 added a commit to BGforgeNet/Fallout2_Restoration_Project that referenced this issue Feb 7, 2021
burner1024 added a commit to BGforgeNet/Fallout2_Restoration_Project that referenced this issue Feb 7, 2021
burner1024 added a commit to BGforgeNet/Fallout2_Restoration_Project that referenced this issue Feb 7, 2021
burner1024 added a commit to BGforgeNet/Fallout2_Restoration_Project that referenced this issue Feb 7, 2021
burner1024 added a commit to BGforgeNet/Fallout2_Restoration_Project that referenced this issue Feb 7, 2021
burner1024 added a commit that referenced this issue Feb 28, 2021
burner1024 added a commit that referenced this issue Feb 28, 2021
burner1024 added a commit that referenced this issue Feb 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants