PDA

View Full Version : Siege Hoth "Lift Exploit/Bug"


ensiform
07-14-2006, 05:40 PM
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, 09: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, 10: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-14-2006, 11:05 PM
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-14-2006, 11:43 PM
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.

gentity_t...

int buttonUseTime;

TouchMulti (touch function for trigger_multiple)

if ( self->spawnflags & 4 )
{//USE_BUTTON
gentity_t *found = NULL;
if ( self->buttonUseTime > level.time )
{//anti-lift lame hack
return;
}

if( !( other->client->pers.cmd.buttons & BUTTON_USE ) )
{//not pressing use button
return;
}

if ((other->client->ps.weaponTime > 0 && other->client->ps.torsoAnim != BOTH_BUTTON_HOLD && other->client->ps.torsoAnim != BOTH_CONSOLE1) || other->health < 1 ||
(other->client->ps.pm_flags & PMF_FOLLOW) || other->client->sess.sessionTeam == TEAM_SPECTATOR ||
other->client->ps.forceHandExtend != HANDEXTEND_NONE)
{ //player has to be free of other things to use.
return;
}

if (self->genericValue7)
{ //we have to be holding the use key in this trigger for x milliseconds before firing
if (g_gametype.integer == GT_SIEGE &&
self->idealclass && self->idealclass[0])
{ //only certain classes can activate it
if (!other ||
!other->client ||
other->client->siegeClass < 0)
{ //no class
return;
}

if (!G_NameInTriggerClassList(bgSiegeClasses[other->client->siegeClass].name, self->idealclass))
{ //wasn't in the list
return;
}
}

if (!G_PointInBounds( other->client->ps.origin, self->r.absmin, self->r.absmax ))
{
return;
}
else if (other->client->isHacking != self->s.number && other->s.number < MAX_CLIENTS )
{ //start the hack
other->client->isHacking = self->s.number;
VectorCopy(other->client->ps.viewangles, other->client->hackingAngles);
other->client->ps.hackingTime = level.time + self->genericValue7;
other->client->ps.hackingBaseTime = self->genericValue7;
if (other->client->ps.hackingBaseTime > 60000)
{ //don't allow a bit overflow
other->client->ps.hackingTime = level.time + 60000;
other->client->ps.hackingBaseTime = 60000;
}
return;
}
else if (other->client->ps.hackingTime < level.time)
{ //finished with the hack, reset the hacking values and let it fall through
other->client->isHacking = 0; //can't hack a client
other->client->ps.hackingTime = 0;
}
else
{ //hack in progress
return;
}
}
self->buttonUseTime = level.time + 5000;
while ( (found = G_Find( found, FOFS(classname), self->classname )) != NULL )
{ // find the other trigger_multiples with the same target (multiple trigger_multiples that "fire" the same lift.
if ( found == self ) continue;
if ( Q_stricmp(found->target,self->target) ) continue;
found->buttonUseTime = level.time + 5000;
}
}

razorace
07-16-2006, 10:55 PM
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, 01: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, 02:58 PM
Well, could we have the trigger do a position scan on the mover before sending the use event?

ensiform
07-18-2006, 05: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, 10: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. :)