New feature? Sit-in players

[Soul]

Hi everyone.

I was recalling memories from old games and i remember that we sometimes allowed "cheat" to make a spectator take over units from a player (who lost connection/left).

Mixed opinions allways followed since the spectator had seen the units of the oponents.

I remembered this and my mind fused this together with something i read in the "to do" wiki.

What if we made spectators able to, before the game starting, pick which team/ally.
Thus these "spectators" would only see allied LOS. This combined with some tweeking in the "share selected units" or the .take command. Would allow a "spectator" to quickly take over from leavers/etc or even if its a very long battle some spectator clanmate can jump in and take over existing units while the player goes to do what he had to do.

This "feature" could later become usefull when we try to enable players from outside a game join a already started game.

An example might be a clan-war fight, and 30 min into the game someone has to leave.
Well if you have another clanmate nearby you could just ask him to join the running game as a "Stand-in" for the player who has to leave.

Perhaps its just easier to make a third option when you join a game "Player, Spectator or a Sit-in/Stand-in player."
Im not realy sure how this is most smothly done, but i would guess that you either, as abow, make some changings into the "spectator" code.
Or make a new category, based on a player, but that has no commander upon start.

This thread would benefit from any ideas on how this might be done and/or other features that might/should be included.

[CarRepairer]

http://trac.caspring.org/

[Soul]

http://trac.caspring.org/

Sry, am I suposed to find something there or are you just making commercial?

[Evil4Zerggin]

CA has this feature already, unfortunately Car didn't link to it directly.

[Soul]

That sounds great but why, if i might ask, would such a thing be mod specific instead of a spring and lobby matter?

[CarRepairer]

http://trac.caspring.org/wiki/GameOptions
http://trac.caspring.org/wiki/GameOptions#Factions
http://trac.caspring.org/wiki/GameOptions#BackupPlayer
http://trac.caspring.org/wiki/GameOptions#Teamspec
http://trac.caspring.org/wiki/GameOptio ... mplemented

Description in last link is not fully implemented because people didn't show much interest, but the backup and teamspec players are usable.

That sounds great but why, if i might ask, would such a thing be mod specific instead of a spring and lobby matter?

Because modders, more than engine coders, want it now. That's why there's also a random faction.

[Licho]

Because it was first coded by mod devs .. its much easier to experiment and develop new features for mod than changing whole engine/lobby infrastructure.

[hunterw]

yeah but this is something that is equally applicable and useful to all mods

speaking of that, volume bar

[CarRepairer]

yeah but this is something that is equally applicable and useful to all mods

speaking of that, volume bar

Engine devs have a zillion better things to do than make built-in widgets. Especially those that have already been made.

[ChaosMonkey]

volume bar

Especially those that have already been made.

hunter try looking at the widget list in spring downloader once in a while

[hunterw]

hunter try looking at the widget list in spring downloader once in a while

this further enhances my point

[Soul]

Ya, but lets not forget, that we also want the ability to join a already running game.

I am quite sure that is near impossible to do only with a mod.

And no offence to widgets, but if you ask me they makes everything alot more messier.
So I personally think that one shouldn't complement everything in spring with widgets.
If you ask me, I see widgets as a fast way to test small changes in spring. But in whole, i do not see them as the final result.
I am aware that many love their little widgets, but when i started playing spring again after being away for along time... they where the ones to scare me away again.

[CarRepairer]

Like I said...

Ya, but lets not forget, that we also want the ability to join a already running game.

If you want stuff like this to happen, then...

And no offence to widgets, but if you ask me they makes everything alot more messier.
So I personally think that one shouldn't complement everything in spring with widgets.
If you ask me, I see widgets as a fast way to test small changes in spring. But in whole, i do not see them as the final result.

...stop asking spring devs to waste time doing little widgety stuff that's already been done by modders and let them do the stuff modders can't.

[Raghna]

Makes me wish I could program and help modding and such...

[Pendrokar]

Makes me wish I could program and help modding and such...

But those wishes fade out very fast...

[YokoZar]

...stop asking spring devs to waste time doing little widgety stuff that's already been done by modders and let them do the stuff modders can't.

If copy/pasting a widget from one mod into a global directory will make every mod better, then it's worth for the engine devs to spend the 20 minutes it takes to do that. It's not like they have to rewrite it from scratch - as you said, it's already done.

[Pendrokar]

IIRC global gadgets don't exist.

[Caydr]

...stop asking spring devs to waste time doing little widgety stuff that's already been done by modders and let them do the stuff modders can't.

Devs, get back to work making cheating easy while I'm making ossum things that cheats will one day destroy.

[MidKnight]

And no offence to widgets, but if you ask me they makes everything alot more messier.
So I personally think that one shouldn't complement everything in spring with widgets.
If you ask me, I see widgets as a fast way to test small changes in spring. But in whole, i do not see them as the final result.
I am aware that many love their little widgets, but when i started playing spring again after being away for along time... they where the ones to scare me away again.

CA has an answer for everything!*

We are currently at work on ChiliGUI, a framework to standardize many commonly used, screen space intensive widgets into one coherent, consistent, and compact style. Consider helping work on the code; Chili's success is a win for the entire Spring community!

*This statement is a fabrication.