MeerCaT

(On a very quick, completely separate note: look how much the pilot adjusts trim during landing. Same is true of many/most/all real world aircraft I think but I'm often guilty of not doing it myself in DCS)

I wouldn't pay much attention to the wind vane while in hover (in fact I think we are actively advised not to chase the vane). Once you've determined the basic wind direction (mission briefing or in-cockpit aids) while on the ground and pointed the nose in the appropriate general direction think no more about it.

Is there any word on whether the 'GeneratorF' F10 map bug is known about and on a radar to be looked into? (Surprised if it hasn't been mentioned before but I haven't found anything in the forums) What I'm referring to is this: In multiplayer (only?) when using CTLD to spawn 'crates' (represented in game by a "GeneratorF" object) on many/most occasions the "GeneratorF" map icon becomes permanently 'stuck' to a specific position on the F10 map view. When moving and zooming the map the GeneratorF icon remains fixed at the same position on the screen. Stuck to the glass! :) Attached is a screenshot of one recent example. Here I've moved the map (Caucasus) West over the sea and we see the icons still 'glued' to those positions on screen - very far from the actual positions they really exist(ed) on the land to the East (near Sochi). I can produce a track and probe a little deeper myself if this isn't already on a TODO list.

DayGlow I agree with your confusion regarding trim. I know nothing about the real world procedures or handling of this aircraft but it's perhaps possible the instruction to trim "down" is a mistake or misinterpretation. But even then, trimming "back" by a full 2 degrees, in my short experience, would seem excessive. What has worked for me is to trim back by just a couple of 'clicks' of the trim hat. (If you make the input visualisation box - whatever it is called - visible then I trim to put the little white diamond just below the centre line so the tip of the diamond touches the line, or there abouts). A suggestion regarding the throttle: as the tutorial says, smoothly roll it all the way to max! This will likely produce quite a fast lift off so be ready to calmly reduce it again very soon after lifting off. I find (also with helicopters) that a reasonably swift lift off is often much easier to control than a very slow one. Slow and controlled is something that comes naturally over time. Being a little forceful (in a gentle way) can actually make things a bit easier to begin with. (Silly example: swipe a pen quite quickly across a page and the line you draw will probably be a lot smoother and straigher than if you drag the pen very very slowly)

Its not a problem for everyone but I doubt I was alone (esspecially among fellow rotorheads) in having a little difficulty with brain-to-hand coordination for throttle control in a hover (jetbourne flight). It is just so ingrained and natural to pull 'up' (back on the throttle) to go up, as is the case in a helicopter; but not the case here in the Harrier. So, I just wanted to share a very quick tip that has helped me focus my mind in the right way. It is simply this: Consider your throttle hand as being pressed palm-down against the floor, as if doing a push-up or handstand. Now it becomes perfectly natural within the mind to 'push' or 'pull' pressure on the throttle appropriately in order to 'push up' or 'pull down' the aircraft, as desired. 10 years in virtual helicopters has worn a deep groove in my mind (right hand up to go up, and down to go down), which is a little tricky to overcome but this idea of pushing/pulling on the ground (rather than the aircraft) has really helped me. Let me know if you have any other/better ideas.

I've only just bought the lovely Harrier (partly due to nostalgia for the original "Harrier Attack" from the 'good old days'), but I agree with Yip-Yip and Swiftwin9s: it does not seem possible to assign controls to MFD input devices. For me, within the Adjust Controls screen these devices are 'greyed out' and do not allow any (re-)assignment. Instead they are pre-configured with the appropriate assignment/mapping to the in-cockpit MFD controls. Not a huge problem for me (and most people probably) but it's definitely a shame it has been restricted like this, and arguably not a correct/fair thing to do. Sure it makes sense that people who have MFD's are likely to want to use them for the corresponding in-cockpit MFD functions but it tastes a little off to have the freedom of choice restricted over how we wish to use our input devices. Also this seems to eliminate the possibility of 'overloading' usage of these controllers with the use of modifiers. Probably manual direct manipulation of the control mapping files is an option but it's a little sad that it should be necessary.

Thanks, that's an excellent option! So to disable the MP track recording: Edit file (create if necessary): C:\Users\<username>\Saved Games\DCS\Config\autoexec.cfg [*]Add to end of file: disable_write_track = true

UPDATE: As an alternative (or in addition) to the following, we can simply disable the recording of multiplayer tracks (the files still get created but are mostly negligible in size, due to not containing any 'history' of what actually happened). See post 5 below. First off, for anyone who doesn't already know, while playing in DCS Multiplayer online it records a 'track' of every session. These files are save somewhere within your Windows user profile directory (E.g. "C:\Users\<username>\Saved Games\DCS<.openbeta>\Tracks\Multiplayer") Even over a short time these files can easily mount up to gigabytes of storage. I'm not actually sure if they ever 'expire' and get cleared down automatically by DCS at any time but in my limited experience it seems not. Therefore it's probably a good idea to a bit of manual tidy up in this folder once in a while. I'm never going to remember to bother doing that, so what I recently did was set myself a 'reminder' using Windows "Task Scheduler". May seem like slight overkill to some, but for anyone interested in doing the same and not already familiar with Task Scheduler here's an example of what I've done. You're all clever people and can figure it out but in simple steps (applicable to Windows 7, can't vouch for any other versions): Open "Task Scheduler" (Windows search for "Task" or "Sched") Task Scheduler Actions -> "Create Basic Task..." [*]Create a Basic Task Name: Reminder-DCS-MPTracks-ClearDown Desc: A reminder to clear down the DCS Multiplayer Tracks folder. Click [Next] [*]Task Trigger [select desired interval (daily, weekly etc.)] Click [Next] [*]Daily / Weekly ... [Configure the recurrence as desired] Click [Next] [*]Action Select "Start a program" Click [Next] [*]Start a program Program/script: %windir%\explorer.exe Add arguments: "C:\Users\<username>\Saved Games\DCS<.openbeta>\Tracks\Multiplayer" Click [Next] [*]Click [Finish] You can test it out straight away by right-clicking your new scheduled task and "Run". It should simply open a new Windows Explorer window in the folder configured above (i.e. your DCS multiplayer tracks folder). I provide no guarantee that it wont cause the world around you to implode, but it seems to be working ok for me.

The lighting (among other things) has got a lot better in the new completely recreated cockpit (currently available in the 2.5.6. BETA version of DCS World). If you're planning on spending any significant time in the Shark during the next weeks/months then I can highly recommend trying out the BETA version. As far as I understand there are no issues in 'upgrading' to the 2.5.6 BETA version of DCS World and then reverting back to the stable version again if you so wish. (E.g. Configuration and settings are not lost.) I can't seem to find it right now but there's a thread somewhere (I'm sure it's a 'sticky') that explains clearly how to run the DCS Updater command line tool to change the version you are running. I used it recently without any problems.

Ah right, well that's a separate issue. I'd recommend starting a new thread for that and see if anyone comes along with any advice.

@Super18 - Don't worry you are fine. What is being talked about here is when people bought the original "Black Shark" (which was a completely standalone game, nothing to do with the "DCS World" we now live in) and then upgraded to "Black Shark 2" and are now trying to 'convert' this combination of "BS1+BS2Upgrade" into a license for the full single "DCS: Black Shark 2" module within DCS World. From what you say, you bought the 'full' version of "DCS: Black Shark 2" straight up within DCS World. So this topic of transferring/converting/migrating licenses doesn't affect you.

Here are a couple of kneeboard pages I find useful as a reminder for a few things in the Black Shark (DataLink setup, Radio channel freqs, Weapon station configuration). Numbers [1] to [5] on the DataLink sheet are the initial setup of the DataLink system (switches that need to be on). Remember, [3] and [4] must be configured so that all members of the DataLink group have a unique ID only one member is the "COM". [6] to [12] are an example of creating a target point and sharing with DataLink partners. Let me know if you spot any mistakes or have any suggestions. There are several way to incorporate custom sheets like these into your kneeboard(s). I'm not giving any instructions on how to do it here but I would recommend taking a look at http://www.dcskneeboardbuilder.com if not already using/familiar with it. In fact I might put together some notes about basic usage of DCSKneeboardBuilder in a separate thread, because it was not very intuitive to me when I first looked at it, and I'm still not sure I fully 'get it' now but it's doing what I need it to. Cheers.

At the risk of hijacking my own thread... @jlummel - It may be worth approaching ED Support about your 'spare' products. Of course, I'm quite sure they are under no obligation to do anything all about it, but perhaps there is a small chance they could do something as a goodwill gesture. Especially if you have a lot of modules in your account. (Transfer to another account? Conversion to 'ED miles'?) As they say: You don't get if you don't ask. Which reminds me, now you mention it, I've got an accidental double purchase of the Nevada terrain from several years ago.

Thank you sir. I've fired off a ticket and yes it seems you are quite right, in the section of the 'New ticket wizard' for specifically addressing this issue ("Replacement of BS2 upgrade key to BS2 full version") they state the following: (...and of course you'll also need to provide your BS2 upgrade serial key) Surely I must be about the last one through the door on this now? :)

There is probably very few of us left who have this BS1-BS2 migration still festering on their TODO list. Live for today... Procrastinate till tomorrow! I have read a lot of threads about this process and now find myself repeatedly circling in a pool of the same pages, posts and information yet I'm not able to achieve the migration. I'm probably being blind to something obvious. At least I hope so. Here's my situation and what I understand of the process: I use DCS World standalone v2.5.6 (Open Beta) I have the Steam version of DCS: Black Shark (1) This is a standalone program completely separate to the 'DCS World' environment as we know it today No license key available/visible within Steam [*]I have the DCS: Black Shark 2 Upgrade version I have the key for this, and this module exists within my DCS World standalone [*]Migration Route 1 I understand there is an official mechanism to migrate from the 'BS1 + BS2Upgrade' combination to the single full 'DCS: Black Shark 2' module: https://www.digitalcombatsimulator.com/en/personal/licensing/replacebs/ However this requires entering a serial key for "DCS: Black Shark" (v1), which is not available to me (or doesn't even exist?) This migration route may not be applicable anymore? [*]Migration Route 2 Another route is the "transfer keyless DCS modules purchased on STEAM": https://www.digitalcombatsimulator.com/en/support/faq/500/#3303126 ...which links to DCS user profile page: https://www.digitalcombatsimulator.com/en/personal/profile/ [*]Here we 'Bind' our Steam account to our DCS account (so DCS can 'see' any DCS-related products we hold in Steam). [*]However, subsequently the "GET LICENSES" function fails to recognise/report my DCS: Black Shark as a product in Steam available for transfer. (It successfully recognises that DCS: A-10C Warthog is already in my DCS account, so it seems the 'connectivity' between DCS and my Steam account is working fine) I'm now not sure what other options are available since I don't seem able (or at least not aware of how) to progress with either of these two routes. Of course it's only really an issue if/when I come to perform a complete reinstall on a new machine (no imminent plans at the moment). And it may even become a moot point with the introduction of DCS: Black Shark 3, if I opt to purchase that and then abandon completely the original 'bird' that got me started in this world almost 10 years ago. :cry: On a completely separate note (now you've got me reminiscing and all teary-eyed about BS1): the background/menu music for Black Shark 1 (and standalone BS2, I think) was amazing. Did that never get carried over into DCS World? For those who have so far been denied the pleasure of this music, here's your chance to catch up on your cultural education:

@FuzzyDunlop - Yes rudder pedals (for fixed wing/planes) and anti-torque pedals (for helicopters) are exactly the same thing as far as we home-simmers a concerned. There is only one type of pedal you will need to buy, which you can then use for flying planes and helicopers. Lot's of different brands and models out there to choose from. Saitek Pro Flight Rudder Pedals (just as one example) also have an additional analogue depressable mechanism in each pedal that can be assigned as analogue wheel brake controls, if applicable to the aircraft.

Thanks for the advice pmiceli. I'll look to update my notes to reflect some of your points. The ability to keep communications to an absolute minimum is definitely a good skill to have in the toolbox, for when it's necessary. I do quite like to hear a constant buzz of activity over the radio though. So if conditions allow it, and the server (or at least the comms channel) is not too busy, there's probably no harm in expanding the radio calls to include advisories such as taxiing and use a couple more words here and there. Helps for an atmosphere that feels a little more alive.

TL;DR - Here are some notes and a reference sheet to help beginners like me get started with some basic radio communication to use online in DCS multiplayer. See attached; a simple two page cheatsheet 'reference card'. Having only quite recently dipped my toe into the DCS multiplayer world I have put together a few 'quick' reference notes regarding the basic procedures and radio lingo to wet the feet and get started, based largely on my own limited online experience. There are huge amounts of help and information out there already, far more comprehensive and eloquently documented than my scribbles, but I hope the short notes here can be useful to someone as they have been (and are) to me. There are basically just two things I'm addressing here: 'Special' words to use over the radio (a.k.a. "Brevity Codes") Basic communication procedures for common situations Note, this guide covers only what to say not what to do. So also ensure you have an understanding of the physical procedures to perform, such as airfield/carrier approaches and landing patterns. Then these notes can provide suggestions of what to say and help anticipate and interpret what other people may say. Disclaimer: it's not unusual for me to be wrong, and what follows is a blend of some 'official' information, bits of what I've picked up from others and a dash of my own personal preferences and habits. Always open to corrections and suggestions. 1 - Brevity Codes First and foremost, I think most would agree it absolutely does NOT matter what words and expressions you use when talking over the radio so long as it is short, relevant/useful and understandable (and reasonably 'clean'; it's a family show kids). Some brevity 'code' words have been invented to help with the 'short' but if you can't remember whether to tally-splash-bandit-spike or blind-bogey-mud-fox then just use plain language to at least keep it 'understandable'. There is a LOT of military terminology and radio brevity 'code words'. Here is just a few (a mere 43!) that I think are most likely to prove useful to amateurs such as myself within an informal multiplayer DCS environment. Day 1 These are the 23 bare essentials to get started with, likely to come in useful from day one. Misc Comms Angels # - Altitude in 1000's feet ("Angels 7" is 7000ft). Some sources indicate this is mostly/only a Navy term and some even suggest it is no longer used, but is universally understood in DCS community. Affirm - "Yes" (A positive response to a question) Negative - "No" (A negative response to a question) Roger - Simple acknowledgement of information/comments RECEIVED. (Legacy phonetic word representing the letter 'R', for "Received". Commonly used incorrectly to mean "Yes". Try to avoid this habit) Copy - Details received and written/remembered. May not be 'official' but universally understood. Commonly abused in the same way as "Roger". Situational Awareness AO - Area of Operations Bogey - Unknown aircraft Bandit - Confirmed enemy aircraft Spike - Air radar locked/tracking (could be friendly or enemy) Mud - Ground radar threat (often used with "-spike" to indicate ground radar locked/tracking, but some argue that is not 'official') Weapons Splash - Target hit, not necessarily destroyed (both air and ground targets, but seems common to use just for air targets) Shack - Ground target hit/destroyed (not sure if this is 'official' by NATO standards, but is very commonly used) Callouts made when releasing weapons: GUNS - Gun/Cannon shot (both air and ground targets) Air-to-Air Fox ONE - Semi-active radar AA missile (e.g. AIM-7 Sparrow) Fox TWO - Infrared-guided AA missile (e.g. AIM-9 Sidewinder) Fox THREE - Active radar AA missile (e..g AIM-120 AMRAAM) Maddog - A Fox 3 missile has been released 'independent' ('Visual' mode), with no initial guidance from launching aircraft Air-to-Ground Not really necessary to call out air-to-ground weapon releases unless coordinating closely with JTAC, wingmen or other friendlies. At most it is enough just to say "<count> away", where <count> is simply how many bombs/missiles you've just released. AWACS Bogey Dope - Request AWACS for some air targets to engage (Surely it should be "Bandit Dope"?!) Request Picture - Request AWACS for complete 'picture' of all detected bandits in the theater of operations Hot - Bandit moving towards you Cold - Bandit moving away from you Flanking - Bandit moving perpendicular to your heading Popup - New bandits detected in AO Day 2 Probably less frequent usage depending on what you do, who you do it with and how 'immersed' you like to get. Misc Comms Unable - Unable to comply with the request/instruction Wilco - "Will comply". Will comply with the request/instruction Situational Awareness Blind - Friendly not in sight (air/ground) Visual - Friendly in sight (air/ground) No Joy - Enemy not in sight (air/ground) Tally - Enemy in sight (air/ground) Raygun - Radar lock on a bogey. Request for friendlies to reply if they believe they are the target of this lock. Buddy Spike <HDG, ALT> - Response to 'Raygun' callout if believed you are the recipient of the friendly radar lock. Give your heading and altitude. Nails - Air radar threat, searching not locked Dirt - Ground radar threat, searching not locked (arguably no longer 'official') Weapons Air-to-Ground Missiles Rifle - Air-to-ground missile (e.g. AGM-64 maverick) Magnum - Anti-SAM missile (e.g. AGM-88 HARM) Bruiser - Anti-ship missile Bombs Pickle - Single 'dumb' bomb Ripple - Multiple bombs released in sequence Paveway - Laser-guided bomb [Anything for rockets?] AWACS Declare - Request AWACS for identification (Is Friend or Foe IFF) of a specific target Sunrise - AWACS Online Sunset - AWACS offline 2 - Basic Comms Procedures Not to let a lack of knowledge or ability stop me from blundering in, I've put together some common and simplified reference notes of basic communication for use online. Key <WHO> = Who are you talking TO. E.g. "Sukhumi traffic", "Sochi tower" <CALLSIGN> = Your callsign (Use the name you are signed onto the server with) Green = Self Red = Others (responses) () Parenthesis = Not strictly necessary (but no harm if capacity allows), or depends on situation. Prep ATIS(If available): Get active runway(s) and altimeter settings from ATIS message Tune radio(s): Ground/Tower ATC or common/Guard frequency (Radio check: "Frequency <FREQUENCY>, <CALLSIGN>, Radio check" "5 by 5 on frequency <FREQUENCY>" or "Loud and Clear on frequency <FREQUENCY>") (Good to break the ice and overcome the dreaded 'mic fright') Take-off (No human ATC – Common Traffic Advisory Calls) (Taxi: "<WHO>, <CALLSIGN>, Taxiing to runway <RWY>") - not so important on an average DCS server Line up: "<WHO>, <CALLSIGN>, Lining up runway <RWY> for [N|E|S|W|Straight out] departure, (<WHO>)" or "…, Taking the active for …" (Take off: "<WHO>, <CALLSIGN>, Wheels up, clear of the active, (<WHO>)") Goodbye: "<WHO>, Last call for <CALLSIGN>, (<WHO>). Out." Operations Approach: "<CALLSIGN>, <#> miles [N|E|S|W] of AO at <LOCATION/REFERENCE>, inbound for [CAP|CAS|SEAD]" …ad-hoc comms to liaise with friendlies… AWACS/GCI (Human) Is Active?: "<CALLSIGN>, Is [GCI|AWACS] sunrise or midnight" "<CALLSIGN>, <AWACS> is sunrise", or from anyone: "Midnight" Picture: "<AWACS>, <CALLSIGN>, Request picture" "<CALLSIGN>, <AWACS> <…DETAILS…>" Tasking: "<AWACS>, <CALLSIGN>, [bogey dope|Request tasking]" "<CALLSIGN>, <AWACS>, [bandit|Group] BRAA <BEARING>, <RANGE> at <ALT>, [Hot|Cold|Flanking]" Landing (No human ATC – Common Traffic Advisory Calls) Approach: "<WHO>, <CALLSIGN>, <#> miles [out|N|E|S|W], inbound for the [pattern|overhead] runway <RWY>, (<WHO>)" Pattern: "<WHO>, <CALLSIGN>, Entering [left|right] downwind runway <RWY>, (<WHO>)" or Overhead: "<WHO>, <CALLSIGN>, Initial <RWY>, for the overhead, [left|right] break, (<WHO>)" (Base: "<WHO>, <CALLSIGN>, [Left|Right] base runway <RWY>, (<WHO>)") Final: "<WHO>, <CALLSIGN>, (Turning) (short) final runway <RWY>, [full stop|touch and go], (<WHO>)" Clear: "<WHO>, <CALLSIGN>, Taxiing clear of the [active|runway], (<WHO>)" Finally, I'll be amazed if I managed to write all these words without making any glaring mistakes, so cookies for the first person to spot them. Cheers! DCS-BasicOnlineCommsRef-v1.1.pdf

Just to pick up on a few small points regarding terminology used here. Technically there is no "locking" functionality within the Gazelle / Viviane Camera system. It is a somewhat 'dumb' camera you simply have to manually manoeuvre to the point you want guide a HOT missile onto. Also the launch cue (little rectangle/'blob' displayed in bottom right corner of camera view) indicates nothing about 'range'. It only confirms that the nose of the aircraft is pointed in the same direction (heading) as the camera, within the small margin of error (3 degrees either side?) permitted for weapons launch. I think everyone here knows this already but just to clarify for anyone new still learning.

Not much of a work-around but perhaps a slight improvement towards a 'slick' aircraft is to use the 'M' variant with zero HOT3's loaded. Then you'll just have empty pylons.

Tiny thing, hardly worth mentinoing really. It has caused me barely any sleepless nights. The writing on the side of the HOT3 missile contains, well either a typo or a deliberate 'Easter Egg'. Instead of reading "DCS WORLD" is has "DCS WORLS" :detective: You know what, I think I prefer it as it is. Forget I said anything :)

There's a lot of value in providing concise but descriptive comments every time you do a source control commit/check-in. ...And of course committing often! Concerned about committing work-in-progress, breaking changes? That's why you should be working on a separate branch, so as not to affect the main trunk until your 'feature' is complete and tested. It becomes a lot less necessary to analyse file deltas/diffs if the commit history contains meaningful comments. Parallel development by several people on the same file entirely relies upon the ability of the source control software being able to 'merge' the changes. The 'miz' files are binary files and as such cannot be merged. No merging means no parallel development on that file. Of course a huge amount of effort (arguably the majority) is likely to be in your custom LUA script(s) rather than the mission file itself. Being plain text files these are perfect candidates for parallel development. If not already, store your LUA scripts as separate entities within source control, rather than just the 'binary' pre-compiled MIZ file containing the entire project bundled up together. UPDATE: oh and if you and your buddy really do need to both be editing the MIZ file, you'll have to come to some arrangement regarding 'checking-out'/locking/reserving the file so that only one of you ever has permission/ability to be touching it at any given time. Only once the edit is complete can it be opened up again.

Some of my favourites: Landings on taxiways Take-offs in the opposite direction of the active runway flow Smoke bomb trails drawn along runways/carrier 1-10 second lags (screen freeze) at crucial moments while air-to-air refueling and carrier landings. :crash: But seriously, despite the inevitable imperfections of a simulated playground, I can very much recommend taking the effort to slowly ease yourself into the multiplayer experience.

I'm not 'official' but here's my 2 pence for starters... TRIM for AoA. THRUST for descent rate. Even slight movement of stick PITCH drastically effects position of the AoA marker. Keep stick neutral while trimming for AoA. As a side note, when on final for landing on a carrier use only the 'meatball' as the glideslope/descent rate reference, not the velocity vector.

I stand happy and ready to be corrected but I will be incredibly surprised if you find it possible to cut out sections of a track file and have it still be a true and valid representation of the original history. Cutting short a 'story' by trimming off the end is fine because it in no way effects the integrity of the story. Cutting off anything at the beginning or middle will corrupt the 'history' of events. Simplified example of what I mean: INITIAL: start at grid reference 4,4. Facing 'up/North' towards grid ref 4,5. STEP: move forward 3 STEP: turn right 90 degrees STEP: move forward 5 STEP: move backwards 1 END: (final position is grid ref 8,7. Facing right/East) If you remove 'INITIAL' then you've lost all context of where you started from, so all following STEPs are meaningless. If you remove any STEPs then you corrupt the history of events and the final position will no longer match the original series of events.