scrapple

I tried setting up a simple mission like in the video on both the Normandy andd NTTR maps. (I didn't try 1.5.) I couldn't get it to work like in the video on either map. I could set up an Embark to Transport option for the infantry at their waypoint 0, but at waypoint 1, where I want to disembark them, there doesn't seem to be a Disembark from Transport option in the Advanced Waypoint options.

This has been fixed in 1.5.7. https://forums.eagle.ru/showpost.php?p=3227902&postcount=53 Not sure about 2.1.1. Thanks Belsimtek!!

The AI gunners issue should be fixed in 2.1.1 in today's update. https://forums.eagle.ru/showpost.php?p=3233515&postcount=32 It was fixed in 1.5.7 in the 8/23/2017 update: https://forums.eagle.ru/showpost.php?p=3227902&postcount=53 More importantly (to me) the rope tearing issue with slingloading was fixed in 1.5.7, but the 2.1.1 changelog doesn't specifically mention it.

Thank you sir! And I just noticed that I seem to get the same behavior if a an AI aircraft group is set to late activation or a delayed start time in the mission editor. Each time the group respawns at a higher and higher altitude. This occurs even if all the waypoint altitudes are entered as MSL.

I've run into something unexpected when using the mist.respawnGroup function to respawn AI aircraft groups in the air. It may just be something I don't understand, or that I'm doing wrong. If the aircraft waypoint altitudes are entered as MSL in the mission editor, the aircraft respawns at the same altitude each time which is the behavior I would expect. However, if the altitudes are entered as AGL, the aircraft respawns at the correct location, but at higher and higher altitudes each time. The altitude increase each time seems to equal the ground height below the starting waypoint. For example, if the ground below the waypoint is 1500 ft above sea level, the aircraft would respawn 1500 ft higher each time. So of course this is a lot more noticeable when the aircraft is respawning over mountainous terrain. I've attached a very simple 1.5.7 mission file that demonstrates the issue. There are two AI aircraft in separate groups (Group #001 and Group #002) that spawn at approx 5000 ft. In Group #001 all the waypoint altitudes are entered as MSL in the mission editor. Group #002 is identical, except I changed the starting waypoint to be AGL. Mission start time is 12:00:00. The lua script respawns the two groups every 30 seconds. 12:00:00 (mission start) - Both aircraft spawn at ~5000 ft. 12:00:40 (first respawn) - Both aircraft again spawn at ~5000 ft. 12:01:10 (second respawn) - Group #001 spawns at ~5000 ft, Group #002 spawns at ~6800 ft. 12:01:40 (third respawn) - Group #001 spawns at ~5000 ft, Group #002 spawns at ~8600 ft. 12:02:10 (forth respawn) - Group #001 spawns at ~5000 ft, Group #002 spawns at ~10400 ft. And so on... And here's the lua script: function respawnAI(arg, time) mist.respawnGroup("Group #001", true) mist.respawnGroup("Group #002", true) return time + 30 end do timer.scheduleFunction(respawnAI, nil, timer.getTime() + 30) end Respawn Testing.miz

Thinking back, you are exactly right. I had never associated the two events before. This one is easily reproducible. In 1.5 I set myself up at Batumi airport with 80% fuel, with a piece of cargo a little ways in front of me. Hooked it up and then intentionally did something to get a ROPE TEARS message. (It wasn't too hard. :)) Then I set the helicopter back down on the ground at Batumi, put the throttle back to idle, sat there and watched the fuel needle go down. After about 4 minutes I got the 20 MINUTE FUEL warning, then about 1 min later the fuel was completely empty. I tested a similar mission in 2.1 on the Nellis map, and the same thing happened. I really hope they fix all this soon.

It seems like something has changed recently with the slingloading. The cable seems to have become incredibly fragile. I don't claim to be the world's smoothest hoverer and slingloader, but until recently I could hook some cargo, lift it, carry it and deliver it, usually without incident. But now, much more often than not, somewhere in the process I'll get a ROPE TEARS message and the cargo falls to the ground damaged. And it happens during some relatively smooth and gentle flying. Back when I was first practicing slingloading, when I was terrible at it (the first time), I would damage cargo all the time, but I don't specifically recall a ROPE TEARS message. So that seems to be new. I don't know...maybe I've gotten just gotten terrible at it again, but it's really frustrating.

Since we don't have a Group.isActive() function in LUA, what would be a good way of determining whether a group has been activated? I was looking at maybe getting one of the units in the group, and checking whether the unit is active using Unit.isActive(). If so, that would imply the group is active. I just wanted to see if there might be a more straightforward (easier) way. Thanks!

Thanks for the replies! I was able to set up a multiplayer test scenario to see exactly when the client aircraft unit went from nil to NOT nil and vice versa, and Grimes you were exactly right...of course. The client' aircraft became NOT nil at the moment he clicked Fly. It went from NOT nil to nil at the moment he died (crashed into the ground). When a still-alive client quit the game and returned to the aircraft selection screen the aircraft didn't switch from NOT nil to nil until he moved out of the aircraft slot (either left the game completely or moved to another aircraft slot). I didn't think to check what happens when the pilot ejects. Anyway, for what all that's worth...

aircraftUnit = Unit.getByName(aircraftName) if aircraftUnit ~= nil then ............. end I've been using something like this code to check whether a human client aircraft has entered or left the game in multiplayer or has died, and it may (or may not be) working, it's kinda hard for me to test. But can someone tell me exactly at what point a client aircraft unit would be become nil or not nil? Does it become not nil when a client clicks Fly? And then does it become nil again when the client aircraft dies or disconnects for whatever reason? Is there a better way to do this?

I just asked basically same question a couple days ago here: https://forums.eagle.ru/showthread.php?t=176178 Bottom line is there isn't a way to do what you (or I) want to do, which is identifying the aircraft unit that selected the menu option. The only workaround is to put each human client aircraft in a different group, as others have suggested. According to Grimes, DCS may add this in the future. Sure hope so!

Thank you Grimes!

When a human client selects an item in the F10 menu, I'd like to be able to pass the unit name or id of that client to the script. There just doesn't seem to be any way to do that right now. Something like this would be nice: missionCommands.addCommandForUnit(unitID, "Options", nil, optionsFunction, unitID) There is of course the addCommandForGroup() function: missionCommands.addCommandForGroup(groupID, "Options", nil, optionsFunction, goupID) With that you could make each client aircraft a separate group and that would accomplish the same thing I guess. But that adds a lot of complexity to the mission, and a lot of extra work for the mission builder. Is there something I'm missing, or is this a feature we might could expect in the future? I'm pretty new to Lua programming, does ED periodically add new Lua functions?

I'm certainly no expert, but it looks like you might be scanning underneath him. I can't see the numbers on your radar screen very clearly, but the top number on vertical scan range on the left looks like it's 14 maybe? If so, based on your 20 mile scan range, and where your TDC is (about 10 nm), that means at 10nm your vertical scan range is only between 14,000 ft and whatever the bottom number is. 18.6 km is just beyound 10nm, so in this particular case I think you may need to raise your vertical scan range higher.

Thanks! I knew there was some sort of issue if you were the host of a MP mission, but I didn't know the same problem existed in SP. I feel better...I guess. I do wish it worked right though. I'm sure ED has this on their list of things to fix Real Soon NowTM. :)

Ok, this is getting frustrating. Now, I can't seem to get the tanker to give me any gas at all. I've attached a track and the mission file if anyone would be willing to take a look at it and see if you see anything I'm doing wrong. It may not be perfect flying, but surely somewhere in there I was in good enough position that he could have plugged in for a little while if he really wanted to. F-15C aerial refueling.trk F-15 aerial refueling.miz

I'm not sure if what I'm experiencing is part of this same issue or not... When I try to refuel in the F-15C, I go through the steps: contact the tanker, pre-contact, open the refueling door, then slide into position. If I get in the right spot, the boom will connect and you can hear the fuel flowing. But...if I get out of parameters and the boom disconnects (which usually happens pretty quickly), there doesn't seem to be anything I can do to persuade the boom operator to give me any more fuel. I can get back into position, both lights middle green, and sit there. It doesn't matter, the boom just seems to wander around aimlessly. The Ready light on the canopy bow is lit. Is there something I need to do to reset after the boom disconnects, like in the A-10C you have to push the NWS button I believe. And also I never seem to hear any radio messages from the tanker that I hear in some other aircraft ("Return pre-contact", "You're taking fuel", etc.)

The only other thing I might suggest to check, if you haven't already, is your display setting in Windows Control Panel where you change the screen resolution. At the top of the page, just below where its says "Change the appearance of your displays' you should see two displays labeled 1 and 2. If display 2 is to the right of display 1, drag display 2 down and place it underneath display 1.

My setup seems to be the same as yours, two 1920 x 1080 monitors stacked one on top of each, with Helios running on the bottom. Here's my monitor setup file. I'm not expert on this stuff. I used EMC awhile back to create it, and every update, I just rerun EMC. So far it has kept working. One of these days, EMC may not work any more, and then I'll be totally lost. :) _ = function(p) return p; end; name = _('My A-10C Stacked'); Description = 'My A-10C Stacked' Viewports = { Center = { x = 0; y = 0; width = 1920; height = 1080; viewDx = 0; viewDy = 0; aspect = 1.77777777777778; } } ED_A10C_RIGHT_MFCD = { x = 1412; y = 1206; width = 435; height = 435; } ED_A10C_LEFT_MFCD = { x = 72; y = 1205; width = 435; height = 435; } ED_A10C_UHF_PRESET_CHANNEL = { x = 747; y = 1557; width = 33; height = 33; } ED_A10C_UHF_REPEATER = { x = 657; y = 1776; width = 113; height = 31; } ED_A10C_CLOCK = { x = 464; y = 1899; width = 147; height = 147; } ED_A10C_CMSC = { x = 852; y = 1219; width = 232; height = 52; } ED_A10C_RWR = { x = 595; y = 1236; width = 186; height = 186; } ED_A10C_UHF_FREQUENCY_STATUS = { x = 630; y = 1640; width = 137; height = 38; } UIMainView = Viewports.Center

I keep mine separated all the time. At first it was a little awkward to grip them so they moved together, but it became second nature very quickly. I don't even think about it any more.

OK, thanks for the info. I can see that computing your TAKEOFF weight wouldn't be much of an issue. I assume in real life the pilot knows that number before he even gets in the plane. The more difficult issue would seem to be computing the LANDING weight, since this would depend on a number of variables that you can't compute ahead of time: how much fuel is left, how many cannon rounds you have left, and how many of the various ordnance types (GBU-12, etc.) you have still hanging off the plane. Plus it would have to be computed while you're flying the plane. So, in real life does the pilot, sometime prior to landing, actually compute the gross weight by adding all this up, or do they do a quick estimate, or do they not do anything and just count on their AOA indexer to keep them at the right approach speed?

To do things right, the rotation and takeoff speeds and approach and landing speeds are based on aircraft gross weight. Is there a magic button I can press in the cockpit to get the gross weight? Or do I have to compute the number using actual math? :(

Well all I can say is that in the short time I've been playing DCS A-10 I've learned a hell of a lot more about how the A-10 is flown in the real world from a real-world A-10 crew chief (paulrkiii) than I have from someone who claims to be an active military pilot (Robert1983NL).

I believe the issue is that you can download it, but there doesn't seem to be any link to buy an activation key. I was able to buy it a couple days ago, but an 'Add to Cart' link doesn't seem to be showing anywhere now.

That document has been available for worldwide download on a public US government website for the past several months. So it certainly doesn't seem like they're trying to restrict its distribution. If there really was some information in the document they would prefer to keep under wraps, well...that cat long ago escaped from the bag. However, I removed the link to the site as soon there was some concern as to whether it should be reposted. It wasn't my intent to cause any problems. I was just trying to pass along some information that was useful to me when I too was looking for some "by the book" procedures.