[sarysa]

Originally Posted by friagram The thing about crouch jumping is you are supposed to jump and then hold crouch (or if you have a macro, possibly both at the same time). It makes no sense to crouch and then press jump a moment later, that's just bad form (and the only way that would trigger that mechanism)

That wasn't what I was doing. Also, I couldn't have been. If you're crouching, you can't jump. (this also goes for the state where you're exiting or entering a crouch)

[Chdata]

No I don't mean nerfing air-strafing. I mean making a dash ability that works differently from normal super jump.

[sarysa]

Hrm.

I've made a lot of charge-like abilities over the last 10 months, but I've never locked the user's yaw on land. I don't really like to do it either because it's a bit of a jarring experience. It works well in water because water is essentially 3d movement with very little influence by gravity:
https://www.youtube.com/watch?v=gON6Rdpo18E

There's another rage:
https://www.youtube.com/watch?v=Au6WsxmyzY4
after Valve broke the conga I had to come up with some replacement that users wouldn't hate. So it does velocity pushes instead of movement and all the users do is move their mouse. I don't force their eye angles in any way, but I do internally keep track of where their yaw *should* be (versus current eye angles) and use that determine where to push the rocks, not the client's eye angles directly.

The point of that tl;dr is that some things can create very bad user experiences, and messing with the user's yaw speed can easily be of them. If that's a client variable you're proposing setting, I won't want to code that at all...what if the user disconnects?
If it's a server feature, it'd just be awkward as hell. Correcting one axis will cause the other axis to stutter since players can't move their mouse perfectly up and down...

(and yes, I'm of the opinion that chargin' targe is a bad user experience the way it's handled...but I've seen modders do much worse)

The other thing I'm concerned of is, how would it differ from demopan's rage or a super jump? I've made charge abilities on land that push the user without locking their yaw. It all happens so fast that people can't really air strafe it. (unless the cooldown is low and they spam it) Other than that, demopan charge seems to handle ground needs and super jump handles air needs...

edit #284: Have you tried clearing the player's WASD keys on the server side while charging? Can't air strafe without WASD, though the client may have more control over the ability to air strafe than the server in that regard...

[Chdata]

No, I also disagree with setting eye angles. But iirc you can set the player's movetype to other things too ... might help with your problems with gravity.

Also I don't see how setting a client variable and handling disconnect logic is hard. Just check IsClientInGame?

Imo chargine targe is just fine. The only problem with it is that you can't easily do that (afaik) without keeping the demo scream / particle trail.

Editing buttons with onplayerruncmd is worse than setting client variables.

Though now that I think of it, setting their view entity should be just fine, if you set the player's angRotation too. The player dashing won't be able to see any jitteriness in their player model when their view is locked by another entity. Unless they're in thirdperson, I guess.

[xXDeathreusXx]

Originally Posted by Chdata Imo chargine targe is just fine. The only problem with it is that you can't easily do that (afaik) without keeping the demo scream / particle trail.

Off-topic-but-sort-of-not fun fact: Any class can charge, and they make the demo scream and have the particles, but if you make another class charge they cannot stop, while demo will eventually, shield or not.

[sarysa]

Setting the view entity has the side effect of stopping the music, though. I originally had it with Pip Squeak (one of the demos I showed you) and then rejected it for that reason alone.

My concern with setting client variables is that they might leak beyond the session. IsClientInGame() will be too late to correct this. Maybe Valve patched this problem but in retrospect, one or two servers I visited maybe two years ago caused me this very problem -- something they did leaked across multiple servers.

BTW, I'm pretty sure setting eye angles is what Valve does with the chargin' targe...I'm basing this on it having the same jerkiness as mods that do the same.

[friagram]

But any player can be made to democharge, i do it all the time...

[Chdata]

But it plays that demo scream + particle effect. I mean I guess the scream can be blocked.

Also, I think you can get around setting the view entity by playing the music centered on that entity. I noticed that when you do something like

EmitSoundToClient(szSound, SOUND_FROM_PLAYER); (snd from plyr is default), and you change the view entity, the sound is then centered on the player entity itself, and you can hear music fade in/out depending on how far your new view entity is.

So, perhaps playing the sound originating from the view entity can fix that.

Originally Posted by xXDeathreusXx Off-topic-but-sort-of-not fun fact: Any class can charge, and they make the demo scream and have the particles, but if you make another class charge they cannot stop, while demo will eventually, shield or not.

So TFCondDuration_Infinite (-1.0) won't make demo charge forever, and TF2_RemoveCondition won't stop other classes from charging? Weird.

And other classes don't stop when they hit a wall? And setting a time of 5.0 on Addcond will still be infinite for other classes?

[xXDeathreusXx]

Originally Posted by Chdata So TFCondDuration_Infinite (-1.0) won't make demo charge forever, and TF2_RemoveCondition won't stop other classes from charging? Weird. And other classes don't stop when they hit a wall? And setting a time of 5.0 on Addcond will still be infinite for other classes?

First part is correct, demo will eventually stop, however RemoveCondition stops classes, and no, you continue to charge running into a wall as any other class, it's quite funny because your turning slowly grinding against the wall trying to escape it

IIRC, making the charge last a split second was the workaround for an infinite charge, aswell as being able to reduce rage per charge

[sarysa]

Originally Posted by Chdata EmitSoundToClient(szSound, SOUND_FROM_PLAYER); (snd from plyr is default), and you change the view entity, the sound is then centered on the player entity itself, and you can hear music fade in/out depending on how far your new view entity is. So, perhaps playing the sound originating from the view entity can fix that.

That might work, but it's beyond my scope...since it's breaking sounds that originate from FF2. (and on my home server, every boss has multiple tracks...with much praise laid upon the soundtrack)

Guess it's not beyond your scope, since VSH is yours now. ;)