View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004002||The Dark Mod||AI||public||01.01.2015 15:07||16.11.2016 15:05|
|Product Version||TDM 2.03|
|Target Version||TDM 2.05||Fixed in Version||TDM 2.05|
|Summary||0004002: Review Stealth Score Reporting|
|Description||Since AI can land on states 1, 2, 3, and 4 on their way to state 5, it's probably not fair that each state contribute to the stealth score.|
Prior to 1.08, an AI spotting the player could immediately leap all the way to state 5, so the score would reflect that. But players complained about the AI's rapid response, so player detection is now a ramping-up process that produces the 1->2->3->4 situation.
We should investigate this and see if there's a fairer way of representing stealth, at least as far as spotting the player is concerned.
|Additional Information||One solution would be to only register the highest alert state reached with the stats module, and do that once the AI has returned to state 0. Each climb and drop in alert level would then represent an "encounter". A "sighting" would still be reserved for having arrived at state 5 (combat).|
When the player dies, we'd need to collect last-minute registrations from AI who are in a state > 0, so that the stealth score is accurate at the end of the mission. (Those AI won't be given a chance to naturally drop back to state 0.)
|Tags||No tags attached.|
Note from demagogue:
"Just on the stealth score, for future reference, when rising levels are connected, it might be good to have the system register the highest alert and cap it there, until it goes back down to zero, then the system resets. Then running and hiding won't be more costly than coming into view and fighting.
But it has to be thought out too. A player should expect a higher score if they prolong the running too much, so it could recount after maybe 30 sec or so as well."
|Moving to 2.05 because it's a large design change which could hinder getting 2.04 out in a timely manner.|
For now, I'm not going to introduce a addition to the stealth score for running around for 30s or more while spotted. This represents a new way of looking at things, and means creating future registration events based on timers, and knowing when to disable those timers if the player manages to hide before the timers run out.
It's too much for me to add timers and their maintenance at this stage.
Track alert events in a list for each AI, and register meaningful alerts when the AI returns to Idle State or the player reaches Mission Complete. Measure the amount of time the AI spends in each Alert State as it rises toward Combat, and only register those that indicate the AI spent “some time” there before rising again. “Some time” is defined as half the time allotted for ramping down in each Alert State, with both Searching and Agitated Searching clamped at 10s.
Anyone checked that sighting objective still fails after this change?
|Do you have evidence that it fails, or are you asking because you looked at the code and found something wrong?|
|How about this for evidence - a guard sees player and attacks but the objective does not fail? Map is Talbot Collateral here.|
Good evidence. I'll look at the objectives in that map and see what's happening.
Edit: An optional objective in Difficult mode is to not have any AI rise to an alert level of 5 (Combat) because of the player.
If the guard is attacking, and no "objective failed" message is displayed, then there's a problem.
I'll look at this today.
The problem lies in waiting until the AI returns to alert level 0 before registering the highest alert level attained.
An objective like this optional objective needs to be registered immediately, instead of waiting for the AI to return to 0.
Perhaps a better way to solve the OP problem is to register the alert level changes, but to have lower alert levels removed from the Statistics math when they are overridden by a higher alert level in the same alert cycle. (I.e. don't wait until returning to level 0 to register.)
Now the registration occurs immediately, but if a subsequent alert on the same cycle (the time between being at Idle, rising in alert level, and falling back to Idle) occurs, the “counting” of the previous alert is undone, based on some time durations between alert N and alert N+1.
|01.01.2015 15:07||grayman||New Issue|
|02.01.2015 14:46||grayman||Note Added: 0007294|
|29.09.2015 00:03||grayman||Relationship added||related to 0004222|
|17.10.2015 18:54||grayman||Assigned To||=> grayman|
|17.10.2015 18:54||grayman||Status||new => assigned|
|26.12.2015 02:38||grayman||Note Added: 0007916|
|26.12.2015 02:38||grayman||Target Version||TDM 2.04 => TDM 2.05|
|10.08.2016 18:16||grayman||Note Added: 0008256|
|11.08.2016 12:43||grayman||Note Added: 0008258|
|11.08.2016 12:43||grayman||Status||assigned => resolved|
|11.08.2016 12:43||grayman||Resolution||open => fixed|
|11.08.2016 12:43||grayman||Fixed in Version||=> TDM 2.05|
|10.11.2016 14:06||duzenko||Note Added: 0008464|
|10.11.2016 14:06||duzenko||Note Edited: 0008464||View Revisions|
|10.11.2016 14:32||grayman||Note Added: 0008465|
|10.11.2016 14:41||duzenko||Note Added: 0008466|
|10.11.2016 15:34||grayman||Note Added: 0008467|
|10.11.2016 15:44||grayman||Note Edited: 0008467||View Revisions|
|10.11.2016 16:27||grayman||Note Added: 0008468|
|13.11.2016 04:33||grayman||Relationship added||has duplicate 0004415|
|15.11.2016 16:32||grayman||Note Added: 0008484|
|16.11.2016 15:04||grayman||Note Edited: 0008484||View Revisions|
|16.11.2016 15:05||grayman||Note Edited: 0008467||View Revisions|