cameroon

If you don't mind me asking, why is that? I have it on and don't recall having any problems with it. Ahh, never mind ;)

If I had to guess, I would think you maybe accidentally have the rotate axis mapped to zoom as well. It's easy to do if you are changing mappings. I ended up unmapping zoom from TrackIR because I found triggering zoom with a button press on my HOTAS was easier to be consistent with.

I can second Savage's recommendation of ASR_AI. Just recently played the Bootcamp campaign with ASR_AI on and it was fine and it doesn't seem to add a huge CPU penalty for the extra behavior. I also like VTS_Duckhunt, which increases the AI's infantry engagement ranges by modifying the vanilla weapon data so that the AI knows that it can be used at greater ranges (it doesn't actually change the range of the weapons, it just lets the AI know it can use it from further away). It's not an AI mod, but I thought it worth mentioning if you're looking for more challenge from the AI in the campaign missions.

Hi mindbl4ster; you might want to take a look at this set of scripts I wrote to make adding and removing objectives easier for scripters: https://dl.dropboxusercontent.com/u/8018430/cjb_alive_extensions.sqf Especially if you're trying to add an objective to only one side (you can't reference anything by editor names). To answer the question, the _id parameter is a string that should be unique per OPCOM object.

Just a heads up for anyone using my SQF script (https://dl.dropboxusercontent.com/u/8018430/cjb_alive_extensions.sqf) I made a small update to where units from deleted objectives will go. Essentially a bug fix so they don't head for unassigned objectives.

Yeah, mutexes would make synchronization a lot less likely to go boom ;) As would exception handling heh.

I think the source of the error is just that there are a lot of threads that access the objectives collections, and there's no good way to make sure they aren't operating on an objective that is no longer valid. If I deleted an objective right at the same time that an OPCOM started its analysis, I could see that blowing up too and then there'd be a dead OPCOM ;) I can think of a couple ways to avoid running into the problem, but it would probably be ranging far afield for the thread.

spitfirefrench, if you haven't already, I'd also suggest checking the Arma RPT file (it'll be in C:\Users\<yourusername>\AppData\Local\Arma 3\) and see if there are any errors being thrown (or run with -showscripterrors).

Well I got to the point of being able to add/delete objectives via the map, but all my testing from before was from the OPFOR side of things and that OPCOM did not have a Military Logistics synced to it. Turns out that Military Logistics doesn't like having objectives removed. I can't really debug it and I'm not sure if it breaks the synced Logistics module permanently, or just for that "run" of reinforcement check. Hopefully it's just for one run, which could delay reinforcing but at least it'd otherwise work but I haven't been able to confirm that. At least for the moment, I'd say if you plan on deleting objectives you shouldn't delete them from an OPCOM that has a Logistics module in effect.

I started toying with it this afternoon, at least as a proof-of-concept. Working out a method for deleting is the tricky part. I haven't tried using onMapSingleClick to delete markers and it's proving to be a bit trickier than I thought. I don't have any experience creating other UI type objects so wanted to go with something simpler just to see it in action, turns out it's still not-so-simple ;)

Sure, go ahead - hopefully we'll get some ambitious mission makers to make use of it! ;) Looks like the forums are being sluggish about PMs - nothing there yet, heh.

EDIT - Bug fixed. Pesky private vars. Ok, this code is way too big to put directly into a forum post. I've created a set of functions that seems to remove an objective without causing errors. https://dl.dropboxusercontent.com/u/8018430/cjb_alive_extensions.sqf I've renamed my functions a bit and there's a whole lot more that removeObjectiveFromSides does now as well. [ "objectiveName", ["WEST"], true] call cjb_ALiVE_removeObjectiveFromSides; The new param determines whether any enroute Profiles will be given waypoints to the nearest other objective that isn't being attacked (so they don't unintentionally join in an assault). The function defaults it to true, so you can still call it the original way (just with the new name) and any profiles will be redirected to whatever objective is nearest. So if you call that, any enroute profiles will be halted and redirected and then OPCOM will be told to remove the objective. This avoids the script error that was occurring and I've been able to add/remove/add/remove/etc an objective and have units sent to the objective whenever it's added (with the regular OPCOM analysis delay). Selection of units appears to follow the regular OPCOM rules, so as far as I can tell, this correctly returns profiles to OPCOM for use. It hasn't had really extensive testing, so there might be some bugs. Please forgive the audio - downside to the wireless headset I'm using I think. Also, I think YouTube is still processing the higher bit rates so right as I'm posting this it's only 360p. NOTE Just a heads up that it won't cause profiles that are currently engaging an enemy profile to flee that fight.

That's why I'm saying you probably have to do it manually, there's nothing prebuilt (at least nothing prebuilt that's documented) to do what you want to do. It might be possible to do with the pauseModule/unpauseModule commands, but you'd have to dig into it to figure out how. ---------- Post added at 14:59 ---------- Previous post was at 14:19 ---------- Trust me, I love the simplicity of being able to place down some markers, modules and sync lines and get a dynamic, living battlefield that I didn't have to script out - but I also want to be able to provide some additional direction to enhance the appearance of intelligence as to what the AI (OPCOM, in this case) is doing and to adapt to what the player(s) are doing. For instance, being able to remove objectives from a side if it's losing would allow the built-in ALiVE logic to naturally consolidate before it has no further units to send, giving it a stronger position. That core principle of simplicity is great and if I could use the editor to enable/disable objectives dynamically that would be AWESOME ;) For instance, if I could sync a trigger to a MCP/MIL/Custom objective and to an OPCOM, where the trigger state of TRUE enables the objective and trigger state of FALSE disables the objective for the sync'd OPCOM then it would be fantastic. I realize there are probably tons of things that are more important to the project so I'm not specifically making a feature request, but adding a [_opcom,"pauseObjective",boolean] to ALiVE_fnc_OPCOM (and attendant ignore/unignore when it's assigning tasks to profiles/TACOM) and removing "removeObjective" might make it easier on you guys since there'd be a lot less "stuff" to cleanup. I'd still want addObjective to exist of course ;) Some mechanism to discuss the API and how to use it would certainly be welcome. The Functions Viewer does seem to generally have good comments but there are also a lot of assumptions of backend knowledge, like the profileHandler docs provide a good list of what operations it supports but doesn't say that "external" users should use the global ALIVE_profileHandler (found that in some other functions).

So add and remove do work and an OPCOM will not send any additional forces, but any enroute will continue. That's not the worst possible scenario, compared to below, so I'm going to look at the problem below first. However, when I added the same objective back to any OPCOM (e.g. "Add OBJ1", "Remove OBJ1", "Add OBJ1"), it got stuck in some sort of loop with the OPCOM ordering TACOM to attack the target and TACOM not acknowledging anything. So maybe OPCOM was able to forget about the objective, but TACOM maybe not or possibly TACOM for that side "died" when the script errors for units that were enroute to a deleted objective. No idea about the TACOM yet. By the way, if you want to see the errors that occur when you do the delete, make sure you're running Arma with this command line or launch option added: -showscripterrors ---------- Post added at 13:15 ---------- Previous post was at 13:09 ---------- There is a "call" inside the ALiVE_fnc_OPCOM function named pause, but I don't know how you'd resume after calling that pause. So you could test it out with the functions I wrote above, but the call you'd be making would be [_opcom,"pause",true] call ALiVE_fnc_OPCOM. You'd be on your own for figuring out if it works and how to resume it though ;)

Hmm, any profiles enroute before the delete is done would keep going, I don't think the OPCOM reroutes units. I'll run another test that's more likely to confirm that it is forgotten, but I was outputting the objective list straight from the OPCOM's "brain". I haven't looked yet, but maybe there is a way to find out which profiles are already enroute and remove their waypoint, in which case we could make the remove smarter. Sent from my iPad using Tapatalk

To follow up on my own reply earlier about removeObjective, it does seem to work actually. The script error occurs for any profiles that are moving towards that objective when they reach their staging. So it does seem possible to remove objectives dynamically, but right now generates a script error. No idea if that causes further problems, but at least it provides some hope that we can script dynamic goals for the OPCOMs! :) ---------- Post added at 20:27 ---------- Previous post was at 20:24 ---------- These are the two functions I wrote for my objective testing, hopefully saves you the debugging I had to do ;) cjb_addObjectiveToSides = { private["_objectiveParams","_factions","_faction","_opcom","_opcomSide","_baseObjName"]; _objectiveParams = _this select 0; _factions = _this select 1; _baseObjName = _objectiveParams select 0; { _opcom = _x; { _faction = _x; _opcomSide = [_opcom,"side",""] call ALiVE_fnc_HashGet; _objectiveParams set[0, format["%1_%2",_baseObjName,_opcomSide]]; if( _opcomSide == _faction) then { [_opcom, "addObjective", _objectiveParams] call ALiVE_fnc_OPCOM; }; } forEach _factions; } forEach OPCOM_INSTANCES; }; cjb_removeObjectiveFromSides = { private["_objectiveID","_factions","_faction","_opcom","_opcomSide","_baseObjName"]; _baseObjName = _this select 0; _factions = _this select 1; { _opcom = _x; { _faction = _x; _opcomSide = [_opcom,"side",""] call ALiVE_fnc_HashGet; _objectiveID = format["%1_%2",_baseObjName,_opcomSide]; if( _opcomSide == _faction) then { [_opcom, "removeObjective", _objectiveID] call ALiVE_fnc_OPCOM; }; } forEach _factions; } forEach OPCOM_INSTANCES; }; You call them like so: [["hill214obj",getMarkerPos "hill214",_size,"MIL",_priority],["EAST"]] call cjb_addObjectiveToSides; ["hill214obj",["EAST"]] call cjb_removeObjectiveFromSides;

DeleteVehicle won't help you, the logic objects aren't monitored for changes - just existence at start. There is a "removeObjective" command available in the OPCOM function (at least according to the function viewer in the editor) that is, I'm sure, supposed to be the counterpart to "addObjective". I briefly messed around with using removeObjective, but it seemed to succeed and then later cause errors to accumulate in other parts of the mod. I didn't put a lot of time into figuring out why, but my guess is that there's lots of things that expect objectives to never be removed. In order to even try to use removeObjective though, I think you'll have to use addObjective and keep very close track of the objective IDs. For instance, the name of the game logic is irrelevant to the objectives that get created. From watching the debug logging as well as messing around with addObjective, it seems like each OPCOM should really get a unique identifier for any objectives assigned to it. I'm not 100% sure on that, certainly the debug markers expect that. I have a post a few pages back that shows a way to add objectives that's more selective than the one in the script snippets on the wiki and I think you'd have to do something similar in order to be able to try using removeObjective. EDIT I just re-confirmed, I can call removeObjective (the syntax is [_opcom, "removeObjective", _objectiveID] call ALiVE_fnc_OPCOM) and that doesn't generate errors, however each time through OPCOM's regular processing/update loop, errors are logged in the RPT file about a variable being undefined on line 794. The error seems to pretty much halt the OPCOM from doing anything else. If the function viewer is accurate for line numbers, then it's probably in this part of the processing. case "getobjectivebyid": { ASSERT_TRUE(typeName _args == "STRING",str _args); private ["_objective","_id"]; _id = _args; { if (([_x,"objectiveID"] call ALiVE_fnc_hashGet) == _id) exitwith {_objective = _x}; } foreach ([_logic, "objectives"] call ALIVE_fnc_HashGet); _result = _objective; };

I don't know nearly enough about the class inheritance system to say why CAManBase works but Man does not. To find the inheritance path though, in the config viewer, look at the Parents field - that should show you the classes you could use in your init event handler. For example, vanilla OPFOR units have a Parents field that includes SoldierEB, so I'm using SoldierEB to spawn some OPFOR units without NVGs.

Use CBA's extended init handler and in that init handler, add your killed handler to the unit(s). I used that same mechanism to add an event handler to all helicopters that let you tell AI that isn't part of your group to get out. In your description.ext, add a definition like: class Extended_Init_EventHandlers { class CAManBase { init = "_this call (compile preprocessFileLineNumbers 'add_killed_eventhandler.sqf')"; }; }; You'd want to set the class to be whichever base type of unit that you want to add your event handler to of course. Then in your SQF file (add_killed_eventhandler.sqf), you would do something like: _object = _this select 0; //code to add your event handler here I'm no expert on this, but hopefully that's enough to get you the rest of the way ;) Edit: One thing you may have to deal with is that units may come and go as players move in/out of spawn range. I don't know if that will trigger your Killed event handler or not, but you might have to account for that. ---------- Post added at 00:00 ---------- Previous post was at 23:58 ---------- So that's extremely frustrating, the board keeps just appending a reply to SavageCDN - which is unrelated. I love ALiVE to pieces, particularly for removing a lot of the grunt work out of providing an unpredictable, challenging backdrop to the players (particularly since I'm generally one of the players, heh) - so I was hoping to avoid having to place some manual-but-random unit compositions ;)

Is there any way currently to get ALiVE to spawn units in a TAOR where it doesn't detect any of the automatic objectives but where the mission designer has placed custom objectives? A huge swath of North West Altis is empty of things that are automatically detected by either MIL or CIV placement. I know custom bases aren't detected/supported, but I was hoping that placing custom objectives (using editor placed Location objects sync'd to OPCOM) would count just to let units spawn.

This is a rather old question, but I thought I'd pipe in with a function I wrote recently to do this. After all, military forces don't always have the same objectives and it took quite awhile to figure out what I needed to do. cjb_addObjectiveToSides = { private["_objectiveParams","_factions","_faction","_opcom","_opcomSide"]; _objectiveParams = _this select 0; _factions = _this select 1; { _opcom = _x; { _faction = _x; _opcomSide = [_opcom,"side",""] call ALiVE_fnc_HashGet; if( _opcomSide == _faction) then { [_opcom, "addObjective", _objectiveParams] call ALiVE_fnc_OPCOM; }; } forEach _factions; } forEach OPCOM_INSTANCES; }; The first parameter is an array that is passed straight to ALiVE_fnc_OPCOM - set it as you would when calling addObjective. The second argument is an array of strings for the factions that should get the objective (strings - just to emphasis that you must pass the string that ALiVE is expecting). Example: [ ["opforComRetake_obj", getMarkerPos "opforComRetake", 200,"MIL"], ["EAST"] ] call cjb_addObjectiveToSides; It's worth noting that the OPCOM may not immediately notice the new objective, and of course it's still prioritized so there might not be any units to send. ALSO NOTE! If you have a marker with the same name as the first argument ("opfoComRetake_obj"), ALIVE will kind-of-sort-of take it over. I recommend that you do not use a marker name as the objective name.

Think of any object that is profiled as a placeholder - they don't maintain any of the links, names, etc. that you would have assigned in the editor. If a specific unit matters because its named, part of a trigger, etc. then it must not be profiled.

As far as I know, if an object (like "bob") is profiled, then it won't be a named object anymore. Even if it starts off inside the spawned range. Since those types of objects should be relatively rare, I'd just make sure it isn't profiled.

You have to adjust the trigger condition manually - triggers don't check height. Something like the following in your condition block in the trigger this && ({ (getPosATL _x) select 2 >= 11 } count thislist) > 0 - Triggers pass the list of objects that would activate the trigger as an array in the variable thislist - You can count the elements of an array that satisfy some condition I can't test it out at the moment, but I think that should work.

First let me say, I love ALiVE - I always hated building missions where the rest of the "world" was dead and who has the time (or CPU) to generally have something actively going on everywhere? There's one thing I keep running up against that I wish I could add, and that's having multiple OPCOMs per side. For instance to be able to have OPCOMs that are responsible for different areas, different pools of troops or different objectives (occupy vs. invade for instance). One not-so-great example could be having Altis split with OPFOR on the sides and BLUFOR in the middle. I might want to essentially have the eastern OPFOR and western OPFOR operating independently of each other. One-OPCOM-per-side seems to be a very basic foundation of ALiVE (I skimmed ALiVE_fnc_OPCOM), so am I missing another way to do something like that? Thanks again ALiVE team, it's an amazing piece of work!