Orient Objects in-hand like the Redirection Cube
Hello all,
I've been lurking through these forums for a little while now, checking out cool implementations for various things on maps. But I haven't been able to find this one.
Is it possible to (and, if so, how might I go about) make(ing) an object orient a specific way when the player picks it up. I'm thinking like the reflection cube always orients so it is shooting its laser away from the player.
In the end, I'm seeing if I can redo the physics for personality spheres so they have a presence when picked up. I discovered recently that prop_personality_core does a funky thing when picked up: it removes itself from the world and floats in front of the player's camera with simple collisions with objects. If I am carrying a core while travelling through a portal, it is completely invisible. If I attempt to put down a core while it is pushed against a wall, it instead does this "attach" motion, which works if it were going to interact with something, but it doesn't set down.
In the main game, you are carrying Wheatly once, for a small amount of time, without access to two portals, so all this is avoided in favor of being able to clearly see Wheatly's face. Since I want to make some levels where you're actually using a core like a testing sphere (in addition to plugging in) I want the thing to have a physical presense. But I still want it to face me.
Main question: is there some core physics or property or script I can change/use to make an arbitrary object orient in the player's hand like the redirection cube?
The easiest way might be to make a standard weighted sphere, then parent a prop_dynamic core to it which you can animate.
There's another way, I think, but I'm going to have to do a bit more research on it first...
EDIT: Wait, how did it work in the finale? You have to go through portals with cores there.
There's another way, I think, but I'm going to have to do a bit more research on it first...
EDIT: Wait, how did it work in the finale? You have to go through portals with cores there.
Well, the standard weighted sphere doesn't reorient like the redirection cube. Also, a prop_physics_override is enough to get a spherical core that "physics" well.
As for the finale, I went a looked just now (YouTube is awesome) and they do work the same way. The big telling thing is that the spheres have no shadow while being carried. Note that spheres can go through portal perfectly fine, it just doesn't show on the other side of the portal, as if there is nothing actually being carried. (I should probably check if a coop partner can see you carrying it)
In the finale, also, there isn't really a spot for you to see yourself by going half way through a portal and looking. And with the time pressure, it certainly wouldn't cross the player's mind to do so. And there are no other physics objects to use to compare (in the boss room and for a couple rooms leading up to the boss). And after the third core. Any other interaction with Wheatly is scripted and doing fun things with poking through the floor into space, so we can't look at that. 
Thanks for the idea though.
Well, there's a property on a func_physbox that forces certain angles. Try using that. Just parent a core to it.
But remember that prop_physics_override can't use any animations. That's why I recommend a prop_dynamic on something else with physics.
But remember that prop_physics_override can't use any animations. That's why I recommend a prop_dynamic on something else with physics.
Well, I certainly want to thank you for giving me a giant concrete brick to play around with, that shakes the level when it hits the ground and actually manages to kill the player when it falls on top of you, something they removed from Portal 2's Weighted Cubes. Still haven't been able to pick up the func_physbox concrete block, but it's fun to portal around the place with! 
On another note, I was unaware that prop_physics_override can't use any animations. There goes that possibility... :/
EDIT: So, the func_physbox does have a "Preferred Player-carry Angles" flag and keyvalue, and that's essentially what I want in a nutshell. But is it possible to use that without a func_physbox (which has a distinct "box" model, like brushes are want to do)? Like, perhaps the FGD doesn't define physgun_interactions { preferred_carryangles }, but it can be used for models or prop_physics or something? :3
I plan on doing custom the textures for the personality core anyway, so is it possible to perhaps change the model of the core to do this or something?
EDIT2: Also, I don't think phyboxes can be NoDraw and still be picked up... 
EDIT3: I lied, the NoDraw brush is apparently just a LOT HEAVIER than a metal wall... It keep dropping it when it's small...
If no draw is heavier, use invisible.
Aperture Science: We do our science asbestos we can!
You can use the Mass input on it, the mass of a cube is 40.
But it doesn't have to be a block. Have you tried using the "Sphere" primitive in the block tool?
But it doesn't have to be a block. Have you tried using the "Sphere" primitive in the block tool?
There's a sphere primitive?! Next thing I know you're going to tell me I'm able to move the vertexes of the brush tool independently or something!! O_o
(Note: I am fairly new to Hammer, like a 2-2.5 weeks, but I am also a long time programmer and fast learner. 
)
I've actually been trying to decompile-recompile the personality core model so I can add a preferred_carryangles to it without losing much. It's not working quite how I'd like (the core seems to be missing his aperture now, despite not touching the model data at all... and also it is sideways in its BindPose... and its collisions are all messed up...) but it is carrying like the redirection cube now. I just now have to see how many/much of the recompiled model file(s) I can just replace with the original stuff, without breaking anything or losing the new physgun_interactions. Hex editing will be fun!!
Also, and perhaps this should be an added note on the wiki: the func_physbox's preferred carry angles property acts differently than the in-model physgun_interactions preferred_carryangles keyvalue. With a physbox and value set to "0 0 0", the object always faces you, even if you look upward or downward. With the in-model keyvalue set to "0 0 0", it will face you around the Z axis, but it will stay level on the X/Y plane, just like the laser redirection cube always stays parallel to the ground. I suspect quick-hacks on Valve's part in Portal 2's version of the Source Engine to make the redirection cubes work better for playtesters. :3
EDIT: Actually, in relation to that last note, everything in Portal 2 carries on level when you look up and down... So the physbox would be deviant from the norm in that game... makes me wonder if the engine deliberately leaves out a pitch angle or something... o_O
But it doesn't have to be a block. Have you tried using the "Sphere" primitive in the block tool?
There's a sphere primitive?! Next thing I know you're going to tell me I'm able to move the vertexes of the brush tool independently or something!! O_o
https://developer.valvesoftware.com/wik ... ertex_Tool
But yeah, decompiling Portal 2 models with animations doesn't work too well. And to get a physics model with animations you have to use an NPC (a turret is actually the easiest for custom models ) and logic_choreographed_scenes or ACTions.
Why don't you try decompiling the Portal 1 core, since the older format works better for that, and giving it the parameters? Then make it a prop_physics with rendermode 10 (Dont [sic] Render) and parent your core to it. The collisions should be about right, physics props can have much better collision than brushes, and it'll animate properly.
HA! I have beaten the recompile with hex editing!! With success!!
So, actually, this is relatively easy. I was comparing the compiled and two recompiled mdl files with various binary comparison programs and had some help from https://developer.valvesoftware.com/wik ... ile_format (although, it is out of date).
Since mdl files are not sequential, their headers simply point to an offset and length for EVERYTHING, all you have to do is append onto the end of the file your modified string (for the few things that take string, which fortunately include the keyvalues) and then modify the header to point to that location with that length. Oh and edit the overall length value. No having to shift all other index offsets, potentially breaking the model. And yes, this method leaves the old value in, but for something as small as a 0x12 length string, it really isn't worth all the trouble to attempt to remove it.
So now I have my own model with editable physics interactions! WOO!! Now all I need to get it to do is animate somehow. Still working on that. Can prop_physics animate (assuming I can convince my model to not remove itself when it is a physics prop)? I wonder if I can somehow override the carry code in the npc_personality_core - that would solve this simply. Unlikely though... I wonder if I could use a superclass of npc_personality_core. Then it might not pick up... intriguing...
Told you hex editing would be fun!
EDIT: for future reference: Portal 2 model relevant header locations:
Model length: int at 0x004C - whole length of file, including header(s)
$keyvalue string offset: int at 0x0138 - location of the start of the keyvalue string
$keyvalue string length: int at 0x013C - length of keyvalue string, including null terminator
Note: when appending, you should probably pad your model file out to the next word with nulls (0x00). All the compiled mdl files are padded this way, so we should be consistent lest something break.