InsideQC Forums

I noticed that the same alignment problem happens in Portal 2, when you shoot a portal at a slope. So the Source engine is also unable to do it. That's interesting.

I wonder if there are open source car racing games that does this properly.

UPDATE:


Found out my hax to ignore the _y value was not needed because the "self" in the function used happened to be the corpse that was just spawned, not the real client whose image its of. So altered it to self.owner for the makevectors and other relevent places where needed, and that code does work without destructively altering anything. Silly mistake

Heres another screenshot where it happened to work pretty nicely:

Well, it was not an engine issue persay here....just a silly mistake.

Makes me wonder if we could detect slopes on the live player and apply force the opposite direction for moving up a steep slope, and increase it for downward slopes.

Also , I guess we could alter the v_angle (pitch) on the player model to make it look more real...?

mankrip wrote:I noticed that the same alignment problem happens in Portal 2, when you shoot a portal at a slope. So the Source engine is also unable to do it. That's interesting.

I wonder if there are open source car racing games that does this properly.

I decided to try pitcing the player as he walks or runs as per my comment above....as well as trying to match it to the surface angle. BOITH have failed ! lol.
Here is what Im trying with pitching the player as he walks / runs...I had nearly the same code in my BOTAI think and he was bobbing nicely, not even using changepitch builtin either. This time I tried it both directly pumping the change into V_angle_x and also the changepitch builtin , and nothing. I tried stuffing .angles directly instead of v_angle and it seems to work but jittery. Is it better to do this in an animation macro maybe?

Cobalt wrote:Also , I guess we could alter the v_angle (pitch) on the player model to make it look more real...?

[/quote]

Cobalt wrote:Makes me wonder if we could detect slopes on the live player and apply force the opposite direction for moving up a steep slope, and increase it for downward slopes.

normally, the player physics applies gravity and then cancels it out by pushing along the direction of the plane normal, which has the effect of pushing the player sideways, which is how come you slide down slopes in (net)quake. friction prevents it from being fast. remove the friction and you have the slide mod.

you could just directly push the player aligned with the slope's plane, sure, but you'll need to change the maths in order to find your vector along the slope relative to gravity instead of relative to the player's angles.


ssqc can only replace the client's current angles. due to latency, by the time the ssqc's angle change arrives on the client, the client's angles have already changed to something new. the new value gets replaced with something that is based on an older version of the angles, hence why it jitters backwards in time, as it were. what I'm trying to say is basically 'good luck with that'. try csqc, it allows you to separate input, aim, and rendered angles, and without latency between reading+writing.
additionally, any angles ssqc sends are typically limited to 8bit (ie: 256 notches), which is jerky on its own.
additionally, players look stupid when their model is aiming forwards but their rockets are shooting directly upwards/downwards.

Well I was experimenting some more and by chance I merely took the vectoangles of trace_plane_normal in a frame where I am tracelining and saw we could match angles_x somewhat like that if we factor in v_angle. Didnt look good on land but in the water it came out pretty good lookin with the player swim model, so I made a vid:

http://youtu.be/_kAxb0Pkz3M

Just detect .movement (the players keys) and it switches to match the angle of the surface below...

Spike wrote:try csqc, it allows you to separate input, aim, and rendered angles, and without latency between reading+writing.
additionally, any angles ssqc sends are typically limited to 8bit (ie: 256 notches), which is jerky on its own.
additionally, players look stupid when their model is aiming forwards but their rockets are shooting directly upwards/downwards.

Once in a while I see an interesting corpse position as in the screenshot....thanks in part to FRikbot.







As for continuing with some code that more or less would have to I guess set the size down to a scale perhaps smaller than player , and I guess give it a movetype_walk and some velocity to make it slide down that sloping arch - probably not possible in the given envoronment..?