0001229: Lives management

Notes
(0005620) Torr Samaho (administrator) 2012-12-30 12:06	Yeah, we should definitely add a ACS function that allows to check the number of lives left. The main question is how exactly we want to handle this to stay compatible with ZDoom. GetPlayerInfo would be an obvious candidate, here we'd have to make sure to use a number for the property ZDoom will never use. Or we add a completely new function for this like we did for PlayerIsSpectator.

(0005632) Toxicity (reporter) 2012-12-31 01:20	I think it would be better to have a completely new, Zandro-exclusive function. Like GetPlayerLives. Because then we can also implement things like AddPlayerLives, TakePlayerLives, or SetPlayerLives.

(0005637) Torr Samaho (administrator) 2012-12-31 10:01	Good point. A GetPlayerLives/SetPlayerLives function pair sounds good to me.

(0005651) Torr Samaho (administrator) 2013-01-02 11:24	I added the ACS commands GetPlayerLivesLeft and SetPlayerLivesLeft. They directly access the values Zandronum is using internally and thus are named accordingly, i.e. that's why their names end with "Left". This build supports the new commands. To use them add -104:GetPlayerLivesLeft(1), -105:SetPlayerLivesLeft(2), to your zspecial.acs.

(0006035) Qent (updater) 2013-02-17 01:05 edited on: 2013-02-17 01:46	Am I right to conclude that these are not in the official testing build (wiki'd anyway)? When adding lives, if sv_maxlives is 0 in Survival, they persist after spectating and rejoining (add 9 lives, all spectate, rejoin, you still have 9 lives). It looks like that was maybe intentional? Spectating works as expected with sv_maxlives 1, though. Also GetPlayerLivesLeft seems to return "lives" (as seen on the HUD) - 1 if the player has lives remaining, and 0 otherwise. Also intentional?

(0006036) Dusk (developer) 2013-02-17 01:16 edited on: 2013-02-17 01:18	Internally the life count is the amount of lives the player has after he dies (so it's 0 if you're on your last life.) To differentiate between a dead player and one still alive is done by a spectator check - in ACS this would be PlayerIsSpectator. Do we want to expose this to the modder though as is? I found the life variable rather confusing when I first tried to work with it. Would it be better to expose the "true" amount of lives (as seen on the HUD, so last life = 1 and 0 = dead) rather than on the internal variable? Though in such case, what if the variable is set to 0? Set the lives left to 0 and kill off the player?

(0006042) Torr Samaho (administrator) 2013-02-17 09:32	Quote from Qent Am I right to conclude that these are not in the official testing build (wiki'd anyway)? No, the official 1.1 beta build should support this. Quote from Qent When adding lives, if sv_maxlives is 0 in Survival, they persist after spectating and rejoining (add 9 lives, all spectate, rejoin, you still have 9 lives). It looks like that was maybe intentional? Spectating works as expected with sv_maxlives 1, though. Good point. "sv_maxlives 0" in survival is a special case. It should behave like "sv_maxlives 1". I'll look into this. Quote from Qent Also GetPlayerLivesLeft seems to return "lives" (as seen on the HUD) - 1 if the player has lives remaining, and 0 otherwise. Also intentional? Yes. As Dusk mentioned it returns Zandronum's internal life counter. Quote from Dusk Do we want to expose this to the modder though as is? Yes, I'd like to just expose Zandronum's internal counter to ensure that modders use the live system as it is intended to be. Lives are no subtracted when dying (that's why you shouldn't try to do anything based on GetPlayerLivesLeft in the death script), but when respawning. "GetPlayerLivesLeft == 0" + "player dead", doesn't necessarily mean that the player can't respawn. If the player died from spawn telefragging for instance, he is still allowed to respawn.

(0006043) Torr Samaho (administrator) 2013-02-17 10:01	This hopefully takes care of the "sv_maxlives" 0 inconsistencies.

(0006048) Qent (updater) 2013-02-18 00:45	Yes, it works like sv_maxlives 0 now.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	Konar6 ZzZombo Combinebobnt
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2012-12-28 17:25	Cutman	New Issue
2012-12-30 12:06	Torr Samaho	Note Added: 0005620
2012-12-31 01:20	Toxicity	Note Added: 0005632
2012-12-31 10:01	Torr Samaho	Note Added: 0005637
2013-01-02 11:24	Torr Samaho	Note Added: 0005651
2013-01-02 11:24	Torr Samaho	Assigned To	=> Torr Samaho
2013-01-02 11:24	Torr Samaho	Status	new => needs testing
2013-01-02 11:25	Torr Samaho	Product Version	=> 1.0
2013-01-02 11:25	Torr Samaho	Target Version	=> 1.1
2013-02-17 01:05	Qent	Note Added: 0006035
2013-02-17 01:05	Qent	Note Edited: 0006035	View Revisions
2013-02-17 01:12	Qent	Note Edited: 0006035	View Revisions
2013-02-17 01:16	Dusk	Note Added: 0006036
2013-02-17 01:17	Dusk	Note Edited: 0006036	View Revisions
2013-02-17 01:18	Dusk	Note Edited: 0006036	View Revisions
2013-02-17 01:46	Qent	Note Edited: 0006035	View Revisions
2013-02-17 09:32	Torr Samaho	Note Added: 0006042
2013-02-17 10:01	Torr Samaho	Note Added: 0006043
2013-02-18 00:45	Qent	Note Added: 0006048
2013-04-05 23:41	Dusk	Status	needs testing => resolved
2013-04-05 23:41	Dusk	Fixed in Version	=> 1.1
2013-04-05 23:41	Dusk	Resolution	open => fixed
2018-09-30 20:23	Blzut3	Status	resolved => closed

Relationships