[Added] r3829 WRF_NOSWITCH behaviour?

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

r3829 WRF_NOSWITCH behaviour?

Postby Enjay » Thu Aug 16, 2012 4:38 pm

I'm not sure if this is a bug or not but a discussion in the editing forum leads me to post this just in case.

In short, I am looking to create a weapon that, once selected, cannot be changed away from (unless the weapon is taken using ACS). The WRF_NOSWITCH seemed like it would do the job however, I ran into problems. The behaviour I experienced may well be what is intended but I feel it makes the feature not particularly useful.

I've copied the relevant points of discussion below. FDARI's comment is possibly the most valuable.


Enjay wrote:What is the best way to prevent a player changing away from a particular weapon (can be ACS or DECORATE).

I'm just trying to get a neater way of making a "mounted gun" weapon like the minigun in my Burghead mod. What I did there was count everything the player had in his inventory, then take it all away and give him the minigun. Then when he stopped using the gun, I gave him his inventory back.

It would be much beater to leave his inventory alone and either create a weapon where its decorate means that you cannot change away from it (making the deselect state jump to the ready state has some unwanted side effects) or some ACS prevents you changing away.


Blue Shadow wrote:Would the WRF_NOSWTICH flag for A_WeaponReady help?


Enjay wrote:That looks like it would do the trick. It seems to be meant for exactly what I'm trying to do. Thanks.

[edit] Hmm, nope, it doesn't allow what I want. Changing the ready state to:

Code: Select allExpand view
   Ready:
      MINI A 1 A_WeaponReady(WRF_NOSWITCH)
      Loop


does mean that you can't switch away from the weapon when you are in the "ready" state. However, if you start firing and then press the button for another weapon while the weapon is still firing, you can switch away. Even worse, if you press the button for another weapon while you are in the ready state, ZDoom seems to remember that you have tried to switch away so that when you start firing (ie enter a state where the weapon can switch away) you change weapons shortly after entering the firing state. [/edit]


FDARI wrote:That may be a bug. It may also be intended behaviour, or perhaps a nigh-unavoidable feature of the design. I would expect and prefer that WRF_NOSWITCH were in effect until a_weaponready was called again.

Emphasis mine.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: r3829 WRF_NOSWITCH behaviour?

Postby Graham Siblingsane » Wed Aug 29, 2012 12:36 pm

Just call A_WeaponReady(WRF_NOSWITCH) upon entering every state. That should do the trick.
Graham Siblingsane
 

Re: r3829 WRF_NOSWITCH behaviour?

Postby randi » Thu Jan 10, 2013 9:53 pm

Fixed in r4024.
User avatar
randi
Site Admin
 
Joined: 09 Jul 2003

Re: r3829 WRF_NOSWITCH behaviour?

Postby Enjay » Fri Jan 11, 2013 1:40 pm

Thank you very much. I look forward to trying this out over the weekend.

[edit] Works like a charm. :D [/edit]
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: r3829 WRF_NOSWITCH behaviour?

Postby VicRattlehead » Sun Jan 13, 2013 2:06 am

This has caused some mods to stop working properly. I've only tried out Russian Overkill, Terrorists, Psychic, NecroDoom and Diaz v3 and the two lattermost are affected -- weapons freeze when attempting to switch to another.
VicRattlehead
 
Joined: 09 Sep 2011

Re: r3829 WRF_NOSWITCH behaviour?

Postby Gez » Sun Jan 13, 2013 4:15 am

Guess we'll need to revert WRF_NOSWITCH to its previous behavior and have WRF_KEEPNOSWITCH for the new behavior.
Gez
 
 
 
Joined: 06 Jul 2007

Re: r3829 WRF_NOSWITCH behaviour?

Postby Enjay » Sun Jan 13, 2013 7:03 am

Hmmm, it looks like the original behaviour was used more than I thought it was. Given that the revised behaviour is also very desirable, two flags would indeed make sense. The revised behaviour has allowed me to cut out a huge, clumsy, easily breakable bit of ACS and replace it with a single line in the Weapon's DECORATE.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: r3829 WRF_NOSWITCH behaviour?

Postby Graf Zahl » Sun Jan 13, 2013 7:15 am

Damn... And I wanted to do a new GZDoom release today. This has to be sorted out first, though, otherwise it makes no sense.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: r3829 WRF_NOSWITCH behaviour?

Postby Blue Shadow » Sun Jan 13, 2013 8:50 am

Graf Zahl wrote:Damn... And I wanted to do a new GZDoom release today.

You ain't having a luck aren't you, Graf? :P This is the second time that this happens.
User avatar
Blue Shadow
 
 
 
Joined: 14 Nov 2010
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: r3829 WRF_NOSWITCH behaviour?

Postby Kate » Mon Jan 14, 2013 12:46 am

2 changes could fix this and still keep the current behavior:

1. WRF_NOSWITCH has no business touching the pending weapon. It should remember that I want to switch and do so as soon as possible, even if that isn't right now.
2. Entering the Deselect state should imply disabling switching, since it's caused by switching, meaning it will result in the weapon deadlocking if it doesn't immediately call A_Lower, which is what's happening right now.
User avatar
Kate
... in loving memory ...
 
Joined: 15 Jul 2003

[r4024] Can't lower certain weapons...

Postby Ed the Bat » Thu Jan 17, 2013 11:38 pm

Since the revision in r4024, trying to lower any weapon that has at least two tics in its Deselect state before A_Lower is called will freeze the weapon. Example included below.
Attachments
fisttest.wad
Pistol can be lowered, but custom fist cannot
(384 Bytes) Downloaded 41 times
User avatar
Ed the Bat
I'm tired. I want to go home.
 
Joined: 03 May 2012
Location: Maryland, US

Re: [r4024] Can't lower certain weapons...

Postby Kate » Fri Jan 18, 2013 1:27 am

That's because this.
User avatar
Kate
... in loving memory ...
 
Joined: 15 Jul 2003

Re: [r4024] Can't lower certain weapons...

Postby Ed the Bat » Fri Jan 18, 2013 1:30 am

Yes, the thing which happened in r4024. The... ONLY thing which happened.

This breaks a lot of projects, including my own. Any weapon with a fancy lowering animation in its Deselect state is now broken.
User avatar
Ed the Bat
I'm tired. I want to go home.
 
Joined: 03 May 2012
Location: Maryland, US

Re: r3829 WRF_NOSWITCH behaviour?

Postby Enjay » Fri Jan 18, 2013 3:37 pm

I am guessing that this problem may also be related.

If a weapon plays a sound in its deselect state sequence, the sound loops rapidly when the player dies while holding the weapon.

[edit] Easier to use example attached a couple of posts down. [/edit]
example:

Code: Select allExpand view
ACTOR TestPistol : Pistol
{
   States
   {
   Deselect:
      PISG A 0 A_PlayWeaponSound("misc/chat")
      PISG A 1 A_Lower
      goto Deselect+1
   }
}


Put the above into a decorate file. Type "give testpistol" at the console to get and switch to the testpistol. [optional: switch to another weapon to confirm that the pistol makes the "misc/chat" sound when lowered]. With the testpistol readied, type "kill" at the console or let an enemy kill you and the sound will play over and over making a helluva noise in the SVN build but doesn't in the official release.

[edit] Actually, the sound seems to be repeating rapidly whenever the weapon is deselected. It's just that when you die, the rapid looping never stops.[/edit]
Last edited by Enjay on Sat Jan 19, 2013 6:08 am, edited 1 time in total.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: r3829 WRF_NOSWITCH behaviour?

Postby Gez » Fri Jan 18, 2013 5:43 pm

You could use "Wait" instead of "Goto Deselect+1". (It wouldn't change anything to the behavior, it just looks cleaner I think.)
Gez
 
 
 
Joined: 06 Jul 2007

Next

Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 2 guests