just played tst4
and all players turned up early
and we played first match well
then other players turned up and the mess began
kicking here and there
calls for admin (who was playing) to do something about it
etc etc
my experience of all games played in tournaments is marred by one thing:
players entering when they shouldn't
we need to sort this out
period
may i suggest that we have a key-password for the server
which can/not be enabled
most of the time it will be disabled because server owners want people to visit
but on such days as there are tournaments
the players involved can be informed of the current password for that server
and on the listing on the masterserver an explanation can be given
this is good for new players for two excellent reasons
1
they do not get involved in the midst of battle
get shouted at
kicked etc
and have a bad experience generally
2
it sets up a mystery
so that new players will look at servers being locked and think they are missing something
-- which they are!!!
how hard can this be to implement?
if it is at all possible...
could we please consider it...?
making tournaments run smoothly
-
2020
- Outside Corner Grinder
- Posts: 1322
- Joined: Thu Dec 29, 2005 9:21 pm
- Location: the present, finally
making tournaments run smoothly
hold the line
-
wrtlprnft
- Reverse Outside Corner Grinder
- Posts: 1679
- Joined: Wed Jan 04, 2006 4:42 am
- Location: 0x08048000
- Contact:
I this case the problem wasn't really the joining players, it was just part of it. Whatup would have been able to rejoin gold sooner, but it would still have been a mess.
What really is a problem is participants of the tournament trying to spoil the game for everyone else and starting discussions with other players during a match, and this can't be solved by technical means.
Though a setting to disallow any team change/join would be helpful.
What really is a problem is participants of the tournament trying to spoil the game for everyone else and starting discussions with other players during a match, and this can't be solved by technical means.
Though a setting to disallow any team change/join would be helpful.
There's no place like ::1
Definitely. A global setting that enables/disables all team changes, and if that is active, another command that gives one player the opportunity to change teams once would be ideal. Players that drop and rejoin could then be allowed to play again without opening up the server.wrtlprnft wrote:Though a setting to disallow any team change/join would be helpful.
unwanted rant
Why are tournaments still using public servers? If your going to be in an organized tournament you should have the technical ability to use custom connect.(When turning a public server private for a tournament, to avoid users with said server bookmarked use a different port after telling it not to talk to master)You could give them the custom connect info weeks days or minutes before the tournament. Force players to join a team before being able to play. etc
Most of this would be avoidable this way. Only a small amount of planning ahead would be needed.
Hmm, also having an admin present that is not involved in the tournament in anyway would keep alot of these problems from happening. An admin playing obviously has to put his teams interest first before being able to solve problems.
Why are tournaments still using public servers? If your going to be in an organized tournament you should have the technical ability to use custom connect.(When turning a public server private for a tournament, to avoid users with said server bookmarked use a different port after telling it not to talk to master)You could give them the custom connect info weeks days or minutes before the tournament. Force players to join a team before being able to play. etc
Most of this would be avoidable this way. Only a small amount of planning ahead would be needed.
Hmm, also having an admin present that is not involved in the tournament in anyway would keep alot of these problems from happening. An admin playing obviously has to put his teams interest first before being able to solve problems.
-
DDMJ
- Reverse Outside Corner Grinder
- Posts: 1882
- Joined: Thu Jun 08, 2006 12:15 am
- Location: LA, CA, USA, NA
- Contact:
I like mom's idea.
The only problem I could see would be that the majority of the players involved in the Ladle and TST, just sign up and show up that day. You'd be surprised how many players asked me where they were playing just minutes before the start. So, if they can't be responsible enough to remember when to play, how on earth are they going to remember what IP & Port to Custom Connect to.
But then again, it's the best possible solution I pressume, other than locking the server of course
.
The only problem I could see would be that the majority of the players involved in the Ladle and TST, just sign up and show up that day. You'd be surprised how many players asked me where they were playing just minutes before the start. So, if they can't be responsible enough to remember when to play, how on earth are they going to remember what IP & Port to Custom Connect to.
But then again, it's the best possible solution I pressume, other than locking the server of course
.-
wrtlprnft
- Reverse Outside Corner Grinder
- Posts: 1679
- Joined: Wed Jan 04, 2006 4:42 am
- Location: 0x08048000
- Contact:
I feel like a broken record here, setting MAX_CLIENTS to 8 (because we were 8 players) would not have fixed the issue, because someone left and I didn't realize until I was playing what happened, and then couldn't decrease it.
Also, I do think spectators should be allowed, so I don't want the server to be completely locked down. Also, Durka joined my server a couple of times to check what was going on, that wouldn't have been possible.
I'll try to implement locking the teams so we can try it out next time.
Also, I do think spectators should be allowed, so I don't want the server to be completely locked down. Also, Durka joined my server a couple of times to check what was going on, that wouldn't have been possible.
I'll try to implement locking the teams so we can try it out next time.
There's no place like ::1
-
2020
- Outside Corner Grinder
- Posts: 1322
- Joined: Thu Dec 29, 2005 9:21 pm
- Location: the present, finally
i like the idea of spectators in principlewrtlprnft wrote: Also, I do think spectators should be allowed, so I don't want the server to be completely locked down.
but it doesn't work --
they just distract players from the game
and sometimes join teams etc
wrt spectators
some thought has to be put into the whole issue
to provide a comprehensive and workable solution that does not impinge upon player concentration
may i ask
is the issue of password entry into a server a technical one
or is it a matter of principle (ie that we want all servers to be open to the public)?
hold the line
-
2020
- Outside Corner Grinder
- Posts: 1322
- Joined: Thu Dec 29, 2005 9:21 pm
- Location: the present, finally
thanksz-man wrote:It is a matter of "already implemented via TALK_TO_MASTER 0/SEVER_PORT somethingelse".
i think this is related to custom port do-das
which has problems for players as someone else has pointed out
you have made the game supereasy to play for a computer illiterate like me
and from my tiny perspective
a password entry to a server is something that is equally super to understand
after so many ladles and now tsts
i find it strange that we still get a lot of messy tournaments
with new players getting kicked
experienced players getting annoyed
and admin being stressed
considering these solutions have been available to us
we need a different solution
player-side as it were
gordian knot solution:
password protect servers
i am sure players will not divulge their passwords since it increases the risk of their games being interrupted...
it may actually make players a tiny bit more responsible
hold the line
-
wrtlprnft
- Reverse Outside Corner Grinder
- Posts: 1679
- Joined: Wed Jan 04, 2006 4:42 am
- Location: 0x08048000
- Contact:
I implemented that now.
Of course, we could also implement a setting on the server, maybe SILENCE_NEW_PLAYERS that works like the SILENCE_ALL setting on the client. The admin could then unsilence the players who should be able to talk.
Also it might be helpful to implement “light moderation” like on IRC, so logged in players see messages sent by players who are silenced on the server side.
You can still enter spectator mode if the teams are locked, simply because you could as well leave and rejoin for the same effect, so I didn't restrict that.NEWS wrote: New settings and commands:
- ALLOW_TEAM_CHANGE: if set to 0 players won't be able to join a team, create a new team or change to another team.
- ALLOW_TEAM_CHANGE_PLAYER/DISALLOW_TEAM_CHANGE_PLAYER: allow/disallow specific players to switch teams
Well, now they can't join teams anymore, and if you don't want to be distracted by spectators I suggest you set SILENCE_ALL to 1 in the console after the match starts, as this setting only has an effect on players who join the game, participants will remain unsilenced.2020 wrote:i like the idea of spectators in principle
but it doesn't work --
they just distract players from the game
and sometimes join teams etc
wrt spectators
some thought has to be put into the whole issue
to provide a comprehensive and workable solution that does not impinge upon player concentration
Of course, we could also implement a setting on the server, maybe SILENCE_NEW_PLAYERS that works like the SILENCE_ALL setting on the client. The admin could then unsilence the players who should be able to talk.
Also it might be helpful to implement “light moderation” like on IRC, so logged in players see messages sent by players who are silenced on the server side.
There's no place like ::1
-
philippeqc
- Long Poster - Project Developer - Sage
- Posts: 1526
- Joined: Mon Jul 12, 2004 8:55 am
- Location: Stockholm
- Contact:
Warning:
Yes, its one of my big "lets build a complex system to address a moderate problem" ideas...
Right now, we have the following "problems"
a) few ways to combine players as teams
ex: all players divided in 2 competing teams except for a single one-man team, the Minotaur.
b) very little in the way of creating teams based on in-game info
ex: Best player is paired with worst player in a team, second best player is paired with second worst player in a team, etc.
c) no mecanism to select a set of players among all the players and only allow them to play for this round
ex: 1 on 1 round, round robin style, between the 5 players present
d) limited association between the in-game info and the map/configs
ex: when N teams are present, pick among the maps that support so many.
e) limited automatic control on who gets to play among the spectators
ex: all newcomer are spectator except for some pre-defined players
f) limited control on what defines a round
ex: think fortress, but instead of conquering a zone, you need to kill a specific player on the opposing team to win.
g) limited control on what defines a match
ex: an automatically administered round-robin competition between all the players present.
h) no mecanism to change the mode/style of play without admin intervention.
ex: a server runs a regular fortress game, except on sundays from 19 to 21, where it is some clan's exclusive sumo training ground.
What I propose it to have a set of mecanism that could take care of all these parts, and be expandable through scripting. Some sort of a "tourney" engine. This engine should be composed of simple modules, each taking care of a single task:
a) player module: moves players between 3 states: spectator (not allowed to play), sitting on the bench (allowed to play, but not at the moment) and active (can be alive or dead)
b) team module: moves players to and from team
c) round module: monitors the game for a condition (or set of conditions) that will end the round
d) match module: monitors the game for a condition (or set of conditions) that will end the match
e) settings module: determine the settings and map that will be used for the coming round
f) planner module: determine when to change the modules, and which instance of each should be used (changing the modules from a classic "100 point or 10 round" fortress to a "2 out of 3 elimination style competition in teams of 2 players")
Each module should be pretty limited in the service it provide, delegating to sub-module and/or scripts for the actual behavior.
Using the previous modules, the tourney engine is able to offer complex customization while being itself relatively simple:
do prepare a round by
select the players allowed to play
(re-)assemble them in teams
apply the settings
let everybody play until the end of round condition is met
repeat the process if the condition for a end of match isn't met
query the planner to see if the different modules should changed for a different setup
With such a break down of all the task in modules, additional implementation should be relatively trivial, allowing creation and customization of emerging tournaments trends but also hopefully to allow for new behavior to be added by the public, enhancing the game.
-ph
Yes, its one of my big "lets build a complex system to address a moderate problem" ideas...
Right now, we have the following "problems"
a) few ways to combine players as teams
ex: all players divided in 2 competing teams except for a single one-man team, the Minotaur.
b) very little in the way of creating teams based on in-game info
ex: Best player is paired with worst player in a team, second best player is paired with second worst player in a team, etc.
c) no mecanism to select a set of players among all the players and only allow them to play for this round
ex: 1 on 1 round, round robin style, between the 5 players present
d) limited association between the in-game info and the map/configs
ex: when N teams are present, pick among the maps that support so many.
e) limited automatic control on who gets to play among the spectators
ex: all newcomer are spectator except for some pre-defined players
f) limited control on what defines a round
ex: think fortress, but instead of conquering a zone, you need to kill a specific player on the opposing team to win.
g) limited control on what defines a match
ex: an automatically administered round-robin competition between all the players present.
h) no mecanism to change the mode/style of play without admin intervention.
ex: a server runs a regular fortress game, except on sundays from 19 to 21, where it is some clan's exclusive sumo training ground.
What I propose it to have a set of mecanism that could take care of all these parts, and be expandable through scripting. Some sort of a "tourney" engine. This engine should be composed of simple modules, each taking care of a single task:
a) player module: moves players between 3 states: spectator (not allowed to play), sitting on the bench (allowed to play, but not at the moment) and active (can be alive or dead)
b) team module: moves players to and from team
c) round module: monitors the game for a condition (or set of conditions) that will end the round
d) match module: monitors the game for a condition (or set of conditions) that will end the match
e) settings module: determine the settings and map that will be used for the coming round
f) planner module: determine when to change the modules, and which instance of each should be used (changing the modules from a classic "100 point or 10 round" fortress to a "2 out of 3 elimination style competition in teams of 2 players")
Each module should be pretty limited in the service it provide, delegating to sub-module and/or scripts for the actual behavior.
Using the previous modules, the tourney engine is able to offer complex customization while being itself relatively simple:
do prepare a round by
select the players allowed to play
(re-)assemble them in teams
apply the settings
let everybody play until the end of round condition is met
repeat the process if the condition for a end of match isn't met
query the planner to see if the different modules should changed for a different setup
With such a break down of all the task in modules, additional implementation should be relatively trivial, allowing creation and customization of emerging tournaments trends but also hopefully to allow for new behavior to be added by the public, enhancing the game.
-ph
Canis meus id comedit.
-
philippeqc
- Long Poster - Project Developer - Sage
- Posts: 1526
- Joined: Mon Jul 12, 2004 8:55 am
- Location: Stockholm
- Contact:
-
2020
- Outside Corner Grinder
- Posts: 1322
- Joined: Thu Dec 29, 2005 9:21 pm
- Location: the present, finally
too many variables for me
ph
so i avoided the post
on closer inspection
a tournament engine sounds interesting...
opens up lots of alternatives...
sometimes variability and choice can limit development
eg
china became china in 221bc because of two things:
standardisation of language
and standardisation of the axel gauge
this meant that people in different cities could communicate
how is this related to tron?
well
it is up to the players to use the standardised settings of eg fortress
we need mechanisms to help players organise themselves
that's all...
if your fortress engine enables a smooth fortress game
without disturbance from spectators
and can allow for latecomers etc
then i am for it
ph
so i avoided the post
on closer inspection
a tournament engine sounds interesting...
opens up lots of alternatives...
sometimes variability and choice can limit development
eg
china became china in 221bc because of two things:
standardisation of language
and standardisation of the axel gauge
this meant that people in different cities could communicate
how is this related to tron?
well
it is up to the players to use the standardised settings of eg fortress
we need mechanisms to help players organise themselves
that's all...
if your fortress engine enables a smooth fortress game
without disturbance from spectators
and can allow for latecomers etc
then i am for it
hold the line