Jump to content
The Dark Mod Forums

Slam doors open while running


snatcher

Recommended Posts

@wesp5I was actually responding to Oktokolo. I am all with you that the setup as is isn't optimal. Similar to the ai's acuity it would be best if mappers would adjust the respective values for their fms. I don't think that is the case mostly, although I may admit that I never really checked. I know that I haven't done it either in my fms back in the day (in addition to a dozen other things I messed up 😕 )

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

On 6/21/2022 at 8:20 AM, Obsttorte said:

Death means defeat. Everything else should be considered challenges to deal with.

The challenge to deal with boils down to: Wait in a dark area AI can't reach (under or on top of furniture is perfect) until cooldown happens. The most often used ways to eliminate the wait are:
- Making fighting a viable option. But at least i play TDM especially for the stealth underdog power fantasy.
- Making the cooldown timer laughably short.

I like the way Styx does it: If you get cought, you just die in one or two hits. I learned how to fight and then was able to reliably win fights but it didn't feel good as stealth wasn't required anymore. Didn't try to learn fighting in TDM, but would expect the same to happen here (i saw videos of a dev defending themselves against multiple AI with a sword on hardest settings, so it definitely is possible).

An actually (for me) fun mechanic would also be to just do what real thiefs do when they are cought and leaving the area fails: Surrender and get arrested. and since this is a game, the main objective would then temporarily change to escaping the jail. But this sort of gameplay isn't a mechanic you could just add to the core and be done with it. While it probably could already be pulled off using existing features, it is significant work and has to be done for each map separately.

A still better than now improvement would be to limit alert propagation to a radius from where the event happened. So i could just sneakily flee the area and continue exploring without the whole map being in full alert state (including the lowest citizen) and immune to KO (i am not a ghoster; i love the KO mechanic and excessively use it).
This is implementable in core and wouldn't need any support from map authors to work on the bigger maps (doesn't have to be Iris-sized, but obviously needs to be bigger than a single mansion).

Link to comment
Share on other sites

10 hours ago, Oktokolo said:

The challenge to deal with boils down to: Wait in a dark area AI can't reach (under or on top of furniture is perfect) until cooldown happens.

That's an issue. It could be somehow circumvented by increasing the cooldown speed if the player is in a spot where he is neither detectable nor reachable.

10 hours ago, Oktokolo said:

A still better than now improvement would be to limit alert propagation to a radius from where the event happened. So i could just sneakily flee the area and continue exploring without the whole map being in full alert state (including the lowest citizen) and immune to KO (i am not a ghoster; i love the KO mechanic and excessively use it).
This is implementable in core and wouldn't need any support from map authors to work on the bigger maps (doesn't have to be Iris-sized, but obviously needs to be bigger than a single mansion).

I am unsure to which extent this can be added to the core mod without breaking the whole AI behaviour.

IMHO this is more of an issue with the mission design then with how the core mod works. People always claim this or that to be added to the core and that it is easy and will solve everything. But at some point you cannot improve a tool any more and have to consider to work on your skills on how to use it.

Some thoughts:

  1. Like acuity also the alert level threshholds as well as the cooldown time are parametrisized, meaning that mappers can tweak them to fit their mission and layout. So in missions with lots of dark places in unreachable area, where it is likely that players will just hide there once detected, mappers could decrease the cooldown times. In inside missions with lots of small rooms acuity could be reduced to accomodate for the lower stim travel distances.
  2. The issue of whole maps becoming alerted could be avoided if the missions would be build in a way that it consists out of several sectors with buffers in between that avoid the alert to spread from one area to another. Note that this is meant figurative! Obviously the player still has to be given the impression of one big area, but what the player perceives and what the underlying architecture is like are two different things. Dishonored did a good job on that matter imho.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

@snatcherHere is a modified version of the script that causes a sound to be propagated, hearable for nearby AI. Initially the sound origin was the door in question, but for some reason that doesn't work if the door is touching a visportal, which it usually does. :blink: Therefore the sound is emitted by the player. As they are nearby when a door gets slam open or closed it doesn't make a big difference, though.

You can play with the number in the propSoundMod function call to modify how loud the propagated sound is (note that the player cannot hear it, it's only for alerting the AI).

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Thanks, Obsttorte.

Where's the link, please?

Running around and slamming doors open isn't my play style but you had a very good idea that can come handy in many situations. The problem was that opening a door while running brings the player to a sudden halt, therefore "quickly opening doors" was the right way of putting it. I, personally, after having tried your (excellent) prototype, I find extra sound emitters and quickly closing doors unnecessary (or even counterproductive) but I let your experienced judgement decide.

Did you, by the way, figure out the issue with the exponential rotation speed?

 

TDM Modpack 4.0

Link to comment
Share on other sites

1 hour ago, snatcher said:

Where's the link, please?

Oops. Getting old. 🙄

fastdoor.zip

1 hour ago, snatcher said:

Did you, by the way, figure out the issue with the exponential rotation speed?

I haven't looked into it yet.

 

  • Thanks 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Dear @Obsttorte ,

I have been testing v2 for some time and I don't have any positive points, I am afraid. The following are in-game sensations (didn't check or alter your scripts).

Your script works fine when running away from AI, but my main testbed this time around has been a house with long carpeted corridors and AI doing its business unalerted.

1) The sound propagation spoiled the fun of the first version and AI is on me in more numbers and much faster than before. And while the idea of some noise could make sense, it doesn't translate well on screen because quickly opening doors doesn't feel too-fast or too-loud to me. The feeling is that I certainly am opening doors faster but with enough control not to slam the door against walls or frames. I like it better that AI detects me because of my floor steps and or simply because they see me. Ghosting at high speed undetected is actually fun!

In addition, trying to quickly opening a door that is locked will alert nearby AI. And while it may be a realistic on paper it doesn't translate well to the screen: why is this guy coming here?

2) Players shouldn't be able to quickly open doors when crouching, but I guess this could depend on whether sound propagation stays or not. It currently doesn't feel right to me and I find quickly open doors when crouching a mechanic that may encourages players to go fast.

3) There's a situation where quickly closing doors doesn't feel right. Put yourself in a long corridor, there's a door to your right that is open. You want to close that door but stay on the current corridor, running in the same direction. You make the move but get no feedback in that split second. Weird.

I say leave "quickly opening doors when running in stand up position" and forget about the rest. Less is more isn't it? That feature alone adds a lot and there's always time for upgrades.

Cheers!

TDM Modpack 4.0

Link to comment
Share on other sites

Thanks for the feedback.

Remember that the idea was that this feature should help players when running away after getting detected, not to increase the speed of the player so he runs through the level all the time. Therefore a few aspects haven't been taken into consideration as they are not relevant for that case, but obviously would need to be added when implementing, while some of your points result from the unintented way of using it.

  • Crouching: left out due to the above reasons, but obviously you should not slam open doors while crouching
  • The noise propagated needs tweaking I guess, and the door should make a different sound when slammed. This would require changes to the door or some default fallback sound to be played as alternative to the typical open/close sound to reflect that it is loud.
  • The aspect you mentioned in regards to closing doors without passing them is correct. I'll have to give this a thought.
  • Regarding closed doors: I guess if you run into them in full speed expecting them to be openable quickly, the sudden stop you'll experience will make quiet some noise ;) I don't really see any reason to tweak that.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I am adjusting from the (my?) initial vision - where everything was chaos - to what your script currently offers and how it translates to the player in different situations.

The issue being analyzed remains that players cannot run and open doors organically since the game brings you to a halt every time. The rest are additions that, while related, aren't addressing the actual issue.

During a chase, it does not matter whether doors propagate sound or not. You either find cover quickly or you are doomed. But I can see how sound propagation can spoil a perfectly acceptable situation.

Once again you are in a fully lit long corridor, and you are cornered: a guy patrolling from one side coming your way and chances of another guy around the corner in the opposite side. There's a door at the end and you make a desperate move: you run and quickly open the door and it happens there's yet another guy inside but looking through the window. You pulled it off! This move would never succeed with sound propagation, hence it will be discarded by players as a viable option.

TDM Modpack 4.0

Link to comment
Share on other sites

If you quickly open a door into a room with someone inside, I guess the first thing that one would expect to happen is that the person turns towards the door. In Thi4f this was even the case for standard door opening, and combined with the peeking through keyholes it works like a charm.

I think you try to adapt the mechanic to way more situations then I originally intented. That's fine, but as you are the only person interested in this it won't make it to the core mod anyways. I consider this a proof of concept, and mappers are free to adopt it to their likings for use in their fms.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I tried Thief 3 and I didn't even complete the first mission. Player movement felt awful. Thief 4 isn't even in my list of "perhaps some day", so I cannot say. I checked some videos and I am not interested. I parked Thief 2 since I discovered TDM.

27 minutes ago, Obsttorte said:

[...] but as you are the only person interested in this [...]

Respect but, based on likes? On these boards?

28 minutes ago, Obsttorte said:

[...] this it won't make it to the core mod anyways.

Not a problem. I am new around and keep adjusting expectations. For what is worth, I am lucky enough I got to try this in-game, and for that, I am grateful. Thanks, Obsttorte.

TDM Modpack 4.0

Link to comment
Share on other sites

1 hour ago, snatcher said:

Respect but, based on likes? On these boards?

Uhm...based on the fact that this is mainly a discussion among both of us. I mean, I don't even started this thread or can remember where I first posted about this, so...

EDIT: Just checked the op. It was in the interactions thread. Well, the loot sweep got way more feedback - and I added it. This here, it would take way more work and in the end it was just a thought, not something I or someone else requested.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

@wesp5You are welcome to do so. I want to fix other stuff.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Since there's some demand, here is my ugly take on script\tdm_frobactions.script. Credits to Obsttorte.

  • Quickly opening doors while crouching is disallowed
  • Removed sound propagation
  • Doors don't quickly close but a 0,5 sec delay remains between the moment the action is triggered and the door starts closing
  • The issue with the exponential multiplayer remains but it should rarely happen
float multi = 4.0; // How much faster the door opens
float fd_delay = 0.5; // How much time should pass when closing the door
void frob_door_test_thread(entity ent)
{
	vector linvec = $player1.getLinearVelocity();
	float velo = sys.vecLength(linvec);
	float door_time = ent.getMoveTime()/1000; // getMoveTime is in ms, time is in sec?!

// [snatcher] changed velo 80 to 90 to prevent quickly opening doors when crouching
	if (velo > 90 && door_time > 0) // normal walk speed is 70 du/sec
	{

// [snatcher] removed sound propagation
//		$player1.propSoundMod("arrow_noisemaker_active",20);

// [snatcher] why 0.9? (I am not sure) Changed to 1.0
		if (ent.GetFractionalPosition() < 1.0)
		{
// [snatcher] multi moved to opening door action only
			ent.time(door_time/multi);
			ent.Open();
			while (ent.GetFractionalPosition() < 1.0)
			{
				sys.waitFrame();
			}
		}
		else
		{
			sys.wait(fd_delay);
			ent.Close();
			while (ent.GetFractionalPosition() > 0)
			{
				sys.waitFrame();
			}
		}
		ent.time(door_time);
		return;
	}
	ent.ToggleOpen();
}

Cheers!

TDM Modpack 4.0

Link to comment
Share on other sites

It affects all doors unless door X uses a different script, class, method, function... I suppose it could be the case of modded doors built to serve a particular purpose. I don't know the source code so I don't know.

If you want take my version of the script for a spin:

  • Download Obsttorte's second version of fastdoor.zip (a few posts above)
  • Open with notepad (or any text editor) the file script\tdm_frobactions.script
  • Scroll down to the bottom and replace the last bits of code with *my* code. Just pay some attention and you will figure it out.
  • Save the file and move the def and script folders to the TDM folder. I personally use a mod activator.

 

 

TDM Modpack 4.0

Link to comment
Share on other sites

Besides the modified script file the zip contains a definition that overrides the base entity definition for the door entities, so it uses this script instead of the default one. As snatcher pointed out, if a mapper has created a custom door with its own frob script that one would be unaffected. But I am pretty sure this isn't the case. I haven't tested whether the script affects sliding doors or other frobable movers, so be prepared for odd side effects ( as said, it's a poc).

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I will settle on the below simplified solution for the time being and see what happens. "Doors open/close faster when running" and nothing else.

I removed the open/close status detection and I let the game stick to whatever current status the door is. I am still able to quickly close doors behind me by employing an awkward 180 degree backwards maneuver that is difficult to achieve but feels kind of natural. I think I also got rid of exponential multiplayer bug.

float speed_multi = 4.0; // How much faster the doors open or close
void frob_door_test_thread(entity ent)
{
	float def_move_time = ent.getFloatKey("move_time"); // default total time in sec
	float cur_door_time = ent.getMoveTime()/1000; // getMoveTime is in ms, time is in sec
	float player_velo = sys.vecLength($player1.getLinearVelocity());

	if (player_velo > 90) // normal walk speed is 70 du/sec
	{
		if (cur_door_time == def_move_time)
			ent.time(cur_door_time/speed_multi);
	} else
	{
		ent.time(def_move_time);
	}
	ent.ToggleOpen();
}

Cheers!

TDM Modpack 4.0

Link to comment
Share on other sites

1 hour ago, Obsttorte said:

I haven't tested whether the script affects sliding doors or other frobable movers, so be prepared for odd side effects

Good point.

You also mentioned at some point large (and I add: or small) doors. We could probably implement a "reasonable size range check" and if a door isn't within that size range that door will open normally. Also, modded doors could have custom times/speeds. I don't know: a rusty door accompanied by a custom sound. We could also have a speed range check, and again, if a door isn't within that range that door will open normally.

Something else I noticed but forgot to report has to do with double slide doors. The door you frob will open fast and the other slide will open normal. I don't know how to detect if a door has a sister / sibling / whatever 🙂

 

TDM Modpack 4.0

Link to comment
Share on other sites

27 minutes ago, snatcher said:

I don't know how to detect if a door has a sister / sibling / whatever

The setup is called frob peer. This is setup at mission start via the spawnargs "frob_peer" or "frob_peerX" (with X beeing a number" respectively. So you can get the other door by checking for the peered entity that is a door (there are handles, too, although it might not be an issue if they move faster, too).

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Ok, thanks. At this moment we have to aim right at double slided doors.

A side effect of my last attempt is that the door maintains its new time/speed until the door gets frobbed again by the player, meaning that AI will open and/or close that door faster forever. I am not sure what's the best way to address this. Is Frobbed by player? I have added, until a better solution is found, a delay of half sec before the door goes back to normal speed.

Hopefully this suffices for some time.

float speed_multi = 4.0; // How much faster the doors open or close
void frob_door_test_thread(entity ent)
{
	float def_move_time = ent.getFloatKey("move_time"); // default total time in sec
	float cur_door_time = ent.getMoveTime()/1000; // getMoveTime is in ms, time is in sec
	float player_velo = sys.vecLength($player1.getLinearVelocity());

	if (player_velo > 90) // normal walk speed is 70 du/sec
	{
		if (cur_door_time == def_move_time)
			ent.time(cur_door_time/speed_multi);
		ent.ToggleOpen();
		sys.wait(0.5);
		ent.time(def_move_time);
	}
	else
	{
		ent.time(def_move_time);
		ent.ToggleOpen();
	}
}

 

TDM Modpack 4.0

Link to comment
Share on other sites

@wesp5, for your information regarding the Unofficial Patch:

As far as I can tell, the set of files found in fastdoor.zip might conflict with at least two existing missions:

I assume (?) the pk4 files in the fms folder take preference so the worst that could happen is that "quick doors" doesn't work in these missions.

TDM Modpack 4.0

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 1 reply
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...