Hellfire

I just removed it and that's solved but I have lots more for FARP. "Scattered" formation throws errors so I'm forced to use "chevron". I have not tested others fully. For me everything should be scattered as anything else is just a single pass cluster target. Blue aggressors take the FARP without a fight with the redDefenders. You mention/require (fails at 1500 I tried) that the FARP zone be 2K radius to match capture zone but DCS FARP capture zone is more like 6700. ??? Something I noticed in the process of hashing the zone radius and the cfxmon issue is the redDefense force would not change to blueDefense if blue aggressors were already in DCS FARP capture zone. Lame bitch you say? Could happen in a persistent fight. Just saying. Fixing below issue I suppose fixes this issue. The .miz file you already have, if you still have it will demo the blue aggressor inside the capture zone. I put them there based on your 2K requirements then noticed later what was actually going on. I have since pushed them beyond the DCS FARP capture zone and run them in and still no fight but the redDefenders do change to blueDefenders. Wait everything about the capture issue's is not entirely correct. What's going on is the troops that are spawned are neutral(white) units, before and after capture. The actual troops are changing from the red type's I had selected to the blue types but their always white which explains the easy capture. Did I miss a setting somewhere? This issue does lend itself to another question I had as I was originally setting this test up. How do I start the FARP as neutral? I was thinking this is not a possibility in DCS but clearly that's wrong. A request to go along with all the other trouble I'm causing. When I'm flying, I am generally task saturated and I know I'm not alone here. Most messages that pop at the top right need a sound to go along with them and FARP being captured needs a ding or a dong or a ding dong ding dong. Thats a request for you and every other mission maker that happens by here. The body of work (or should I call it fun?) you have created here is impressive. Hat off and bow. DML-TEST.miz

Just messing around with the FARP module to see how it works and what happens when FARP is attacked. It's throwing errors as the aggressor's approach. See attached. DML-TEST.miz Hey Badass, what other persistence module are you using?

Also looking at Persistence. EXCELLENT! writeup on all that is persistence. Question regarding persistence. I use some of the other collections like MIST and MOOSE and now looks like DML and I was wondering if there would be issue with objects created by MIST or MOOSE?

There are dead links in this pdf, can anyone update this or supply the missing files?

Waiting for the fuzzy dice mod.

Maybe fiddle with the hard point power switches next time. I've had similar issues with other systems, I change planes.

https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/index.html https://forum.dcs.world/search/?q=gci&quick=1&type=forums_topic&nodes=79 That should keep you busy.

Is it possible to save the SaveUnits.lua to Save Game folder instead of main DCS folder?

GitHub - lukrop/GCICAP: Autonomous GCI and CAP script for DCS: World. I'm using GCICAP.lua in what used to be a working mission until DCS's latest updates. I suspect it's the changes to the airbase names in NTTR. I had to load MOOSE update and modify some code to fix issues with it but MIST based GCICAP is also kicking error. ERROR SCRIPTING: MIST|doScheduledFunctions|1286: Error in scheduled function: [string "C:\Users\Gamer\AppData\Local\Temp\DCS\/~mis0000535D.lua"]:1453: attempt to index local 'airbase' (a nil value) That error points at line 1453 in GCICAP local airbase_pos = airbase:getPoint() Have there been any updates to mist to address this or am I barking up the wrong tree? I did update mission to mist_4_5_106.

Can you be more specific on what you did to repair? Mission I created CA works in single player but no vehicle access in multi.

Callsign comes from Microprose Gunship. Pieces of passwords go back to that also. Seems like they would just do an A variant then bring the Bow later.

Mission could have a bump in it so be sure to try something diff to test.

Weird. I just had a flashback to Falcon4.

Is there anyway to refresh the MIST database? Not sure thats even a relevant question though, see below. I'm using both MOOSE and MIST in a campaign I'm working on and I have sets of tanks that are spawning using MOOSE and some times units will get stuck together and then the whole group will not move as these units spin around each other. I devised a fix for this using MIST teleport and then MIST groupToPoint : local vars = {} vars.gpName = 'Nellis2Mesquite Blue Tanks 1#001' vars.action = 'teleport' vars.point = mist.getLeadPos('Nellis2Mesquite Blue Tanks 1#001') vars.radius = 25 vars.disperse = 'disp' vars.maxDisp = 100 mist.teleportToPoint(vars) mist.groupToPoint( "Nellis2Mesquite Blue Tanks 1#001", "Mesquite Defense Zone", "On Road", 360, 50, 0 ) Works nicely to separate the stuck units and restart them on their path. Works nicely once the campaign has been restarted that is. What I mean by that is I'm using Simple Group Saving by Pikey to continue the campaign and the code above works nicely on units that are alive before restart. Where I run into problems is on units that are recently spawned and then I get an error with the code above "Nellis2Mesquite Blue Tanks 1#001 not found in MIST database" pointing specifically at the mist.teleportToPoint line. Thing is mist.groupToPoint has no problems if I run it alone or before the teleport but obviously that's not going to work.

1. figured out. local redtank = Group.getByName( 'REDTANK' ) Group.getByName('REDTANK'):activate() 3. figured out. Group.getByName('REDTANK'):destroy() 2. ??? elusive. local redtank = Group.getByName( 'REDTANK' ) Group.getByName('REDTANK'):activate() --Group.getByName('REDTANK'):destroy() --if Group.getByName('REDTANK'):isActive() == true then if Group.getByName('REDTANK'):isExist() == true then trigger.action.outText("YES REDTANK", 420) else trigger.action.outText("NO REDTANK", 420) end If I use isExist I always get YES REDTANK no matter if I destroy() or not. If I use isActive I get group is nil no matter if I destroy() or not.

Can someone help me with a couple of lines of LUA code? I had hoped that a solution to this seemingly simple problem would avail itself but alas to no avail over the course of this project. Now at the end I still have no working solution for: 1. Spawn late activate object (REDTANK). 2. Check if object exists in an 'if then". 3. Despawn object only to be possibly respawned later. I need help with some lua scripting to achieve above. I already have 1 in the form of: Spawn_Vehicle_1 = SPAWN:New( "REDTANK" ) Spawn_Group_1 = Spawn_Vehicle_1:Spawn() but it seems like there should be an easier line of code to do this. I don't have 2 at all and I have 3 but I can't get it to work. I've tried various iterations of the below. local dest = GROUP:FindByName("REDTANK"):destroy() local myObj = GROUP:FindByName("REDTANK") myObj:destroy() To be clear on my objectives I want this to be a "switch" that can be turned on and off and is spawned out of the way and does not need to be seen by players. It will be saved by a persistent save script for campaign restarts.

I have a second screen, touch screen actually and before I fly I have a "flight pack" pdf's pics etc that get loaded to that screen and also the screen shot folder is there so I just screen shot and open later in an altitude hold pattern. Used my iphone for screen pics also in the past. All of you probably have some old junky monitor laying around just get you a wall or desk mount and see your SA rise.

I found it. The check box "apply enable/disable windows axes state" in CCP needed to be checked.

yes I have always turned off emulation I was wondering if maybe the axes would still have residual effect of some sort even after emulation off. If so i'm not sure what the most efficient way of doing that is. I don't want to have to reflash the stick. Know an easy way to do this?

Nothing moves in the device tester except the microstick button directx button 19 lights up when pressed. Also if I load up keytester, holding S3 and pushing microstick button produces and INS key up down. Should I have flushed any programming out of the stick before attempting any of this? I ask because when button emulation is turned on I still get the Foxy programming settings back. Just wondering if that might be interfering. Microstick was programmed with this: MIX /I 6 23 (2 4 6 8 11 14 17 21 25 30 36 43 58 65 71 76 80 84 87 90 93 95 97 98) MSY(3-) MSY(3+) MSY(0) /O 3 HotasSlewDown ^ HotasSlewUp MIY /I 6 23 (2 4 6 8 11 14 17 21 25 30 36 43 58 65 71 76 80 84 87 90 93 95 97 98) MSX(3-) MSX(3+) MSX(0) /O 3 HotasSlewRight ^ HotasSlewLeft

Ok here are the pics off ccp and device analyzer.

Thanks for the reply sorry for the lack of information. CCP checks out with axes at 7 & 8. I'm currently using A10C with FC3 and KA50 as only the other aircraft configured. So far most of the functions I have tested (in A10C) seem to work fine with a few that don't but I have only done a cursory run through so like this most will probably be user error. Here is output from run. Running script: C:\Program Files (x86)\Thrustmaster\TARGET\DCS World.tmc Mapped plugin module "C:\Program Files (x86)\Thrustmaster\TARGET\Plugins\sys.dll" Compile Succeeded. Physical USB HID devices managed by script! Currently plugged USB HID devices[3]: 1: "Thrustmaster HOTAS Cougar" - "USB\VID_044F&PID_0400&REV_0110&MI_00" 2: "F16 MFD 2" - "USB\VID_044F&PID_B352&REV_0100" 3: "F16 MFD 1" - "USB\VID_044F&PID_B351&REV_0100" USB HID device with hardware id "VID_044F&PID_0404" cannot be found USB HID device with hardware id "VID_044F&PID_0402" cannot be found USB HID device "F16 MFD 1"(USB\VID_044F&PID_B351\5&6D14A7A&0&5) selected USB HID device "F16 MFD 2"(USB\VID_044F&PID_B352\5&5237C50&0&3) selected USB HID device "Thrustmaster HOTAS Cougar"(USB\VID_044F&PID_0400&MI_00\6&22A98733&0&0000) selected USB HID device with hardware id "VID_044F&PID_B10A" cannot be found Virtual HID devices managed by script! Connecting virtual joystick...Done Device name set to Thrustmaster Combined Connecting virtual keyboard...Done Connecting virtual mouse...Done DCS_Init (Profile v1.35): Differential Braking: Input = 0 Analog = 0 Differential = 0 DCS A-10C Warthog Config (Profile v1.35): Enabling Aircraft Modules...Ka-50...A10C...P51D...Done Map Cougar Left MFD (DX31)...Done! Map Cougar Right MFD (DX32)...Done! Map HOTAS Cougar for DCS A-10C Warthog: Map HOTAS Cougar: Axis mapping Cougar Stick...Done! Axis Mapping TQS Main... Initializing Throttle Twin Engine Start/Shutdown Routines...Done! Axis Mapping TQS Auxiliary...Done. Digital Axis Mapping: Man Range to Autopilot Switch...Done! ...Done! Button Mapping: Shift Commands: S3 momentary......Done! Cougar Stick Buttons......Done! Init Trim with Padlock for TrackIR Users. Hat1 (Trim)...Done! Hat2 (TMS)......Done! Hat3 (DMS)......Done! Hat4 (CMS)......Done! TQS Buttons... Type 3 (Analog-Momentary) Airbrake Set. Brake Out = 3500 Brake In = 2000 ...Done! HOTAS Cougar Mapping Complete. Dogfight Switch Initial Check...Done. DCS A-10C Warthog Init Complete! Setting Landing Gear Indication...Set! DCS A-10C MFD Defaults (0,0): A-10C Warthog Config Complete! Setting Landing Gear Indication...Set! main returned 0 AirBrakeProc() AutoRepeat Enabled.

Hey Home Fries nice work on the layouts. I'm trying to get this setup on my cougar but I must have missed something because I have no microstix, they don't even show up in DCS when I go to axis assign. Did I miss an option some where?

Need to dig this up as I have the opposite problem. The yellow mouse pointer is always there and does not fade away. Recently cleaned out Cougar HOTAS including firmware and fresh installed everything. The mouse functions fine in every other aspect as a mouse pointer and a slew control for TADS and TGP and Maverick. Anyone ideas?

I have had some fun with this script today, lots of problems but no less cool. Attached is a pic of a culmination of issues. Destroyed aircraft are cleared instantly but there is the problem of the ejected pilot. :lol: That mig in the background is about to wipe out all of these aircraft. There are two more hovering overhead like vultures. They seem to have a tendency to run to the back airbase instead of going after the actual airspace intruder, not always but the cap patrols seem to have a sort of tunnel vision or single minded way about them. Do the cap patrols only engage what is in their patrol zone or will they go after GCI alerts also? An unseen part of this picture is bluecap1 did not try to engage these migs as they were coming down on the base and they went straight to their patrol zone while these poor bastards got picked off one by one. So I had an idea, wish someone could do a combat video script that just jumped around from furball to furball. I have a 8' screen in the movieroom so it would have been nice to grab a beer and peanuts and watch the show .... after Daytona of course. :D