 |
When a projectile impacts and sets up a removal event, turn off any visual stims it’s giving off. For all intents and purposes, it’s no longer in the game. rev. 4994: State.cpp projectile.cpp |
 |
Hm, but why is it a bad idea that the firearrow sends a stim for 1.5s (unless that is a typo and meant 15s)? An expanding fireball _should_ send a visual stim to the AI, shouldn't it? After all, there is this huge explosion going on, why would the AI ignore it? |
|
|
In the *.def file for the fire arrow projectile_result, the visual stim that's a default for all p_rs is replaced with a fire stim. I don't think it was by accident, because of the way it's written. The p_r sends out a suspicious propagated sound, which is what alerts the AI. The projectile arrow is the only in-flight arrow that gives off visual stims. I suppose the idea is that there's no way AI are going to ignore a flaming arrow whizzing past. But the arrow hangs around for 1.5s after impact, and continues to give off that visual stim. So the result is that the arrow impacts, the sound propagates to AI, alerting them, causing them to say "what was that?" barks, and then a split second later they get stimmed by the arrow, and they say one of the more casual suspicious barks. So I just turned off the visual stim on the arrow after impact to prevent the secondary remarks. The AI still respond quite well to the explosion sound. I don't think they need a belts-and-suspenders visual stim from the p_r, which is probably why it was replaced by the original designer. |
|
|
Hm, I am not sure that turning the visual stim of just to avoid the secondary remarks is a good idea. Ideally, the code should be smarter and not emit these barks when the AI just heard a loud bang. The problems with the turning of is that it means that AI who not get the bang ignore the explosion altogether. Either because the AI did not hear the sound due to being out of range (it might be that the sound travels not as far as the visual stim, I am not sure), or because simply the AI is deaf. A deaf AI staring at the place where the arrow explodes would probably just ignore it now, unless it accidentily also sees the arrow whizing in - which it might miss depending on how often that stim is emitted. Think of deaf AI looking out of the door onto street, fire arrow explodes in front of the door. Btw, the mines might have (or not) the same problem. How is their explosion set up? |
|
|
We could give the projectile_result a visual stim of type AIUSE_EXPLOSION. Then we'd need a new sound snd_sawExplosion and collect together appropriate sounds for each voice set that have a higher urgency than the existing suspicious sounds. Then we'd need to coordinate sound alerts with visual alerts so that AI will make a single bark. This is not presently done. We can't just turn back on the arrow's visual stim after impact, because that causes the AI to use the less urgent suspicious barks, which aren't appropriate, and was the reason this issue was filed. That stim served its purpose when the arrow was in flight. After impact, any visual stim should come from the projectile_result for as long as it's around, which I think is 4s. Due to the volume of work, this would need to be deferred to 1.08. |
|
|
Hm, yes, using just an "suspicious" visual stim for an explosion is not good. The AIUSE_EXPLOSION sounds like a good idea then. Please do so :) |
 |
Original issue was addressed long ago. If someone wants to implement tie AIUSE_EXPLOSION concept it can be tracked in a new tracker. |
- Anonymous
