|
Notes |
|
|
(0006747)
|
|
Empyre
|
|
2013-07-22 16:02
|
|
|
Oops! Sorry for making a duplicate of this. I should have searched first. Lesson learned. |
|
|
|
|
|
I guess, better have two flags, one for unblocking of players, and another for firing. |
|
|
|
|
|
I believe this was already fixed for 1.3? |
|
|
|
|
|
|
|
|
|
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
|
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
|
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.
|
|
|
|
|
|
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
|
|
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. |
|
|
|
|
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. |
|
|
|
|
|
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. |
|
|
|
|
|
|
|
|
|
Thanks! Looks quite good already. See the pull requests for some technical comments. |
|
|
|
(0011140)
|
|
cobalt
|
|
2014-12-30 16:17
|
|
|
|
|
(0011176)
|
|
Arco
|
|
2015-01-01 18:16
|
|
|
sv_unblockplayers 0 appears to be broken, as I was able to go through players in r150101-1703. |
|
|
|
|
|
I can't reproduce the problem. Please tell me exactly how to pass through players while sv_unblockplayers is 0. |
|
|
|
|
|
|
|
|
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. |
|
|
|
|
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). |
|
|
|
|
|
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 |
|
|
|
|
|
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. |
|
|
|
|
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
|
|
2015-01-17 22:46
|
|
I made an error on my end. r150101-1703 works with different classes.
|
|