search

ZeroK-RTS / Zero-K

Open source RTS game running on the Spring/Recoil engine
https://zero-k.info
GNU General Public License v2.0
685 stars 205 forks source link

Check Gauss animations #3295

Closed sprunk closed 5 years ago

sprunk commented 6 years ago

[03:39] _Shaman: in the current test version [03:39] _Shaman: for some reason, guass fucks up big time and causes massive lag [03:39] _Shaman: it keeps calling the unpack-pack animation [03:40] _Shaman: like rapidly calling it

ArchShaman commented 6 years ago

See #3296 (cuz you beat me to it :( )

ArchShaman commented 6 years ago

This actually is in stable too and oh boy, it's a lag machine. You remember the solar panel mass lag thing? this is even cheaper. I've replicated it here: https://youtu.be/5kXd2l4AFHI

Battle in question: http://zero-k.info/Battles/Detail/630776 (occurs ~18:36)

ArchShaman commented 6 years ago

Can Confirm it wasn't @Anarchid 's guass turret fix that caused this. The bug has been present since April. Tested on v1.6.4.32 and bug was present. My estimate is that this goes all the way back to it's creation. Either that or it's an engine related bug.

GoogleFrog commented 6 years ago

The model is a dae, so I assume @Anarchid made it. I haven't tried to open the file, but the bug looks like it is caused by a piece that both changes location and is returned by AimWeapon.

Anarchid commented 6 years ago

This should not be the case. The model has a separate, immobile piece for aiming, for that exact reason.

https://github.com/ZeroK-RTS/Zero-K/commit/cd56bfc129b593d064d873e09108add3ef0526fe#diff-aa9ff8d9c35c6986adab62311686c454 could be relevant?

ArchShaman commented 6 years ago

Another incident: http://zero-k.info/Battles/Detail/631031 (recreated for funz)

GoogleFrog commented 6 years ago

QueryWeapon could be it. Fire checks come from both the query and the aim piece.

Anarchid commented 5 years ago

My current primary suspicion is that the problem is that boolean shift between two QueryWeapon pieces causes a very sharp non-continuous angle change, which in turn causes the weapon to oscillate between two states every frame when the angle-to-target difference between those pieces is large enough.

A proper fix that retains the hax in cd56bfc would be an extra rotatable proxy aiming piece that aligns perfectly with Muzzle when unpacked, eliminating the discontinuity. I'll try this sometime weekendly-ish.

Anarchid commented 5 years ago

^ The above implements the solution proposed in the previous message.