stgatilov

I don't like variable-sized subtitles in general, especially if people can set width at will. If we know speech subtitles are not going to be large, then we can make them always less wide. Although I'm not certain we can know it in advance. Maybe we'd better implement some automatic size adjustment for subtitles in the future? If the subtitle fits one line, then show it on one line. After that, check 3 tiers of width and show the minimum one that is OK. Of course, top-middle point of the subtitle box is always at the same location, even if the box is smaller.

There was an idea to add two features to GUI scripts (6164). The first one is runScript command, which allows GUI script to call a function from game script. Interestingly, this feature is already supported in the GUI engine, but the game code only processes this command when the player clicks left mouse button on the GUI (i.e. usually it works in onAction handler, but not in namedEvent or onTime handlers). Obviously, ID initially did not envision runScript as a global feature which works the same way everywhere, their idea was that it is context-sensitive, and whoever calls the GUI code can then pull the commands generated by the call and do whatever he wants with them. I'm not sure I really want to change this architecture... Anyway: what are the possible use cases for runScript command? The second feature is namedEvent command, which simply generates/calls a named event with specified name on the whole UI, which can be then handled by matching onNamedEvent handlers. However, this command can be implemented in several ways: Whenever namedEvent command is executed, the named event is processed immediately. The rest of the script (after namedEvent command) is continued only after generated named event is fully processed. Whenever namedEvent command is executed, named event is put into some kind of queue, then the current script continues to execute. The generated named event is executed at some moment later, but surely on the current frame. The point 2 can be further differentiated on the exact order when generated named events are processed. So the first approach is how functions normally behave in normal imperative languages, with a real call stack. The second approach is delayed execution, like what we currently do with "resetTime X; -> X::onTime 0 {...}" combo (at least everywhere in the main menu GUI). My worry with the first approach is that it is an major change for GUI engine with no past experience, and it will probably not match well with the long-established GUI wierdness (I mean e.g. the wierdness that all expressions in GUI script are executed before the script commands start executing). And it would work different both from the "resetTime + onTime 0" combo. On the other hand, the callGui in game scripts do execute named event immediately. And I must admit nested GUI calls could be used to reduce the issues from the GUI weirdness mentioned above. Also, this command exists in Quake 4, but I'm not sure how exactly it works. And it's probably good idea to make TDM work the same way.

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.

I tried both configs, no crashes for me.

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?

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

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.

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".

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.

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.

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.patch The 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).

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.

dev16829-10455 is available.

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.