Obsttorte

As promised here is the first proof of concept. Currently it doesn't distinguish between the different sides the player is approaching from. Whether it gets added would depend on how your opinions are, as after testing the setup I am undecided on that matter. https://www.mediafire.com/file/yqu0xf9bx3035pi/fastdoor.pk4/file

The reason I am doing this is so that others can see who applied the change and for what reason (I also add the bugtracker number). It also helps me to find my changes later on quickly if fixes are needed (which happens more often than I like to admit ) Regarding the actual topic: I've only glanced through the thread as I haven't followed the topic by now, so I just add my two cents, which may be redundant. If misinterpretation occours I may read the whole thread more carefully later, but right now the coffee hasn't kicked in yet You cannot climb in a crouched position irl, so I don't expect it in a game. Therefore in regards to visibility the game should handle the player as if he were standing independent from crouch/stand stance while climbing a ladder, rope or mantling. Nevertheless players should be able to tell the game, which stance they want to be in after said action is finished. The stance icon at the light gem should represent that. As tapping the crouch key would cause the stance change, sliding down should still be initiated by holding the crouch key, like it is now. Although I think that the time for how long you have to hold the key before sliding begins could be shortened. In this regards it would be nice if holding the crouch key could be used to abort mantling, if for example you notice that there is a guard coming around the corner. Or is this already possible?

Interesting mission of good size, not to small, not too big. I liked the visual style and the voice-acting was pretty well done. Kudos to the speakers. Both were good to understand even for a non-native speaker like me. Overall the atmosphere was good. The only downside is that the mission is way too easy under the highest setting. A few more thoughts: I overall like the approach you are taking and trying to find some means for the loot to acquire by the usage of the shop. This holds quiet some potential. And I hope there will be more from the voice actress. Despite some criticism I can easely recommend this mission. Well done.

@snatcherWhy should it not open into your direction? It does so now. I agree that it will probably not work well and it is also counterintuitive that fast opening would work with a door opening towards the player, but I rather not implement something that restricts the players abilities of interacting with his surroundings compared to how it is now. Especially as the whole idea was the exact opposite.

If the door opens to your side, it will behave like always. It is intented to open faster when opening away from you. Then I misinterpreted that. Sorry.

@WellingtoncrabIt wasn't my intention to discourage you in giving feedback, it is appreciated. But if you give feedback you will get feedback on that, too. And even though I can't be sure as 90% of the interhuman communication is non-verbal, and this part is obviously missing when discussing in a forum, but the last paragraph of yours reads a bit passive-aggressive to me. I don't think that this is helpful to anyone, especially as I have already stated that the idea of enhancing the feature, for example by allowing to trigger it via other means as described by you is not completely of the table, but requires some additional upvotes. Otherwise I am simple not convinced it is a necessary or a positive addition. But again, I do not decide this on my own.

That's why in return I asked whether players tend to run through missions or when approaching doors. As the game is about sneaking I would guess that most of the time they either move with normal speed upright or crawling fast. Accidently alerting ai should be off the table when you are running around the whole time. I see the issue, but I don't understand why you expect it to exist. I have to make a prototype once I find the time, but I consider issues like this unlikely. That's what the lockpicks are meant for, and even those are useless most of the time if the mapper decides so (like they do most of the time). It's is therefore doubtable whether mappers would use this new feature, which they first had to be aware of, and whether players would use this as they can't know which missions uses them and which doors are bashable and which not. This seems to be a huge source of confusion and frustration considering there is almost no gain and we already have, as mentioned, other means for the player to open the door (In thief wooden doors could be opened with the sword and I think this feature exists in TDM, too, although barely used by the mappers). I am really opposed into implementing something that everyone does as he likes with not much potential gain, considering that something as fundamental as door behaviour should be consistent among missions. You weren't meant btw. My point was that the title by snatcher and the points he brought up implies that he had a different idea of this door opening feature then I had, despite quoting me in the op. I just wanted to clarify what my ideas are as most likely I am the one to implement it, and my experience tought me that most of the opposition I am facing is against stuff I never wanted to add, but that got brought up during the discussion. So to sum things up: I'll see if I can setup a test map with a rough proof of concept to illustrate what I mean and to see whether the potential issues you've brought up arose. We can further discuss on whether enhancing this feature makes sense, although, as this was originally brought up in a thread dealing with object manipulation, I think is beyond the scope. But others may agree with you, so in the end it is not my decision. We'll see.

No. Those are binaries uploaded by someone else who had an issue, so I guess those are the reason. I was surprised myself but normally it loads faster.

Timing is everything. I've just committed the changes to svn. Also filed a bugtracker: https://bugs.thedarkmod.com/view.php?id=5984 I made a little test run on a new job using this feature. There are only to instances were it came to use, but at least you can see that normal interactions don't seem to be affected how I suck at TDM (Had to make some adjustments in between. I wanted to cut them out, but the video program didn't )

The ignore feature is really funny. It is as if you were talking with a ghost. (A really annoying ghost )

@snatcher@thebighI never mentioned self-closing doors nor is this something I would like to see set as a standard. It's a bit pointless discussing possible gameplay additions if you don't read carefully. I think this statement made it pretty clear that the door is not supposed to close on itself, but to let it react delayed if the player frobs it while running. The whole argumentation behind this (beside gameplay implications) that I brought up in the other thread is that irl you are indeed able to close a door behind you, whereas in TDM you can only interact with things in front of you. This is an unnecessary limitation imho considering that one of the strengths the player has opposed to the ai is his agility. Also note that this will still require some timing from the player, as the intention is not to let the door wait for the player. If he frobs it too soon, he will block himself, too late, and he may miss it (the door will not be frobhilighted anymore once the player presses the frob key). Obviously this requires some fine-tuning.

Which is an unarguable sign of quality

That's definetely something that needs consideration. The idea was, though, that the door opens faster if the player is running at it. I am not sure if players usually tend to run through the mission all the time. That would go against the intention. It is not about bashing it open for the sake of bashing (the thread title may imply this). The idea is to speed up the progress of getting through a door when fleeing and to be able to close it behind you with a minimal chance of hindering yourself, something that doesn't work well atm. Having to hold the frob button would slow down the progress. I had a factor in mind. So like the door opens 50% faster or twice as fast. This way it would still depend on the settings the mapper applied. Yeah, as mentioned above not my intention. Guessing from the thread title and @snatcher's initial post their seem to be two different ideas existing on what we are talking about, so I would like to clarify. My idea that I brought up in the other thread was to 1. allow faster door opening on running (with the downside of creating some noise) and 2. allow to close a door behind you after having ran through by letting the door react delayed to the player frob (so you frob it while it is still in front of you, but once it starts closing you have already passed it) The other idea and a gameplay mechanic to be found in quiet some other, mostly more action oriented, games is to slam a door open, normally for the purpose to surprise the enemies inside, get inside fast or to bash away anyone standing directly behind the door and knocking him out. This is NOT what I had in mind. Pushing whoever stands behind the door away from it when fast opening so the door doesn't get blocked by the ai is something that might be worth discussing, although I don't consider it necessary.

Agreed. Wouldn't make much sense on sliding doors anyways, I guess. Another thing to take into account is the size. That's no problem, it isn't an animation, the doors just rotate. I disagree here. You cannot open a door faster if it opens towards you. And I fairly doubt players expect this behaviour. In addition, if it only works if the doors open in the direction you are running to it adds a nice little detail both towards the importance of the opening direction for the mapper (beyond aesthetical or logical reasons) and towards the things the player has to consider when keeping track of possible escape routes. I again disagree. The idea was that you frob the open door before passing through it but it starts closing with a minor delay, so it doesn't block you. And compared to the player the ai is intented to be clumsy (they have the bigger weapons in return). I think we already have those, or at least sounds we could utilize for this (heavy object falling on wood for example). The sound can be propagated by the door itself. No issue here. Here things get problematic. We had the idea of pushing away the ai in the past, and I created a working prototype. But this is far from perfect. For the rest: I would not like to add anything that requires new animations or that allows the player to turn doors into weapons. Pushing away ai might anyways be something we scrap, because as far as my original intention has gone it is more about making the whole process of "escaping through a door and shutting it behind you while fleeing" less clumsy and not to outweight a possible player disadvantage that imho doesn't exist.

An update regarding the multilooting. I have added two cvars to control the timing, one for the minimum interval between two consecutive frobs, one to handle when to disable multilooting, even if the player still holds down the frob key. I chose the values more or less from guessing, so they are definetely arguable. Cvars are also adjustable via menu guis, so there could be different pickup speeds depending on personal taste (a bit slower to give more time to read what you have picked up e.g.). Multilooting starts if an item that can go to the inventory (loot, weapons, playertools, readables et. al.) got frobbed and the player keeps pressing the frob botton. Other objects cannot be interacted with in this state (you can see this at the second table were I start looting, then frob hilight the button and continue looting. I had the frob button pressed all the time) The normal frobbing mechanics are not affected by this as far as I can tell. One thing that may needs some love is that the code doesn't differentiate were you multiloot. We may not want this on items attached to ai. Any thoughts? Note that I consider this still a proof of concept as this is quiet some change to a core mechanic, so I would prefer to get some feedback before commiting it.

As Xolvix said. But as stated before, I don't think auto-looting is really on the table. Or is there anyone thinking this is necessary?

I'm not. It's just funny. You know that this dev thingie is more of a honorary title? It's not like we are employed or something. Most "devs" that started creating the project aren't even present anymore, and most of those who are currently active (including myself), weren't present at the early days. In addition, people jump on and off depending on how much time and motivation they have. I haven't been active the last two or three years or so, for example. It is not that noone can or want to understand where you are coming from, it is perfectly clear and it makes perfect sense. But what you can't or don't want to understand although several members have already explained that to you is that the workflow that has evolved over the time is that the devs spend their time on the most important matters first, whereas what is important and what not is something everyone decides on his own. If you consider the console warning spam important, you are free to improve the situation as far as possible. And we are thankful for your work. But if each status update of yours and your progress is accompanied with a complaint about how important the stuff you are doing is and that we are just to incompetent to acknowledge that or that we are just to lazy to deal with it in addition to what we are already doing, how on earth can you expect to be taken seriously. In a real life situation, face to face, a sarcastically placed smiley would be the least you'd have to expect as a reaction to your behaviour.

Funny, as I was considering opening a new topic but then thought that I don't want to clutter the forum with different threads that all relate to the same aspect of the game. But I am not opposed, though not able to do so myself. Yeah. I though that there should be an interval between the different pickups anyway, as like this it really is like playing a vacuum cleaner. Would make a nice mod, though. Vacuum Cleaner: The Suck Project.

@DragoferNo, no, no, it is our incompetence and lazyness. I am incompetent and lazy, you are incompetent and lazy, everyone around here is incompetent and lazy ... except Nort, he is a god.

That's obviously a proof of concept that needs some fine tuning has to be tested in real missions for possible issues before it can even be considered whether or not to add it to the mod. But I guess that is what you have meant. While we are talking about frobbing there is something else that came to my mind. Interacting with doors when running away from the guards (yes, not all of us ghost) is extremely clumsy sometimes. I like to propose that the door behaviour differs if the player is running when frobbing a door in a manner that when opening the door it gets opened faster, but propagates a suspicious sound upon doing so when closing the door, the closing is in addition delayed. This would mimic that player closes the door behind himself. Note that player interaction via frob is limited to what the player has in front of himself, whereas irl you can easely slam a door close behind you. This would make the approach of running away, including the usage of tools like the flashbomb, much more useful as compared to just quickloading, which is, in all honesty, currently the best strategy under almost all circumstances. I thing there is a gain for gameplay here, and the changes should be minor. But I would like to get some feedback, just in case I have overseen an important aspect.

Indeed. And yes, I noticed that. I wasn't offended, though, if that what it reads like, and didn't meant to offend you. There is a code change involved here. There is an additional flag in the code of the entity base class that I have added to the brittle fracture class (used by func_fracture). So it will work in 2.11

Because that is not what I have written, and you are right that basically the appearence change. Taking a look at the security cameras it appears that they are set to AIUSE_BROKEN_ITEM to begin with, which oddly causes issues with the glass, as it will alert the ai even if the glass is not broken yet, but doesn't seem to behave so with the camera. There is quiet a bunch of other spawnargs set, though, so maybe some of them can get the desired behaviour without the necessity of further code changes. EDIT: I just looked at the code and could see that the security camera does what I intented for the func_fracture. It has an inactive visual stim that gets enabled upon destruction, at least if notice_destroyed is set to 1 (what is the default). I guess I can just mimic that for the func_fracture. EDIT EDIT: Works like a charm.

Using the detour of implementing it in a fm first definetely can help convincing devs of adding stuff to the core mod, especially if it's about something most people didn't explicitely asked for or solving issues most people do not consider to be such.

That's what I wrote, a bit shortened, though. That was another issue I have already resolved. The issue was that a flag was added to the entity baseclass to mark it as broken. However, the functions called by default entities versus the one func_fractures use are different and the flag has not been set in the latter. By doing so the ai does notice the func_fracture if the AIUse flag and the visual stim are set at map start. The only issue now is on how to make the ai aware of the glass once it's broken. Now that I think about it, it might be already sufficient if the visual stim is off at map start and gets turned on once the glass breaks. I'll have to test that.