stgatilov

I plan to make dev build today evening. If your machine is under repair, may I commit your 3 patches beforehand? I mean: leaning, mantling, and weapon selection. Or you want to do it yourself? Or are you waiting for more feedback?

Hey, calm down please.

There also such thing as "code inertia". You are discussing something as simple as "controls" or "bindinds". But in reality it is the whole logic of frobbing, grabbing, dragging, light extinguishing, light handles, scripts and spawnargs --- all tied in a single knot. The code existed long time in a way that you can shoulder a body only after you grab it, and you can extinguish a candle only after you grab it. As far as I understand, @Daft Mugi did not refactor everything so that this idea no longer exists --- that would be too hard right now and probably break too much. Under the hood, there old logic somewhat remains in addition to the new one. Such things often bite back with bugs, corner cases. Also it makes it even harder to further change things in frobbing. Of course, one could say that the new code has been extensively play-tested, but then we'll find yet another mission where something is used in unexpected way and we need to change something again. Indeed, happy people will just add more if-s and condition-s, but often it just shifts the problem into a different case. So you know, if there are several plausible solutions, I would definitely lean to a more conservative one, which better complements the old one.

Ehm... not really, to be honest. If I get to books, I'd better look at book stuck issue: it completely breaks the game.

Oh god no! With this patch, the frob code already looks like spaghetti. If you make it scriptable, it only means all non-standard configurations will break all th etime.

Yes, absolutely. It is not tutorial, it is "training" mission. More like a playground, which appeared when no real missions existed. New Job does not count either: it just shows 3-4 tips, which are on the level of generic idea. Tutorial should be short, simple, linear, and able to cite current player's controls straight into text messages.

One issue I really see with saying "just click to shoulder body" is that clicking again does not drop it. Right now the player has to press Enter to shoulder the body, so it is logical to press Enter to unshoulder it. But as soon as we try to simplify it and move shouldering to the same mouse button, it would be natural to expect that player should unshoulder with the same mouse button too. But it does not happen by default. It is indeed possible to unshoulder on click. That's what @Wellingtoncrab said is already done with the patch, although it did not work for me when I tried --- perhaps I messed something up. The real issue is that player might also want to frob doors when body is shouldered, so now opening doors and unshouldering body gets mixed together. It is possible to unshoulder on click only when there is no object highlighted, but that's still a bit strange. And I think there is no perfect way around it.

I think not. The goal is to have convenient way to instantly shoulder a body and instantly extinguish the candle. The old scheme is bad because frob is by default on mouse, and use is by default on keyboard, so doing click + keypress + click feels awful. As for discoverability, only the proper tutorial mission can really solve all the problems. You have something like 4 pending changes right now. Perhaps you commit the other three (which are less radical) to trunk, then I'll make a dev build of it, and then I'll apply your patch and create a test build (also in tdm_installer) with frob changes? Then I can do the same with double-clicking prototype.

It is not a long-click, it is click-and-hold, where holding time matters (and is much longer than long click). So with your change it would be short click, long click, and click-and-hold. Click-and-hold at least continues short click, while long click does not. When I pick up a candle, the candle is lift off with delay --- that's because long click does not continue the action of short click, so the code has to wait until mouse is released and can't apply the short-click action immediately. That's exactly the issue that you fixed with crouching, and now you introduce it in another place.

Maybe I'll try make a double-click prototype? Indeed, I don't have 7 months, so it won't be anywhere as polished as this proposal, but perhaps I could make something enough to understand how it feels. The double-clicking can be made generic, so that we would probably be able to assign other actions to double-click. P.S. I think I only saw long-click thing on touch screens, and there I always see some kind of circular progress bar which explains to me that holding the button will do something special. But that's not something suitable for TDM unfortunately. And yeah, I cannot easily google up discussions regarding long-click with mouse.

Well, I'm sorry I missed the discussion. The only threads I see are 2 weeks old. You decided to change core aspect of gameplay, such things are painful.

Oh no, you are changing the controls scheme. Previously body grabbing was toggle-like behavior (click to toggle between grabbed and not), now it has hold-like behavior (has to hold to drag body). Previously clicking a body did not shoulder it, now it does. Previously holding the click slightly longer did not cause a different action on a candle, now it does. The old controls scheme is consistent: you click to grab/ungrab, then you Enter to perform action on the grabbed object. The double-click scheme is also consistent: you still click to grab/ungrab, but now you also have double-click to combine grab + action. The proposed scheme is totally inconsistent. Clicking on an object grabs it, clicking again ungrabs. Clicking on a body... shoulders it... why? Then clicking again does not even unshoulder it. Long click on a candle extinguishes it without grabbing, but long click on a body grabs it... why? So you hold you mouse for grabbing bodies, but for grabbing candles this does not work... why? Sooner or later someone will come and say that objects should also be grabbed by holding, since bodies does so. And we'll make excuses like "you know, body grabbing is garbage and nobody needs it, but grabbing objects is different, so we just made different controls, and now making them similar won't work". I like the idea of making instant-shoulder and candle extinguishing easy to do, but the exact controls scheme is something very strange.

Ok, maybe we should just imagine that the head is rotated a lot but the camera is rotated less for the sake of player's convenience. After all, it is much easier for a human to comprehend rotated view when his head is rotated accordingly (vestibular system tunes to the real-world gravity vector, not the in-game one).

I don't pay attention to this argument, sorry. I can agree that grabbing bodies has little gameplay utility and is something like an engine show-off. But situation with candles is different: both grabbing and extinguishing are useful. Click vs Long click, irreversibly extinguishing candles accidentally, eternal arguments about exact duration --- this confusion is removed with double-click. And new players have equally low chance to discover double-click and long click, unless it is explained somewhere. UPDATE: And the double-click approach does not change existing controls, only adds new meaning for the second part of double-click.

Yes, custom keys works the same.

It feels uncomfortable that two entirely different actions are done depending on how long I hold the button. This is not even a widespread UI design. Why not double-click instead? Suppose something like that: Single-click body to grab/ungrab it Double-click body to shoulder it Single-click candle to grab/ungrab it Double-click candle to extinguish it This even satisfies the sanity condition that double-click action should include the single-click action: When double-clicking body: first click -> grab it, second click -> shoulder it. When double-clicking candle: first click -> grab it, second click -> extinguish and ungrab it. Isn't it better in all regards?

I asked myself and my family: how would they lean into the doorway if they don't want to be seen? All of us prefer to only expose head. And this is impossible for a human being to do with such a low rotation angle. Moreover, my family members also suggested leaning horizontally, i.e. with full 90 degree angle. As far as I understand, the main reason to love your change is because it simply makes leaning easier for the player. But I think it is wrong: leaning should only be used to quickly glimpse what is around the corner. If you want to look properly, just go around the corner with your full body. And most definitely, it is wrong to make shooting bow easy while leaning. Of course, we are not some kind of spies/special agents, maybe someone knows better.

Yes, it sounds like better idea than virtual 5-speakers. I guess simply passing local X and Y coordinates would be enough for this. Do we want to show elevation somehow?

I guess at this moment we have too many analysis and need "the decision" Maybe I'd share the GUI code for And we'll just accept it or decide what needs to be changed? The code is here: https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/ui/UserInterface.cpp Check SubtitleOrientationProbeVars, ComputeSubtitleProbeValues, basically everything about subtitles and probes. The source for spatializedDirection is in https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/sound/snd_world.cpp (just search for spatializedDirection ). So I think right now the XY plane in listener's local coordinates is considered. 5 virtual speakers are placed. Then we look at the unit direction vector to sound source (distance does not matter), and decompose it as linear combination to two adjacent speakers. The coefficients are put into these "oriXxxYyy" GUI vars. As far as I understand, this approach is used to compute volumes for individual speakers on 5.1 sound systems. Volume affects alpha-transparency (_alpha), but I think it is not very reliable now.

It is available in dev builds as engine feature (6283), but it is not used in any GUI scripts. I was hoping that someone would volunteer to propose, tweak, and test the change of font size and rectangle of subtitles. Perhaps I should just do rough approximation myself and commit changes I feel that feature of showing location is pretty desolated too. Indeed, I implemented it and it works, but it fells horrible. People are asking what the hell this moving white bars are, which totally confirms the idea that current design does not work. Yes, this is indeed possible, not really hard to do in C++. To you want to color the text?

Now, it is just for "auto-remove me after X seconds". But nothing uses it, except for some platform (not used anywhere) and the famous "penis". The penis is attached to one type of proguard, which is indeed used in High Expectations, but I have no idea how this suicide script can migrate from penis to anything else. And I don't see any C++ code for dynamically spawning tdm_suicide. While I checked that the values that I printed are usually correct, and tdm_suicide.script:54 is indeed removal of entity, I think that logic won't help here. Either the information about tdm_suicide is simply nonsense, or there is some major corruption happening long before crash. I wonder if @snatcher can reproduce the crash from fresh start, or whether he reproduces it from particular save file.

I think it's the same issue. But it seems that either of the two attachments can get deleted. Anyway, I'd be happy if someone clarifies what tdm_suicide.script does and why it affects weapon attachments. In case anyone used it...

This time aimer was killed by tdm_suicide.script. Trying to understand why it was invoked...

@snatcher, I uploaded second debug executable: https://drive.google.com/file/d/1vP_XcRAo8-YQeibMsprT72ANZFKZo8Iq/view?usp=sharing This time I hope to learn who posts the event for deleting attachment...

According to the last three events, someone deleted the arrow from script: The first two events happen inside GetWeaponDef when player switches from blackjack to bow. This should be the only place messing with the weapon. Two attachments (aimer + arrow) are added here. But then the arrow gets destroyed inside ServiceEvents, which is unexpected. Normally, it should be destroyed in the same GetWeaponDef at the very beginning, before creating new attachments. This is either triggered by script code, or by C++ code which posts delayed event.