A_JumpIfCloser not working on weapons

DoomRater · Post by **DoomRater** » Wed Jul 16, 2008 20:31

I tested over on ZDoom 2.2.0 and this worked, however the JumpIfCloser never activates on GZDoom.

ACTOR KnifeGrenade : Weapon Replaces Fist
{
attacksound "weapons/sawhit"

States
{
Select:
SAWG A 1 A_Raise
Loop
Deselect:
SAWG A 1 A_Lower
Loop
Ready:
SAWG A 1 A_WeaponReady
Loop
Fire: //swing a knife animation
PUNG A 3 
TNT1 A 0 A_Refire
SwingKnife:
SAWG B 3 //A_ClearRefire  //not implemented yet?
TNT1 A 0 A_PlayWeaponSound("weapons/sawfull")
SAWG C 3 A_CustomPunch(5,0,1,"BulletPuff",80)
SAWG D 2
PUNG A 7 //A_Refire //can't test this yet
Goto Ready
Hold: //throw a knife animation
TNT1 A 7
TNT1 A 0 A_JumpIfNoAmmo("SwingKnifeHARD")
TNT1 A 0 A_JumpIfCloser(96,"SwingKnifeHARD")
PUNG D 3 offset (-55, 32)
PUNG C 3 offset (35, 32) A_FireCustomMissile("KnifeSpam",0,1)
PUNG B 3 offset (125, 32)
PUNG A 5 offset (1, 32) A_Refire
Goto Ready
SwingKnifeHARD:
SAWG B 2 //A_ClearRefire
SAWG C 2 A_CustomPunch(7,0,1,"KnifeHitsWall",80)
SAWG D 2
PUNG A 9 //A_Refire

}
}

Post by **Enjay** » Wed Jul 16, 2008 21:40

Do you know if it works with more recent SVN versions of Zdoom? The current official GZdoom is based of a more recent version of the Zdoom SVN than the official Zdoom (2.2.0) is.

DoomRater · Post by **DoomRater** » Wed Jul 16, 2008 23:10

There doesn't seem to be a newer version of GZdoom than 1.1.4, and I already reported a bug that was due to compiler differences rather than different code, but I suppose I should take a look if only to use the development version codepointers I have commented out.

Can you recommend some SVN builds, or at least a place where I can stay up to track on those?

Post by **Enjay** » Thu Jul 17, 2008 0:42

Sorry, perhaps I wasn't clear. The latest official GZdoom is 1.1.4 but that is based of newer code than the latest official Zdoom.

So what I was trying to say is that this bug might still be a Zdoom problem, but one that wasn't present when 2.2.0 was released. It could have crept into the post-2.2.0 code which has since been used to base GZdoom 1.1.4 on. A way to check this would be to try a more recent Zdoom SVN version which may have the newer, problematic code. If the problem exists there, then it's a Zdoom problem rather than a GZdoom one. Given that this bug isn't obviously related to the OpenGL nature of GZdoom, it strikes me as quite likely that it might be Zdoom, rather than GZdoom, related.

Anyway, the best place to get compiled versions of the SVN code is linked to from the front page of the Zdoom Wiki. Nash is the one responsible for building them and here's where you will find them:

http://nash.wanzafran.com/doomstuff/svn/

DoomRater · Post by **DoomRater** » Thu Jul 17, 2008 1:39

Yeah, I knew what you meant, but was feeling lazy about looking up SVN builds.

By the way, the movespeed bug was where a nasty compiler difference produced incorrect behavior between ZDoom and GZDoom.

ANYWAY, works in experimental ZDoom (that is, the last SVN build) and in experimental GZDoom. So it has been fixed, whatever the problem was.

Post by **Graf Zahl** » Thu Jul 17, 2008 8:21

DoomRater wrote: By the way, the movespeed bug was where a nasty compiler difference produced incorrect behavior between ZDoom and GZDoom.

Not a compiler problem but a compiler settings problem.

Both ZDoom and GZDoom are compiled with the same compiler (VC++ 2008) but I had to change the floating point precision setting in GZDoom because enforcing strict correctness slows down the renderer by approx. 10%.

Post by **Graf Zahl** » Thu Jul 17, 2008 8:24

And just fyi, I'd very much like to release a new version but I'm waiting for Randy to do some work on the sound code. It still has some problems I don't want to have in an official release.