View Issue Details

IDProjectCategoryView StatusLast Update
0001327The Dark ModCodingpublic07.10.2011 16:00
ReporterIshtvan Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityalways
Status resolvedResolutionfixed 
Product VersionTDM 1.06 
Target VersionTDM 1.07Fixed in VersionTDM 1.07 
Summary0001327: CProjectileResult remains indefinitely
DescriptionWhenever you fire an arrow, the CProjectileResult object stays around indefinitely. They used to self-destruct, but I think they were then used to apply "suspicious weapon" stims, so they no longer self destructed. However, they should still self destruct when the arrow is frobbed out of the ground. Also, using them for broken arrows doesn't make much sense, since broken arrow pieces can fly far from the point of impact, but the CProjectileResult stays at point of impact.

EDIT: The main reason I'm reporting this is that you could eventually hit the 4096 entity limit if you have a battle between archers or something. Or if some deranged player fires an arrow into wood and frobs it back hundreds-thousands of times.
TagsNo tags attached.

Relationships

has duplicate 0002870 closedgrayman AI see a weapon stim even if the weapon itself is destroyed 

Activities

Ishtvan

Ishtvan

11.10.2008 07:47

reporter   ~0001942

Update: Some information was wrong. The broadhead CProjectileResult remains for 2 minutes, the rest go away after a second or two. The broadhead behavior still qualifies as buggy though.

First, broken pieces can end up far from the point of impact, yet the point of impact still alerts them. Second, the alerting CProjectileResult doesn't go away when the arrow is frobbed back. Third, it probably should stay around if the arrow sticks in something and is never frobbed back. Otherwise it's kind of weird to have AI alerted by an arrow sticking out in the first two minutes, but not if they see it later than that.
grayman

grayman

07.10.2011 16:00

viewer   ~0004065

Fixes these problems, with [solutions] noted:

- A broadhead sticks into wood and the player quickly frobs it. A passing AI is alerted by the no-longer-visible arrow and barks that he sees a weapon. [When the arrow is frobbed, remove the projectile_result entity that’s sending the visual stims.]

- A noisemaker bounces off the ceiling and falls to the floor some distance away. AI are alerted by the sound, but search where the noisemaker hit, not where it ended up. This looks especially bad if an AI kneels down to inspect the arrow, but is nowhere near it. [Bind the projectile_result to the arrow so the visual stims come from wherever the arrow is, not where it hit.] (I’ll occasionally see an AI kneel far from the arrow, but I think that’s a hiding spot search problem, because I verified that the stim is originating from the arrow. Most times they’ll kneel at the arrow. I’ve even had two AI come at the arrow from different directions and kneel together at the arrow w/o getting in each other’s way. Looked pretty nice.)

- Ditto for broadhead flinders.

- Broadhead flinders get removed after 10s. AI can still “see” them for up to 2 minutes. [Remove the projectile_result entity when the flinders are removed.]

- A rope arrow sticks into wood, but passing AI can only “see” it for one second afterward. [Change the projectile_result’s expiration time from 1s to 2min.]

 AI can “see” a failed vine arrow forever, as opposed to the 2 mins defined for other arrows. [Give the projectile_result an expiration time of 2min.]

- AI finding arrows will bark about weapons, but the barks are designed for melee weapons lying on the floor, not arrows sticking into things. [Change the AIUse spawnarg for arrows to AIUSE_SUSPICIOUS and add code to support it. Make necessary *.def, *.sndshd changes so AI will make more appropriate barks for found arrows.]

 AI searching around a door can block other AI trying to use the door [Have other AI stand off until the search is over.]

- AI might sometimes not see an open door. [Loosen the requirements for a door that’s an obstacle.]
- Alerted AI sometimes messed up the order of a door queue. [Ignore alert level.]

rev. 4988:

State.cpp
State.h
ObservantState.cpp
SuspiciousState.cpp
HandleDoorTask.cpp
ai.cpp
ai_pathing.cpp
Memory.cpp
Memory.h
AIComm_Message.h
BinaryFrobMover.cpp
BinaryFrobMover.h
FrobDoor.cpp
FrobDoor.h
UserManager.cpp
UserManager.h

rev. 12288:

tdm_weapon_arrow_result_base.script
tdm_weapon_vinearrow_result.script
tdm_weapon_ropearrow.def
tdm_weapon_vinearrow.def
tdm_weapon_arrow.def
tdm_weapon_firearrow.def
tdm_ai_animal_horse2.def
tdm_ai_animal_rat.def
tdm_ai_base.def
tdm_ai_humanoid.def
tdm_ai_humanoid_undead.def
tdm_ai_monster_base.def
tdm_ai_monster_spider.def
tdm_ai_steambot_base.def
tdm_ai_trainer_melee.def
tdm_ai_vocal_set*.def
tdm_ai_critic.sndshd
tdm_ai_jack.sndshd

Issue History

Date Modified Username Field Change
06.10.2008 06:04 Ishtvan New Issue
06.10.2008 06:05 Ishtvan Description Updated
06.10.2008 06:05 Ishtvan Description Updated
11.10.2008 07:47 Ishtvan Note Added: 0001942
29.09.2011 21:31 tels Relationship added related to 0002870
01.10.2011 22:24 grayman Relationship replaced has duplicate 0002870
01.10.2011 22:25 grayman Assigned To => grayman
01.10.2011 22:25 grayman Status new => assigned
01.10.2011 22:25 grayman Product Version => TDM 1.06
01.10.2011 22:25 grayman Target Version => TDM 1.07
07.10.2011 16:00 grayman Note Added: 0004065
07.10.2011 16:00 grayman Status assigned => resolved
07.10.2011 16:00 grayman Resolution open => fixed
07.10.2011 16:00 grayman Fixed in Version => TDM 1.07