MODELDEF: Offsetting Visible Projectile

[ReX]

I am using a model for a projectile, which does not "emerge" centered from the weapon in the HUD. Instead, no matter what offsets I use, it always originates to the right of the weapon's muzzle. I have checked the wiki, but it only briefly touches on offsets. Here is the MODELDEF code I'm using:

Code: Select all

Model BlasterRedBolt
{ 
   Path "Models"
   Model 0 "RedBolt.md3"
   Skin 0 "RedBolt.png"
   Scale 0.4 3.0 3.0
//   Offset -150.0 0.0 5.0
   Offset 0.0 0.0 5.0
   PITCHFROMMOMENTUM
   
   FrameIndex PRBT A 0 0
}

As you can see, I tried an x-offset (which I then commented out). Regardless of the x-offset I use, the model seems to emerge at virtually the same spot relative to the weapon's muzzle. I'd appreciate any suggestions. Thanks.

[Enjay]

Obvious question: does a correctly centred spite appear in the correct position relative to the weapon?

If not, the problem is more likely to be in your DECORATE code than the MODELDEF.

If the sprite is correct, the model itself may have a weird position for the mesh. It would be easy enough to move it in a model editor.

[ReX]

Obvious question: does a correctly centred spite appear in the correct position relative to the weapon?

The curious thing is, I don't see any reference to projectile sprites in the weapon's definition. Here it is:

Code: Select all

ACTOR blaster_rifle : BaseWeapon
{
	Weapon.AmmoType 		"energy_cell"
	Weapon.AmmoGive 		15
	Weapon.AmmoUse			2
	Weapon.Kickback			10
	Weapon.SelectionOrder	8
	Weapon.SlotPriority		0
	Inventory.Icon			"RIFPA0"
	Inventory.PickupMessage "blaster rifle"
	+WEAPON.AMMO_OPTIONAL
	States
	{
		Spawn:
			RIFP A -1
			Stop
		Ready:
			RIFL A 2 A_WeaponReady
			Loop
		Select:
			RIFL A 1 A_Raise
			RIFL AA 0 A_Raise
			Loop
		Deselect:
			RIFL A 1 A_Lower
			RIFL AA 0 A_Lower
			Loop
		Fire:
			RIFL A 0 A_JumpIfNoAmmo("NoAmmo")
			RIFL A 2
			RIFF A 4 BRIGHT A_FireCustomMissile("BlasterRedBolt", Random(-1, 1), 1, 5, 0, 0, Random(-1, 1))
			 RIFF A 0 A_PlaySound("weapon/blaster/fire",CHAN_WEAPON,1.0,0,ATTN_NORM)
			 RIFF A 0 A_GunFlash
			RIFL A 5 A_Refire
			Goto Ready
		NoAmmo:
			RIFL A 12 A_PlaySound("weapon/blaster/empty",CHAN_WEAPON,1.0,0,ATTN_NORM)
			RIFL A 0 A_WeaponReady(WRF_NOFIRE)
			Goto Ready
		Flash:
			TNT1 A 1 A_Light(1.0)
			TNT1 A 1 A_Light(0.6)
			TNT1 A 1 A_Light(0.2)
			TNT1 A 1 A_Light(0.0)
			Stop
	}
}

Actor BlasterRedBolt : StandardRedBolt { Damage (10) -FORCEPAIN }

Actor StandardRedBolt //: FastProjectile
{
	Radius 2
	Height 2
	Speed 60
	Projectile
	+NOGRAVITY
	+FORCEPAIN
	DeathSound "BoltExplode"
	States
	{
	Spawn:  
		PRBT A 1 Bright 
		Loop
	Death:
		LPFF ABCDEF 3 Bright
		Stop
	}
}

[Enjay]

Assuming that BlasterRedBolt is the actor, its sprites are PRBTA* in the spawn state sequence and LPFFA*,B*,C*,D*,E*,F* in the death state sequence.

And from your code, PRBTA (probably PRBTA0) is the sprite that the model is attached to.

The weapon doesn't reference those sprites - nor should it. The weapon fires the projectile and the projectile makes reference to the sprites.

[Cherno]

Code: Select all

         RIFF A 4 BRIGHT A_FireCustomMissile("BlasterRedBolt", Random(-1, 1), 1, 5, 0, 0, Random(-1, 1))

The fourth parameter (5) is the horizontal offset of the spawned projectile. Positive values makes the projectile emerge to the right of the screen center.

[ReX]

.... PRBTA (probably PRBTA0) is the sprite that the model is attached to.

The source file from which I cobbled the MODELDEF code does not have sprites named PRBTA0, which is curious in light of your explanation.

The fourth parameter (5) is the horizontal offset of the spawned projectile. Positive values makes the projectile emerge to the right of the screen center.

This, indeed, solved the problem. For reference, a value of 1 is ideal for my purposes.

Thanks to you both for your efforts.

[Enjay]

Ooops, I should have spotted the offset in the weapon code too. Good catch Cherno.

The source file from which I cobbled the MODELDEF code does not have sprites named PRBTA0, which is curious in light of your explanation.

Possibly not. If you look in my Genetech mod (I'm not actually encouraging doing so - it's not a simple example), there are lots of model actors and many of them use a huge number of sprites. However, if you look inside the PK3, you won't find those sprites. That's because I used the TEXTURES lump to define literally hundreds of sprites for use in the models - but there is only one graphics lump used by all of the text-defined sprites.

I'm not certain, but I think things may even have moved past that and it may now even be possible to not do the above. I could be wrong here (because I haven't tested it) but it *might* be the case that you can get away without defining sprites in textures. Just as long as your DECORATE and MODELDEF reference the same sprite names, I *think* the sprites don't actually have to exist. Don't take that as gospel though, I really need to check it to be sure.
OK, scrap the above paragraph. It does not seem to be correct. I just replaced the DECORATE and MODELDEF definitions of a simple model actor with sprites that don't exist. It did not work (actor has no frames error). However, it is possible to get it to work with only the first sprite being valid and the rest not. I don't know if that's considered good editing or not though. Seems like it might not be to me.