Page 2 of 2
Posted: Tue Jul 20, 2004 4:44 pm
by BirdsofaFeather
I did a lot of experimenting with this. My first real problem was actually dealing with the type of siege weapon I made. I made a trebuchet, with a swinging net that launches the rock. I tried many different combonations of vectors and for a while was frustrated because the rock always seemed to move in the same direction: straight backword. It took a long time before I realized that the rock was actually hitting the net as it swung out and bouncing backward. So to correct this I simply had the rock move partway to the set of waypoints I'd created earlier, and then I turned on physics with the velocity. And that worked. I had to use something other than forward vector however, because for some reason forward vector still sent it straight backward. So basically I just used one of the waypoints that I had binded to the trebuchet as an origin point. My code ended up looking like this:
Code: Select all
$treb_rock[local.anyrocknum] unbind $treb_net
$treb_rock[local.anyrocknum] time .25
$treb_rock[local.anyrocknum] moveto treb_way2
$treb_rock[local.anyrocknum] rotateXdown 360
$treb_rock[local.anyrocknum] waitmove
$treb_rock[local.anyrocknum] moveto treb_way3
$treb_rock[local.anyrocknum] rotateXdown 360
$treb_rock[local.anyrocknum] waitmove
local.vec = ($treb_way4.origin - $treb_rock[local.anyrocknum].origin) * 20
$treb_rock[local.anyrocknum] physics_on
$treb_rock[local.anyrocknum] physics_velocity ( local.vec )
It still works this way when I rotate the trebuchet because the $treb_way4 is bound to it. I'm still experimenting with the speed, I'm trying to find out the velocity equivilant of 2000 units per second. That's how fast my rock is supposed to go. Thank you all who posted for all the help.
Posted: Tue Jul 20, 2004 8:49 pm
by BirdsofaFeather
Ok, one last question. If the velocity you set really is the change in origin over 20 game frames, does that mean that the speed could potentially change depending on how the individual's fps is? Since I have my rock moving at 2000 units per second through the waypoints until I turn on physics, I'd like to calculate exactly how much to multiply the velocity value to mimic this speed.
Posted: Tue Jul 20, 2004 9:42 pm
by bdbodger
You better read my script again . For one thing did you make your machine so that forward was facing 0 in the editor? If you did then you can use the forwardvector of the machine . Also it is not change in origin over 20 game frames it is change in origin over 1 game frame * 20 . so 2000 is a change in origin of 100 since 100 * 20 = 2000 and 1 game frame is about .2 seconds I understand but maybe longer than that . That is a very small distance . You also have to unbind it before you set the physics on and set the velocity . Useing the forwardvector of the machine gives you direction so the rock will go forward provideing you did as I said and made the machine face 0 when made in the editor. It may help to make part of your machine notsolid so the rock will not hit it and bounce back .
Posted: Wed Jul 21, 2004 4:14 am
by BirdsofaFeather
Yes bd, my weapon was actually already facing 0 before I made this post, so I did not have to move it. Forward vector still made the rock go straight backward, but that was not a problem. If I wanted to I could still use forward vector, I would just use a negative multiplier (ie * -20). The problem was the rock hiting the net and bouncing back anyway. I could potentially make the net nonsolid, I had not considered that before. But either way, I could use forward vector or a waypoint, it doesn't really matter. Either way works, and with the waypoint, I also wouldn't be limited to facing the weapon toward 0, I could bind the waypoint to the weapon and face it any way I want. This is what I've used for a different weapon of mine that faces an odd direction. I'll try making the net nonsolid, that's good idea. Thanks for the info on the speed again. I think it might be somewhat different than that however. I've been experimenting, and right now, I have my waypoint set up so that when the weapon is pointing toward 0, local.vec = (500 0 0) * 8. This is the closest I've been able to simulate 2000 units per second just by observation. So basically, I have a change in origin of 500, take that * 20, then * 8 for the multiplier, over 1 game frame, according to your model.
That's 80000 units per game frame, which if a game frame is .2 seconds, is 400,000 units / second. I know the rock isn't moving 400k units per second, so there must be some other factor involved. I'll keep experimenting and see if I can come up with the closest multiplier to use. Thanks for all your help sofar.
Posted: Wed Jul 21, 2004 6:19 am
by bdbodger
local.vec = (500 0 0) * 8
so 500 x 8 = 4000 devide that by 20 you get 200 units per game frame and if that is .2 seconds that some people seem to think then that is 1000 units per second . I guess my post was not clear .
what I said was
Also it is not change in origin over 20 game frames it is change in origin over 1 game frame * 20 . so 2000 is a change in origin of 100 since 100 * 20 = 2000 and 1 game frame is about .2 seconds
also my test a while ago seem to indicate that gravity was mesured with 1 being normal gravity so if I had used $crate gravity .5 the crate would have gone farther before hitting the ground .
Posted: Thu Jul 22, 2004 12:10 am
by BirdsofaFeather
Ahh cool. I think I found it just by experimenting, not sure if .2 seconds is really a game frame or not, but whatever. Making the net notsolid did the trick, I can't believe I didn't think of that before. Thanks for all your help.