DaveSD

@silverdevil Good observation! That was one of the new units I added as a test, but I went in and added a "perform task" "go to waypoint" action, but that didn't do anything. I then tried the same thing under "perform command" and that didn't work, either. I'll probably just replace those bad boy vehicles with fresh ones. It won't be a huge deal since there are only two or three waypoints for each before they reach their destination.

Hi @silverdevil, I hadn't thought about doing that. Sometimes I'm a bit slow... The attached mission file is a cleaned-up version of the original mission - no sense in bogging a computer down with things that aren't relevant. The vehicles in question from the original mission are here, along with one that I added after the original mission was saved. Those first vehicles are still exhibiting the same behavior - they run for a few seconds, then shut down without having moved an inch. I did take one of those original vehicles and placed it on a road for waypoint 0 - still no change. However, the new vehicle I added behaves normally. I have a feeling that the "cold start" status is remaining (in a mutated form, since they're actually starting out running), even though "cold start" is unchecked. I can always just replace the odd vehicles with fresh ones, of course. I'm baffled, but I'm easily baffled. Dave Update: I created a fresh mission with each vehicle having a different option: On-road, cold start, 0 knots at waypoint 0 On-road, cold start, 11 knots at waypoint 0 On-road, hot start, 0 knots at waypoint 0 On-road, hot start, 11 knots at waypoint 0 Off-road, cold start, 0 knots at waypoint 0 Off-road, cold start, 11 knots at waypoint 0 Off-road, hot start, 0 knots at waypoint 0 Off-road, hot start, 11 knots at waypoint 0 I also used these same combinations with vehicles starting on a road and going off-road, starting off-road and going on-road, etc. Everything behaved as expected, so I'm guessing it's just a little glitch in the mission file. Update to my update: I added an enemy tank and set it to attack the lazy blue units. That made them very, very angry, and even though they weren't moving (the engines weren't even running), they wasted no time in destroying the tank. test.miz

Howdy everyone, I'm experiencing a problem I've never seen before. It's probably not a bug, just something with a solution I haven't considered. I've got some ground units set up. Currently none are set player driving, none are late activation, and none are cold at start. These vehicles shut off their engines within a few seconds of the mission start. This mission was saved from an earlier mission in which these ground vehicles were set for cold at start and late activation, but I verified none of that is the case now. Originally, the waypoint 0 (off the road) speed was zero, and the first waypoint (on the road) with a speed of 11 knots. I did a couple of things to see if I could resolve the problem. I made the waypoint 0 starting speed 11 knots (didn't work), and I inserted an off-road waypoint between the starting point and the on-road waypoint for each of the vehicles (also didn't work). Any ideas? Could my little AI guys have gone AWOL? Deserted? (These are blue force vehicles, by the way.)

That's no fair, Exorcet, your AI is smarter than my AI. Your example worked perfectly. I modified it for some experiments and those worked fine, too. I don't know why my original testing didn't work. I like your user name, by the way.

I tried a three versions of an experiment, none of which worked. I had an airplane fly over a runway, and between the ends of the runway I placed a series of in-line waypoints. I gave each waypoint a bombing action, each one dropping a single bomb. Mr. AI got confused and couldn't handle that - no bombs dropped, and he didn't even fly the specified path. Then I used a single waypoint and created a series of bombing actions for it, laid out along the runway - one bomb per action. Mr. AI got confused again and ignored my orders. Then I converted the actions to bomb map object, and Mr. AI couldn't hack it. A court martial is forthcoming. Then along a completely different tack, I tried carpet bombing on the first of two waypoints that should have guided the airplane along the runway. Mr. AI dropped all the bombs in rapid sequence, but along a path that wasn't even remotely in line with the runway. Mr. AI has fled the country and is now Edward Snowden's roommate.

I haven't found an answer to this in the forums or in the user manual. So... is it possible to bomb both runways in an airfield, like with Anderson on the Marianas map? With a group consisting of a single aircraft, the same runway is chosen regardless of which way the aircraft approaches it. I tried using two aircraft in a single group; one of them bombed one runway at Anderson, the other didn't bomb anything, and both landed at Won. Please tell me I'm crazy and that there actually is a way to do this, hopefully without LUA scripting. It seems this should be basic functionality; if not, it would be pointless to have maps that have dual-runway airfields.

Hey everyone, Here are some things I'd like to see incorporated into the mission editor. "Jump to location" using any or all methods of geo-location - lat/long,etc. Another option could be "Place unit at location" and/or "Place group at location," although "Jump to location" could serve the same purpose. I'd like to see is the ability to break individual units out from the group they're in. Ordinarily this wouldn't be much of a request, but it's a bit more important when creating semi-dynamic campaigns (one mission's results dictating what's in the next mission, updated manually),. If one unit in a group is killed, it would be easy to ditch the dead one. This may be possible now by changing the number of units in the group, but if it is then I've messed it up and accidentally deleted the entire group. This one would probably be hard to add, but I'd like to see the ability to use additional 3D model formats and digital image formats for skins. As many of us want, multi-point polygon trigger zones, or (which I just thought of) the ability to merge multiple trigger zones, which would serve the same purpose. Actually, that's a better option because both polygonal and oval zones could be combined. The behind-the-scenes computing for this might be tricky. I'm a little familiar with the SVG image format, and I assume trigger zones use a similar method to mathematically define a shape. Complex shapes, like merged polygonal and oval zones, could require a lot of markup code. I sometimes run my own version of a dynamic campaign - basically one mission with multiple client aircraft located at multiple airfields, so that if one is destroyed, I want to fly a different aircraft or fly from a different location, it's easy to pause the mission, make the change, and continue on. Of course, any and all anticipated mission changes (aside from aircraft type, weapons load-outs and spawning airfield) need to be included in advance with late activation. Unfortunately, there's no way I'm aware of to do real in-game mission planning with waypoints, etc. Okay, enough words from me today. Dave

Hey gang, I've done the easy part - starting a looping radio transmission when entering a trigger zone. The hard part - stopping the transmission when I exit the trigger zone. In searching around I saw that it will apparently take a short LUA script to do this. Despite buying a LUA book and experimenting with it in DCS, I'm still pretty stupid when it comes to working with LUA. Extremely stupid, actually. Basically what I want to achieve is this - when I intercept an aircraft I want a warning to play that tells them to get out of Dodge by noon or I'll shoot 'em dead in the dusty street. Well, you get the idea. Once I'm out of the trigger zone I want the looping radio transmission to stop, and if, later in the mission, I re-enter the zone I'd like it to start again. I found a reference for doing this via a Google search earlier today and now I can't find it. If someone can either tell me where to find that information or if they can give me a hint here, I'd really appreciate it. EDIT: I do have an inelegant solution for this - a series of trigger zones along the planned flight path, each playing the radio transmission once with no looping. The only operational consideration is that I'd need to fly at a speed low enough for the sound file to stop playing before I reached the next trigger zone. That can, of course, be controlled to some degree by the size of the trigger zone. A couple of other things... I've noticed that when setting up a triggered radio transmission, the OGG file doesn't play in the dialog box where I choose the file. It's not a big deal at all, but I'm wondering if anyone else has experienced this. Also, I've been creating some interesting "degraded" simulated radio transmissions using Audacity and an online text-to-speech website that allows the choice of multiple accents and male or female voices. Dave

Thinking back, I didn't really explain it clearly. Oops! Basically, it keeps the same mission file running, but it pauses after a certain amount of time so that not only can you hop into a new airplane, all the assets and time itself will stop. (Quantum physics!) Then once you're in a new airplane (or the same one, for that matter, as long as you haven't crashed it) and you un-pause, everything continues as if it were a caveman thawed out of a block of ice. So you can create a single mission file that can run until the sun goes supernova - there's literally no limit as to how long one of these could run. The only limiting factor I can think of is once the last unit (AI or client) is dead there's nothing more to do. The nice thing about this is there's no need to write the positions and damage conditions of the units to file, that's then read back into a new mission that took off where the first one ended. You could also combine more than one of these extended mission files into a campaign. And if you wanted, you could even opt to not fly for one or more timing cycles (whatever interval you want - one hour, 90 minutes, two hours, etc.), just letting the AI do its thing while you sleep. Another thing I wasn't clear about is that I chose a 90 minute cycle between pauses, which roughly correlates to the length of a carrier aviation cycle. (And some may not know that aircraft in the second cycle launch before aircraft from the first cycle recover - that minimizes the number of aircraft on the deck that have to be respotted, armed, etc. The only time the flight deck is completely packed is the period between the recovery of the last cycle on day one and the launch of the first cycle on day two.) Often (at least in the glory days of the 1980s) gas-guzzlers (pretty much anything except Vikings and Hawkeyes*) would fly a single cycle - launch at 0600 and be back on deck around 0730. That doesn't mean those aircraft can't fly multiple cycles - more external tanks and aerial refueling are there to ensure you get a nice case of hemorrhoids. (Ejection seats only have about a half inch of padding.) Vikings, and I assume Hawkeyes, usually flew double-cycle missions - launch at 0600 and be back for the 0900 recovery. *We also had an A-3D in our airwing - I don't know how many cycles a typical mission took, but I would guess two because they probably carried a lot of gas. And because they didn't have ejection seats (nor do Hawkeyes, obviously) the seat cushions would be thicker. I don't know of any E-2 or A-3 guys with 'roids.

I just noticed two areas delineated in yellow on the Roosevelt flight deck, one pretty much enclosing elevator three and one just forward of the crotch. What are these, arming and de-arming areas? I made two cruises on Vinson while I was in the Navy, and made three trips out on carriers as a civilian (Vinson, Nimitz and Roosevelt). I didn't spend much time looking at my feet except when I was in a FOD walkdown. I didn't check other carriers in DCS, and yes, I looked in the manual but I missed it if it was mentioned. I didn't see any images with these in an image search on Google. Dave

Hey everyone, This may be old news to a lot of you, but I found a simple way to achieve mission persistence using triggers. In my test, I had a Hornet in the air and one on the ground. I had an F-15C going at max speed so I could watch it in the F10 view to make sure it was continuing on and not starting from the first waypoint. I pretty much only fly the Hornet, and in naval aviation a carrier flight cycle is roughly 90 minutes, so I'm going to set my pauses for that duration. Here's how to do it: Create as many client aircraft as you'd like, starting from anyplace you'd like. (I haven't tested it yet to see if multiple aircraft will crowd each other on a carrier flight deck, but since only one client aircraft at a time exists I would guess that it won't be a problem.) Create a trigger Column 1: Mission start Column 2: (skip) Column 3: (named) Flag on Create another trigger Column 1: Repetitive action Column 2: Time since (named) flag - X number of seconds (5400 = 90 minutes) Column 3, first item: X: Set command with value: 52 and -1 (negative 1) Column 3, second item: (named) Flag off Column 3, third item: (named) Flag on Then begin your mission. After X number of seconds the mission will pause. At that point, hit the Escape key to bring up the menu, then Choose Slot and continue the mission. The AI units should all be continuing from where they were when the mission paused. Then after X number of seconds the mission will pause again and you can choose a new aircraft. On and on... You'll have to either set waypoints for all the client aircraft in advance or figure out how you want to fly subsequent missions when you get to them. If you'd like, please test this yourself and let me know if you experience any problems. Thanks! (I may have actually contributed something of value here after all these months!) Dave EDIT: There's a minor blip, not even really a glitch, that I encountered when flying a full-length 90-minute flight - the pause didn't kick in until (apparently) the engines came to a complete stop. My 90 minute timer paused at about 113 minutes. Not a huge deal and it doesn't really have an effect on the usability.

In other words, although I understand the Campaign Builder interface, I don't quite understand how best to use it. It seems to me that persistence from mission to mission would be what really makes campaigns work best. Right now it seems that the missions in a campaign are relatively unrelated - the outcome of Mission 1 doesn't drive the situation for Mission 2. So does anyone have suggestions about how to squeeze the most out of the Mission Builder? I know it's a wide-open topic, one that could easily take dozens of written pages or a few hours of video tutorials. I see small parts of the whole being addressed, like the nuts and bolts of using the interface or the little finishing touches that can add to the realism, but has anyone done much about the actual logic behind creating a campaign? Thank ya'! Dave

And enlightens users to the fact that it resides there? I'm not trying to be argumentative, but I generally don't look through the folders when I install software. I guess I should.

I finally found the manual online, but not in a very logical spot. (See another reply here for details.) While having a manual in that folder is great, it's not necessarily an obvious place to look. Personally, I think the manual should be prominent in the support section of the website. That manual describes the core functionality of DCS, unlike the more specific aircraft manuals, etc., and since that manual would be used by all DCS users it should be easy, easy, easy to find.

God d*** and the FN can be read phonetically, as effen'. I finally found the DCS manual. Logically, it's in the Documentation section of the website. Illogically, it's on page two instead of the first page. Illogically, the search function only lets you search for aircraft manuals, and that led me to believe that section only had aircraft manuals. I'm sure a lot of people will think I'm just a whiner, which is okay. However, I spent several years writing and illustrating manuals for complex IT equipment, and I made sure I created them with as little ambiguity as possible. I tried very hard to look at it from the end user's perspective, asking myself what might be confusing and what information that's required might be accidentally excluded from the manuals; too much information is better than not enough information. That was for IT professionals. DCS is a consumer entertainment product, and things should be set up for consumers for their entertainment, not to increase their workload. This isn't about the complexity of the product itself (although I see plenty of things in the Mission Editor that could be improved), after all, aircraft and military operations are complex, and realism is the driving force behind DCS. But the complex nature of the simulation needs to be balanced with clear, easy-to-find documentation. (And personally, I believe a lot of basic things that require LUA scripting should be handled within DCS itself.) Do consumers use DCS for entertainment or as an unpaid part-time job? Exactly. I agree. For the most part I'm okay with videos handling some of the documentation, but that shouldn't be the bulk of it. And here's something to consider - people who are vision impaired wouldn't be using DCS, but hearing impaired people very well could be, and video tutorials leave them out. I realize the folks at ED are working like crazy to make things great for us, and I appreciate it, but in that effort to give us massive reality in the simulations they seem to have left the documentation work in the dust.