[2.14 beta] Frob Changes / Additions

[STiFU]

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

[Baal]

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.

[STiFU]

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.

[Baal]

It was TDM inverted. But it works as intended after a load. I don't know what I did before it occured, so I can't reproduce it. 

[Taffingtaffer]

I did some testing in the Training Mission. Overall, the tdm_frob_control_style modes feel great, but there are a few rough edges in my view:

• Frob focus isolation is really well done. You won't accidentally grab an object while bulk-looting in TDM-inverted mode, eating an edible with long-frob keeps the focus on the object (now in your stomach!) until you let go of the input, and long-frobbing a door will also keep the focus on that specific door.>
  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.
   
• 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'm suspecting this might intended, but big edibles take a bit longer to eat than small ones (bread, cheese or fish take like a full second versus apples, which are instantaneous).

As for tdm_door_control, I agree that 3 is the most useful and clean of the bunch paired with the force-close mechanic. Mode 1 is quite cool, but the sound spam and rendering glitches need to be addressed.
Mode 2 is practically useless, but it instantly made me think of snatcher's fast-opening mechanic in his TDM Modpack. Wouldn't it make sense to include a force-open mechanic if there's a force-close one now? :)

 

[STiFU]

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.

[Taffingtaffer]

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 any other door that can be opened or you won't be able to use and sheathe your current weapon, or change to another one.
It also happens if you don't have a selected weapon, or any weapon in your inventory.

46 minutes ago, STiFU said:

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?
 

It isn't a big deal, I find the second point way more jarring:

46 minutes ago, STiFU said:

I don't understand what you are suggesting here. Could you elaborate? 

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.

Edited February 2 by Taffingtaffer

[STiFU]

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.

 

[snatcher]

I am thrilled by everything you are doing lately and how you are managing it @STiFU. Thank you.

Why would tdm_holdfrob_delay be 200ms by default? I mean, why rushing it? In my experience hold actions take between 0.5 and 1 second in moderns games. Hold is a separated control and developers must make sure players never do anything unintentionally. Whenever an action fails, the error must always be attributed to the player and not to the design of the mechanic, hence a "long-enough" hold time. 

300ms was the default in 2.13 and 200ms is the default now in 2.14b2 but why? I didn't understand it until I started manipulating doors and noticed doors sometimes open but don't move. It seems I sometimes unintentionally hold-frob longer than I should. I tried setting tdm_holdfrob_delay to 500ms and while everything else worked well that way the frob door feature didn't feel good anymore.

You wanted "one solution to rule them all" (refactoring) but sometimes different mechanics require separate solutions. By decreasing hold delay you may make doors work the way you intend but you are at the same time increasing the chances of failure in other areas: shoulder a body when the player actually wants to pick a key, risk extinguishing a candle when carrying it around, etc.

I think tdm_holdfrob_delay should be at least 0.5 seconds. I think the new frob door mechanic is not ready for general use.

Edited February 3 by snatcher

[snatcher]

Regarding the "TDM" frob control style I would expect unshouldering a body would require the same control/effort than shouldering it (hold frob). This is something I highlighted in the old topic: 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. Total failure. This can be avoided by consistently having hold-frob for both shoulder and unshoulder actions.

[STiFU]

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.

[snatcher]

10 minutes ago, STiFU said:

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. [...]

Sorry but I can't figure out examples for this scenario for Disabled, TDM or Thief styles so I assume you are referring to TDM-inverted which would mean the introduction of the experimental TDM-inverted style forced you to change primary styles.

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. I would actually extend the thought to the Disabled style.

41 minutes ago, STiFU said:

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.

tdm_door_control 3. The door opens slightly, as you say. And I have to close it to open it again.

When I comment about these things it is not about me, I can setup TDM to my liking. I am sharing feedback about things few, many, most players might experience at some point.

[snatcher]

1 hour ago, STiFU said:

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.

I have frob set to F from day one. And R to reload use.

[STiFU]

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.

[snatcher]

I will keep trying all different modes and provide feedback if I find anything worth sharing.

[STiFU]

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.

[snatcher]

1) Locked door with handle. Unpickable.

Example: Tears of ST. Lucia setviewpos -80 460 140.

No lockpick selected:

• 2.13: Door handle reacts and makes a noise.
• 2.14b3: Door handle reacts and makes a noise.

Any lockpick selected:

• 2.13: Lockpick makes a noise.
• 2.14b3: Lockpick makes a noise. Door handle reacts and makes a noise.

Considering players will frob the door three times (initial frob, first lockpick and second lockpick) there is to much feedback and noise going on in 2.14b3. It is more elegant (and immersive) in 2.13 in my opinion.

2) Locked door with handle. At least two tumblers. Pickable.

Example: Tears of ST. Lucia setviewpos -7 835 10. Turn around.

Many wrong things happening in 2.14b3. If you manage to go pass the first tumbler but frob again the door handle reacts, makes a noise and resets (visually). This also happens if you switch to the wrong lockpick at any moment during picking.

In 2.14b3 the experience can feel loud and clumsy. Amateurish. This made me appreciate how well the experience is executed in 2.13  in comparison. Thiefy.

Edited February 14 by snatcher

[STiFU]

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.

[snatcher]

It is fixed, yes. Thank you.

I use default settings.

Hold-Frob Mechanic for Doors.

Considering there already is the "attack to force close a door" shouldn't doors open upon regular frob? I explain. You open the door a little, you open the door a little more, and a little more, shouldn't the next regular frob open the door instead of close it?

Edited February 16 by snatcher

[STiFU]

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.

[snatcher]

12 minutes ago, STiFU said:

I do understand where you are coming from, however.

Good.

I no longer can manipulate doors, levers, switches... while shouldering bodies (2.14b4).

Edited February 16 by snatcher

[STiFU]

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

[snatcher]

22 hours ago, STiFU said:

[...] another beta round!

As many as needed! Thanks for the fix.

Did you assess the "unshouldering bodies on hold-frob" in TDM style"? Does it look like a complex implementation?

[Taffingtaffer]

There's an edge case with the auto-search feature. It triggers on dragging bodies, when it should only work on shouldering. (Also, did it always work in two steps? It doesn't shoulder the body and pick up the loot at the same time; it first picks up the loot and then forces you to make another input to actually shoulder the body.)

There are also issues with long-frob and switches. In Displacement, regardless of the frob control scheme, the radio in the first room and the oil lamp in the bathroom make noise on long-frob but don't turn off/on. When you let go of long-frob, they turn off/on without making the *click*.
This isn't the case with the light switch of the lamp in the wall near the radio; it turns on/off on short-frob and after letting long-frob go, and the *click* plays when the action actually triggers.

That's what I meant when I said this:

On 2/2/2026 at 7:13 PM, 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.

ie. Regardless of the scheme, a rock can be grabbed on short-frob, dropped likewise; dropped when you long-frob and let go after you short-frobbed it; and grabbed as long as you long-frob it, then drop it when you let go.

Fixed objects such as switches would act as the wall lamp in Displacement.

 

[irisx]

Copying over from the Imperial Sword thread: playing that mission in 2.14b6 revealed some suboptimal interactions with the new frob behaviour. With frob/interact set to Thief:

1. There were instances when doors/cases would not open and switches would not activate with something that "intuitively" felt like a short frob. This could just mean that the long-frob activation interval is far too short for me, and I would expect for others too. However, the behaviour seems to be more generally inconsistent, e.g. long-frob doesn't seem to do anything on switches *and* fully open doors. Having long-frob activate so easily and then lead to a non-operation seems troublesome for me.

2. I can confirm that in two instances (a loot item and a key) I needed to frob twice with the corresponding sound playing also twice, before getting the thing. In once instance I *think* the animation/"visual zoom" effect also played twice, but since it is difficult to replicate, I am not able to confirm it.

Edited February 28 by irisx