func_static renaming makes it dissapear

[sparhawk]

I think I found a bug.

 

I created a patch, and a brush. The patch I copied and rotated and fit it to the other end of the brushcylinder. Then I converted these three objects to a func_static. Now when I go into the entity editor and click on name it has the default generated name func_static_1. When I changed that name the entity dissepears. I also saved it to disc and looked into the map, but it was nowhere to be found.

 

I think I found the reason. Apparently a func_static, that is converted in such a manner doesn't really have a model, so it associates the name with the model. Now when I changed both, the name and the model, then it was back again.

 

I don't know if this is possible, but I think in such cases it would be good if the editor would automatically replace both entries, instead of only the one.

[greebo]

That's a known issue (http://bugs.angua.at/view.php?id=263), and I even had a go at it once, but my solution didn't work out.

 

I'm afraid this can't be solved on a low level (the Doom3Group class itself), but I have another idea that would involve the Entity Inspector, which could catch "name" key changes of func_statics.

[sparhawk]

Yes, that't what I meant where it should be implemented. I'm just not sure if you can reliably detect such a specific "brush" entity from some other entity which has a real model assigned and the name is just the same as the model.

[greebo]

It is of course possible to detect them, because if it weren't possible we wouldn't have func_statics at all. If a mapper has a "real" model and assigns the same "name" == "model", it's his own fault.

 

The problem with my first solution attempt was that if I changed the model key accordingly at low-levels, some nasty Callbacks were triggered which had unwanted side-effects.

 

Tackling this on a high-level is not exactly cool, because this algorithm shouldn't be implemented there - but if I can't think of any other solution, this would be the way to go.

[OrbWeaver]

What about the idea to have a "name changed callback" on the Doom3Group along with the usual model changed callback? Or was this what you tried and it didn't work?

[greebo]

The problem is that both the "name" and "model" keys already have callbacks and start to interfere. I already tried to disable the callback temporarily to be able to change the "model" key without interference, but this broke the func_statics on map load (the spawnargs are set in no specific order and there were cases where the func_static wasn't recognised any more).

 

This whole design that func_static can be used for "real" models and for static world geometry is pretty cumbersome in the editor.

[OrbWeaver]

Oh yeah, I see what you mean. If "model" has to update "name", and "name" has to update "model" they will go into an infinite loop .

[greebo]

Yes, and if I intercept the callback, it might be that nothing gets changed at all - this is what happened during map load. I really hate those callbacks.

[OrbWeaver]

Can you put in a mutex, e.g.

 

bool _blockCallbacks;

 

in the class definition, and then

 

// Name callback
{
if (!_blockCallbacks && currentName == currentModel) {
	_blockCallbacks = true;
	setModelKey(newName);
	_blockCallbacks = false;
}
}

// Model callback
{
if (!_blockCallbacks && currentName == currentModel) {
	_blockCallbacks = true;
	setName(newModel);
	_blockCallbacks = false;
}
}

[greebo]

That's what I tried, but this broke the map loading somehow. It's of course possible that I forgot something - I'll have to look into that again, I guess.