Ghost Questions

I'm taking a look at it, and Moof, I'm wondering if you can shed some light on a few things before I really get into it, so I have some questions:

1. Would it be possible during the end of wave check to instead of deghost someone where ever they are, to actually teleport them to their destination first?

2. If that's possible, then why can't we set up either a timer that would time out, give up, and teleport them to their destination if ghost was taking a long time for some reason?

3. You recently said that ghost uses some sort of distance check to decide when to drop the person off, and that, due to lag or something, this check could fail and there was no "distance to dest is actually increasing rather than decreasing" check. Is it not possible to put this check in ourselves and then, should it start to occur, give up and teleport the ghoster to his destination?

I'm looking at some of the code in Mysterial's ArtifactTeleport and I'm finding it amazingly simple when compared to ghost (or more accurately DruidGhostInv). I was wondering why one could not utilize something like Instigator.SetLocation() (or perhaps whatever code works for the translocator) to stop ghost and put someone somewhere if we could put code into ghost to check for "problems".

Any of those three things is easy to implement. And, as a matter of fact, I never thought of simply moving the player to their destination after a time out. I was trying to redo the whole darn thing from scratch instead.

Actually, what I was trying to do before I got too busy at work to do anything at all was make the player run to their destination without ever leaving the world. Meh. It's doable by replacing the player controller with a bot-type one and using the bot's movement functions to run over. But I never got it working.

Your money spots for these changes are Tick() and ReviveInstigator() in DruidGhostInv. In pseudocode, Tick() does:

if (I'm disabled) return;
if (I should not revive player) return;
else revive;

and the size comparative is:
VSize(Instigator.Location - RevivePoint) > VSize(Instigator.Velocity) * deltaTime

Other Ghost bugs to fix, in DruidGhostInv GiveTo:
Random revive point selection does not work, and it always picks a start point (first section)
POV should reset itself to player's default upon ghosting
Player.bFire and bAltFire should be forced to False upon ghosting

And, if you're feeling REALLY adventurous, the movement functions need to be recoded to project the player in an absolutely straight line and move them faster and slower. Setting PHYS_Hover will help. A warning, however: if the player moves too fast, they will ALWAYS "miss" the unghost point.

For reference, this is what the original Tick in DruidGhostInv looks like:
Code:

function Tick(float deltaTime)
 {
 	if (bDisabled)
 		return;
 	// if the game will reset in a few seconds give up immediately so the Controller/Pawn don't get screwed up
 	if ( Level.Game.ResetCountdown != 3 && VSize(Instigator.Location - RevivePoint) > VSize(Instigator.Velocity) * deltaTime
 		&& (!Level.Game.IsA('Invasion') || Invasion(Level.Game).bWaveInProgress || Invasion(Level.Game).WaveCountDown < 14) )
 	{
 		//refresh Instigator velocity to counter air friction
 		Instigator.Velocity = Normal(RevivePoint - Instigator.Location) * (Instigator.AirSpeed + Instigator.AirSpeed * 0.5 * OwnerAbilityLevel);
 		if (Instigator.HasAnim('HitL'))
 			Instigator.PlayAnim('HitL',,0.1);
 		return;
 	}
 	ReviveInstigator();
 }

This is what I propose we change it to - I can commit as soon as we have some kind of consensus:
Code:

function Tick(float deltaTime)
 {
 	if (bDisabled)
 		return;
 
 	TotalTime = TotalTime + deltaTime;
 	// BF: Okay, we're adding this to hopefully stop bugs where people zip past
 	// their RevivePoint and keep going.  Our previous distance should always be
 	// larger.  If it's not, fix that.  Also put a time limit on it.
 	if (PrevDist < VSize(Instigator.Location - RevivePoint) || TotalTime > 8.0 * (4 - OwnerAbilityLevel))
 	{
 		Warn("Set location to RevivePoint - either timed out or distance question.");
 		// I'm thinking we'll avoid other bugs by setting it to zero.
 		PrevDist = 0.0;
 		// This should teleport the ghoster.
 		Instigator.SetLocation(RevivePoint);
 	}else
 	{
 		PrevDist = VSize(Instigator.Location - RevivePoint);
 	}
 	// if the game will reset in a few seconds give up immediately so the Controller/Pawn don't get screwed up
 	if ( Level.Game.ResetCountdown != 3 && VSize(Instigator.Location - RevivePoint) > VSize(Instigator.Velocity) * deltaTime
 		&& (!Level.Game.IsA('Invasion') || Invasion(Level.Game).bWaveInProgress || Invasion(Level.Game).WaveCountDown < 14) )
 	{
 		//refresh Instigator velocity to counter air friction
 		Instigator.Velocity = Normal(RevivePoint - Instigator.Location) * (Instigator.AirSpeed + Instigator.AirSpeed * 0.5 * OwnerAbilityLevel);
 		if (Instigator.HasAnim('HitL'))
 			Instigator.PlayAnim('HitL',,0.1);
 		return;
 	}
 	// Well, we should already be there, but if for some reason we're not,
 	// Say, like the end-of-wave stuff is in effect:
 	Instigator.SetLocation(RevivePoint);
 	ReviveInstigator();
 }

What these changes do:

First, there's a global variable keeping track of the Total Time passed. If that time exceeds 24, 12, or 8 seconds (dependent on Ghost Level) Instigator is teleported to RevivePoint. It shouldn't be possible for the code to think that the player needs to go another Tick as a Ghost.

Second, there's a check on the distance between where we are and where we are going. If the distance we were previously is actually smaller than now, we have to assume we've gone past our RevivePoint and need to get back to it. So, again, we're teleported there. The rest of the code can work out the details.

Finally, there's an additional SetLocation command, mainly there to take care of the end of wave/round cases, where the Instigator may not be anywhere near his RevivePoint, but Ghost has decided to terminate anyway.

Now, I'm all for rewriting this so that the coding is more efficient or elegant, but right now this is the brute force fix (but not yet committed).

I haven't looked at the other bugs that Moof mentioned - only the issues with failing to pop up in the place that you're supposed to.

The only thing I've been able to test (by changing the 8 to a 1) was the timeout. But I can tell you it's a little disorienting to suddenly pop up where you were headed, especially when you probably aren't 100% sure where that is. Dunno if there's anything that can be done about it though.

Comments?

This should do it a bit more elegantly (note that TotalTime and PrevDist are initialized during the GiveTo):
Code:

function Tick(float deltaTime)
 {
 
 	TotalTime = TotalTime + deltaTime;
 	if (bDisabled)
 		return;
 
 	// if the game will reset in a few seconds give up immediately so the Controller/Pawn don't get screwed up
 	if ( Level.Game.ResetCountdown != 3 && VSize(Instigator.Location - RevivePoint) > VSize(Instigator.Velocity) * deltaTime
 		&& PrevDist > VSize(Instigator.Location - RevivePoint) && TotalTime < 4.0 + (4.0 * (4 - OwnerAbilityLevel))
 		&& (!Level.Game.IsA('Invasion') || Invasion(Level.Game).bWaveInProgress || Invasion(Level.Game).WaveCountDown < 14) )
 	{
 		PrevDist = VSize(Instigator.Location - RevivePoint);
 		//refresh Instigator velocity to counter air friction
 		Instigator.Velocity = Normal(RevivePoint - Instigator.Location) * (Instigator.AirSpeed + Instigator.AirSpeed * 0.5 * OwnerAbilityLevel);
 		if (Instigator.HasAnim('HitL'))
 			Instigator.PlayAnim('HitL',,0.1);
 		return;
 	}
 	// Well, we should already be there, but if for some reason we're not,
 	// Say, like the end-of-wave stuff is in effect:
 	Instigator.SetLocation(RevivePoint);
 	ReviveInstigator();
 }

It hasn't really been tested this way yet. If no one has a problem with it, I'll give it a perfunctory test and then commit it. Modified the timeout; it's now 16, 12, or 8 seconds. If someone wants to debate/demand that the equation for the timeout be something different, it's not hard to change ...

The timeout will be somewhat disorienting, but welcome, on vinv and ons maps. That's my first thought.

It all sounds good to me.

The only other thing I thought of is that when someone ghosts, it may be worth switching off any artifacts they have active.

Artifacts and Weapons, as Moof noted.

I'll work that through and see what kind of code changes I can come up with. In the meantime, I'll commit this to CVS.

I have committed additional fixes that should cover:

Zooming (but not vehicle death ghosting)
Artifact Deactivation
Weapons Fire

No guarantees - some of those aren't easy to test (mainly weapons fire).

Moof wrote:

The timeout will be somewhat disorienting, but welcome, on vinv and ons maps. That's my first thought.

Well, technically we could just eliminated it, assuming that the "passing the revive point" bug is fixed. I just threw it in there for the heck of it, really.

Dru can let me know to go ahead and remove it, modify it, or just take it out himself.

Thing is, *something* I think is needed (even if it's something like 25, 20, 15) for maps like Seasons.