MeerCaT

Ok I'll check again with different aircraft. I was in a Huey, sat behind a very big mountain about 150nm or more away from the 'beacon' transmitting at 1W power. I'll try some more places and aircraft. Cheers.

I've been playing around with the "Set Frequency" advanced waypoint action, to allow units to emit a radio beacon. It's working fine (when paired up with a "Transmit Message" action, of course) ... little too fine in fact! I'd like to set up a very weak/shot-range beacon but I'm finding that the minimum range that can be achieved (at a power of just 1 Watt) seems to be around 200 nautical miles; this covers the vast majority of the 'populated' area of the Caucasus map. Power settings of less than 1W (e.g. 0.1) don't appear to have any effect different to that of 1W (this is the minimum possible?). Terrain and buildings also having no effect on the signal of course, but we know that already. Does anyone with more experience with this have any advice? Thanks.

Hehe, quite right; I just tried it and it lasted a whopping 1m 30s! :) (Is there no resupply mechanism available for infantry units?)

Thank you for the info; everyday is a lesson :) I think you're right, "uncontrolled" probably isn't quite the right tool to be involved in this job. What I'm probably looking for, in an idea world, is simply a 'shutdown' command that could be issued to an AI aircraft. Oh how we all dream of these 'ideal worlds'! :) Sure the aircraft selection mechanism (when aircraft have been configured as being a "client") is at least a fall back option, but again it doesn't quite hit the mark. For example, these aircraft don't exist in world until having 'selected' them to fly with. And of course the 'old' aircraft disappears. Also it may not always be desirable to have all aircraft available to the player when initially entering the mission. I'll keep looking into options for achieving some vague approximation of the desired effect. Compromise is the order of the day :)

I'm really no expert at mission editing/scripting etc, but one idea that comes to mind is to artificially 'simulate' the battle until such a time that you're ready for units to start getting killed, and so allowing the battle to eventually come to an end. This can be achieved by making the opposing groups 'invisible' to each other (so they won't actually shoot each other), and also assign each group a waypoint action of firing at a point in the vicinity of the opposing group - (making it appear like they are actively firing at each other). Wait of course, even more simple: how about making both opposing groups immortal? (which probably ought to be done in the idea above too). They can then happily fire at will at each other but nobody dies until the almighty judge (you) flips the switch and turns them into mere mortals again. Advanced (Waypoint Actions)->Perform Command->Immortal Advanced (Waypoint Actions)->Perform Command->Invisible Advanced (Waypoint Actions)->Perform Task->Fire at Point Trouble is, this is all configured at design-time within the mission editor. I'm not yet sure whether these attributes can then be changed at runtime via scripting. I know I've seen some code in MIST for manipulating waypoints. In theory I reckon it's possible to simply delete those waypoints/actions thus removing the unit's immortality...?

Thanks. I've just tested it and yes it does seem to accomplish the desired effect. It's a little restrictive though, being only available from the 'ramp' position and, more importantly for my purposes, doesn't allow the player to 'take control' of the unit until 'ACTIVATING' it first - at which point it executes its "Takeoff from ramp" waypoint instruction. (Being available only in such a specific circumstance, I am curious what the intended use/purpose is of this 'UNCONTROLLED' feature? ) One purpose I have in mind for having units (helicopters) sat idle on the ground is to serve as a visible 'pool' of aircraft that the player can take control of at will and 'hot-swap' between them. I'm not seeing any way that 'UNCONTROLLED' could play a part in achieving this. We can 'ACTIVATE' via script, which seems to negate/remove the 'UNCONTROLLED' attribute on the unit, but I don't think we can ever get it back into that uncontrolled state again, can we? And regarding the player taking control, that's not possible through script either is it? (Related to this, but a separate question for another thread and day, is what to do with the aircraft we have just swapped out of when doing this 'hot-swap'?) I'm kind of just thinking this stuff out loud, but any suggestions welcome. Cheers.

(v1.5.7.10872) Hi all. Feels like this one is probably a very simple one, but I must be having a 'mental moment' because I'm just not 'seeing it' right now... How can we configure/script/instruct our AI helicopter friends to play "sleeping lions", "sit and be good" or do their best impression of a rock? What I mean is, start off and remain sat on the ground (or official airport/FARP parking) and work like a politician and do nothing at all of any benefit to anyone...ever! :) (Sorry, let me just slide this soap box out of the way) How can we spawn a helicopter group/unit on the ground somewhere and have it sat there nice and quiet doing nothing? The waypoint 'Types' available can be categorised as either 1) 'Be in the air flying already',or 2) 'Be on the ground initiating a startup/takeoff procedure'. Sure there's the 'static object' option but that doesn't then allow for any 'usage' of that unit at a later point in time. One obvious option is of course to start them off cold on the ground and turn off 'AI' for that group/unit using a trigger before they have chance to start flicking any switches and playing with their knobs: Place a new AI helicopter group on the map in the desired location Name (a.k.a. "Group"): MyNewShark Type: Ka-50 Pilot (a.k.a. "Unit"): MyNewSharkPilot [*]Create a new trigger Type: ONCE New Action: Type: GROUP AI OFF Group: MyNewSha...wait a minute! Why isn't it in the list?!?! Ok fine let's try the 'Unit' (Pilot) approach instead... Type: UNIT AI OFF Unit: MyNewSha...hmm really?! Not here either. Aha! I have an idea: Type: GROUP STOP Unit: MyNewSha...ok scratch that. Strangely (it's strange to me at least) MyNewShark and MyNewSharkPilot do appear in the available Group and Unit list for the GROUP ACTIVATE/DEACTIVATE and UNIT ACTIVATE/DEACTIVATE actions, respectively. It's not clear to me what the significance or meaning of this is. I can 'activate/deactive' my group/unit but I can't turn on/off its AI? How are actions these so fundamentally different such that one should be available for a unit and the other not? Please do come and take pleasure in pushing my face into a big fat custard pie that is "The Obvious Answer". I look forward to its sweet and familiar taste Cheers all.

Yes the 'hold' and 'invisible' (to enemy AI) should be good for certain scenarios. But when it is desirable to have the group/unit disappear completely (until required later again), would it be frowned upon to teleport (banish!:)) them away to a remote corner of the map for 'safe keeping'? (And also switching on AI invisibility and invulnerability, for extra safety) Are there any potential issues with this I've not thought about? If DEACTIVATE-(RE)ACTIVATE is not a valid lifecycle then this 'hidden banishment' could be the next best alternative for achieving 'disappearing-reappearing' units? What I'm specifically considering here are groups/units that have a configured route to follow and potential interactions with triggers and trigger zones. Or would it be better to get into the murky depths of spawning shiny brand new groups/units using MIST. Wouldn't that then require manually coded route configuration/scripting? I'm trying to keep my fingers out of MIST where possible and use vanilla Mission Editor features. (Who's that laughing at the back there?)

DEACTIVATED to death Ok thanks all. I've confirmed that MIST is indeed preserving group names during respawn (teleport). That's good news. Even better news (I think) is that I've discovered what I believe to be the cause of the issue: GROUP DEACTIVATE Don't do it! Not if you want to ever do anything with that group again...ever. (Like respawn and have it interact with triggers, just as a random example off the top of my head). This is probably a well known fact within the 'building' community, but very not well known to me :) (That is until the last day and a half of 'education' on the subject) While I'm happy to have (apparently) found the cause of the problem I'm also a little sad that 'ACTIVATE-DEACTIVATE' appears to be a 'linear' one-time sequence rather than a 'circular' life-cycle process. (But in time I think I'll recover eventually) Just for fun (cause that's what I choose to call a day and a half of educational frustration) and your viewing pleasure, I've attached a very simple demonstration mission showing two identical trucks (you can see there's nothing up my sleeve, and I never use stooges), 'involved' in two identical sets of triggers, except one gets DEACTIVATED and the other does not. (Now if that's not what you consider to be worthwhile entertainment of an evening then I'm afraid there's nothing I can do to help you) (Note: it expects the MIST script file to be simply called 'mist.lua') Thanks again, and remember: never point a GROUP DEACTIVATE at anything unless you mean to kill it, to death. RespawnTest.miz

DCS v1.5.?.? MIST v4.3.74 Possibly it's just me doing something silly, but maybe someone knows whether this is 'correct': An AI ground unit (group) respawned, using MIST, no longer activates any (switched) triggers when entering the corresponding trigger zones again. (Triggers that do successfully activate, multiple times, prior to the group being respawned) My first thought was that possibly the MIST 'respawnGroup()' function might be assigning a new, dynamically generated, name to the respawned group (thus the trigger no longer 'matching' on group name). But a brief glance through the LUA script suggests that it probably is preserving the original group name. So what else might be breaking the trigger condition? Thanks.

Just a small point I thought might be worth adding: DCS allows multiple 'modifier' buttons to be applied at the same time for any given command (<modifier_1> + <modifier_2> + <some_key>). For my X52 setup I have assigned two modifier buttons: the 'Pinkie' button, and the 'Clutch' button. This allows almost every button on the HOTAS to be reused for FOUR different functions. (1: button, 2: button+modifier1, 3: button+modifier2, 4: button+modifier1+modifier2) It makes it challenging trying to keep a note of all these assignments :) (I have a pretty cluttered paper diagram illustrating each of the numerous commands assigned to each of the different buttons)

Yeah, I seem to remember a while back (in standalone BlackShark) discovering the ever-so-slightly dodgy physics concerning contact with buildings :) Here is an old thread containing a funny little track I uploaded about it: (I wonder if old BlackShark track files work correctly in DCS:World? - Can't test it right now) http://forums.eagle.ru/showthread.php?t=82497 Hats off to all those people (3 of them ...4 maybe?) who are able to hold anything resembling a steady hover in this rusty old tin bucket! :)

Just though I'd share something I stumbled upon today; this is an excellent read for those interested at all in military aviation: http://www.neptunuslex.com/rhythms-the-compendium/ Jump straight into a nice bit of the action: "Part XXIX Troops in contact" :book:

I thought for ground crew operations (rearm, refuel, repair) all you need is for the airbase to be assigned to your coalition (reb/blue)? You've got me questioning myself now, but I'm pretty sure that's all I've had to do in the past - just set the airbase to the appropriate coalition (within the mission planner) and then all ground crew operations are 'active'. No placing vehicles required. This is all part of the resource management aspect of the strategic side of the simulator gradually being incorporated. Airbases can have finite quantities of 'resources' (aircraft, fuel, ammo etc) that must be managed. This is all infinite by default, so once it is assigned a coalition you instantly have infinite resources available to you at that base. Unless of course I've misunderstood something?

Having just built a new computer, I am now looking to get all the fun stuff installed on it. Since my broadband isn't all that 'broad', I'm kind of reluctant to download the 6-7GB of the very latest DCS World installer files, but I already have the DCS World 1.2.1.xxxx installation files from some time ago. So I was just thinking, do you think it would work to install the old version 1.2.1.xxx, and then perform an automatic update to bring it into line with the current 1.2.4.xxxx? (Theory being there will be considerably less 'gig-age' to download) I did in fact try this last night, but the "Checking for updates..." dialog came and went, clearly without actually doing anything. (And yes, the Internet connection was up and working at the time :))

> remapping keys Most games (DCS World certainly does) save these settings in a separate file that can simply be back-up and copied across into the new installation. > remembering all my passwords Every password for every account you have EVER created should be recorded somewhere anyway (in a secure, protected file somewhere, or just a little notebook under your pillow) > couple of programs that I lost the keys for Before wiping your current system, it may be possible to retrieve the serial keys for some of your programs from the Windows Registry. Search the internet for specific details about this for each separate application. Things usually have to get worse before they can get better. Before you enjoy the pleasure, first endure the pain. <insert_favourite_cliche_here>

The Earth has aligned with Saturn and it's 34th moon "Tarqeq", the lesser-spotted twigglewit bird is dancing his funky wiggle, and an another event is about to occur that is even more rare than those two combined: the grand opening of my wallet to spill a few coins in exchange for shiny things. That's right, its PC upgrade time. Well actually, it's "bring out your dead" and chuck it all away - we're starting again from scratch ... time! And since I'm willing spend a reasonable wedge of notes (mere 'spare change' to some people, I'm sure) I feel its worthwhile opening up to advice from you knowledgeable good fellows. Here's where my search for "shiny bits" has lead me so far: CPU: Intel Core i7 3770 - ~£200 (2nd-hand) RAM: Corsair 8GB DDR3 1600MHz Red Vengeance Memory (2x4GB) - £65 Graphics: Gainward GTX 460 1Gb [re-use existing one] - £0 Mobo: Asrock Z75 Pro3 Socket 1155 - £70 Sound: [onboard 7.1] - £0 SSD: OCZ 128GB Vertex 4 SSD - £100 HDD: WD 1TB Black Desktop Drive - £70 PSU: Corsair Gaming Series 2013 Edition 700 Watt - £70 DVD: Lg Internal 24x - OEM - £15 Case: Silverstone Raven RV02B-EW - £130 Windows 7 Pro 64-bit - £40 Peripherals: [re-use existing: Saitek X52 + pedals, TrackIR5, Medusa 5.1 headphones] All the above currently totals nearly GBP800 (~USD1200), but I'm holding out until it drops closer to around GBP600 (~USD900); hopeful that the impending Intel release will see a price drop on previous gen CPUs, an dI've heard there are some new graphics cards due out soon too. Thoughts, comments and recommendations greatly received.

On loading of the P-51D "Landing" training mission I found all flight instruments in the cockpit to be blackened out, and were only visible while zoomed in extrememly close. It has happened a couple of times to me in the past (I am now on 1.2.4 and previously 1.2.2) but restarting the mission and/or application usually fixes/removes the issue. Just wondering if anyone has any thoughts on this? Some kind of Dynamic lighting effect gone bad?

+1 to Irregular programming (and I'm not just talking about my software development style). TrackIR is a great addition. A touch overpriced, in my opinion - but that's only because the company knows they can get away with it. (Same with all market leadering companies) Yes the 'clip' is made from brittle plastic, but even though mine broke (like many/most do?) it's nothing a blob of blue-tac couldn't fix and it still works perfectly fine. The weak link in the chain seems to be the way the 3-pronged infra-red LED 'fork' is connected to the 'clip' unit. It is designed in such a way as to allow the angle of the LED 'fork' arm to be adjusted (angled higher or lower). But having found a suitable position For myself, there was no reason to have this adjustable any further. for this reason I'd probably recommend finding the desired position and then permanently gluing it into place to help strenthen it. (I keep meaning to replace the blule-tac on mine with some solid glue, but never seem to get around to it). I've never used the alternative 'reflector' clip (I don't even own a cap, so I have nothing to fit it to) but I'm sure it works fine.

Might be touching ever-so-slightly off topic here, but I've recently been told about "Windows Blue" (some referring to it as Windows 8.1 'update') as being a significant improvement over Windows 8. Windows 8, I'm told, was just a stepping-stone into this operating system paradigm shift. I can't truly comment myself since I've not actually seen anything about this new version/update, but I've already decided I'll be skipping 8 and jumping straight to '8.1'(?) - probably wont be released until next year, is my guess. The big question (for me) is: will I be able to get in the Huey with my lowly 32-bit system? I really want to wait until 'Blue' before doing my full system upgrade but there's little chance I could resist the temptation to upgrade until next year knowing there is a Huey sat waiting for me! The other big question: will the huey come with a built in "Ride of the Valkyries" sound track?! :)

Not wishing to hijack here, but it's quite closely related... I've done my fair share of 'playing around' with the hog and, only yesterday in fact, I deliberately did the same thing at 13,000ft in the "Weapons Training" standard mission. (Oh I've just remembered, this is a total tangent but I'll mention it anyway: I did this after attempting air-to-air refuelling, which kept failing because the tanker would connect and then disconnect with the 'complete' message all in an instant the very moment contact was made, without transferring any fuel, and would veer off to the left as if to get out of my way. I'm reasonably ok at refuelling and I know the usual procedures and nose-wheel steering button thing so I don't think I was doing anything wrong?) ...Anyway... After starving the engines of fuel due to being upside down they cut out, I dropped and switched off both throttles, started APU, turned off left and right generators, turned on APU generator, spooled up left engine, spooled up right engine....wait a minute, what's this? Right engine never reaches idle speed!? 'Motor' the right engine for a while, then try normal start-up again but no difference. Ok so I limp home on one engine, but even that seems a little under powered compared to usual (yes I do often limp around on one engine - a testament to my SAM dodging skills...or lack thereof!). So engine restart problems (but only for one engine) after a fuel-starvation cut-out; any ideas what was happening here?

Excellent work guys, thank you; that hit the spot :) Interestingly, the "SPU-9 PTT" entry in the controls list was blank/disabled in the 'Saitek Joystick' (my controller, obviously) column. Meaning I was not able to assign this action to any of my HOTAS buttons; well not through the GUI at least. Instead I had to manually add the appropriate entry to my Ka-50 controls LUA file. Anyway, it looks to be working now so thanks again for the nudge in the right direction. Now then, I wonder if my spandex flightsuit still fits me...

Here's an odd one for you. (May or may not be specific to the BlackShark, but I've not experienced anything like it with any other aircraft) I have a [modifer]+[button] HOTAS assignment for the 'Communication Menu' action. (i.e. radio menu) This action works fine while on the ground, but as soon as takeoff is performed this button assignment becomes 'inactive/disabled/lost/null'. Land again - it works. Takeoff - it does nothing. :joystick: I've always used this same button assignment, and since it works while on the ground I don't believe there is any issue with the assignment configuration or the physical HOTAS equipment, or anything like that. Has anyone else had experience of (or can anyone suggest a plausible explaination for) this change in control behaviour between gounded and airborne 'states'? Thanks

The SSL certificate for lockon.co.uk seems to have expired nearly a year ago (unless my Internet connection really is being fliddled with by a thrid party!) I expect the number of people using the 'E-shop' at lockon.co.uk is probably pretty low these days (superceded by digitalcombatsimulator.com). Is it not worth the fee for renewing the SSL cert?

I see what you mean. Kind of clever sneakyness! :) So there's no official 'refuel' task. And come to think of it, no 'rearm' either I supose. Shame. Ok thanks.