SWBFII Skin Randomizer Script

[SleepKiller]

Someone flicked me a question about a skin randomizer they had found for SWBFII and how it could be expanded to support more than two skins. Having just gotten back from being away from home for a couple weeks I've taken the time to look through what they sent me and quickly make a skin randomizer that should do what they want.

After a player (or ai) spawns in as a class a new skin is randomly picked for that class for the next time that class spawns. Usage can look as simple as this.

Code (lua) Select Expand

EnableRandomizedSkins{
   cis_inf_sbdroid = {
      {
         { property = "GeometryName", skin = "name of a model" },
         { property = "GeometryLowRes", skin = "name of a low res model" }
      },
   },

   rep_inf_trooper = {
      { property = "OverrideTexture", skin = "name of a texture" },
   },
}

You can find the script over here. It is documented with usage instructions and detailed comments on how the code works. However it is completely untested (hence why this isn't in Release Assets), however it should work but even if it doesn't it should still serve as a fine starting point for anyone looking to implement something like this.

[Teancum]

I took a quick look at it, but I'm curious what localizes it to one instance of a class, versus all the classes. Is it this?

Code (lua) Select Expand

CreateSpawnCallback = function (skins)
   -- Create the closure that we'll return as the event callback. This
   -- captures the function argument `skins` as an upvalue.
    local callback = function (player)
I'm not really all that savvy with lua ironically, but I'm assuming the callback is what gets that specific player/npc, regardless of using SetClassProperty()

[SleepKiller]

Well this is embarrassing, the event callback was supposed to be capturing the name of the class to set the properties of. I refactored this a couple times while settling on a design so that'll be how I missed it. Still that is a pretty big flaw to miss.

I've updated a the gist with a fix and you can see the difference here. Thanks for making me catch that, I prefer to not leave horribly broken code floating around.

Anyway yes it updates classes, not instances of a class. This is because my understanding there are certain properties (GeometryName) that can only be updated at respawn. This also does mean that you're limited to using properties that only update with respawn. Perhaps I should've clarified this aspect of the design in the documentation.

Although it could be extended quite easily to also support properties that don't need a respawn to update. If you (or anyone else) is interested in that just let me know.

[Teancum]

... This is because my understanding there are certain properties (GeometryName) that can only be updated at respawn. This also does mean that you're limited to using properties that only update with respawn. Perhaps I should've clarified this aspect of the design in the documentation.

Ah, that makes sense. I was sitting here thinking it might change a live unit.