|Affected ArmA II version:||1.56 BETA||First affected ArmA II version:|
|Reproduced by another DH user:||No||Single / Multi Player?:|
|I am using some Mods:||No||BIForumURL:|
|I am using:||NGUrl:|
|Reproducible for you:||No||WIKIurl:|
|Related to content of DLC:|
Add a new setPlayerRespawnTime command (to work in conjunction with the existing playerRespawnTime command).Implementation requirements:
- It simply changes the default respawnTime value, so it should be very easy to implement.
- I think it would only need to operate on the player's local client.
- It needs to be able to be set multiple times during the game (different value for each death).
- It's especially useful for PvP game modes.
- It should also be able to be changed even while the player is dead with the respawn timer already started.
- In some cases, the default time could be 30 seconds or even 600 seconds, which can then be adjusted to suit.
- The display of the timer can be controlled by the mission anyway, so the change won't be noticable.
- It would probably be best if the respawn time was reset to the default respawnDelay=X (set in description.ext), each time a player is respawned.
- If the player is dead and waiting to respawn, you could force an immediate respawn by setting setPlayerRespawnTime to zero
- For example, once a suitable spawn position is chosen.
- Another example use is to prevent a player spawning somewhere which has enemy waiting there to kill them upon spawning.
The benefit of this is to avoid having to create special safe holding areas on the map to spawn the players until they are ready to be moved into the proper mission areas due to additional mission controlled time delays and penalty times.
Eg: If using 'wave (group) respawn', or if using a respawn selection dialog, safe area spawning, penalty delay times, etc.
These special areas need all sorts of special checks: to prevent players entering and/or killing the spawned players while they're "waiting to spawn" or return to the proper area, scoring handling, ROE handling, etc all because there is no way to delay the spawning of a player.
All of this could be solved with a simple client-side value change. (This was requested 2 years ago on the old wiki wishlists.)
Updated by kju about 6 years ago
- Due date set to 12/14/2010
- Status changed from New to Feedback
Same as #11192?
Updated by Dr_Eyeball about 6 years ago
Yes, looks like it's the same request. (Searched for playerRespawnTime and found nothing.)
Could you link this topic as a duplicate, for reference. It contains 2 points for consideration in the implementation.
You'll also have to start monitoring and crack down on the idiots who keep voting negative on these requests. It's getting out of hand.
Wish we could see who is voting in order to explain to them what it's intended purpose is. Seems people are of the mindset that if something is of no benefit to them directly, they comment against requests, rather than considering the overall benefits to the whole community.
Updated by Xeno about 6 years ago
I don't think that votes have a meaning at all.
As you can see I've requested the same like you 6 months ago and the chance that it will ever be implemented equals zero.
(And it can't be such a dramatic change as respawn time is a local client thing).
As long as it is not important for BIS we simply don't get it or maybe in a few years.
Beeing a little bit sarcastic here...
Instead we get features like playing a movie ingame in a resource which nobody ever asked for :(
Updated by kju about 6 years ago
- Due date deleted (
- Status changed from Feedback to Duplicate
Thanks. Merged your good report with the one from Xeno.
Overall people seem to use the voting sensible.
Also Xeno if you look into the addressed issues, apart from CTD,
most were among the highest votes ticket.
So it is simple not true that votes do not matter.
At the same BI foremost adds functionality they need for their plans.
Nothing new or non obvious. The marketing talk we all can understand and ignore.