Thanks in advance for yoru answers!
Brushes with multiple triggers?
Brushes with multiple triggers?
This might sound like a ridiculous question (and probably not phrased as it should, as I'm not really good when it comes to mapping lingo) , but... it is possible to assign multiple triggers to a single brush? For example, is it possible to create a moving teleport? If it is, how do you do it?
Thanks in advance for yoru answers!
Thanks in advance for yoru answers!
Neurotic Conversions - New location: Update your bookmarks!
Re: Brushes with multiple triggers?
You'd need to code something, most likely. I'd start with the code for func_train and then resolve the fact that the target field will be needed by both the train and the teleporter...CocoT wrote:This might sound like a ridiculous question (and probably not phrased as it should, as I'm not really good when it comes to mapping lingo) , but... it is possible to assign multiple triggers to a single brush? For example, is it possible to create a moving teleport? If it is, how do you do it?
Thanks in advance for yoru answers!
I see... does it make it easier if one of the two does not need a target field? The moving teleporter was the example I had in mind, but, in fact, I'm more looking for a brush that would be moving but, when you step in it or throw something in it, it also does something to that particular object... Will this also need to be managed on the code side?
I mean the "what happens to it" has already been coded as a specific trigger, I was wondering if I could combine the two in a map editor.
And I should probably be less cryptic and let you know that what I'm working on is a trigger that destroys the translocator of Transloquake when shot through with it. I was wondering if I could make that brush move.
I mean the "what happens to it" has already been coded as a specific trigger, I was wondering if I could combine the two in a map editor.
And I should probably be less cryptic and let you know that what I'm working on is a trigger that destroys the translocator of Transloquake when shot through with it. I was wondering if I could make that brush move.
Neurotic Conversions - New location: Update your bookmarks!
Most likely you'll want a code solution. I can't think of any way to accomplish this with the stock Quake entities. Unless you can stack one entity inside of another. I think Quark allowed this but I don't know how it resolved it in the compiler or game.
Now, it has to be said that two triggers *CAN* share the same bsp model, but they will still appear as two separate instances of the same brush. For example, in code you can say newmis.model = plat.model (which ends up being "*4" or something similar) and newmis will look like the platform. However, moving the platform doesn't move newmis and moving newmis won't move the platform.
One easy QC solution might be to have your trigger (that destroys the object thrown in) point to the object it should follow (using .target or some other field). In code you make sure it links to the other object. Then it sets the destroyer trigger to MOVETYPE_FOLLOW so it automatically follows its target around. If you can't assume MOVETYPE_FOLLOW is supported by the player's engine, then you can always do it the manual way with a think function setting its origin every frame or 0.1 seconds. Because you're working with BSP models there's some weirdness there with setorigin, but since they're both BSP models (presumably) it should work without problems.
I think I understand what you're trying to do, but I might not. I hope my suggestion is helpful to you.
Now, it has to be said that two triggers *CAN* share the same bsp model, but they will still appear as two separate instances of the same brush. For example, in code you can say newmis.model = plat.model (which ends up being "*4" or something similar) and newmis will look like the platform. However, moving the platform doesn't move newmis and moving newmis won't move the platform.
One easy QC solution might be to have your trigger (that destroys the object thrown in) point to the object it should follow (using .target or some other field). In code you make sure it links to the other object. Then it sets the destroyer trigger to MOVETYPE_FOLLOW so it automatically follows its target around. If you can't assume MOVETYPE_FOLLOW is supported by the player's engine, then you can always do it the manual way with a think function setting its origin every frame or 0.1 seconds. Because you're working with BSP models there's some weirdness there with setorigin, but since they're both BSP models (presumably) it should work without problems.
I think I understand what you're trying to do, but I might not. I hope my suggestion is helpful to you.
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
Yes, you totally nailed it, I think
I could feel editors didn't really make it possible, but I wanted to check. I think I'll either go with coding a kind of hybrid brush code (something that would combine the two) or play around with a think function, as you suggested.
Great! Thanks guys
I could feel editors didn't really make it possible, but I wanted to check. I think I'll either go with coding a kind of hybrid brush code (something that would combine the two) or play around with a think function, as you suggested.
Great! Thanks guys
Neurotic Conversions - New location: Update your bookmarks!
In vanilla Quake, a 'moving' teleport could theoretically be done in a semi-hacky way. For example by placing several teleporters in line with unmarked and non-moving buttons on the floor and thin invisible (skip-textured) func_trains blocking all but one of them.
However, since it's for a mod anyway, you can do it in much cleaner (and versatile) ways.
However, since it's for a mod anyway, you can do it in much cleaner (and versatile) ways.
Hehe... yeah, I tried to do it on the code-side and well, didn't realize it would be so easy. I'm not used to play around with button.qc and/or plats.qc, but they're quite transparent. So it works now! (not the moving teleport thingy, which I'm not really interested in (I might still add it, though), but the translocator-destroying moving brush ... this is going to create some interesting possibilities!...)
... this is going to create some interesting possibilities!...)Neurotic Conversions - New location: Update your bookmarks!