Fixes for the original (1.02d) DOOR and CONTAINR scripts

[Muttie]

Introduction (500 words, followed by an OPTIONAL changelog w/ all the details)

I had a break (kind of). After which I've decided to rebuild the box scripts for WM2 and while at it check them for fundamental issues. (bit of ground research as a side-benefit – or possibly main-benefit...).

Which then resulted in several weeks working on nothing but these scripts (i.e. looking for bugs, fixing them, experimenting w/ ideas, full test sessions, learning about the engine and so on). Got a bit out of proportion.

Anyway, I think I'm finished with it for now... and as the scripts have reached a kind of finished state it seemed like I should share them.

https://easyupload.io/9ocpcx
[Temporary link to the files (so far), if interested, These are updated templates of the default Containr & Door source of Fo2 (1.02d).
The two ssl files have a lot of comments. Should all be self-explanatory.]

I think the best part of these scripts is that they allow to adjust the settings for every door individually. If you want a fridge that closes after opened, but cannot be lockpicked or destroyed you can set that at the beginning: CLOSE, NO_LOCK, NON_DESTROY. If you want a door that closes and opens automatically, can be destroyed by two charges of dynamite and lockpicked with electronic & crowbar items (only), you can set that, too: [BOTH WAYS, METAL, DOOR STRENGTH 1, NO_LOCK_ELEVATOR.]

This being individually changeable for every door is probably the best part of it. In fact, the adjustable sections has many options -> combinations. Use what works best for you. Should be easy enough to toggle.

Plus bug fixes and some improvements like auto-doors (see next & changelog).

Rat Maze (using EcRobber) to test auto-doors.
I also made versions of this maze with quadruped critters, multiple critters and one I've send Vic through. The main purpose was not only to test auto-door functions but also if critters & companions can disarm traps (correctly), which is a new feature in door.ssl.

Anyway, I believe these default Fo2 scripts should be all correct now. Rest is expanding on it.

Do mind that ANY other vanilla 1.02d script that was based on these templates may still be bugged, e.g. ZiLckDor is missing the damage type check, so any damage takes it down, while ZiWodDor decided, for some reason, to do w/o the "locked variable" and consequently required script stunts all over the script – bit bizarre. Not sure what to make of it. Btw, DiDoor is basically ZiWodDor. And last but not least the party.h macro that added "procedure checkPartyMembersNearDoor" to 1400+ scripts, but is really only needed by 20, tops. Was getting on my nerves a bit, tbh.

500 words

Rest is a full rundown of changes.

Spoiler: Changelog

List of changes w/ code examples

macros & defines
-allowed Script_<Name> to be set normally and moved the generic msg (door/containr) to its own macro. This should make it easier to use it as a template.

/* You can define your script name in the following as usual */
#define NAME                    SCRIPT_
/* If you want to call the generic door/box msg then define it here: */
#define DOOR_NAME               SCRIPT_CONTAINR          // SCRIPT_DOOR (if object is a door)
/* and use : display_msg(door_mstr(204)); : instead : display_msg(mstr(204)); */

-expanded/fixed defines to allow toggling all script functions and options :

...these already exist...
#define STATE_WOOD                      (0)
#define STATE_METAL                     (1)
#define STATE_NON_DESTROY               (2)
...these already exist...
#define STATE_STANDARD_LOCK             (0) //allows basic
#define STATE_ELECTRIC_LOCK             (1) //allows electronic
...new...
#define STATE_NO_LOCK_CRATE             (2) //allows crowbar (only)
#define STATE_NO_LOCK_ELEVATOR          (3) //allows electronic & crowbar
#define STATE_STANDARD_CROWBAR          (4) //allows basic & crowbar
#define STATE_LOCK_ONLY                 (5) //allows basic & electronic
#define STATE_UNIVERSAL_LOCK            (6) //allows all
#define STATE_NO_LOCK                   (7) //blocks skill and items
...these already exist...
#define STATE_DOOR_NOCLOSE              (0)
#define STATE_DOOR_CLOSE                (1)  //doors close (distance)
...new...
#define STATE_DOOR_OPEN                 (2)  //doors open (nearness)
#define STATE_DOOR_BOTH_WAYS            (3)  //doors close & open auto.

-added full explanations to the define section, to make adjusting the script easier.

use proc
-added missing obj_name to line 205
-[Door only] New Feature: critters & companions use a new check which allows them to disarm traps they've spotted. (before this they would only "spot" traps over and over until setting them off)

if (source_obj == dude_obj) then begin                            // ADDED for NEW critter check
   <old check>
end
/* NEW CRITTER CHECK FOR critters AND companions */
   else begin
      /* Originally, companions (and critters) who ran into a trapped door would spot the trap, then keep using the door until triggering it, now they have a chance to disarm it. */
         /* Notes: */
         /* critters do treat "locked" doors as blocked tiles and will never interact with a locked (or open) door */
         /* quadruped critters (like dog companions) are blocked from using doors... only biped (includes floaters, btw) and robotic critters can use doors */  //exception: silver & gold geckos are biped, but can't use doors (must be hard-coded)
            /* party control companions : are treated as the dude, never goes into this check. */
      if (local_var(LVAR_Trapped) == STATE_ACTIVE) then begin
         if (is_success(Traps_Roll)) then begin
            script_overrides;
            /* Critters don't need to set LVAR_Found_Trap,1; they either disarm or trigger the traps they've spotted */
            display_msg(obj_name(source_obj)+door_mstr(205));

            if not combat_is_initialized then begin // no disarm or skill use in combat, normal engine behaviour : ofc, the player will not use a door after spotting a trap, while critters/companions will be back to using the door till they trigger it; that said, one may decide to remove this check and allow critters/companions to disarm in combat : OPTION
               Traps_Roll:=roll_vs_skill(source_obj,SKILL_TRAPS,Trap_Bonus);

               if (is_success(Traps_Roll)) then begin
                  set_local_var(LVAR_Trapped,STATE_INACTIVE);
                  set_local_var(LVAR_Found_Trap,1);   //else it would still trigger for the dude, despite the object not being trapped anymore
                  obj_open(self_obj);     //I removed "reg_anim_clear(source_obj);" as critters have no magic hands, but added this, as it seemed to help the critter to move smoother
                  display_msg(obj_name(source_obj)+door_mstr(201));
               end
               else begin
                  call Damage_Critter;
               end
            end

         end
         else begin
            call Damage_Critter;
         end
      end

   /* Spam of "The doorway seems to be blocked" messages. Caused by a critter opening a door that is mid open animation.
   Most commonly caused by two critters opening the same door OR a companion opening an auto door. The slower the door's swing animation the more likely it is to trigger.
   The following blocks it. */

      if (obj_is_open(self_obj)) then begin
         script_overrides;
      end

   end                                            // End of NEW CRITTER CHECK FOR critters AND companions

-expanded the auto door check, it has now 4 settings: off (), close (after opening), open (when approaching) & on (closes & opens automatically). Macro is called in various places. See timed event for extra notes.

pickup proc
-[Container only] does not call use proc anymore : new fix (see use skill proc)

use skill proc
-added script_overrides
-added New Option to disable lockpick skill
-added a new Steal check, as the pickup proc fix would open the inventory screen when a trap goes off

/* Skill_Steal */
/* The engine allows to steal from a container when it is open. It also allows to steal from containers* that can't be opened. */  // *edit: actually any item, not just containers -.-
/* This behaviour enables to circumvent traps (on objects like bookshelves) and locked states (on objects like workbenches) */
   /* A way to fix this was to call use proc in pickup proc. However, this has a downside: If a trap goes off on an object w/o an
      open state (like a workbench), or an object in the open state (like a locker), the inventory screen does not get cancelled
      and the player explodes with the screen open. */
      /* So I used the following instead: */
   else if (Skill_Used == SKILL_STEAL) then begin
      if (local_var(LVAR_Locked) == STATE_ACTIVE) then begin             // added to emulate engine behaviour; it checks for locked first, if true, action cancelled
         script_overrides;
         display_msg(door_mstr(203));
      end
      else begin
         /* this should check for "obj_is_open", if true then, but this check returns as false for objects w/o an open state like shelves and workbenches */
            if (local_var(LVAR_Trapped) == STATE_ACTIVE) then begin
               script_overrides;                                         // remove this and it has the same bug as pickup proc (inventory screen comes up while trap explodes)
               call use_p_proc;                                          // (detect or explode) : this allows Steal to trigger use proc on a "closed" locker, which it normally can't (should get cancelled)
            end
            /* else : nothing, allow Steal */
         /* else : this should play an engine message saying ("The container isn't open."), but it doesn't exist. */
      end
   end                                                          // End of Skill_Steal

-New Feature: option to call Examine Checks through Science skill

use obj proc
-removed "else" checks as they blocked (crowbar & explosives) usage
-added script_overrides
-expanded and added status checks
-[Container only] added super lockpicks (standard & electronic)
-pry door checks if door is locked

damage proc
-damage proc checks for damage type (door only)
-fixed the fridge & non-destroy variable dupe/conflict (containr only)
-[Container only] New feature: if not destroyed, the objects opens (like "blowing a safe open"), nice visual with some containers; (Door script needs to enable it)
-fixed the explosion loop of metal containers
-added message that damage was done
-[Door only] added message for indestructible state

look_<X>
-made bonuses definable (this makes spotting traps consistent, i.e. same modifier throughout)

look_traps
-added the missing "set trap found" checks (4x)

disarm traps
-added missing obj_name to line 199
-moved XP from spotted to disarmed, as it was inconsistent (many options to spot a trap in the script, only one gave XP)
-added missing 198 line for the dude, goes with 202

super lockpick lock
-moved proc for better structure

lock door
-added that the object closes when locking it (new feature)

set trap
-explosives are only removed on success and critical failure, not on every attempt (fix, imo)

pry door
-added missing obj_name to line: 181, 182/183, 186/187 & 185
-added XP gain, same as lockpick but can be defined separately

timed event
-expanded on the Door.ssl auto door function to support all 4 options

set timer
-added Set Timer proc; which sets timers for auto door function,
-and called it in use, use skill, use obj and map enter.

Spoiler: Want to Test:

-Name the door.ssl script DiDoor and make the settings you want.
-Test script in the Den w/ & w/o Vic (and all the wandering loser models).

*you may have to rest 10 minutes to kickstart them.

-Testing containers (dunno easy set up)... if you know a box script (based on the template) you may replace that temporarily, else you may just use desert1, put a container, assign it EcBox, then save containr.ssl as EcBox and make the settings you want.
Or (instead EcBox & Fo2) you may use WM2, which has 8 box scripts (!box1 to !box8), allowing to set up 8 different types on desert1 (that's what I did).
Otherwise you need to take another hurdle and adjust scripts.lst and so on.

[BEFORE YOU CALL IT A BUG:]
[quick notes from my documentation on "auto doors":
-the basic function is to step in front of the door/container – wait till it opens – then go through OR use Steal to access it – then walk away : [this is still slow, but some may prefer it to opening doors by walking into them]
-trapped doors are prevented from auto opening (-can look like a bug, but isn't-)
-the engine cannot open/close locked objects (-easy to forget-)
-the script can be used with "gl_autodoors" (a script that has the dude behave like a critter)
-setting a trap on an auto opening door requires to "lock" the door first. Then unlock the door again after setting the trap
-closing auto opening doors manually is a bit silly and you could consider to add script_overrides to block use proc when you use auto doors [but only override for the dude (better) and only if the door is not trapped (important)!]
-players are likely to flip when you set containers to auto open. - they can use Steal to access them, but expect to be yelled at first.

I hope these examples show how that this can change and mess up known mechanics, but still work by creating new ones. There are many variables → options. Try and experiment. Including using gl_autodoors with CLOSE, for example. Many options. You can even turn it all off; NOCLOSE.

Known Bugs (all considered minor):
- When a critter is scripted to stay next to a door (see orphans in the Den) it fails to close the door as "last object" is never out of range. [fixes itself by loading map]
- A door with a very slow close/open animation can trigger timed event before the door can be registered as closed/open and breaks sequence. [can fix itself]
- General Manhandling can Create Bugs (example; I managed to set a trap on an open door) [has to be done on purpose]
- And a few optimizations here and there [details]
-Long list of ideas and smaller improvements... nothing vital. [but I have a working prototype that allows companions to pry open a door, which is intriguing, but also a full job, and possibly stupid, maybe next time, plus some other mad ideas which are probably all going for bust anyway]

Options:
-Please note the commented out option "not to auto-open a door again after the player closed it" in Set Timer proc. This may help to enhance the OPEN option to something you may actually want.
-There is also an option in map enter "not to close objects on map enter". Also commented out, but something you may want with some doors (e.g. set to open in mapper).

You probably have to experiment a bit.

Bonus:
If tired of global procs:

/* How far do party members have to be from the door before it closes */
#ifndef PARTY_CLOSE_DIST
   #define PARTY_CLOSE_DIST                (5)
#endif

#define CHECKMEMBERNEARDOOR(inparty, obj)                                           \
         if (inparty) then begin                                                    \
            if (tile_distance_objs(self_obj, obj) <= PARTY_CLOSE_DIST) then begin   \
               return 1;                                                            \
            end                                                                     \
         end

#define CHECK_PARTYMEMBERS_NEAR_DOOR     CHECKMEMBERNEARDOOR(Vic_In_Party, Vic_Ptr)                                  \
                                         CHECKMEMBERNEARDOOR(Myron_In_Party, Myron_Ptr)                              \
                                         CHECKMEMBERNEARDOOR(Marcus_In_Party, Marcus_Ptr)                            \
                                         CHECKMEMBERNEARDOOR(MacRae_In_Party, MacRae_Ptr)                            \
                                         CHECKMEMBERNEARDOOR(Sulik_In_Party, Sulik_Ptr)                              \
                                         CHECKMEMBERNEARDOOR(Lenny_In_Party, Lenny_Ptr)                              \
                                         CHECKMEMBERNEARDOOR(Cyberdog_In_Party, Cyberdog_Ptr)                        \
                                         CHECKMEMBERNEARDOOR(Doc_In_Party, Doc_Ptr)                                  \
                                         CHECKMEMBERNEARDOOR(Goris_In_Party, Goris_Ptr)                              \
                                         CHECKMEMBERNEARDOOR(Davin_In_Party, Davin_Ptr)                              \
                                         CHECKMEMBERNEARDOOR(Miria_In_Party, Miria_Ptr)                              \
                                         CHECKMEMBERNEARDOOR(Robobrain_In_Party, Robobrain_Ptr)                      \
                                         CHECKMEMBERNEARDOOR(Laddie_In_Party, Laddie_Ptr)                            \
                                         CHECKMEMBERNEARDOOR(Bess_In_Party, Bess_Ptr)                                \
                                         CHECKMEMBERNEARDOOR(Chicken_In_Party, Chicken_Ptr)                          \
                                         CHECKMEMBERNEARDOOR(Karl_In_Party, Karl_Ptr)                                \
                                         CHECKMEMBERNEARDOOR(Jonny_In_Party, Jonny_Ptr)                              \
                                         CHECKMEMBERNEARDOOR(Lloyd_In_Party, Lloyd_Ptr)                              \
                                         CHECKMEMBERNEARDOOR(Dogmeat_In_Party, Dogmeat_Ptr)                          \
                                         CHECKMEMBERNEARDOOR(Pariah_Dog_In_Party, Pariah_Dog_Ptr)                    \
                                         return 0;

/*
create following proc:
procedure checkPartyMembersNearDoor begin
   CHECK_PARTYMEMBERS_NEAR_DOOR
end
in every script that needs to call it
*/

Scripts that use it:
The ones in GENERIC (ZILCKDOR.SSL, ZIMTLDOR.SSL, ZIWODDOR.SSL) and TEMPLATE (DOOR.SSL) use this, plus;
MIDOOR.SSL, SIVDOR.SSL, IILOCKDR.SSL, RIJALDOR.SSL, RIVLTDOR.SSL, WILV1DOR.SSL, WIBAYDOR.SSL, WIBNKDOR.SSL, VIVLTDR2.SSL and VIVLTDR3.SSL.
The scripts DIDOOR.SSL, NIBASDOR.SSL and NIDOOR.SSL are updated through ZIMTLDOR &  ZIWODDOR (need to be re-compiled).
That "could" be all in 1.02d...
and 1400+ scripts can shed a proc they don't need.
Plus, maybe, proper macro in SICLSDOR.SSL, SIKDOOR.SSL, SSFLXDOR.SSL, SSFRGDOR.SSL and SSGUNDOR.SSL. (not tested, but they don't check for Dogmeat & Pariah, plus, any new companions you may want to add to the list).

This fix should also allow to define party_close_distance in the door & containr template scripts (currently disabled).

DONE, 2500 words, sue me.

 

[gustarballs1983]

Okey dokey.. One more thing..

You actually say "explosives can destroy doors" *however* did you meant only dynamite and plastics? or did you happen to take into consideration grenades and rockets fired from a rocket launcher (bazooka) as well. It's a damn shame Tim never made that feasable to blow the doors open with rocket launchers or certain types of grenades ( namely the frag and plasma ones, not Molotovs, although emp grenades could damage the electronic lock causing to be locked out of that door unless you blow it open with explosives :p ) This way those damn rocket launchers would have a use now, when infiltrating EPA or Sierra one could actually do some Bazooka shooting instead of freaking relying on lockpicking the door..

 

[Muttie]

Okey dokey.. One more thing..

You actually say "explosives can destroy doors" *however* did you meant only dynamite and plastics? or did you happen to take into consideration grenades and rockets fired from a rocket launcher (bazooka) as well. It's a damn shame Tim never made that feasable to blow the doors open with rocket launchers or certain types of grenades ( namely the frag and plasma ones, not Molotovs, although emp grenades could damage the electronic lock causing to be locked out of that door unless you blow it open with explosives :p ) This way those damn rocket launchers would have a use now, when infiltrating EPA or Sierra one could actually do some Bazooka shooting instead of freaking relying on lockpicking the door..

There is a difference between "doors/portals" and "boxes/containers". A portal can be damaged by anything if the script allows it. Normally, door scripts allow "explosive damage" which includes Frag grenades, Molotovs and Rocket Launchers, but not Plasma grenades (as it's plasma damage), however, you can change the script to also allow plasma damage. A container can only be damaged by "explosives" (dynamite & plastic)... however, that's an oversimplification, see following post.


Continued working on WM2, had to return to portals and containers:

EcBox (one of the few boxes based on the template (actually the door one, not the containr one) has a small bug:
(give_pid_qty) does not trigger when loading a game (hard-coded), but (remove_pid_qty) does ; both is part of the (check_restock_item) macro
So it will not add items on loading a game, but may reduce the qty of items already inside the container.
Needs metarule 22 == 0 before create content.

Then I found the reason for pickup proc not working:

procedure use_p_proc begin
<Hidden>
           else begin
              script_overrides;
               call Damage_Critter;
           end
<Hidden>

All it needed was to add a script_overwrite, instead I wrote a full Steal rework.
On the plus side: the Steal rework is possibly more elegant and closer to engine behaviour then calling use proc in pickup proc. [containers seem to ignore use proc when the object is locked... engine intervention. - and the pickup proc fix circumvents that]
Also adding the script override (as above) means that the door/box won't open when setting off the trap. Which I believe was the intention: "traps go off when an object is opened", then again that [blocking it] may be considered a plus w/ containers, but possibly not with doors... don't know what to do yet. It's almost a matter of preference. For the moment, I think I'll stick with my Steal rework.

Detail:
Changed:
Note: boxes can only get hit by explosives (PID 51 & 85) (probably hard-coded).
To:
Note: boxes can only get hit by explosives (PID 51 & 85) (oversimplification).
It's mostly correct as far as the player is concerned but portals/containers and damage is actually more complex. For example, it seems portals are immune to splash and absorb splash, except when it's explosives (PID 51 & 85), plus, containers can get hit by (explosion) [triggered when a trapped door/box is damaged, for example] but it (trapped explosion) does not trigger during combat, so it's (PID 51 & 85) only again. That's as far as I've got... but I think it's "basically" correct... anyway, PID 51 & 85 are probably hard-coded (in many respects) but the damage on boxes is probably coming from the (explosion) command.

And, last, I added a check to block use proc when the door is automated, this makes it smoother to use:

procedure use_p_proc begin
<Hidden>
   if (source_obj == dude_obj) then begin                             // ADDED for NEW critter check
      if (local_var(LVAR_Trapped) == STATE_ACTIVE) then begin
       <Hidden>
      end
      else if (obj_is_locked(self_obj)) then begin
       <Hidden>
      end

   /* override to make auto-doors smoother : less conflict between use proc and timed event : makes it cleaner */
       /* Notes: */
       /* Only use this with dude_obj, critters don't handle a use proc disable too well. : If using gl_autodoor (i.e. dude behaves like a critter) it may also be better to disable this. */
        /* If you used the option in Set Timer for the OPEN state ("do not open object after manually closing it") you'll need to disable this block. */
      else begin
         if ((CLOSE_STATUS == STATE_DOOR_OPEN) or (CLOSE_STATUS == STATE_DOOR_BOTH_WAYS)) then begin
            //if (source_obj == dude_obj) then begin //for boxes; as said it is better not to disable use proc for critters, although I can't think of a case where a critter would access a container...
               if (combat_is_initialized == FALSE) then begin //(important); the timer events are turned off during combat (see timed event), also skill use (Steal) is blocked during combat
                  script_overrides;
                  //display_msg("You have to use your Steal skill to access this container."); //for boxes; as it can be rather confusing w/o this prompt
               end
            //end
         end
      end

   end

Anyway, that's an example of how I would add the use proc override (as mentioned as an option in the first post).

Tested with this entrance gate:

Which I thought would look nice if it would open/close automatically.
And blocking use proc helped to make it go smoother.
I also did a few test in the Den (w/ Vic and combat), seemed to be fine (after the fixes).

Still, I'm not entirely sure yet... in fact, I'm not entirely sure about the whole auto-door thing, but adding it in individual cases (like the gate above) is a nice touch.

New Link: https://easyupload.io/ptky7s
[This is the same as the old link (same folder), plus my current set. I can't cope anymore to keep my own versions and versions that others can use... you may compare the ssl (old vs new) files to see the changes (not much, just the above really) and then create something you may/can use, if you want to.]

 

[agris]

A portal can be damaged by anything if the script allows it. Normally, door scripts allow "explosive damage" which includes Frag grenades, Molotovs and Rocket Launchers, but not Plasma grenades (as it's plasma damage), however, you can change the script to also allow plasma damage.

this sounds as if it is possible to set a door's script such that it's breached with splash rocket or grenade damage.

can this script be extended to walls? there is art in the game for breached brick, vault, and wooden walls iirc. having some structures' walls destructible with either dynamite/C4, or explosive splash damage, would be amazing.

 

[Muttie]

Not sure, but you can attach scripts to anything in Fo. Literally, anything (edit: except tiles). I'm almost certain the engine could be used to build a Resident Evil house, w/ use hand icon on an object to reveal a hidden passage and so on. I believe there are a lot of options for a detective game.
If walls can "be damaged" as such I'm not sure, my guess would be no, but you can very probably script them to "if object x is used on wall set it to invisible" and possibly play an explosion animation for visual effect. (edit: may need to change the action flag of the wall proto (not tested), else may try a condition, or see the Military Base removing rocks with an exploding mine cart, it's also possible to swap out scenery pieces and so on. There are a lot of options w/ scripts. I think the area is widely underutilized.)
Doors/portals are special as they can be targeted in combat like a critter. But no other object (walls, scenery etc.) can I believe.

[edit II: sorry, I tried to reply within a few minutes of seeing it, which is out of my scope. Did a quick test with a wall and I'd say it behaves the same as a container, which means if you give it a script with a damage proc it can be destroyed but probably only by "explosion(tile_num(self_obj), elevation(self_obj), Trap_Damage);" which is Dynamite and Plastic Explosives (for the player) – or any "explosion" you trigger next or onto it (for scripter). That's probably it for scripts. Engine and global can probably do more, but that's still out of my league. Haven't looked into those areas at all yet.]

 

[agris]

it's also possible to swap out scenery pieces

without explicit engine support, isn't this the key to destructible walls? you don't set the wall to destructible per-say, you assign it a script that swaps the art of the solid wall to that of the damaged one when the script detects explosive/explosive splash. not sure how that would work to make it passable though, can a segment of wall be scripted to become a 'portal'?

 

[Muttie]

without explicit engine support, isn't this the key to destructible walls? you don't set the wall to destructible per-say, you assign it a script that swaps the art of the solid wall to that of the damaged one when the script detects explosive/explosive splash. not sure how that would work to make it passable though, can a segment of wall be scripted to become a 'portal'?

Yes. You can create a portal that opens/closes when damaged. You can also animate scenery pieces (like Klaxon or Switches) and toggle them (red light/no light sirens etc.). However, only Portals can be targeted in combat. The main problem is, though, that even Portals don't get hit by splash (rocket launcher, grenades etc.) and with that it goes out of the window (w/o engine fix) as that would be the main feature of destructible terrain, I'd say.
Otherwise you can use the "explosion command" (as dynamite uses it) to trigger damage proc on an object and have it adjust (toggle, open/close or replace), or even just do that by script alone (e.g.destroy object and replace it with another object when X). However, that is not going to help in combat unless you create a timed event or similar that triggers it*. I don't know what happens if you make it a critter (like Gizmo at his desk) but that would need testing if that won't cause issues elsewhere...
Anyway, the problem is nothing, but critters, will behave in combat as you'd need it to.

Sorry about the x (4 apparently -.-) month delay, I'm not an internet person. I'm happier off-line.


*Edit: Made a mistake: Forgot that it [setting something off in combat via timed event] may not work, as animations (triggered in script) get (usually) blocked in combat. Including explosions. Dynamite working in combat is an exception (I think) (i.e. it can trigger and splashes all alike (critters & other objects)). So setting a timed event to go off during combat would go off (you can trigger message floats, for example), but animations are likely to get blocked [edit: actually opening/closing portals works in combat, that's another exception – but you can't animate critters (pretty sure of that... would need to test more... but scripting a critter to fall over in combat does not work]) and I couldn't trigger the explosion command in script during combat (once, when I tried), otherwise, operating switches may work (?), but Animate Forever stops, I believe [edit: yes, tested, see below]... sorry, but [Fo2] is complex...
[edit: warning note: animations are also a solid cause for crashes: example, trigger a "critter to blow up" on map_exit and it crashes, cause a critter w/o a standing animation to walk/run and it crashes - something you should always test in "window" mode.]

Example

procedure map_update_p_proc begin
   //if (combat_is_initialized == 0) then
   //begin
      reg_anim_begin();
      reg_anim_animate_forever(self_obj, ANIM_stand);
      reg_anim_end();
      display_msg("I'm spinning.");
   //end
end

Animate Forever, blocks spinning in combat, but even when I disable it, the animation of the spinning fan stops anyway.
I like to test these things (boundaries...). You may think they added that check (if (combat_is_initialized) for a reason, but when you try and disable it, it gets blocked anyway (does nothing). My money is on that this is default behaviour and the script addition was just a precaution (or common practice when adding animations).
Anyway, expect animations to get blocked in combat.

 

[Muttie]

Actually, using a critter as a wall piece may not be that bad... I can think of only two issues so far:

1. The wall piece will show up as a critter on automap (motion sensor)
2. If disabling resting on a map, the dude will have to kill the "walls" to re-enable it.

However, those are minor inconveniences. The main thing would be combat. But that can actually be fixed fairly easily in script (see EcCrtBra). In addition, the prototypes of critters have many flags which disable most critter behaviour that would seem wrong on a wall (No Steal, No Drop, Ages, No Heal, No Flatten, No Knockback, Invulnerable (to block crits) etc.). And of course a critter would be a proper target in combat and could also have HP, so a stone wall could be different from a wood wall. If you give it a AA (standing) frm and death animations (B(x)), I don't see why it would be an issue. The engine doesn't care what frm you give a critter, and a critter who has no script is basically a scenery piece, it just stands there. Of course, it will react when attacked in combat, but that can be suppressed (as said) very correctly in script. Not an issue - actually desired in this case).
It would need testing, ofc, but only if something odd comes up or something I can't think of, but on paper it's basically a Brahmin w/ EcCrtBra script– and that's not a problem.
As said, it will mess with minor things (two points above) and there may be more. But from my current understanding, I would not say it's doomed from the start. You may just have a lot of "critters" on map... still, if you do that once on a map (special scenery object) why not...

Edit:
I would test if drug items get blocked by script_override, but I'm pretty sure they are (those are only an issue inside inventory, if I remember correctly). However, First Aid Kit/Doctor's Bag can't be blocked. Nothing you can do about them in script. So:

1. Can be healed with First Aid Kit & Doctor Bag items.

That's another inconvenience.
Still, if you want a barricade the player has to shot down. Or a set of "stasis tanks" the player has to defend against enemies (as a critter the tanks could be set as a target in "attack(obj)"). That may still be acceptable.