Anonymous | Login | Signup for a new account | 2024-04-18 02:07 UTC |
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0002941 | Zandronum | [All Projects] Suggestion | public | 2016-12-02 14:30 | 2024-03-17 00:28 | ||||
Reporter | Zalewa | ||||||||
Assigned To | Zalewa | ||||||||
Priority | normal | Severity | minor | Reproducibility | N/A | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | Microsoft | OS | Windows | OS Version | XP/Vista/7 | ||||
Product Version | 3.0-beta | ||||||||
Target Version | 3.1 | Fixed in Version | 3.1 | ||||||
Summary | 0002941: Option to not reset the map when all players lose lives in survival. | ||||||||
Description | Currently survival looks like this: 1. Players get X amount of lives basing on what is the server setting. 2. When player loses all lives he cannot respawn anymore. He must wait until the map is completed or all other players die. 3. All players die. 4. The map is reset. 5. All lives are restored for all players. I would like to be able to disable point 4 with a dmflag. Reasoning is that when playing with a friend the limited amount of lives adds edge to gameplay (normal cooperative is boring because death doesn't punish you). However, if we both die and we were half-way through the map, we don't want to replay this half. Normally we BFGBALL spam everything until we reach the point where we died. Having an option to not reset the map would make the restart more convenient for us. | ||||||||
Attached Files | |||||||||
Relationships | ||||||||||||||||
|
Notes | |
(0016418) Zalewa (developer) 2016-12-04 16:51 |
PR:'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/174/sv_survival_nomapresetondeath-zadmflag/diff [^]' |
(0016428) Kaminsky (developer) 2016-12-05 19:56 |
Could this flag also work in cases where all players leave (either by spectating or disconnecting) the game? That way, players who try to rejoin an empty game can still continue where the map was left off instead of restarting the map. |
(0016429) FascistCat (reporter) 2016-12-05 23:29 |
So this is a 'wait for everyone else to die to re-join the fray' option? That could be ok. |
(0016467) Zalewa (developer) 2016-12-11 14:07 |
Quote from Kaminsky I implemented this partially: 'https://bitbucket.org/zalewa/zandronum/commits/8d6b0ef75ae2fc5483c80b7b3710bab12604d07f?at=default [^]' If all players leave, the map will reset to the default state as usual. But as long as there's at least one in the join queue the map will continue. |
(0016934) Torr Samaho (administrator) 2017-03-05 16:57 |
I added your pull request for this a while ago:'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/174/sv_survival_nomapresetondeath-zadmflag [^]' |
(0016944) Zalewa (developer) 2017-03-05 19:47 edited on: 2017-03-05 19:48 |
We're playing survival with this option on for some time now. We haven't observed any serious problems. The map switch is messy, but harmless, when players die upon map exit (for example, with the popular barrel/Romero explosion map exit). The next map starts from players being frozen and the game going through the "respawning dead players" state, but the behavior is similar when the new flag is off. Once this sequence goes through, players can continue the game normally. Apart from this, everything seems to function correctly. |
(0017506) WaTaKiD (updater) 2017-05-01 23:22 |
i was under the impression that weapons/ammo/etc being kept as mentioned here 'https://bitbucket.org/Torr_Samaho/zandronum/commits/a1996234a5d05f70e41472a4a1050f5fcd9926cd [^]' would only take affect if sv_survival_nomapresetondeath was true but that is not the case as it instead seems that such things being kept is the new default behavior, and that if we want the old behavior we would have to enable all 6 sv_coop_lose* cvars was this truly intended or is it a bug? |
(0017508) Zalewa (developer) 2017-05-02 07:21 edited on: 2017-05-02 07:21 |
This only happens when the map is completed. The map is considered beaten by the players and the dead ones recover inventory. If all players die, only then the inventory is reset - if you'd ask me I'd say this behavior is questionable, too. IMO players should be reverted to the inventory they started the map with. So, Quote yes, it was intended. |
(0017510) WaTaKiD (updater) 2017-05-02 09:07 |
while i support the new behavior being implemented in some way, im against it becoming the default behavior i have not asked what anyone else thinks of this change, but i feel that if the default survival behavior we've been used to for several years was going to possibly change then there shouldve been a forum thread to atleast let others know whats up and they can discuss it, seeing as such behavior wasnt even mentioned in this ticket, but in the pull request where regular users dont tread but in the end, i dont even play that much these days anyways (look how long it took for me to notice this new behavior which has been around for several months) and the old behavior can still be activated (albeit with a whopping 6 cvars, but thats nothing a .cfg cant take care of), so maybe its not really a big deal |
(0017511) Cutman (reporter) 2017-05-02 09:27 |
I agree, this should be off by default as everyone is used to the old rules of survival and I imagine a lot of people prefer them. |
(0017516) Zalewa (developer) 2017-05-02 12:04 |
Torr should decide. In my opinion the original behavior that everyone is used to is wrong. Why should you keep items when you die but still have lives remaining but lose them when you run out of lives?Quote Not really. The sv_coop_ flags will also remove items when you still have lives remaining, not only between maps. |
(0017520) WaTaKiD (updater) 2017-05-02 17:26 |
Quote from "Zalewa" yea youre right, i was only thinking of 1 life survival at the time, sorry now, with that realization, im ever so slightly more against this new behavior since the old behavior seems even further out of grasp (unless someone with rcon wants to sit there and forcespec anyone who loses all their lives, or hit binds that activate/deactivate all 6 sv_coop_lose* cvars just before/after changing to the next map, to try and simulate the old behavior) |
(0017521) Torr Samaho (administrator) 2017-05-02 19:17 |
AFAIR, back then Zalewa argued that we have enough options already and shouldn't introduce yet another flag to toggle the inventory behavior of dead spectators. I'm fine with the new behavior and would keep it if there are no strong objections from the community. WaTaKiD, feel free to make a forum thread about this. If there is enough demand to warrant a flag for this, I can easily add it. As a side note, I suspect that the old behavior was not an intentional decision, but is just what you get when you turn a player into a dead spectator and back without taking special precautions. |
(0017523) Ivan (reporter) 2017-05-02 20:13 |
The change introduced here breaks DnD's intended behavior. Special precautions need to be taken in order for it to work apparently. Watakid can confirm/deny this. I'm not sure what exactly is the change either. However the old behavior actually does make sense. Think about it: You're not out of the game until you've lost all your lives. That makes perfect sense. It's like reloading a saved game. You don't lose your stuff when you reload a save game. |
(0017524) Torr Samaho (administrator) 2017-05-02 21:25 |
Quote from Ivan If that's the case, we definitely need an option to restore the old behavior. Can you elaborate how it breaks DnD? Quote from Ivan Dead spectators keep their inventory. So when they are revived, they still have have their inventory as if they just respawned normally without being a dead spectator in between. |
(0017525) WaTaKiD (updater) 2017-05-02 21:39 |
i have made a forum thread to hopefully gather more opinions regarding this behavior change: 'https://zandronum.com/forum/viewtopic.php?f=26&t=8295 [^]' |
(0017527) Combinebobnt (reporter) 2017-05-02 22:50 edited on: 2017-05-02 23:18 |
I have a strong objection to keep the new behavior as standard. You can make the new behavior optional or whatever and that is fine, but the old should be default. I don't know why people have a "too many options is bad" mindset if the default options are the most sensible. It lets you customize the port/server to your personal preferences so that making compromises is completely unnecessary. The normal behavior will be followed in the majority case and for those with different tastes, they can look up these obscure settings and play the way they want to play. It's a win-win. Want proofs? Look at like every single new gameplay mod for zdoom. They each come with a billion optional settings in the options menu and nobody has a problem. Those who care less don't ever have to open that menu and just play normally. Arguing why this new behavior should not be the default: I'm lucky in that I don't really have to argue it myself; you said it best already. "when playing with a friend the limited amount of lives adds edge to gameplay": This is the distinction between cooperative and survival; if you die, there is punishment. Some bfgball spam crap seems like an awful solution to your problem, I have a simpler one: it's called don't die in the first place. You can't both have and not have an 'edge' to the gameplay at the same time. "normal cooperative is boring because death doesn't punish you": However what you say is that when you guys both die, you just start at the spot at where you died with pistol spawn. This is literally no different than playing cooperative with SV_SameSpawnSpot true & SV_Coop_LoseInventory true, although your ticket just adds a lives counter to this. Can be done easily with an acs wad. "Why should you keep items when you die but still have lives remaining but lose them when you run out of lives?": This is what 'having lives' means in the first place... It's so definitive I'm kind of baffled you question this. It's like the old arcade games where you don't actually lose until you run out of lives. What more is there to understand lol. If you want to lose inventory on each respawn, SV_Coop_LoseInventory true. Ivan brings up the good point that you are going to break a bajillion wads with your selfish personal playstyle (dnd, levelmaster, whodunit or zombiehorde etc. servers that don't switch maps immediately, the challenge from wrath of chronos, I can keep going...). Great going. The sum of this is why this should not be the new default behavior. Don't ruin it for everyone else, just keep it optional. An easy to understand concept. I'm glad watakid posted a thread because it looks like this almost got in and I had no idea. Kind of scares me esp since I watch the tracker... |
(0017529) Razgriz (reporter) 2017-05-02 23:34 |
I disagree with it being the new default behavior, there's no need to change the way survival has been played for almost ever just because one person thinks it should be played differently. Yes it should be an option, why because Zandro is about having the option to do something, why else have all these flags in the first place. |
(0017530) Ivan (reporter) 2017-05-03 00:03 |
@Torr, the problems happen with people losing their weapons for no apparent reason and not receiving their starting weapons after having lost all lives, or something along those lines. Watakid reported the bug, and I suspected it wouldn't be DnD because nothing was changed in that area. So we pinpointed the problem to this specific change. |
(0017531) WaTaKiD (updater) 2017-05-03 00:10 |
Quote from "Ivan" turns out this was because the server owner had enabled sv_coop_loseweapons |
(0017532) Catastrophe (reporter) 2017-05-03 00:27 |
I am changing my stance to strong rejection. While I really like the idea that's described in the OP, forcing a change of the default behavior in Survival to achieve this is a big NO. |
(0017533) Ivan (reporter) 2017-05-03 01:08 |
@Watakid then I think this is the problem where people show up with whatever weapons they previously had, but started out as level 1 (or something) that I heard a few weeks ago? Eitherway there's a problem that causes DnD to not behave properly with the current behavior. |
(0017534) WaTaKiD (updater) 2017-05-03 02:19 |
Quote from "Ivan" sounds like sv_coop_loseinventory mightve been enabled, which would mean losing inventory items that track experience points, levels, etc (note: i have not tested this, its just my guess) |
(0017536) Torr Samaho (administrator) 2017-05-03 06:05 |
Alright, the thread and the comments here give a very clear picture. I'll restore the old behavior as default and add an option that allows dead spectators to regain their inventory when being revived after a map change. Any suggestions for the name of the corresponding CVAR? |
(0017538) Zalewa (developer) 2017-05-03 07:45 |
Quote Some suggestions: * sv_survival_deadspectators_keepinventory (or _keepitems) - that lines up with the sv_survival_nomapresetondeath CVAR. * sv_coop_deadspectators_noloseitems - lines up with other sv_coop_ flags that manage inventory keeping * sv_deadspectatorskeepitems - short, but still a mouthful * sv_deadplayerskeepinv - shorter * Any permutation of the above. |
(0023412) Ru5tK1ng (updater) 2024-03-17 00:28 |
Long resolved with sv_Survival_NoMapResetOnDeath and sv_DeadPlayersCanKeepInventory |
This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why. |
|
Supporters: | Kaminsky |
Opponents: | Catastrophe Combinebobnt Ru5tK1ng Razgriz Ivan mifu |
Issue History | |||
Date Modified | Username | Field | Change |
2016-12-02 14:30 | Zalewa | New Issue | |
2016-12-02 14:31 | Zalewa | Description Updated | View Revisions |
2016-12-03 14:19 | Zalewa | Assigned To | => Zalewa |
2016-12-03 14:19 | Zalewa | Status | new => assigned |
2016-12-04 16:51 | Zalewa | Note Added: 0016418 | |
2016-12-04 16:51 | Zalewa | Status | assigned => needs review |
2016-12-05 19:56 | Kaminsky | Note Added: 0016428 | |
2016-12-05 23:29 | FascistCat | Note Added: 0016429 | |
2016-12-11 14:07 | Zalewa | Note Added: 0016467 | |
2017-03-05 16:57 | Torr Samaho | Note Added: 0016934 | |
2017-03-05 16:57 | Torr Samaho | Status | needs review => needs testing |
2017-03-05 19:47 | Zalewa | Note Added: 0016944 | |
2017-03-05 19:48 | Zalewa | Note Edited: 0016944 | View Revisions |
2017-05-01 23:22 | WaTaKiD | Note Added: 0017506 | |
2017-05-02 07:21 | Zalewa | Note Added: 0017508 | |
2017-05-02 07:21 | Zalewa | Note Edited: 0017508 | View Revisions |
2017-05-02 09:07 | WaTaKiD | Note Added: 0017510 | |
2017-05-02 09:27 | Cutman | Note Added: 0017511 | |
2017-05-02 12:04 | Zalewa | Note Added: 0017516 | |
2017-05-02 17:26 | WaTaKiD | Note Added: 0017520 | |
2017-05-02 19:17 | Torr Samaho | Note Added: 0017521 | |
2017-05-02 20:13 | Ivan | Note Added: 0017523 | |
2017-05-02 21:25 | Torr Samaho | Note Added: 0017524 | |
2017-05-02 21:39 | WaTaKiD | Note Added: 0017525 | |
2017-05-02 22:50 | Combinebobnt | Note Added: 0017527 | |
2017-05-02 23:18 | Combinebobnt | Note Edited: 0017527 | View Revisions |
2017-05-02 23:34 | Razgriz | Note Added: 0017529 | |
2017-05-03 00:03 | Ivan | Note Added: 0017530 | |
2017-05-03 00:10 | WaTaKiD | Note Added: 0017531 | |
2017-05-03 00:27 | Catastrophe | Note Added: 0017532 | |
2017-05-03 01:08 | Ivan | Note Added: 0017533 | |
2017-05-03 02:19 | WaTaKiD | Note Added: 0017534 | |
2017-05-03 06:05 | Torr Samaho | Note Added: 0017536 | |
2017-05-03 07:45 | Zalewa | Note Added: 0017538 | |
2017-11-13 21:40 | Zalewa | Relationship added | related to 0003138 |
2017-11-13 21:40 | Zalewa | Relationship added | related to 0003139 |
2017-11-13 21:45 | Zalewa | Relationship added | related to 0003339 |
2024-03-17 00:28 | Ru5tK1ng | Note Added: 0023412 | |
2024-03-17 00:28 | Ru5tK1ng | Status | needs testing => resolved |
2024-03-17 00:28 | Ru5tK1ng | Resolution | open => fixed |
2024-03-17 00:28 | Ru5tK1ng | Fixed in Version | => 3.1 |
2024-03-17 00:28 | Ru5tK1ng | Target Version | => 3.1 |
Copyright © 2000 - 2024 MantisBT Team |