stgatilov
-
Posts
6801 -
Joined
-
Last visited
-
Days Won
234
Posts posted by stgatilov
-
-
I tried both configs, no crashes for me.
-
On 9/2/2023 at 5:05 PM, Frost_Salamander said:
Also I could reproduce the bow crash in the starting tunnel pretty easily just by partially drawing the bow and cancelling it until it crashed. Sometimes it takes a while but you shouldn't need to go up into the street and do anything crazy.
I make automation script which draws bow for 0.1-0.85 seconds (with 0.05 sec increments) every 3 seconds.
The SVN version does not crash.Perhaps I should take your config file and retry on 2.11.
Also: do you have any mods installed? -
On 9/22/2023 at 6:24 PM, Geep said:
@stgatilov, attached is a screen shot of what I'm calling the "sound source cue" or "sound source oval" directional indicator. Unlike the previous Photoshopped mockup, this is implemented as a prototype in gui script.
I have implemented your idea:
The volume-to-alpha thing is a bit weird since it does not take volume of the sample into account (hopefully improved in the future). And perhaps someone would replace images (I'm not an artist, you know).
But it works and looks nice
-
3
-
-
47 minutes ago, Skaruts said:
It may also happen accidentally if your fingers twitch, or if your mouse misregisters an extra click, or when you think you didn't hit the target and immediately click again, but it so happens that you did hit the target the first time;
I think people will have way more misclicks with single-click vs long-click prototype: you don't even need a second press to do the wrong action. And increasing the duration threshold to reduce this chance will also increase delay of single-click actions, which is hard to notice on 200 ms.
-
2 hours ago, Daft Mugi said:
The quick-press frob action never happens before or after the long-press frob action. The single-click action always happens before the double-click action.
Your implementation just falls into the following category: "you delay all single-click actions until you are sure it cannot turn into double-click/long-click".
-
2 hours ago, Daft Mugi said:
The fundamental design of double-click is to always perform the single-click action before the double-click action. The single-click action of a candle is to pick it up (and move it). That'll always happen before extinguishing a candle with a double-click. There's no way around that unless its fundamental design is changed.
That's the same for all versions, for both double-click or long-click.
You either start single-click action immediately when first click starts (proper solution), or you delay all single-click actions until you are sure it cannot turn into double-click/long-click (ugly), or you just map the different action to a different key (proper solution). Pick your poison.
-
54 minutes ago, Wellingtoncrab said:
Since candles are still picked up on double click, this is maybe a little better but not ideal solution for ghosters who don’t like to pick up or move objects at all - doesn’t describe me but I know from the missions I have worked on there are at lots players who have adopted this play style.
Can extinguish but cannot move the candle?
These rules just need to be relaxed slightly for TDM realities.
The game has never allowed extinguishing/using an object without potentially moving it.After all, we don't support some kind of official competition with strict rules, just like we don't support speedrunning (given that we change movement all the time).
-
This patched version is available in tdm_installer as test-frob-daftmugi.
-
1
-
-
Here is an alternative way to simplify extinguishing candles and shouldering bodies.
Player can double-press / double-click frob button to do a mixed frob + use action.The test build is available in tdm_installer as "test-frob-stgatilov".
Attached the source code patch too: FrobUse_By_DoubleClick.patchThe original TDM controls are left unchanged.
The difference starts only when double-click is registered (which unfortunately can happen accidentally).Also, the double-click action always continues the single-click action.
So when you grab a body/candle, the single-click action happens immediately: there is no need to delay it.The maximum time between double-clicks is controlled by cvar in_doubleClickDelay, default is 200 ms.
In principle, you can set it to zero to return to the old behavior: then double-clicks won't be registered.
Here is how it works internally.
There is an utility class which tracks held buttons (which are called "impulses" --- Doom 3 has too few "buttons").
I have extended it to also register double-click.So whenever player clicks frob and this is registered as double-click, then:
- If there is nothing grabbed, then do ordinary "frob" to grab item (this allows to double-click on already grabbed item).
- If there is nothing grabbed now, then fall back to normal single-click frob (this happens for ungrabable stuff like doors).
- If there is something grabbed, then "use" it (that's the main part: it shoulders/extinguished/eats the thing).
- Unless we have a body shouldered, release currently grabbed item (we want to ungrab extinguished candle).
And there is also a special case:
- If there is something equipped at the moment of double-click, the just "use" it instead of anything else (this allows to unshoulder body by double-click).
-
1
-
The black mess under newspaper is the peter-panning of shadow maps.
The non-aliased adge on top-right is probably due to some screen-space effect. Most of these effects work on non-multisampled framebuffer.
-
- Popular Post
- Popular Post
dev16829-10455 is available.
-
6
-
10 hours ago, Daft Mugi said:
My dev machine is down for repairs at the moment, unfortunately.
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?-
1
-
-
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).
Subtitles - Possibilities Beyond 2.11
in TDM Editors Guild
Posted
Oh sorry!
When I started, I tried to find the prototype, but did not find it.
So you suggest to reduce the width of subtitles?
How can you even do it globally? Where would you place all the text?
Having different width depending on verbosity... that's something to think about.
I bet most people would actually care about story subtitles anyway, both players and mappers.
Maybe it would be OK to have smaller size for speech only.