Hi everyone. I recently made a significant change to my Assassination Mode code... each class of enemies (5 total) is handled by a separate team. So I now have 8 teams in total:
-ATT (the player)
-DEF (the basic guards that run around all the time)
-TAR (the targets)
-CIV (the civilians)
-DFB (the level 2 enemies)
-DFC (the level 3 enemies)
-DFD (the level 4 enemies)
-DFE (the level 5 enemies)

Since making this change, the map crashes to desktop while loading. Here is my error log - as you can see there are only Sev-2 errors:
And here is the JERc_con.lua... if you have any questions about the AssassinMode stuff in ScriptPostLoad please let me know: I did make a number of corresponding changes to the AssassinMode.lua as well, but those changes only involved changing things like this: ...to this:

Um... there IS a severity 3 error in the error log you posted, lol

Message Severity: 3
.\Source\LuaCallbacks_Mission.cpp(866)
Lua ReadDataFile: Could not open ..\..\addon\BDT\data\_LVL_PC\dtshell.lvl
prev = none iLastPage = nil
prev = texture iLastPage = 1
prev = texture iLastPage = 2
prev = texture iLastPage = 3
ifs_legal.Exit

Alright fine, but it's from the Dark Times mod, which I've had installed for about 7 months, and has never affected anything before.

Edit: My point is that I find it really hard to believe that a DT specific shell error is causing a crash on my non-DT-related mod only after I add a few extra teams. And I've had that particular error in all of my BFront2 logs as long as I can remember.

Oh okay well if that's not new... then here are some other ideas:
Your local teams have ridiculously high unit counts, why? The target class, in particular, has 200 bots for no apparent reason?? 5 would suffice, wouldn't it? I don't know if having 1+10+200+164+4+4+4+4 = 391 bots would be problematic, but it can't hurt to cut down on that. Other than that... are you using custom CIS units? Because I didn't notice any changes from stock -- though any missing custom side would leave error messages, I think. Also, you don't define the status between teams -- you should set team 1 as enemies to 5, 6, 7, 8, etc. Other than that, I don't see any issues -- but it is possible that there could be something in the AssassinMode file, could you post that lua file as well?

The team size of the first local team determines the cap for all local teams... Sounds weird I know but essentially if I set the target team unit count to 7 I would get 5 targets and 2 civilians. So that's why my target team size is just a bit bigger than the total units of all my local teams combined.
The teams' diplomacy settings are all handled in AssassinMode.Lua, which I can post tonight when I get home from work. I am using custom SBDs that have only wrist blasters. Nothing new there, that's been around since my second or third munge.

jedimoose32 wrote:The team size of the first local team determines the cap for all local teams...

You have actually observed this? Because that makes no sense to me, I have never heard of a thing like that before, have no idea why the game would distinguish local teams from the main 2 in that regard, and I had previously (in my first version of Gun Game Mode) setup multiple local teams, defining each in the LUA to have 20 units, and had never observed any strange spawning issues.

I have observed and tested it as empirically as I possibly can. And yes the game does distinguish between local teams and the main 2 teams.

Edit: AssassinMode.lua - Do not distribute this code without my express permission please.

Edit 2: I solved the crash by undoing my team changes, and putting all the difficult guards back on one team. Now what I've set up is a system that will assign those guards' classes to a certain range of GetTeamMember values (e.g. rocketeer to members 0 - 3, sniper to members 4 - 7, etc) and keeps track of which range is allocated to which kind of unit. It's roughly the same number of lines of code as the multiple team method, maybe slightly longer. And it seems to work very well!
And it doesn't crash the game.

or would be faster and shorter.

Also keep in mind concatenating two things using ".." will crash the game if one of them is nil. Passing each field as an argument to print() is much safer. Look up variable length arguments if you don't know how to use "..." and "arg" (or is it "args").

You need to go back before the latest changes and slowly add them in one at a time or slowly remove each change from the current code. For code as extensive as yours, you are using version control (bazaar, git, svn) or at least making regular and multiple backup copies right? If not, immediately start doing that. If you don't know what I'm talking about, I'd recommend using Bazaar (sometimes called bzr) as it has nicer documentation than git.

One thing I tried when creating a Deathmatch mode was putting each character on it's own team. I noticed weird things like team number 11 would crash but 99 would work (not the actual numbers, but something like that)... With 9 teams you might have a similar problem. Don't forget about team 0.

I've never heard of that local team size limitation. Someone else needs to verify if it's true and if so it should be added to the SWBF2 limits topic.

[RDH]Zerted wrote:For code as extensive as yours, you are using version control (bazaar, git, svn) or at least making regular and multiple backup copies right? If not, immediately start doing that.

I hadn't until yesterday when I realized that it's a major pain in the butt to revert this kind of change... so yeah I'm now making local backups but I like your idea of using bazaar or git (never heard of bazaar, I'll look into it right away).

And, regarding the local teams issue... I would love it if someone else can try and verify this limitation. It doesn't really make logical sense to me at all. I discussed it briefly with ZoomV in THIS thread but I don't think we ever "proved" it.