Should pickpocketing keys be easier?

[SteveL]

This isn't a gameplay suggestion, it's a question how to fix a bug.

Some small moveable items, such as keys, have "frob boxes" surrounding them to make them easier to pick up. A frob box is an invisible box that's larger than the item it encases. You can frob anywhere on the box to frob the item. That makes keys easier to frob from chests or cluttered tables, where other items are competing for your frob-highlight.

We have a bug with frob boxes: if the key or necklace is bound to something moving, such as an AI's belt, the frob box doesn't move with it. That means that you can "pickpocket" the item from two different places in the map: the AI's belt, or the other place in the map where the frob box got left behind. For def_attached items, that's always the map origin, so if the player can find the map origin and does frob-frob-frob-frob-frob, they can pickpocket every key off every guard in the map.

Clearly we need to clear up the misplaced frob boxes. The question is whether to fix them so they move with their item, which would make it easier to pickpocket keys, or to remove them from the game world completely, which will leave pickpocketing the same as it is now.

Right now frob boxes only help with stationary objects like keys in chests and push-buttons. Objects attached to AI are easier to grab anyway because they are not surrounded by other frobable objects, so I'm not sure we need them carrying frob boxes too. What do you guys think?

[Obsttorte]

I think it would be rather inconsistent if frob_boxes work for stationary, but not not for attached objects. So I'm for suggestion #1, they should move with their item.

[Springheel]

I think keys are already a little too easy to frob...I'd rather leave them working the way they are now. Good find on that bug though!

[Destined]

I have so far never encountered any problems with pickpocketing keys. But I have quite some problems with money pouches on guards. So as for the problem at hand, I would also leave it as it is.

[SteveL]

I reckon that keys shouldn't be easier to pickpocket too. As for purses, they don't have a frob box anyway, so they're harder to get from chests too. We could add a frob box but it won't help with pickpocketing unless we go with the other option and make frob boxes move, thus making keys easier to pickpocket too. I've never minded purses being hard to pickpocket -- after all, it should be quite tricky to steal someone's purse -- but we could give them a frob box like keys so that they're easier to pluck from chests and tables.

[Springheel]

but we could give them a frob box like keys so that they're easier to pluck from chests and tables.

 

 

I agree--they have always been finicky to get out of chests.

[Destined]

For chests it is a really good idea. On guards I actually did not really mind. After some failed attempts I usually just give up. I am not perfectionistic enough to loot all the gold in the level and just rely on other loot.

[ERH+]

I thought that 0 0 0 point of map may store temporal objects in this editor, just like in Dromed. Are there any other reasons for avoiding central point, or maximum map boundaries ?

[Scampada]

Clearly we need to clear up the misplaced frob boxes. The question is whether to fix them so they move with their item, which would make it easier to pickpocket keys, or to remove them from the game world completely, which will leave pickpocketing the same as it is now.

 

Right now frob boxes only help with stationary objects like keys in chests and push-buttons. Objects attached to AI are easier to grab anyway because they are not surrounded by other frobable objects, so I'm not sure we need them carrying frob boxes too. What do you guys think?

 

As I've experienced after two days playing, pickpocketing keys isn't way too hard. I can even grab them without seeing 'em. But, in some cases, like the key in a pot in 'Tears of Saint Lucia', it's easier to get them without looking right into it. Is it possible to leave them only for static keys?

 

_{PS Too bad that there is only one jdude's mission. It's terrific! I want more!}

[SteveL]

I thought that 0 0 0 point of map may store temporal objects in this editor, just like in Dromed. Are there any other reasons for avoiding central point, or maximum map boundaries ?

I've seen slowdown in at least one of my test maps at the origin. A lot does go on there. On the other hand, I've checked out real maps whose origin is accessible to the player (NHAT part 2, A Score to Settle) and they don't have noticeable problems around the origin (except the one we're talking about fixing in this thread).

 

As I've experienced after two days playing, pickpocketing keys isn't way too hard. I can even grab them without seeing 'em. But, in some cases, like the key in a pot in 'Tears of Saint Lucia', it's easier to get them without looking right into it. Is it possible to leave them only for static keys?

That's probably what we'll end up doing.

[Tels]

I'm torn. Fixing the frob-box to move with the key is the correct thing to do, but pickpocketing shouldn't get easier.

 

OTOH, *does* it really get noticable easier if the frob-box moves with the key?

[SteveL]

I'm torn. Fixing the frob-box to move with the key is the correct thing to do, but pickpocketing shouldn't get easier.

 

OTOH, *does* it really get noticable easier if the frob-box moves with the key?

 

No, it turns out that it won't get easier if the frob box moves with the key. I've since discovered that prop keys (meant for def-attaching) don't depend on the frob box at all. The frob box is irrelevant. Prop keys have a 32-unit cube as their collision model, instead of a precise collision model derived from the visible model. That 32-unit cube would swallow the 10-unit frob box completely even if the frob box could move.

 

I've already committed a fix for the mislocated frob boxes: remove the frob box from any entity that gets bound to an AI or other animated entity. That's still probably the right thing to do given that (1) those misplaced frob boxes are bugs, (2) in general we want to reduce not increase the number of moving collisioin models for performance reasons, and (3) we have another way to make pickpocketing easier -- using enlarged and simplified collision models for attached items like happens with keys right now. But it's up for debate.

[Tels]

No, it turns out that it won't get easier if the frob box moves with the key. I've since discovered that prop keys (meant for def-attaching) don't depend on the frob box at all. The frob box is irrelevant. Prop keys have a 32-unit cube as their collision model, instead of a precise collision model derived from the visible model. That 32-unit cube would swallow the 10-unit frob box completely even if the frob box could move.

 

I've already committed a fix for the mislocated frob boxes: remove the frob box from any entity that gets bound to an AI or other animated entity. That's still probably the right thing to do given that (1) those misplaced frob boxes are bugs, (2) in general we want to reduce not increase the number of moving collisioin models for performance reasons, and (3) we have another way to make pickpocketing easier -- using enlarged and simplified collision models for attached items like happens with keys right now. But it's up for debate.

Thanx for the investigation and fix!

 

The 32-unit cube might actually be adjustable - smaller => harder pickpocket, larger => slightly easier. But I'm not sure it really needs adjusting, we don't seem to have many complaints.

 

And yes, I concur that having less collision boxes is better - although the code only uses one of them (either the frob-box, or the CM), anyway?

 

I'm still trying to think if removing the frob-box from bound items will create problems in some cases. What happens for swords or other items attached to an AI? And is the frobbox restored when the item gets "unbound"?

This doesn't happen for things the player picks up, but it might be for things theAI can drop, like the lantern?

 

Edit: Or did you mean you simply removed the frob-box definition from the prop items?

Edited May 18, 2015 by Tels

[SteveL]

The 32-unit cube might actually be adjustable - smaller => harder pickpocket, larger => slightly easier. But I'm not sure it really needs adjusting, we don't seem to have many complaints.

It's adjustable using the "size" spawnarg. Personally I think keys should be a bit less easy to steal than they are -- the CM is half the size of the AI that's carrying the key! -- but I won't start a campaign about it

 

And yes, I concur that having less collision boxes is better - although the code only uses one of them (either the frob-box, or the CM), anyway?

I hadn't spotted that... Although, at least some of the code must be using both collision models: the original bug that started this discussion was: you can pickpocket keys from AI from two places in the map.

 

I'm still trying to think if removing the frob-box from bound items will create problems in some cases. What happens for swords or other items attached to an AI? And is the frobbox restored when the item gets "unbound"?

This doesn't happen for things the player picks up, but it might be for things theAI can drop, like the lantern?

The frob boxes for things attached to AI are always in the wrong place, so removing them shouldn't cause any problems. No, I haven't added code to recreate the frob boxes when an AI drops an item. I can if we think it's needed.... I couldn't think of any realistic circumstances where we'd want that to happen, although as I say that I can imagine a TDM dev in 10 years saying "I found the bug! frob boxes get destroyed on binding but not recreated when unbinding!".

[Tels]

It's adjustable using the "size" spawnarg. Personally I think keys should be a bit less easy to steal than they are -- the CM is half the size of the AI that's carrying the key! -- but I won't start a campaign about it

You are right, I meant "it might be _easily_ adjustable" with a hint of "maybe we should look into it"

 

I hadn't spotted that... Although, at least some of the code must be using both collision models: the original bug that started this discussion was: you can pickpocket keys from AI from two places in the map.

Right, as soon as I hit post, it occured to me that some code must always use the frobbox, but other code not, or even it checks both of them in some order. (Oh the joys of speculating without reading the code

 

The frob boxes for things attached to AI are always in the wrong place, so removing them shouldn't cause any problems. No, I haven't added code to recreate the frob boxes when an AI drops an item. I can if we think it's needed.... I couldn't think of any realistic circumstances where we'd want that to happen, although as I say that I can imagine a TDM dev in 10 years saying "I found the bug! frob boxes get destroyed on binding but not recreated when unbinding!".

Hm, yeah, any case where:

 

* the AI drops an item the player can pick up

* the item has a CM that is smaller than the frob-box

 

I can only imagine that a mapper might make custom prop items, and force the AI dropping it (by scripted scene?) and then the player can't pick it up anymore.

 

Just removing the definition of the frob-box on the prop-keys would not fix this issue, however, as then you would still get at frobbox at 0,0,0 if the mapper defines one for his custom item.

 

 

Oh, and that reminds me.. I did have a custom chain+ring made for the Swift demo level, consisting of two entities bound to each other. The newest version is only one entity, but that would be one of these special cases - you have one special entity bound to another (not nec. AI, think "button + elevator").

 

The "real" fix would be to always move the frob-box with the bound item. It would be more costly, but void any such side-effects. I'm all for the optimization, but we really should see if it doesn't have unintended consequences. (I trust you to think them through

Edited May 18, 2015 by Tels

[Tels]

Addendum:

 

This is something that occured the last time I looked into that, but I forgot it in the meantime:

 

The frob-box is seemingly located in absolute terms in the world, and not moved if the item is bound to something, but moved if the entity moves on its own.

So, wouldn't it be easier to define the frob-box as "relative to the current world-origin of the entity", and then everytime it is used, to compute its current extends?

 

That's certainly less work then to keep the frob-box updated all the time, just to query the actual box when the frob occurs. Frobbing events occur much less often than "entity origin moved" events. Might speed up everyting up a tiny bit, not having to update the hundreds of frob-boxes every frame.

 

Edit: And another micro-optimization: If the CM is a box AND the box is larger than the frobbox, remove the frobbox after on entity spawn.

Edited May 18, 2015 by Tels

[SteveL]

Oh, and that reminds me.. I did have a custom chain+ring made for the Swift demo level, consisting of two entities bound to each other. The newest version is only one entity, but that would be one of these special cases - you have one special entity bound to another (not nec. AI, think "button + elevator").

 

The "real" fix would be to always move the frob-box with the bound item. It would be more costly, but void any such side-effects. I'm all for the optimization, but we really should see if it doesn't have unintended consequences. (I trust you to think them through

Thanks. Happy to confirm that the Swift Mazes example is already covered. The frob box gets destroyed only if the bind master is an animated entity like an AI. From the bugtracker:

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.

 

The frob-box is seemingly located in absolute terms in the world, and not moved if the item is bound to something, but moved if the entity moves on its own.

So, wouldn't it be easier to define the frob-box as "relative to the current world-origin of the entity", and then everytime it is used, to compute its current extends?

 

That's certainly less work then to keep the frob-box updated all the time, just to query the actual box when the frob occurs. Frobbing events occur much less often than "entity origin moved" events. Might speed up everyting up a tiny bit, not having to update the hundreds of frob-boxes every frame.

I don't think that could work... There's a chicken-and-egg problem. Frob boxes have to be independent of their parent entity, because they help the game identify which entity the player is looking at. So you don't know which frob boxes need to be "used" in a frame until you know which frob boxes are in the player's line of sight that frame, which you don't know until you know the world coords of every frob box.

[DeusXIncognita]

It's adjustable using the "size" spawnarg. Personally I think keys should be a bit less easy to steal than they are -- the CM is half the size of the AI that's carrying the key! -- but I won't start a campaign about it

It might be helpful to be a bit more consistent though.

I was often thinking why it seems easier to steal a key than a purse, much easier, and that is the answer it seems.

(I don't think one would hang a key so loose to ones belt that it can easily be taken, cause then its easy to accidentally loose too, so it should be similar in difficulty with purses, I think)

[Scampada]

I was often thinking why it seems easier to steal a key than a purse, much easier, and that is the answer it seems.

(I don't think one would hang a key so loose to ones belt that it can easily be taken, cause then its easy to accidentally loose too, so it should be similar in difficulty with purses, I think)

 

I don't think so, a key is lighter so it's easier to steal... its owner won't notice it's missing... just grab it and cut off the belt. A purse weights more, and it's harder to steal it unnoticed. So to steal a purse is harder than a key.

[Destined]

The stolen purse might get noticed quicker, but it is easier to steal, because it is bigger. With a small key you have to get pretty close and maybe have to fumble around to get it loose (or cut off). As mentioned before, the key is unlikely to be dangling on a cord on the belt (aas the purse is more likely to be), but is maybe tucked into the belt. This makes it more difficult to steal.

[Tels]

I don't think that could work... There's a chicken-and-egg problem. Frob boxes have to be independent of their parent entity, because they help the game identify which entity the player is looking at. So you don't know which frob boxes need to be "used" in a frame until you know which frob boxes are in the player's line of sight that frame, which you don't know until you know the world coords of every frob box.

 

Rats!

[SteveL]

I'll put a 10-unit frob box on purses so that they are easier to get from cluttered desks and chests.

We could make keys a bit harder if people want by reducing their enormous collision cube. That's done by a different mechanism than the frob box which is why it works when AI are carrying them around. Here's a pic of a guard with his collision models outlined in red. The huge cube stuck to his right hip is the key he is carrying. You can frob anywhere on that box to pickpocket the key,

 

[Tels]

Am I right that the CM on the prop keys is only used for frobbing, because the key, when bound, is non-solid?

[SteveL]

Am I right that the CM on the prop keys is only used for frobbing, because the key, when bound, is non-solid?

I'm not 100% sure, but I think you must be right. Otherwise he'd never get through a door!

[Springheel]

You can frob anywhere on that box to pickpocket the key,

 

 

 

Hmm, do all key entities have that? I would think a box that size would make it ridiculously easy to frob keys from some distance away, and I can't say I've noticed that.