Siege Hoth "Lift Exploit/Bug"

[ensiform]

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]

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]

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]

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]

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]

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]

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]

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

[ensiform]

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]

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.