Cant frob a key after opening a drawer

[Bikerdude]

I'm using the 'writingbureau' prefab and now matter what i try, if I place a key in the secret book drawer, the key wont highlight, yet any other object I place in the locations does.

 

Any idea's or will I have to upload a test map with the problem..?

[grayman]

Key is frobable if you put it on the desktop?

 

Does the key have a collision mesh (green when "Collision surfaces" filter is off)?

[Bikerdude]

• Key is frobable if you put it on the desktop?
  
• Does the key have a collision mesh (green when "Collision surfaces" filter is off)?
  

• Yes, sorta. If I put it anywhere other than on the desk of the bureau it will frob.
  
• yes.
  

[grayman]

• no, this key entity has no CM - would that be the problem..?
  

 

That would be my guess. The frob code can't find a collision mesh to latch onto, so it builds a 10x10x10 box at the first surface it hits, then looks for frobables inside that box. It should be building the box at the bottom of the drawer, but maybe it's not. Also, it could be finding the drawer itself, which is frobable.

 

Examine the kitchen bathroom door in In the North. A note is posted on the door, along with a frob_peer buddy for the note. If the note was a key and the door was a drawer, perhaps adding a frob_peer buddy would let you grab the key. Pay attention to the frob_bias and frob_peer spawnargs.

[Bikerdude]

That would be my guess. The frob code can't find a collision mesh to latch onto.

Sorry, the key does have CM. I edited my post before you replied.

 

I will have to lookup what frob_bias does as that's a new one on me.

[grayman]

If you can't get it working, post a test map and I'll check. I'll look at the code if I need to.

[Obsttorte]

There is a target_setfrobable within the secret book drawer. If you broke the link somehow from the opener to the target somehow, then the things inside the rawer will stay non-frobable even after you openend it.

 

I would suggest that you look if the opener targets the target entity correctly and if the spawnargs on the target entity are set correct. (There is one particular spawnarg, called "start_frobable" IIRC which should be not set or set to zero).

[Bikerdude]

The the target_setfrobable link is there and working, there is a purse and a loot bottle in the same location and they work just fine, its just the key.

 

I have attached a testmap.

frobtest.zip.txt

[Obsttorte]

OK, I took a look at it.

 

It seems that the code changing the frobability is broken in reference to keys. But there is a way you can bypass this. Instead of using a key entity u can use the specific model. Add the spawnarg "frobable" "1" on it. Now, with the key model still selected, go to the stim response editor. Go to the responses tab and add the response "frob". In there, add two effects. The first one is "frob", the target of this effect is the key entity which you should place in your blue room. The second effect is "remove", the target is "_SELF".

 

That's it. You may file a bugreport about this behaviour.

[Bikerdude]

You may file a bugreport about this behaviour.

Thank you Imperious leader!

 

bugtracker: http://bugs.angua.at/view.php?id=3279

[Obsttorte]

... if you want to. Obviously I hit the wrong tone. So let's try this:

 

Go forth and file a bugreport, minion.

[Bikerdude]

Go forth and file a bugreport, minion.

Your wish is my command, your excellency

 

<up your pipe ya tosser>

[grayman]

It seems that the code changing the frobability is broken in reference to keys.

 

Are you planning to fix it?

[grayman]

@Biker, the last two bug reports you filed (3278 & 3279) are TDM bugs, not Dark Radiant bugs. Could you move them from DR to Darkmod?

 

Thanks.

[Obsttorte]

Are you planning to fix it?

I have no idea how. If you can point me to the specific file/class or whatever that handles the behaviour of the target_setfrobable entities, than maybe.

 

Found it.

Edited January 9, 2013 by Obsttorte

[grayman]

Okay, thanks.

 

I thought that since you said the code was broken, you knew where the break was. Fixing it is always a different matter, and I'm trying to find out if I need to look at it.

[Obsttorte]

OK, here is the code that seems to handle things.

 

 

void CTarget_SetFrobable::Event_Activate( idEntity *activator )
{
idEntity *Ents[MAX_GENTITIES];
bool bOnList(false);

// Contents mask:
int cm = CONTENTS_SOLID | CONTENTS_CORPSE | CONTENTS_RENDERMODEL | CONTENTS_BODY | CONTENTS_FROBABLE;

// bounding box test to get entities inside
GetPhysics()->EnableClip();
int numEnts = gameLocal.clip.EntitiesTouchingBounds(GetPhysics()->GetAbsBounds(), cm, Ents, MAX_GENTITIES);
GetPhysics()->DisableClip();

// toggle frobability
m_bCurFrobState = !m_bCurFrobState;

for (int i = 0; i < numEnts; i++)
{
	idEntity* ent = Ents[i];

	// Don't set self or the world, or the player frobable
	if (ent == NULL || ent == this || 
		ent == gameLocal.world || ent == gameLocal.GetLocalPlayer())
	{
		continue;
	}

	if (ent->spawnArgs.GetBool("immune_to_target_setfrobable", "0")) 
	{
		continue; // greebo: per-entity exclusion
	}

	if( m_bCurFrobState )
	{
		// Before setting something frobable, check if it is on the
		// list of things we set un-frobable earlier
		bOnList = false;

		for( int k=0; k < m_EntsSetUnfrobable.Num(); k++ )
		{
			if( m_EntsSetUnfrobable[k] == ent->name )
			{
				bOnList = true;
				break;
			}
		}

		if( bOnList )
			ent->SetFrobable( m_bCurFrobState );
	}
	else 
	{	
		// setting unfrobable
		if( ent->m_bFrobable )
		{
			m_EntsSetUnfrobable.AddUnique( ent->name );
			ent->SetFrobable( m_bCurFrobState );
		}
	}

// Uncomment for debugging

	idStr frobnofrob = "not frobable.";
	if( m_bCurFrobState )
		frobnofrob = "frobable.";

	DM_LOG(LC_MISC,LT_DEBUG)LOGSTRING("Target_SetFrobable: Set entity %s to frob state: %s\r", Ents[i]->name.c_str(), frobnofrob.c_str() );

}
}

 

 

 

// Before setting something frobable, check if it is on the

// list of things we set un-frobable earlier

 

I don't understand this part. When the target is activated, it looks what it has done last time via

the variable m_bCurFrobState and then makes everything frobable or not frobable (except some exceptions).

So, I don't really understand the purpose here. Another thing is that the m_EntsSetUnfrobable list does

not seemed to be cleared after frobability change has taken place.

 

So IMHO the lines that changes the frobability should look like this (in replacement for the for-loop)

 

 

for (int i=0;i<numEnts;i++) {
 idEntity* ent = Ents[i];
 if (ent == NULL || ent == this || ent == gameLocal.world || ent == gameLocal.GetLocalPlayer()
   || ent->spawnArgs.GetBool("immune_to_target_setfrobable", "0")) {
   continue;
 }
 else {
   ent->SetFrobable( m_bCurFrobState );
 }
}

 

 

[Obsttorte]

Just thinking about it again I have a rough idea what may happen here. The m_EntsSetUnfrobable list seems to fit the purpose that only things that were set non-frobable the last time are set frobable this time. I'm not sure why this is needed, maybe if a mapper creates overlapping target_setfrobable entities.

 

So I'm just thinking loud. This method is called upon map start to set everything within its borders to non-frobable. The key created by Biker therefore would be non-frobable now. This part works. What if, for any unknown reason, the name of the key gets changed afterwards. I know this sounds silly, but to me it seems that this is the only way why the code ignores the key.

 

Has any behaviour in this direction ever been noticed?

 

A simple fix would be to just delete the lines considering the m_EntsSetUnfrobable list. If the only purpose of this is the above mentioned, then I think we can lay the responsibility to the mapper. But it may be a good idea to ask the person who wrote this what the real purpose is or to just find out what happens to the key (or its name).

[Bikerdude]

@Biker, the last two bug reports you filed (3278 & 3279) are TDM bugs, not Dark Radiant bugs. Could you move them from DR to Darkmod?

I thought i had filled them correctly, soz. Ok looking at the report screen I spotted the option to switch between TDM & DR. However I cant seem to see how I change a ticket from DR to TDM....?

 

Can someone who has higher priv's than me change them over or will I have to close the existing tickets and create new ones..?

[grayman]

Can someone who has higher priv's than me change them over or will I have to close the existing tickets and create new ones..?

 

Sorry, I didn't realize we can't move issues back and forth between TDM and DR. That sucks.

 

Unless someone has a problem with it, I suggest creating two new issues for TDM and simply referring them to the existing DR issues, w/o having to retype everything. Then stick a note in the DR issues saying they aren't DR issues after all.

[grayman]

Just thinking about it again I have a rough idea what may happen here. The m_EntsSetUnfrobable list seems to fit the purpose that only things that were set non-frobable the last time are set frobable this time. I'm not sure why this is needed, maybe if a mapper creates overlapping target_setfrobable entities.

 

So I'm just thinking loud. This method is called upon map start to set everything within its borders to non-frobable. The key created by Biker therefore would be non-frobable now. This part works. What if, for any unknown reason, the name of the key gets changed afterwards. I know this sounds silly, but to me it seems that this is the only way why the code ignores the key.

 

Has any behaviour in this direction ever been noticed?

 

A simple fix would be to just delete the lines considering the m_EntsSetUnfrobable list. If the only purpose of this is the above mentioned, then I think we can lay the responsibility to the mapper. But it may be a good idea to ask the person who wrote this what the real purpose is or to just find out what happens to the key (or its name).

 

I'll take a look at what's happening behind the curtain.

[grayman]

Preliminary finding is that when the target_set_frobable entities are creating their individual lists of what they're controlling, the key somehow gets put on the list belonging to the drawer beneath it, and not on the list of the hidden space behind the "book door".

 

So when you frob open the hidden "book door", the purse and two bottles are set frobable, but the key is not, because it doesn't belong to that list.

 

To prove what's happening, I removed the drawer's target_set_frobable and was able to frob the key.

 

Since the key is outside the drawer's bounds, I'm now looking at how the target_set_frobable entities determine what to put on their list.

 

And I found this comment:

 

" List of the names of entities previously set unfrobable

This list is maintained to avoid accidentally setting anything frobable

that was not frobable before it went in the brush

Only ents that get added to this list will become frobable."

 

So if the player moves something that can be frobbed, but is currently unfrobable, into that space, the target_set_frobable entity won't inadvertently make it frobbable when toggled.

 

@Biker:

 

Your OP says the key was in a drawer. Was that your original problem, or was the key always behind the "book door"?

[Obsttorte]

Preliminary finding is that when the target_set_frobable entities are creating their individual lists of what they're controlling, the key somehow gets put on the list belonging to the drawer beneath it, and not on the list of the hidden space behind the "book door".

This is very odd. How can this happen? (And what exactly do you mean with the drawer beneath it? Isn't the target entity the only thing here creating such a list?)

" List of the names of entities previously set unfrobable

This list is maintained to avoid accidentally setting anything frobable

that was not frobable before it went in the brush

Only ents that get added to this list will become frobable."

This is odd either, as the most cases in which this entity is used is to avoid the player to frob something through a wall or so. If, for example, you use the drawer without this entity, you are able to frob the key and the loot trough the closed "book door"

Your OP says the key was in a drawer. Was that your original problem, or was the key always behind the "book door"?

This happens with other key entities, too. The strange thing is, that if you use a key model instead, everything works as suppossed to be.

Edited January 9, 2013 by Obsttorte

[grayman]

The root cause of the problem is that the key is using a default frobbox_size of 10, which pushes the boundary of the key down into the target_set_frobable below.

 

This lets the target_set_frobable in the drawer think the key is w/in its boundary, so it places the key in its list.

 

The purse and bottles don't have the problem, because they don't use frobbox_size, so the code uses their collision boundaries instead. Their boundaries don't extend down into the drawer, so they aren't picked up the same way the key is.

 

You can pick one of two solutions:

 

1 - set the frobbox_size spawnarg on the key to zero. The code will then use the key's collision boundary size.

 

2 - if you don't plan to put any frobable objects in the drawer beneath the key, delete the target_set_frobable brush inside that drawer and remove the spawnarg reference to it on the drawer entity itself.

 

I tested both solutions and they both work.

 

No code changes are needed.

 

Once you pick a solution and test that it works for you, please close the bugtracker issue as a "non problem".

[grayman]

This is very odd. How can this happen? (And what exactly do you mean with the drawer beneath it? Isn't the target entity the only thing here creating such a list?)

 

The drawer has its own target_set_frobable brush, which makes a list for its own use.

 

This is odd either, as the most cases in which this entity is used is to avoid the player to frob something through a wall or so. If, for example, you use the drawer without this entity, you are able to frob the key and the loot trough the closed "book door"

 

Yes, it's highly unlikely that "things that should not be made frobable" get placed inside a target_set_frobable by the player. But whoever wrote the original code must have been worried about it.

 

This happens with other key entities, too. The strange thing is, that if you use a key model instead, everything works as suppossed to be.

 

Correct. My guess is that the key entities all have a default frobbox_size of 10, whereas if you make your own entity and give it the key model, there's no frobbox_size spawnarg, so the collision mesh gets used instead, preventing the problem.