There are two bugs in CompileUnitTables(). Both "elseif arg[1] == 1 " statements should tested against 2 not 1. You also don't need the unitteam property because all classes in unittablemaster1 are going to have a unitteam of 1 and a value of 2 for unittablemaster 2 (but that's not a bug).

You can add more unit classes anytime the game is running, but there's no way to remove them. So once you've hit the limit you shouldn't add any more. The 'spawn as locals' script added the local units to the main teams so I'd say you can't force someone into a class not on their team (if you could then I would have when making that script).

It would have been trivial for the uf_classes table to contain each classes team information. I missed a feature there.

If you change weapon properties through Lua the map will crash online, so in your addme.lua don't add your map to the mp mission list. Reloading with different unit classes will probably work online so long as every possible class is loaded every time. You wouldn't have to add every loaded class. Only the server would add classes to teams. Clients could be forced spawned with the proper classes, but no one will be able to manually select a class. To get around that, the server should create a specific object that represents a specific class layout. Clients should watch for the existence of the object then configure their teams accordingly. Based off my 'spawn as locals' experience, I believe that'll work well for MP.

Ah, okay, thanks for that heads up. For now I'll use a mix of classes and setting properties so that there won't be an absurd amount of classes while still staying MP compatible. It took my 140 classes down to 37.

I hope you're using tables and not super long if/elseif statements. If not, start another topic and I or someone else will convert a portion of your code to be table based and you can do a similar thing to the rest of your code.

[RDH]Zerted wrote:If you change weapon properties through Lua the map will crash online...

That's not (entirely?) true. Changing weapons with SetClassProperty can be done in ScriptInit without any errors. Provided you're not expecting to dynamically change class mid-game (i.e. you're saving "advancement" data), you can configure a unique class for each player (pre-load) and restrict the spawn based on username (although that might assume you're going to run this entirely online - I'm not sure if you can pull username outside of multiplayer).

[RDH]Zerted wrote:I hope you're using tables and not super long if/elseif statements. If not, start another topic and I or someone else will convert a portion of your code to be table based and you can do a similar thing to the rest of your code.

Heh...you got me! After I start working on the super long if/elseif statements, I'll definitely make a topic so I can learn more about tables.

EDIT: I don't know why I didn't think of this before, but you can use unit classes from other teams if you simply change the team of the character using SelectCharacterTeam. I don't know why I didn't think of this before but it will certainly help my endeavors greatly.

Well, there are limitations. You cannot use SelectCharacterTeam to change a human player to anything other than team 1 or 2 (causes a crash, I believe). But yes, you can take a human on team 1, spawn them as a team 2 unit class, and then change them back to team 1. You will want to use both SelectCharacterTeam(player) to change the character's team as well as SetObjectTeam(GetCharacterUnit(player)) to change the character unit (object)'s team. If you change just the character team, then the unit will still fight on the team that the unit class belongs to.