Frankenturrets follows you
I want to create a Frankenturret which tries to reach you instead of moving straigh forward.
As well i would know if you know a way to make it move more quickly or make it "jump" farther than default
Any clue on how to recreate that effect?
I don't know much about Hammer, but couldn't this help?
Quote:
Override Parameters
A list of physics keyvalues that are usually embedded in the model. Format is key,value,key,value,...
zivi7 wrote:
I don't know much about Hammer, but couldn't this help?Quote:
Override Parameters
A list of physics keyvalues that are usually embedded in the model. Format is key,value,key,value,...
No.
Override Parameters is a prop class keyvalue that allows you to override keyvalues in the model itself (the keyvalues shown in the properties window in Hammer are exposed by the class, not the model).
Before a model is compiled, it is composed of two main parts, the SMD and the QC file. The SMD is simply the mesh data and so forth for the model itself while the QC file is a human-readable script that describes physical properties of the model to the compiler (things like model name, collision model, animations, mass, etc.). In this respect, they are essentially the model equivalent of VMT files.
QC files contain a block called $keyvalues which describes a variety of prop behaviours such as breakability, flammability, explosivity.
You cannot change the way the frankenturret moves by modifying this data because its movement is implemented in the class itself, not in the prop/model.
CamBen wrote:
no, parent the frankenturret to the tank, and parent the phys_trhuster to the tank also.
These all sound like the most ridiculous and disgusting setups in the world.
You're a certified bro in my book, but stop bullshitting ideas out of your butthole if you have no idea what you're even suggesting.
Jade2k8 -
No. There's no way to accomplish what you are wanting. You can settle for, at best, complete disgusting hacks of the physics systems. But they don't even have any real AI, they just spring kind of randomly. To say they go in straight lines is very generous.
Vordwann wrote:
CamBen wrote:no, parent the frankenturret to the tank, and parent the phys_trhuster to the tank also.
These all sound like the most ridiculous and disgusting setups in the world.
Doesn't work, func_tank has no physics.
You would need to parent the func_tank to the frankenturret and the phys_thruster at the func_tank (but I don't know if this still transfers the force on the turet).
Though,ataching the thrust to the Franky does speed it up if it is no parented to the tank but only if it keeps its physics properties.
Damn Wheatley...why you made your cubes so dumb!?
).
I think that if this is finally achieved by func_tanks or whatever other parenting maneuver it would look odd anyway (will modify the moster box natural movement with sudden orientations or floating effect as mentioned...). I think the only good-looking system would be to use scripts. I haven't experimented much with this though but there are some interesting params that maybe could modify its predefined trayectory...
Just an idea:
- Get player's angles (position in terms of pitch, yaw, roll )
- SetVelocity / SetAngles of the prop_monster_box upon player's position.
That of above can be achieved by triggering a logic_script. Then it would be necessary to fire this logic_script every once in a while by means of math_counter/logic_relays in order to continually update the direction of the monster box.
Another possibility would be to disable the Smart Edit and add a Target !player new line?? Don't know if that would be exactly the command, I'm referring to the same one as the trigger_catapults have as "Launch Target".
But there is also one more thing and I'm a little concerned because pakrat seems to don't have native support for including .nut files.
If i pack my .nut file on the .bsp that i will upload to the Workshop...should it work properly without any extra downloads?
Brainstone wrote:
The answer is no. your users will have to download it seperately and out it in the right location. That is not due to Pakrat, but the way source works: It loads the scripts before you start any maps.
Completetly correct. 