 |
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. |
 |
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? |
|
|
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. |
|
|
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? |
- Anonymous
