fargo007

SteamVR beta broke last night, and I could not get it to work. Compositor 306 and 400 errors. Some investigation led me to just dropping out of the beta, and everything worked again. But how? So just so everyone is aware, the SteamVR beta works very differently from the way DCS and DCS OpenBeta work. In DCS, they are different code branches. In SteamVR, the beta is simply the newest version standing in front of the production one. Each production one itself formerly the beta. So coming out of the beta at this point puts you right back where you were before. What was formerly beta is now production. I hope I'm making sense here.

The problem I had was that I could spawn a single infantry easily and make him a JTAC, but after that he was no longer transportable via CTLD.

Thanks for doing these monthly videos. They are very much appreciated and I watch every one of them. The transparency you are providing into the actual bugs being tracked and worked is AWESOME. Couldn't be more transparent. I dare to call it a model to be followed. Bravo!

What did you come up with? This is interesting.

A line of code isn't equivalent to a trigger. It just doesn't work that way. A line of code can be equivalent to one, ten, or twenty triggers. And not all scripts are created equal. There are good and bad scripts just like good & bad triggers. The multimissions we run on our servers have some ~2000 lines of code, plus CSAR, CTLD, cmws and many others and among over 50 mini-missions where every single aspect of the AI is fully randomized. The type of enemy, their location, their route, their quantity, their skill, ROE, formation, state, destination... everything. Absolutely nothing fails to work and they run for several days at a time until someone restarts them or loads a different miz. Aside of the functionality you just can't accomplish with the ME alone, the time it takes to put all that together and test a gordian knot of triggers is among the principal issues here. It's a fraction of the time commitment, and testing/debugging it is super simple and lightning fast. In fact, seeing different aspects of how DCS operates through MOOSE/Mist/native lua script development has increased my understanding of not only DCS, but how many features in the ME work. The reason that we're suggesting a script to accomplish this isn't to steer people away from using the ME. We all use it. It's that Moe would be done with this and flying by now. There are a lot of us here who cheerfully assist people with debugging their scripting all the time. It's never been easier to learn what { : and # mean. There are even DCS-specific videos on scripting, MOOSE and all underlying aspects. Dozens and dozens. I used to do it exactly like you're now doing it until I decided to learn, so I know exactly what's involved in both approaches. And with that in mind, I would urge you to reconsider giving the stiffarm to what is undeniably the most powerful aspect of mission development available to us. I'll even help ya.

It's astonishing that the effort you guys are spending on this rats nest of triggers is greater than it takes to actually learn how to write a simple script to do this. MOOSE has classes that randomize the ever loving stuffing out of every possible thing. Moe - can you make a simple flow chart of what you want to happen here?

I'll pick up the tomcat for sure event though I'm a rotorcraft guy, but there's just something about this one that makes me want it even more. I know a guy who was a crew chief for one. He spoke very very highly of it.

The way it's set up it's honestly too confusing for me to comment with authority but I don't think so. It looks like you are manipulating *all* of the flags regardless of which unit is killed. I'm suggesting to have one flag that is set to a random value whenever a unit is killed. Have a switched condition watching that flag and activate whatever group you want based off a TIME_SINCE_FLAG condition. I'll stand by the remark visible in the bottom left of your screenshots. ;-) This would be 25 lines of code or less.

I looked at it, and there are a lot of very basic architectural things wrong with it. #1 of these: --- You are not loading MOOSE at all. No wonder why it's not working. It has to be loaded as the first trigger as MISSION_START. After that, as I wrote before, should be all your spawn declarations in a single script. Trigger #1 - Load moose as MISSION_START Trigger #2 - Load the moose script with all your moose stuff in it as MISSION_START Trigger #3 - Load Mist with a TIME_MORE of 3 seconds. ... then all the rest. Also pointing out that you should be loading mist on its own trigger with a TIME_MORE condition.

This isn't a simple scenario, and you're into script territory with layers of randomness & probability involved. You could try setting a certain flag to a random value on destruction of a particular unit. Have a switched condition for each possible value watch that flag. If it equals 1, spawn enemy1. 2, spawn enemy2.... etc. Then reset the flag The problem here is that you will have a metric ton of triggers and you'll need a set of them for every enemy. This is why a script is a better choice.

I can't open it because I don't have the A4. When requesting assistance it's always a good idea to distill the issue down past all the mods to make it easy for people to comment and see the issue. Some thoughts unseen: Make sure MOOSE is the first thing loading, and in a MISSION_START trigger. Second, Make sure your script is the second thing loading, also in a MISSION_START trigger. No conditions on either. I point out that what you want do do if you want the spawns to begin on a trigger is (in this case) NOT call :SpawnScheduled() in the script but in the trigger (DO_SCRIPT) itself. e.g. Scramble01:SpawnScheduled(30,.5) You are starting the spawn as soon as you call SpawnScheduled(). Your spawn objects should also be declared as local in the script. There should also be one script. There's no reason to separate each spawn into a different lua script of its own. Just list them all one after the other.

Here's a video of one IRL being hit by a manpad, and continuing on like it doesn't care. I also agree it has a damage model that leaves it out of balance with the other helicopters in DCS at the moment. Looking back at the tracks, a single ak-74 burst of seven rounds will bring you down pretty reliably. Now - that CAN happen I suppose, but it should definitely not be "likely" or as it is now "almost certain." And not only in the Mi-8. I'd fly it a LOT more if this were brought into balance with the other helos.

Here's an example of the round camp, with a (ranger pack mod) barbed wire rim around it. You just tell it where to put it (zone), how many infantry to stick in there, and what group you create is to go inside. The outer guard vehicles you define (towers here) are groups, so they will engage enemies as you set their ROE.

thanks, I don't own that, but should be possible. If it's a 25M segment, it's a direct replacement.

It's probably not what you want to hear, but a script employing MOOSE or Mist could do this so much cleaner & easier. If this is the type of thing you are going to be doing in the future, maybe it's time to drive straight in, instead of a very, very long way around it. There are so many tutorials now, it's never been easier.

I'll confirm that. The lights in that mod pack are excellent and you'll see them from far away too. They are uncontrolled though. On all the time at night.

I put together a square camp generator that builds a 200M square frame of barbed wire with towers every 100M on the perimeter. It's a function, so you can call it with a variety of content options for the vehicles on the perimeter, or on the insides. They are all static objects. It's built around the dead center of the zone you create, so you can populate the contents as desired. Once loaded, it's called via a DO_SCRIPT trigger, where you pass it the parameters you want. e.g. 1 - The zone name. 2 - If you want vehicles inside, or empty. 3 - The outer guard vehicle identity. 4 - The country that owns it. 5 - The name of the vehicles to put in the middle (like a parking lot) It's also the perfect size to put a FARP in the middle, and does all the work of placing the objects around the edge. There's one in the example mission. It uses MOOSE, and the barbed wire from Ranger Pack 2.4.1. Example mission (with the script inside it) attached. The script is commented with usage instructions and examples. Let me know if you like it. I am also publishing a no-mods round camp generator soon as well. /Fargo squarecamp.miz

Does it still say "SAFE" on the armament control panel when AGM is selected? Check that. It didn't use to require a manual fusing but I've noticed that lately it does.

Voice attack is totally worth the small fee they are asking for it, and their support is excellent. I use it to drive extended functionality in the menus, where it walks the entire tree for me to conduct certain things like loading passengers via CTLD, requesting a signal flare for CSAR, etc. I also have the F-keys all bound to "Fox One" through "Fox Twelve." So I can just say it, and it chooses it for me. I can walk the menus manually this way. Immersion wise, it's also great for helicopters like the Mi-8 and Huey. The pilot doesn't push every button and turn every knob himself. He relies on the crew. You can mimic this in VA easily. "Ivan, collision light on!"

Thanks - that diamond was exactly what I was looking for. I want to try and understand more of the info on the TPOD itself next.

Love this, and our next training Tuesday is focused on JTAC with rotorcraft (5-Line) in fact. I would like to see some text on screen while the comms are running that shows which portions of the comms flow are being discussed or read out. It's very easy to get lost in it. e.g. pop up a message that basically says what the pilot or JTAC is saying, and which portion of the dialogue it is from. By all means keep on going, because this is AWESOME, and an often ignored area of tremendous realism that is available in DCS right at our fingertips. Bravo!

I'm sure the A-10C folk have done this, but I've found a lot of money in hunting laterally with the TPOD. Think of flying to the left of a long island, and looking down and to your right at the island, scanning for targets. When you find one, you roll in. It can be challenging to keep SA in this approach in terms of where you are looking. Although I'm effective this way, I'd love to see a "How to hunt" tutorial on this to pick up some finer points. I also don't think all the TPOD symbology has ever been explained. For instance, in the A-10C, you know exactly where the tgp is looking; you can see it on the map. Is something like this possible in the Harrier?

Does anyone have a workaround for this that operates successfully on the PG map in 2.5.3? The behavior is reproducible here, but not in caucasus. The spawning of any ground vehicle generates a client wait state where they are looking at an hourglass, a screen freeze or whatever message their VR headset displays. Everytime it happens, you have (n) pilots chattering that "I have some kind of big lag spike....." and some of them crash through (this time) no fault of their own. Using MOOSE, with :InitLimit(n,n) and :SpawnScheduled(n,n) I experimented with scoping the variables as local or not, and when the SPAWN: declaration is made local, there's no spawn at all, and it outputs a message that it's scheduling the spawn of an obsolete group. I also have a copy of every enemy ground unit in the mission alive on the map elsewhere. Would really like to resolve this any which way, but if someone else can still reproduce after a bit of hacking at it, I think it's time for a bug report. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ETA - I was able to dramatically minimize this by making the SPAWN: declaration local and by making the :SpawnScheduled(n,n) call non-local. I'm not sure why this worked, but it definitely did. Does not spawn: local apc = SPAWN:New( "apc") :InitRandomizeZones(SamZones) :InitRandomizeRoute(1,5,3000) :InitLimit( 4, 360 ) :SpawnScheduled(2,1) Spawns with unacceptable (enough to crash your plane) lag: apc = SPAWN:New( "apc") :InitRandomizeZones(SamZones) :InitRandomizeRoute(1,5,3000) :InitLimit( 4, 360 ) :SpawnScheduled(2,1) Spawns with almost imperceptible lag most of the time: local apc = SPAWN:New( "apc") :InitRandomizeZones(SamZones) :InitRandomizeRoute(1,5,3000) :InitLimit( 4, 360 ) apc1 = apc:SpawnScheduled(2,1)

I also feel like the MSAA is necessary so I kept that, ditched shadows and I can PD up to 1.5 and stay buttery smooth. I can also spot ground targets VERY far away with it like this.