 |
Added a second guard with a key on his belt. I can stand at the origin, and with two frobs pluck both keys off the belts 300 units away. It's as if the keys are sitting at the origin, but when I check the origins of the keys, they're out on the guards' belts. Something odd is going on with the trace function. It thinks the keys are only 39 units away, w/in frob distance. |
|
|
At first, I corrected this by checking the abs bounds on the entity, instead of the abs bounds kept in the cliplink list (the following code from idClip::ClipModelsTouchingBounds_r). // if the bounds really do overlap if ( check->absBounds[0][0] > parms.bounds[1][0] || check->absBounds[1][0] < parms.bounds[0][0] || check->absBounds[0][1] > parms.bounds[1][1] || check->absBounds[1][1] < parms.bounds[0][1] || check->absBounds[0][2] > parms.bounds[1][2] || check->absBounds[1][2] < parms.bounds[0][2] ) { continue; } This corrected the key problem, but it caused a problem of not being able to hit an AI's head with a broadhead; the arrow sailed right through. Putting the code back to what it was corrected that problem. So--if there's a fix at all, and there might not be--it has to lie in the link/unlink code. |
 |
Mysterious that frobbing works from two different places. There must be two checks happening, either explicitly or more likely as a side effect. How did you discover the nonsolid head effect? And I wonder if an arrow would be stopped a little way above the origin in that experiment? Just idle speculation atm but I find this really intriguing. Working out how the clip links work is on my to-do list too. I plan to have another go at those physics issues that were too hard for me in April once I get back to the uk next week. I might have more chance of success now I'm a bit more acclimatized to the game code. |
|
|
I attached a test map that shows the problem. After starting, try frobbing in the air above or near the square patch in the floor. You should be able to frob the attachments off the guards. I noticed the nonsolid head when I was conducting tests on the pickpocket reaction. I think the problem comes from an attachment being spawned momentarily near the origin, then moved as an attachment to the AI. The cliplink list captures both clipmodel boundaries, then later uses the wrong one when testing what's in the path of the player's LOS during a frob. Correcting for an attachment clobbered collision detection on an AI's attached head. Perhaps some special-case detection also needs to be added. It's unclear to me why there would be more than one clipmodel for anything. |
|
|
Thanks. I'll be able to play with it Friday. I'm wondering whether g_showentityinfo will show them there too. Inventory items leave their world bounding boxes behind like that, but that's different because they've not been moved, they've just been hidden. But it makes me wonder whether it makes a difference whether the key is positioned in DR or def attached. A key positioned in DR has no business at the origin. |
|
|
Yup, the keys are frobable from the origin but not, apparently, the coin purse. g_showentityinfo does *not* show bounding boxes at the origin. Keys positioned in DR don't have the problem, as suspected. Why keys and not a coin purse? Hmmm. I got a definite pickpocket reaction from one of my snatches-from-the-origin, delayed by a few seconds. |
|
|
Aha! It's not the key being hit by the trace at the origin, it's the key's frobbox. Keys do have two distinct collision models: their own, plus their frobbox. The key's own cm is correctly positioned when the map starts, but the frobbox cm is sitting at the origin. The reason you can't frob the loot purse from the origin is that it doesn't have a frobbox spawnarg. |
 |
For the frobbox an additional clipmodel is used, but only if frobbox_size or frobbox_mins _maxs respectively are set. The member pointer is m_frobbox in idEntity. To me it seems that when the entities position get's updated, the frobbox doesn't get moved, too. Maybe this have been overlooked back when the frobbing was implemented. I'm currently trying to find the piece of code handling the movement. |
|
|
I think you're right. There might simply be no code at all that updates the frobbox tracemodel. But there must be some code somewhere that updates the other tracemodel, the one for the object's own clipmodel. If you can find that code, perhaps we can make it happen for the frobbox too. |
|
|
I'm assigning this to myself because I diagnosed it last summer and will eventually get round to fixing it, but if anyone wants to fix it sooner please just assign the issue to yourself! |
 |
Here is a bit more info: For idMoveableItem, the frobbox is stored in trigger and this is updated on each Think: /* ================ idMoveableItem::Think ================ */ void idMoveableItem::Think( void ) { RunPhysics(); if ( thinkFlags & TH_PHYSICS ) { // update trigger position trigger->Link( gameLocal.clip, this, 0, GetPhysics()->GetOrigin(), mat3_identity ); } idEntity attempts the same. Both have the same subproblem, temporary hidden objects will use 0,0,0 as origin. In this case the update might be needed to be skipped: if ( (thinkFlags & TH_PHYSICS) && m_FrobBox ) { // update trigger position // TODO: Tels: What about hidden entities, these would use (0,0,0) as origin here? m_FrobBox->Link( gameLocal.clip, this, 0, GetPhysics()->GetOrigin(), GetPhysics()->GetAxis() ); } The frobbable keys should be idMoveableItem, however. The code for updating the frobbox might thus not be correct. One suspicious difference is that it doesn't use the "axis" to update trigger->Link() (either it must use the axis to construct the tracemodel, and update it, or the identity, but once so and once so?) The other problem might be that the key is attached, and thus the bindmaster's origin might need to be taken into account. Hope this helps to track this down. |
|
|
Ack, the error is obvious. I just spotted this again while looking for another issue in my list. The error is in the code you pasted above: GetPhysics()->GetOrigin(). GetOrigin() for bind objects returns the origin *relative to the bind point*, which is 0 0 0 unless the mapper does something special. The clip link code will need the *world* origin. |
|
|
No, I'm wrong. That'll teach me to check the code before posting. GetPhysics()->GetOrigin() apparently returns world coordinates already. It's the *script event* getOrigin() that returns the local coordinate. |
|
|
The keys aren't idMoveables after all, they are idSpawnableEntity. That's just an empty wrapper for idEntity. I added a walking guard with a bound key (placed in DR and bound, not def attached) to the test map, and he wanders around leaving the frob box midair where he started. I can grab the key using that frob box too. This matches a report I remember from RJFerret last year about scrolls bound to AI being frobable from where they spawned as well as from the scroll itself. It seems the frob boxes of bound items are not updated at all, so def_attached items leave their frob boxes at the map origin, and entities placed in DR leave them where they spawn. idEntity::Think for bound items doesn't call any physics code directly. Physics updates for bound items are handled by the bind master's idEntity::RunPhysics. It doesn't do frob boxes, but it needs to. |
|
|
Forum opinion broadly in favour of removing the frob boxes instead of making them move with their owner. Keys are easy enough to pickpocket already. idEntity::PostBind seems the right place for the fix. It gets called after both def_attachments and DR binds. An entity can destroy its frob box if it finds itself attached to an animated entity. Frob boxes will still be left behind when a frob-boxed entity is bound to something else that moves, e.g. an idMover. But broadening the fix to include those cases would risk losing frob boxes where they are needed in chests etc. |
|
|
at rev 6499 game/entity.cpp |
|
|
After blackjacking discussion in the forum today, reopened to check that the BJ mechanism isn't affected by this change in 2.04. |
|
|
It's fine, the KO logic doesn't use a frob box or anything like it. Hits to standard body trace models are used. |
- Anonymous
