Problem with 0 tic loops online.

[XutaWoo]

Okay, so basically I have a clientsided actor spawning clientsided actors. I have a clientsided actor spawning a lot of clientsided actors. How many? Well ...

Code: Select all

   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 0, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 5, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 10, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 15, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 20, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 25, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 30, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 35, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 40, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 45, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 50, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 55, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 60, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 65, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 70, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 75, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 80, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 85, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 90, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 95, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 100, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 105, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 110, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 115, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 120, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 125, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 130, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 135, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 140, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 145, SXF_CLIENTSIDE)

... Yeah.

That's not even all of them.

So, my solution was instead to do a limited 0 tic loop, like such.

Code: Select all

  SpawnLoop:
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 0, SXF_CLIENTSIDE)
   TNT1 A 0 A_SetAngle (angle + 5)
   TNT1 A 0 A_GiveInventory ("ChargeTime", 1)
   TNT1 A 0 A_JumpIfInventory ("ChargeTime", 72, "SpawnEnd")
   loop

And it worked.

Offline.

However, online, Zand freaks the heck out and slows to the crawl as it spawns the HitspawnParticles without stop. So, I know why the client-killing lag happens. What I don't understand is why the loop breaks and turns into an infinite 1 tic loop, since it works perfectly fine offline and in GZDoom. Only online does it have such a bad freak out.

So, how do I avoid this, and if I can't, what can I do instead of the massive wall of A_SpawnItemExs or this online-breaking loop?

[CloudFlash]

Maybe instead of

Code: Select all

   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 0, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 5, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 10, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 15, SXF_CLIENTSIDE)
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 20, SXF_CLIENTSIDE)
Etc etc etc

Do something like

Code: Select all

TNT1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 0 A_SpawnItemEx("HitsparkParticle",97.5, 0, 0, -6.5, 0, 0, random(0,150), SXF_CLIENTSIDE)

[XutaWoo]

The issue with that is that to make a perfect circle with that, I'd have to spawn more than 360 actors rather than the 72 that I am right now, and even then that wouldn't be assured. 72 already feels pretty huge for just some particles.

Granted, an idea has popped to mind, but I'll feel the need to flick the Zand devs on the forehead if it works better than what I'm trying.

[Dark-Assassin]

In this case, I guess only the former can be performed.
It's an inconsistency that has been around since probably forever (Skulltag) and possibly couldn't be fixed.

Should also try to see if ZDoom freaks out when you set up a network game with this.
Oh, and try Zandronum 2.0

[Ijon Tichy]

If it's clientsided (+CLIENTSIDEONLY), it should be fine. Server actors don't have inventory changes sent to the clients, except to the client's own player, and so A_JumpIfInventory never actually jumps.

Had almost this exact issue with a chaingun grenade - it would constantly flicker between exploded and not-exploded when lying on the ground since an A_JumpIfInTargetInventory never actually ran, and the client jumped ahead.

Had a similar issue with a minigun flame which spewed out all the particles it had left on death - no matter how far it went, it still spewed out something like 250 particles per flame. The minigun fired a flame every tic.



People use SXF_CLIENTSIDE? I never trusted it.

[Cruduxy]

If the particles follow a specific movement pattern you should do it with a sprite. Because 360 or even 70 is a shitton of actors o_0

[XutaWoo]

If it's clientsided (+CLIENTSIDEONLY), it should be fine. Server actors don't have inventory changes sent to the clients, except to the client's own player, and so A_JumpIfInventory never actually jumps.

Had almost this exact issue with a chaingun grenade - it would constantly flicker between exploded and not-exploded when lying on the ground since an A_JumpIfInTargetInventory never actually ran, and the client jumped ahead.

Had a similar issue with a minigun flame which spewed out all the particles it had left on death - no matter how far it went, it still spewed out something like 250 particles per flame. The minigun fired a flame every tic.



People use SXF_CLIENTSIDE? I never trusted it.

I'm not entirely sure how to interpret this - so is it a lost cause or not? Because while I am pretty sure it doesn't have any effect on the server itself, something screws up and the client is rendered unplayable.

Adding +CLIENTSIDEONLY or changing the item check into Inventory does nothing.

If the particles follow a specific movement pattern you should do it with a sprite. Because 360 or even 70 is a shitton of actors o_0

Models, you mean? Because sprites wouldn't work at all. Even then, I know one thing I'm using this for would require such a messy, mindbending model that just using a ton of particles is probably better for the computer looking at it..

[Cruduxy]

You can split the different parts of the effect you know.. Anyway think you should show a screenie of the effect so people might suggest better alternatives.

[Zalewa]

I've already responded to your tracker ticket (which got closed). The loop works perfectly if you remove all CLIENTSIDE flags. The problem, as others have stated, seems to be located in actor's inventory.

Your example edited:

Code: Select all

actor Hitspark
{
  renderstyle None
  +NOGRAVITY
  +NOBLOCKMAP
  states
  {
  Spawn:
   TNT1 A 0
  SpawnLoop:
   TNT1 A 0 A_SpawnItemEx ("DoomImpBall2", 0, 0, 0, 6.5, 0, 0, 0)
   TNT1 A 0 A_SetAngle (angle + 5)
   TNT1 A 0 A_GiveInventory ("Clip", 1)
   TNT1 A 0 A_JumpIfInventory ("Clip", 72, "SpawnEnd")
   loop
  SpawnEnd:
   MISL B 20
   stop
  }
}

actor DoomImpBall2 : DoomImpBall
{
  damage 0
  +THRUACTORS
}

actor DoomImp2 : DoomImp
{
  health 9999
  states
  {
  Pain:
   TROO H 2 A_SpawnItemEx ("Hitspark", 0, 0, 32, 0, 0, 0, 0, SXF_NOCHECKPOSITION)
   TROO H 2 A_Pain
   goto See
  }
}

This causes some hit on the net traffic where each spark spawner causes additional 2kB/s of traffic in this case. If that's something that you find unacceptable, I guess you have to use your original, exploded solution.

Personally, I would find such lack of functionality infuriating back in the day, but now I think I'd just write myself a Python script that would spawn appropriate, exploded DECORATE code automatically and don't bother myself with silly engine limitations.

[XutaWoo]

I guess I should ask if uservars are in 2.0, which would make more than adequate replacements should they actually behave with clientside actors. It'd be quite the delay, but eh.

[Torr Samaho]

Code: Select all

  SpawnLoop:
   TNT1 A 0 A_SpawnItemEx ("HitsparkParticle", 97.5, 0, 0, -6.5, 0, 0, 0, SXF_CLIENTSIDE)
   TNT1 A 0 A_SetAngle (angle + 5)
   TNT1 A 0 A_GiveInventory ("ChargeTime", 1)
   TNT1 A 0 A_JumpIfInventory ("ChargeTime", 72, "SpawnEnd")
   loop

Basically Ijon already answers why this doesn't work, but let me describe this in a bit more detail: For non-clientside actors, clients lack the information to handle most of the A_Jump* statements on their own. So they simply ignore the statement and move on as if the jump condition was false. Meanwhile the server will notice that the jump condition is fulfilled and tell the clients to do the jump. This doesn't work with infinite loops of zero duration though. The sever can't inform the client while the client is stuck in such a loop.

What should work is to move your looped spawn code to a new invisible actor and let your original actor spawn that one client side instead of doing the spawn loop on its own.

[XutaWoo]

I'm not sure if I quite understand. Currently, I have a sort of spawn hierarchy like this:

Code: Select all

Player
- The Posted Actor ( CLIENTSIDE )
-- HitsparkParticle ( CLIENTSIDE )

So, do I do something like this for a spawn hierarchy?

Code: Select all

Player
- The posted actor ( CLIENTSIDE )
-- Another actor ( CLIENTSIDE )
--- HitsparkParticle ( CLIENTSIDE )

Or should the posted actor no longer be clientside?

I suppose that wouldn't quite make sense, since I already have an actor with a 0 tic loop being spawned by a non-clientside actor. I just want to make sure you meant to double up on how clientsided the loop is.

[Torr Samaho]

Code: Select all

Player
- The Posted Actor ( CLIENTSIDE )
-- HitsparkParticle ( CLIENTSIDE )

Oh, I overlooked that your original actor is CLIENTSIDE. Then, your construct should work. If it doesn't, it looks like a Zandronum bug. Please open a tracker ticket and add a minimal example wad.

[Zalewa]

Oh, I overlooked that your original actor is CLIENTSIDE. Then, your construct should work. If it doesn't, it looks like a Zandronum bug. Please open a tracker ticket and add a minimal example wad.

It's already reported:
http://zandronum.com/tracker/view.php?id=1832

[Torr Samaho]

It's already reported:
http://zandronum.com/tracker/view.php?id=1832

I see. This ticket was closed before I noticed it. I'll look into the issue.

[Zalewa]

I see. This ticket was closed before I noticed it. I'll look into the issue.

Thank you. I dislike when problems like this one get dismissed or blamed on the WAD not being designed properly, although in this case I would be inclined to just assume that client doesn't handle clientside inventory properly by intentional design, as CLIENTSIDE flag was always pretty limited to what could be done.

[Torr Samaho]

https://zandronum.com/tracker/view.php?id=1832#c9474

EDIT:

in this case I would be inclined to just assume that client doesn't handle clientside inventory properly by intentional design, as CLIENTSIDE flag was always pretty limited to what could be done.

No, this was not intentional. The problem is that many functions need to be explicitly adapted to work properly with CLIENTSIDE actors. I can only fix those that are reported as being broken.