|
Post by quakeulf on Mar 29, 2016 19:24:30 GMT -5
I have been looking all over for this but I haven't been able to find anything.
I want the same effect as id used in their map "security", but I haven't been able to work out how to do this. I think there are some func_timers and target_relays involved to control the lasers, but I don't know anything more.
So what I want is for a laser to fire for X seconds and not fire for Y seconds, and that one laser fires after the other in a loop.
Please help me with this.
Thank you all very much in advance for helping me out.
|
|
|
Post by knightmare on Mar 30, 2016 1:26:11 GMT -5
Target_lasers toggle when targeted. If you want two lasers to binary toggle, where either laser A is or or laser B is on but not both, you can give them the same targetname and set the START_ON spawnflag for one of them.
BTW, the moving lasers in that map target invisible func_train entities, probably ones that have an origin brush, and maybe made of a hint or skip brush or monsterclip brush, something that won't be visible. Be careful not to use too many laser/func_train pairs, as all brush models count toward stock Q2's limit of 255 models.
BTW, you can extract the map (maps/security.bsp) from Quake2's pak0.pak file and look at it in a text editor (the text section near the end) to find out the entity relationships in the map.
|
|
|
Post by quakeulf on Mar 30, 2016 7:23:41 GMT -5
Weren't you one of those Quake3World-forumgoers?
But the core of my issue is that I want the lasers to behave like this:
Active X seconds, inactive Y seconds, active again for X seconds, inactive for Y seconds (looped)
I have tried looking at the MAP/BSP-scripts but I don't understand that much about how they work for these kinds of things yet.
|
|
|
Post by knightmare on Mar 30, 2016 16:00:36 GMT -5
You can use a func_timer with a wait of X+Y that targets the target_laser to turn it on and a trigger_relay (same targetname as the laser) with a delay of X to turn it off again.
|
|
|
Post by quakeulf on Mar 30, 2016 16:25:43 GMT -5
I'm afraid that did not work.
I set a func_timer with a time of 4 to target the laser and the relay which had a delay of 2, but nothing happened.
|
|
|
Post by quakeulf on Mar 30, 2016 17:43:24 GMT -5
I'm trying to figure out a way to do this now and I have made the game crash in wonderful ways ("ED_Alloc: no free edicts" for this, lol), and also I had to restart my PC since everything hung.
|
|
|
Post by knightmare on Mar 31, 2016 16:43:23 GMT -5
You can try setting the wait (pulse cycle duration) and delay (on duration) keys for the laser if you have the Lazarus mod installed (included with KMQuake2). I can't think of how it was done in that map if using a trigger_relay won't work. You should try decompiling it with bspc if you want to figure out the implementation there.
|
|
|
Post by quakeulf on Apr 1, 2016 21:32:59 GMT -5
You can try setting the wait (pulse cycle duration) and delay (on duration) keys for the laser if you have the Lazarus mod installed (included with KMQuake2). I can't think of how it was done in that map if using a trigger_relay won't work. You should try decompiling it with bspc if you want to figure out the implementation there. Well, I had to give it up for now. Maybe later. ;_;
|
|
|
Post by sP1Sp0pD on Apr 10, 2016 6:12:39 GMT -5
Did you read Panjoo's old tutorial on lasers? Particularly, there is example.map with four of different kinds of uses of target_laser (and func_timer) which you might find helpful to study.
|
|
|
Post by quakeulf on Apr 16, 2016 3:24:37 GMT -5
Did you read Panjoo's old tutorial on lasers? Particularly, there is example.map with four of different kinds of uses of target_laser (and func_timer) which you might find helpful to study. I did, but it didn't help with the main issue: Having X time off and Y time on.
|
|
|
Post by sP1Sp0pD on Apr 22, 2016 10:21:16 GMT -5
knightmare is right, trigger_relay is the way to go. It works because several relays can share the same targetname which can be targeted from e.g. func_timer, and you can emulate independent on and off times by using different delay values of those relay entities (note that you need two relays). I'm attaching a simple map, laser2.map (5.69 KB), which has a laser that is turned on after 4 seconds into the game, fires for 3 seconds and sleeps for one (3 + 1 = 4). It can probably be optimized further by removing initial X+Y delay. What's more interesting, however, is that apparently security.bsp (aka Grid Control) implements this differently, by using trigger_always -> trigger_once -> trigger_multiple -> ( n * trigger_relay) -> target_laser chain. I've tried to play around with it, but most likely didn't find correct spawnflags, got bored, and stopped. It would be nice to figure out how exactly this approach works though.
|
|
|
Post by quakeulf on Apr 23, 2016 5:39:42 GMT -5
If only the setup had been described in detail then I would have known how to have done this earlier, but the laser2.map-setup was one of the things I didn't try because the trigger_relay without a delay seemed a bit superfluous to me. All that should be needed is one timer to control another with different timings.
Maybe I can use this for my next map, then. :3
|
|
|
Post by sP1Sp0pD on Apr 23, 2016 9:56:17 GMT -5
> ... trigger_relay without a delay seemed a bit superfluous to me. All that should be needed is one timer to control another with different timings.
I'm afraid that's too technically vague for me to give substantive commentary. Can you show us how exactly (well, more or less) those two timers should look like, in your opinion? And why would trigger_relay without a delay be superfluous? Relays are used for one-to-many distribution of events; optional delay is completely orthogonal to this (although no doubt very handy).
After giving it more thought I am now more inclined to believe that func_timer approach is suboptimal here. Also, my earlier analysis of those triggers in security.bsp was inconclusive. Eventually I've come up with the following (working) triggers for a laser parametrized by X (on time), Y (off time), Z (initial delay aka phase shift, may be zero):
// laser entity skipped; assumed to be initially OFF (starton = 0) ... { "classname" "trigger_always" "target" "mult" } { "classname" "trigger_multiple" "targetname" "mult" "target" "relay" } // this trigger turns the laser ON { "classname" "trigger_relay" "target" "laser" "targetname" "relay" "delay" "Z" } // this trigger turns the laser OFF after X seconds { "classname" "trigger_relay" "target" "laser" "targetname" "relay" "delay" "X + Z" } // this trigger refires the main loop, leaving laser OFF for Y seconds { "classname" "trigger_relay" "target" "mult" "targetname" "relay" "delay" "X + Y" } I hope this is clear enough, so I wouldn't have to upload new version of that laser2.map (tell me if it is not). What's still unclear though is why did they forward initial trigger_always event through trigger_once... Perhaps this is some kind of optimization, as trigger_once is destroyed after being fired?
|
|
|
Post by sP1Sp0pD on Apr 24, 2016 5:54:10 GMT -5
You most likely forgot to set your timer's start_on property (spawnflags = 1), so it never fired. However, this combination still wouldn't work as expected: trigger_relay will trigger first at X+Y+X seconds (as expected), but then continue to trigger every X seconds (that is, not X seconds after every X+Y seconds, just after the first one). With func_timer kicking in (every X+Y seconds), new independent X-periodic trigger_relay loops will be spawned, eventually leading to event avalanche.
|
|
|
Post by quakeulf on Apr 27, 2016 6:01:10 GMT -5
I spent a few hours trying everything I could think of, but apart from the more insane contraptions I can't remember specifics.
But let's say you build up a sufficient array of relays, would it be possible to have the lasers/lights do morse code?
|
|