Camera Changes

#21 Daniel, it sounds like you guys are making good progress.

I haven't tried the AIPlayer yet.

On the trackObject method with newtonRotation: I have attempted to do this a while back, my results where the same as yours: a "stationary" camera that rotated to keep the player in center view. When I hit Alt+C it would rubberband or slingshot back and forth across the players position. But I was unable to control the camera.

So the OrbitMode uses the same controls as the player. The trackObject does not.

Hmmmm....

IDK

http://www.torquepowered.com/community/forums/viewthread/5742

Long days! Cold weather!

DIG DIG DIG!!! Argh! I'm going to get some captin in me!

I will dig tonight and see what other ideas I can come up with tomorrow. The acceleration script sounds cool. What about an attached pathed camera? Or another node that you can attach the camera to, and that node is effected by physics.

I'll dig tonight.

J

#22 J,

Alt+C shouldn't be used when testing the camera stuff we're doing. Alt C changes camera mode, and certain camera modes don't use Newton stuff, and it's just going to confuse me.

Explain more about the pathed camera. I thought it was used for a camera to follow on a spline.

#23 Daniel,

I found a thread a while ago (I was unable to find it again, sorry) regarding TGE where someone had used the track mode from the Advanced Camera Resource, they where able to view the player in a stationary rotate (such as we have with T3D's trackobject) and follow the player on a pathed camera.

I'm still playing with the trackobject with no avail. I'm not getting newtonRotation to work with anything except that slingshot stuff when you control the camera separate from the player. (Alt+C)
You can update the camera's transform and move the camera, but to get a nice flowing camera with newtonRotation that stays in a relevant position to the player? ...no dice.

I'm really at a loss. What have you come up with?

#24 Well, as Michael Perry was explaining, you can't just update the camera's location every tick - it ignores Newton stuff. What you need to do is use the $mv variables for the camera. What I proposed earlier is to give the camera a function (onUpdate) that sets the camera's $mvForwardAction = 1 if the camera is > x distance from player (x being an arbitrary distance representing the max veiw distance we prefer.)

This is all still assuming the trackObject mode is used. The camera will always turn to face the character, and therefore "move forward" ($mvForwardAction) will always be following the character.

I'm having a hellish time finding an opportunity to get to this between work and other stuff. I promise I WILL get into it though!

#25 Same here Daniel... wish I could get paid to work on Torque all the time! lol.

I've got this afternoon off, so I'll come up with something hopefully.

#26 Please correct me if I'm wrong here:
I don't think you can assign $mvForwardaction to another object besides a player/aiplayer. At least I could never get it working. the "mv" variables are tied into the code and preform operations that are all tied into camera/player/aiplayer. Animations/gravity and movement calculations, etc... are a part of that.

The player movement could definetly use an upgrade.

so friday I dug into all this. I tried making an movement script for the player. Basically its a setTransform on the rotation of the player. Subsittuted the turnleft/turnRight with this function. It works but makes the player and camera jerky; since the camera is still tied to the player.

So I made a script that figures a matrix around the player and determines a position a set %dist behind the player, then I attempt to make the camera stay within a %mindist/%maxdist. So If the camera is getting too far away the next applyImpluse/setVelocity can be upped a little to compensate.

Alright, this all great and works up to a point... I can echo and everything returns fine but I could never get applyimpulse or setVelocity to work on the camera. (I did not dig through the code to look and see it was setup to even handle applyImpulse on the camera)

And u have to use a pretty high number on the applyImpulse, but it never worked on the camera.

So I tried a movement function instead... the setTransform is jerky again and makes it look terrible. setPosition interpolates better, but still didn't work like I thought it should.

So I don't think there is anything in place currently to really allow what we want and a half-arsed hack that doesn't look good isn't going to cut it.

It does look like there was something in the works for us though...
If you do a dump on the player you can see a chaseCam function. Wonder what that's about.

So I guess unless you go code side, it isn't going to happen.

#27 Anyone one at GG have a comment on this?

I mean it says "tethermode" in the docs. Can you give a specific example of how to do this?
Because I really don't think you can do it. If you can't, you need to take it out of the docs. Its missleading.

What is chasecam about? Something that is to come?

Is there ever going to be a stock, separate control object setup for T3D implemented?

Is there ever going to be a modified player movement. Or the ability to designate which object is taking commands from the keybinds?

You can do so much more with the Advanced Camera resource and other resources that add onto the functionality of the Advanced Camera. I've read a few posts stating that the new camera system in T3D was supposed to be so much better... Is this still in the works? On the drawing board? Is it ever going to be a part of T3D?

If any of this is there or you know how to get it without engine modifications, please help us out. I'd greatly appreciate it.

#28

Quote:I don't think you can assign $mvForwardaction to another object besides a player/aiplayer.

The client-side $mv variables are the inputs from a single client - usually a player's keyboard and mouse. Each client connected to the game sends the current values of its $mv variables to the server a few times every second (probably once per tick, but I really don't know), and the server applies them to the client's control object. So

Quote:Or the ability to designate which object is taking commands from the keybinds?

setControlObject lets you determine which object receives a client's moves - but not all objects are set up to take move inputs. The Player and Vehicle classes, for a start, and probably whatever class the free-flying camera is represented by. But not, for example, Items. Also, there's not really any way to send a client's input to multiple objects.
This does happen to some degree in certain situations- for example, when a Player is mounted on a Vehicle, selected movement inputs are applied to the Vehicle rather than being wasted in the Player's move processing (because the player can't actually move). There's no generalised way to get the same effect though, and certainly not in script.

An interesting upgrade to the Torque engine series might be to expand and expose more controlOject functionality. Off the top of my head, setControlObject could be changed to a 'stack' of control objects, each with an 'input mask' that determines which parts of the input move they use. So in the case of a player mounted on a vehicle, the primary control object would be the player, and it would have a mask with basically only the jump trigger filled in. Then the vehicle would be next in the stack, receiving all other inputs after the player has gobbled up the jump trigger and done with it whatever the Player needs to do (in this example, dismounted when the trigger is down).
But that might be of limited use... you still need to get into the engine code to have your objects make any use of the inputs they're sent. Scripts really aren't the place to do this - scripts handle events and properties, not the tick-by-tick responses and movement of objects. I assume that's why you're finding it so hard to create a script-only solution; the language, and the way it interacts with engine code, wasn't designed for what you're doing.

#29 Daniel,

Thank you for the comments, that is a big help. I'll quit digging on it, lol.
There are a lot of resources regarding this situation, I'll start working with the source.

Have a Merry Christmas.

#30 Well that's sad.

I think Torque script needs to have more things exposed to it in general. The way it's set up now, you need source access to do anything other than a first person shooter. In a way, I wish GG were more aware of what their product can and cannot do in script. I'd been talking with Michael Perry for a while on this issue and he seemed like it was the first time he'd considered this script-only camera issue.

I'm still on the fence about the Binary. I think it's a great value, and I can always get someone to make a binary for me with some changes to it. At the same time, it will be like purchasing a vehicle that's missing a key. It's all there, but I would have a lot of trouble getting it started.

Thanks a whole lot for the info Buckmaster. I've been watching your posts for a while and you really seem to know what's happening in source (even without owning T3D).

I have until Wednesday to consider the purchase, I believe. J - if you ever end up coding a solution to this, I'd be interested in it!

#31

Quote:I think Torque script needs to have more things exposed to it in general. The way it's set up now, you need source access to do anything other than a first person shooter. In a way, I wish GG were more aware of what their product can and cannot do in script.

I think if you were willing to put the work in, you could fairly well do a small-scale RTS or a racing game... but you're right, the Torque engines are geared towards FPS games (it's their legacy). That hasn't been an issue until now, because all former engine licences were source-access licences; the binary-only T3D licence is something new, and maybe it will take a while for a) people to get used to not having source access, or b) GG to start catering to a non-source audience. That would mean creating more generalised and flexible game systems to be exposed to scripts.

Quote:I'd been talking with Michael Perry for a while on this issue and he seemed like it was the first time he'd considered this script-only camera issue.

I can't speak for Michael, but again, the answer to problems until now has been 'you've got source, you can do whatever you like!' Until now there's been no real need to script complicated functionality, since the script-only demos were just a way to try out some of Torque's capabilities before buying and getting source access to code in your really core features.

Quote:I've been watching your posts for a while and you really seem to know what's happening in source (even without owning T3D).

I must confess that any T3D knowledge I display is assumption on my part - I'm familiar with TGE's code, and from what I've heard, T3D doesn't change fundamentals like script/code interaction, the way some systems work (like input, datablocks), etc.

#32 I worked with TGB Pro for a little while as a side hobby of mine, and I really haven't had to do a whole lot of source editing. The scripting was very powerful and the engine didn't seem like it was "guessing" what kind of game you were making.

They've had a binary in TGB for a long time now, and I guess because of how scripting worked in that, there wasn't as much of a problem of "I can't do this in script and it's very basic."

With the (assumed) popularity of the T3D binary, I hope GG will improve the functionality of script vastly.

In my OP, I asked if there were any "genre packs" that had these kinds of things built in, but alas the only solution was Ubiq's Adventure Kit that's almost the price of T3D alone.

#33 Ah, you're right - I forgot about TGB, I haven't had much to do with those engines at all.

Despite what I've said, you might find some way to completely hack the engine and make this work in some crazy way. For example, when I thought about it, I came up with an AIFlyingVehicle instructed to follow the player around, with an AIPlayer mounted to it to track the player, and the camera mounted to the AIPlayer (all of that invisible). Then I realised AIFlyingVehicle was a resource :P. Unless it's been added to T3D.