View Issue Details

IDProjectCategoryView StatusLast Update
0002885The Dark ModAIpublic24.11.2017 16:38
Reportergrayman Assigned To 
PrioritynormalSeveritynormalReproducibilityalways
Status newResolutionreopened 
Product VersionTDM 1.06 
Summary0002885: Fire arrows continue to send visual stims to AI after impact
DescriptionFire arrows are the only arrows that send visual stims in flight. After they impact, they continue to send those stims until they're removed 1.5s later. This can cause AI to react to them as suspicious objects even as the fireball is expanding.
TagsNo tags attached.

Activities

grayman

grayman

15.10.2011 18:30

administrator   ~0004072

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
tels

tels

16.10.2011 10:20

developer   ~0004073

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?
grayman

grayman

16.10.2011 15:22

administrator   ~0004074

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.
tels

tels

16.10.2011 17:43

developer   ~0004076

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?
grayman

grayman

16.10.2011 18:34

administrator   ~0004077

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.
tels

tels

16.10.2011 19:17

developer   ~0004078

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 :)

Issue History

Date Modified Username Field Change
15.10.2011 17:19 grayman New Issue
15.10.2011 17:19 grayman Status new => assigned
15.10.2011 17:19 grayman Assigned To => grayman
15.10.2011 18:30 grayman Note Added: 0004072
15.10.2011 18:30 grayman Status assigned => resolved
15.10.2011 18:30 grayman Resolution open => fixed
15.10.2011 18:30 grayman Fixed in Version => TDM 1.07
15.10.2011 18:30 grayman Target Version => TDM 1.07
16.10.2011 10:20 tels Note Added: 0004073
16.10.2011 10:20 tels Status resolved => feedback
16.10.2011 10:20 tels Resolution fixed => reopened
16.10.2011 15:22 grayman Note Added: 0004074
16.10.2011 15:22 grayman Status feedback => assigned
16.10.2011 17:43 tels Note Added: 0004076
16.10.2011 18:34 grayman Note Added: 0004077
16.10.2011 19:17 tels Note Added: 0004078
16.10.2011 21:32 grayman Fixed in Version TDM 1.07 =>
16.10.2011 21:32 grayman Target Version TDM 1.07 =>
24.11.2017 16:38 grayman Assigned To grayman =>
24.11.2017 16:38 grayman Status assigned => new