Gravity manipulation
Oh, yes. I think I was more accustomed to my custom gravity gun, or the original one. 
anyway, I got the +use issue solved. I was able to use my same viewmodel, with no changes in the rotational axis. All I did was move it forwards a ton before it was activated so that the player could press buttons, then once picked up, I enabled everything I needed to as before, but then I disabled use again and moved the gun back. Seemed to work out well, and I got the pickup to actually use the item instead of teleportation without deactivating the gun. The rest of the buttons in the map pack are punt panels, floor buttons, or Electrotech access pads, which can be activated by zapping/punting them, or standing on them.
Aperture Science: We do our science asbestos we can!
I set mine up so you immediately have it on mapspawn, but none of it is enabled, but once you pick up a portalgun, it is enabled. I hade to eliminate the teleportation trigger because if you are standing in the wrong way, you can easily teleport what you grab on the other side of a wall or even the map itself
Yes, i found that annoying too, so I decided to use an old mechanic used in my ragdolls gun map which allowed me to filter out certain objects from being picked by !picker to filter out triggering the tank.
I too have an invisible nonfunctional gravity gun placed at the player, where once triggered, the game ui and triggers and such are enabled.
Aperture Science: We do our science asbestos we can!
I am revising the gun again because some play-testers found the gun buggy. I combined several trigger_pushes and a trigger_vphysics_motion for pulling objects, and then a trigger_push and trigger_catapult for pushing objects. I found the tank moves better with the Yaw movement eliminated and the pitch movement lowered.
Now if I can only figure out why on earth does the effects of all the triggers seem to move beyond the regions of the triggers themselves when you look around standing still but when you walk forward the triggers align their properties backinside themselves.
I place a crosshair in there to show you what i mean
It's a bug with things parented to the player. It goes something like this: if the object is aligned correctly, and the player looks to the side, the yaw will not update. The pitch will always update properly, but the yaw will not. If the player presses a movement key it will cause everything to update, but if they stand still and rotate it will again mess up the aim.
There are a few ways to fix it, such as sending +back;wait;wait;-back to a clientcommand or just using a measure_movement instead. I used the latter for the Blapperture Multitool, although you then need to use an odd arrangement of tanks to smooth out the motion of the viewmodel (the motion of the player's crosshair is somewhat jerky, if always precise).
the client_command apparently didn't recognize those inputs at all. I am now experimenting with the measure_movement for the first time and I don't really see any change. I might not be doing it right. It would be nice if the wiki had example content per entity.
Can you post a link to something this entity is used in?
I think Radelite released a WIP a while back with it, but I don't know if it worked or not.
I've got a fully functioning and working gravity gun that I made as a part of gravity chambers that uses the logic measure movement, but it has a custom player model behind it, player model arms on the gravity gun, hl2 sounds for death and the gravity gun, as well as a custom gravity gun model.
And yes, using vphysics motion for both the push and pull is the way to go. That's what I used anyway.
Aperture Science: We do our science asbestos we can!
But how do you prevent it clipping through walls? I use pushes for the punt, but so far I haven't come up with a good way to make the pull work.
After some experimentation, i found that entity way better than the controllable func_tank. It may be jittery when walking, but I will take it over bad aiming