|
Notes |
|
|
|
|
It seems that you only have to wait in DM. In coop, you simply respawn inside another player. If you respawn inside a player, no teleport fog will appear. |
|
|
|
|
|
|
|
|
|
|
|
(0004439)
|
|
Qent
|
|
2012-08-24 21:29
|
|
|
Why would you want such a thing? Then players could prevent each other from spawning by blocking the spawns. |
|
|
|
(0004441)
|
|
Dusk
|
|
2012-08-24 21:51
|
|
Please don't bump tickets just to say that you support a feature...
Is this even needed anymore since sv_unblockplayers exists? |
|
|
|
(0004445)
|
|
Qent
|
|
2012-08-25 06:12
|
|
|
Based on the first note, I thought it would be mainly for DM when sv_unblockplayers is not used. I think that could use some clarification as well: should compat_norespawntelefrag work differently in co-op vs. DM? In vanilla, do players get stuck in one another, or does it work basically like sv_unblockplayers? |
|
|
|
|
|
How do other multiplayer ports like ZDaemon or Odamex handle this? |
|
|
|
(0004466)
|
|
Konar6
|
|
2012-08-26 18:32
|
|
ZDaemon utilizes a server CVAR coop_telefrags: "It's a boolean. It controls whether player-to-player telefragging is enabled in coop/survival modes"
Also: "If a spawn is blocked by a player or monster, they will get telefragged except for the first 5 seconds of the level. That should give players enough time to move off the spawn points" |
|
|
|
|
|
Let me clarify: What does ZDaemon do in DM? For coop we already have sv_unblockplayers to resolve the issue. |
|
|
|
(0004479)
|
|
Konar6
|
2012-08-26 21:35
(edited on: 2012-08-26 21:37) |
|
Then there is no such telefrag setting in ZDaemon. In DM players get always telefragged.
However, the spawnpoint selection system won't let a player onto a spawnpoint where it would telefrag another player standing too close to it. It goes through available spawnpoints until it finds a free one. Only if there is no free spawnpoint, a telefrag will happen.
I'm not too sure how Zandronum handles this.
|
|
|
|
(0004962)
|
|
Watermelon
|
2012-10-05 14:49
(edited on: 2012-10-05 14:51) |
|
Does sv_unblockplayers keep players only unblocked until they move out of the range of another player? Or do they just move through players though the entire map like +THRUSPECIES was on? Just because if it was something that stays on the entire match, it'd change competitive gameplay too much from the standard. If it only blocks them for the first few seconds or until they move out of the actor's radius, then sv_unblockplayers should do the trick here.
EDIT: I think ZD checks each spawn (in CTF mode at least) to ensure players do not telefrag another person, unless all the teleport spawns are filled upon which it will forcefully telefrag the player). Could be wrong here though.
|
|
|
|
(0004967)
|
|
Dusk
|
|
2012-10-05 19:16
|
|
|
sv_unblockplayers behaves like +THRUSPECIES in this regard, yes. |
|
|
|
|
Damn
I checked it with co-op today, sv_unblockplayers would change competitive modes like CTF too drastically for the benefit given by no telefrags. |
|
|
|
|
sv_unblockplayers is only intended for coop. And since
Quote from Konar6
Then there is no such telefrag setting in ZDaemon. In DM players get always telefragged.
competitive players can't be used to having the requested behavior. IMHO preventing telefrags in DM is not a good idea anyway since the players could block the spawns deliberately to prevent other players from respawing. |
|
|
|
(0004998)
|
|
Watermelon
|
2012-10-06 17:00
(edited on: 2012-10-06 17:01) |
|
I think the way ZD and Oda do it is through iterating all the possible spawn spots and checking if any team player is in the way, and if it doesn't find one suitable to spawn then it forcefully telefrags a team mate.
I figure it'd go like this pseduo-code:
// Check for spawns
for (int spawnLocation = 0; spawnLocation < allTeamSpawnLocations; spawnLocation++) {
if (player.inRadius([spawnLocationHere])
continue;
else
// Spawn + end here with a return; or something
}
// This would be the normal code we already have:
SpawnPlayer(one of the random spawnspots); // Whatever the code is normally
|
|
|
|
|
This was fixed in zdoom, but the problem is it requires a big backport.
This is a pretty irritating thing, do we want a quick patch or just to leave it until a backport? |
|
|
|
|
|
If water was telling the truth, whatever fix he was talking about should be in our codebase as of 3.0. Since the ticket went off topic and shifted to CTF telefragging, 2791 will focus on that separate issue. |
|