[2.5.0] Three bugs in one

[pkmnfrk]

Bug #1:

I have the following Decorate script:

Code: Select all

Actor IjiMachineGun : DoomWeapon replaces Chaingun 10011 {
	Game Doom
	Weapon.SelectionOrder 50
	Weapon.AmmoUse 1
	Weapon.AmmoGive 10
	Weapon.AmmoType "IjiClip"
	Weapon.SlotNumber 2
	Radius 24
	Inventory.PickupMessage "You got the Machine Gun"
	Obituary "%o was perforated by %k's machine gun."
	
	var int user_mgun_ammo;
    
	States {
	Ready:
		GUN1 A 1 A_WeaponReady
		Loop
	Deselect:
		GUN1 A 1 A_Lower
		Loop
	Select:
		GUN1 A 1 A_Raise
		Loop
	Fire:
        	GUN1 A 0 A_SetUserVar("user_mgun_ammo", 10)
		GUN1 A 0 A_FireBullets(5.6, 0, 1, 5, "BulletPuff", FBF_USEAMMO) // A_FireCGun
        	GUN1 A 0 A_PlaySound("weapons/chngun", CHAN_WEAPON)
        	GUN1 A 4 A_GunFlash
		GUN1 A 0 A_ReFire
	Hold:
        	GUN1 A 0 A_FireBullets(5.6, 0, 1, 5, "BulletPuff", 0) // A_FireCGun
        	GUN1 A 0 A_PlaySound("weapons/chngun", CHAN_WEAPON)
        	GUN1 A 4 A_GunFlash
        	GUN1 A 0 A_JumpIf(user_mgun_ammo == 0, "Fire")
        	GUN1 A 0 A_SetUserVar("user_mgun_ammo", user_mgun_ammo - 1)
		GUN1 A 0 A_ReFire
		GUN1 B 10
		GUN1 CDEF 1
		GUN1 GHIJ 1
		goto Ready
	Spawn:
		MGUN A -1
		stop
	}
}

ACTOR IjiClip : Ammo 2007
{
    Game Doom
    SpawnID 11
    Inventory.PickupMessage "$GOTCLIP" // "Picked up a clip."
    Inventory.Amount 1
    Inventory.MaxAmount 10
    Ammo.BackpackAmount 1
    Ammo.BackpackMaxAmount 20
    Inventory.Icon "CLIPA0"
    States
    {
    Spawn:
    CLIP A -1
    Stop
    }
}

Actor Iji : PlayerPawn {
	player.startitem "IjiMachineGun"
	Player.WeaponSlot 2, "IjiMachineGun"
	Player.DisplayName "Iji"
	Player.JumpZ 16
    
}

EDIT: Whoops! This bug is a duplicate! The other two are legit, though

Included is a replacement for the chain gun, which is should operate similarly. However, for various reasons, I want the ammo usage to be different. Basically, I want to give the player 10 bullets/ammo usage. So, 20 ammo means 200 shots. (This is to fit in with the ammo for the other weapons, which are not rapid fire, etc, etc)

To do this, I did... well, what you see up there. In theory, this should work. However, in practice, I get the following error in the console:

user_mgun_ammo is not a user variable in class DoomPlayer

And,

(Sidebar: In GZDoom, the class mentioned will be "Iji". See Bug #2)

To try it yourself, use the attached pk3, fire up idfa and hit 2. When you fire, the bullet ammo will go down by 1, and stay there as long as you hold down the button (and, the console will spew errors). It SHOULD go down by 1 every 10 rounds (or, possibly 11 if I have an off by one error...)

Bug #2:

This is my MapInfo.txt (also included in the pk3):

Code: Select all

gameinfo {
    PlayerClasses = "Iji"
}

According to the wiki, that should restrict the available classes to "Iji" and (since there's only 1) default to using it. ZDoom does not, however, defaulting to "DoomPlayer".

GZDoom, however, DOES use the "Iji" class.

Bug #3:

In GZDoom, when you die while running the attached pk3, it crashes. This is because it's using the "Iji" player class. Vanilla ZDoom does not crash, but that's because it's not using the "Iji" class in spite of my efforts otherwise (see Bug #2). I did get it once or twice, though, which is how I know it crashes.

According to testing right now, it crashes because I don't define any states (derp). However, it doesn't cause any problems until you die. And, it shouldn't crash. Maybe spew some errors, but anything other than crashing.

[Graf Zahl]

Bug #2: That feature is post- 2.5.0. Use a newer SVN build.
Bug #3: You cannot define players without states. It crashes because if there is no death state the player gets removed when you die and without a player the game can't work.

[pkmnfrk]

Bug #2: That feature is post- 2.5.0. Use a newer SVN build.

Oh. Well, so it is. Perhaps I should update the wiki, then...

Bug #3: You cannot define players without states. It crashes because if there is no death state the player gets removed when you die and without a player the game can't work.

Fair enough. But, perhaps it should handle this situation a bit more gracefully.

Meh, either way, it shouldn't ever happen, so whatever.