View Issue Details

IDProjectCategoryView StatusLast Update
0004392The Dark ModAIpublic04.10.2016 14:37
Reportergrayman Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityalways
Status resolvedResolutionfixed 
Product VersionTDM 2.04 
Target VersionTDM 2.05Fixed in VersionTDM 2.05 
Summary0004392: Dropped torches seen by passing AI as dropped weapons
DescriptionDouse a torch carried by an AI that's got an attached weapon, and AI will see the attached weapon as a suspicious dropped weapon.
Steps To Reproducebug2603:

Builder guard carries a torch and a hammer. Douse his torch and he drops it. Passing AI comment about seeing a weapon: the hammer still carried by the builder guard.

Wench carries a torch and a dagger. Douse her torch. Passing AI comment about seeing a weapon: the dagger still carried by the wench.

Secondary problem:

Dousing the wench's torch didn't cause her to drop it. This is the first time in years that I haven't seen the torch get dropped.
TagsNo tags attached.

Activities

grayman

grayman

04.10.2016 13:48

viewer   ~0008362

There’s very old code (idEntity::GetTeamChildren()) that was found to be buggy a long time ago, but it was never fixed. Routines calling this code make sure they call it in such a way that the bug doesn’t occur. It’s too late to straighten out the buggy code because it’s used all over the place, and changing could be dangerous.

Calling this code from the light holder script didn’t account for the bug, so ALL attachments to the AI that gave off STIM_VISIBLE were having their stims enabled, even when they remained attached to the AI. Now that AI are receiving STIM_VISIBLE from weapons, this caused passersby to see an attached weapon and react.

Only enabling the visual stim on lights fixes the problem.

Rev. 14604:

tdm_light_holders.script


Secondary Problem:

I'm guessing that the wench, going into alert mode when she was stimmed by her own dagger, somehow disrupted the torch dropping code. With the alert now avoided, hopefully the problem won't recur.
nbohr1more

nbohr1more

04.10.2016 13:52

developer   ~0008363

How about creating a new idEntity::GetTeamChildren_New() and then each time a bug about the old one is encountered point the calling code at the new one and then we can slowly migrate all code to the new one as individual cases start accumulating and turning into general cases?
grayman

grayman

04.10.2016 14:08

viewer   ~0008364

This is a good idea.

However, the issue is in how the team tree of attached items is set up. The routine says it only deals with the children of the specified entity, but what happens is that it ends up dealing with _all_ the members of the team. (A 'team' is--for example--an AI and his head and a hat and weapon and keys and coin purse and torch. A team could also be a complex group of movers that are attached to each other in odd ways.)

So guaranteeing that a new routine only considers its real children depends on the complexity of the team member relationships.

This could take a considerable amount of time to understand and accommodate all possible relationships.

It's possible that this was why the code was never fixed, and why code using this routine only calls it with the team master (or 'parent'), or checks on each provided child to make sure the child is an object that's relevant to the action being performed on that child.

There might be a better way to warn coders about the situation. I'll have to think about it.

I'm very reluctant to migrate existing code from the old routine to a new routine. I think I'd rather just fix the bugs as they appear, in a way that's relevant to the situation at hand.
nbohr1more

nbohr1more

04.10.2016 14:37

developer   ~0008365

Ouch.

I guess another way would be to create a brand new relationship concept. Eg. idEntity::GetCollectiveChildren() which is only used for making these types of determinations and then call that from idEntity::GetTeamChildren() if conditionals are met. You could then start with a small sub-set of releationships and then expand the scope until you've covered most of the broken use-cases?

Issue History

Date Modified Username Field Change
04.10.2016 02:21 grayman New Issue
04.10.2016 02:21 grayman Status new => assigned
04.10.2016 02:21 grayman Assigned To => grayman
04.10.2016 13:48 grayman Note Added: 0008362
04.10.2016 13:48 grayman Status assigned => resolved
04.10.2016 13:48 grayman Resolution open => fixed
04.10.2016 13:48 grayman Fixed in Version => TDM 2.05
04.10.2016 13:52 nbohr1more Note Added: 0008363
04.10.2016 14:08 grayman Note Added: 0008364
04.10.2016 14:37 nbohr1more Note Added: 0008365