InstaGhosting - mainly to replace comments in code

The URL for this post will appear in a comment in the code.

InstaGhosting I'm guessing is related to the distance check. It's still occurring (yeah, HoboJoe wasn't hallucinating - most occurred with Titan rocks with me to).

So, even after the change to correct for the possibility of Tick being called close after GiveTo that PrevDist == CurrDist, I'm guessing one of two things:

1. PrevDist is popping up as 0 somewhere, or
2. The knockback from certain deaths is registering to the point that the GiveTo establishing PrevDist ends up with the player being farther away during the Tick than PrevDist says they're supposed to be.

So, I'm adding a few checks:

1. PrevDist must not be 0 for the PrevDist part of the if statement to be evaluated.
2. The TotalTime must greater than 2.0 seconds for the PrevDist statement to be evaluated.

Finally, though it might result in more logging than we'd like, I'm going to go ahead and stick some debugs in - if PrevDist < VSize(Instigator.Location - RevivePoint), it will write the values of those things and TotalTime.

Is it possible it has something to do with being in the air? Maybe switching the players physics to walking prior to looking for the nav point would help?

That might make the solution more elegant. I think we've realized by now that most of my code is hammer based, rather than scalpel.

I'll take a look at it when I have a mind to - this has become quite the lazy Sunday so far.

TheDruidXpawX wrote:

Is it possible it has something to do with being in the air? Maybe switching the players physics to walking prior to looking for the nav point would help?

That's already done.

Brain's a bit fried; all I can do now is wait until an epiphany or 209 to see if there's something that could clue me in to what's happening, if my fixes don't fix the problem.

On the other side of things, if the bug does appear fixed in 209, I have some ideas for 210:

1. Set up configurable variables: BaseTime, TimeMultiplier, and change the timeout equation to: TotalTime < BaseTime + (TimeMultiplier * (4 - OwnerAbilityLevel)) so that we can tweak the values to length or shorten ghost in INI. I just don't want to muck with it yet if instaghost occurs and the debug lines report something odd like "TotalTime = 45" which should never happen.

2. Since we have code that will account for passing the destination that would appear to be working at that point, I would think of changing the velocity equation so that, if it would take the player more than the established time period to get to the destination under the base velocity, we "speed them up" so that they arrive at the destination at the end of the timeout. This would help avoid the "still a bit disorienting" quality of the "not yet there? Teleport!" situation we have now.

I just moved the initialization of "PrevDist" to after the PHYS_Flying and Velocity setting line. The reasons for doing so make my brain hurt (and involve a lot of "it's not really going to fix case x, only case y, neither of which should be happening" ) so I won't go into them.

Perhaps now would be the time to recode Ghost, as we've previously discussed. We have discussed several versions of this in the past.

I propose that we set ghost skins, teleport the player to their destination, hold them for a set number of seconds (15, 10, 5?), and then revive them.

That would keep it "ghost" while solving all of the travel issues that have been the bane of the ability since the beginning.

Should we decide to go this route, I'll code it.

Moof wrote:

Perhaps now would be the time to recode Ghost, as we've previously discussed. We have discussed several versions of this in the past.

I propose that we set ghost skins, teleport the player to their destination, hold them for a set number of seconds (15, 10, 5?), and then revive them.

That would keep it "ghost" while solving all of the travel issues that have been the bane of the ability since the beginning.

Should we decide to go this route, I'll code it.

I like your idea better than when I had it coded as resurrection. You can call me sentimental, but it just doesn't seem as fun as floating through the map.

I propose perhaps a hybrid, keeping it much like it is now the way Bot has been playing with it, but if it determines it's too long and wants to insta spawn the player, instead we hold them in a ghost state where they're going to spawn for 5 seconds so they can get their bearings?

What are everyones thoughts on that?

TheDruidXpawX wrote:

I like your idea better than when I had it coded as resurrection. You can call me sentimental, but it just doesn't seem as fun as floating through the map.

I propose perhaps a hybrid, keeping it much like it is now the way Bot has been playing with it, but if it determines it's too long and wants to insta spawn the player, instead we hold them in a ghost state where they're going to spawn for 5 seconds so they can get their bearings?

What are everyones thoughts on that?

Sounds like a plan - gimme a day or two and I'll have it in CVS.

I'll be learning a bit about water while I'm working on this ... just to see if I can figure out how to stop someone on land from drowning.

Okay. There should be:

- Water fixes in (cross fingers)
- Configurable Variables such as:
-- TOBase (default 4.0) a float establishing the base seconds for the Timeout
-- TOMulti (default 4.0) a float establishing the level based multiplier
-- TOWait (default 2.0) the number of seconds a timed out ghoster will wait after being moved to their destination

So, in theory, this is what's going to happen, should someone be very far away (depending) from their destination:

A Ghost 3 ghoster will go for 8 seconds, teleport to destination, and wait 2 seconds before being able to move. Ghost 2 - ghost for 12, wait 2. Ghost 1 - ghost for 16, wait 2.

I figure 2 seconds is just enough time for someone to look around and go "Oh crap, titans in my spawn point" before they revive and get smooshed.

Hey, something occurred to me ... and considering what it is, it's odd for me to suggest this but ...

If someone *does not* time out with their ghosting, there is no delay in respawn - if they get there before the time out, they should just pop right out (if I've coded it right, which we'll see).

Do we want to be nice and give them the two seconds? Or do we want to just say "You should have been paying attention."