I'm not really going to describe it so as to not teach more people how to do it, i will give razor the fix when he gets back and anyone else who wants it, just not publically.

Lathain Valtiel

07-14-2006, 10:30 PM

Just to check, which elevator are we talking here? I wasn't aware if this was doable on the droid elevators, I've not seen it used there.

ensiform

07-14-2006, 11:35 PM

i just did it their earlier and it seems to do the same thing only not as harsh as the big elevator. also i opened up the sample map and it uses the same style of triggering as the big one that is. its not a matter of elevator, its a matter of if the lift is triggered by a trigger_multiple / once that uses the spawnflags 4 (USE_BUTTON) and prolly FIRE_BUTTON as well. basically what i did was added a new int to gentity_t and when someone "fires" the lift with their use key. it will set the new int to level.time + 5000 (5 seconds) so that there is a 5 second delay. then it does a loop, and checks for all trigger_multiple entities that target the same lift, and sets their delay as well. so that you cannot have somebody sitting on top of lift and below the lift. i hope you don't start a war though with this because truely it is a bug. and just suz you know, the delay is set per lift not per client.

trigger_multiple [spawnflags&4] -> lift

Lathain Valtiel

07-15-2006, 12:05 AM

Is this delay set to the elevator itself, or to the use of the buttons in question?

I'm asking because if there's a noticable delay in the elevator going back... yeah.

I'm not going to argue on whether ot not it's a glitch since frankly I'm not sure either since I REALLY doubt Raven intended to make it possible to lock up elevator entry, especially if like in the droid case it's the only path in question. The fact that it requires great timing and isn't easy to do adds to this suspicion.

ensiform

07-15-2006, 12:43 AM

well its set to the button trigger. and its not necasarrily a delay, it just blocks the stuff from being called, the lift still works fine.

I think I know what you're talking about. But isn't this a pretty hair trigger issue to fix? If some lifts move faster than the debounce, it's going to make the button free slow, right? Could we maybe redesign the code to make the lifts move to the called position after completing their current move? That would be more realistic behavior compared to the real world.

ensiform

07-18-2006, 02:03 PM

no, not really. they already do. its just the triggers seem to interupt it whereas other things do not. besides the fact that hoth is the only map that has this type of trigger->mover thing i think it is fine.

razorace

07-18-2006, 03:58 PM

Well, could we have the trigger do a position scan on the mover before sending the use event?

ensiform

07-18-2006, 06:03 PM

i dont understand why bother doing this? a delay is fine. and i think you might want to rewrite your last post i couldnt understand half what you said. what would the position of the lift matter anyway?

razorace

07-19-2006, 11:21 AM

Err, the problem is with the trigger overriding the standard check that prevents the lift from switching directions in mid-movement, right? Why not just add that check to the triggering entities?

My concern with a delay is that it might interfer with normal lift operation at some point. Like maybe with the Korriban Blue Crystal lift. Sorry, I don't mean to sound overcritical, I'm just trying to come up with the best solution possible. :)