View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004222||The Dark Mod||Coding||public||28.09.2015 23:56||22.03.2020 12:10|
|Priority||normal||Severity||normal||Reproducibility||have not tried|
|Product Version||TDM 2.03|
|Target Version||TDM 2.09|
|Summary||0004222: Might be a Mission Stats problem with registering alerts|
|Description||Look through the code and reconcile the use of:|
and the old way of doing things, which probably only involved
|Additional Information||CMissionData::AlertCallback() needs to be called for the rise in alert level to be registered with the stats. It might be that this is bypassed for certain alerts.|
Find out if it's this way on purpose, or does AlertCallback() need to be moved inside SetAlertLevel().
|Tags||No tags attached.|
Rather than having an AI tell MissionData about alert level increases as they are happening, it would be more accurate for stats purposes to precede this line in IdleState::Init()
owner->m_recentHighestAlertLevel = 0; // grayman 0003472
with a call to MissionData to record an 'episode' of increasing alertness.
This guarantees only one registration per 'episode' and eliminates the possibility of registering multiple times as an AI goes up and down and up and down in alert level after leaving IdleState.
Ditto for AlertIdleState::Init().
"My intuition is it could be defined in a time band. If the level is ramped up in less than maybe 3 or 5 seconds, it should count only the highest, as if it's one event.
But if it's more than that, they count separately, the logic being you were under alert and could have gotten out, but didn't, so get separate punishment.
Or more generally, after 3 seconds or so in a dynamic situation, it's more fair to call the 2 interactions separate "events"."
|Moving to 2.05 because it's a large design change which could hinder getting 2.04 out in a timely manner.|
|Moving to 2.07 due to the amount of work involved.|
Moving to 2.08 for the same reason: big design change.
I'll try to get to it after 2.07 is released.
In the hopes of getting at least the loot total to render,
I went poking around with this again.
setting a static int for:
int MissionStatistics::GetFoundLootValue() const
static int sum = 0;
in MissionStatistics will render value out of x for loot but the value
will be totally incorrect.
I tried moving up the codebase to where LOOT_COUNT is inherited from
but thus far have not been able to compile anything set to static up there.
|28.09.2015 23:56||grayman||New Issue|
|29.09.2015 00:03||grayman||Relationship added||related to 0004002|
|29.09.2015 01:54||grayman||Note Added: 0007808|
|29.09.2015 01:54||grayman||Note Edited: 0007808||View Revisions|
|01.10.2015 11:48||grayman||Note Added: 0007827|
|17.10.2015 18:54||grayman||Assigned To||=> grayman|
|17.10.2015 18:54||grayman||Status||new => assigned|
|26.12.2015 02:39||grayman||Note Added: 0007917|
|26.12.2015 02:39||grayman||Target Version||TDM 2.04 => TDM 2.05|
|21.10.2016 15:28||grayman||Target Version||TDM 2.05 => TDM 2.06|
|16.09.2017 18:34||grayman||Note Added: 0009261|
|16.09.2017 18:34||grayman||Target Version||TDM 2.06 => TDM 2.07|
|24.11.2017 16:29||grayman||Assigned To||grayman =>|
|24.11.2017 16:43||grayman||Status||assigned => new|
|13.12.2018 12:40||grayman||Note Added: 0010902|
|13.12.2018 12:41||grayman||Assigned To||=> grayman|
|13.12.2018 12:41||grayman||Status||new => acknowledged|
|13.12.2018 12:41||grayman||Target Version||TDM 2.07 => TDM 2.08|
|18.12.2018 05:27||grayman||Assigned To||grayman =>|
|26.12.2018 07:21||nbohr1more||Note Added: 0011128|
|07.01.2019 15:25||grayman||Assigned To||=> grayman|
|07.01.2019 15:25||grayman||Status||acknowledged => assigned|
|08.01.2019 04:55||nbohr1more||Relationship added||parent of 0004950|
|22.03.2020 12:10||grayman||Target Version||TDM 2.08 => TDM 2.09|