[2.2.0] Problems with Sigil in Deathmatch

[Jorto Badfingers]

So, I was playing some bots in deathmatch, and decided to use the lego cheat to obtain certain pieces of the Sigil. Piece one did no damage at all to other players/bots. Pieces 2-4 only did damage to players if used at point blank range, and Piece 5 appears to only deal damage via the main projectile at point blank range or via the side or via the secondary projectiles which come out of the main projectiles. These secondary projectiles do not attribute frags to a player who kill his/her opponent. The point blank shots for Pieces 2-5, however, did give frags. I confirmed the fact that numerous pieces were not doing damage using the linetarget command and via running two instances of a deathmatch game with sv_cheats set to true for testing purposes. Curiously enough, the Sigil appears to work perfectly fine against monsters, but deals inadequate damage against players or bots. There also seems to have been a similar problem reported some time ago here, http://forum.zdoom.org/viewtopic.php?f= ... 0&p=188004, but in spite of many efforts, I still am unable to deal damage to players.

[Graf Zahl]

Unfortunately the spectral damage handling is massively screwed up in Strife. These are just some of the examples that happen. They implemented it so that the Sigil only can hurt monsters and that spectral monsters' projectiles only hurt players - but obviously it suffers from this problem as well. I guess it has to be completely redone so that the weapon works in Deathmatch.

[randi]

Was the Sigil actually available in vanilla Strife deathmatch?

[Graf Zahl]

Yes. It's the only place where the Sigil pickups were spawned.

[Graf Zahl]

fixed. This was an utter and complete mess in Strife. I hope now it's working better.

[Gez]

Looking here, there's something that intrigues me.

The old code said:

Code: Select all

            // Although there is a P_SpawnMissileZ function its
            // aiming is much too bad to be of any use
            self->z+=SpawnHeight-32*FRACUNIT;
            AActor * missile = P_SpawnMissile (self, self->target, ti);
            self->z-=SpawnHeight-32*FRACUNIT;

The new code says:

Code: Select all

            // This seemingly senseless code is needed for proper aiming.
            self->z+=SpawnHeight-32*FRACUNIT;
            AActor * missile = P_SpawnMissileXYZ (self->x, self->y, self->z + 32*FRACUNIT, self, self->target, ti, false);
            self->z-=SpawnHeight-32*FRACUNIT;

I don't get what is the point of substracting 32*FRACUNIT in order to add it just after. Couldn't it be this instead?

Code: Select all

            // This seemingly senseless code is needed for proper aiming.
            self->z+=SpawnHeight;
            AActor * missile = P_SpawnMissileXYZ (self->x, self->y, self->z, self, self->target, ti, false);
            self->z-=SpawnHeight;

Which in turn could be reduced to just this so that self->z isn't changed just for this function and reverted after...

Code: Select all

            // Proper aiming code.
            AActor * missile = P_SpawnMissileXYZ (self->x, self->y, self->z + SpawnHeight, self, self->target, ti, false);

[Graf Zahl]

Looking here, there's something that intrigues me.

I don't get what is the point of substracting 32*FRACUNIT in order to add it just after. Couldn't it be this instead?

Read my comment above the line. Yes, it makes a difference - the aiming is completely different for both cases. That's the different aiming modes A_CustomMissile offers.

[Gez]

The only way P_SpawnMissileXYZ can tell the difference is if it compares heights... Oh.

Code: Select all

	else if (z - source->z >= dest->height)

Sure is an odd method, though.


... By the way, when FRandom pr_212e4 ("212e4") was changed to FRandom pr_spectrechunk ("212e4"), the reason the parameter wasn't updated as well (to something like "AlienSpectreChunck" for example) is so as to not have to bump the min save version because it could break current Strife saves, right?

[Graf Zahl]

... By the way, when FRandom pr_212e4 ("212e4") was changed to FRandom pr_spectrechunk ("212e4"), the reason the parameter wasn't updated as well (to something like "AlienSpectreChunck" for example) is so as to not have to bump the min save version because it could break current Strife saves, right?

No, it was because I was lazy. I just found pr_212e4 and did a search&replace on it without thinking about the name. It's for internal maintenance only and doesn't really matter. It would have affected demo compatibility (which was shot to hell by the changes anyway) but savegames, although affected, would not break.