Tremulous Forum
General => Feedback => Topic started by: tskuzzy on October 17, 2009, 10:26:52 pm
-
I haven't really thought this idea out much, so it could be a very bad idea.,,
I see a lot of people complaining about how single goons can destroy a feeder human team (even with one or two good humans on them) within minutes. Why not let players get a free automatic spawn upon joining a team? The game gets more balanced once both teams get a decent number of people out on the playing field so why not start out that way?
Discuss.
-
this has been suggested several times, and the main issue is that it's complicated to find a spawn point for all the players.
-
this has been suggested several times, and the main issue is that it's complicated to find a spawn point for all the players.
Why not just spawn at the telenode? :o
-
actually guys, there are binds that can already do this!
im not sure what they are... (talk to me ingame and i could help you) but i know volt made them.
the bind puts you to the team you want and spawns you
-
this has been suggested several times, and the main issue is that it's complicated to find a spawn point for all the players.
Why not just spawn at the telenode? :o
that works for one player, not for the whole team.
-
Why not just spawn at the telenode? :o
that works for one player, not for the whole team.
Well, they're not really spawning all at once per se. You could still have them spawn one at at time at the telenodes albeit with a much lower wait time.
Its also not as if 20 players are joining human team all at once. Its more like 1 person/second or so.
-
The first thing that came to mind was, what if you want to be a builder when you join?
Theoretically there could be a variable that the client sends telling the server what default class they wanted to spawn as, but that seems like more trouble than it's worth.
Alternately the client could be set to automatically send a spawn request of the desired type when joining a team, but it doesn't take long to select a class form the list anyway, so I don't see how that would really help.
-
Starting with a low spawn delay then rising it by time might work. But I have doubts.
-
The first thing that came to mind was, what if you want to be a builder when you join?
Theoretically there could be a variable that the client sends telling the server what default class they wanted to spawn as, but that seems like more trouble than it's worth.
Alternately the client could be set to automatically send a spawn request of the desired type when joining a team, but it doesn't take long to select a class form the list anyway, so I don't see how that would really help.
Nono. I meant you get one "free" spawn right after you join the team. Not spawn immediately after joining.
-
:o Oops... Well, your post makes much more sense now.
-
The first thing that came to mind was, what if you want to be a builder when you join?
Theoretically there could be a variable that the client sends telling the server what default class they wanted to spawn as, but that seems like more trouble than it's worth.
Alternately the client could be set to automatically send a spawn request of the desired type when joining a team, but it doesn't take long to select a class form the list anyway, so I don't see how that would really help.
Nono. I meant you get one "free" spawn right after you join the team. Not spawn immediately after joining.
the delay is on the nodes, not the players.
-
the delay is on the nodes, not the players.
Well, it wouldn't be terribly difficult to implement a second queue for players that just joined the team. This second queue would act alongside the normal spawn queue except with a much lower spawn rate.
-
I don't want to discourage you but it might be terrible difficult depending on the current implementation(which I don't know).
Ignore my comment if you know the implementation...
-
I don't want to discourage you but it might be terrible difficult depending on the current implementation(which I don't know).
Ignore my comment if you know the implementation...
No, I haven't had a look through the code. But as a programmer myself, I have a pretty darn good guess. :P
-
Fun fact: if you somehow managed get 64 players on a team to all join the spawn queue at once, the game would think that the queue was empty and wouldn't spawn any of them.
-
Fun fact: if you somehow managed get 64 players on a team to all join the spawn queue at once, the game would think that the queue was empty and wouldn't spawn any of them.
o_o
Why would that happen? I can't imagine that would be caused by an integer overflow...
-
The spawn queues are simple circular buffers with MAX_CLIENTS == 64 entries, so it uses modulo 64 arithmetic, and 64 == 0 (mod 64).
-
The spawn queues are simple circular buffers with MAX_CLIENTS == 64 entries, so it uses modulo 64 arithmetic, and 64 == 0 (mod 64).
O_O
Why would the spawn queue be implemented as a circular buffer?? That makes no sense :o What's wrong with a simple linked list?
-
qvms don't have access to (a proper) malloc(), so static memory is used heavily.
-
Actually you wouldn't need malloc() if you store the link pointers in the client_t structures.
-
But if you did that for everything, how many millions of linked lists would you end up with?
-
You know what someone brought up an idea in another topic with something similar to this that oculd solve spawn killers...
In the other post it said something about 2 seconds invincibility so they could spawn and by the time their invincibility wore off they could spawn another person.
:telenode: :human: :tyrant:-> :telenode: :human: :human: :tyrant: or :egg: :egg: :dretch: :granger: :battlesuit: -> :egg: :egg: :dretch: :dretch: :dretch: :granger: :battlesuit:
but then again by the time they get to your nodes you'd have lost the game anyway...