Catweedle

For ground targets make sure the WP altitude is set to ground level. Just put a zero into the altitude field, the ME will adjust it accordingly.

Iterate over a unit's table and its pylons. This is how the unit/-s table for a group looks like (found in the mission file inside .miz archives): ["units"] = { [1] = { ["alt"] = 2000, ["hardpoint_racks"] = true, ["alt_type"] = "BARO", ["livery_id"] = "VFA-37", ["skill"] = "High", ["speed"] = 179.86111111111, ["AddPropAircraft"] = { }, -- end of ["AddPropAircraft"] ["type"] = "FA-18C_hornet", ["unitId"] = 1, ["psi"] = 0, ["y"] = 632571.42857143, ["x"] = -298571.42857143, ["name"] = "DictKey_UnitName_7", ["payload"] = { ["[b]pylons[/b]"] = { [1] = { ["CLSID"] = "{5CE2FF2A-645A-4197-B48D-8720AC69394F}", }, -- end of [1] [2] = { ["CLSID"] = "{C40A1E3A-DD05-40D9-85A4-217729E37FAE}", }, -- end of [2] [3] = { ["CLSID"] = "{GBU-38}", }, -- end of [3] [4] = { ["CLSID"] = "{AAQ-28_LEFT}", }, -- end of [4] [5] = { ["CLSID"] = "{AWW-13}", }, -- end of [5] [7] = { ["CLSID"] = "{DB769D48-67D7-42ED-A2BE-108D566C8B1E}", }, -- end of [7] [8] = { ["CLSID"] = "{9BCC2A2B-5708-4860-B1F1-053A18442067}", }, -- end of [8] [9] = { ["CLSID"] = "{5CE2FF2A-645A-4197-B48D-8720AC69394F}", }, -- end of [9] }, -- end of ["pylons"] ["fuel"] = 4900, ["flare"] = 30, ["ammo_type"] = 1, ["chaff"] = 60, ["gun"] = 100, }, -- end of ["payload"] ["heading"] = 0, ["callsign"] = { [1] = 1, [2] = 1, [3] = 1, ["name"] = "Enfield11", }, -- end of ["callsign"] ["onboard_num"] = "010", }, -- end of [1] }, -- end of ["units"] Example for iterating over pylons: function print_payloads() for coa_name, coa_data in pairs(env.mission.coalition) do if (coa_name == 'red' or coa_name == 'blue') and type(coa_data) == 'table' then if coa_data.country then for cntry_id, cntry_data in pairs(coa_data.country) do for obj_type_name, obj_type_data in pairs(cntry_data) do if obj_type_name == "helicopter" or obj_type_name == "plane" then if ((type(obj_type_data) == 'table') and obj_type_data.group and (type(obj_type_data.group) == 'table') and (#obj_type_data.group > 0)) then for group_num, group_data in pairs(obj_type_data.group) do local groupName = env.getValueDictByKey(group_data.name) if group_data then for unitIndex, unitData in pairs(group_data.units) do local unitName = env.getValueDictByKey(unitData.name) env.info("Pylons for unit "..unitName.." ("..unitData.type.."/"..groupName.."):") local pylons = [b]unitData.payload.pylons[/b] for k,v in pairs(pylons) do env.info(k.."> "..v.[b][color="DarkRed"]CLSID[/color][/b]) end end end end end end end end end end end return end This will print something like this -- the ordnance/pods/.. are represented as CLSID: Pylons for unit Pilot #001 (FA-18C_hornet/TestHornet): 9> {5CE2FF2A-645A-4197-B48D-8720AC69394F} 2> {C40A1E3A-DD05-40D9-85A4-217729E37FAE} 8> {9BCC2A2B-5708-4860-B1F1-053A18442067} 3> {GBU-38} 1> {5CE2FF2A-645A-4197-B48D-8720AC69394F} 4> {AAQ-28_LEFT} 5> {AWW-13} 7> {DB769D48-67D7-42ED-A2BE-108D566C8B1E} Of course you need to know the CLSID for pods or whatever you want to check. Either find them yourself in mission files or somewhere else.

getAmmo() returns a table and not a string, hence _playerLoadout[i].desc.typeName works and type(_playerLoadout) == 'string' returns false. The string match would have to be changed accordingly: not via find() but ...desc.typeName== restrictedWeapons[k].

This thread might help; it explains the usage of the DCS function world.searchObjects. I use the function to get objects around marks I place on the map (cf. screenie). As mentioned in the above thread, the function can be kind of wonky if you don't do error handling, especially when retrieving a lot of objects and/or using large search-spheres.

Some of the aircrafts' skill settings are set to Client: change the skill for the unit you want to play to Player and the rest to any difficulty, e.g. Average, Expert, ....

Thanks, did not know.

The follow command in the ME only works for groups of the same coalition. To change the ROE, which initially would be set to "WEAPON HOLD" in the advanced waypoint actions for the Su-27, one solution would be to create a trigger for a moving zone which checks for player units' presence to change its ROE. In advance, you would have to a) define an arbitrary zone that will be used as the moving zone in the moving zone trigger, and b) setup the ROE change as a triggered action on the Su-27's waypoint/-s, which in turn will be used in the moving zone trigger. Since you are new to the ME, maybe can help.

Issuing commands (WP/target) during runtime might break advanced actions that have been setup in the ME to force the AI to e.g. not abort the mission and RTB prematurely. So, yes, because we have to do things in the ME to make the AI work a little better, F10'ing, or scripting in general, is usually the better solution to command our pixel planes.

I don't see any pics, but I am pretty sure that's related to suboptimal pathfinding and terrain management in general. Plus, pathfinding seems to be in an extremely bugged state right now (cf. recent threads in bug forums, e.g. for Combined Arms). Not much you can do about it until this issue is resolved or optimised; try finding workarounds if applicable.

I would like to thank HC_Official -- and I think I speak on behalf of most HC regulars -- for always keeping the Havoc Company servers and missions updated and running, especially in extraordinary (DCS) times like these. :thumbup:

The concept is old, the rather negatively associated term crunch (time) not so. I do agree, though, that repeatedly crunching a bag of chips usually results in a mess. Fingers crossed ED does not end up like that.

Another factor might have been deployment time. Depending on skill level, the artillery AFAIR needs 1-3 minutes to deploy and fire the first shells.

Hm, Alec might be right. Sochi had ~7 km/h around 1400, and the server shows 7 m/s after its lunch break -- even if the average wind speed of the AO is calculated the assumption seems to hold. The PG server, however, appears to be working correctly wrt. that -- e.g. north-central UAE had ~11 m/s at 1400. Something else: auto-kick stopped working. Thanks, and stay healthy!

@OP: If you by "first waypoint" mean the first waypoint you have manually set, try setting invisible on the previous waypoint, i.e. the group's start position at waypoint 0. I just tested it, and I am not having any issues. Wrt. hiding also the 3D-Model: correct, invisible only makes other AI units ignore the invisible ones. To completely hide them you could set them to "late activation" or spawn them via script. Both options are probably not what you are looking for, though.

[REPRODUCED]Flickering lights I am observing the same flickering (exterior) lights as shown in this thread, using the latest OB from 27.11.2019. The blue reflection/flickering shows on the right side of the plane and only when the exterior lights are switched on and the position lights are turned above min. power; formation lights do not even have to be turned on for the blue flicker to be visible. The red flicker appears on the same spot as the blue one, just on the opposite side of the plane (left). The red flicker, however, is always there, even if the lights are turned off. The effect is only visible when the plane is moving/airborne and the game is unpaused. I made a short video showing the observations in the order above and attached the corresponding trk file, plus my ingame graphics settings (I'm using a 1060; Windows 10). The video compression had a hard time with the dark scene, but it actually helped to make the issue stand out. f18_extLights_bug.trk

The formation lights "reflection" only shows when the lights are switched on and the position lights are turned above min. power; the actual formation lights do not even have to be turned on for the blue flicker to be visible. The red flicker appears on the same spot as the blue one, just on the opposite side of the plane (left). The red flicker, however, is always there, even if the lights are turned off. I will try to make a video and report it today.

Server 1: no more CTD's, Robles and me tested in CCIP/Auto. Edit: Nope, 2nd weapon release on same mission -> CTD. Only difference was pylon + moving target. Thanks, HCO, nevertheless!

PG server still CTD's Hornets. Will try server 1 now.

I just tested it with Hornet+GBU-12's on both Havoc servers: on weapon release -> CTD, no crash log generated. Works okay in SP and when hosting my own server. Unfortunately, AFAIK nobody has reported this issue in the bug forum yet, so it may not be a general problem.

That was a bit odd, I expected Search Then Engage ... to work out of the box -- it didn't this time. However, setting ROE to WEAPON FREE finally did the trick and units get engaged.

A general workaround for missing units is to have "USAF Aggressors" on the desired side (RED/BLUE). In your case, you could have a Ticonderoga on RED side and have it launch cruise missiles at the base.

After a couple of tries I also cannot find the Havoc Company in the server list after several refreshes; it worked a couple of hours ago, though.

I see this happening also, and it can be replicated every time units get spawned via addGroup-scripting and not late/activation (e.g. on the havoc-company server/-s). I have the feeling that the introduction of the "Game Master Only" option for groups in the ME might play a role here. That option, when inspecting the mission file within the miz file, sets the group variable/attribute ["uncontrollable"] to either true or false. I do not see anything similar in any of the popular scripts (moose, ctld, mist) when defining group tables for spawning. Also in my scripts, that script-spawn groups/units, I never used it. I will contact havoc-company or try myself if it makes a difference when adding that attribute to the group's spawn tables. Edit: moose seems to use deepcopy'd group data, so if it was set in the mission editor, spawned groups should inherit the uncontrolled setting; the same holds true for mist, as I just found out. Hence, the coalition.addGroup-spawning _might_ not be the problem.

If you mean manual transmission, maybe the checkbox Automatic Transmission in Options->Special->CA will help.

Greetings, the Msta artillery unit shows some unusual behaviour when hit by 25mm HE: Front and side armor have anomalies in weak points: might be hatches (intended?), but also odd (border) regions of the armor that basically have to be sniped Unit does not take any damage when hit from behind, i.e. neither rear nor side armor Chassis never takes damage (intended?) I have tested this with the current DCS OB version from yesterday (12.11.2019), in the order it is listed above, and attached the corresponding trk file for the video: 25mmHE_Msta_test.trk