Author Topic: Half Life 1 Weapons Project - Redux  (Read 6521 times)

Super useful stuff. Thanks.

Just so you know %pos appears to be the coordinates where the projectile last hit, and %normal appears to be the which side it was hit on in some kind of vector (shooting the north face of a 16x16 resulted in 0 1 0, shooting the south 0 -1 0, shooting the east 1 0 0, ect)
well wow %normal turned out to be more useful than i thought. i need to test that on players. and as you expect, its a vector. normals are simply vectors perpendicular to a certain surface that have a length of 1, so yes, your guess is right - its displaying the normal of the collided side.

i'd go with glow on the front section but not the bottom part, if that's not too much trouble.

Next big problem is to do with animating.

I'm trying to get the orange cylinder to spin when LMB is held down, but I can't get it to spin at a speed that's independent of the state sequence timeout values. I want it to just spin at a constant speed when charging... preferably without having to do multiple sequences with different animations for each to compensate for the timeout values because that would be really complicated.

Is there a way I can get something to animate at a constant speed independent of the timeout value? Setting the sequence to "cyclic" didn't seem to do anything, it still speeds up and slows down depending on how fast the timeout value is

EDIT: When I set the sequence name to "Ambient" it loops just fine. It's only when I put it in a state sequence that it breaks.
« Last Edit: May 31, 2016, 05:21:27 AM by Rally »

Screw it I just did the math and then set up like 103 keyframes instead, I'll probably make good animations after college exams when I have 400 hours of free time to hand craft a billion individual keyframes and wrap my head around the sequence system

animation example

I made some minor changes to the gluon gun, I smoothshaded the feed tube because IMO it looks really loving nasty flatshaded and I think it looks better but if anyone has any comments that would be cool


triple loving post yo

Check out this power gauge thing I made



it ends
real nice animations you got there! for the tripmine you can probably start with the landmine addon for the base code, just a suggestion

Jesus loving christ, if I ever finish the trip mine, it will be my magnum opus

In other news:




I didn't think I'd get this far for like, another week

Hey, how come this raycast doesn't work? echo(%raycast) seems to give me 0 no matter what.

Code: [Select]
%raycast = containerRayCast(%pos,VectorAdd(%pos,VectorScale(%rot,5000)),$TypeMasks::fxBrickObjectType,%obj);

%raycast always seems to be equal to 0 no matter what I do. I put in 5000 because I don't really know what the forget I'm supposed to put there lol
« Last Edit: June 02, 2016, 04:08:39 PM by Rally »

containerraycast(%start, %end, %typemasks, %obj)
%start, %end are self explanatory

%typemasks are the kinds of things the raycast will detect. Right now you're only detecting bricks.

The raycast types are
$TypeMasks::FxBrickObjectType - hits raycasted bricks
$TypeMasks::FxBrickAlwaysObjectType - hits all bricks, even unraycasted
$TypeMasks::TerrainObjectType - Not sure if its depreciated but i suspect its used for hitting the ground or maybe modter
$TypeMasks::PlayerObjectType - Players and bots
$TypeMasks::VehicleObjectType
$TypeMasks::StaticObjectType - Probably staticshapes; haven't tested. Seems like it would require the staticshape to also have collision, since Port's new brick tool doesnt let you cast on other player brick beams
There's likely more, but i dont remember how to dump variables of $wildcard* to a file off the top of my head.

%obj is the object firing the raycast; im not exactly sure what that's used for.

example code:

   %start = %obj.getMuzzlePoint(%slot);
   %end = vectorAdd(%start, vectorScale(%obj.getMuzzleVector(%slot), 1000));
   %TypeMasks = $Typemasks::PlayerObjectType | $Typemasks::FxBrickObjectType | $Typemasks::TerrainObjectType |
   $TypeMasks::StaticObjectType | $TypeMasks::VehicleObjectType;
   %ray = containerRaycast(%start, %end, %typemasks, %obj);

The format of %ray is the "objectID posx posy posz objectID posx posy posz" and so on i believe. Check for yourself and correct me i guess - I've only ever used the first object.
« Last Edit: June 03, 2016, 03:39:36 AM by Conan »

Got it working thanks to you and Swallow. But now I have a really weird problem...



Trying to make a minor translation to correct the start point didn't seem to help either. The amount of error seems to be relative to the side of the brick.

EDIT: it gets stranger than that. it's all kinds of very inaccurate. Idfgi
« Last Edit: June 02, 2016, 05:55:04 PM by Rally »



It works! Well, if you like schedule spam. It's got a long way to go

did you fix the strange error? i'm curious to know what it is.

also if you're running the schedule by collecting all items on the map currently and running all of them at once, it may lag more when there's a lot. It's probably a better idea to have each tripmine contain its own schedule so that the server never has to run a bunch of them all at once; instead its staggered out.

and of course you should probably make an rtb pref or something to limit the total number ever present at one time.

...maybe make a way to defuse it? like a defusal tool. have it be a short ranged raycast weapon that runs a container check for the planted projectile or whatever it is you're using to place those things at the point of raycast hit/expire.
« Last Edit: June 03, 2016, 03:41:38 AM by Conan »

did you fix the strange error? i'm curious to know what it is.

I don't have the clue why it might be happening. Realistically it's probably the result of my raycast having some weird rotational error. Is there a command that lets me see raycasts?

also if you're running the schedule by collecting all items on the map currently and running all of them at once, it may lag more when there's a lot. It's probably a better idea to have each tripmine contain its own schedule so that the server never has to run a bunch of them all at once; instead its staggered out.

and of course you should probably make an rtb pref or something to limit the total number ever present at one time.

Currently each placed mine runs 2 scheduled loops of it's own... one checks if there's a player infront of it and one checks if the tripmine static shape is still there in-case the laser needs to be deleted. I don't really know how i'd approach it differently

Currently the mines disappear after 2 minutes of being placed, but that's just kinda a placeholder. How would I go about limiting the amount of mines in the server? Just delete the oldest one when we hit the max or not allow players to place them?

...maybe make a way to defuse it? like a defusal tool. have it be a short ranged raycast weapon that runs a container check for the planted projectile or whatever it is you're using to place those things at the point of raycast hit/expire.

I'm thinking of adding a feature where you can shoot them to blow them up like in HL1. I guess I'd have to do a radius search for projectiles or something? I used .dump(); on a staticshape for one of the mines and there's quite a few methods relating to 'damage' but I'm not sure what any of them do

I don't have the clue why it might be happening. Realistically it's probably the result of my raycast having some weird rotational error.

My hypothesis was correct, I think I fixed it. I changed this line of code:

Code: [Select]
%raycast = containerRayCast(%pos,VectorScale(%rayVector,500), $TypeMasks::FxBrickObjectType, %obj);
to this:
Code: [Select]
%raycast = containerRayCast(%pos,vectorAdd(%pos,VectorScale(%rayVector,500)), $TypeMasks::FxBrickObjectType, %obj);
(I added the end point vectorScale position and the object position together)

And I'm pretty sure it's fixed now. I think the vector was being slightly "shoved" or rotated slightly in the direction of the origin.