Spring RTS Engine

The following additions can be used to make spectator mini-games,
as well as allowing for hosting spectators to control game state via
scripts, allowing players/specs to easily send their camera states, etc...

I'll probably add a host controlled block so that these calls aren't abused.


New LuaUI call-outs:
Spring.SendLuaUIMsg(string msg[, string mode])
Spring.SendLuaCobMsg(string msg)
Spring.SendLuaGaiaMsg(string msg)
Spring.SendLuaRulesMsg(string msg)

* mode can be < 's' | 'specs' | 'a' | 'allies' >, not unlike chat messages
* the default SendLuaUIMsg sends to all players

New call-in for all lua scripts:
RecvLuaMsg(string msg, number playerID)


P.S. I plan to use Pong as the demo widget

Only spectators?

re-read

allowing players/specs to easily send their camera states

right

This will be nice for sending UI input to gadgets, although using a unit command to any unit and then catching it in allowcommand() works very well apart from being very hack around dirty.

Someone should immediately maek widget that shows your allies screen view on your minimap. Spring has lacked this demo recorder feature sorely for a long time.

LordMatt wrote:Someone should immediately maek widget that shows your allies screen view on your minimap. Spring has lacked this demo recorder feature sorely for a long time.

Cool idea, why not throw in mouse movements as well so you can see their micro.

Zpock wrote:

LordMatt wrote:Someone should immediately maek widget that shows your allies screen view on your minimap. Spring has lacked this demo recorder feature sorely for a long time.

Cool idea, why not throw in mouse movements as well so you can see their micro.

Well okay but viewport positions on minimap is most important.

Oh, I was thinking a (little?) extra screen showing the actual view of the ally, not sure if you can create extra viewports like in supcom tough.

With lua, you could redraw the units and features from an ally's viewpoint.
The projectiles could not be drawn with the current lua interface (lack of
projectile information), and the sky and terrain would be problematic at best.
There is no engine support for separate viewport rendering.

Widget request (or maybe I'll do it myself):
The widget should do this (all possible via lua):
Draw player camera position both on the minimap and the field. Simple team-colored cross (like the one when you middle-click) is enough.
Upon holding shift, the widget would also draw mouse position. Spectators would see the mouse position all the time. The cursor would be a simple team-colored circle.
Show selected units. Requires shift/spec.
If a player gives an order to his units, DrawUnitCommands is called for a second for those units. Requires shift/spec.

Would do it myself but I'm not sure how to handle lag and I'm afraid that I would send too menay messages (which could cause some additional lag). In other words I'm inexperienced in realtime network coding. Maybe after I see your pong demo I would feel confident enough.

network messaging

Does this mean that the data are stored into the demo files?

yes (I'm pretty sure at least)

BigHead wrote:If a player gives an order to his units, DrawUnitCommands is called for a second for those units. Requires shift/spec.

Is this just for the player to see or for all allies/specs? If the latter then it is very similar to tombom's ShowAllCommands widget.

Will there be a way for a client to prevent being spammed with other players minigames / mouseposition messages?

Not everyone owns a 16Mbit connection....

As mentionned in the first post, I do plan on adding a feature to
block custom lua messages. I've yet to determine exact how that will
be done (.nospecmsgs? .noluamsgs?) The other half of the problem
is that I'll need to add a function to get the different custom message
network usage rates for the players / specs.

BigHead wrote:Widget request (or maybe I'll do it myself):
The widget should do this (all possible via lua):
Draw player camera position both on the minimap and the field. Simple team-colored cross (like the one when you middle-click) is enough.
Upon holding shift, the widget would also draw mouse position. Spectators would see the mouse position all the time. The cursor would be a simple team-colored circle.
Show selected units. Requires shift/spec.
If a player gives an order to his units, DrawUnitCommands is called for a second for those units. Requires shift/spec.

Would do it myself but I'm not sure how to handle lag and I'm afraid that I would send too menay messages (which could cause some additional lag). In other words I'm inexperienced in realtime network coding. Maybe after I see your pong demo I would feel confident enough.

network messaging

Does this mean that the data are stored into the demo files?

Well I think you should start simply with just the viewport position on the minimap (and perhaps your viewport as well. In OTA it was a rectangle that was colored whatever your team color was.

Lua quizbot anyone?

Automatically downloaded in-game missions.

If a mod is setup for it, you could send a lua script mission file (probably from the host),
to the LuaRules script with custom lua messages. This mission script can be sitting on
the host machine (unsynced), but becomes synced when it goes through the custom
lua messaging system (all players receive the script).

You could share user textures (I added extra code so that lua messages are received
exactly as sent, no extra trailing '\0' characters, etc...) I don't really think that this is a
reasonable use for this feature, but I mention it to point out that just about anything can
be sent across (you may have to watch out for MTU).

Sounds good. In other words, the whole 'ally view' thing would show where the ally's cursor is at all times?

You'll know who's AFK or not, anyway. AND who's drawing all the damned scribbles.

(you may have to watch out for MTU)

This should be no problem since big packets getting splitted for you.

In other words, the whole 'ally view' thing would show where the ally's cursor is at all times?

No, only your allies camera position. Update cursor position over network = much lag = bad idea.

Shared camera bandwidth example:
(watch 64 bytes become 30.72 KBps)

64 bytes / camera update (real data + overhead)
2 updates / second
128 bytes / second / player
16 players (6 vs. 6, 4 specs)

client input = 16 * 128 bytes / sec = 2.048 KBps
host input = 15 * 128 bytes / sec = 1.92KBs
host output = 16 * 15 * 128 = 30.72 KBps
[ N * (N - 1) relay rule ]

The host output number is the one that probably matters the
most. Even on some 2 MBps lines, the upload bandwidth is
still around 100KBps. Using 30% of the host's upload capacity
to show cameras views is a rather large percentage.

P.S. You can save some bandwidth by only sending updates
when the camera has moved by at least a certain amount.