Spring RTS Engine

In TA overview camera mode and Total War camera mode, when we move the camera around, it keeps its height relative to ground constant, and that is pretty good.

However, when passing over a cliff, wall, or pit, the camera jumps and that is not so good.

So I suggest that instead of following the heightmap, it follows the smooth mesh grid (the one used for airplaines).

Note: How low can the camera be should still be limited by the real terrain, I'm only talking about how the camera follows the ground when moved around.

I like this idea, would work just fine with TA cam
How would one zoom in near the penishills on tabula though?

seems like a good idea.
inb4 "lua it" but shouldn't it be possible to use zeroKs "complete controll camera" widget as a base to do that?

How would one zoom in near the penishills on tabula though?

awkwardly?
When manual adjust camera-height, the real terrain would be the limit. Only when scrolling in x-z the smooth mesh would be used for y.

I think that the camera should stay at it's level unless zoomed in below hill level so it can pop over the hills if need be but that falling camera shit, that makes no sense to me.

Yeah, it's annoyinmg that it pops up when going over a hill. It makes it take longer to scroll over the map too.

Can you mandate camera behaviour with lua or are you stuck with default behaviours?

I was hoping it was a simple enough request that it could just be fixed at the engine level instead of having to once again hack around it with a giant pile of fragile Lua.

What I mean is that, althought it is possible and not even too difficult to code a new camera system with a Lua system, that would create a whole new slew of neverending issues. In particular, incompatibilities with other widgets wanting to set the camera. Because those "Lua camera" are not really new camera mode, but just widget/gadget that every frame place the FPS camera at a certain angle & position. Let me explain: I have a gadget that makes you control a single unit and have the camera follows it. I have a widget that automatically place the camera at pretty angles over action-filled area when speccing. I have people playing KP with their own custom camera widget. And when two *dgets compete for camera controls, things get very ugly.

zwzsg wrote:I was hoping it was a simple enough request that it could just be fixed at the engine level instead of having to once again hack around it with a giant pile of fragile Lua.

What I mean is that, althought it is possible and not even too difficult to code a new camera system with a Lua system, that would create a whole new slew of neverending issues. In particular, incompatibilities with other widgets wanting to set the camera. Because those "Lua camera" are not really new camera mode, but just widget/gadget that every frame place the FPS camera at a certain angle & position. Let me explain: I have a gadget that makes you control a single unit and have the camera follows it. I have a widget that automatically place the camera at pretty angles over action-filled area when speccing. I have people playing KP with their own custom camera widget. And when two *dgets compete for camera controls, things get very ugly.

A) You're wrong, it's very difficult and I've been working on it for years. Writing a new camera widget means _rewriting_ all the motions of the engine camera you take for granted, like scrolling and unit following.

B) That is why all the stuff you mention goes into the same single widget! Hey good ole car already did it for you. Some features of COFC:

All camera motions configurable.
Unit following.
3rd person unit following.
Free mode (allow you to move camera underground and point at any angle).
Smoothscroll - love it or hate it, I put it in there and it's optional.
Follow players' cursor when spectating. Uses data from alliedcursor widget.

Point me to the action-following code and I'll throw that in there too.

Ok, it's very difficult to Lua a camera, whatever. But, difficult or not, the point is, it will never integrate well with the rest.

Err, it does.

Anyway if I could get an equivalent to spring.tracescreenray that gives the smoothmesh point instead of groundpos I could swap that function in and be done.

equivalent to spring.tracescreenray that gives the smoothmesh point instead of groundpos

Did you try like that:
..., gx,gy,gz = Spring.TraceScreenRay ( mouseX, mouseY)
smooth_y = Spring.GetSmoothMeshHeight (gx,gz)
smooth_x, smooth_z = gx,gz
Yes,it is not the real coordinates but maybe close enough?

Gah, now you're all discussing Lua and my engine feature request will be ignored.

Move all camera controls to lua

Remove engine cameras, insert COFC (It does everything the others do)

Forboding Angel wrote:Remove engine cameras, insert COFC (It does everything the others do)

no

COFC is so unstable it was disabled by default in ZK. I introduced a few people to the game and without fail I had to go over and disable COFC for them within the first 10 minutes to play as it had done something stupid like stick in the terrain.

Anyway as for the engine request this should be an option. Too often hardcoded changes are applied to the engine because one person wanted it. Options (springsettings) fix all the problems.

You didn't set the defaults correctly. In evo, I went through and set the defaults so that they act very similar to f2 and f4 cams respectively.

It isn't fair to blame the widget because the zk people didn't bother setting good defaults.

Shitstorm in 3... 2... 1...

I don't care if some people/mods want to use my widget or not. I interjected into this thread as a response to the question of whether you can make a fully functional camera widget in lua. I spent a lot of time adding as many features imaginable as you can read in my post. There are always more to add of course.

@Googlefrog: I'd be happy to debug anything if I were given a method of duplicating the issue.

@forb: thanks for defending. If they don't want to use it, oh well.

@knorke: thanks for the code. I'll give it a shot. If it works I'll make it an option in the widget.

I just don't want to see the engine code stripped out and replaced with your camera, I think it is good work but not what I want in a camera if you feel me man.