Is it possible to make map entities dependant on # players

(Ifurita) #1

I see that it is possible to adjust scripting based on gametype. Is it possible to setstate an entity as default/invisible depending on the number of players at the start of the game?

(Java.Lang) #2

Well you can query server settings…

Take a look at this thread… it will give you information on how to query, and to convert your if-then-else by making use of triggers.

(Ifurita) #3

hmmm, will look into that. Any server people here who know what cvar counts the number of players. You could add walls that only exist if the player count is small. Then the routine would kill itself after spawn

(Java.Lang) #4

The problem with that, is if more people join the server, the count changes…

You could always just hook up relays to your individual spawn entities. I am sure you are familiar with how spawn entities work… that someone will spawn in the closest available spawnpoint to the blob… That being said, if a spawn entity is spawned in… it would fire off a relay that could doo whatever you wanted.

Say for instance a room that is locked, would remain locked until a spawn is fired, then it would open. Not sure if that is what you are wanting to do.

(Ifurita) #5

No, because you can run the routine only at spawn, then have it kill itself. We did the same thing with Vengeance where a random number is generated, the objectives are placed in one of 3 bunkers, then the other two entities are removed.

(SCDS_reyalP) #6

Hmmm, spawn points trigger their targets when players spawn. So if you target the intial spawn points on something whose script increments a counter, and then use a timer so it stops adding to the count before the next spawn wave, this should work most of the time to figure out how many started the game (obviously, it will not deal correctly with late joiners).

pseudocode


game_manager
{
// accums used for spawn counting
// 0 number of players spawned
// 1 bit 1 enable/disable spawn counting
...
 trigger count_spawns 
 {
// only 
  accum 1 abort_if_bitset 1
  accum 0 inc
 }
 trigger finish_spawn_count 
 {
  accum 1 bitset 1
// do whatever other stuff to set up map based on count value.
...
 }
...
}
// target_script_trigger for spawn counting, triggered via initial spawn points
spawn_counter {
 trigger count {
   trigger game_manager spawn_count
 }
}
// target_script_trigger to finish counting, triggered target_delay, which is in turn
// trigger from game start (alertentity from game_manager spawn ?)
// might also be able to just use a delay in some scripts spawn block.
spawn_counter_finish {
 trigger finish {
   trigger game_manager finish_spawn_count
 }
}

OSPs random spawn offset may cause a problem, since the first respawn wave isn’t a predicable time after the initial spawn. Still, if your time is something like 1 second, the chances of people /killing and respawning in that time are pretty small. You also have to make sure the changes are far enough from the spawn area that players cannot reach them before the delay expires.

That said, I don’t see this being a good gameplay characteristic. Better just to make the map one way all the time and accept that it has a certain ideal number of players. If you want it to play better with larger/smaller numbers, make a new version.

Note that you could use the same map with different scripts, so that server admins could choose the many or few player map script, depending on the size of the server.

(SiliconSlick) #7

A quick “cvarlist” on [ND80]The Grotto doesn’t indicate
anything useful.

Given my rather limited experience with mapping, one idea
that springs to mind is something like this (a different spin
on the previous post).

Since the spawn points (team_CTF_red/bluespawn) closest to
the spawn marker (team_WOLF_objective) are used first, perhaps
sets up a trigger surrounding one of the spawns for the first
15-30 seconds or so.

e.g. given the following spawn marker and spawn points

M 1 2 3 4 5 6 7 (<<< represents geographic proximity)

you could possibly put a trigger around spawn point 4 for
each team and if it is activated on both sides, then add/remove
the needed walls (assumes a certain amount of team balance).

Be sure to set up an accum not to do it twice. Set up a timer
to deactivate the trigger shortly after round starts.

Crude and probably open to some problems (e.g. people
spawning at spot 3 then running through the trigger at 4
[actually, that might be solvable by setting the trigger and
spawn point high so they drop through it as they spawn])
but it might work.

SiliconSlick

(G0-Gerbil) #8

Church did that originally, it counted the players at round start and set spawn times appropriately.
It worked almost exactly how SCDS_reyalP described it I think.

Only problem is, as he says, numbers change.
It was easier in RTCW where you had seperate ‘initial spawns’ from ‘in-game spawns’ because you could detect if new players joined (but not left).
The end result is always a bit inaccurate however, so just make sure you don’t use it for anything too critical to map balance.

(nUllSkillZ) #9

Couldn’t this be achieved by creating several scripts for several server sizes?
And let the admins decide which script to use?
So there could be mymap_6.pk3 for 6 players mymap_12.pk3 for 12 players and so on.
Then only thing to do is to delete the unused scripts.

Alternatively there could be one script with commented lines that could be uncommented by server admins.

(SCDS_reyalP) #10

AFAIK, the idea was to dynamically adjust depending on how many people were on the server.

Note that you could probably do this in conjunction with a console bot (like etadmin_mod which already can limit panzers etc based on the number of players) and the cvar_ mapscript stuff

(LaggingTom) #11

jet Pilot is figuring out how to change the trigger_multiple entity to allow for a key called “players” which will could the entities within it.