STiFU
-
Posts
4601 -
Joined
-
Last visited
-
Days Won
70
Posts posted by STiFU
-
-
7 hours ago, snatcher said:
@STiFU wait, that's most likely a completely different situation. Let's see your fix in action first.
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.
-
-
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.-
2
-
1
-
-
1 hour ago, snatcher said:
The King of Diamonds: Drop the starting note and pick it up. The compass remains in the background.
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.
-
1
-
-
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.
-
4 hours ago, Arcturus said:
You can run around with bow out, so it seems logical to me to draw arrow right before shooting.
To me this is a bigger issue: https://bugs.thedarkmod.com/view.php?id=6566
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.
-
On 2/11/2026 at 11:04 PM, chumbucket91 said:
You're an absolute madman for playing this game with the lightgem, compass, and crouch intent indicator turned off, but I like the hud fadeouts for item/arrow counts.
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.
-
9 hours ago, Bikerdude said:
Back in 2024, I spent a lot of time updating & tweaking almost every aspect of each of the 3 missions. There is a visual and perf upgrade across the board. @STiFUthose rays in the forest are from memory, decal patches and were in place from the original version of the campaign.
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."
-
1
-
-
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!!
-
1
-
1
-
-
-
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):
Spoiler-
WeaponInventory
- DynHUD_WeaponRule1: Never show for weapons without ammo (cvar)
- DynHUD_WeaponRule2: Briefly show when selecting a weapon not qualifying for rule 1
- DynHUD_WeaponRule3: Briefly show when hidden and next/prev weapon is pressed and a weapon is selected that does not qualify for rule 1. Skip actually switching weapons. (cvar)
- DynHUD_WeaponRule4: Briefly show when ammo changes and respective weapon is selected (cvar)
- DynHUD_WeaponRule5: Show while a temporal weapon effect is active (e.g. holy water) -> Ensured on assets side
-
ItemInventory
- DynHUD_ItemRule1: Briefly show when selecting an item (compass will not fade out because Inventory_HUD_Opacity was simply not defined there)
- DynHUD_ItemRule2: Briefly show when hidden and next/prev inv item or next/prev inv group is pressed. Skip actually switching items. (cvar)
- DynHUD_ItemRule3: Briefly show when picking up a new item (cvar)
- DynHUD_ItemRule4: Show when item can be used with world entity
- DynHUD_ItemRule5: Briefly show when using an item
-
HealthBar
- DynHUD_HealthRule1: Briefly show after taking damage
- DynHUD_HealthRule2: Show when equipping a weapon intended for combat (special cases: water arrows with holy water flask, rope arrow)
- DynHUD_HealthRule3: Show when breath is running out (cvar)
- DynHUD_HealthRule4: Show when health is below a certain threshold (cvar)
- DynHUD_HealthRule5: Show while healing
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:
Spoilertdm_dynamicHUD If enabled, the HUD-elements will hide
depending on context.
tdm_dynamicHUD_fadein_duration The fade-in duration for the dynamic hud in
ms.
tdm_dynamicHUD_fadeout_delay The fade-out delay for the dynamic hud in
ms.
tdm_dynamicHUD_fadeout_duration The fade-out duration for the dynamic hud in
ms.
tdm_dynamicHUD_healthBar Displaying the healthbar.
0 -- regular static
1 -- dynamic
2 -- Hide always
tdm_dynamicHUD_healthBar_airThreshold If air is below this threshold, the health
bar will not fade out anymore. Air is in
tics, see pm_airTics.
tdm_dynamicHUD_healthBar_healthThreshold If health is below this threshold, the
health bar will not fade out anymore.
tdm_dynamicHUD_itemInventory Displaying the item inventory gui
0 -- regular static
1 -- dynamic
2 -- Hide always
tdm_dynamicHUD_itemInventory_nextPrevOverride If enabled and inventory HUD is currently
not shown, the inventory hud will show on
next/prev item/inventory group press instead
of switching item.
tdm_dynamicHUD_itemInventory_showName If disabled, the item name will not be
displayed.
tdm_dynamicHUD_itemInventory_showOnPickup If enabled, the inventory hud will briefly
show after picking up an item.
tdm_dynamicHUD_weaponInventory Displaying the weapon inventory gui.
0 -- regular static
1 -- dynamic
2 -- Hide always
tdm_dynamicHUD_weaponInventory_nextPrevOverride If enabled and weapon HUD is currently not
shown, the weapon hud will show on next/prev
weapon press instead of switching weapon.
tdm_dynamicHUD_weaponInventory_showBowOnly If enabled, the weapon hud will only show
when equipping the bow.
tdm_dynamicHUD_weaponInventory_showName If disabled, the weapon name will not be
displayed.
tdm_dynamicHUD_weaponInventory_showOnAmmoChange If enabled, the weapon hud will show
whenever the ammo of the currently selected
weapon changes.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)
-
3
-
WeaponInventory
-
1 hour ago, wesp5 said:
Will this end up in 2.15 or is this already hidden in 2.14? I will have to update my patch if this looks good ;).
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.
-
23 hours ago, stgatilov said:
This has to be fixed.
You cannot access game state from renderer backend because they are on different threads.
Aside from that, you should not access game state even from render frontend, because it breaks incapsulation. Renderer has its public API though which all the information is passed.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)-
3
-
-
2 hours ago, datiswous said:
I should add that my idea is only relevant for missions having this feature (fm Displacement is an example). I guess you could already script to remove the lightgem in non-hostile environments in such missions. I wonder if only the lightgem gets removed, because I think it also removes the healthbar and breathbar, but I could be wrong.
Healthbar and breath bar are definitely not removed, but the crouch-intent indicator is.
-
2 hours ago, I.C.H.I. said:
In general any changes to HUD behavior should be optional, because I really don't have problem with the current configuration, thus it's totally subjective how HUD should work.
I will answer by quoting myself.
6 hours ago, STiFU said:(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)
2 hours ago, chakkman said:Are there really people who want to hide the lightgem? It is definitely not always obvious if you are fully hidden or not.
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.
3 hours ago, snatcher said:Please fix this existing usability issue first:
When you drop or use an item and this item is the last one in the stack whatever random item that is in the queue gets auto selected.
- Drop a key = here is the compass for you
- Drink a potion = perhaps you need a mine?
- Launch a flashbomb = time to read this note
- ...
Sure, we can fix that as well. Should be really simple.
-
1
-
54 minutes ago, Baal said:
That means: Auto hide items when scrolling, or on pickup. Don't hide when explicitly selected by a key. Is it possible to implement it that way?
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.
34 minutes ago, datiswous said:should show when it can interact with something.
Might be doable by checking the canBeUsedByEntity. I'll add it to the list for consideration.
38 minutes ago, datiswous said:it should generally also show up when there's less than 20% left
Good idea!
38 minutes ago, datiswous said:Idea: Lightgem not showing when not in a hostile enviroment. When you steel something in a non-hostile enviroment
I have added a section on lightgem above. I am not sure it will be worth the effort.
-
1
-
-
1 hour ago, stgatilov said:
This has to be fixed.
You cannot access game state from renderer backend because they are on different threads.
Aside from that, you should not access game state even from render frontend, because it breaks incapsulation. Renderer has its public API though which all the information is passed.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)
-
Added information: None.
-
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.
-
Added information: Arrow type and amount.
-
Blackjack and Sword
-
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?
-
Compass
-
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?
-
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.
- 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?
-
4
-
On 2/5/2026 at 8:37 PM, STRUNK said:
I want to play this mission!!!
But I'm gonna wait until the final release of 2.14 I guess.
I had the google AI read the thread for me and summarise all technical problems to be sure not to encounter any spoilers
, and that seemed to work, so I decided it would be better to wait a bit.
So guys ... hurry up plox!!
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.
-
5 hours ago, Arcturus said:
How about giving a different outline for valuables and non-valuables?
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.
-
1 hour ago, Amadeus said:
That looks pretty sharp! Has this been committed? I'd be down to try it out
I commited it just now for you to try, at revision 11138, no asset changes involved. Separate inventory item frob outline is enabled via r_frobOutlineInv. Then you can configure the separate froboutline via r_fobOutlineColorInv*. Here are my current settings.
r_frobOutlineExtrusion = "-2"
r_frobOutlineColorInvA = "1"
r_frobOutlineColorInvB = "0"
r_frobOutlineColorInvG = ".6"
r_frobOutlineColorInvR = "1"
r_frobOutlineColorA = "1"
r_frobOutlineColorB = ".2"
r_frobOutlineColorG = ".2"
r_frobOutlineColorR = ".2"
r_frobOutlineInv = "1"
r_frobOutline = "2"
-
1
-
1
-
Conformal perspective as an option in TDM?
in The Dark Mod
Posted
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.