Status Update news

Update on v7

I've been receiving countless emails and private messages wondering what happened to v7 and where it's at. The good news is that v7 is almost finished - in fact I have one bug left to resolve and I can consider it in a release-able state (although I might cram some more polish into it). It is possible to test a beta version of V7 by going onto our Discord server, where a pinned message in #sef-general has a download link.

The bad news is that the one bug is quite convoluted to test and puzzling to fix. This is on top of my work with VOID Interactive on Ready or Not, which is quite demanding indeed - I work the equivalent of a fulltime job in game development (which as some of you may know, can be quite demanding as it is), whereas before I was working on my Bachelor's (I graduated in May). Fortunately I've had some help from a few notable people who have contributed artwork and number-crunching to the mod, and even some code. Because of their efforts, we will be including Brettzie's M4A1 and the FN FAL!

Background to the bug

One of the principal new features in v7 is the ability to share equipment between teammates. In singleplayer, you are able to command your squadmates to give you a piece of equipment, via a command such as REQUEST FLASHBANG. You can also give your AI teammates a piece of equipment by pressing the melee key on them while holding a relevant piece of equipment. Although you can bind Melee/Check Lock/Give Item separately if you wish, this just leads to less keys needing to be bound. This is working as expected, and although I had to work around a lot of the native loadout code, it wasn't too bad to implement.

The real trouble is with implementing this feature in CO-OP.

When an officer spawns into the game, they have a fixed set of equipment represented by a static array. That is, there are precisely 23 pockets of equipment that are spawned, and we cannot add any more pieces of equipment. The code looks something like this:

var(DEBUG) protected Actor PocketEquipment[Pocket.EnumCount];

This is pretty bad, because we can't add any additional pieces of equipment on a whim. For example, if we want to give someone a piece of equipment, where would it go? We would need to rewrite the entire way that loadouts are represented to make it happen. Expanding the number of pockets or adding another array of given equipment won't work because of the concept of native classes. Native classes cannot have their size differ from a fixed number that is defined in the engine. That is, we cannot alter the number of variables in the loadout. We have to work within the constrained space. If we don't, the game will crash, notifying us that the native class size doesn't match the Unrealscript class size.

This isn't a problem that's exclusive to the Loadout class either - in fact, 40% of SWAT 4's code are native classes that we can't modify the size of. It ranges from basic stuff such as the player itself, to very specific things such as the Optiwand and the Night Vision goggles.

So, what solution did I employ to fix this? Well, the native classes need to fit within a certain number of bytes. So, if we can somehow take the same space and extract more value out of it, we should be good to go.

The key here is that PocketEquipment has a fixed size associated with it - it is an array of 23 Actors (an Actor is anything that is spawned in the world, such as players, items, suspects, ...). But, if we were to remove the size constraint on PocketEquipment, the size actually goes down - by a lot. In fact, we can fit 23 unconstrained arrays in that one array space. Thus, if we change the above section of code to read as follows:

var(DEBUG) protected array<Actor> PocketEquipment;
var(DEBUG) protected array<Actor> GivenEquipment;

var int unused[21];

We use exactly the same amount of space as before, and even have some leftover space to work with. The first array is the equipment that we spawned in with, and the second array is the equipment that we were given from other players. A side benefit of this is that we can now have as many pockets as we want without breaking the game, so things such as gun attachments, weapon skins, and so on could all be possible in the loadout.

However, this causes a number of different chain reactions of breakage in the engine, and it's a matter of finding each cause and neutralizing it. You see, this is Unrealscript code, but on top of these native classes specifically, there is C++ code running (which Irrational has never given us the source code to), and while I can make an attempt to reverse engineer the engine and prevent some of that C++ code from running, it's always going to be a problem.

Particularly, this is a problem with replication - that is, reproducing (replicating) stuff which has occurred in the server's eyes to the client's eyes. In a multiplayer, dedicated server environment, when we give a piece of equipment to another player, we as a client in a multiplayer game aren't actually doing anything - we are telling the server "hey, I want to give my flashbang to the guy in front of me, can you make it happen?" Replication is an extremely complicated subject, and I'm not going to describe it in very great detail here, but it's related to the bug.

Fun fact: I spent about a month fixing the replication for traps and snipers in CO-OP. It was not a fun month.

Instead of straight-up changing the ownership of the item that we are holding, the server takes away one "count" of the item, and either gives another "count" of the item to the other player (if they already have one of those items - you're giving a flashbang to someone who either has one in their possession or they have used one previously), or it spawns a new item and places it in their GivenEquipment in their loadout. That's a bit of a simplification though in the case of pepper spray and the optiwand, which are both "weapons" and not grenades/handheld equipment, but generally, that's how it works.

The Bug Itself

Right, so we have two cases: either you're giving an item to someone who already has one of those items or has at least used one in the past, or you're giving an item to someone who has never held one of those items before. The first case works fine actually, and we can see in the current beta's CO-OP that if we pass a flashbang back and forth between two players who have one in their kit, it works perfectly, although it doesn't notify the player if they can't equip a flashbang because they've given it away, but that's a separate bug entirely.

The other case...doesn't work at all. If we have an optiwand and our teammate doesn't, when we try to give an optiwand to them, it vanishes into the ether, and we cannot ever get that optiwand back. To test out why this occurs, I had to install a virtual machine to run two different instances of SWAT4, and also run a dedicated server as well. And of course, because SWAT 4's version of Unrealscript is highly specialized, I don't have access to a debugger at all, and instead I have to print everything to the log instead of being able to set breakpoints and see the value of variables at real time. But after a lot of test where I recompiled the code over and over again to see why stuff wasn't working, the reason it happens is actually quite straightforward: the client doesn't see the newly spawned optiwand. It's not replicated. The client doesn't think it has spawned. It's "None" to them.

Why does this happen? Well, I have no idea actually. Even if I force the spawned item as being always relevant (and therefore *always* replicating to other clients), the client has no idea that this item is ever existing. I've heard it suggested that clients need a few ticks for the spawned item to be replicated, but it never happens. In fact, looking through the replication logs, it tries to replicate from server to client, but the client doesn't accept the spawned item for some reason or another.

Conclusion

So, if there's some Unrealscript wizards on this website or that people know of that have an idea how to fix it, that's kind of what I'm holding out for. You can kind of see my last attempt at fixing the issue here, but all it was able to do was prove that the newly spawned item never replicates. I might have to figure out some other kind of strategy to make giving items possible. As an ultimate cop-out, I could disable the Give feature while in CO-OP, but I really wouldn't want to do this - Sharing is a big part of the update, and it almost seems more important in multiplayer than in singleplayer.

That's where v7 is at. Hopefully that quells some of the concerns over whether or not v7 is getting released. ;)