Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000186Zandronum[All Projects] Suggestionpublic2010-11-08 23:242015-07-17 14:28
ReporterAlexMax 
Assigned ToTorr Samaho 
PrioritynormalSeverityminorReproducibilityN/A
StatusfeedbackResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000186: New COMPATFLAG: "Vanilla Weapon Switch Canceling"
DescriptionZDoom and Vanilla Doom/ZDaemon have different behaviors with weapon switch canceling. In other words, if you are switching weapons, and suddenly change your mind midway through the switch, Skulltag and ZDaemon handle it differently.
Steps To ReproduceIn Skulltag and ZDaemon:

Lets say that you're holding the SSG and switch (or are forced to switch because of force switch on pickup) to the CG. _Before the weapon goes down_ you change your mind and decide to switch to the RL instead. As long as you hit the switch command for the rocket launcher _before the weapon goes down_, you can still switch to the RL.

In Vanilla/ZDaemon:

As soon as the SSG disappears, you _will_ pull out the CG. If you hit the key for the rocket launcher, you must wait for doomguy to fully pull out the CG before it'll switch to the RL.

In Skulltag:

You can switch anytime, even after the CG starts coming up.

The compatflag would make switch happen like ZDaemon.
Attached Files

- Relationships
related to 0001362closedWatermelon Separating compat_oldweaponswitch from affecting weapon raise 

-  Notes
User avatar (0000584)
AlexMax (developer)
2010-11-08 23:26
edited on: 2010-11-08 23:56

 To clarify, the 'point of no return' is exactly HALF the time it takes for you to switch weapons, not as soon as the sprite disappears from view (though this might be the one and the same as far as code is concerned).

Something to watch out for. ZDaemon has a bug where if you hit the weapon switch at the latest possible time, it will appear to pull out the CG, but serverside will pull out the RL (to use the above example). Watch out for this potential desync.

Thanks to dew for pointing out this bug.

EDIT: Demos!

Use the latest ZDaemon to play:'http://neokotchka.net/dew/doom/weapswitch.zd.zip [^]'
18:35:51 <+dewww> ok i got the demo for zd
18:36:35 <+dewww> with doing the quick switch right, wrong and triggering the desync bug
18:38:18 <+dewww> it's pure OS doom2 map01, should behave like vanilla.. except when i pick the ssg i desync the demo
18:38:53 <+dewww> it shows me throwing fist around, but it's actually ssg shots

A normal doom2.exe demo on judas23_.wad:'http://neokotchka.net/dew/doom/weapswitch.van.lmp [^]'
18:45:19 <+dewww> here's me picking weapons up in vanilla on judas23_
18:45:37 <+dewww> shows how easy you can mess it up

A Skulltag demo. Needs duel32-rc1: 'http://neokotchka.net/dew/doom/weapswitch.st.zip [^]'
User avatar (0000918)
Torr Samaho (administrator)
2011-02-02 01:16

 Does this make the switch more like ZD?
User avatar (0000920)
AlexMax (developer)
2011-02-02 02:05
edited on: 2011-02-02 02:15

 My apologies Torr. It's not quite exact through no fault of yours, since I was incorrect in my original example of the weapon switch behavior. I didn't want to confuse the issue by mentioning the same weapon twice, but as it turns out there is a very important distinction.

Let's assume that we're playing Vanilla Doom and that W1, W2 and W3 represent unique weapons. You have W1 out and hit the key for W2. Before the halfway point, if you hit W1 again, it should ignore the command completely. However, if you hit W3, it WILL in fact switch directly from W1 to W3 without cycling to W2.

So, from the patch you have now, make it so if you're bringing down a weapon, you can successfully select any other weapon before the midway point EXCEPT the one you are currently switching away from. You have the after midway pull-out behavior perfect, by the way, so that one modification to bring-down behavior should make weapon switch behavior Vanilla-perfect.
User avatar (0000924)
Torr Samaho (administrator)
2011-02-02 12:25

 I tried to reproduce this but couldn't: When I have out W1, select W2 and then select W1 before the midway point, W2 is still brought up before W1 is pulled out for me (only tested with the binary I posted here). Are you using any special flags? Did you test this online or offline?
User avatar (0000925)
AlexMax (developer)
2011-02-02 13:12
edited on: 2011-02-02 13:15

 After trying again this morning (with a fresh mind), it seems like perhaps I wasn't testing correctly, because I tried the two cases of switching back to W1 when W1 is coming down (should go to W2) and switching to W3 when W1 is coming down (should go to W3) and both of cases appear to be correct, actually. I dunno what I was doing wrong last night, but I think that you handled the coming down case correctly as well.

In which case your patch is pretty much perfect. This is going to be rolled up into compat_oldweaponswitch with the forced switch on pickup, correct?
User avatar (0000927)
Torr Samaho (administrator)
2011-02-02 13:19

 > This is going to be rolled up into compat_oldweaponswitch with the forced switch on pickup, correct?

This would make sense to me, but I also wouldn't mind creating a new compat flag. Is there anybody who would want this to be a separate flag?
User avatar (0000928)
unknownna (updater)
2011-02-02 13:21

 I suppose for flexibility (although not necessarily needed), it could become a new compat flag.
User avatar (0000930)
AlexMax (developer)
2011-02-02 13:51
edited on: 2011-02-02 13:55

 Some players might prefer "almost vanilla" settings for maps, but one or two switches that make the map more playable. I seem to remember people saying that disabling force pickup on DWELLER2 MAP11 made the map play a whole lot better.

However, for what it's worth, unless I'm missing something (which is very possible since I don't have ZDaemon installed on this computer so I can't doublecheck) ZDaemon doesn't seem to have a separate setting for force pickup and weapon switch, just one DMFLAGS2 1114112 which is called "Classic Weapon Switching": 'http://www.zdaemon.org/dmflags107.html [^]'

Besides, having force pickup on with classic switching off is merely an annoyance since you can 'exploit' it as you can now. I can see classic switching on with force pickup off, but I have no idea if that edge case is worth splitting it up into two.
User avatar (0000936)
Torr Samaho (administrator)
2011-02-03 02:21

 For the sake of flexibility I added the new flag compat_oldweaponswitchcancel for this. Please test this binary.
User avatar (0000944)
AlexMax (developer)
2011-02-03 13:52

 I'll test these changes tonight. However, I think that the names of the compat flags could use an adjustment:

compat_forceweaponswitch = Always pick up a weapon when you run over it.
compat_oldweaponswitch = Rest of the functionality you added.
User avatar (0000951)
Torr Samaho (administrator)
2011-02-04 00:51

 I have no problem renaming compat_oldweaponswitchcancel, I don't like the name too much either, but I'd rather avoid renaming compat_oldweaponswitch. It's been in the public releases for more than two years now and I don't know how many people or wads rely on it being called how it is now.
User avatar (0000958)
Gez (reporter)
2011-02-04 15:16
edited on: 2011-02-04 15:17

 It would make sense to me to merge them both together. Are there really going to be people who use the one without the other?
User avatar (0000959)
unknownna (updater)
2011-02-04 16:26
edited on: 2011-02-04 16:36

 What if Skulltag had a PWO feature? Some people might want to use the old selection behavior, but without the forced switching.
User avatar (0000962)
Torr Samaho (administrator)
2011-02-05 02:52

 > It would make sense to me to merge them both together.

Yeah, they are very related. At least I'd prefer merging them to renaming the existing cvar.

> What if Skulltag had a PWO feature? Some people might want to use the old selection behavior, but without the forced switching.

Well, PWO is an absolutely non-Vanilla feature, so it would be kinda strange to me if someone on the one hand insists on having PWO and on the other hand on having the old selection behavior.
User avatar (0000992)
Torr Samaho (administrator)
2011-02-06 23:35

 To resolved the naming issues I decided to merge the addition into compat_oldweaponswitch. If anybody has strong reasons why this needs to be a separate flag, report here. I still can change this before the final release of 98e.
User avatar (0001000)
AlexMax (developer)
2011-02-07 03:55
edited on: 2011-02-07 03:56

 That sounds like a totally reasonable decision.
User avatar (0001404)
unknownna (updater)
2011-04-21 19:59
edited on: 2011-04-21 21:28

 I just found out through the Doom Wiki that you can't select the fist in Vanilla Doom if you have the chainsaw, unless you have the berserk power-up. It'd be nice if compat_oldweaponswitch also emulated this behavior.

> The fist is the player's stock melee attack. It is always available unless the player has picked up a chainsaw.

> A berserk-powered player that has obtained or obtains the chainsaw is able to switch to the fist by pressing 1 on the keyboard. That is, instead of allowing only the chainsaw, as with respect to the normal fist attack, the key press will toggle between the two types of attack as long as the berserk powerup is active. When switching from another weapon slot (2 or more) the chainsaw is raised, while the berserk fist is produced with a second key press.

> If a player has already picked up the chainsaw, arms himself with the fist when progressing to the next level, the fist will continue to be available on the next level, albeit at regular strength again. Once the player switches to another weapon, the fist cannot be toggled back again until a berserker pack has been picked up.

Edit:

And shouldn't the compatflag also enforce the behavior of cl_noammoswitch upon the clients?
User avatar (0001975)
unknownna (updater)
2011-07-27 13:55
edited on: 2011-07-27 17:51

 The switchonpickup setting can affect how the weapon selection works when you're out of ammo and then pick up some ammo. If switchonpickup is set to 0, you will not automatically switch to the corresponding weapon. This is not how it works in Chocolate Doom. AFAIK you always switch to the corresponding weapon there.

There is a special case if you have the SSG in your inventory but not the shotgun as well. Then you will not switch to the SSG when you pick up some ammo. But if you have the shotgun as well, you will switch to the shotgun rather than the SSG when you pick up some ammo.

The BFG is also affected by this behavior. If you have the BFG in your inventory but not the plasma rifle, you will not switch to the BFG when you pick up some ammo. But if you have the plasma rifle as well, you will switch to the plasma rifle rather than the BFG when you pick up some ammo.

Could we enforce the switchonpickup 2 behavior when compat_oldweaponswitch is set to 1? There's no need to worry about this trivial issue before 98e though.
User avatar (0012959)
unknownna (updater)
2015-07-17 14:28

 Hmm, the notes above are about trying to emulate vanilla Doom, but since we're more interested in ZDoom 1.23b33, we can probably ignore them.

Anyway, the current implementation does not work like it does in ZDaemon (ZDoom 1.23b33).

In ZDoom 2.0.63 the weapon selection worked like it did in ZDoom 1.23b33. That's the last version I could find that has the old behavior.
In ZDoom 2.0.90 the weapon selection was changed, but it was broken.
In ZDoom 2.0.92 the weapon selection was changed to the one we now have in Zandronum.

The weapons don't raise fully in ZDaemon if you press weapprev/weapnext in a fast manner, but in Zandronum with compat_fullweaponlower enabled they are forced to raise fully before switching to another weapon.

Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2010-11-08 23:24 AlexMax New Issue
2010-11-08 23:26 AlexMax Note Added: 0000584
2010-11-08 23:28 AlexMax Note Edited: 0000584 View Revisions
2010-11-08 23:29 AlexMax Note Edited: 0000584 View Revisions
2010-11-08 23:32 AlexMax Note Edited: 0000584 View Revisions
2010-11-08 23:39 AlexMax Note Edited: 0000584 View Revisions
2010-11-08 23:41 AlexMax Note Edited: 0000584 View Revisions
2010-11-08 23:56 AlexMax Note Edited: 0000584 View Revisions
2011-02-02 01:16 Torr Samaho Note Added: 0000918
2011-02-02 01:16 Torr Samaho Assigned To => Torr Samaho
2011-02-02 01:16 Torr Samaho Status new => feedback
2011-02-02 02:05 AlexMax Note Added: 0000920
2011-02-02 02:05 AlexMax Status feedback => assigned
2011-02-02 02:08 AlexMax Note Edited: 0000920 View Revisions
2011-02-02 02:09 AlexMax Note Edited: 0000920 View Revisions
2011-02-02 02:11 AlexMax Note Edited: 0000920 View Revisions
2011-02-02 02:14 AlexMax Note Edited: 0000920 View Revisions
2011-02-02 02:14 AlexMax Note Edited: 0000920 View Revisions
2011-02-02 02:15 AlexMax Note Edited: 0000920 View Revisions
2011-02-02 12:25 Torr Samaho Note Added: 0000924
2011-02-02 12:25 Torr Samaho Status assigned => feedback
2011-02-02 13:12 AlexMax Note Added: 0000925
2011-02-02 13:12 AlexMax Status feedback => assigned
2011-02-02 13:15 AlexMax Note Edited: 0000925 View Revisions
2011-02-02 13:19 Torr Samaho Note Added: 0000927
2011-02-02 13:19 Torr Samaho Status assigned => feedback
2011-02-02 13:21 unknownna Note Added: 0000928
2011-02-02 13:51 AlexMax Note Added: 0000930
2011-02-02 13:51 AlexMax Status feedback => assigned
2011-02-02 13:55 AlexMax Note Edited: 0000930 View Revisions
2011-02-03 02:21 Torr Samaho Note Added: 0000936
2011-02-03 02:22 Torr Samaho Status assigned => feedback
2011-02-03 13:52 AlexMax Note Added: 0000944
2011-02-03 13:52 AlexMax Status feedback => assigned
2011-02-04 00:51 Torr Samaho Note Added: 0000951
2011-02-04 00:52 Torr Samaho Status assigned => feedback
2011-02-04 15:16 Gez Note Added: 0000958
2011-02-04 15:17 Gez Note Edited: 0000958 View Revisions
2011-02-04 16:26 unknownna Note Added: 0000959
2011-02-04 16:36 unknownna Note Edited: 0000959 View Revisions
2011-02-05 02:52 Torr Samaho Note Added: 0000962
2011-02-06 23:35 Torr Samaho Note Added: 0000992
2011-02-07 03:55 AlexMax Note Added: 0001000
2011-02-07 03:55 AlexMax Status feedback => assigned
2011-02-07 03:56 AlexMax Note Edited: 0001000 View Revisions
2011-04-21 19:59 unknownna Note Added: 0001404
2011-04-21 21:14 unknownna Note Edited: 0001404 View Revisions
2011-04-21 21:15 unknownna Note Edited: 0001404 View Revisions
2011-04-21 21:28 unknownna Note Edited: 0001404 View Revisions
2011-07-27 13:55 unknownna Note Added: 0001975
2011-07-27 17:49 unknownna Note Edited: 0001975 View Revisions
2011-07-27 17:51 unknownna Note Edited: 0001975 View Revisions
2013-06-08 18:38 Watermelon Relationship added related to 0001362
2015-07-17 14:28 unknownna Note Added: 0012959
2015-07-17 14:28 unknownna Status assigned => feedback




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker