Recluse

Hard to see since it won't expand, but this is the trigger zone: Here is the mission. I stripped out a bunch of other stuff I was playing with and just left the three factory zones. The LEO-2 thing happens only on the DesertBLUE zone (triggers above). But it happened on one of the other zones I had previously placed on the map with similar RED values. EDIT: OH!!! I see I misspelled SOLDIER in the the first entry!!!! I fixed it and it worked fine!! LEO-2 must be some kind of DEFAULT for unknown units?????? I stared at this for a long time but didn't notice it until I pasted it in here!! FALSE ALARM, I think. The perils of COPY/PASTING an error over and over!! I noticed that I made a similar typo in the attackersBLUE, with M2-Bradley instead of M-2 Bradley. In this case, a Leo-2 also spawned in place of the misspelled unit name. DML Owned ZoneFactory Test.miz

So a strange thing is happening to me whenever I create a Factory Zone and assign defenders. Seems to happen with either defendersRED or defendersBLUE (and also attackers, at least for BLUE). When I double up on a Unit, it seems to always spawn a LEOPARD instead of one of them. So, for example, Soldier M249,Soldier M249,M-2 Bradley (defendersBLUE) spawns an M249 Soldier, an M2A2 Bradley and a LEO-2 M-2 Bradley,M-2 Bradley, M-1 Abrams (attackersBLUE) Spawns an M2A2 Bradley, and M1A2 Abrams and a LEO-2 Sometimes the LEO-2 seems to spawn out of nowhere. The first time I saw it, I had a defendersRED set to just BTR-80 and it spawned a LEO-2 as well.

Interesting. This happens to me as well, but USUALLY only if I pick the F-15E as the FIRST jet after joining a MP Server. If I fly something else, then select Role as F-15E it seems to work. I do have MODS and DICE loaded, so I will look into that as well. I don't believe I have a DICE script for the F-15E, though..but will double check.

Hi, Thanks for the reply. That is exactly what i did. Added the helo(s) to the CSAR of Georgia mission. EVERYTHING else in the CSAR manager works fine in the UH-60L, and I did manage to check the DML ADF worked with the AH-64D Apache, so, I think it is a UH-60L issue. What is odd is that the UH-60L picks up one of the built in ADF's (688 KHz (if I recall correctly) just west of the Airbase) without any issue. Must be a UH-60L thing. Was hoping someone else had tried it and could comment on whether it worked for them.

Wow.. I can't imagine what a labor of love this must be!! Amazing work. I am slowly coming to grips with the DML system. Quick question, though. I did a quick search of this thread for UH-60L and ADF and didn't find a similar report, so here goes. - Running the latest CSAR in Georgia demo mission (from the very recent release in the top post). I added a UH-60L to the base and edited the CSARManagerConfig zone to add the UH-60L as an active Helo for CSAR Everything works fine, EXCEPT when I tune the UH-60L ADF to the frequency shown, the pointer doesn't move at all. I thought I just didn't know how to use ADF correctly in this mod, but I tuned to one of the built in Map ADF beacons, (also in proper KHz units)and it worked fine. Any ideas? Unfortunately I do not own any of the other helo mods to test it. I realized I had the AH-64D, so I set it as a TROOP CARRIER (had to use the 'any' config item) and the ADF works just fine. Must be some UH-60L peculiarity (or some other OPERATOR ERROR on my part) Anyone get it working?

Copy over the Scratchpad folder from <yourname>\Saved Games\DCS[OpenBeta]\Scripts Copy over the scratchpad-hook.lua file from <yourname>\Saved Games\DCS[OpenBeta]\Scripts\Hooks to the respective folders in your new Saved Games hierarchy. Create the Scripts and Hooks folders if they are not already there. There is also a Scratchpad folder one level higher at: <yourname>\Saved Games\DCS[OpenBeta]\ You can copy this over, but it SHOULD be automatically created when Scratchpad first runs.

Well looks like I spoke too soon. We started getting script errors today, and it seemed to be in the part of the Foothold zonecommander.lua that got updated after the last patch changed the scripting. EDIT: @Dzsekeb has fixed the ZoneCommander.Lua everything is good (again) THANKS!!

Yes I do believe so, at least until it Merges with @SPAS79 UH-60L update

There have been a lot of updates to the Scratchpad. THE original versions were skipping the first WP in the HORNET (assuming you wanted to use if for something like BULLSEYE) but this limitation was removed (by @Draken35) in later versions. Make sure you grab the LATEST version and all should work fine. (I know you said you had it, but there have been a lot of updates recently. Most recently, there should be a full download that should be the MOST up to date). I have been using the Hornet and Mudhen quite a lot and they both have been working fine. (Also Mirage2000 and Harrier, but not as much) Error messages could indeed be related to the TICKS setting especially in Pancake mode.

Is this going to re-break the code for MOOSE and MIST related scripting (e.g. FOOTHOLD/PRETENSE/*POWER persistent missions that got fixed after the last patch, or will both getCategory() syntaxes work now? EDIT: Just did a quick test and all seems to be working..

Yeah, honestly, THAT video was what gave me the idea to try out the different routes for the JDAM programming. I had sort of gotten the idea when trying to enter sequence points in a jet that had NO sequence points and only "B". I found I could enter 1A or 1.A into Scratchpad to create the A sequence AND I think it (or maybe another video) clued me into the entering SHIFT B to get back to "Waypoint zero" (or "B") when another sequence had been added. I was trying 1B to no avail, and didn't realize it was just "B". The LIST points are very powerful, but, until there is a true DTC, they rely on putting the points in the Mission Editor, so might not be generally available (e.g. on Mulitplayer servers).

So let me add something I just "discovered" which was probably already obvious to everyone. Building on @Str][ker's excellent video (Yes I finally did watch the whole thing!!) I have been messing with JDAM and SCRATCHPAD a lot. Here was my EUREKA moment. - Let's say you have a bunch of Sequence Points already. A mix of Steer and Target. Now you want to designate a bunch of Targets for your JDAM handoff. - Sure, I know I have 10 Sequence Points, so I can just start at 11. either using the WSS parameter or denoting each Scratchpad coord with the number. - BUT the strike Eagle lets you have multiple routes, A, B, C.. so assuming your NAV points are all in the A hierarchy, you can do the following: Set Scratchpad WSS to @<1.C> Set all subsequent WDes Coordinates to @[#.] <----Note the . for Target point Upon entering the coordinates from Scratchpad, you will get a Route of Targets as 1.C, 2.C, 3.C etc... which is totally distinct from your existing A route Sequence. To load your JDAM, Start with entering 1.C and henceforth, just enter 2., 3., 4. etc.. and the Jet will know you want to continue with C route. Once your JDAMS are loaded, you can return to 1.A or whatever A sequence point you want to fly your route.

You're welcome!! Now let's cruise over to the Apache Forums and talk about FIREBIRDS!!

My experience has been similar to the OP. I can bring up the FLIR screen on another MFD, but if I move the TDC to it (SCS toward that screen) it immediately takes over. As long as the TDC isn't there, the Radar remains the sensor. I usually use SEA or GMT radar with AGM-65F to designate a target and bring up the FLIR to make sure I have what I want. I can fire at range. With Laser Guided Ordnance, sometimes including AGM-65E, I find that you can lose the target as you get too close or otherwise out of radar GIMBAL limits, so it is useful to switch to a FLIR designation. For movers, this is always kind of a pain with a lot of heads down activity to lead the targets JUST RIGHT to get a PTRK.

As @Str][ker mentioned above If you are trying to overwrite a TARGET point with a WAYPOINT it will fail because the Scratchpad is trying to pull up a WAYPOINT (no DOT) and you will get the flashing FAIL because there is no WAYPOINT with that number. You need to make it a Target Point for Scratchpad to over-write it. (e.g. 3.A to overwrite Target Point 3) You will get the same error trying to do this manually. It drove me crazy for awhile. Another thing: IF you have NO Nav points set up, it will default to "B" which is essentially WP 0. For Scratchpad or to start populating manually, you should give it the A to start the sequence as just the numbers don't seem to want to create new B points.

I can confirm this. This has been a problem for a long time. I tried to search for the previous Bug Reports, but have come up empty. I know they are there somewhere!! At one point, switching to the TGP MFD retained the Radar Lock, until a DESIGNATION was made on the TGP. Then at some point it change to the behavior shown above where just SELECTING the TGP caused the Sensor to change from RADAR to FLIR. FOUND IT!

Seems to work perfectly for me. Maybe you can make a video or something? Seems like you are doing everything right. When I hit the +L/L button, the coordinates captured represent the position of the dot. I have been successfully dropping JDAMS since 2.9 using these coordinates, so it is definitely working.

Seems like the change in scripting in 2.9 that affected many of the persistent missions has hit the *Power missions as well. Fired up Vegas Power and it was fine for the first run, but when the Save was loaded for the next run, it reported nothing operational, BLUEFOR and OPFOR as well. EDIT: It looks like putting in the latest MOOSE.LUA into the mission has fixed it.

Yeah, I think the script was Dzsekeb's original with some updates by OBI for the Marianas flavor. I hope they see fit to fix it. Pretty sure that there are more instances throughout the Foothold scripts managing that stuff. More challenging when we aren't collecting points for our successes!!

THANKS for the info...

Yeah, I realize that, but I am not skilled enough in scripting to know if it is affected. All I know is that after the update all of our Foothold missions ceased to work in the ways they had just before. If it is any diagnostic help, this (to the best of my limited ability to discern) is the kind of script that seems to be failing: I can see the UNIT.CATEGORY.AIRPLANE and following code that seems similar. function BattleCommander:startRewardPlayerContribution(defaultReward, rewards) self.playerRewardsOn = true self.rewards = rewards self.defaultReward = defaultReward local ev = {} ev.context = self ev.rewards = rewards ev.default = defaultReward function ev:onEvent(event) local unit = event.initiator if unit and unit:getCategory() == Object.Category.UNIT and (unit:getDesc().category == Unit.Category.AIRPLANE or unit:getDesc().category == Unit.Category.HELICOPTER)then local side = unit:getCoalition() local groupid = unit:getGroup():getID() local pname = unit:getPlayerName() if pname then if (event.id==6) then --pilot ejected if self.context.playerContributions[side][pname] ~= nil and self.context.playerContributions[side][pname]>0 then local tenp = math.floor(self.context.playerContributions[side][pname]*0.25) self.context:addFunds(side, tenp) trigger.action.outTextForCoalition(side, '['..pname..'] ejected. +'..tenp..' credits (25% of earnings). Kill statistics lost.', 5) self.context:addStat(pname, 'Points', tenp) self.context.playerContributions[side][pname] = 0 end end if (event.id==15) then -- spawned self.context.playerContributions[side][pname] = 0 self.context:resetTempStats(pname) end if (event.id==28) then --killed unit if event.target.getCoalition and side ~= event.target:getCoalition() then if self.context.playerContributions[side][pname] ~= nil then local earning,message,stat = self.context:objectToRewardPoints2(event.target) if earning and message then trigger.action.outTextForGroup(groupid,'['..pname..'] '..message, 5) self.context.playerContributions[side][pname] = self.context.playerContributions[side][pname] + earning end if stat then self.context:addTempStat(pname,stat,1) end end end end if (event.id==4) then --landed if self.context.playerContributions[side][pname] and self.context.playerContributions[side][pname] > 0 then for i,v in ipairs(self.context:getZones()) do if side==v.side and Utils.isInZone(unit, v.zone) then trigger.action.outTextForGroup(groupid, '['..pname..'] landed at '..v.zone..'.\nWait 10 seconds to claim credits...', 5) local claimfunc = function(context, zone, player, unitname) local un = Unit.getByName(unitname) if un and Utils.isInZone(un,zone.zone) and Utils.isLanded(un, true) and un:getPlayerName()==player then if un:getLife() > 0 then context:addFunds(zone.side, context.playerContributions[zone.side][player]) trigger.action.outTextForCoalition(zone.side, '['..player..'] redeemed '..context.playerContributions[zone.side][player]..' credits', 5) context:printTempStats(zone.side,player) context:addTempStat(player, 'Points', context.playerContributions[zone.side][player]) context:commitTempStats(player) context.playerContributions[zone.side][player] = 0 context:saveToDisk() -- save persistance data to enable ending mission after cashing money end end end mist.scheduleFunction(claimfunc, {self.context, v, pname, unit:getName() }, timer.getTime()+10) break end end end end end end end Thanks for confirming!

I think we ran into this. We play the FOOTHOLD dynamic persistent missions and all of a sudden things stopped working (granting of credits for kills) and we did get some Script error messages that seemed related to this. I noticed it tonight on Marianas Foothold, and then I fired up the Foothold Caucasus 1.4.4 and the same thing happened (no credits granted nor message). I didn't fly that long enough to get a script error. I know a lot of people run various Foothold flavors on their servers. Have you noticed this happening?

Ok Just installed it. Are you recommending the setting as shown, or pointing it out as a potential issue not ALLOWING SYSMEM fallback from VRAM to SYSTEM Memory?

Interesting. I don't have that setting nullI have to say, however, that I haven't had this issue since turning off MSAA pre-2.9 Still do get occasional FPS drops and VRAM overflows but doesn't seem as correlated to F10 map as it once was.

Yes they do, but not the dedicated binds in the module controls for Radio1 VOIP and Radio 2 VOIP as in other modules useful if you want to have different commands per module based on other bindings. null