0001318: sv_unblockplayers doesn't work with different classes

(0006747)
Empyre (reporter)
2013-07-22 16:02

Oops! Sorry for making a duplicate of this. I should have searched first. Lesson learned.

(0006770)
ZzZombo (reporter)
2013-07-23 14:26

I guess, better have two flags, one for unblocking of players, and another for firing.

(0008708)
Watermelon (developer)
2014-05-05 22:30

I believe this was already fixed for 1.3?

(0010206)
Leonard (developer)
2014-08-15 07:05

'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/66/sv_unblockplayers-now-works-with-different/diff [^]'

(0010208)
Hypnotoad (reporter)
2014-08-15 11:11

I'm not sure this /should/ be fixed, if I want players of different classes to pass through each other, I set them to be the same species in decorate. Sometimes I want some players to pass through each other, and some players not to, I feel this could be the same for other mods, and forcing all players of different classes to pass through each other might break compatibility.

(0010209)
Leonard (developer)
2014-08-15 16:46
edited on: 2014-08-15 16:48

Since you already use the Species property, could you not add the THRUSPECIES flag on your classes instead?
And if you want it to be toggleable, you can already set it via ACS so I guess this shouldn't be a problem?

(0010219)
Hypnotoad (reporter)
2014-08-19 14:30
edited on: 2014-08-19 14:38

Can you please clarify a way to toggle thruspecies in ACS without gross hackery? The only way I can think of is giving an inventory on spawn that does A_Changeflag, but this isn't very reliable and fairly hackish.

Furthermore, you did not address the issue of compatibility, are you sure this wont break other older mods that might want both teams to be unblocked, or might only want actors of the same species to be blocked?

I don't see why simply using a patchwad to set different species on each team isn't a superior solution, rather than changing engine behavior which potentially breaks compatibility of older mods.

If you can clarify a clean way to toggle it, and ensure no compatibility problems, then I'd support this.

edit: in fact what I'd suggest is adding an additional setting, having sv_unblockplayers 2 will use the new proposed behavior, ignoring classes, and sv_unblockplayers 1 retains the current behavior.

(0010220)
Hypnotoad (reporter)
2014-08-19 16:12

Leonard and I have discussed and come up with the idea of having additional flags since there are many scenarios we might want. Our idea is to have the flag sv_unblockplayers unblock all players no matter what, but then to introduce two new flags, sv_blockteams and sv_blockspecies, that keep different teams and/or different species/classes blocked if unblockplayers is on.

(0010221)
Dusk (developer)
2014-08-19 18:21

I don't really understand why blocking per species is necessary. Can you elaborate on why it would be useful?

IMO enemy players should always block each other, even if sv_unblockplayers is on. The current behavior is an oversight and should be fixed.

(0010222)
Torr Samaho (administrator)
2014-08-23 07:37

Quote from Dusk
IMO enemy players should always block each other, even if sv_unblockplayers is on. The current behavior is an oversight and should be fixed.

I disagree. sv_unblockplayers is intentionally not named sv_unblockallies. Sure, it would be good to also have the latter as an additional option.

(0011103)
Torr Samaho (administrator)
2014-12-28 16:07

For the record, I declined the pull request a while ago. Reason: "sv_unblockplayers is intentionally not named sv_unblockallies so it should definitely not be restricted to unblock just team mates". Feel free to make a new patch that fixes the bug, while still doing what the name of the CVAR implies.

(0011137)
Leonard (developer)
2014-12-30 01:02

'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/122/fixed-cvar-sv_unblockplayers-now-works/diff [^]'

(0011139)
Torr Samaho (administrator)
2014-12-30 12:42

Thanks! Looks quite good already. See the pull requests for some technical comments.

(0011140)
cobalt (updater)
2014-12-30 16:17

Issue addressed by commit e3ea25015618: Fixed: CVAR sv_unblockplayers now works with different species. (fixes 1318)
Committed by Leonard on Tuesday 30 December 2014 16:42:07

Changes in files:
docs/zandronum-history.txt | 1 +
src/p_map.cpp | 15 ++++++---------
2 files changed, 7 insertions(+), 9 deletions(-)

(0011176)
Arco (updater)
2015-01-01 18:16

sv_unblockplayers 0 appears to be broken, as I was able to go through players in r150101-1703.

(0011179)
Torr Samaho (administrator)
2015-01-01 18:25

I can't reproduce the problem. Please tell me exactly how to pass through players while sv_unblockplayers is 0.

(0011188)
Hypnotoad (reporter)
2015-01-01 20:10

What about the additional flags suggested here:'http://zandronum.com/tracker/view.php?id=1318#c10220 [^]' since unblocking all species will break my blockteam pk3 hosted on NJ pubctf servers, something needs to be done to enable teams to block each-other.

(0011191)
Torr Samaho (administrator)
2015-01-01 20:30

I don't see why you need sv_blockspecies. Dusk's question about a usage scenario (0001318:0010221) hasn't been answered yet.

And instead of creating a flag sv_blockteams that changes the behavior of sv_unblockplayers, I'd rather add a separate flag sv_unblockallies.

(0011193)
Hypnotoad (reporter)
2015-01-01 21:17

sv_unblockallies sounds reasonable.

I believe sv_unblockallies may solve the use case I was going to raise for sv_blockspecies, as I believe the new unblockplayers could break prophunt (sometimes unblockplayers might be turned on for this if there are many players), it still wouldn't be quite ideal ('hard props' like lights/decorations would lose collision with other props, which is incorrect behavior, but at least they'd still collide with players on the other team).

(0011194)
Leonard (developer)
2015-01-01 21:35

I confirm it is broken in 2.0, looking at the source it looks like the flag's name was never changed (from DF3_UNBLOCK_PLAYERS to ZADF_UNBLOCK_PLAYERS) in p_map.cpp

(0011196)
Torr Samaho (administrator)
2015-01-01 21:47

What are you talking about? There is no occurrence of DF3_UNBLOCK_PLAYERS in the 2.0 source. This wouldn't compile if I didn't properly change DF3_UNBLOCK_PLAYERS to ZADF_UNBLOCK_PLAYERS when merging the changes with 2.0.

(0011197)
Leonard (developer)
2015-01-01 22:01

Oh my bad, I was looking in the wrong repository here.
After re-checking in both 1.3 and 2.0 it turns out the flag isn't broken, I got confused because I had a wad loaded while testing this that set the flag automatically and I didn't notice.
I'm not sure for Arco however.

(0011412)
Arco (updater)
2015-01-17 22:46

I made an error on my end. r150101-1703 works with different classes.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	RusselCS someoneelse President People Qent Dusk Empyre roman6a
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2013-04-05 10:35	HexaDoken	New Issue
2013-07-22 14:37	Dusk	Relationship added	has duplicate 0001424
2013-07-22 14:42	Dusk	Relationship added	related to 0001264
2013-07-22 16:02	Empyre	Note Added: 0006747
2013-07-23 14:26	ZzZombo	Note Added: 0006770
2013-09-18 16:54	Watermelon	Assigned To	=> Watermelon
2013-09-18 16:54	Watermelon	Status	new => confirmed
2014-05-05 22:30	Watermelon	Assigned To	Watermelon =>
2014-05-05 22:30	Watermelon	Note Added: 0008708
2014-08-15 07:05	Leonard	Note Added: 0010206
2014-08-15 11:11	Hypnotoad	Note Added: 0010208
2014-08-15 16:46	Leonard	Note Added: 0010209
2014-08-15 16:48	Leonard	Note Edited: 0010209	View Revisions
2014-08-17 18:43	Dusk	Status	confirmed => needs review
2014-08-19 14:30	Hypnotoad	Note Added: 0010219
2014-08-19 14:34	Hypnotoad	Note Edited: 0010219	View Revisions
2014-08-19 14:38	Hypnotoad	Note Edited: 0010219	View Revisions
2014-08-19 16:12	Hypnotoad	Note Added: 0010220
2014-08-19 18:21	Dusk	Note Added: 0010221
2014-08-23 07:37	Torr Samaho	Note Added: 0010222
2014-12-28 16:07	Torr Samaho	Note Added: 0011103
2014-12-28 16:07	Torr Samaho	Assigned To	=> Torr Samaho
2014-12-28 16:07	Torr Samaho	Status	needs review => feedback
2014-12-28 16:07	Torr Samaho	Assigned To	Torr Samaho =>
2014-12-30 01:02	Leonard	Note Added: 0011137
2014-12-30 09:52	Edward-san	Status	feedback => needs review
2014-12-30 09:56	Edward-san	Status	needs review => feedback
2014-12-30 12:42	Torr Samaho	Note Added: 0011139
2014-12-30 16:17	cobalt	Status	feedback => needs testing
2014-12-30 16:17	cobalt	Target Version	=> 1.4
2014-12-30 16:17	cobalt	Description Updated	View Revisions
2014-12-30 16:17	cobalt	Note Added: 0011140
2015-01-01 18:16	Arco	Note Added: 0011176
2015-01-01 18:16	Arco	Status	needs testing => feedback
2015-01-01 18:16	Arco	Description Updated	View Revisions
2015-01-01 18:25	Torr Samaho	Note Added: 0011179
2015-01-01 20:10	Hypnotoad	Note Added: 0011188
2015-01-01 20:30	Torr Samaho	Note Added: 0011191
2015-01-01 21:17	Hypnotoad	Note Added: 0011193
2015-01-01 21:35	Leonard	Note Added: 0011194
2015-01-01 21:47	Torr Samaho	Note Added: 0011196
2015-01-01 22:01	Leonard	Note Added: 0011197
2015-01-17 22:46	Arco	Note Added: 0011412
2015-01-17 22:46	Arco	Status	feedback => resolved
2015-01-17 22:46	Arco	Resolution	open => fixed
2015-01-17 22:46	Arco	Fixed in Version	=> 1.4
2018-09-30 23:54	Blzut3	Status	resolved => closed

Notes
(0006747) Empyre (reporter) 2013-07-22 16:02	Oops! Sorry for making a duplicate of this. I should have searched first. Lesson learned.

(0006770) ZzZombo (reporter) 2013-07-23 14:26	I guess, better have two flags, one for unblocking of players, and another for firing.

(0008708) Watermelon (developer) 2014-05-05 22:30	I believe this was already fixed for 1.3?

(0010206) Leonard (developer) 2014-08-15 07:05	'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/66/sv_unblockplayers-now-works-with-different/diff [^]'

(0010208) Hypnotoad (reporter) 2014-08-15 11:11	I'm not sure this /should/ be fixed, if I want players of different classes to pass through each other, I set them to be the same species in decorate. Sometimes I want some players to pass through each other, and some players not to, I feel this could be the same for other mods, and forcing all players of different classes to pass through each other might break compatibility.

(0010209) Leonard (developer) 2014-08-15 16:46 edited on: 2014-08-15 16:48	Since you already use the Species property, could you not add the THRUSPECIES flag on your classes instead? And if you want it to be toggleable, you can already set it via ACS so I guess this shouldn't be a problem?

(0010219) Hypnotoad (reporter) 2014-08-19 14:30 edited on: 2014-08-19 14:38	Can you please clarify a way to toggle thruspecies in ACS without gross hackery? The only way I can think of is giving an inventory on spawn that does A_Changeflag, but this isn't very reliable and fairly hackish. Furthermore, you did not address the issue of compatibility, are you sure this wont break other older mods that might want both teams to be unblocked, or might only want actors of the same species to be blocked? I don't see why simply using a patchwad to set different species on each team isn't a superior solution, rather than changing engine behavior which potentially breaks compatibility of older mods. If you can clarify a clean way to toggle it, and ensure no compatibility problems, then I'd support this. edit: in fact what I'd suggest is adding an additional setting, having sv_unblockplayers 2 will use the new proposed behavior, ignoring classes, and sv_unblockplayers 1 retains the current behavior.

(0010220) Hypnotoad (reporter) 2014-08-19 16:12	Leonard and I have discussed and come up with the idea of having additional flags since there are many scenarios we might want. Our idea is to have the flag sv_unblockplayers unblock all players no matter what, but then to introduce two new flags, sv_blockteams and sv_blockspecies, that keep different teams and/or different species/classes blocked if unblockplayers is on.

(0010221) Dusk (developer) 2014-08-19 18:21	I don't really understand why blocking per species is necessary. Can you elaborate on why it would be useful? IMO enemy players should always block each other, even if sv_unblockplayers is on. The current behavior is an oversight and should be fixed.

(0010222) Torr Samaho (administrator) 2014-08-23 07:37	Quote from Dusk IMO enemy players should always block each other, even if sv_unblockplayers is on. The current behavior is an oversight and should be fixed. I disagree. sv_unblockplayers is intentionally not named sv_unblockallies. Sure, it would be good to also have the latter as an additional option.

(0011103) Torr Samaho (administrator) 2014-12-28 16:07	For the record, I declined the pull request a while ago. Reason: "sv_unblockplayers is intentionally not named sv_unblockallies so it should definitely not be restricted to unblock just team mates". Feel free to make a new patch that fixes the bug, while still doing what the name of the CVAR implies.

(0011137) Leonard (developer) 2014-12-30 01:02	'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/122/fixed-cvar-sv_unblockplayers-now-works/diff [^]'

(0011139) Torr Samaho (administrator) 2014-12-30 12:42	Thanks! Looks quite good already. See the pull requests for some technical comments.

(0011140) cobalt (updater) 2014-12-30 16:17	Issue addressed by commit e3ea25015618: Fixed: CVAR sv_unblockplayers now works with different species. (fixes 1318) Committed by Leonard on Tuesday 30 December 2014 16:42:07 Changes in files: docs/zandronum-history.txt \| 1 + src/p_map.cpp \| 15 ++++++--------- 2 files changed, 7 insertions(+), 9 deletions(-)

(0011176) Arco (updater) 2015-01-01 18:16	sv_unblockplayers 0 appears to be broken, as I was able to go through players in r150101-1703.

(0011179) Torr Samaho (administrator) 2015-01-01 18:25	I can't reproduce the problem. Please tell me exactly how to pass through players while sv_unblockplayers is 0.

(0011188) Hypnotoad (reporter) 2015-01-01 20:10	What about the additional flags suggested here:'http://zandronum.com/tracker/view.php?id=1318#c10220 [^]' since unblocking all species will break my blockteam pk3 hosted on NJ pubctf servers, something needs to be done to enable teams to block each-other.

(0011191) Torr Samaho (administrator) 2015-01-01 20:30	I don't see why you need sv_blockspecies. Dusk's question about a usage scenario (0001318:0010221) hasn't been answered yet. And instead of creating a flag sv_blockteams that changes the behavior of sv_unblockplayers, I'd rather add a separate flag sv_unblockallies.

(0011193) Hypnotoad (reporter) 2015-01-01 21:17	sv_unblockallies sounds reasonable. I believe sv_unblockallies may solve the use case I was going to raise for sv_blockspecies, as I believe the new unblockplayers could break prophunt (sometimes unblockplayers might be turned on for this if there are many players), it still wouldn't be quite ideal ('hard props' like lights/decorations would lose collision with other props, which is incorrect behavior, but at least they'd still collide with players on the other team).

(0011194) Leonard (developer) 2015-01-01 21:35	I confirm it is broken in 2.0, looking at the source it looks like the flag's name was never changed (from DF3_UNBLOCK_PLAYERS to ZADF_UNBLOCK_PLAYERS) in p_map.cpp

(0011196) Torr Samaho (administrator) 2015-01-01 21:47	What are you talking about? There is no occurrence of DF3_UNBLOCK_PLAYERS in the 2.0 source. This wouldn't compile if I didn't properly change DF3_UNBLOCK_PLAYERS to ZADF_UNBLOCK_PLAYERS when merging the changes with 2.0.

(0011197) Leonard (developer) 2015-01-01 22:01	Oh my bad, I was looking in the wrong repository here. After re-checking in both 1.3 and 2.0 it turns out the flag isn't broken, I got confused because I had a wad loaded while testing this that set the flag automatically and I didn't notice. I'm not sure for Arco however.

(0011412) Arco (updater) 2015-01-17 22:46	I made an error on my end. r150101-1703 works with different classes.