Jump to content
The Dark Mod Forums
Sign in to follow this  
Springheel

Adjusted Door Handling

Recommended Posts

I thought it would be awkward too, when reading Briareos' post, but maybe not. You develop muscle memory for games too. Dragging a door back with the mouse while backing off with 's' might be ok. And there are other options. Letting the door push the player while it's being frob-manipulated could be an easy and natural way to simulate the easy and natural way we all get out of the way of a door that we're pulling open.

Share this post


Link to post
Share on other sites

@grayman:

Because the ways of doing it are either:

  1. Make the door non-solid while it is being opened by the player character: looks like shit, feels like shit.
  2. Push the player aside with a realistic motion curve so that they side-step enough for the door to swing open, then get them back into the door frame while walking them forwards slightly: may feel like too much control is taken from the player, can play tricks with the physics system / other objects, lots of testing to get it right, requires long and clever code to make it work nicely from every angle.
  3. Do nothing and just expect the player to navigate around the swinging door with their movement keys: the closer they are from the door initially, the more difficult it is for them to back off without hindering it, doesn't feel very fluid and pretty far from the "fine-tuned movement" I was talking about.

EDIT: I was not talking about analog door manipulation, which is absolutely fine in my book :)

Edited by Briareos H

Share this post


Link to post
Share on other sites

What's "analog door manipulation"?

 

I just saw in the code that someone made an attempt at fine-control door manipulation through mouse movement 4 years ago. Apparently they didn't finish the job, because it's currently disabled. I can't tell who was working on it at the time. Issue #2316 was filed to handle the changes.

Share this post


Link to post
Share on other sites

I mean:

In 2.03, we'll be looking at "grab door, and while hanging onto it by keeping the button depressed, be able to swing it open and closed by moving the mouse".

 

My only point was to highlight that too short a frob distance would create problems, which is independent from whether it is finely manipulated ("analog") or frobbed ("digital").

Share this post


Link to post
Share on other sites

I am still wondering why you want to do this in the first place if it doesn't add anything to the gameplay! Is this just because you could and it was cool in Penumbra? Aren't there more reasonable things to do? Like the readable-close-frob and weapon-holster suggestions that would make the UI more consistent in an much easier way and were always pushed aside as only adding another option. It seems the mouse-movable door is adding just another option, but one that's connected to much more work and problems!

Edited by wesp5

Share this post


Link to post
Share on other sites

Yeah, we just want to do it cause it's cool and we want to be just like Penumbra. That's what we're all about. :rolleyes:

Share this post


Link to post
Share on other sites

No really. If it doesn't affect the gameplay and is bound to cause problems, why do it? Was it requested by many players?

Share this post


Link to post
Share on other sites

Who said it doesn't affect gameplay? or that it's bound to cause problems?

Share this post


Link to post
Share on other sites

Not to be tremendously sarcastic, but way to support and motivate our developers! <end sarcasm>

 

Sorry but beating this point and demotivating the team isn't particularly productive, or going to endear any of them to wish to address your personal agenda either I wouldn't imagine.

 

Others have been more tactful over the days in regards to this, but you've made your point repeatedly, you'd apparently prefer that volunteers work for you, rather than pursue what they desire, got it. (<--please don't quote this line out of context defensively--this is an extreme of the impression I personally have gotten, nothing more)

 

Might there be something constructive to offer, contribute, produce, generate or help with instead?

  • Like 2

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Share this post


Link to post
Share on other sites

Sorry, I didn't intend to demotivate the team. I only wonder why some complicate things seem so high priority while others never get tackled at all. Also I keep repeating some things because it looks to me that I didn't really get any answers. Like does this change affect gameplay yes or no? Makes it closing door silently possible? Makes it AI not recognize you when you look from behind a half closed door? It may make sense to figure out things like these before starting on a huge change like this...

 

As for doing something constructive, I have no experience with TDM other than a player at all, so all that I can do is voice my opinion on possible changes. I apologize that I can be a bit stubborn in that ways. I'll try to lay lower...

Share this post


Link to post
Share on other sites

You're making a series of assumptions.

 

1. You're assuming it is "high priority". No one said that.

 

2. You're assuming this is a "huge change". I've already suggested the opposite.

 

3. You're assuming we're working on this change without thinking it through (which implies that we're either inexperienced or incompetent).

 

As for not getting answers, answers to most of those points have already been posted. Asking them multiple times is unlikely to result in different answers.

 

"Why do some things get done and others not?"

 

Because we do this in our free time and people prefer to devote their time to the things they find interesting and/or important.

 

"Does this change affect gameplay?"

 

Yes, because as I said already, it can be annoying to have to click multiple times to get a door to stop where you want it to. This would allow players to have greater control over opening doors, if they wish. Since AI can notice doors that are opening/opened, this could be valuable to players who want it.

 

"Does it make silent door closing possible?"

 

AI do not hear the sound of doors opening or closing.

 

A great deal of discussion will happen in the development forums when it comes time to think about this issue, where we will debate the pros and cons, the work involved, the benefit to gameplay, the affect on existing maps, and various other factors before arriving at a decision whether to proceed or not, and in what fashion.

  • Like 2

Share this post


Link to post
Share on other sites

@wesp5

And I didn't mean to diminish your passion either! :-) Sometimes there aren't answers, because there aren't specific answers yet. Or answers are nonsensical, like affecting game-play...affect it how, for better? For worse? It's subjective. If things become broken or not as originally intended, then they are fixed before release.


"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Share this post


Link to post
Share on other sites

You're making a series of assumptions.

 

Yeah, guilty as charged :)!

 

1. You're assuming it is "high priority". No one said that.

 

Well, it got its own thread here...

 

2. You're assuming this is a "huge change". I've already suggested the opposite.

 

I know, but opinions varied. Some said no gameplay changed, others disagreed.

 

3. You're assuming we're working on this change without thinking it through (which implies that we're either inexperienced or incompetent).

 

I never did! I thought this thread was meant to discuss possible issues and this was the reason why I voiced my concern.

 

Yes, because as I said already, it can be annoying to have to click multiple times to get a door to stop where you want it to.

 

Why would one want to do this in the first place? As a beginner I usually open the doors completely. Is this because of sight?

Also I wasn't aware stopping a door is possible already. In that case it would only be an improvement of something existing!

 

AI do not hear the sound of doors opening or closing.

 

Ah, I wasn't aware of that either. But you are the first one to actually answer this question which I probably asking multiple

times here. So the NPCs only see if a door is open or closed? I always assumed the closing door sound would be heard!

Share this post


Link to post
Share on other sites
Well, it got its own thread here...

 

This thread was devoted to discussing the idea of having the frob focused on doorhandles. That's a completely separate mechanism from the penumbra thing, which was raised as a bit of an aside.

 

I know, but opinions varied. Some said no gameplay changed, others disagreed.

 

You may have been conflating two different discussions. Most of the comments in this thread are not related to penumbra-style door opening.

 

 

Why would one want to do this in the first place? As a beginner I usually open the doors completely. Is this because of sight?

 

Yes. AI will turn to look at a door that opens in their vicinity, and if the door is marked "shouldbeclosed" by the mapper, they will come to investigate. If the player opens it only a crack, the AI may not notice. Beyond that, opening the door slightly gives you a chance to look through without as much chance of being spotted. Many players also like leaving the door open a crack so they can better hear when AI are coming their way.

Share this post


Link to post
Share on other sites

I just saw in the code that someone made an attempt at fine-control door manipulation through mouse movement 4 years ago. Apparently they didn't finish the job, because it's currently disabled. I can't tell who was working on it at the time. Issue #2316 was filed to handle the changes.

 

That was me. I believe it was "kind of sort of" working. The hard, not working, part was to detect when the door had fully shut or just opened under fine manipulation. So it ended up in some bad states when you left off frobbing it, like able to rotate past its original limits upon the next frobbing, shut but door mover thinking it's still a crack open, etc.

 

[EDIT: I also don't remember if that implementation actually checked for physical collisions and stopped; you might still be able to open it through things.]

 

I can't remember if I was using hold frob + mouse wheel (not really analog), or hold frob + move mouse up and down. But it was something like that.

Share this post


Link to post
Share on other sites

Beyond that, opening the door slightly gives you a chance to look through without as much chance of being spotted. Many players also like leaving the door open a crack so they can better hear when AI are coming their way.

 

Question: is that part about being less visible through a crack actually true with our AI visibility calculation?

 

I know we do multiple traces from AI eyes to different parts of the player's body, but I thought that if any of the traces hit, the player was "visible" as opposed to "not." You certainly could do all the traces and then factor in a "concealment" factor based on what fraction of the traces hit. But I thought we were worried about the performance of that and just stopped testing on the first trace to hit, calling the player visible, not allowing for a concealment calculation? Multiple long traces from AI to player body points can be computationally expensive.

 

Maybe that changed since I was active, don't know. If it's still the old way, it might be worth testing the "do all the traces and calculate concealment" way and seeing if semi-modern hardware can deal with it.

Share this post


Link to post
Share on other sites

Aren't lid's on chests handled the same way in the code as doors, if you change the way the door works by opening the door by the handle does this mean that handles have to be added to chest lids.

Share this post


Link to post
Share on other sites
I know we do multiple traces from AI eyes to different parts of the player's body, but I thought that if any of the traces hit, the player was "visible" as opposed to "not." You certainly could do all the traces and then factor in a "concealment" factor based on what fraction of the traces hit. But I thought we were worried about the performance of that and just stopped testing on the first trace to hit, calling the player visible, not allowing for a concealment calculation? Multiple long traces from AI to player body points can be computationally expensive.

 

No, you're basically right. I have a proposal on the books for partial cover system involving multiple traces, but atm I think we only do enough to ensure the player can't hide behind a broom. But having the door open a crack is still useful, since it blocks many of those traces and makes it easy to sever others before the AI goes alert.

Share this post


Link to post
Share on other sites

Ah, I wasn't aware of that either. But you are the first one to actually answer this question which I probably asking multiple

times here. So the NPCs only see if a door is open or closed? I always assumed the closing door sound would be heard!

 

This particular question does not need to be answered for you. You have ALL the tools at your disposal to test this yourself.

Open any map with an AI standing outside, and repeatedly slam the door. Do they notice?


I always assumed I'd taste like boot leather.

 

Share this post


Link to post
Share on other sites

I'd like to bring this topic a bit back from the unrelated "fine door manipulation" back to the "unrealistic long frob distance".

 

For my Swift Mazes maps, I have set a lower frob distance (70 IIRC), because the default 100 meant the player could frob the chain while standing an unrealistic distance away - and since he has no arms it looks silly, almost like "let me operate that lever over there with my magic telekinesis ability".

 

But I've also disabled frob on the door itself, so the "frob door at hinge" is not a problem here. And since the pullchain or levers are a lot smaller than doors, the closer distance works.

 

I think what Springheel meant isn't that the player needs to stand "20 units in front of door, then getting it slammed in the face, then move away".

 

Apart from the fact that this can (and does) already happen (if you stand too close) and players already need to deal with it, the thing that should/could be changed is the "frob the door from 100 units away from the hinge".

 

Basically, the distance should be measured better - maybe from the handle, maybe the angle should factor in (closer to the rotating edge).

 

Changing the default from 100 to 80 might already addresse the concerns while not change the normal player behaviour. Or the distance calculation could be improved (distance to center instead of to closest point?).


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

The easiest way I thought would be to only make the handle frobable. This way the frob distance would be calculated from the origin of said one. (Bolocks, the origin does not play a role here). In addition, door placement would be more relevant and mappers would get another feature to play (deal :) ) with.

 

However, the frobability of the door and the handle attached is linked together for whatever reason. So if the door is non-frobable, the handle is, too and vice versa. Very odd.

 

EDIT: Post corrected. :(


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

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

The frobbability of the handles is linked, because that was how it was supposed to be. Technically, handles could be handles without being frob_peers, but the code simply sets up both at the same time.

 

So, to make a frobbable handle, just make a normal entity, make it frobbable, set a "frob_action" script on it, and attach it to the door (but don't add it as handle). In the script that make the code simple trigger the door. It's abit cumbersome to setup.

 

However, making only the handles frobbable is quite a game mechanic change. Making the door not that far frobbable from the hinge side would be less intrusive. (It depends on if this is for one map only, or the TDM wide default).


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
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.

Sign in to follow this  

×
×
  • Create New...