G_AddEvent doesn't do a thing...

[Eraser]

I've made a target_debrisemitter entity which, when triggered by a trigger_multiple should call G_AddEvent to send an event to the clients but it doesn't work for some reason. The entity should throw out a bunch of debris (kind of like a player that's gibbed spews out gibs and blood). This is my code:

Code: Select all

void target_debrisemitter_use (gentity_t *self, gentity_t *other, gentity_t *activator) {
	G_AddEvent( self, EV_EMIT_DEBRIS, 0 );
}

void SP_target_debrisemitter (gentity_t *self) {
	self->use = target_debrisemitter_use;
}

When I replace the reference to self in the G_AddEvent call with activator, then it does work properly. The debris is emitted from the location of the player. Anyone got any idea what's going wrong?

[VolumetricSteve]

When this entity is being used....is the entity's name spelled correctly? Assuming that all of those functions are passing the right data types around, it looks like it should be ok... is there any way you could have your code output the value of each variable as it runs?

[^misantropia^]

I suspect that the event somehow isn't in your PVS and hence isn't sent. Does it work when you use G_TempEntity()?

[Eraser]

With G_TempEntity it works. What does that tell you?

[^misantropia^]

I get a mention in the credits?

[Eraser]

lol, that will undoubtedly be so. However, it's not very flexible this is it? I can send the event but no arguments whatsoever?

[Eraser]

Having another bit of a problem.
I want to get the origin of an entity that's made out of a brush (or brushes), like func_static. However, it seems these entities don't have an origin (ent->s.origin is 0 0 0) unless you include an origin brush in there.

However, doing so seems to make the whole entity non-solid. Is there an (easy) way of determining the origin of such an entity without the use of an origin brush, and if not, do you know what's up with brushes becoming non-solid because of an origin brush?

[^misantropia^]

lol, that will undoubtedly be so. However, it's not very flexible this is it? I can send the event but no arguments whatsoever?

Not with a one-liner but you can manipulate the temp entity:

Code: Select all

ent = G_TempEntity(origin, EV_MY_EVENT);
ent->s.eventParm = 42;

[^misantropia^]

Having another bit of a problem.
I want to get the origin of an entity that's made out of a brush (or brushes), like func_static. However, it seems these entities don't have an origin (ent->s.origin is 0 0 0) unless you include an origin brush in there.

However, doing so seems to make the whole entity non-solid. Is there an (easy) way of determining the origin of such an entity without the use of an origin brush, and if not, do you know what's up with brushes becoming non-solid because of an origin brush?

What happens if you set "origin" "123 456 789" (or whatever its location) on the func_static? I don't think you need an extra brush here.

[Eraser]

Same thing as when you use an origin brush. I think (haven't checked the code but I think the Radiant documentation states this) that using an origin brush is just a fancy way of setting the origin key. What I don't know, however, is if it's Q3Map that translates the origin brush to the origin key, if the engine does this or if it's handled somewhere in the game code.

[^misantropia^]

I did some digging. q3map2 a) replaces the origin brush with a literal origin key, and b) makes everything with an origin non-solid.

As to the why of b) I've no idea.

[Eraser]

Is there some way for me to override the non-solidness of those entities again?

It's kind of odd, as the entities.def file for Radiant states the following for func_bobbing:
"In order for the sound to be emitted from the entity, it is recommended to include a brush with an origin shader at its center, otherwise the sound will not follow the entity as it moves."

Wouldn't that mean that you end up with a non-solid func_bobbing if you want it to emit sound? Or is there some exception made for func_bobbing in q3map? Quite odd indeed.

[^misantropia^]

Off the top of my head:

Code: Select all

ent->r.contents = CONTENTS_SOLID;
ent->clipmask |= CONTENTS_SOLID;

q3map2 doesn't seem to special-case anything so presumably a func_bobbing with a "noise" key will be non-solid.

[Eraser]

Won't work unfortunately. And I'm beginning to be afraid it's not that simple either. The thing is that it's not entirely non-solid. Movement through the brush is jerky and bullets hit some surfaces of the brush but pass through others. It's like it has some sort of odd clipping that's culled on one side or something.

I've been looking at func_rotating because that does have an origin and is pretty damn solid, but I think that the G_MoverPush function has something to do with it. Perhaps the func_rotating brush is non-solid like a func_static would be, but the player is simply moved by the G_MoverPush function and thus it appears to be solid again.