Spring RTS Engine

I have (yet again) questions in relation to the FPS mode. It may be thought of as an useless gimmick to the spring's otherwise fully RTS engine, but i have a few possibly fun ideas with it - such as FORCING the player to view the battlefield from within his units.

"Want overhead? Build a flying scout and try not to get shot while starcrafting your goons!"

I've been questioning some of those a few years back, but things have changed since, so rather than necroposting the old thread, i'll just ask anew.

So,
1) (How) can i detect when the player is in FPS mode?
2) Can i hijack and/or re-route the FPS controls? Can i add new ones?
3) Can i somehow hide the default ugly aiming crosshairs? Not the X-in-center, but those colored ugly circles on ground that show where your actual guns point at? I so want to replace them with flashy TARGET LOCKED and CONQUER MODE and FASTER PUSSYCAT KILL KILL KILL etc! (this i asked earlier - and was told that 'no way, and also no way we're adding any call-in to keep the ugly hud away')
4) Can i reliably hijack/control the camera in FPS mode? Like, say, by keeping it locked to the unit front or whatever i designate as the main gun? Will that anyhow break the controls for, say, planes? (no matter if i can override without a ton of movectrl, of course)

P.S, i've heard Kernel Panic has some direct control thing where you view your unit from top and control it with keyboard. Anyone know how it does that? (soz vor being lazy in rtvs here).

1) Spring.GetPlayerControlledUnit
2) limited, Spring.SendCommands + uikeys.txt (bind <key> <action>, unbind <key> <action>)
3) no
4) you can put Spring into any camera mode (/viewta, /viewfree, etc) at any time

Kloot wrote: 3) no

FEATURE REQUEST? move aiming thingies to debug mode maybe?

Anarchid wrote:P.S, i've heard Kernel Panic has some direct control thing where you view your unit from top and control it with keyboard. Anyone know how it does that? (soz vor being lazy in rtvs here).

I have singled out the gadget that does that in this mutator: http://springrts.com/phpbb/viewtopic.ph ... 3&start=10 (Just extract the gadget and read it or use in another mod)


KDR_11k once made a Spring game about fps'ing a plane: Air Raid. You'll have to fix what got broken by new Spring versions, but still a worthy starting point.

KDR_11k once made a Spring game about fps'ing a plane: Air Raid. You'll have to fix what got broken by new Spring versions, but still a worthy starting point.

Tried that, didn't fix too much, but got the hang. Though, seems this fps works by extensively movectrl'ng the plane.

One issue i couldn't figure how to fix was the camera getting far back from the unit, have no idea why and how to fix.

Anyway, movectrl'ng the fps'd unit would essentially require having each of the controllable units have almost its entire physics mapped/mappable to lua not to allow for vast differences between what it can do as a player-fps'd unit and a normal unit :\

iirc Flozi mentioned he fixed up Airraid.
Though one serious problem with fps in spring is lag.
I found Airraid unplayable in multiplayer ( http://springrts.com/phpbb/viewtopic.ph ... d&start=61 )
But slow sluggish ground vehicles might work better than zipping fast aircraft.

FORCING the player to view the battlefield from within his units.

If you just want the player to see the battle from a units perspective but not nessecarely fight himself, you could make a "virtual unit." There is a widget named "spec run" which does just that.

If you just want the player to see the battle from a units perspective but not nessecarely fight himself, you could make a "virtual unit." There is a widget named "spec run" which does just that.

Sticking the player as control agent of his army into a unit more or less forces the option of providing them with controls to run that vehicle (even without shooting) - so at least some degree of control is imperative.

iirc Flozi mentioned he fixed up Airraid.

Can i haz?

though one serious problem with fps in spring is lag.
I found Airraid unplayable in multiplayer ( viewtopic.php?f=14&t=20296&hilit=air+raid&start=61 )
But slow sluggish ground vehicles might work better than zipping fast aircraft.

Is this the generic command-execution lag, or network-specific? While spring can usually be played with hideous lags on really shit connections (kudos to the network code, i guess). In other words, a bit slower units on a bit faster network would or would not work?

(if all that lags about as much as normal spring fps, i guess, that's tolerable)

springs physix-update cycle is every 16 th frame aka 2 a second

THAT is very good for a rts with thousands of units. The problem is that with first person rts, you have to find a compromise, which results in basically writing too physix engines (action engine around you, exchanging units at the circle..)

Its really a nice gimick, but nothing more. I once suggested it to be used for death animations (when your com die, the background behind the map slowl breaks away, revealing it to be a holo on a black background, and you see the coms view for a second before everything blows to bits

Is this the generic command-execution lag

it is the fact that commands (including FPS control inputs) go from client to server back to client before being executed --> ping matters since lag ~= 2 * ping

springs physix-update cycle is every 16 th frame

nein

aka 2 a second

nein

nein?

Time

Seconds (s)
Frames (f) - There are 30 frames in a second.
Resource Frames - There are 32 resource frames in a second.
SlowUpdate - These occur every 16 frames.

So slowupdate isnt the synced"real Game Engine"?

Kloot wrote:

Is this the generic command-execution lag

it is the fact that commands (including FPS control inputs) go from client to server back to client before being executed --> ping matters since lag ~= 2 * ping

I think most FPSs deal with that by having unsynced movement (and maybe even other actions, but usually not effects) - it probably wouldn't be a small thing to implement that.

I think most FPSs deal with that by having unsynced movement (and maybe even other actions, but usually not effects) - it probably wouldn't be a small thing to implement that.

Some of that could be arsed up pretty easily. Like, allow the view to deviate from the actual camera-piece orientation a bit, and then do the muzzle-flash clientside right on the click, in a widget unsynced. So what if the projectile spawns only later.

it is the fact that commands (including FPS control inputs) go from client to server back to client before being executed --> ping matters since lag ~= 2 * ping

So if everyone has 50 ping to server, it's not that bad. I guess i'm keeping this idea, but making actual fighting with your 'commander' unit less important, and have it mostly as provider of 'frontline micro' to one's advance squads.

Though, some further evaluation of feasibility of integrated control physics (i.e, how to do the overriding fps as in airraid with minimal movectrl hax and without extra huge physics cheats) is going to be needed, and also i still have to play with the heroes gadget.

PicassoCT wrote:nein?

nein!

PicassoCT wrote:So slowupdate isnt the synced"real Game Engine"?

You missed my main point, which was simply that the "physics simulation" (Spring's does not really deserve the name) is updated every frame for every unit/feature/projectile, not every 16 frames.

? wrote: Resource Frames - There are 32 resource frames in a second.

I don't know where this quote originates, but it's wrong: resources are updated every 32 frames, ie. every 32/30 seconds <--> there are 30/32 (0.9375) resource frames in a second. And finally, this...

PicassoCT wrote: every 16 th frame aka 2 a second

is also wrong: every 16 frames is 1.875 (30/16) times per second, not 2 (32/16) times per second.

you know... because people like you people like mythbusterscrew get unemployed.

Thx for the info, will try to repeat correct factoids and numbers next time. Sorry Gajop

Anarchid wrote:

iirc Flozi mentioned he fixed up Airraid.

Can i haz?

Not me, ask KingRaptor, and of course test with current development engine (Bug in 85.0).