Things that could be improved

[Ideal]

4 hours ago, Obsttorte said:

I rarely have any issues with the head turning. Surely it can happen that you get spotted, but shouldn't approaching a heavy armed guy be somewhat risky!? If you encounter this to be troublesome for you, why don't you try another approach first. You have the means to take out the guard in most missions and you are with some exceptions not forced to pickpocket every ai in a mission.

The argument with the training mission is valid, though, and that section probably needs rethinking. On the other hand it already informs new players that they may get spotted by ai even if the consider to be in a relatively save spot. So maybe it isn't such an issue after all.

I don't think there should be any random risk of failure in a tutorial environment, that's where you really want the player to associate failing with making avoidable mistakes. If you as a new player were as unlucky as I was going through that room, you'd assume you'd failed the given task somehow, which is obviously not the intended takeaway if you actually didn't.

 

More broadly, if that added randomized risk is in fact a deliberate deviation from the Thief formula, then that's fair enough. I'm still interested in learning whether it would be possible to change those AI FoV cone dimensions by messing around with variables, and would appreciate help there.

Edited August 31, 2022 by Ideal

[AluminumHaste]

15 hours ago, CrisiusXIII said:

CLEAN THOSE BUFFERS

i think that part off some problems is that old code is still in the buffer.

especialy with (quick) LOAD that is provable. if you save on a real dark spot and walk into the light next to a guard, the guard will see you and probably kill you

if you restart the original DARK spot will have a LIGTH notice in the darkness-button by which that SAME GUARD sees you WHILE NOT in the original saving

this means the guard REACTS ON CODE THAT WAS FROM THE LAST USE BEFORE THE RELOAD

!!!

realy, sorry for the shouting, but this is important.

if i RELOAD TWICE the "late ligth" effect is gone!

but the only way the guard can see me enligthed while i am in the dark

is becouse off OLD CODE IN THE BUFFER!

i am 100% sure about it.

I've already reported this a while ago.

 

EDIT: Apparently I never created a bug tracker for it?
Just recorded a video and posted about it in the beta mappers forum.

 

 

The issue is that when you quickload while in full brightness, you are still lit when the game loads you into darkness.

Easier to see at really low fps, set com_maxfps to 24, and the lightgem stays lit for a longer period of time.

 

EDIT 2: filed bug tracker:

https://bugs.thedarkmod.com/view.php?id=6088

[wesp5]

3 hours ago, Ideal said:

I don't think there should be any random risk of failure in a tutorial environment, that's where you really want the player to associate failing with making avoidable mistakes.

I think an easy solution would be to mention the random head turning in the training mission. After all this is where you are supposed to learn the differences to other games...

[Ideal]

1 hour ago, wesp5 said:

I think an easy solution would be to mention the random head turning in the training mission. After all this is where you are supposed to learn the differences to other games...

Yes, I'd make sure to emphasize both the head turning and the more realistic peripheral vision on NPCs (and would support the latter being made toggable), both are significant departures from other stealth-based games I've played. I still object to that being a factor in that particular room since its defined purpose is not even related to detection by sight, that hurts the modular structure of the tutorial and just confuses things for the people it's designed to help.

Edited August 31, 2022 by Ideal

[snatcher]

8 hours ago, AluminumHaste said:

EDIT 2: filed bug tracker:

https://bugs.thedarkmod.com/view.php?id=6088

Thanks, AluminumHaste. I hope it gets resolved.

[snatcher]

On 8/30/2022 at 10:36 PM, Ideal said:

I see the case for realism, but the existing combination of random head turns and guards' peripheral vision makes it so that the player's success in some cases is dependent on a real element of luck alongside skill, which I think detracts from the experience and can cause confusion regarding what, if anything, the player did wrong.

I personally find random head turns (and everything that comes with it) very well executed and extremely satisfying.

[AluminumHaste]

The only weird thing to head turns is that when you are spotted, the AI starts turning their bodies towards you and the head stops tracking you and ends up looking off into space until at some point it re-acquires you.

[snatcher]

I take you word but I don't recall ever noticing it. Shhh...

[Ideal]

1 hour ago, snatcher said:

I personally find random head turns (and everything that comes with it) very well executed and extremely satisfying.

That's fair, they're additions that have evidently added to a fair number of players' experience and that's certainly a good thing. My only personal gripe is the RNG-based risk factor it brings to the game compared to Thief and other games it's inspired. I actively avoid save scumming so I don't like dealing with risk I cannot mitigate through skill, even if it's an objectively low chance that a lantern-carrying guard will randomly look down and catch me crouching right behind him for a second trying to nab his key for a door I can't pick the lock on.

I'll keep trying to fiddle with variables to the best of my ability and see if I can find a solution that suits me. I've tried accessing the documentation linked on the wiki (http://bloodgate.com/mirrors/tdm/pub/doc/index.html) but the link seems to be broken.

Edited August 31, 2022 by Ideal

[Obsttorte]

If you are right behind the guard his body should actually block his vision. If that's not the case then I would consider it a bug. But you really would have to stand behind him, not somewhere to the left or right of his back. If I find the time this weekend I'll take a look.

Regarding rng: If the player is aware of the head turning, then all it does is to increase the ai's fov, with the difference that there is an area in front of the ai where you are always visible and the area to the sides where you are only occasionally visible. And as the ai doesn't tend to turn their head like a lighthouse tower there should be an area in their back where you cannot be seen.

From my experience this is the case, but as stated above, there might be occassions where something goes wrong. However, I wouldn't consider such a setup random. If you stand at the ai's side you know you will get spotted. The only thing you don't know exactly is how long it takes.

[wesp5]

I replayed the Stealth section of the Training Mission and I see only one place where info about the head turning could be added without breaking the message formatting which is in the second book. This is what I did and I updated the patch...

Edited September 1, 2022 by wesp5

[Ideal]

6 hours ago, Obsttorte said:

Regarding rng: If the player is aware of the head turning, then all it does is to increase the ai's fov, with the difference that there is an area in front of the ai where you are always visible and the area to the sides where you are only occasionally visible. And as the ai doesn't tend to turn their head like a lighthouse tower there should be an area in their back where you cannot be seen.

That was my original assumption and I was satisfied with that, but turns out there is quite a range of head movements that can result in the player getting spotted even if they're standing directly behind the AI.
 

 

[Springheel]

The turning in those videos is not caused by random head-turning...those are idle animations, which is a slightly different issue. 

One possible approach is to see if AI vision can be affected by frame commands in animations.

 

[STiFU]

3 hours ago, Ideal said:

That was my original assumption and I was satisfied with that, but turns out there is quite a range of head movements that can result in the player getting spotted even if they're standing directly behind the AI.
 

 

Hm, that DOES look a bit extreme. Are we sure we don't have to do anything about that @Springheel, @stgatilov?

[Obsttorte]

@IdealWell, that's definetely an issue. I never noticed this as in a case as demonstrated by you in that videos I wouldn't have gave the ai enough time to react like that. His back is just soooo inviting for a knockout

3 hours ago, Springheel said:

One possible approach is to see if AI vision can be affected by frame commands in animations.

Frame commands can be used to execute routines in the source code, as done by the blackjack attack animation for example. The question is whether there is an already existing set of code we can utilize or whether something new has to be implemented (and if so, what, of course).

What I wonder is whether it is really necessary to have such a wide vertical view angle. It seems to me that this is partly a reason for the ai reaction, as he leans forward. Another thing to investigate is whether the ai's body is taken into consideration when checking the visibility of the player. I am not sure whether this is the case here.

[Ideal]

On 9/1/2022 at 4:01 PM, Springheel said:

The turning in those videos is not caused by random head-turning...those are idle animations, which is a slightly different issue. 

One possible approach is to see if AI vision can be affected by frame commands in animations.

 

For what it's worth, in my testing actual head turns did occasionally get me seen where I'm standing in the videos as well, though they rarely seem to cause anything but low-level alert comments at that distance and light level.

[Xolvix]

I reckon the AI should be tweaked so that if it decides to perform a head turn, for perhaps a 1% chance each time a turn is going to happen, it turns the head a full 360 degrees. Just to confuse the player.

Edited September 2, 2022 by Xolvix

[thebigh]

If they start projectile-vomiting green pea soup I'm outta here.

[Obsttorte]

I've just taken a look at the code and it is indeed the case that the ai is excluded during the visibility check, meaning that the ai's body does not occlude view. This is most likely to avoid parts of the ai model to interfer with the trace. The same is done with weapons collision testing for example to avoid weapons to collide with themself.

I will see what happens if I disable this and if it causes issues (what is to be expected) will try to implement a workaround.

[Obsttorte]

Investigating further on that issue turned out that the self-occlusion (or its absence) isn't the issue here. The actual problem comes from the animation. The ai is leaning forward while at the same time slightly moving its torso to one side. If you replicate this irl you will notice that you are indeed able to see behind you in that case.

I see two possible solutions:

1. Avoid any animations like that as idle animations
2. Introduce an additional check to explicitely exclude the possibility of the ai to see anything behind itself (behind in respective to its bodies orientation).

I favor the second one as it means less work for anyone working with animations. I mean, nobody expect that to happen anyway.

 

[Obsttorte]

So, blocking the ai's vision backwards does do the trick. The question is what we should define as behind. We can either use a constant angle, which makes the implementation simple (like in finished ) or we could make it depending on the ai's vision, which would need a bit more love.

Some ai' have there horizontal vision modified, either because they wear a helmet or a cape or because they have an eyepatch. It may not be necessary to take these things into account as the play may not end up within the viewcones of those special cases anyways. Thoughts?

[Ideal]

Implementing a constant "blindness cone" extending from their backs does sound to me like the safest way to ensure that "never visible" space from your illustration, I'd be all for that.

[Springheel]

2 hours ago, Obsttorte said:

Some ai' have there horizontal vision modified, either because they wear a helmet or a cape or because they have an eyepatch. It may not be necessary to take these things into account as the play may not end up within the viewcones of those special cases anyways. Thoughts?

What method do you plan to use to block their vision?  Humanoid AI with special cone values always see less than the default, not more, so if it's an extra spawnarg, a default block value should work in those cases.  There might be special AI, like spiders or willowisps, that see more than 180 degrees though.

 

[Obsttorte]

1 hour ago, Springheel said:

What method do you plan to use to block their vision?  Humanoid AI with special cone values always see less than the default, not more, so if it's an extra spawnarg, a default block value should work in those cases.  There might be special AI, like spiders or willowisps, that see more than 180 degrees though.

 

My initial idea was that, if I assume that ai can turn their head by 90° in both directions, the area in which the ai can never see is what is left if you extrude the forward pointing viewcone by 90° in both directions and take the complement. The problem is that the default horizontal fov is 150°, so this would lead to a very narrow cone in the back (doubling the angle or similar might work better). (#) Such an approach would cause ai with 180°+ fov to not have a blind spot (although I just checked and spiders, zombies, fire elementals et al. have the same viewcone as human ai).

(#) If one assume that even a non-restricted ai cannot see what's behind it, then restricted ai might not need extra threatment.

During this I have only taken human-like ai into account thus far, to be honest, as those are the ones with the respective head animations that cause the issue. Using a dedicated spawnarg to specify the blocked off area might also be a good approach here, as it would also be easy to modify the defs accordingly as only the base definitions need change. But from what I've seen thus far I am not sure this is necessary.

[Dragofer]

7 hours ago, Obsttorte said:

The actual problem comes from the animation. The ai is leaning forward while at the same time slightly moving its torso to one side. If you replicate this irl you will notice that you are indeed able to see behind you in that case.

I thought that in the example videos it wasn't obvious that the AI would be able to see backwards in those animations. That would speak for excluding backwards vision. I dont think there are any regular AIs in Thief/TDM OM/FMs that have all-round vision.