 |
In the calculations for alert levels 2-4, this is used to increase stealthScore: stealthScore += ( i - 1 ) * m_Stats.AIAlerts[i].Overall; If we want the Overall value for the busted level to be either 0 or 1, this would increase stealthScore by ( 5 - 1 ) * 0 = 0 or ( 5 - 1 ) * 1 = 4 So my first question is: where did the fixed "20" come from? Is that artificially high because getting busted is the worst case scenario for a stealth score? And my second question: if this is either a busted or not busted situation, then why does the accumulated number in m_Stats.AIAlerts[5].Overall matter? If it's 0, then you weren't busted. If it's > 0, then you were. Add the appropriate value to stealthScore and be done with it. |
 |
Ok here are the "short" answers. First, just to clarify the context, the basic punchline of this entry (the actual "bug") is that m_Stats.AIAlerts[5].Overall gives the wrong count for lvl-5 busts. If you're seen "3" times, instead of "3", it will output something nonsensical like "74". That's the bug this tracker is asking to fix if possible. If that were fixed, then we could just have the "stealthScore += ( 5 - 1 ) * 3 = 12" and everyone is happy. But right now, we can't get the "3", so we can't do that (it'd instead be *74, and you get some huge absurd number added to the score. BTW this makes your hypothetical example not possible. Your example was "( 5 - 1 ) * 1 = 4", but you can't get the "1" from anywhere. That's the problem. If you could get the "1", great!, that fixes it.) So the punchline is: If we can fix that bug, let's do it. If not, then we'll have to tolerate the current system, which works, and this entry isn't asking for anything else. The "busted or not busted" method (what I mean by "the current system") was just my hack fix in the meantime, since I couldn't get the accurate number but I could check ( 0 | >0 ), "add the appropriate value to stealthScore and be done with it" just as you noted. And that's just how it works in the current system; and it works fine. Your questions sound like they're asking "how do we fix that method". But (1) it works so there's nothing to fix, and (2) the point is we (or I) actually don't want it at all. What I'd like is to fix AIAlerts[5].Overall so that we can simply state "You were seen 4 times", and throw out the "busted or not busted" method altogether. To answer your questions directly. ...................... 1. where did the fixed "20" come from? Is that artificially high because getting busted is the worst case scenario for a stealth score? ...................... Essentially yes. "+20" is the 1-time penalty for being seen at all that I used as the hack fix when I discovered the AIAlert[5] was giving nonsensical output. It needed to give the message "VERY BAD", so that's why it's much higher than "4". We actually had a discussion in the thread & in PMs looking at different options & picking the best number, what's a number that can fit most FMs in most situations, and looking at the options side-by-side 20 seemed best. BUT NOTE that an adept player seen 1 time and a blundering player seen 400 times in a 6 hour game both get the same +20, so while it seems "high" for being seen once, actually on average it's much too LOW. It only represents being seen 5 times if we could track the number of busts the "proper" way (i.e., +4/per bust), and 5 busts is a rather low amount. (But a higher number has other problems.) I want to be clear though, to get back to the main bug, I personally hate being forced to pick one number for all situations. It's so unfair IMO! 400 busts only +20 = not fair. If there were a way to get m_Stats.AIAlerts[5].Overall to output the accurate number of busts, I would just list ( that number * 4 ) and toss this system out in a heartbeat. ............................ 2. if this is either a busted or not busted situation, then why does the accumulated number in m_Stats.AIAlerts[5].Overall matter? If it's 0, then you weren't busted. If it's > 0, then you were. Add the appropriate value to stealthScore and be done with it. ............................ This gets to the heart of the matter. First, to say it again, I personally don't want it to be "a busted or not busted situation", that was just my hack fix at the time. The score had to register *something* when you're lvl-5-busted. But the accumulated number would be much much better IMO. The reason the accumulated number matters is because if I'm a player and I want to know how many times I've been seen, a number like "12 times" will make me much happier than simply "You were seen." As it is now, 2 players seen 1 time and 100 times are treated the same, which is very unfair to the first player, especially for a big FM with like 100 AI and he avoids 99 of them. A stealth score worth its salt really needs to go easy on a player seen "1 time" and blast a player seen "100 times". And a stealth score that can't do that (i.e., the current system) should be fixed so that it can, if possible. Thanks for looking into this by the way. =) I'm always impressed by your energy & how well you've gotten to know our AI. If you want to read more detail, I actually wrote a longer post which I cut for this, but you can still read it here: https://docs.google.com/document/pub?id=1yctLH2bH2IxiWy2cGDARAb0UrmEXwB3lo1vVIPjohR4 |
|
|
Thanks for the great details. It seems, then, that the way to fix this is to not keep track of Level 5 alerts the same way we keep track of Level 2 - 4 alerts. While the latter can be a simple increasing count, the former must be a list of all the AI that have spotted you. That way, if an AI drops out of Level 5, back into Level 4, then spots you again, it won't get counted twice, which is probably what's happening. That's the only alert that can get miscounted, because when other types of alerts occur, they don't reoccur. (I.e. you can't steal the same loot twice.) So if Bob sees you, Bob's name gets put on a list. If Bob sees you again, he's already on the list, so he doesn't get double-counted. If Mary sees you, she gets put on the list. When it's time to post the stats, we just count up how many names are on the list. Wrt the math, though, if (say) 3 AI see you, how does that add to the stealth score? Is it (5-1)*3 = 12? Thanks. |
|
|
- Yes, a separate tracking of Lvl-5 alerts sounds like the way to go. - I like the simplicity of your idea. "4 AI saw you.", or maybe just "4 saw you" (since it's not good for a fiction to admit it's "AI"). It's easy to track (I think) & communicate. - IIRC we wanted a lvl-5 bust to be "5 points", because it's the worst bust so deserved a little tip on the scale. So 3 AI see you would be a simple ( 5 * 3 ) = 15. - Another idea (or a case to re-do the current system but fixed to work properly): it might be a good thing counting every "encounter", i.e., just counting the "entry bust" to Lvl-5 "period" then not counting "re-busts within that period" ... even for the same AI, e.g., 1 AI sees you, goes back down to 4, then sees you again later back to 5 = "Seen 2 times". That's actually not a bad thing. E.g., it's ok IMO if you leave for a while & come back to that AI. One way to do it that avoid the problems of the current system might be with a "delay timer", so when the AI goes "into Lvl-5" it only "counts" if he has not been in Lvl-5 (i.e., *has* been at any other lvl) at any time within the last 30s or 1m, that is, there's been a delay since "the last time seen". Then you can have 1 AI see you 2x and count twice, but we don't worry about cascades or quick turn overs. Just another idea to think about. - Or even if you go to lvl-4 at any time, or goes to Lvl-4 for longer than 1 or a few frames, I think that can re-set the ability for the Lvl-5 bust to count (a simple Lvl5BustCountable boolean), and any before that time don't count. Practically that might work the same way as above, and may be easier to work out. BTW I don't think this is how the current system bugs up (I'm not sure?). I don't think with the current system the AI *is* actually going down to 4 and back up to 5. In my earlier testing with the lvl-5 stat, I had alert debug info on and once the AI went to Lvl-5, the AI never (visibly) dropped out of lvl-5 running after me the whole time, I'd let him kill me, and saw that the count was still incrementing pretty fast, so I also thought it might be counting something like the player-visStims it received the alert. Also the stat was adding up about 1 "hit" every 1-2 seconds, much faster than I think the AI ever goes down to 4, so I thought it was something else. Another thing, just looking at the code, once the AI is in lvl-5 it looks like it "locks in" until it goes quite a long while without stimulus, and new stimulus doesn't alter it's state (IIRC); and the stat is adding up "busts" much faster than what the code looks like it should. (Actually that confused me about the whole thing.) Anyway, the point is that maybe it's good a new system re-sets the Lvl-5 countability (a boolean) when the AI goes into any other alert for longer than 1 or a few frames. Your idea was clever in that it completely side-stepped the whole issue by just single-counting that one AI, but if it is possible to somehow count discrete "entries into encounters" I think it's worth at least considering. - One question for discussion on which approach is better: if you were an ave player wanting the most useful info about their stealth record, which is more useful: (1) knowing the raw number of AI that see you (if they see you once, they know you're there for good) "Seen 1 time" or (2) knowing each time you're busted, so if there's a tricky part with 1 AI, and you try 3 times & get busted the first 2 times but make it through the 3rd, then the stat says "Seen 2 times". I tend to think option-(2) gives more information about the stealth record to the player. So I'd tend to go with (2) if I had to pick, but if (2) is hard to set-up properly and (1) is much better, that's of course a good reason to go with option-(1), and it's much better than the current way. - A 3rd idea: I still like the idea if one AI sees you "more" it's worse than if he sees you "less" if possible. What I mentioned above is one way. Another idea I'd like if it's possible is if you could get the sys.time at the moment he goes into the alert and the sys.time he goes out, subtract & get the duration of alert, then just make a += stat for TotalLvl5Duration (for all AI). So then you could have "You were seen by 4 AI for 6m:14s" (or even, "You were seen for 6m:14s"), which deserves a worse score than "You were seen by 4 AI for 0m:3s". (One twist is that this would be man-seconds, that is 2 AI seeing you for 1 min would = "2m", which might confuse some people (e.g., if it's longer than the whole mission time) but it's still a good standard. Another alternative would be to divide it by the AI alerted (so 6m:14s/4, and say "You were seen by 4 AI for an ave 1m:31s per AI", or "You were seen for ave 1m:31s"). Another alternative would be to not count overlapping alert time, which would be complicated but not impossible. All this is assuming we can get the sys.time "going into" and "going out of" the Lvl5 alert (or into any other alert for that AI). If so, I think it would be a nice thing to add.) - Anyway just some ideas to think about. If we're making a new system altogether, it raises the opportunity to do some creative things while we're at it. One reason I haven't tried much myself is, first of all, I didn't know how to send a variable from the alert code to the stat code (my logic is pretty good, but I'm still rusty on simple programming stuff), and I wasn't sure where or how to best do the counting. |
|
|
I can easily change the stealthScore addition to 5*N, where N is the number of unique AI that saw you. "AI" appears in 5 text strings on the Stealth Details page. We should defer any text changes to 1.08. We are on the doorstep of freezing 1.07, and changing text at this point means affecting Tels' internationalization: he'd need to change thoses texts in several languages and test them. I've already had to ask him how to change the busted strings to the new format. Also because we're about to freeze 1.07, I would prefer to defer any changes to the way the stealth score is calculated to 1.08. The level of detail you're proposing will require a lot of code changes and testing, not good things to do when we're about to freeze. And I think these changes should be put to the team, since I've honestly paid zero attention to stealth when playing myself, and don't know what types of strongly-held opinions are out there. And one other question: On the Stealth Detail page, it says: "Alert 5. Seen + 4" Shouldn't that be "Alert 5. Seen * 4"? (Or, with the severity change: "Alert 5. Seen * 5".) |
|
|
I deliberately didn't assign "Target Version" to "1.07" because I realized this couldn't make 1.07 in time and would be for 1.08. The only reason I made the bugtracker now is because I thought I had made it months ago and double-checking a few days ago I realized I hadn't! So thought I may as well do it now. It's cool to wait for 1.07 to get out the door first though. Yes we should drag back up the thread on this when we get to changing code to run it by the team. On the Stealth Detail it currently says "Alert 5. Seen + 20" because there's the one-time addition of "+20" when you are seen. When we fix it, it'll probably be changed to something like "Alert 5. 3 alerts * 5". I forgot to mention the other thing I like about tracking "duration" is that it doesn't matter how many times or how the alert re-triggers, it just keeps adding up time whether it's 1 long period or 50 bursts, it doesn't matter to it, but you still get that extra info of "being seen more is worse". |
|
|
See http://forums.thedarkmod.com/topic/9771-stealth-score/page__view__findpost__p__269177. |
|
|
Track when AI see the player and lose sight of him. Tally it all up at the end for the mission statistics screen. rev. 5015: ai.cpp ai.h MissionData.cpp MissionData.h MissionStatistics.cpp MissionStatistics.h rev. 12377: strings/* |
- Anonymous
