Been a while since the last post, so I thought I should go over some of the things that have gone down since last time I vomited my deranged thoughts onto the internet.
First of all, SpawnWhenTriggered had to be partially rewritten in order to work online; the way we were doing it resulted in creatures which generated overlay effects having multiple copies of their effect spawned online due to the way relevance works. We both learned a lot about netcode while debugging this issue, though, and our new system takes this behavior into account.
UA also improved beam performance online, resulting in unbelievably smooth beam movement in coop. It is absolutely crazy how well this stuff performs now. He’s even gotten a new flare physics system in place which, again, works flawlessly online (and about a billion times better than the original flare code, which is absolute ass).
But probably my favorite recent change has been the brand new, rewritten-from-scratch seeking projectile code, which is far more robust and cleaner than before, all while performing better on and offline. One of our experiments online in Map 19 turned into what has been quite possibly the most hilarious thing I have ever seen happen on this engine.
So, first of all: SpawnWhenTriggered. I had this shit all figured out offline, and then the engine went and took a dump on my dreams as soon as I fired up a dedicated server to test it. This seems to be a common occurrence when it comes to netcode.
Anyway, all creatures were spawning properly, but they were generating crazy amounts of overlay effects; this resulted in things like Lavatitans and Archdemons having FREAKISHLY BRIGHT lava glows, because they had eight or ten of them instead of one. Why was this happening online and not off? Relevance.
While investigating the problem, UA discovered that all actors call Destroyed() and PostBeginPlay() repeatedly online (clientside). Whenever an actor becomes irrelevant, it destroys itself on the client (so only the server keeps track of it), effectively removing the actor until it becomes relevant again, whereupon PostBeginPlay() is called again and the actor reappears on the client.
This means that not seeing an Archdemon or Lavatitan or what have you and then seeing it again would cause extra effects to spawn and not always get destroyed properly. What we ended up doing to solve this crisis involved a new overlay-spawning system built into EXUScriptedPawn. Basically, we had to resort to proxy actors (yeah yeah I know) to generate the pawn’s effects. The proxy actors generate these effects and then destroy themselves immediately afterward, setting the spawned effects’ owner to the proxy’s owner.
All in all, the new system ended up working fine on and offline, but it resulted in a ton of rewrites of pawn classes and the creation of new proxy classes to handle all of their unique cases. However, I did manage to simplify some of the spawning mechanisms due to the nature of the system, and it DID allow me to clean up older, shittier classes in the process, so it’s not all bad – in fact, it might not be bad at all. It definitely makes it a lot easier to just slap some overlay effects onto any given pawn if you use a preset proxy class, of which there are many now, some of which are shared between classes (which formerly would have done all their own spawning shit in PostBeginPlay()).
There is still one problem left with SpawnWhenTriggered, though, and it’s on and offline. Part of the SpawnWhenTriggered state sets the “unspawned” creatures’ physics to PHYS_None so it will remain exactly where it was placed in UED. This is all well and good, but if you specify an alternate startup state, it won’t work properly. For example, “Patroling” – this state just doesn’t work; the pawn will fail to find its initial PatrolPoint. But if we disable the setphysics line, which of course isn’t an option if we want SpawnWhenTriggered to do what it’s supposed to, the pawn WILL start patroling once spawned. So we are going to have to find some workaround to fix this problem, but it should be doable.
That about covers the SpawnWhenTriggered stuff, and the beams are pretty self-explanatory. And while there have been lots of netcode updates and bug-fixing improvements (for instance, Shitballs and Shit Canisters were totally recoded, and now perform waaaaaaaay better online, which is awesome), nothing else holds a clusterfuck candle to the new seeker code.
UA really did some amazing shit here, and after I ported the Clusterfucker rockets and other various seekers to the new system, everything began performing AMAZINGLY. Missiles will now spiral around in circles until they hit their target if they have a solid lock, which looks hilarious when you have lots of rockets going after several targets at once. Missiles will redirect smoothly and quickly, and Fusion Seekers from the Fusion Flare look even more amazing in action. The result is very little waste – almost all seeker projectiles will reacquire targets and hit SOMETHING when before they would have missed due to improved targeting and lock code and re-lock behavior. It’s awesome.
But the REALLY amazing thing I did was to take a Super Sneer and make a version of it that seeks: the ULTRA SNEER.
We summoned thousands of these things in Map 19, set their target acquire range to 16384 (huge distance), and let them at it. Every time an enemy spawned into the map, THE MOTHER FUCKING SWARM converged on it and sneer’d it to oblivion almost instantly – even ARCHDEMONS. The Sneers just tore shit the fuck up and it was easily one of the funniest, most amazing things I’ve ever seen in EXU. Words can barely do it justice; you’ll just have to see for yourself when EXU2 goes final and you can summon a bunch of SneerBurst projectiles which spawn 100 Ultra Sneers apiece!