Latest posts for the topic "Ghost velocity"

Ghost velocity

Moof — GMT

Dru, this afternoon while we were lazily floating across the big ONS maps, you mentioned that you would have to do something about Ghost in the large map gametypes. I got an idear. In DruidGhostInv.uc, here's the money line (124): Code:

Instigator.Velocity = Normal(RevivePoint - Instigator.Location) * (Instigator.AirSpeed + Instigator.AirSpeed * 0.5 * OwnerAbilityLevel);

It shouldn't take too much codewise - just some trial and error testing - to add in a distance calculation, like Code:

VectorVictor *= VSize(RevivePoint - Instigator.Location);

Unfortunately, I can find next to no darn documentation on Actor.Velocity. Either my Google Fu is weak or it's just a mystery to all but the master UnrealScript coders. ;) I added a Log() line to the GhostInv to check things out, but I can't really understand the numbers with no reference. But along this track, we should be able to scale Ghost's movement speed not only for its AbilityLevel but also for the distance moved. It would even be possible to lock Ghost to a timeframe - Ghost 1 takes 15 seconds to get wherever it's going, where Ghost 3 takes 5 no matter the distance.

Re:Ghost velocity

TheDruidXpawX — GMT

I'll accept patches ;)

Re:Ghost velocity

Moof — GMT

It's not possible. Not from what I can see. There appears to be a limit on the magnitude of velocity vectors, at least from the experimenting I've done. At a velocity vector magnitude of 1, it takes 93 seconds for a player to move 1000 units. At magnitude 660 (the default for Ghost 1 when a player is using it), it takes about 2.5 seconds. At magnitude 65535, it takes about 2 seconds. So...yeah. Bad juju :(

Ghost velocity

KohanX — GMT

Did you try other numbers aside from 65535, or just jump straight to the max? There's got to be a way to do this.

Re:Ghost velocity

Moof — GMT

I spent about 3 hours testing this, working out numbers, writing down units traveled and time spent traveling, trying to find some correlation between them. There just flat out doesn't appear to be one. It's consistent, that's for sure, but distance traveled:time traveled doesn't scale in a linear fashion. I was excited when my rough numbers showed that at vector magnitude 660, ~5000 units = ~10 seconds, ~1000 units = ~2 seconds and ~23000 units = ~45 seconds. I was all about that, seemingly a near 500:1 relationship. But then I changed the velocity. Yes, Ghost 2 and 3 move faster than Ghost 1. But not that much. Really, the way the game calculates it (Pawn.AirSpeed + .5 * Pawn.AirSpeed * GhostLevel) where AirSpeed = 440 for players, it seems like there would be some sort of tie in to the physics engine for air resistance and the like. The code even has a check for that. But it really doesn't make much difference either. Overall, it was a really frustrating few hours of testing, measuring, and tweaking, only to say "forget it" and create that test case where RevivePoint = Instigator.Location + vect(0,0,1000) and start tweaking the velocity vector magnitude. Once I saw that it scales in such an extreme manner - the difference in effect between 1 and ~500 appears to be greater than the difference between 500 and infinity - I gave up.

Re:Ghost velocity

Flak Monkey — GMT

How about making 1 more level in this ability and make it instant like the teleporter artifact? It is frustrating to ghost, even at lev 3 accross a large ONS map. Most of the time I reach the random point, the wave is over and I missed out on a lot of carnage.

Re:Ghost velocity

Moof — GMT

I must say after doing this study that the Unreal 2 physics engine is FAR more detailed than I had thought it was. The best part is I can do max damage with redeemers now ;) In answer to your question, that's certainly doable and actually fairly simple. It'd be up to Dru and Shan to put it in (or not) tho.

Re:Ghost velocity

TheDruidXpawX — GMT

So I'm confused. Did you figure out a solution Moof, or did you run into trouble with the velocity thing?

Re:Ghost velocity

TheDruidXpawX — GMT

Oh! I think I see what you're talking about... you might want to look at the velocity code in RW_Knockback to see how I figured out how to do it. Somehow you have to modify the length of the vector, as in the case of movement, a Vector works differently than a location.

Re:Ghost velocity

Moof — GMT

Dru, great! I'll check into using the momentum physical property. Also: right now, ghost appears to iterate through a lengthy "find the spawn point" process. If it fails to find a viable RevivePoint, it falls back to assigning a random spawn point as the RevivePoint. In my experience, it pretty much always takes me to a spawn point. Would you consider eliminating the RevivePoint discovery process and defaulting to a random spawn point? You'd be looking at eliminating 37 lines of code looped potentially 1000 times PER GHOST.

Re:Ghost velocity

TheDruidXpawX — GMT

It's better if it doesn't find a spawn point first, as it will find a point closer to the player. I'm not sure why it's always doing the spawn point thing right now.

Re:Ghost velocity

Moof — GMT

I FOUND THE "GHOSTING OUT OF THE WORLD" BUG. Working on it.

Re:Ghost velocity

Moof — GMT

TheDruidXpawX wrote:

It's better if it doesn't find a spawn point first, as it will find a point closer to the player. I'm not sure why it's always doing the spawn point thing right now.

Dru, there's two ways to handle that. One, trying to fix the find a random RevivePoint code. Two, picking a random point off LevelInfo.NavigationPointList.

Re:Ghost velocity

Moof — GMT

Moof wrote:

I FOUND THE "GHOSTING OUT OF THE WORLD" BUG. Working on it.

Status: Here's the money line. Code:

VSize(Instigator.Location - RevivePoint) > VSize(Instigator.Velocity) * deltaTime

What happens is on the rare occasion that someone's framerate is low, or something else strange happens like a lag burst, the game can actually "miss" when the ghost is supposed to stop. In that case, the velocity never changes, and the player keeps moving in a straight line forever. There are several ways to handle this. I'm not sure what's best, to be honest. Right now, I have it set so that Code:

if (10000 * deltaTime) < (player's distance from revive point) {move player to revive point and RevivePlayer()}

That works on my system, but it's still possible to skip past it. So, perhaps we could build in a sanity check for delta player distance increasing. It's all about making a call on granularity vs. looks. If you set it so that you'll never ever ever have the slightest chance of the revive point getting "missed" in this way, you'll have players jumping around/warping/teleporting near the end of each ghost. But if you set it so that the teleporting never happens, you'll have players missing the revive point. I need to take a break from coding - tomorrow's going to be a really rough day. I'll work on this more later. Also: momentum can only be used when imparting physical impacts between objects. That works well with knockback since you have a bullet/missile hitting something else. With ghosting, you have no imact, so you're restricted to velocity. Velocity is in turn restricted by a player's terminal velocity and physical resistance, even while flying. However! All these problems are solved by using Phys_Hovering instead of Phys_Flying. But with faster ghost speeds, you miss the revive point more often. With no restriction on the AirSpeed of the player, multiplying the velocity by even 10 means that ghost NEVER stops. Ever. Catch 22. ;)

Re:Ghost velocity

BotFodder — GMT

Moof wrote:

What happens is on the rare occasion that someone's framerate is low, or something else strange happens like a lag burst, the game can actually "miss" when the ghost is supposed to stop.

Hmmm ... that's wierd. I was just about to feed you the line "The server is always right and the client shouldn't be able to impact things in this way." That may still be the case, but then I know from what little I've looked at the Ghost code that there's a "disconnect/reconnect" sequence for the player. I guess something around there could get a little wierd - but then you'd think the "ghoster" would see something a lot different from what the rest of the players are seeing ... hmmm. How often is the "Ghosting out of the world" bug occurring on the server?

Re:Ghost velocity

Moof — GMT

BotFodder wrote:

How often is the "Ghosting out of the world" bug occurring on the server?

Increasing the speed of the floating ghost 10x with no other changes to the code results in the bug happening every single time.

Re:Ghost velocity

Moof — GMT

I have recoded the check to see when ghost should end, but now the velocity is wonky, and on long gohsts (ONS) it can miscalculate the destination (though the new movement check accounts for that and compensates, it still shouldn't happen.) Here's the current state of the code, since I've been posting like a madman all darn day and shared nothin'! This is INCOMPLETE CODE and not suitable for testing, let alone production. Changes: -global variables -uses PHYS_Hovering during ghost movement -sanity check with OriginalLocation and RevivePoint being concretely assigned before motion starts -uses new system to check when ghost should end, search on deltaGhostTravel. The variable itself determines how far Instigator is from RevivePoint; the moment it increases (instead of decreases), player is revived.

Re:Ghost velocity

TheDruidXpawX — GMT

Moof wrote:

What happens is on the rare occasion that someone's framerate is low, or something else strange happens like a lag burst, the game can actually "miss" when the ghost is supposed to stop.

I'm not sure that's possible. From my understanding, the client doesn't get to move the pawn at all once it starts ghosting, but rather the server is constantly setting the location. Maybe I'm wrong about this, but I really dont think the client has that kind of control, otherwise it would be easy for somoene to write a hack and control the ghosting pawn. Just because that's not the cause though, your description makes a certain amount of sense. Maybe the server skips a tick because it's busy. Would it be possible to measure the distance between the revive point and the pawn as compared to the original start location, and if the distance is ever greater than the current distance to the pawn, cause them to revive at the revive point imediately? Like I said though, I haven't seen the ghost forever bug in a long long time. I think Mysterial and I fixed the major problem (which involved a physics model other than walking, swimming, or falling) Is this problem still happening and I just dont know about it?

Re:Ghost velocity

TheDruidXpawX — GMT

Moof wrote:

Increasing the speed of the floating ghost 10x with no other changes to the code results in the bug happening every single time.

well that sux. I wonder with the momentum and a lower tick rate on the server, if they never actually hit the revive point, and instead on the next tick simply move past it.

Re:Ghost velocity

Flak Monkey — GMT

I dont know if this is the same bug as mentioned, but on the map CTF-Bridge of Fate, I ghosted either in the cliff of the gorge, or just over it, not on the bridge, and either died from being in the cliff or fell to my death. Anyway, that should not have been a valid spawn point.

Re:Ghost velocity

BotFodder — GMT

Flak Monkey wrote:

I dont know if this is the same bug as mentioned, but on the map CTF-Bridge of Fate, I ghosted either in the cliff of the gorge, or just over it, not on the bridge, and either died from being in the cliff or fell to my death. Anyway, that should not have been a valid spawn point.

Question: Did the wave come to an end while you were mid-ghost? That we're aware of (although I haven't gotten to it and am not 100% sure it's fixable, though I think what we *are* working on is a step in the right direction).

Re:Ghost velocity

Flak Monkey — GMT

Did the wave come to an end while you were mid-ghost?

It was sometime earlier this year or last year sometime, so the details of that instance are sketchy at most. Just remembered that it happend. I've had a few ghosting enomolies in my past, just not recently.

Re:Ghost velocity

Moof — GMT

BotFodder wrote:

That we're aware of (although I haven't gotten to it and am not 100% sure it's fixable, though I think what we *are* working on is a step in the right direction).

The code changes posted above, though ickily buggy still, MAY handle the midwave problem. I have not yet tested it. (It would handle it by teleporting the player to the revive point and immediately reviving them, though I don't yet know if that would handle the two pawn bug seen in Mysterial's original code.) It would certainly handle Flak's situation. Consider: right now, ghost can "miss" its stop point; that also means there's a plus/minus range around the intended stop point. There's a remote possiblity that if the stop point was close to a wall and he overshot it, it would instantly crater him when he revived. The reason I'm so sure this can happen is: during the testing I did with different speeds and physics models, this actually happened once with me, where I cratered halfway in the floor at the bio in Deck 17 while ghosting up from the main lava pit.

Re:Ghost velocity

Moof — GMT

After all that, it's back to the drawing board. I can patch up some stuff, and I REALLY like a modified version of Szlat's resurrection-by-healing thing (it could happen as a normal part of ghost even - the first time you die, you ghost, and the second, you freeze and hope for a ress), but ANY changes to the physics of the ghost (Flying to Hovering, as suggested by Dru) cause the flying out of the world bug to happen every time. Then, if I try to patch it, I start to get really bizarre vectors coming out of nowhere, or the ghost autocratering every time. The only thing I didn't get to is using DrawDebugLine(). Maybe next try. So, I'm giving up for now. Work is getting crazy, and in the time I have I'd rather play instead of spend more hours on this.