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