MeerCaT

When setting up AI aircraft in a mission editor is it possible to have them land at an airport, refuel and then take off again and continue with its waypoints? Thanks.

'Snap-views' are a useful option for working with the side panels. I particularly use the RCtrl+0, 2 view to snap to the CDU panel.

Well sure, even more so in multiplayer when Pause is not possible. Just throwing options out there :)

The multiplayer menu background image; am I just looking at it in the wrong way or does it really contain some dodgy looking 'brushed' lines drawn in that seem entirely out of place?

If you are runing Windows 7 I find the Windows "Snipping Tool" very useful. It allows you to draw a rectangle to define the exact section of the screen you wish to capture. Just Alt-Tab out of DCS, start the tool and then Alt-Tab back to DCS.

Just to contribute my 2-pence of solidarity, I also experience this slow JTAC process in the default A-10C Georgian Hammer campaign. I don't think repeated requests are necessary. I tried circling for 5 minutes awaiting JTAC response to "ready for comments" and eventually he got back to me. Other times he still doesn't continue the conversation after 10 minutes. It is difficult to spot any obvious reason for this delay but I have a feeling it might (sometimes) be related to friendly AI units engaging the target that JTAC was in the process of reporting. If you're lucky the friendly unit(s) will destroy the target group and so JTAC will call "ABORT ABORT ABORT" and then proceed to start a new target assignment.

Yes sure, I would love to see 'splash' damage be much more effective, esspecially against soft targets. I get the impression the current damage modelling implementation is relatively lightweight, incorporating a simple Hit Points Vs Damage Dealt system; with Damage Dealt probably sharply decreasing with distance away from the epicentre of the area of effect. The issue of modelling damage can become very complex very quickly. It is entirely possible to concieve of a 'damage model' that is as detailed and involved as the flight model with its incredibly complex aerodynamics calculations. The physics and mathematics invovled is immense the closer you attempt to model the real world processes and interactions between objects. I think many strategy games over the years have come up with some elegantly simple ways of approximating the complexities involved in the concept of 'damage'. They often divide the concepts into a few basic categories, such as: sharp blunt explosive shock wave heat (radioactive!) etc. Then each 'object' in the virtual world has an 'armour' value for each category representing its ability to resist such damage, while each 'weapon' has a value for each category representing its ability to deal damage of that type. Then apply algorithms to calculate the NET effect of the coming together of these two entities to determine how much underlying damage is done to the target object, whilst also factoring in a sliding scale of effectiveness to incorporate distance from 'epicentre'. There is almost no limit to how deep and complex you could take this modelling if you wish. It is just a reflection of how truely complex the real world we live in is. The daring developers of a 'simulator' have to prioritise the many real world aspects they wish to incorporate into their virtual world and what level of detail they wish to take each aspect to. For a military flight sim what kind of priorities are reasonable? Flight model (aerodynamics etc) Aviation systems (cockpit bells and whisltes) Weapon systems (target tracking, ballistics modelling) Artificial Intelligence (friendly and enemy activities of many different units) Weather system Damage modelling 3D object modelling ('smoothness' and realism of object shapes) Visuals (ground and object textures, lighting effects) Audio (sound samples, sound effects) Networking (multiplayer) ...the list is endless Just a few thoughts for the day :)

I must admit, without understanding the immense technicalities and the different methods/mechanisms involved here, I can say I have never noticed any significant inaccuracy with the QFE callouts. Certainly not in the 1000’s. I have been training a lot of ILS/TACAN landings recently and I have not encountered any such issue. Have I just been lucky, or is one of us misunderstanding something here? Is it more prominent at certain airports?

Every soft target - not necessarily. Only the ones that actually get hit. :) But no I agree, we would all love to see a site of total devestation emerge from the huge blanket of explosion and dust that these things inflict on an area. Just thought of another good point: All of the CBUs contain a setting (accessed through the Inventory page) that determines how high above the ground they will 'shed their load'. ("HOF" - Height Of Function). If you use the default setting without changing it then this is usually something like 1500 ft (...or metres?). The higher the 'spreading' happens then the further apart each little bomblet is likely to be by the time they reach the ground, and if there is more space between each one then that leaves a much higher chance that one of your intended targets manages to 'slip through the net' and avoid getting hit directly. If you don't already, try changing this setting to 500 or 700 for a much tigher grouping of your little day-ruining parcels.

Don't forget that the 87's are completely 'dumb' bomblets that randomly scatter across the area. As Witchking mentioned, objects have an amount of 'health' that must be depleted before it will be considered 'dead'. It is possible that it takes more than 1 CBU-87 bomblet to destroy a tent (though I doubt that would be the case for tents). But either way, it is entirely plausible that a random scattering of bomblets would only score a direct hit on 1 or 2 tents within the area of effect. And if it really does require more than one direct hit, that would reduce the kill count even more. As for the 97 variant, as far as I understand these use 'smart' skeets that search for infrared heat signatures of armoured vehicles. I wouldn't have thought a tent would necessarily show as a viable target.

I have had the "Transfer Complete" myself, but not because I had filled the tanks (no much chance I'll reach that anytime soon). Instead, this also happens when manually disengaging by pressing the 'fuel intake reset' button (aka nosewheel steering, aka manual lase).

I know there are many threads on the general issue involved here so I shall refer to it only as "Air-to-air Re-...um...-filling of combustible energy juice" Otherwise known as "AAR" - pronounced by most as "aaaarrrggghhh!!!" (The recent discussions about it have inspired me to start practicing it again) It is hard! There's certainly no argument against that. I am rubbish at it. Sure, I can accept that fact. But I am getting better. A bit. I can currently remain latched for up to 10 seconds at a time (with today's price of fuel that is all I can afford!). But seriously, my question is to do with the 'disconnect' logic in effect. Like I said I can remain latched for 5-10 seconds on a good day, but regardless of still being latched the guy with the big pointy stick only ever serves me juice for about 1 second at a time. The process always goes something like this: ...[pre-contact procedure complete]... Physical contact established RADIO('Stick Man'): "Contact" Cockpit: 'Latched' light illuminates [1-2 seconds pass] RADIO('Stick Man'): "You are taking fuel" [1-2 seconds pass] RADIO('Stick Man'): "Disconnect" Transfer of fuel stops Cockpit: 'Latched' light is still illuminated Fuel line is still physically connected Physical contact remains for a further 3-5 seconds Any idea why the "Disconnect" call is made without there being any need to actually disconnect? I find I then have to deliberately break the connection (not very difficult for me to accomplish!) and re-establish a new connection before old 'Sticky' is willing to feed me any more of the good stuff (..for another 1 second). On a separate but related point, I would love to see video footage of what people are doing with their real-world, physical controls while duelling with the Stick Man. I am interested to see people's different approaches used in physically manipulating the controls to achieve the desired results in the simulator.

It is probably not the cause for 99% of the instances of this issue, but it might be worth bearing in mind the "Emergency Autopilot Disable" button (a button on the cyclic). Some might have this mapped on their HOTAS and accidentally press it without noticing on 'random' occasions.

Personal experience suggests that 'broadcast SPI' is not necessary for AI wingmen. I don't have a huge amount of experience in multiplayer so I am not sure if it has any effect with human players (i.e. whether human players will see your SPI if 'broadcast' is not activated). Regarding symbology, yes the TAD display does provide user feedback on the status of SPI broadcasting. Somewhere near the top right corner of the TAD there are the words "SPI off" or SPI on", which is also highlighted with a green (on) or black (off) background depending on the status.

Amazing! Thank you Ajax. What a very specific and obscure fix. I guess this is a very well known fact amongst the mission building community, but extremely unlikely that anyone would discover this little secret for themselves without being told. Thanks again. (Is there a 'gotchas' page somewhere listing any other known quirks?)

Am I right in thinking that to be able to perform 'ground crew' operations at a FARP, there must be present at least one of each ground unit corresponding to each 'ground crew' operation you wish to perform? To refuel there must be a fuel truck. To reload there must be an ammo truck. To enable ground power there must be a GPU truck. (What is the purpose of the 'Fuel and lubrication oil' truck?) I have created a custom mission containing a FARP and at this FARP I have the following units and structures present: two different types of fuel truck. a 'Fuel and lubrication oil' truck a ground power unit truck a fuel storage unit an ammo storage unit a command bunker a number of infantry I experience the following behaviour: Refuelling is possible Ground power is not possible Rearming is not possible [Repairs - not tested] I am clearly missing the ammo truck so no suprise that I cannot rearm. What is this called within the unit list? I could not find it within the encyclopedia either. Any obvious reason for the lack of ground power? Also, my FARP is assigned to country: USA. But the USA do not appear to have any ground crew units. So instead I have had to select the country Georgia (an ally to USA in this mission) in order to access these units. Is this right? On a slight tangent, on the subject of 'units only available to particular countries' - this does not seem to allow for the concept of 'capturing' enemy units. Seems a little restrictive to deny the ability for one country to use vehicles that originate from another country. Or have I misunderstood something here?

...hmph. Scratch that. No fix here :( No no, it really is quite unpredictable. I wouldn't say 'random' because I'm sure there is a good reason the software is doing what it is doing, but I really can't figure it out. ("They don't get happy, they don't get sad. They just...run...program") It seems that making a change to the wav files (e.g. swapping them for other sound files and renaming them) results in them being played correctly (undistored) for a one or two mission starts, but then it reverts back to the distortion problem. Life is too short to obsess over squeeky doors. I quit :)

SOLVED (/workaround) Replacing the "KA50_DoorClose.wav" sound file in my DCS:World installation with the one from my old BlackShark 2 standalone installation has successfully resolved the issue. Strange thing is, the two files are byte-for-byte identical!!! But I have confirmed that the 'broken' file is definitely influencing the issue (if not entirely the cause) by the following process: - run DCS:World (Ka-50 single mission). Close door - distorted sound - replace broken file with blackshark2 file - run DCS:World (Ka-50 single mission). Close door - correct sound - replace blackshark2 file with broken file - run DCS:World (Ka-50 single mission). Close door - distorted sound - replace broken file with blackshark2 file - run DCS:World (Ka-50 single mission). Close door - correct sound If that doesn't prove the file itself is at least part of the problem then I don't know what does. Just for completeness, find attached the 'broken' file in question (renamed and zipped): KA50_DoorClose-broken.zip

I installed DCS World one month ago so possibly not the very latest no. Tonight I'll check what version it is exactly, but I can see the latest download files are version 1.2.0.63205. (Any idea the date this version was released?) Come to think of it (on a slight tangent here), what is the update procedure for DCS:World? Simply download the entire 5GB installation set and install over the top of the existing version? Or is there a more sophistimacated patching/update system somewhere? Incidentally, the first time I experienced this 'creaky door' issue was during multiplayer. The moment I opened the door I heard the beginnings of this distorted sound and then immediately got kicked off the server with a "Connection interrupted" error. Maybe some kind of sound file corruption occurred during multiplayer? Could anyone point me towards the file containing the Ka-50 door sound? I could try overwriting it with a copy from my old standalone BlackShark 2 installation.

I've not been in the shark for a little while, which maybe explains why the sound of the cockpit door opening and closing is an horrendous screetching noise instead of the smooth 'clunk-click' I remember it being previously. Not only does it sound like a rusted iron gate, all other sounds are muted while the door sound is being played. Is this familiar to anyone else?

Made a little track to demonstrate the issue. (It really is quite short: right engine shot out seconds after take off, turn around and land, park, quick shut down and then time acceleration is used during repair and start up attempts) Right engine is shot out by AAA. No fire started so no need for fuel cutoff and extinguisher (so this should eliminate the possibility of these systems having any effect/cause on the issue) After repair the APU starts fine, left engine starts fine but right engine (which was...still is?... damaged) cannot fully spool up to idle. Shut right engine down and then 'motor' it for a couple of minutes (time accelerated). Motoring definitely seems to have had an effect because now when attempting to start up the right engine a second time it hits a similar RPM limit as before but this time keeps on climbing ever so slowly until it reached a much higher (but still less than 'normal' idle) RPM. It might be worth mentioning that having had this exact scenario before (post-motoring allows a higher RPM during start up) I tried throttling up to feed it some gas (not performed in the attached track), and sure enough it slowly managed to reach full RPM; although the fuel rate and temperature were both running slightly higher than the undamaged left engine. (Curiouser ans curiouser). Anyway, this is just an example I thought might be useful/interesting to some: EngineRepair-Restart.trk

...aaaaahhhhhh. I see said the blind man. Ok forget it. Nothing to see here. Move along, keep moving. (Thanks!)

In the mission editor I don't see Su-25T (or even Su-<anything>) in the list of available aircrafts in the "Airplane Group" Type list. I just know it's available somewhere/somehow... isn't it? Surely!

Time acceleration :thumbup: All we need now is a Benny Hill sound track mod. :) (Apologies to those who have no idea I mean by that. Google Benny Hill now!)

I've had a read through a number of posts, some quite recent, about that old favourite issue: "[Left|Right] Engine wont start after a repair". (Yes I've been experiencing it myself recently, but I'm not here to whine on about that right now) Some instances are simple mistakes, but there does seem to be a number of cases where this behaviour is a genuine mystery - (a.k.a. bug :music_whistling:) I was just wondering whether this has been formally classified as a defect and has a corresponding ticket on the ToDo list? Or has it been thrown aside into the "Too Hard" basket? :) (It's ok, I wont think any less of you. Life is too short to waste time chasing the impossible.)