mad_cheese

They did help me calm down the more compulsive ticks of helicopter pilots. As with everything in the editor, I may have been attributing it to this while actually something else did the trick.

Take it with a grain of salt as I can not test this, but from my struggle with HC I remember that this setup is not MP compatible. BIS HC is not very flexible and has to be created in the mission setup.

What happened to _unit disableAI "THREAT_PATH"; _unit disableAI "PATHPLAN"; These are not recognized on DEV branch and produce script errors. While on the subject of disableAI, I can not resist to just randomly plug a little request: Something like: _unit disableAI "GETOUT"/"DISMOUNT" or similar... OR: _unit allowGetOut false; would make me smile.

Hi there, I feel a bit bad to ask this: would you consider using a stacked eventhandler for your onMapSingleClick commands? It's so easy for the reular ones to get broken and honestly speaking, my addon C2 is one of those things that mess it up. I am forced to block the default engine level mapclicks sometimes and that can break your onmapSingleClicks. I completely understand if this is not a priority. I fixed the other bugs between the addon and mission, there's ways I can work around this one too but a stacked EH would also generally protect your mission so I thought I'd ask :)

Thank you @Riksen! @Skanda, the default HC module that you have in Arma. This is what causes things to seem buggy. I am not sure that this is the situation you are having, but I find that sometimes things can look sort of buggy with that and I have not really tried it in a while. Other than that, the only issue with HC that I am aware of is that Suppression and Ambush actions are not bulletproof yet when using AIC, I still need to fix that.

That does not do the trick unfortunately. So far I assume the AI leaser sort of does what the player leader would do... I don't understand why doFSM will snap them back into stop state instead of executing the fsm.

If you order a subordinate unit to 'Stop' (x-1-6) and want to use doMove in a script afterwards, you need to use moveTo as well. You can freely move the units around by scripting, but they will always return: currentCommand _unit == "STOP" Until the player manually orders them to move or fall back into formation. This is news to me...Has something changed since 1.76.143187? I was damn sure that the combination of doMove and moveTo was switching the unit's currentcommand to "MOVE" before, even over a 'engine level stop' . But I may be wrong. We tried everything to snap the unit out of the STOP-state. DoMove/moveTo works with units that were scripted to stop with doStop/commandStop, those units will return 'MOVE' as their currentcommand. But player given stop-orders with (X-1-6) can not be overwritten by script commands. This seems odd given that you can change player given movement orders with doMove easily for example. Units in a player ordered "STOP" state will also not execute anything with doFSM. Can someone confirm this is new? Maybe I just did not see it before or I am generally not understanding things .

well i'll be damned, this actually works: params ["_unit"]; private ["_gP","_leader"]; _gp = createGroup (side player); _leader = _gP createUnit [(typeOf player), [0,0,0], [], 0, "FORM"]; _leader hideObjectGlobal true; [_unit] joinSilent _gp; [_unit] joinSilent (group player); deleteVehicle _leader; deleteGroup _gp; joining the unit to another AI leader is a temp fix, but it would be really cool to have it 'back' ;) doFSM will still not work though, the unit will go back to STOP state and not execute the FSM.

Hi Skanda, I can not cater to everybody's personal tastes as much as I would like to. Sticking to mine has proven to be efficient and if the data overwhelmingly suggest something, like map planning over tablet, I got for it. That's why I included the off toggle option. I am not sure what issues you are encountering with the HC stuff but it sounds to me like you are synced to a A3HC module, which is the least effective way to use C2 with HC. I can remove it if it's confusing, I see the room for error. I mentioned it in some video but of course I do not expect everyone to watch them and things change a lot. Anyways, for HC I recommend either no module at all, simply disbanding and rejoining units from and to your squad, or AIC if you want to command everybody. I had the approach to do modular but it is ineffective and unnecessary. You can disable the keybinds if you personally really deem a feature unnecessary.

Sorry, you are absolutely correct. I picked that up somewhere and got accurate results, but they were actually misleading and _vehicle land "_pad" does really have no effect. Since my experiments were succesful I was mislead, but what really made it work is spawning a helipad at the desired location, moving the chopper there and telling it to land. Usually of course the spawned helipad is the closest, which lead me to belive that _vehicle land "_pad" was working even tho the syntax seemed odd.

You can use _heli land landingType; If you want to just land the chopper in the proximity. But you can also spawn a pad and tell the chopper to land at it. The engine will remain on and I find the chopper's behaviour on the ground a bit impulsive, but it works. _pad = "Land_HelipadEmpty_F" createvehicle _landingpos; _heli land _pad; Sometimes around airfields and bases, the unit will still land at a real helipad in the proximity. Not at all a fact but I assumed landAt was only for jets and airfield Id's.

I am glad I am not the only one :) I have only experimented with player led units that are local to the player. The issue is present in the editor as well unfortunately :( I posted it on the feedback tracker: https://feedback.bistudio.com/T126933

And some more stuff: Infantry waypoints can now be synced with 'Pickup'-Waypoints, making the assigning the units as cargo and boarding them to the vehicle. Tanks will now face the direction you assign! Also, the Jet landing- parking- and takeoff routine has been added to the HC/Reserve functionality. The addon will park the vehicles in front of unoccupied hangars. Next patch coming soon, Beta as always available on Discord!

oh.. YES!!!! Thanks for the hard work on this!

@CoA|Saint @Leopard20 I was unsuccesful in making a ESC-menu dialog for C2. This is the only way I could get a setup where restarting the mission will be enough. Most missions get broken via some kind of group related stuff. Some of it I can address when the time is there. Here's some new WIP footage of some new features! There's some real nice stuff heading towards main branch :) C2 Formation Manager: (video by @reggaeman007jah) Sling Load Implementation:

@Rockapes you can get the beta on discord!

Here's another WIP report: The HUD-MENU-UI has developed a bit and has received the first layout of the new, rotating FORMSECTOR ICON, better visualizing the combination of FORMATION and SECTOR. This icon is the first icon byour brandnew 'UI-GUY" - @[VW]Wrath The squadlevel waypoint-manager has received a complete restauration. The sloppy data was combined into sub-blocks, enabling sets of waypoint-conditions and more importantly "WAYPOINT ACTIONS". As a first experiment, I dove into a long lasting dream of mine and added the REARM-WP-ACTION. This essentially enables you to chose specific items from crates. If the unit has no plans with a wp-action that has a defined crate and items, the unit will break from his plans and go to the crate. But if has the action with an assigned crate, it will add to the plan. In a nutshell this means: You can browse and choose individual items from different crates, the unit will move from crate to crate, picking up all the items. Only for individual units, group selections will go for the general 're-arm' without specific items. BETA AVAILABLE ON DISCORD!

Hey @Rockapes I can not say this with certainty as I have not tried the missions you refer to. General rule of thumb: If something happen only within a certain mission, then the mission is using scripts that prevent C2 from working properly. Unfortunately that's the way it is, mission makers and modders both use the same pot of commands and if the mission does something unexpected, the addon will have problems. For example, I sometimes play Dynamic Recon Ops and Dynamic Combat Ops. DRO is perfectly fine, but DCO has some weird stuff going on that creates a bunch of problems that I only experience in that mission. WLA was another mission I tested that had scripting mess with C2, even deleting all keybinds. I can not help this problem. I am not referring to the authors of the missions we mentioned, but I need to say that 90% of workshop missions are very poorly written, especially SP. That's not a diss, it's more about the format - most people would not invest the hundreds of hours into a mission that you play once (You mostly start a mission and 'count allunits' returns 140+., 5km south from the action, there's a herd of sheep. 3km west there's a whole platoon of AI occupying the base that was seen in the intro script. That kinda stuff). So what I'm saying is: Sometimes I can fix these problems, others times not. If a script tells your unit to do something or puts the units in states that prevent scriptcommands from being effective, there's nothing I can do :s

I just realized what a nerd I really am, coz this made me laugh out loud for real.. Ohhh these guys. Aren't they adorable. This is really a mean example lol I personally treat AI like a dog. Awesome? Check. Get the paper? Maybe.

I don't know of any issues myself. What you experience, the only thing I can imagine is that something slows down the overall performance causing my interfaces to get a bit laggy. I personally only had thtis kind of experience with hopelessly overloaded missions. The units saying 'negative' points to something not working, 'ready' is what they say when they arrive somewhereCan not be 'prevented', only switched off entirely.

@reggaeman007jah @u-104 thanks guys! the discord is like rocket fuel :D

thx! that's fine really, if you feel a threshold is reached shoot me a line of credit and that's it! The function you are speaking of is itself based on KillzoneKid's work just so you know.

Here's a little WIP update. The HUD UI, in latest DEV-build, becomes controllable by using a hotkey when units are selected (Current Default: SHIFT - will probably change). HUD and PLANNING modes, are fully interactive in the Beta. HUD mode has new access to Travel / Destination Stances, Speed and GoCodes. It also has the option to override or add to existing pans. Together, HUD ad PLANNING mode, alongside the STANDBY function, give you the full flexibility I was hoping for. Radial menu unit selection is also changing. LMB on a unit selector will select it for the A3 world and the Radial. RMB will select them for HUD mode. SHIFT + RMB will open up the context menu, which currently only carriest the option to change the teamColor but could include many other options, now that we get closer to looking at some kind of 'unit interaction'. You can join us on Discord to get access to newest Beta and discuss your ideas. https://discord.gg/cuW9fJC If you want to keep track of how C2 is growing, you can peep our PATREON, it's pretty much a blog.

Before taking this to the feedback tracker I figured I'd consult the oracle. Is it possible to return the codeblock that was set through onMapSingleClick? My concrete problem is that I need to temporarily disable the default mapclick functions for _shift and _alt, the good old issue. In my case it's for an addon - it would be cool if I could disable the _shift and _alt control layers, but only while a map overlay is open. I can not disable the engine level mapclick functions via my own added UI-eventhandlers. _mouseHandler = (findDisplay 12) displayAddEventHandler [ "MouseButtonDown", { if (_this select 4) then {true} else {false}; } ]; The above will not work. I'm not sure if this is related but generally I find that you can override engine functions by returning TRUE in the end of your codeblock ONLY FOR KEYBINDS. not for mousebinds. The only working thing is: onMapSingleClick {if (_shift) then {true}}; But this is not a feasible solution for an addon it seems, since it will override anything a mission designer had in mind for this command. There can only ever be one onMapSingleClick. I found a script that is called 'multiple onmapsingleclicks' but it's just a management script that still creates one onMapSingleClick command and a script that manages the rest on it's own behalf. Does anyone know a way to return the code that is currently assigned to onMapSingleClick? This way I could just add to the code, but I do not think it's possible... If that does not exist, I think I should write a feature request for either this or custom mousebinds being unable to prevent default engine functions of those binds. Thank you!

sorry to bump this thread. I have made an error with my original question, apologies for that. The real issue is this: I have a map overlay, while this is open I would like to disable the engine level mapclick commands, if the overlay is not open I would like them to work as normal. This is the only thing I can get to work //-- after overlay is opened onMapSingleClick {true}; //-- after overlay is closed onMapSingleClick {}; It works well of course, but there is only the one onMapSingleClick EH and since I am using this for an addon, I am worried to break missions. I can not use the new stackable option because I need to prevent the engine commands, and I suspect that a lot of mission designers will not use that option so I could end up breaking a crucial mission function. In rare cases admittedly, but it could happen. Using the method described above by @pierremgi , I am able to execute code, but returning 'true' does not have the effects I desire as was also mentioned. The shift waypoint can still be set, but more importantly for my case the player character will issue a movement order on every mapclick if he is commanding an AI-driven vehicle. I can not avoid that bevahiour other than with onmapSingleClick. I tried this to see if I could get a hint somewhere, but no dice... disableserialization; { _display = _x; _allCtrls = []; { _ctrl = ((str _x) splitString "Control#"); { if (_x == "Control#") then { _ctrl = _ctrl - [_x]; }; } foreach _ctrl; _ctrl = _ctrl joinString ""; _ctrl = parseNumber _ctrl; if (_ctrl > 0) then { { (_display displayCtrl _ctrl) ctrlSetEventHandler [_x,(format ["systemchat 'control %1'; true",_ctrl])]; //~~ rumour: if EH returns number, default will be overriden. Could not confirm } foreach ["MouseButtonClick","MouseButtonDown","OnMouseButtonDown"]; }; _allCtrls pushback _ctrl; } foreach (allControls _display); } foreach (allDisplays); { _display = _x; { _display displaySetEventHandler [_x,(format ["player commandchat 'control %1'; true",_display])]; } foreach ["MouseButtonClick","MouseButtonDown"]; } foreach (allDisplays); I do get the chat messages, but the engine events are still firing. Who knows, maybe this gives someone an idea :D