r3829 WRF_NOSWITCH behaviour?

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: r3829 WRF_NOSWITCH behaviour?

Re: r3829 WRF_NOSWITCH behaviour?

by Enjay » Tue Feb 05, 2013 11:53 am

Yes, it seems to work perfectly. Thank you very much and sorry for the flurry of "X mod doesn't work any more" posts that were spawned because of the initial report and change.

Re: r3829 WRF_NOSWITCH behaviour?

by randi » Mon Feb 04, 2013 8:28 pm

r4062 adds the WRF_DISABLESWITCH, which reimplements the WRF_NOSWITCH semantics from r4024. I believe that should be what you want, yes, Enjay?

Re: r3829 WRF_NOSWITCH behaviour?

by Enjay » Tue Jan 29, 2013 12:23 pm

Just thought I'd update with a little info here just in case it helps. When the ZDoom code changed initially I added A_WeaponReady(WRF_NOSWITCH) to the ready state sequence of my Minigun (and it worked as I wanted - as reported earlier). With the current code, the Minigun now half does what I wanted: once the weapon is selected, you cannot deselect it by pressing another weapon button. However, once you have pressed the button for another weapon, the Minigun no longer works properly. Even with the fire button held down, the gun only fires in short bursts (I assume it is going through its fire sequence right to the end before repeating rather than restarting when the fire sequence gets to A_Refire).

I know that the feature has not been fully addressed yet - and I'm not nagging - but I thought the information might be useful. In the spoiler is the code for the weapon concerned but there is quite a bit going on there so it might not be the best example. If a simpler example to work with is required, let me know.
Spoiler:

Re: r3829 WRF_NOSWITCH behaviour?

by Enjay » Fri Jan 25, 2013 9:44 am

That's good. I saw a bunch of changes that seemed to be in this area but I wasn't sure if they were preparing the groundwork for something or were part of something else like a tidy up or whatever. Thanks for putting them into context for me.

Re: r3829 WRF_NOSWITCH behaviour?

by Graf Zahl » Fri Jan 25, 2013 8:47 am

I think it's obvious from the changelog that Randy was preparing some more changes but hadn't had time yet to finish them.

Re: r3829 WRF_NOSWITCH behaviour?

by Enjay » Fri Jan 25, 2013 8:43 am

I notice that r4039 reverts things to the old behaviour (which certainly makes sense given the number of mods that have been adversely affected by r4024). It seems that doing this has fixed the sound-looping-when-lowering-a-weapon problem too.

I'm hoping that this thread not yet being moved to closed bugs indicates that some way of having the behaviour that I wanted is also being considered?

Re: r3829 WRF_NOSWITCH behaviour?

by Gez » Thu Jan 24, 2013 1:36 pm

Winter's Fury is affected by the problem.

Re: r3829 WRF_NOSWITCH behaviour?

by Enjay » Sat Jan 19, 2013 5:01 am

Thanks. I keep forgetting that "wait" even exists.

I've attached an easier to use WAD example with the pistol replaced with one that plays misc/chat when deselected (ie similar to the above example but using "wait").

Re: r3829 WRF_NOSWITCH behaviour?

by Gez » Fri Jan 18, 2013 4: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.)

Re: r3829 WRF_NOSWITCH behaviour?

by Enjay » Fri Jan 18, 2013 2: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 all

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]

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

by Ed the Bat » Fri Jan 18, 2013 12: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.

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

by Kate » Fri Jan 18, 2013 12:27 am

That's because this.

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

by Ed the Bat » Thu Jan 17, 2013 10: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 79 times

Re: r3829 WRF_NOSWITCH behaviour?

by Kate » Sun Jan 13, 2013 11:46 pm

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.

Re: r3829 WRF_NOSWITCH behaviour?

by Blue Shadow » Sun Jan 13, 2013 7: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.

Top