STiFU

Wow, it sounded interesting on paper, but these curved "straight" lines of the panini projection make me dizzy. I'll stick with linear perspective and a proper viewing distance.

I just looked in the code: Regardless of whether using an item or dropping to hands, the reduction of the item count is done in the same function that I have fixed for the aforementioned issue. So, this should also fix those "use after use"-bugs.

I already logged it under 6688.

Fixed! :-) Revision: 11188 #6688: FIX Drop item to hands will select next item if stack is empty, which can sometimes cause multiple items to be selected.

Great, I can reliably reproduce this. I don't think this is a 2.14 issue, as the inventory remained untouched in this development cycle I believe. However, I'd still like to have a look. We can probably kill two birds with one stone here: Drop to hands not selecting the next best item should do the trick.

Confirmed. Damn it, I guess we have to do another beta round! Thanks, for the report. Fixed at revision: 11186.

At first I thought, that's a really good idea, but then I thought about what other situations might occur. Imagine you hold-frob opened a door so much that you can squeeze through. You sneak around the room and a guard comes along, so you quickly close the door again. The regular controlscheme for regular frob is: open - stop (if door is moving) - close. I think the hold-frob door control is in line with that. Open and stop are integrated in a single action, and naturally follows close. I do understand where you are coming from, however.

I think those issues are already fixed in b4. At least I cannot reproduce them and there were some further changes to frobActionScript execution. I tried on frobControlStyles Disabled and TDM-inv. Please don't forget to report frobControlStyle along with feedback / bug reports.

That is indeed something that has been bothering for some time, too. However, I don't think there's anything illogical about readying your arrow at the same time as you ready your bow. For one thing, it is extremely common in other video games, too. Two, historically, archers would actually hold multiple arrows in their non-drawing hand together with the bow, so they can draw the next arrow faster. That is in line with the arrow position marked in red above. Three, having arrows on your back is a movie trope. Getting an arrow this way is extremely cumbersome and would take awfully long, so readying the arrow beforehand totally makes sense.

Hehe, you should give it a shot. It creates some extra tension and it actually works very well without seeing it. As for the compass, I do use it and it also does not fade out, if you select it in the inventory.

Sooooooo, since you're listed as one of the authors of this campaign, how about you treat us with a resolution in a forth mission??? Father Lavante abroud sounds like a nice destination to visit, and the boat to go there is already lying in the harbor... "Guards are looking for me everywhere. I need to get out of here quick. My plan is to sneak onto the boat in the harbor, which is set to leave soon. I'll travel as a blind passenger, and as fate has it, that boat is headed to XY, just where good old Father Lavante is supposed to be at the moment. Maybe I'll pay him a nice little visit."

I totally forgot how fun NHAT was and still is. I had only played the original mission-by-mission release back then, so this re-master of sorts is really cool for my playtesting of 2.14 and my dynamic HUD project right now. The campaign format also gives it a really nice flow. I just finished mission two and took a short stroll into the forest afterwards. It seems like that forest has received the most significant overhaul, so far. In mission two, you maybe went a little overboard with those window god rays every where, but hey, it's fine. Still a great campaign!!

Damn, getting some serious Dark Souls vibes from that one...

I was curious to try all this out, so I had a go at it at least on code- and GUI-side. I am quite happy with the result. I have implemented dynamic HUD rules for the WeaponInventory, ItemInventory and HealthBar. Here are the current dynamic HUD rules, which are highly configurable (see cvars below): I found that any dynamic modulations of visibility did not work well for the crouch-intent indicator due to the attached scripts, so I decided to ditch that idea. My reasoning here was that people playing with lightgem probably don't mind the crouch-intent indicator, and people playing without lightgem would not want the crouch-intent indicator displayed on its own anyway. Here are the cvars: And here is a short demonstration video of the result. Of course, without proper explanation of what buttons I press and what I am demonstrating in any given moment, this video might be a bit hard to follow. I guess a better look at this will only be possible in the first dev build after 2.14 release. In the video, at first I demonstrate the dynamic hud of the weapon inventory, then the health bar, then the item inventory and finally, the health bar again due to drowning. Help Needed: Show Arrow Model on Equipped Bow Even though I am fairly happy with the result, I would still prefer if we could have the actual arrow models displayed somehow when equipping the bow (before drawing it). Ideally, the arrow would be attached to the idle position of the bow as if the thief was holding both bow and arrow in the left hand, as marked in red. Another option would be to take one of those first frames of the bow drawing animation that already shows the arrow, but could still be considered for an idle position. Of course, we would have to slow down the remainder of the bow drawing animation then, so that the shots-per-minute of the bow still remains the same. I wonder if there are still any modelers around, who would be interested in undertaking this task. Maybe it could even be solved via scripting only? (Just pinging some people, in case anybody knows someone, who might be able to support. @Arcturus, @kingsal, @Amadeus, @Dragofer)

Right now, the change is only on trunk. @stgatilov is preparing the next beta build at the moment. Since we usually don't allow new developments to go in during beta, I let him decide whether to include it or not.

Fixed at Rev. 11144. @Amadeus, @Wellingtoncrab, just a heads up: I renamed the cvars to something more meaningful: r_frobOutlineValuables, r_frobOutlineValuablesColor*. I have also added two new presets 7 and 8 to r_frobOutlinePreset: 7 - geometric, yellow for valuables, grey for junk (STiFU) 8 - geometric, yellow valuables, none for junk (STiFU)

Healthbar and breath bar are definitely not removed, but the crouch-intent indicator is.

I will answer by quoting myself. I play without lightgem almost exclusively and I know I am not alone in that. My estimate of how hidden I am is maybe not 100% accurate, but sufficiently good and not having the lightgem show actually adds to the tension. But as I said, either you need the lightgem all the time or never at all, so there is no need to make anything dynamic about it. Sure, we can fix that as well. Should be really simple.

Might be possible, I'd have to check, but on the other hand: if you press your key for flashbomb, it should briefly show in the inventory. If it then fades out, it would still be usable and you still know that it is selected, so I think the fade out would be fine. Might be doable by checking the canBeUsedByEntity. I'll add it to the list for consideration. Good idea! I have added a section on lightgem above. I am not sure it will be worth the effort.

Understood, I'll look into fixing that.That's the problem with all those globals and public members, it is easy to do it wrong simply because the code allows you to do it. Proper encapsulation would have prevented that. That being said, it's just a boolean that is accessed and the information is non-critical, so there won't be any actual multithreading issues.

Preface HUD-elements are often a technical necessity, to convey important information to the player that would otherwise not be available to them. A problem with such HUD-elements is that they don't belong to the virtual world. They make it painfully clear to the player that they are just playing a game, thereby reducing immersion. There are many genres, where you need to have such information available at all times, think fast-paced first person shooters, Mobas, or strategy games. However, especially for genres featuring free exploration, that information is simply not needed at all times. Some games (e.g. Dead Space or Metro series) have gone to extreme lengths to completely eliminate HUD elements by integrating all relevant information in the virtual world. While this is of course the most immersive approach, it is also the hardest to implement. A much easier solution is to rely on a dynamic HUD, where certain HUD elements are displayed depending on context. In recent years, I have become hyper focused on immersion. I can't stand a cluttered HUD ("sensory overload") or a map full of quest pointers ("feels like work"). I want to immerse myself in the world, not tick of pointers on a map. About a year ago, having played a ton of WoW in my youth, I played the alliance fraction on WoW Classic for the first time. Via interface addons, I had my UI completely disappear during exploration, but when I entered combat or clicked on an enemy, the UI would become visible. The minimap would generally only become visible during mouse-over. The same goes for non-combat-relevant action-bars. I paired that with a text-to-voice addon for the quest texts and some nice dynamic camera addons that would zoom in on characters when talking to them. Of course I also did not use any quest-GPS addons, so that I actually had to pay attention and search the world for the quests. It was super immersive and a glorious experience reminiscent of the 2004 release. So naturally, having played a lot of TDM recently, I am thinking about how we could improve our dynamic HUD in TDM for immersion-seekers. Current State of Dynamic HUD in TDM The HUD of TDM already has quite some dynamic elements Healthbar only shows if we are not at 100% health Breathbar only shows if we are not at 100% breath Weapon only shows if a weapon is selected and ammo text only shows if ammo is relevant to that weapon Inventory-Icon and -text only shows if an item is selected Pickup- and object-update texts are only displayed momentarily Ideas for More Dynamic HUD Elements in TDM So basically, with every HUD element, we should ask ourselves the following questions: Added information: Does this HUD element actually convey any information? Relevant when: In what situation is that information relevant? Let's start! (Please note that all proposals below shall be made optional under some "tdm_dynamic_hud"-cvar or something like that, so I am not planning to take anything away from anyone) I will update this list of ideas as we go. Weapon HUD Blackjack and Sword Added information: None. The player can see the 3d model of both weapons, so the HUD does not add any information. Relevant when: Never Proposal: Remove completely --> Very easy (already tested) Bow and arrows Added information: Arrow type and amount. Sadly, the 3d model does not show the type of arrow unless the bow is drawn. So, the icon and weapon text add information. Also, there is the ammo display. Relevant when: Player is equipping the bow Proposal: Investigate if we can alter the non-drawn bow model such that it already shows the arrow type. If that works nicely, remove arrowtype and arrow icon from HUD and potentially move the ammo display around and make it bigger. I would need support from a 3d modeler here! Proposal: Consider showing the arrow amount only briefly when the weapon is selected (and/or when the player presses "R"?) (and/or ammo amount changes) and then fade it out again. Healthbar Added information: Health Relevant when: Player is losing health. Player is likely going to loose health, e.g., when in combat or when breath bar is close to zero. Player is preparing to enter combat. Player has very low health Proposal: Briefly show after losing health; Show when equipping a weapon (possibly limit to sword?); show when breath is close to running out; show when health is below some threshold (like 20%) Breathbar: Already very dynamic. No action needed! Inventory HUD (Not the inventory grid) Compass Added information: direction Relevant when: When player equips it. Must not fade-out unless a different item is selected. Other items: Added information: Selected item Relevant when: Only during selection (or when player forgot which item is selected) or when the item can be used with the world Note: I had added the tdm_frob_item_selects_item to prevent items being selected when picking them up, thereby eliminating the respective HUD annoyance. However, I found that frequently, I wanted to use the picked up item right away (a readable, a key, etc.), so this approach is not working well. Proposal: Briefly show after selecting an item, then fade-out. Show item when it can be used on a world entity. For picking up items, consider selecting, but not showing them, so player can use them right away without HUD pop-in. When HUD is not shown, pressing next or prev item should not go to next / prev item, but just show the HUD element. Are there maybe other types of inventory items that need special treatment? Shouldering HUD Added information: Shouldering state Relevant when: Always when shouldering a body Proposal: It would be awesome if we could actually have the 3d model shouldered in view. Then we could get rid of the HUD, but of course, this would be very hard to achieve. Lightgem Added information: To some degree, visibility of player Relevant when: sneaking about or running to hide (so basically always) Discussion: It is actually debatable, how much information is really added, because the player can already tell how well illuminated they are just by looking at the environment. I would say minimalists simply disable the lightgem and all others keep it on all the time. Crouch-intent indicator Added information: Crouch-intent, i.e., while it is impossible to change crouched-state, the crouch-state that will be assumed once crouched-state is unlocked again. Current crouch state can be seen by looking at the 3d world. No indicator needed for that. Relevant when: Only while crouched-state is locked / cannot be changed. Proposal: Only show when crouched-state and crouch-intent differ? Any other UI elements I forgot? Another aspect of dynamic HUDs is HOW visibility is controlled. HUD elements might pop-in instantly or gradually fade in and out, like our FrobHelper. I would say, having HUD elements fade in and out looks generally more appealing, but I would need some advice on how to best control transparency. Should transparency be handled by the GUI scripting or dictated by the engine like in the case of the FrobHelper? What makes most sense here?

I think on 2.14 beta-03, you should be good. We had introduced a major frob handling refactor, new frob control styles and a new long frob door control in beta-02. The latter feature broke a few things, but those are now resolved.

Are you suggesting to have a third color configurable to distinguish regular inventory items from loot? That would be a bit too much, I think. The current implementation also allows the player to distinguish junk from inventory items. That should suffice.

By the way, you can also set it to only show frob outline on inventory items, by setting r_frobOutlineColorA 0.0.