STiFU
-
Posts
4601 -
Joined
-
Last visited
-
Days Won
70
Posts posted by STiFU
-
-
29 minutes ago, chakkman said:
Edit: nevermind, it worked now. It was that (excuse my language) completely shitty blackjacking mechanics again, which prevented me from being able to blackjack the guard.
Actually, after being flashed, the ai should be blackjackable from any direction, just like sleeping AI, so if you aim at the head, you should be good.
I agree that we ought to revise the blackjacking rules. They are awfully complex. The blackjack helper is a way to counter these complex rules: It raises when you aim at a position from an angle that would get the AI KO'd, although sometimes this did not result in a KO for me, too, sooo.
Maybe we can tackle this topic for 2.15. However, don't expect it to become as easy as in the originals, as that was crazy overpowered.
-
1
-
-
Just so everybody knows that this issue is resolved and does not need further investigation/reporting:
There was an issue that items attached the BinaryFrobMovers (like the Pendulum in DISPLACEMENT or drawers) could not be picked up. Instead, they would trigger door handling, at least on long-frob. The problem here is that for attachments like door handles, we need to get the bind-master, i.e., the door, to execute the door handling. For loot on drawers, this leads to the described misbehaviour.
The solution was to move some things around so that inventory items get processed earlier than doors. Fixed at revision 11135.
-
1
-
-
30 minutes ago, snatcher said:
I don't know what your code looks like but from your comments I tend to believe TDM-inverted exists simply because the new code allows for it, not because there is a use case.
It exists because it always bothered me that we have this super cool drag-and-drop for body limbs (in Thief-control-style), but that it is not consistently applied to all entities. Refactoring the frob-handling code was also long overdue, as it accumulated a lot of technical debt over time, with crazy state-leakage and what not. So, I hit two birds with one stone: A clean frobhandling routine and two new frob control styles in TDM and TDM-inverted, the latter being my own personal holy grail and I am certain there will also be other players who like it.
Edit: By the way, in TDM-inverted and Thief control style, unshoulder body is consistent.
-
53 minutes ago, snatcher said:
Why would tdm_holdfrob_delay be 200ms by default? I mean, why rushing it?
The reason why I decreased it is not the door control, but the hold-type grabber. If there is a big delay and the player rotates the view, the object will attach very late. In the long-term, I would like to address this by slowly moving the grabber object to the center of the screen, but for now, that is the situation we are in.
If a door remained closed on pseudo-long-frob, that can only mean that you used tdm_door_control 1, which is experimental and definitely not finished. With both other modes, the door should open at least slightly.
The 1s hold-time you are citing is wildly exaggerated. If at all, you can only be talking about controller inputs, but even there a long-press is usually significantly shorter than 1s. And we are not talking about a controller here, but a mouse. According to this post on stack-overflow, which also cites a paper that I sadly cannot access, the average mouseclick lasts 85 ms with an upper bound of 135 ms. This is well within the default value of 200 ms.
If you actually have problems with the current delay, just increase it. If many players show up with issues in this regard, I will gladly increase the delay back to 300 ms again.
1 hour ago, snatcher said:I think the new frob door mechanic is not ready for general use.
The door mechanic does still have a few quirks. That's what the beta is for. One of them was fixed, see above, another one was found in Welli's and Amadeus' FM and I will fix it tonight.
51 minutes ago, snatcher said:sometimes I am in a rush and I don't aim well at a door (doesn't highlight) and I not only don't open the door but end up with a body on the floor.
To be frank, if you fail to aim at something as huge as a door, the error lies not in the programming.
Just kidding! I just adopted the existing control scheme for unshouldering bodies. You suggestion might be something we could consider for 2.15.
-
11 hours ago, joebarnin said:
I just confirmed, the problem involves the new Hold/Frob Interact option in TDM 2.14. If this is set to anything but "Disabled", and if tdm_door_control is set to 2 or 3 (3 is the default), then when you do a "slow" frob on a locked door, nothing happens. The frob is basically ignored. "Slow" is relative here; my click was pretty fast, just not blazingly fast.
And, if the Paw is in use, that's when you get the weirdness where you can't change weapons. The workaround is to quick-click the door again: this time the frob works, the door opens, and weapons are available.
This should be recreateable: set the settings as I described, then slowly right click on a locked door (click down, wait, release).
I don't know if this is specific to the doors in this mission, or in general.
This is a different issue than what @Wellingtoncrabreferenced. It is already fixed and will hopefully come to next beta, see frob changes beta thread.
-
On 6/10/2025 at 3:54 AM, Wellingtoncrab said:
The "issue" with the animation at least appears to be on the script side, so even those of us who only know enough to be dangerous can still play with it. In "tdm_ai_base.script" there are blocks to specify how animations are handled when an ai is blinded. It only plays the animation once across the torso and legs channels and the ends regardless if the ai is still blind or not.
void ai_darkmod_base::Torso_Blinded() { // play the blinded animation playAnim( ANIMCHANNEL_TORSO, "walk_blind" ); while( !animDone( ANIMCHANNEL_TORSO, 4 ) ) { // waitFrame(); sys.wait(0.0166667); } finishAction( "blinded" ); animState( ANIMCHANNEL_TORSO, "Torso_Idle", 4 ); } void ai_darkmod_base::Legs_Blinded() { // play the blinded animation playAnim( ANIMCHANNEL_LEGS, "walk_blind" ); while( !animDone( ANIMCHANNEL_LEGS, 4 ) ) { // waitFrame(); sys.wait(0.0166667); } finishAction( "blinded" ); animState( ANIMCHANNEL_LEGS, "Legs_Idle", 4 ); }The result is it that rather quickly after the animation is complete, the ai seems to snap to idle and it is imo very hard to tell what state the ai is actually in. You kind of expect them to snap out of it, but they are actually still blind and just standing there:
I am a very bad scripter, but by copy pasting the torso channel animations a few times and adding some pauses in between for the leg channel you already get what is imo a not perfect but a much more legible "I'm blind" response: The ai is covering their eyes the entire time, they switch between stumbling forward and standing in place, they change direction, etc. You can also much more clearly see the difference from the randomization at the end the blind timer:
void ai_darkmod_base::Torso_Blinded() { // play the blinded animation playAnim( ANIMCHANNEL_TORSO, "walk_blind" ); while( !animDone( ANIMCHANNEL_TORSO, 4 ) ) { // waitFrame(); sys.wait(0.0166667); } playAnim( ANIMCHANNEL_TORSO, "walk_blind" ); while( !animDone( ANIMCHANNEL_TORSO, 4 ) ) { // waitFrame(); sys.wait(0.0166667); } playAnim( ANIMCHANNEL_TORSO, "walk_blind" ); while( !animDone( ANIMCHANNEL_TORSO, 4 ) ) { // waitFrame(); sys.wait(0.0166667); } playAnim( ANIMCHANNEL_TORSO, "walk_blind" ); while( !animDone( ANIMCHANNEL_TORSO, 4 ) ) { // waitFrame(); sys.wait(0.0166667); } playAnim( ANIMCHANNEL_TORSO, "walk_blind" ); while( !animDone( ANIMCHANNEL_TORSO, 4 ) ) { // waitFrame(); sys.wait(0.0166667); } finishAction( "blinded" ); animState( ANIMCHANNEL_TORSO, "Torso_Idle", 4 ); } void ai_darkmod_base::Legs_Blinded() { // walk forward play the blinded animation playAnim( ANIMCHANNEL_LEGS, "walk_blind" ); while( !animDone( ANIMCHANNEL_LEGS, 4 ) ) { // waitFrame(); sys.wait(0.0166667); } // wait a cycle before walking again sys.wait(animLength(ANIMCHANNEL_LEGS, "walk_blind") + 0.0166667); // walk forward play the blinded animation playAnim( ANIMCHANNEL_LEGS, "walk_blind" ); while( !animDone( ANIMCHANNEL_LEGS, 4 ) ) { // waitFrame(); sys.wait(0.0166667); } // wait a cycle before walking again sys.wait(animLength(ANIMCHANNEL_LEGS, "walk_blind") + 0.0166667); finishAction( "blinded" ); animState( ANIMCHANNEL_LEGS, "Legs_Idle", 4 ); }Again very bad at scripting. There is probably a much better way to handle this. For example it'd probably be better to pull the blind duration spawnargs from the ai and loop the animations for that length specifically and not repeat so many lines. Maybe introduce some kind of randomization to try and break up the "synchronized swimmer" look.
Found a reference to #3431 in the relevant code section.
QuoteSince the blind state lasts 4s more than the blind anim, added code to make the AI stare down for the remainder of the state after the anim finishes, as if he’s waiting to regain his sight. Looks better than staring straight ahead like a dummy.
So, it seems that - at least to some degree - there was some intention behind the current behavior. Sadly, no further details on why the animation was not extended. Did that simply not occur to grayman?
-
1
-
1
-
-
45 minutes ago, Wellingtoncrab said:
@STiFUyeah I understand that as well. Perhaps given we have already done so many questionable menu overrides it is feasible to stick a “loot spent” statistic somewhere in the end game screen.
Maybe that should become a core-feature. If what you're saying is accurate, that shopping generally affects the loot totals, it should probably always be on the stats page.
-
2
-
-
30 minutes ago, wesp5 said:
Isn't 1.5 seconds really short? How long is the AI internally blinded, even if the animation isn't correct?
It is spawnarg "blind_time" (default=8s) ± a random value on the range of spawnarg "blind_time_fuzziness" (default=4s), but mate, how about you just playtest this rather than theorizing about it?
The whole point of this thread is to find a decent value for the duration based on player experience:
On 2/1/2026 at 8:12 PM, STiFU said:That duration is subject to balancing, which is one of the goals of this thread. The reasoning here is that we did want to make the flashbomb and flashmine a little more useful, but not overpowered in the way that you could clear out entire rooms with a single one.
-
1
-
-
Ok, got it. I guess we should evaluate how many missions there are that use a mission.cfg and whether they set any archived cvars. We would need to patch those missions then, but what should the engine do, when it encounters a mission.cfg because somebody has an old mission lying around? Would that FM be kind of broken then, according to the author's intent?
-
1 minute ago, Wellingtoncrab said:
@STiFU @joebarnin we just aren’t that sure about changing that. You currently make a choice between spending your money or keeping it and it seems more natural to me that that impacts how much loot you “finish” with vs it not.
Thats how my prior implementation of in game stores has worked anyway.
I get it, but still, would be nice for the player to see what percentage of loot they found.
@joebarnin, if you are curious, use the command tdm_show_loot at the end to check what loot is still missing. Maybe look on the ground before executing the command so you don't spoil hiding places to yourself. -
14 hours ago, sullium said:
Hi, I was playing my map and found that I could mantle straight through a gate onto some nearby stairs, as long as I was aiming through a gap in the gate's bars.
Through testing I've found that I can mantle through incredibly small gaps, like this 2x2 unit hole in a 3-unit-thick wall of solid worldspawn (see video):
Thicker walls seem to reduce the problem but not remove it: This 22-unit gap in an 8-unit-thick wall is too thin to walk through, but a well-aimed mantle gets me past it (see video):
I should note that the positioning is a bit particular, moving the hole or the target platform by a few units can make it harder or impossible to pass through by mantling.
In both cases above, I can simply stand still and tap the mantle key or hold the jump key to climb through. Moving or leaning in certain ways could help to perform the exploit in practice, but the core issue seems to be a bug/oversight in mantling in general.
I tested this in TDM 2.13 on two different Windows 11 PCs.
If you're curious, both of the simple test maps seen above are attached to this post. The player is already in position on map start, just tap mantle or hold jump. (The second map is a bit precise, if you have trouble try binding a keyboard key to Attack so you can start the map without jostling the mouse. Or just spam mantle, it's not pixel-perfect or anything.)
Haha, that's a nice bug. When checking for mantling options, we are checking the player collision model only at the target location, so that explains this bug. It won't be easy to fix so this will not get into the currently running 2.14 beta anymore. I have added created a bugtracker entry for this. Thanks for the report.
-
3
-
-
1 hour ago, joebarnin said:
Question about loot
On the Mission Statistics page, it appears that "Loot Acquired" lists the amount of loot you currently have, not the amount of loot you acquired over the mission. If you bought items, that reduces the reported total. So even if you steal every piece of loot, if you purchased anything this number won't match the maximum.
It would be nice if this stat actually reflects how much you stole.
Damn, @Amadeus, you didn't end up implementing my suggestion after all?
-
Could we not simply automatically replace any occurence of "set" in mission.cfg with "setm" and we are done?
-
23 minutes ago, Taffingtaffer said:
Uh oh, I just found an edge case of frob focus. Long-frobbing a locked door, or trying to slowly open a door further that's fully opened (assuming tdm_door_control (3) is used) hijacks the current unsheathed weapon (blackjack, sword and bow).
You have to frob the door that you long-frobbed again or you won't be able to use and sheathe your current weapon, or change to another one.Confirmed and fixed, at revision: 11133. Thanks for the report.
17 minutes ago, Taffingtaffer said:Basically assume you want to grab one-action objects with a short-frob in TDM-inverted mode and with a long-frob in TDM and Thief modes.
But that's exactly the point of TDM-inverted-style: You grab nothing with short-frob. Grabbing is only long frob and short-frob is only ever a use-type interaction. In TDM-style, it is the other way around: grabbing is always short-frob and using is always long-frob. On Thief-style, however, we have kind of a weird mixture, with bodies being grabbed on long-frob and all other entities being grabbed on short-frob.
-
1
-
-
Thanks for the detailed feedback, @Taffingtaffer.
1 hour ago, Taffingtaffer said:The nitpick I have with this is that long-frobbing the air keeps the focus on nothing, preventing you from interacting with anything until you reset the state. Changing the focus from nothing to the first thing you highlight would be nice, if it's feasible.
I think that is a good suggestion and that it could be done, but it would again be quite a design change. I am not sure I want to open this can of worms in beta. Does the current behavior seriously impact your gameplay or is this just a nice to have? Maybe this could be postponed to 2.15 or a future dev build? @stgatilov do you concur?
1 hour ago, Taffingtaffer said:Long-frob behaviour on one-action objects (junk items, eaten apples, extinguinshed lights) don't feel good in TDM and Thief modes; the same goes for short-frobbing them in TDM-inverted mode. I think making an exception for "consistency" here would make for smoother gameplay, but again I don't know if it's feasible.
I don't understand what you are suggesting here. Could you elaborate?
1 hour ago, Taffingtaffer said:Wouldn't it make sense to include a force-open mechanic if there's a force-close one now?
Certainly, yes. I've had the idea, too, and I would furthermore like to explore if the force-open and force-close could be used to KO AI.
However, again, 2.14 is pretty much feature-locked. These latest additions were an exception. These suggestions will have to wait for the next dev-build after 2.14 release.
-
2
-
-
21 hours ago, chakkman said:
I'm probably missing something, but, isn't the duration quite a bit longer than 1.5 seconds? I just tried in the training mission, and, it seems like I can knock out the guard as long as he doesn't enter the alert state where he draws his weapon?
As long as the guard was not alerted, he will be blackjackable for the full duration. Being flashed currently does not raise the alert level, as far as I am aware.
21 hours ago, chakkman said:If you alert the guard so that he draws his weaoon and searches, and then drop a flash bomb, the guard will be blinded ("blinded" animation plays shortly), and, when you blackjack him then, the blinded animation will play again shortly.
That is exactly the situation where the change should be active. Flash an alerted guard, and he should be blackjackable for 1,5s afterwards. Was that not the case?
Please note that we are not going to fix all flash bomb issues in 2.14 beta like that lacking looping of the flashed-animation. Let's focus on the change at hand in this thread, please.
-
The animation should be looped until they are not blinded anymore. This is currently not the case apparently (#6636), but since it should ultimately loop, we should not tie this duration to the animation.
-
15 minutes ago, Baal said:
I have a strange issue with beta 2. Whenever I pick up (as in physics grab) an object, the perspective changes a little. The camera seems to shift back a little bit, (or the fov is slightly higher, but I think it's the former). When I put the object down, it reverts back to normal.
The default tdm_door_control (3) is the only method I tried so far, and it works well. I like it.
What's your tdm_frob_control_style? What you describe sounds pretty weird. Maybe related to the immobilization induced by the grabber? Please try different FMs and the Training Mission as well.
-
@stgatilov noted that some of my changes were hidden too well, because they are only introduced as cvars. One of those is tdm_frob_item_selects_item. When you pick up an item, it normally gets automatically selected in your inventory (bottom-right screen corner). With this new cvar switch activated, picked-up items will not be auto-selected anymore. A similar option for weapons already existed. While the latter makes an actual difference in the gameplay (equipping a weapon changes your light gem), the prior is purely cosmetic and intended for those who like to immerse themselves as much as possible by disabling HUD elements. I figured the audience for such a feature is probably rather small, so I left it as a cvar for now.
-
@Everyone, I have created two additional beta threads specifically for gameplay changes / additions, so we can discuss feedback and report issues in a structured manner there.
-
1
-
-
On 1/24/2026 at 11:39 PM, STiFU said:
However, it used to be possible to set the crouch-intent while attached to climbable, i.e., you could tell the game that you want to be crouched or standing up when detaching from the climbable, which is a useful feature. For whatever reason, Daft Mugi disabled this behaviour with his patch for #5973. Probably just an oversight. I think I will look into fixing this for 2.14.
Edit: Done.
This is now included in 2.14 beta. When attached to ladders, you can now toggle the crouch-intent state again. If you attach crouched, you can stand up once, but not get back to crouched state. As I said, that was an intentional design decision from way back, but we might revisit this for 2.15.
-
1
-
-
- Popular Post
- Popular Post
As was suggested in this discussion, non-elite AI can now be KO'd from any direction for a brief duration after being flashed. That duration is subject to balancing, which is one of the goals of this thread. The reasoning here is that we did want to make the flashbomb and flashmine a little more useful, but not overpowered in the way that you could clear out entire rooms with a single one.
The default value for this duration is currently 1500 ms, i.e., 1.5 s. You can change it via the cvar tdm_ai_ko_susceptibility_after_flash_duration in the unit of milliseconds. If you set the duration to "infinity", non-elite AI can be KOed for the full duration of the flash.
Bugtracker: #6636.
2.14 Beta
Please post issues and feedback related to KO after flash here. Please also try out some different values for the duration (tdm_ai_ko_susceptibility_after_flash_duration) and give feedback if the current default is suitable or if and why it should be changed.
Pinging some players that previously showed interest in this feature: @chumbucket91, @chakkman, @Epifire, @nbohr1more, @snatcher
-
6
-
This thread is intended for discussing and reporting things about the new frob changes during beta. Most of the description below was already given in a previous thread. Bugtracker: #6658, #6668.
New Frob Control Styles
I have completely refactored the frob-handling code. Now, it is easy to setup different frob control styles. There are currently 3 (and a half), which you can try in 2.14 beta. Under "Settings > Gameplay > General > Hold Frob/Interact" (cvar tdm_frob_control_style), you can change the frob control style. This setting replaced the previous hold frob delay setting (tdm_holdfrob_delay), because I think that nobody would touch that value unless they want to disable the holdfrob mechanic, which can now be achieved by the new setting as well.
The currently available control styles are:
- Disabled: No hold-frob mechanic, i.e., pre v2.12 control style
- TDM: Short frob is the same as pre v2.12, but long frob is a shortcut for "grab and then use" (use-type interactions)
- Thief (v2.12): Same as TDM, but behaviour for bodies is swapped. Body limbs are interacted with via "drag and drop".
- TDM-inverted: Short frob for use-type interactions, hold frob to "drag and drop" objects (when you release the mouse button, you will release the object)
I always loved the drag and drop interaction with body limbs created by Daft Mugi and I wanted to see it consistently extended to all objects, which motivated the refactor. I am very happy with the result and I hope you players enjoy it as much as I do. The Thief control style will still remain the default settings, however, as I didn't want to open that can of worms.
Hold-Frob Mechanic for Doors
There was previously no hold-frob mechanic for doors, except for experimental manual door control feature. I have added two additional new control modes for hold-frob on doors, which you can activate through the cvar tdm_door_control. The modes are:
- 0: Disabled
- 1: Manual door fine control (experimental, existing feature)
- 2: Hold frob to slowly move doors. They are opened and closed alternatingly, just like regular frobbing a door, but interrupting a moving door is skipped.
- 3: Hold frob to slowly open doors.
Additionally, I added in the ability to quickly force close a door by holding frob and pressing attack.
It felt like mode 3 ("Slow Open") gave the most benefits and most direct controls to the player and pairs well with the force-close mechanic. So, I just set "Slow Open" as the default and I did not add it to the settings menu, but you are of course encouraged to try the other modes as well.
The idea behind this addition is that the player can now slowly sneak and peak through a door, but then can also quickly shut the door again if the player deems the situation unsafe. This adds more skill expression and creates further immersion.
2.14 Beta
Please use this thread to report any issues with frobbing (always state tdm_frob_control_style and tdm_door_control configuration), the new door control modes (please test them rigorously) and to give feedback on any of the above changes.
UPDATE: These changes were removed in beta214-07.
Pinging players that previously showed interest in this: @wesp5, @snatcher, @Baal, @Skaruts, @Wellingtoncrab, @Amadeus-
4
-
Congrats on the release. Incredible achievement!
Enjoy people, this one is a banger!!
-
2
-
[ 2.10 ] New Frob Shader
in The Dark Mod
Posted
Distinguishing loot from junk can sometimes be tricky. I just tried to remedy this situation by allowing a different froboutline color for inventory items. I've set up an extremely subtle grey-blueish outline for junk, but a rather strong yellow outline for inv / loot. I think it works quite well...