LostOblivion

The conditions in your trigger will eventually be true, and the group will always be activated, although it will only be activated once. In other words, this trigger is useless in that it does exactly the same as activating a group at start. To convince you this is the case, I invite you to try the following trigger. I have not tried it myself, but I am pretty sure the group will be activated eventually, although it might take as much as a couple of minutes before Random picks something that rare, seeing as Once appears to run every second or so. Once; Random(1) And FlagIsFalse(Flag1); GroupActivate(Group1), SetFlag(Flag1) I wrote this in my previous post. You want to randomly set a flag using MissionStart and then check that flag later along with whatever rule that triggers the event. An example would be if you want to activate a group at 10 minutes with a 50% chance of spawning, you'd want the triggers below. MissionStart; Random(50); SetFlag(Flag1) Once; FlagIsTrue(Flag1) And TimeMore(600); GroupActivate(Group1) But I agree, Once is misleading, and I've used Random with it before unaware of this behavour. Not sure if Random has any good use other than in a MissionStart type of trigger.

You cannot use Random with anything other than MissionStart, because Once will run every second or so until the conditions have been met. This means that if you put say Random(33) And TimeMore(600), the engine will test those conditions until they are true, i.e., Random(33) will run until it is true. This means you will have you to use Random in a MissionStart type of trigger, which will only run once, at the start. I have a question. What is it you want to achieve?

This is my way of randomizing which one out of n groups will spawn. Only one group will spawn, each with the same chance to spawn. I do this with randomly located SAM sites in my missions. At each trigger, perform random with a chance of 1/n to succeed, where n is the total number of groups in this randomization REMAINING to be picked, and if it is true, AND Flag1 is false, then spawn a group, and set Flag1 to true. Do this for the remaining groups, one trigger per. Make sure to put them in order, or it will not work. Examples follow: Three groups: MissionStart; FlagIsFalse(Flag1) And Random(33); GroupActivate(Group1), SetFlag(Flag1) MissionStart; FlagIsFalse(Flag1) And Random(50); GroupActivate(Group2), SetFlag(Flag1) MissionStart; FlagIsFalse(Flag1) And Random(100); GroupActivate(Group3), SetFlag(Flag1) Six groups: MissionStart; FlagIsFalse(Flag1) And Random(17); GroupActivate(Group1), SetFlag(Flag1) MissionStart; FlagIsFalse(Flag1) And Random(20); GroupActivate(Group2), SetFlag(Flag1) MissionStart; FlagIsFalse(Flag1) And Random(25); GroupActivate(Group3), SetFlag(Flag1) MissionStart; FlagIsFalse(Flag1) And Random(33); GroupActivate(Group4), SetFlag(Flag1) MissionStart; FlagIsFalse(Flag1) And Random(50); GroupActivate(Group5), SetFlag(Flag1) MissionStart; FlagIsFalse(Flag1) And Random(100); GroupActivate(Group6), SetFlag(Flag1) The first FlagIsFalse test and last Random test may be omitted. If you want to do the same thing, except for events happening later than mission start, e.g. activate group at time t, you can replace Flag1 with numerous flags, each mapping to separate events, then in the following trigger, test whether the previous flag was set. Randomize the events: MissionStart; Random(25); SetFlag(Flag1) MissionStart; FlagIsFalse(Flag1) And Random(33); SetFlag(Flag2) MissionStart; FlagIsFalse(Flag2) And Random(50); SetFlag(Flag3) MissionStart; FlagIsFalse(Flag3) And Random(100); SetFlag(Flag4) The last Random test may be omitted. Perform the events: Once; FlagIsTrue(Flag1) And WhateverRule(); PerformEvent() Once; FlagIsTrue(Flag2) And WhateverRule(); PerformEvent() Once; FlagIsTrue(Flag3) And WhateverRule(); PerformEvent() Once; FlagIsTrue(Flag4) And WhateverRule(); PerformEvent() Having said that, I agree with the fact that it would be nice with a cleaner way of doing this, where flag functionality could be extended to include more integer operations and boolean expressions.

DCS doesn't like tab.

What's the word on the next patch for the hog?

Awesome mission. Me and my friend played it last night, and again today. We really enjoyed the intensity of it, which really works with the set payload. Also, authentic voice comms! Good work! More like this, please!

If you're buying it specifically for DCS: A-10C, then yes, the hog is worth it, but if you're flying a lot of other flying games as well, then I'm not sure. The hog has more buttons than the X-65, but what makes the difference is that everything is where it should be on the hog, whereas for the X-65 the buttons will not always be intuetively positioned for the A-10. You also have to take into consideration that the X-65 has force sensing, which means the stick does not move. For modern aircraft like any fighter and the A-10, it's ok, but it feels weird for games modelling old planes, like Il-2, or Rise of Flight. Having said that, I have the hog, my friend has the X-65, and we're both just as happy when flying in DCS: A-10C.

I've found having many aircraft in the vicinity of the camera gives a lot of overhead in terms of GPU.

How do I map my joystick buttons to the radio keys? :/ Do I need like a joystick->keyboard emulator or something?

This will probably get implementer sooner than later by my guess. It's an important feature.

It also helps getting the hog up to about 5000 knots before firing. :)

Thank you for the positive feedback, Sessine. I'm aware of the JTAC issues, but I'm afraid all of them has to do with bugs in the game actually. The JTAC dialogues are a bit buggy in the current release (1.1.0.9). I have a WIP on a new mission called Op DOUBLE CROSS, featuring a large battlefield scenario involving three airfields and several phases. It's coop 8. Unfortunately I haven't been able to work as much on it lately to finish it, but I'll post it here 'when it's done'™. :)

Will there be any updates as to DCSW in between to fix the various bugs introduced in 1.1.0.9?

My guess is that they revised some GUI in .9 and that they forgot to transfer some states between the GUI and the underlying system. Old missions probably have these settings saved correctly.

+1! Genius! Haha...

This is a good read. :) http://usmilitary.about.com/cs/airforce/a/aforganization.htm

You have an entire squdron escorting a C-130? :D :P A squadron is pretty large, you probably mean a flight. :)

Hi, I am currently looking for people in Norway that plays this game and would like someone to play with, maybe even create a VFS. We are two at the moment, and usually play between 18 nd 24 h local time. Post here if you are interested. ;)

What is the thing with the 23d TFW England AFB skin? I mean, all the others are Fighter Squadrons, not a skin for an entire Wing... ? And it does stand for Tactical Fighter Wing right?

I AGREE!!! This would def be something I'd like to see too. The only problem I see here is that rotating them should be possible to do for both individual and the group as a whole. +1

I'm looking for a VFS. Will it be 112th VFS then, Rossi? Had a good time today. :)

Engage Targets is is currently bugged. How to replicate: Create an apache far from the target (~8 nm), create a wp close to a ground target. Remove its CAS role. Add Engage Targets. Run the mission. You will see the apache following its route not engaging. Now open its Engage Targets task, deselect AIR, then select AIR again. Run the mission. The apache will now engage the target. There is a bug having to with connecting the actual target selected in the mission editor to the simulator. It appears Engage Targets will not set these properties properly until you actually flick some of the radio buttons (like I did now, turn them off, then the same buttons on again). Same thing with Engage Targets in Zone. Same thing with SEAD. Same thing with CAP. Another bug: They do not respect the maximum range. Well, "semi" bugged, rather an implementation error. As long as any distance between a target and any leg of the route is shorter than the set max engagement distance, they will fly straight to that target, ignoring the 50 waypoints between them. Intuetively, max engagement range should be a measure between the vehicle and a target, not between the route and a target, IMO. At least when the aircraft is in "following route mode". I understand how the vehicle-target distance method can lead to trouble, say, if it took a diversion to kill a target, it would suddenly come in range of other targets the mission designer didn't intentionally mean for it to kill. At least if doing the route-target distance, queue that kill task after reaching that waypoint of the part of the leg that is close enough to a target, instead of queuing it straight away at the start of its life, 50 waypoints away, like it is now. But I am happy now, because I know there is a workaround. :) And thanks a lot, ReOrdain! I really haven't used ROE before, but in fact it is quite useful! :) Hope someone will find this useful...

What I usually do is give them a Fire At Point triggered action. Usually works, and most arty will commence firing within 2-3 minutes. Note that you have to use the AI TASK from within the trigger section to start the task.

I think it's because the mission creator put them too close to another unit, i.e. inside its hitbox. Try moving them out and see if they still move. Hawg 1-1, Krymsk, you are cleared for takeoff runway 22.

1 second bursts from 30+ down angle at 350+ IAS usually does it, even for a T-80, followed by an escape manoeuvre in both horizontal and vertical with the M program popping flares at 1 second intervals. The firing distance from target depends on the target, but usually between 0.7 and 0.5 nm for heavy armor and 1.5-2 for anything else, to reduce the threat from light arms fire.