[r4172] 0 tic frames not always lasting 0 tics

[GFD]

I was making voxel models of Cave Story weapons, when I decided it might be cooler to have the trails of the weapons be transparent. So in addition to the bullet, I made my weapons fire a near-identical actor for the trail (the only differences being the states and some properties, like Damage 0). Then I noticed that one of my weapons wasn't in sync with its trail, and after a long bout of analyzing this, I discovered removing some 0-tic frames on the bullet made them go back in sync.
Example wad here. Both the bullet and the trail will create a star effect when they die (the weapon is short-range). The primary fire fires a trail and a blade with some 0 tic frames in its Spawn state to play some sfx. You can see that the star effects spawned by these two actors spawn at different times in different places, which they shouldn't, because both actors have the same properties (including speed, etc) and (in theory) the same lifespan. The alternate fire fires the same trail, and a blade identical to the former except it has no 0 tic frames in its Spawn state.

[Enjay]

When I ran the mod, I stood facing a wall and was able to get myself into a position where the primary fire would produce a death sound because it was hitting the wall. However, from the same position, the secondary fire would die before hitting the wall and so did not make a death noise. (The distance is about 192 units btw).

Here's my guess. It's not that the frames are lasting longer than 0 tics but the fact that you are calling more frames in a tic. Therefore the number of calls/checks/ or whatever they are to the movement code has increased and so the projectile is moving faster (and thereby further). If this is the case, then lots of effects in Doom/ZDoom rely on this and, I suspect, it should not be changed. If I'm right, then it won't be changed but the obvious editing solution to your problem would be to give other matching 0 tic frames to keep them all in check with each other.

[GFD]

So, according to your theory, if I were to add a whole bunch of 0 tic frames, the projectile should zoom forward? 'Cuz it doesn't move any faster if I do that...

This is so confusing.

[Enjay]

That would have been my guess, yes. Certainly, if you shorten the duration of enemies walking frames they get quicker, and weapons with 0 tic calls to A_Raise or A_Lower raise/lower more quickly.

However, it is just a guess and I don't know for certain that projectiles would behave in this way. My thinking was along the lines of "well, a projectile has no specific pointers to call for its movement so being a projectile must imply calls to the movements code. More frames might mean more calls to the movement code so it goes faster". I could easily be wrong though. Either way, the little test routine that I carried out shows *something* I guess.

[GFD]

Still a better theory than anything I've managed to come up with.

Which is none.

I have no theories this just transcends reality

[Blzut3]

I'm fairly sure this is part of the magical first state (the one that doesn't execute action pointers). What I believe is happening is that P_XYMovement gets called once before the animation starts.

During normal animation, AActor::Tick will not be called while the state has a duration of 0 since the function will return once a state with a duration > 0 is hit. This assumption is false if the Spawn state has a duration of 0. Perhaps the tics-- line needs to happen after the loop?

[Graf Zahl]

It's not that simple. When the first state is set it's just set, without ever checking for amounts of tics. And this is done at a time when the action function can't be called yet.
So a 0-tic duration on the first frame is not really possible.

[Blzut3]

Hmm? This patch seems to solve the problem for me. Is there an obvious reason this wouldn't work? (Note that it isn't exactly what I described in my last post.)

[Graf Zahl]

Well, the biggest problem I see is that this may inadvertently break existing mods. You know yourself how many side-effect-exploiting stuff is out there...

[Blzut3]

I suppose that could be a problem, although I would think the worst that could happen is some timing is off by one tic.

I think it would be wise to try this fix out since I would rather it not become a known quirk, but I'm not sure if Randy is planning to release 2.6.2 in the near future or not.

Edit: My bad. Thanks Gez.

[Gez]

It would be 2.6.2.

[randi]

Added in r4231. Does this break anything or is it safe?

[Enjay]

This is easier to test in GZDoom because the mod uses models but the problem can also be shown in ZDoom.

Using LWM's mod "Cammy", start a game and press the spacebar so that you will spawn somewhere on the map. Type "kill monsters" to get rid of all the bad guys and then "summon devastator". God mode would be handy too.

In GZDoom a model resembling a 40K dreadnought should appear. In ZDoom it will look like a cacodemon. Different parts of the monster can be destroyed separately. Aim for one of the weapon arms (invisible in ZDoom but you can aim to the bottom left or bottom right of the caco to hit them) and shoot it until it explodes. In GZDoom r1555 and ZDoom r4225 the place where the weapon was should start spewing a smoke plume. In GZDoom r1557 and ZDoom r4231 the plume is not visible.

GZDoom r1555: Smokin'


GZDoom r1557: Not Smokin'


I don't *think* this is a sprite sorting issue (as a result of the recent changes) because, using the automap cheat to look at the actors, the smoke plume doesn't seem to be getting spawned at all. So, I think it's a spawning, rather than a rendering issue.


[edit] Now that I look at it again, there are a whole bunch of smoke effects that don't spawn. This can be easily shown by going through the above steps but instead of shooting the devastator's arm, just type "kill monsters" again and it will explode. On the older (G)ZDoom version, all the debris leaves a smoke trail as it scatters. In the newer version there is no smoke. Although the devastator actor is quite complex, I don't think that there is anything particularly unusual about the smoke spawning routine.

I noticed that the smoke actors have a scale of 0 (which is then changed via a script) so I changed that to a non-zero value but the smoke still didn't appear. I also tried commenting out the call to the script in the DECORATE and still no smoke. [/edit]

[edit2]typos[/edit]

[Enjay]

So, I looked at the changelog to see if there were any changes other than the sprite sorting that would affect this. I saw the noextratic fix and thought that might be responsible. Looking at the code for the smoke effects I saw this:

Code: Select all

ACTOR SmokeFX
{
	PROJECTILE
	+FORCEXYBILLBOARD
	+NOCLIP
	Speed 1
	RenderStyle Translucent
	Alpha 1.0
	Scale 0
	States
	{
	Spawn:
		SMOK A 0
		SMOK A 0 ACS_NamedExecuteAlways ("SmokePlume", 0)
		SMOK AA -1
		stop
	Death:
		TNT1 A 1
		stop
	}
}

As an experiment, I tried changing the first spawn frame to have a duration of 1 instead of 0. This made the smoke work with r4231 so it looks like something in the noextratic fix probably is responsible for this. Although I don't know what specifically ZDoom is doing in the background to make this spawn fail, the above code is certainly not particularly unusual so there may well be a number of mods "out there" where this arrangement could cause a problem.

[Gez]

Can you try with r1556?