stgatilov
-
Posts
6825 -
Joined
-
Last visited
-
Days Won
237
Posts posted by stgatilov
-
-
33 minutes ago, AluminumHaste said:
Are you being obtuse on purpose? You know exactly what he means. With his limited time to work on the project, he'd rather spend his time on game breaking bugs.
Hey, calm down please.
-
1 hour ago, ChronA said:
The essence of the proposal is that whatever interaction is the most indispensable--the "primary action"--that should be mapped to the default short frob that everyone is familiar with. The less important "secondary" action gets mapped to the new long frob, which we hope will be more discoverable than the use-while-frobbing combo.
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.
-
On 9/25/2023 at 8:48 AM, Daft Mugi said:
Are you going to look into this book stuttering issue that was introduced in 2.12?
Ehm... not really, to be honest.
If I get to books, I'd better look at book stuck issue: it completely breaks the game.
-
1 minute ago, snatcher said:
Yeah, actually @Daft Mugi could consider making parts of the source code he works on script-friendly, instead of adding obscure cvars that we easily forget about and might never be worthy of a proper in-game setting.
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. -
6 minutes ago, ChronA said:
The TDM training mission is technically competent, but it fails at the critical requirement of giving new players motivation to slog through the learning curve in order to play the game proper. This is an area where Thief inarguably did it better even 20 years ago. TDM's tutorial is too long. It is bloated with too much non-essential information, and lacks any teasers of the world building or gameplay loops that would motivate a player to try the game proper.
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.
-
8 hours ago, Daft Mugi said:
Is there agreement that the following issues need to be solved?
- How can the control scheme be made less cumbersome?
- How can bodies be shouldered without first dragging them?
- How can candles be extinguished and lanterns toggled off/on without first picking them up?
- How can so much key pressing and mouse clicking (currently in TDM 2.11) be eliminated?
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.
QuoteEven if you disagree with long-press frob, is it ok to include long-press frob in 2.12 dev if players want it?
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. -
9 hours ago, Daft Mugi said:
Another reason for long-press frob for special action: 2.11 already has one, multiloot.
Quick-press frob to loot.
Long-press frob to multiloot.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.
-
10 minutes ago, Daft Mugi said:
This long-press frob proposal has already been play tested and agreed to be a good control scheme by several players. Double-click frob would need new code written, would need to be play tested, and would need to be fine tuned based on player feedback. Another rewrite of the code would be a distraction and may not bring us closer to the goal of "providing a better experience for new players as well as longtime players," especially since one has already been found and proven: long-press frob.
After 7 months of player research, code experiments, early player feedback, adjustments, rewriting code, and more player feedback, I believe long-press frob is good enough, given all of the compromises, imperfections, and its iterative design. It solves the problems stated in the proposal on the first page, and its design goals are met.
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.
-
1
-
-
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). -
25 minutes ago, Wellingtoncrab said:
There is a method via the delay cvar for experienced players who prefer the old system to restore it, so I am uncertain what the down side is really?
I don't pay attention to this argument, sorry.
QuoteWhat is getting lost is the primary interaction with a body imo is actually to shoulder it - not drag it. Obfuscating this behind a second input is clunky and confusing to new players.
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.
-
2 minutes ago, wesp5 said:
I like your idea, but I have not bound Frob to the mouse, so you mean single frob vs double frob, yes?
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?
-
1
-
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.
-
3
-
-
On 9/5/2023 at 7:43 PM, Geep said:
Instead, let me show the end goal I was thinking about, through a mockup. The idea is to have a non-moving oval (representing a disc laid flat on the floor, in perspective), with a small colored square constrained to move smoothly along it, representing the direction of the sound source. In the mockup (attached cropped image), the oval is blue, the square is red, and the direction being indicated is front right. (Or maybe the ring should be dark red and the square light blue... or disk could be solid, etc.) The translucent field is 240 (out of 640) pixels wide, so the oval shown is roughly 30 pixels wide. The perspective could also be made more prominent, if instead of a uniform stroke width on the ring, the lower ("nearer") edge was thicker than the upper ("farther") edge.
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?
-
On 9/4/2023 at 12:10 AM, Geep said:
@stgatilov, both the compressed Carleton and Stone fonts look better than the original uncompressed IMHO. We could give the user a choice of either, while keeping the gui scale factor fixed at 0.25 (e.g., 12 pt). If Stone's artifacting you mentioned was not too problematic.
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?
QuoteAnother topic. I'd like to play around a bit with the 5 sound-source-location variables you were using to position the white bars. In file tdm_subtitles_message.gui, these were of form:
"gui::subtitle0_oriBackLeft" // where 0 if subtitle was shown in vertical "slot 0"; could be 1 or 2
and name suffixes were _oriFront, _oriFrontLeft, _oriFrontRight, _oriBackLeft, and _oriBackRightCould you briefly explain what values these could take on, how they would work or differ, how often they get updated? Thanks
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. -
17 hours ago, Geep said:
@stgatilov, would it be correct to say that the latest public 2.12dev contains the original 4:3 fonts, and does not distribute the narrowed 16:9 fonts (e.g., for Carleton and possibly Stone)?
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.QuoteAlso, I'd greatly appreciate it if you could expose a numeric variable whose value is set to indicate whether the current subtitle is of type "verbosity story", "verbosity speech", or "verbosity effect", that can be read (but not set) in tdm_subtitles_common.gui
Yes, this is indeed possible, not really hard to do in C++.
To you want to color the text?-
1
-
-
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. -
On 8/28/2023 at 9:58 AM, snatcher said:
Are we talking two (bow-related but) unrelated cases?
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:
This time I hope to learn who posts the event for deleting attachment...
-
1
-
-
According to the last three events, someone deleted the arrow from script:
Spoiler[116336] Attach: player1_weapon <- idStaticEntity_atdm:attachment_aimer_7 Stack trace (hash = FFFF20A8): idCommonLocal::PrintCallStack G:/TheDarkMod/darkmod_211_src/framework/Common.cpp:618 idAnimatedEntity::Attach G:/TheDarkMod/darkmod_211_src/game/Entity.cpp:8724 idWeapon::Attach G:/TheDarkMod/darkmod_211_src/game/Weapon.cpp:3612 idWeapon::GetWeaponDef G:/TheDarkMod/darkmod_211_src/game/Weapon.cpp:1064 idPlayer::Weapon_Combat G:/TheDarkMod/darkmod_211_src/game/Player.cpp:4164 idPlayer::UpdateWeapon G:/TheDarkMod/darkmod_211_src/game/Player.cpp:4422 idPlayer::Think G:/TheDarkMod/darkmod_211_src/game/Player.cpp:7551 idGameLocal::RunFrame G:/TheDarkMod/darkmod_211_src/game/Game_local.cpp:3366 idSessionLocal::RunGameTic G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3061 idSessionLocal::RunGameTics G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3107 idSessionLocal::FrontendThreadFunction G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3157 <lambda_4da128457a8cbff73e848802e63deb86>::<lambda_invoker_cdecl> G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3234 BaseThreadInitThunk :0 RtlUserThreadStart :0 [116336] Attach: player1_weapon <- idStaticEntity_atdm:attachment_broadhead_8 Stack trace (hash = FFFF5B10): idCommonLocal::PrintCallStack G:/TheDarkMod/darkmod_211_src/framework/Common.cpp:618 idAnimatedEntity::Attach G:/TheDarkMod/darkmod_211_src/game/Entity.cpp:8724 idWeapon::Attach G:/TheDarkMod/darkmod_211_src/game/Weapon.cpp:3612 idWeapon::GetWeaponDef G:/TheDarkMod/darkmod_211_src/game/Weapon.cpp:1108 idPlayer::Weapon_Combat G:/TheDarkMod/darkmod_211_src/game/Player.cpp:4164 idPlayer::UpdateWeapon G:/TheDarkMod/darkmod_211_src/game/Player.cpp:4422 idPlayer::Think G:/TheDarkMod/darkmod_211_src/game/Player.cpp:7551 idGameLocal::RunFrame G:/TheDarkMod/darkmod_211_src/game/Game_local.cpp:3366 idSessionLocal::RunGameTic G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3061 idSessionLocal::RunGameTics G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3107 idSessionLocal::FrontendThreadFunction G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3157 <lambda_4da128457a8cbff73e848802e63deb86>::<lambda_invoker_cdecl> G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3234 BaseThreadInitThunk :0 RtlUserThreadStart :0 [116384] Destroy: idStaticEntity_atdm:attachment_broadhead_8 Stack trace (hash = 00001C57): idCommonLocal::PrintCallStack G:/TheDarkMod/darkmod_211_src/framework/Common.cpp:618 idEntity::~idEntity G:/TheDarkMod/darkmod_211_src/game/Entity.cpp:1545 idStaticEntity::`scalar deleting destructor' :0 idClass::Event_Remove G:/TheDarkMod/darkmod_211_src/game/gamesys/Class.cpp:1093 idClass::ProcessEventArgPtr G:/TheDarkMod/darkmod_211_src/game/gamesys/Class.cpp:1049 idEvent::ServiceEvents G:/TheDarkMod/darkmod_211_src/game/gamesys/Event.cpp:619 idGameLocal::RunFrame G:/TheDarkMod/darkmod_211_src/game/Game_local.cpp:3405 idSessionLocal::RunGameTic G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3061 idSessionLocal::RunGameTics G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3107 idSessionLocal::FrontendThreadFunction G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3157 <lambda_4da128457a8cbff73e848802e63deb86>::<lambda_invoker_cdecl> G:/TheDarkMod/darkmod_211_src/framework/Session.cpp:3234 BaseThreadInitThunk :0 RtlUserThreadStart :0
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.
-
1
-
Development versions (2.12)
in The Dark Mod
Posted
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?