Functionality of Func_trains

[Shadriss]

One of the problems I'm working on with my current project (Duel of The Fates, V 2) is the issue with the forcefield timing in the corridor just before the pit room.

 

Me and LDJ have discussed this a few times, and we THINK we have a solution, but we havent had the time to test it out, so I thought I'd ask if this Idea might work, or if there were another way to do it easier.

 

The base problem is that we cannot, so far as we know, have a func_door auto-trrigger every "x" number of seconds. The reason this is important is because of the way we set up those fields, which is thus...

 

WHen door one opens/closes, ,it triggers the next one via a target_delay, which gives a one or two second pause between each beam opening/closing. The trick then becomes how do we trigger the FIRST door.

 

We have a theory, and it uses a pair of Func_trains.

 

What we think will happen is : we create a pair of trtains to ACT as doors, ,each having two points to go between at a high rate of speed. Since we can set delay on those, and they ALWAYS move... we THINK that each time it moves, it would trigger the target_delay, and thus, the whole array of doors.

 

But, we're not sure, and we havent had time to do a test build of it.

 

If you have any informaiton on weither or not his would work, or on an easier way to handle the situation, post here, please. Would make a map that is already great even better. Be a part of the NEW most-downloaded map on the internet. (I think the original still holds that title...)

[Eldritch]

I don't see any reason why it wouldn't work - the theory is sound. Any time the trains move away, it should activate the target delay and thus, the rest of the beams.

 

Can't wait for this map to be completed! Great work guys!

 

-Anakin

[Leslie Judge]

Hmm...

 

Why can not the last door trigger the first through a target_delay with a longer delay than between the other doors? This case you only need to trigger the first door once (for the first time) wich can be made anywhere with a trigger_once. For example you can put a trigger once around one of the spawn points.

 

Does this make sense?

[Shadriss]

Actually, that DOES make sence, Les. Only question I have is this (I'm not too familiar with triggers yet...) : Would simply walking through the trigger cause it to fire? I'm assuming so from what you said, but...

[Toonces]

I'm neither a mapper or a coder but I would imagine you could rig it like any door that opens when you stand in front of it. In theroy it would trigger as soon as the first player spawns

[Shadriss]

I dont use triggers to open my doors, Toonces.

[Toonces]

Oh, ok, like I said, I'm a modeler not a mapper

 

Hides back in 3dsmax

[Leslie Judge]

Yep, when somebody go into or through a trigger (not all of them but most of them) it will fire it's target.

 

If you use trigger_once it will work only for the first time and never ever.

[Shadriss]

Well, then, I'd say that solves the problem, then. SO simple and elegant, yet evasive enough that LDJ didnt think of it HIS first time making this, nor did Raven. Hehe. Thanks much, Les.

[Shadriss]

So nice a solution, ,I should have know something was wrong with it. And I was right - there IS no trigger_once in the MP side! ARGH!

 

So, now I'm back to square one - using func_trains.

 

UNLESS!

 

There is an entity called trigger_always.... do you think that, if this was pointed at a target_delay, it could do the job of the trigger_once?

 

Just a thought, I guess.

[Eldritch]

Trigger_always means that the trigger constantly fires independent of anyone touching it. While this might be good for something like flame bursts in a hallway, it may not be what you want for the doors.

 

-Anakin

[Leslie Judge]

Sorry, Shadriss, I make SP maps.

 

So... I took a quick look, but no info about how often the trigger always triggers it's target. Maybe very often and maybe you can find some detailed info on the net.

 

The point is that it can be good for you trough a target_delay to fire your first door, as would the func_train do. You have to try.

[Shadriss]

Found out the func_train idea wont work either - there's no delay option in MP. *long creative stream of cursing* Man, ,I hope this trigger_always does the trick...

[Shadriss]

That about says it all.

 

I was trtying to implement the func_train idea (and struggling to get it done) when I happened to let my eyes wander for a moment. And they landed on a slightly different function brush... a nifty little thing called (get this...) a Func_Timer.

 

In the entities properties window, the first thing it says is "This should be renamed trigger_timer"

 

Yup, this thing apparently does what I've been asking for! I havent run a test yet (it's compiling while I speak) but if it DOES do what it appears to do, then all we had to do was actually LOOK AT THE LIST OF FUNCs!

 

Isn't that, like, number two on the idiot-check checklist of troubleshooting?

 

I'll let you know the results... but I think I've got it figured out now.

[Shadriss]

One Word :

 

SCHWIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIING!

 

Works BEAUTIFULLY. Just have to adjust the actual timing now. Thanks to all who helped out.

[Leslie Judge]

Fine.

 

So func_ not trigger_ hmm... Very tricky.

[Shadriss]

Yeah I know. Sneaky Buggers....