func_pushable going in wrong direction

[catalyst]

hi,
i'm almost done with my func_pushable code. got a small cube in my map that i can push and it moves... just in the wrong direction. i used the self.enemy.angles attribute to copy the angles to the cube and something is wrong with the angles.

Code: Select all

self.enemy = other;
newdest = self.origin + 4*normalize(self.enemy.angles);

SUB_CalcMove (newdest, 10, pushable_stopped);


any idea, how to make the angles proper?

[frag.machine]

Code: Select all

self.enemy = other;
newdest = self.origin + 4*normalize(self.enemy.angles);

newdest = newdest + '0 180 0';

SUB_CalcMove (newdest, 10, pushable_stopped);


Or something like that should do the trick.

[catalyst]

Nope. It just moves the cube 180 units away. I tried adding it to the angle instead

Code: Select all

newdest = self.origin + 4*normalize(self.enemy.angles + '0 180 0');


...but it still moves in wrong direction. Maybe different angles? I'm trying diff combinations like '270 90 0', '90 90 0' with no effect :/

[MauveBib]

Try

newdest = self.origin - 4*normalize(self.enemy.angles);

[catalyst]

No, I think it has something to do with the point vector vs. angle vector. Cuz newdest is the destination point I pass to the Sub_CalcMove function to move my cube to that point. But, I calculate the destination by adding angles to my origin, instead of adding vectors derived from angles to my origin.

I'm looking for a function that would convert my angles (pitch, yaw, roll), especially yaw, to an XYZ vector to add to the origin.
so...

Code: Select all

//instead of
newdest = self.origin + 4*normalize(self.enemy.angles);

//should probably be something like
newdest = self.origin + dist * AngsToPosition(self.enemy.angles);


I've looked through the Quake-C Built-in functions guide but didnt find anything. Only functions converting position vectors to angles.

[catalyst]

hah! i figured it! :D

Code: Select all

dir = normalize(self.enemy.velocity); //gets direction from player's velocity vector (velocity indicates player's direction)
newdest = self.origin + dist *dir; //destination point

SUB_CalcMove (newdest, 10, pushable_stopped);


Just gotta fix the Z direction so the cube doesnt get pushed into the ground when the player jumps on it.

[catalyst]

Alright, the next problem...

How do I apply gravity and collision with other objects to the pushable cube? I want it to drop off edges and be carried by elevators etc...

Any simple way to copy the code from another entity?

[Spirit]

I think you should take a look at Gyro.
http://quakematt.quakedev.com/gyro.php

[catalyst]

Alright, any idea how to make a simple pushable object in Gyro? :P
...or do I need to register at their forums to ask this question? :D

[Spike]

SUB_CalcMove is a function for items with MOVETYPE_PUSH only.
MOVETYPE_PUSH items are doors/platforms/etc stuff that push other things.
Their movement ignores the world and other MOVETYPE_PUSH objects. This means if you're telling them to move via SUB_CalcMove then they're just going to move through things and never stop on top of them.
Simply put, PUSH cannot touch PUSH.
You would need to use an object which is not MOVETYPE_PUSH (thus not SOLID_BSP either).
What you can do is make it SOLID_BBOX and MOVETYPE_STEP, and call walkmove on it whenever the player bumps into it.
Note that walkmove can recurse, and can result in boxes walking into boxes, but coding that properly is likely to be tricky, so ignore box touching box events.
The walkmove builtin will allow you to push up steps. If you clear the onground flag before calling it, you can push it over edges, and it'll fall down due to gravity (but won't topple over the edge, just suddenly drop when far enough over).
It will sit on moving platforms moving with them, but will not sit on other pushables (so players might get a bump on their head if they try. Because walkmove uses traceboxes, the size of the pushable should be one of the standard hull sizes (you can get away with making it look shorter, but you won't be able to push it through holes that are too small for the hull size).

[Wazat]

Never normalize angles, they are distinctly different from directions and velocity.

If you want to turn an angle into a direction, do this:

Code: Select all

makevectors(self.enemy.angles);
newdest = self.origin - 4*v_forward;


makevectors will turn angles into 3 directions: v_forward, v_right, and v_up. When you're working with a player, you can also use makevectors on his .v_angle to tell where he's looking, not just where his model is pointed.

There's a small bug/weirdism where .angles_x and .v_angle_x are reversed, but you don't need to worry about that for what you're doing here.

Another (probably better) option for pushing your box:

Code: Select all

newdir = normalize(self.origin - self.enemy.origin); // direction from them toward me
newdest = self.origin + 4*newdir;


This will always push the box away from the object touching it, no matter what direction they're facing when they bump into it. So if they back into the box it won't respond by going through them; it'll go away from them. This is probably the solution you want.

I hope that helps!

[Wazat]

Ninja'd by Spike.

I also recommend you use MOVETYPE_STEP and SOLID_SLIDEBOX (or BBOX, don't know how important the difference is).

However, you can move such objects by applying velocity and removing the FL_ONGROUND flag each frame. It may work extremely well to do both methods: apply half the movement with the walkmove code, and the other half with velocity. Walkmove doesn't cause walking objects to touch each other (so walking monsters never touch each other, right?), but velocity will, so your boxes can bump into each other with the hybrid system.

I may be able to provide some rough code examples for this later today. In the mean time I need to go to work.

Cheers!

[Spike]

walkmove triggers triggers. I don't think it triggers solids.
The problem with using velocity to touch other boxes to get them to move is that you're not sure how much it moved beforehand. A tiny tiny velocity is perhaps sufficient in order to get the thing to be touched without being weird.

The problem with most pushables is that pushing against them deflects the player's movement along the plane of the slower-moving pushable. This can be annoying. Make sure the player moves only as much as the thing they are pushing, if they're pushing anything.

[frag.machine]

Nope. It just moves the cube 180 units away. I tried adding it to the angle instead

Code: Select all

newdest = self.origin + 4*normalize(self.enemy.angles + '0 180 0');


...but it still moves in wrong direction. Maybe different angles? I'm trying diff combinations like '270 90 0', '90 90 0' with no effect :/

Ouch, I knew there was something wrong on that.
/me makes note to self: do not try to help in coding when you're too sleepy and/or too drunk.
/me slides slowly and ashamed to the shades

[goldenboy]

Hipnotic and Nehahra have pushables.