Toumal

That was indeed my error! Thanks!

Got some logs for you! Unfortunately, there's not much to see: https://pastebin.com/casfvtuj For this test, I load up the Splash Damage script before MOOSE. However, that doesn't change a thing. The units I attacked are inside a zone, and are spawned as follows: function CaucasusPendulum.SpawnCaptureZoneUnits (zoneName, coalitionParam) local SpawnZones = { ZONE:FindByName( zoneName .. " ZONE" )} local coalitionName = "BLUE" if (coalitionParam == coalition.side.RED) then coalitionName = "RED" end local SpawnGroup env.info("GROUP SPAWN: "..coalitionName.." "..zoneName) SpawnGroup = SPAWN :New(coalitionName .. " " .. zoneName .. " GROUP") :InitKeepUnitNames( true ) :InitLimit(20,0) SpawnGroup:Spawn() end So really nothing special. The zone has MOOSE scoring set up as follows: Score = SCORING:New( "Caucasus Pendulum" ) Score:SetScaleDestroyScore( 100 ) Score:SetScaleDestroyPenalty( 200 ) Score:SetMessage<profanity>( false ) Score:SetMessagesDestroy( true ) Score:SetMessagesToAll( true ) Score:AddZoneScore(AlphaZone, 50) The result is that neither the scoring messages, nor any actual score updates seem to work once SplashDamage is loaded together with MOOSE. EDIT: Here's how MOOSE hooks in: self:HandleEvent( EVENTS.Dead, self._EventOnDeadOrCrash ) self:HandleEvent( EVENTS.Crash, self._EventOnDeadOrCrash ) self:HandleEvent( EVENTS.Hit, self._EventOnHit ) It seems like these don't work anymore once SplashDamage is loaded. Maybe the event has to be passed on by you so other handlers can receive it as well? EDIT: I tried replacing the pcall with a direct call in the splashdamage event handler: function WpnHandler:onEvent(event) -- protectedCall(onWpnEvent, event) onWpnEvent(event) end However that changed nothing - splash damage works fine still, but no MOOSE scoring events. EDIT2: Also tried disabling wave_explosions, same result.

Hi, No joy. First of all, a brand new JF-17 does not start for me anymore using the published procedure. Engine spools up to about 25 and then stops with a bang. Also tried ENG + GND button, engine spools up to 20 and then stops. If I use ENG first, wait until 20, and then switch it to START and press GND, engine spools up to 25 and stops with a bang. Also tried STARTER position, no success. I tried spooling it up with ENG to 20, and then switching to START without pressing the GND button, nothing happens. Last but not least, even on a freshly spawned aircraft I tried doing the ENG crank first, letting it spool up to 20 and spool down eventually, then switched to START and pushed GND. The engine spooled up to 25 and then went out with a Bang again. So, with all that said, and after having read both the official documentation and Chuck's guide, and having tried all the combinations above on an empty mission with just a fresh JF-17 (with fuel) on the map, what is the procedure for the JF-17 start after this patch, step by step please?

I can't get it to start up at all anymore. Tried all three settings, no bueno. Is there any way we could get updated procedures?

Argh, I don't think I have that log anymore. But I did scour through it and saw no error or other related message really. I think what happens is that MOOSE hooks into the events, and then you hook into the events, and apparently events handlers work via the highlander-principle. But I could be wrong!

Hey there, I also have our server crash when I launch a SLAM-ER with a manually entered steerpoint and a cleared altitude. The funny thing is, the crash appears to happen a few seconds after the weapon detaches from the pylon, it feels like it's the moment when the weapon starts its own navigation logic. Is this something that needs more crash logs for investigation?

We observed this issue on the 167th DGN Server and haven't had this happen in almost 2 years. The groups I spawn are only spawned after being destroyed or after they land, at which point the old group is destroyed before the new one is spawned, everything via MOOSE. Recently we've had invisible JF17s fly around the map and shoot down people, and this is most definitely a new thing. I checked the code again to see if there was any change but aside from upgrading MOOSE itself and of course DCS updates, the logic that spawns AI CAS and CAP units hasn't changed. I never spawn AI airplanes without checking if there's a copy flying currently. To me this smells like a bug in DCS. Even on the server side the list of objects doesn't contain them (I send updates to a web live map from the server).

Heya! I love your script, but unfortunately I found that it interferes with MOOSE scoring. Ground target hits are no longer detected by MOOSE (latest stable version). Is this a known issue or did I just miss a step?

Thanks, that is indeed confusing. I have to have MOOSE (as well as mist, witchcraft and a few others) to support the various modules. I did not intend to use MOOSE specifically, in fact I was actually trying to avoid using it for fundamental things However, as it turns out for me the cleanest way to proceed is to store intent instead of results, i.e. commands that led to the creation of the static, instead of the statics themselves. Anyway, thanks a lot for the help! I'm pretty sure I'll run into the problem of iterating through statics again soon, so this will come in handy.

AllStatics:ForEach(function (grp) local _name = grp:GetName() if (string.starts(_name, "CTLD ") ) then env.info("Found CTLD static: "..grp:GetName()) env.info("Found CTLD static X: ".. grp:getPoint().x .." Z: ".. grp:getPoint().z) env.info("Found CTLD static Country: ".. grp:getCountry()) SaveStatics[grp:GetName()] = { ["heading"] = grp:GetHeading(), ["groupId"] =grp:GetID(), ["shape_name"] = grp:GetTypeName(), ["type"] = grp:GetTypeName(), ["unitId"] = grp:GetID(), ["rate"] = 20, ["name"] = grp:GetName(), ["category"] = grp:GetCategoryName(), ["y"] = grp:GetVec2().y, ["x"] = grp:GetVec2().x, ["Country"] = grp:GetCountry() } end end) I also tried staticObject = StaticObject.getByName(name), no joy. I actually found a workaround by not using any of those functions, and just storing commands for recreating the objects needed along with the required parameters. But it's super cumbersome, and I also found out that some scripts hook into the static creation in a way that completely breaks it (specifically Airboss). It's all quite painful.

I tried that, but no joy. But even before that I have the problem that I do not know what object is which, for when I iterate though every static I get 2 objects returned for a single static object in game and I don't see a way to discern between these two. And calling getPoint() on a static that I fetch by known name results in a nil error. EDIT: I think there's something wrong in DCS here. The returned objects seem to imply that internally there's both a group and a unit. But the usual methods don't work.

Hi, I'm having trouble getting the position of a static object. I have created a static object in the editor but I cannot use function such as GetVec2().x and .y to get the position. Basically I'm trying to save the position of an existing static to respawn it later. I have analyzed SimpleStaticSaving (https://github.com/thebgpikester/SimpleStaticSaving/blob/master/SSS) as well as SWAPR and CTLD. Is there a difference between mission editor placed static objects and dynamically spawned ones when trying this? Also, when iterating through all statics with SET_STATIC:New():FilterStart(), how does one differentiate between the group entry and the, well, "unit" entry of the static object? Thanks!

Heya, I had the issue that I needed a much larger radius for certain locations - mostly locations with a certain terrain elevation. Since using land.getHeight it works consistently. I think if you do a test case on a mountain top you'll find that you'll need a crazy large radius value for it to work, and zone.radius won't find a thing. As for both unit and group being returned - yes that is the case, even with category.UNIT specified. What I found is that apparently everyone is doing this kind of alive check in their scripts (CTLD for example) which will only pass for the actual unit, not the group. That's appears to be the reason why they don't run into troubles.

Hey there, thanks a lot for the reply. I gave that function a try, but unfortunately it didn't seem to work quite yet. Let's say I have a trigger zone called "BRAVO ZONE" which the function does find. I did notice that even though the radius in the mission editor was set to 1000, the searchZone.radius turned out to be an odd value: 304.79998779297 Worse, it was extremely inconsistent, sometimes it detected units properly, sometimes it did not. As it turns out, zone points are MSL, and I need to add terrain altitude. The second problem: I have a single unit in BRAVO ZONE, yet when I iterate through the results I get this: 2022-01-12 17:55:45.544 INFO SCRIPTING: Defenders alive in BRAVO 2022-01-12 17:55:45.544 INFO SCRIPTING: ScanZone: Unit found: RED JULIET GROUP-1-1 2022-01-12 17:55:45.544 INFO SCRIPTING: ScanZone: Unit found: RED JULIET GROUP-1-1#001-01 I get these results even after I kill said unit with tank fire from a player controlled tank (which is not part of that group, so that's not the reason for the two units). When I try to check for health getLife or IsAlive I get a nil pointer error. Turns out, the first object is a group, and the second object is the unit. Unless you do your object conditions in the right sequence, you run into nil errors. In the end, I modified the function as follows, which works as expected: function CaucasusPendulum.ScanZone(category, coalition, zoneName) local foundUnits = {} if trigger.misc.getZone(zoneName) ~= nil then local searchZone = trigger.misc.getZone(zoneName) -- new sphere searchVolume from searchZone local searchVolume = { ["id"] = world.VolumeType.SPHERE, ["params"] = { ["point"] = {x=searchZone.point.x, z=searchZone.point.z, y=land.getHeight({x=searchZone.point.x, y=searchZone.point.z})}, ["radius"] = searchZone.radius, } } -- search the volume for an object category world.searchObjects(category, searchVolume, function(obj) -- if the found object is of the same coalition, add it to the table if obj ~= nil and obj:getLife() > 0 and obj:isActive() and obj:getCoalition() == coalition then foundUnits[#foundUnits+1] = obj end end) end if #foundUnits > 0 then -- return the found units return foundUnits end -- return nil if no found units return nil end Thanks a lot for your help, I hope I could contribute back!

I can confirm that it used to work in the past. Much fun was had with no problem. And again, I wouldn't mind having to stabilize yaw myself as per official flight manual, but then at least the ground stabilization of the camera needs to remain functional in multicrew as it does solo.

This sounds weird since there is AP switches for Pitch, Roll and Yaw in the cockpit. And there's an auto-slave toggle button on the stick, which has the function of aligning the helicopter with the current target of the camera. Unless of course, all these controls do not exist on the real helicopter. The flight manuals I found do say the same thing you do, but I see versions of the Gazelle cockpit with and without the axis switch box, so I'm wondering if there may be versions that do stabilize yaw. I did not have to do any of these steps. Neither do they change anything about the observed issues. Even minute changes in manual yaw produce 10, 20, 30m or more deviation in the camera aim, which makes it impossible for the gunner to hit a target. We are talking sub-millimeter changes on the rudder pedals throwing off the aim. The only solution is to land the helicopter on a hill so there's no more yawing happening. If the yaw was a bit more forgiving on the camera, and/or the camera ground stabilization would work in multicrew, I could understand and cope with it. As it is now, it's not usable.

Hi, I'm trying to find out, in LUA, whether a given zone has units of a particular coalition inside. Getting a callback for when the zone has no units alive inside would be also acceptable. So far I tried MOOSE's onEnterEmpty() which didn't fire, I tried using a filter expression ala SET_GROUP:New():FilterPrefixes("GROUP PREFIX STRING"):FilterActive(true):FilterStart(), but iterating using ForEachGroupAlive() returns me groups that are not nil, but when calling functions on them say they are nil.... So I figured I'd just ask: How can I find out, or get notified, when a zone has for example no red units in it anymore?

Hey there! Old thread but... I recently tried these callbacks to be notified when all units of a certain coalition had been destroyed in a given zone. However, if I destroy the last enemy unit in the zone the callback does not fire. Is this supposed to work still or is that a known issue?

This is from the mission editor, the fixed ELINT sites have circles scribbled around them in blue.There's also one AWACS for each side outside this view. All units are spawned dynamically based on capture zones. I have SRS and TTS set up and the "Atis" always says no contacts, on both sides, no matter what. The F10 map in the game shows only my circles (they denote the current capture status and are not generated by ELINT). All these zones have SAM sites in them, and as red I would expect at least some of them to be detected. Or are the towers just too far away? They are on hills with LOS down to most of the bases in that area.

Hi there, Is there any way to find out why ELINT won't discover any SAM sites? In my server logs I can see this if I set debug to true: 2022-01-04 16:15:28.192 INFO SCRIPTING: [Hound](T) - 5202: default has 5 Contacts 2022-01-04 16:15:30.970 INFO SCRIPTING: [Hound](T) - 5202: default has 9 Contacts I'm just using default zones for both sides - is that a problem? I got some comms towers about 5-10 grid squares away, as well as AWACS for both sides.

If you are pulling your hair out because your path is correct and you still get the "Windows cannot find..." error: Make extra double sure you have a TIME MORE (1) condition for the loading of your related LUA files, as shown in the documentation: Adding that delay condition made it work for me!

Hi, had a lenghty test session yesterday and found the following issues appearing in multicrew, and ONLY in multicrew: Autohover doesn't work as expected as soon as another player hops into the helicopter. More specifically, autohover will actually engage, but will only manage cyclic, not the tail rotor nor the collective. The Ctrl-Enter indicator also shows this. As soon as the second player exits, autohover works as expected. HOT-3 gunner cannot stabilize the crosshair on a target intermittently. This works if playing alone, but as soon as you join another helicopter in multicrew this function appears to be broken. Because of 1 and 2, it is impossible to deploy the rockets against ground targets in multicrew. Even the smallest yaw motion makes the crosshair jump some 30 meters to the left or right. When a gunner joins, weird things happen in the cockpit: for example, the INS rotary knobs move to different positions. If the gunner joins while the turbines are running but the main rotor hasn't spun up, the state of both seem to be completely desynced between the pilot and the gunner. Maybe that's an older bug, but I'm mentioning it for completeness' sake. We tried this multiple times with people swapping roles and helicopters and could reproduce this consistently. That's a big shame because the HOT-3 variant is the one that makes the most sense in multicrew, and right now it appears to be unsuable. Still works fine if you fly without a second player in the same helicopter!

I'm having an issue with Kobuleti remaining neutral at map launch even though there are red units (and no blue ones) spawned there. Anyone know why this happens, or why this only appears to happen on Kobuleti and not other airports?

Aaaah, ok so the behavior doesn't change, it's just getting rid of an erroneous offset. Gotcha, thanks!

Hi, I noticed the following in the patch notes: Scripting. The scripting function Unit.getLife() returns a value that is 1 higher than what the units actual health is - fixed. What does this mean for scripting? Do I have to check whether a unit is alive by doing if (unit:GetLife() > 1.0) as before? Or does GetLife now return values between 0.0 and 1.0 as one would expect?