Spooner

Thanks very much for this. I've ticketed this at DH and we will look into it ASAP. Sorry, I thought anyone would be able to report tickets, but I've made you a reporter for the project so you'll be able to make future reports without any problems.

I wouldn't recommend putting any community addons, even ours, in your main addons directory.

CBA v0.1.2 Key Changes * FIXED: ALICE and SILVIE stop working when CBA is active * FIXED: Support for the "AnimStateChanged" event needed. * ADDED: JIP-persistent markers (CBA_fnc_setMarkerPersistent, CBA_fnc_getMarkerPersistent). * ADDED: Persistent player actions (CBA_fnc_addPlayerAction, CBA_fnc_removePlayerAction). Full documentation is available at DevHeaven. Download The addons, manual, functions reference and complete sources are included in the release. * DevHeaven

Do not name HC modules yourself. They are automatically named by the system, so unless you are telepathic, it is possible that you could give them incorrect or misleading names (BIS_HC_ prefix implies that a name has been given by the HC module itself, not that that is what you should force it to be named). In this case, it makes more sense to only have one subordinate module (multiple subordinate modules are used to group together sub-groups. You only have the 3 subgroups, so no need to group them). Thus, you should really just have one SL synced with one Commander module synched with a single Subordinate module synched to 3 fire teams. You might find my example clears up how to make a complex hierarchy, though for your simple hierarchy the example on the HC docs page might be plenty. Regarding trying to get an FTL to get into a vehicle, just wait until the HC module is fixed to allow this.

No problem. Easily resolved. Just glad people are actually bothered enough to make reports ;) We probably need to edit the original post to make it clear there has been a hotfix anyway.

This was actually a known issue with CBA v0.1.0 (sorry!), but we believe we fixed it with CBA v0.1.1. I'm pretty sure that the NVG addon wouldn't cause any significant slowdowns on its own. If you can confirm that CBA v0.1.1 causes this problem (if you can, please check if CBA on its own causes this slowdown), we can take a look at it properly. Thanks for your feedback!

Yes, key event handlers should always return true/false. The real problem with this report is it is a bit vague and doesn't refer to the handler that returned the bad value (as it couldn't). Personally, I dislike making it idiot-proof (where ANYTHING except "true" is counted as a false result) because that just hides the truth and still allows you to pass the wrong value by accident (that is, you have a variable that is 5, when you wanted it to be true. By complaining that the handler MUST return true/false, it catches this problem. Assuming 5 is "false" hides an error from the user and since I think a lot of the woes in SQF are caused by BIS ignoring errors rather than dealing with them in a rigorous way, I want to keep this as it is. The warning should be made a lot clearer though... Regarding action-key support, I did have it in SPON, but not in the released version. CBA is getting a lot of the unfinished stuff that was in SPON Core but I lost enthusiasm A1 a lot in the last year. Some sort of merge might make sense, as this work is already partially done.

Save games have nothing to do with SP any more :P Although this addon uses an inefficient workaround to deal with the issue, it should work fine with SP or MP saves. Unfortunately, there isn't really a better way to deal with this at present... We are looking at adding a simple framework to manage this in CBA. Even if this just means that we get to inefficient once on behalf of all CBA-dependent addons :D

We only released the new version in the last couple of hours. They probably haven't updated yet.

PreInit and PostInit are only run once. You are quite correct and thus you don't need the usual global-variable test to stop it happening more than once. The former is run before any objects are created, the latter after they are created. In your case, you might as well use PreInit unless you need the player object for something. The syntax for the once-only handlers is a bit different though (not associated with an object class): class Extended_PreInit_EventHandlers { S_NVG = "[] execVM '\S_NVG\init.sqf'"; }; CBA has just been hot-fixed, by the way, since the first release was a little bit borked. Sorry, I realise you were probably waiting to release until you had an official XEH to use, but anyway, everything is fine now (fingers crossed!). @Zipper: The FR should work with the new version of CBA... Sorry, that was our fault, not sholio's!

@Robalo_AS, I've ticketed this at DH and hope to get the fix out ASAP.

I assumed low, medium, high, very high refered to none, 2x, 3x and 4x AA and thus were lower than the 5x, 6x, 7x, 8x options. Your card may not support all the options, but I guess it defaults to the next lowest setting if it doesn't. Essentially, each 'x' means the screen is drawn that many times bigger before resizing to be viewed (well, this isn't literally what is going on, but good enough for a simple explanation). So, for 4xAA on a 800x600 screen will be rendered at 1600x1200 and then resized to 800x600 before the user sees it. I did indeed see that MSAA was many times faster than the equivalent fill-rate. That is, 4xMSAA is vastly faster for me than 200% fill-rate (I think because graphics cards are optimised for hardware AA, but not for fill-rate, which must be done in software).

Sorry guys, but I don't plan to support SPON Money much longer and definitely see no personal or community benefit from porting it to A2, since the Warfare commerce system is perfectly good (although it still needs properly documenting and fixing, but that isn't my job ;)). Got plenty of other things to keep me busy.

Rather than continually adding and removing the actions, it would be simpler to use the A2 action condition (same as the A1 action condition, but it can be applied in scripts as well as in config). I'd also prevent people outside the vehicle opening and closing the doors, but that is my choice. Either open or close action, as appropriate, available for anyone in the vehicle: _vcl addAction ["Open C-130 doors", "C130_openDoor\openDoor.sqf", "", 0, false, true, "(not (_target getVariable 'NORRN_openDoor')) and (_this in _target)"]; _vcl addAction ["Close C-130 doors", "C130_openDoor\closeDoor.sqf","", 0, false, true, "(_target getVariable 'NORRN_openDoor') and (_this in _target)"]; Thus the whole init file can be about 8 lines.

Yes, absolutely! Multi-levels make a lot more sense when all commanders are players. However, there is no reason that complex fsms could not be written to manage multiple-levels of command, but really, the effort would be enormous if the sub-commanders are to act as you would like them to. You are actually asking for more intelligence in HC sub-commanders than I've seen within single AI groups that aren't part of a structure. No surprises that they aren't perfect yet...