[ 2.10 ] New Frob Shader

[geegee]

1 hour ago, MirceaKitsune said:

Idea: If we do add a menu option for this, we could give it three values; Off, on, on with occlusion.

The only factor the casual player will consider is aesthetics - which leaves it up to the more conscientious mapper to account for every choice.  A mapper can't just assume the player will choose the option the player prefers for playtesting areas.

Here I've put a backgammon set on top of a hidden note, and under the desk is a switch.  The player is approaching from the back, scanning back and forth, up and down.  Some secret.  So how does the mapper account for that?  

[geegee]

Here's the same desk, the player approaching from the front.

[geegee]

Having spotted the switch right through the backgammon board and desktop while standing upright from the front, the player might crouch to look.

[OrbWeaver]

It seems like the highlight has exposed a serious bug in the line-of-sight check. That switch should not be frobbable at all through the top or rear surfaces of the desk. But perhaps the line-of-sight check doesn't (or can't) calculate occlusion by model surfaces?

[nbohr1more]

Right, depth is disabled unless you set:

"r_frobIgnoreDepth 0"

as stated multiple times in this and the other thread

[Dragofer]

It may be too late to change how frob detection works, since it's entirely possible that there are missions with frobable items arranged in such a way that they can no longer be frobbed if a clear line of sight is needed.

A frob outline with depth detection wouldn't break anything except possibly performance. Maybe this could be remedied by introducing overall graphics settings - Low, Medium, High, Ultra High - in which the frob outline is disabled on lower settings.

[geegee]

10 minutes ago, nbohr1more said:

Right, depth is disabled unless you set:

"r_frobIgnoreDepth 0"

as stated multiple times in this and the other thread

I assume that in my posts.  I'm addressing the issue of fps "costs" and etc. for hardcoding this vs MirceaKitsune's notion of making this a player menu choice vs. the impact not having it set has on gameplay and the impact on designing a good FM.   

What are the drawbacks to hardcoding this and also applying some auto-version of the old style frob effect, to cover those cases where the outline is obscured by frames or etc? 

[MirceaKitsune]

41 minutes ago, Dragofer said:

It may be too late to change how frob detection works, since it's entirely possible that there are missions with frobable items arranged in such a way that they can no longer be frobbed if a clear line of sight is needed.

A frob outline with depth detection wouldn't break anything except possibly performance. Maybe this could be remedied by introducing overall graphics settings - Low, Medium, High, Ultra High - in which the frob outline is disabled on lower settings.

Yeah what's done is done, changing existing functionality would be very risky to break FM's. For the future though, we could maybe add a boolean spawnarg for entities to require line-of-sight check for frobbing. Most shouldn't need it anyway, and this may cause extra checks that can be hard on the CPU: Probably useful for well hidden secrets primarily.

[geegee]

9 hours ago, Dragofer said:

A frob outline with depth detection wouldn't break anything except possibly performance. Maybe this could be remedied by introducing overall graphics settings - Low, Medium, High, Ultra High - in which the frob outline is disabled on lower settings.

I just went through my map with "r_frobIgnoreDepth 0" and found no problems anywhere.  Although the outline is occluded by deepset doors etc., in no cases was it totally occluded and in those cases where it was occluded most the old frob highlight was still there, making the frobable at least as clear as it is in v209a. 

I got the impression that if the old highlight is kept, alone without an outline, the highlight code will be hardcoded so can be removed from material.mtr entries and this will speed up load times which is wanted by everyone.   

I also got the impression that if a frobable has to be frobed through a box or etc., even with total occlusion the frobable can still be frobed just as accords with the mapper's original intent and how it has gone before.  The highlight and/or outline just can't be seen, which is also what's wanted.  

So Dragofer outlines a plan that doesn't break anything and seems best for all purposes, it seems to me.

[STiFU]

14 hours ago, OrbWeaver said:

It seems like the highlight has exposed a serious bug in the line-of-sight check. That switch should not be frobbable at all through the top or rear surfaces of the desk. But perhaps the line-of-sight check doesn't (or can't) calculate occlusion by model surfaces?

If I remember correctly, there is a proper line of sight check in the frob detection. Could there maybe something be wrong with that model? Very suprising finding indeed.

[STiFU]

14 hours ago, Dragofer said:

It may be too late to change how frob detection works, since it's entirely possible that there are missions with frobable items arranged in such a way that they can no longer be frobbed if a clear line of sight is needed.

A frob outline with depth detection wouldn't break anything except possibly performance. Maybe this could be remedied by introducing overall graphics settings - Low, Medium, High, Ultra High - in which the frob outline is disabled on lower settings.

I'd rather not hide stuff like that behind general settings, as players would have no clue what this setting actually does. I am also not opposed to just offering configuration of the frob highlight via the menu. After all, one of our aims was to increase accessibility.

[Oktokolo]

17 hours ago, OrbWeaver said:

It seems like the highlight has exposed a serious bug in the line-of-sight check. That switch should not be frobbable at all through the top or rear surfaces of the desk. But perhaps the line-of-sight check doesn't (or can't) calculate occlusion by model surfaces?

It doesn't look like a bug to me. There are countless coins and stacks of coins in missions, that are literally impossible to get a line of sight to. But you can still get them by "fumbling around" in the dark.
I believe, that mappers made them well-hidden by intent in the majority of cases.

It only becomes a problem when you add a bright depth-ignoring in-your-face glow to the regular (in this case invisible) frob highlighting.
To mitigate the new frob highlight, someone would have to go through all the maps and look at all the frobable things. Sometimes adding frob-clip would be enough - sometimes a possible not-too-obvious line of sight has to be created too. The famous coin stacks in a cash box might be okay as they are though...

[OrbWeaver]

38 minutes ago, Abusimplea said:

It doesn't look like a bug to me. There are countless coins and stacks of coins in missions, that are literally impossible to get a line of sight to. But you can still get them by "fumbling around" in the dark.

Do you mean that there are loot objects which are designed to be frobbable despite never being visible, so the player just has to keep right-clicking in the hope of picking them up?

That still seems like a bug to me. As far as I know, being able to frob "through" solid objects was never an intended part of the design, and would not be good design in any case — it just encourages players to keep spamming right-clicks everywhere in the hope of finding something interesting.

For all we know there could be dozens of broken missions out there right now, in which players can get through locked gates by frobbing switches through solid walls (unless the line of sight check is working differently for brushes vs models).

[Dragofer]

@OrbWeaver
A lot of chests contain objects that can only be frobbed from certain angles/distances, especially if the chest body is frobable and it's not possible to climb on top. You know the items are in there, but you can't see them at the time of frobbing. Chests are one of the clunkier aspects of gameplay.

[greebo]

If I recall correctly, the code is not just relying on a single trace, but performs a small bounds expansion at the point of impact to find things that have been closely missed by the trace, which could be the reason behind things lighting up near or behind the trace end point. I might be remembering wrongly though since I haven't looked at that code for a very long time.

[Springheel]

1 hour ago, greebo said:

If I recall correctly, the code is not just relying on a single trace, but performs a small bounds expansion at the point of impact to find things that have been closely missed by the trace, which could be the reason behind things lighting up near or behind the trace end point. I might be remembering wrongly though since I haven't looked at that code for a very long time.

That was certainly the case at one point, in order to allow frobbing of things on top of ledges or objects that would otherwise be difficult to target.

[OrbWeaver]

5 hours ago, Dragofer said:

Chests are one of the clunkier aspects of gameplay.

I agree entirely. I'm never sure whether I'm supposed to stand, crouch or lean, in order to get a decent vantage point and frob ability.

I think chests are another aspect (like blackjacking) which could do with a bit less physics and a bit more game design. E.g. making it so you automatically pick up loot within a chest when you open it (like the original games did), rather than needing to move around and frob each individual loot item.

4 hours ago, greebo said:

If I recall correctly, the code is not just relying on a single trace, but performs a small bounds expansion at the point of impact to find things that have been closely missed by the trace, which could be the reason behind things lighting up near or behind the trace end point. I might be remembering wrongly though since I haven't looked at that code for a very long time.

That fits my recollection too. I think it was @Ishtvan who implemented it years ago, and I remember him talking about making a virtual box at the end of the line-of-sight ray, and using this box to discover any nearby frobbable objects. This certainly makes it easier to frob items without requiring a precise sniper-level mouse alignment, but does seem to introduce the possibility of frobbing items through a solid surface.

To be honest I have no idea how you'd even fix this. Presumably the problem occurs when the virtual box expands through a thin surface and captures a frobbable object on the other side, but you'd need a lot of additional line checks to make sure that some part of the object was actually visible to the player, which would complicate the code and probably impose a performance cost.

[greebo]

36 minutes ago, OrbWeaver said:

To be honest I have no idea how you'd even fix this. Presumably the problem occurs when the virtual box expands through a thin surface and captures a frobbable object on the other side, but you'd need a lot of additional line checks to make sure that some part of the object was actually visible to the player, which would complicate the code and probably impose a performance cost.

This problematic situation was there right from the start, I think Fidcal solved in Thief's Den by adding trickery to the chest lid, like triggering the contents to make them frobable as soon as the chest is opened. Something similar could be applied to the situation of the secret lever that is frob-highlighted unintentionally: The thing that is obscuring the lever might need to be moved away first to reveal the lever and make it frobable at the same time.

[STiFU]

1 hour ago, OrbWeaver said:

I agree entirely. I'm never sure whether I'm supposed to stand, crouch or lean, in order to get a decent vantage point and frob ability.

I usually lean into the chest. However, there is one issue with that: The lantern does not move with the player while leaning. So if you need the lantern to see the contents of the chest, you have to crouch-mantle on it, to get a decent light exposure.

[wesp5]

1 hour ago, OrbWeaver said:

I think chests are another aspect (like blackjacking) which could do with a bit less physics and a bit more game design. E.g. making it so you automatically pick up loot within a chest when you open it (like the original games did), rather than needing to move around and frob each individual loot item.

I think Dragofer already improved this a lot in his own missions by first making only the bottom of chests frobable to lockpick them and then turning the bottom to be unfrobable and turning the lid frobable to be opened. Thus items inside are not competing with the bottom anymore. This should go into the core game!

Edited August 17, 2021 by wesp5

[Springheel]

5 minutes ago, wesp5 said:

I think Dragofer already improved this a lot in his own missions by first making only the bottom of chests frobable to lockpick them and then turning the bottom to be unfrobable and turning the lid frobable to be opened. Thus items inside are not competing with the bottom anymore. This should go into the core game!

 

I'm pretty sure I went through the chest prefabs and changed them so only the lids are frobbable some years ago.  The lid is the thing that is moving, after all...there's no reason for the entire chest to highlight and it's much easier to grab things when it is not competing for the frob trace.

Having everything be picked up immediately on opening a chest wouldn't work for us, even if it was desirable, since chests often have multiple movable junk objects in them, and the player can only pick up one at a time.

 

[wesp5]

2 hours ago, Springheel said:

I'm pretty sure I went through the chest prefabs and changed them so only the lids are frobbable some years ago.

I think Dragofer had a solution in which this is done using core game scripts which would work on all older missions too. I agree that taking everything is not a good idea...

Edited August 17, 2021 by wesp5

[Oktokolo]

21 hours ago, OrbWeaver said:

Do you mean that there are loot objects which are designed to be frobbable despite never being visible, so the player just has to keep right-clicking in the hope of picking them up?

That still seems like a bug to me. As far as I know, being able to frob "through" solid objects was never an intended part of the design, and would not be good design in any case — it just encourages players to keep spamming right-clicks everywhere in the hope of finding something interesting.

For all we know there could be dozens of broken missions out there right now, in which players can get through locked gates by frobbing switches through solid walls (unless the line of sight check is working differently for brushes vs models).

Whether it was intended that way or not - the mechanic is actively used to "hide" loot in lots of missions. Authors deliberately hid bonus loot in a way that you can't get a line of sight (without noclip) but are still able to grab it if you frob it blindly.

Might formally be bad game design or not. It seems to be one of the current ways, authors use to make completionists' lives harder and the 100% loot score more rewarding.
I am no completionist, but still feel a light rush of achievement when i blindly frob into a classic loot place despite seeing anything - and there actually is something (even if it is just a single coin).

 

Apart from that there are the countless switches and hidden levers authors hid in plain sight - which now are jumping right in your face instead of just being subtly highlighted.

Also, being able to frob switches through a desktop and the likes never was a problem, as nobody runs around frobbing everything like a maniac (authors also tend to place noisy clutter to prevent that). But now, you can clearly see the button like if TDM has gone mainstream AAA (still missing the minimap though)...

 

[wesp5]

18 minutes ago, Abusimplea said:

Whether it was intended that way or not - the mechanic is actively used to "hide" loot in lots of missions. Authors deliberately hid bonus loot in a way that you can't get a line of sight (without noclip) but are still able to grab it if you frob it blindly.

Another argument to replace the frob helper with the frob outline option as the former never made much sense to me.

Edited August 18, 2021 by wesp5

[Araneidae]

How much difference would it make to this conversation if

seta r_frobIgnoreDepth "0"

was made the default for future releases?  I have added that into my autoexec.cfg for now, and the frob highlight hasn't given me any issues yet.