doveman

Thanks. I wasn't sure if there was some Apple-specific app or format that people were using. I think 7" might be a bit small, having used my Mum's, so probably 10" is what I should look at. I get confused about what resolution is needed for certain screen sizes. I'd normally think as high as possible but wouldn't that just make everything smaller and harder to read as it does with PC monitors (unless you increase the DPI). Of course you can zoom but it's nicer if you can see most of the page at once and not just a small section and have to keep unzooming/zooming on different parts. I've actually already got DCS Manager on my phone and despite my phone being absolute crap, it works fine so I browse that when I'm stuck on a train or something to pass the time :) I'm not sure if the charts are up-to-date though and it would be great if it was updated to cover more aircraft.

I presume an android tablet would work equally well? What's size screen is suitable? Is it easy to make bookmarks to quickly switch to selected pages?

No, turned out I just needed to change the setting in FTNoir.

I'm using FTNoIR and confirmed it works with ArmA3. For DCS, I've got the files from here http://forums.eagle.ru/showthread.php?t=114706&highlight=headtracker in the /bin folder, as I've done previously (I enabled/disable them with JSGME) but I get no response in Controls when checking the TrackIR axis or in the cockpit. In FTNoIR, I've tried "Use Freetrack, Hide TrackIR" and "Both". It installs a file when using the latter that makes DCS think TIR is installed, hence the TrackIR column appearing, which stays even if I remove the headtracker files. OK, got it working :) I switched back to "Use Freetrack, Hide TrackIR" and that makes the column show as "Headtracker" instead of "TrackIR". Maybe setting it to both installed something that made it work. Please ED, provide Global settings for the Axis columns though. I had to null the Roll on both X and Y axis as I get phantom input otherwise (I don't need Roll anyway) and had to do it individually for each of the 15 or so aircraft, which was very tedious. You could have a "Override global" tickbox for any aircraft where we want to tweak things for specific aircraft but for the majority, certainly all the FC3 aircraft, I imagine most people will want the same settings for headtracker/TrackIR and the joystick/throttle/rudder settings.

This looks like it will be really helpful to my small group. Thanks a lot :)

I was using Helios with the KA-50 fine a week or so ago but now it doesn't seem to send anything to DCS, or at least nothing's happening. The touchscreen itself is working fine and I can move the switches, etc. I wonder if something in the 1.2.10 update has changed which is causing this? Any other ideas? EDIT: Never mind, I'm a dumbass. Forgot I'd enabled touchbuddy in the export.lua. Working again now I've removed that line.

I already have 16GB DDR3 and there was £30 cashback on the 4670k, so the CPU and board only cost me £230.

Any managed to get a multi-plane monitor config working properly? I've tried this but loading the KA-50 I just got the Abris and Shkval (I presume it must be wrongly identifying the unit_type as "A-10C", as that's the only section that contains any exports that might give this result (i.e. Left and Right MFCD) and loading the A-10C, I don't get anything on my second monitor, so it must be using the default_setup then. _ = function(p) return p; end; name = _('MultiPlane'); Description = 'Config for all planes' function default_setup() Viewports = { Center = { x = 0; y = 0; width = 1920; height = 1200; viewDx = 0; viewDy = 0; aspect = 1.6; } } GUI = { x = 0; y = 0; width = 1920; height = 1200; } UIMainView = GUI end default_setup(); UIMainView = Viewports.Center; function reconfigure_for_unit(unit_type) if unit_type == 'Ka-50' then Viewports = { Center = { x = 0; y = 0; width = 1920; height = 1200; viewDx = 0; viewDy = 0; aspect = 1.6; } } ED_KA50_Shkval = { x = 1927; y = 7; width = 809; height = 650; } ED_KA50_ABRIS = { x = 3251; y = 0; width = 587; height = 838; } ED_KA50_PVI = { x = 1956; y = 678; width = 212; height = 107; } ED_KA50_Ekran = { x = 3080; y = 955; width = 162; height = 116; } ED_KA50_UV26 = { x = 2751; y = 533; width = 307; height = 84; } GUI = { x = 0; y = 0; width = 1920; height = 1200; } UIMainView = GUI elseif unit_type == 'A-10C' then Viewports = { Center = { x = 0; y = 0; width = 1920; height = 1200; viewDx = 0; viewDy = 0; aspect = 1.6; } } LEFT_MFCD = { x = 1921; y = 0; width = 921; height = 730; } RIGHT_MFCD = { x = 1920+1272; y = 0; width = 648; height = 812; } CDU_SCREEN = { x = 3220; --3210 mfd coordinate y = 70; width = 380; height = 285; } CMS_SCREEN = { x = 1945; y = 460; width = 400; height = 84; } RWR_SCREEN = { x = 1945; y = 625; width = 400; height = 400; } GUI = { x = 0; y = 0; width = 1920; height = 1200; } UIMainView = GUI elseif unit_type == 'Su-25T' then Viewports = { Center = { x = 0; y = 0; width = 1920; height = 1200; viewDx = 0; viewDy = 0; aspect = 1.6; } } RIGHT_MFCD = { x = 3154; y = 0; width = 690; height = 550; } GUI = { x = 0; y = 0; width = 1920; height = 1200; } UIMainView = GUI else default_setup() end end Using the KA-50 tags in a separate config just for that aircraft, all the exports show up fine _ = function(p) return p; end; name = _('Keen KA50'); Description = 'Helios Keen KA50'; Viewports = { Center = { x = 0; y = 0; width = 1920; height = 1200; viewDx = 0; viewDy = 0; aspect = 1.6; } } ED_KA50_ABRIS = { x = 3249; y = 0; width = 588; height = 846; } ED_KA50_Shkval = { x = 1920; y = 0; width = 816; height = 659; } ED_KA50_PVI = { x = 1956; y = 678; width = 212; height = 107; } ED_KA50_Ekran = { x = 3080; y = 955; width = 162; height = 116; } ED_KA50_UV26 = { x = 2751; y = 533; width = 307; height = 84; } GUI = { x = 0; y = 0; width = 1920; height = 1200; } UIMainView = GUI

Thanks for doing that. It does seem to prove that even beyond 4 cores, extra cores make a difference, with the same increase of 15 fps going from 2-4 (25-40 fps) and 4-6 (40-55 fps) cores. Even so, I still would expect (from everything I've been told about Intel vs AMD for single-threaded performance) that an Intel i5 quad-core would probably comfortably outperform an AMD 6 or 8-core at the same Ghz (and probably even with the AMD OC'd higher than the Intel) as far as DCS (or any other predominantly single-threaded program) is concerned but I don't have any test data myself to support that.

You obviously understand the technical stuff more than I do. I'm just repeating what other people have told me (and which seems reasonably true) about DCS and X-Plane, as I haven't been able to compare AMD 6-8 core with Intel quad core myself. It would be interesting if you could repeat your test with 4 cores though, to see if there's any advantage with 6 cores. I can see from your two core test that both cores were pretty much maxed out at the same points, so it's understandable that DCS is hitting the buffers in this test, although it's somewhat strange considering that ED have said that EDGE only needs/uses 2 cores (and I presume the same for current DCS) but with 4 cores to spread the load over it might be all it needs. 3.3Ghz is quite low as well, so you might find if you test OC'd to 4.4Ghz (which seems to be quite an easy OC with a i5-4670k and so what most people will use), that those two cores then have sufficient headroom not to limit DCS.

Nice find DC, thanks for the share. Such a good deal I've bought a couple, even though I don't have any current plans what to use them for :) EDIT: From the picture, it seems the chips are fakes/clones, which probably won't matter but some of the comments here have mentioned running into issues that disappeared once they replaced them with genuine parts http://tronixstuff.com/2013/05/16/the-max7219-led-display-controller-real-or-fake/ Even if we end up having to replace the chips though (which is unlikely), it's still worth it just for the PCB :)

Yes windows automatically spreads the load over the cores but that doesn't mean you're getting any real benefit from having more cores, if the total load only amounts to 100% of one core (in your screenshot it's only using 15% of 6 cores, which is less than 1 core fully loaded). I believe that it has been confirmed in a recent statement that EDGE will still only use two cores, although I'm not sure exactly what that means, considering that Windows will automatically schedule the load amongst all available cores, unless you lock it to specific cores using Process Lasso or similar. So if the main part of DCS is single-threaded (and maxes out one core) and it also runs some other threads for audio, etc that don't amount to more than 100% of one core, then probably two good, fast cores would be sufficient. Sure, we have other apps running but they generally don't require much CPU % each, so a quad-core is generally adequate. It's been proven that Intel i5 CPUs work much better for single-threaded processes than AMD ones at the same clock speed, simply because they're designed differently and more efficient for that. Even at 5ghz I don't believe a 6 or 8 core AMD will outperform a 4.5Ghz i5-4670k. X-Plane is similar to DCS in that it runs it's main simulation process on a single-thread but uses other threads for scenery loading, etc and likewise that runs much better on an i5 than AMD and there's little to no benefit from the extra threads with an i7 or more than 4 cores. Anyway, I've just bought myself an i5-4670k and Z97 board, so I'll be able to compare for myself once I get that set up.

You can get a 27" benq VA panel which looks a lot better than even IPS by all accounts, for £160, which is a lot less than £400. The viewing distance to properly appreciate 4k on a 50" screen is about 3.5ft, so you'd have to sit pretty damn close to a 28".

If DCS remains single-threaded then that oc'd 8350 will still be worse than an i5-4670k

Probably not, I don't think the tutorial leaves that long before telling me to start the engines. Why would that be important? I just tried the easy landing tutorial and lined up with the LNDG heading had me come in at right-angles to the runway!

Wouldn't an encoder work better, as then you could have the software (running on Arduino or bridge software on the PC) set to adjust the trim by x amount per click, with x set differently for DCS and IL2? If the multi-turn pots are still better regardless though, please let me know which ones you're using, so that I can get some myself ;)

If I ever equated my girlfriend with DCS, she'd hit me ;)

Yep, definitely powered up as I was running the taxi, take-off training mission and took off and flew around for about 20 minutes before trying to land. So I guess it must be #2. Damn, that's going to make life hard having to know what the offset is for every location and setting the instruments to compensate. I'm not even sure there is an offset setting for the SU-25T, so maybe we just have to compensate manually?

Is there something off about the SU-25T HUD heading, as trying to land at Mozdok runway 26, heading 256 degrees didn't get me lined up and after restarting, on the ground the HUD shows about 262 degrees with the plane lined up with the centre line and about 82 degrees facing the other way, which the Kneeboard chart shows should be 76 degrees?

Thanks, they look very nicely done. Definitely printing those out to put in my folder :thumbup:

OK, thanks. Yeah, I see them know. Easy enough to print out :)

OK but can they be extracted and printed? Even if they can, I don't want to create work for myself if the pdfs I already have are accurate.

I've got the following files Airfield Diagrams.pdf May 2011 DCS-A10C GND and VAD Charts_v403.pdf for DCS 1.2.4 18/05/2013 DCS-WORLD GND and VAD Charts_v403.pdf for DCS 1.2.4 18/05/2013 DCS_GND_Charts_v36_030513.pdf for DCS 1.2.4 3/5/2013 DCS_VAD_Charts_A10C_v36_030513.pdf for DCS 1.2.4 3/5/2013 DCS_VAD_Charts_FC3_v36_030513.pdf for DCS 1.2.4 3/5/2013 IFR Batumi.pdf by Tango -117- 2010 Can anyone advise whether those are all still accurate and consistent with 1.2.10 or if I should delete any of them and if there's any more up to date replacements? I just want to make sure I'm not using and sharing any documents that will just make life more difficult.

Well he's using a £200+ Warthog instead of a £15 Pro Micro but apart from that ;)

I found this code to make the Leonardo function as a USB joystick: http://www.imaginaryindustries.com/blog/?p=80 I've tested it on my Pro Micro and it works and sends random data for testing purposes, as intended. I wonder if anyone would be able to help me adapt and merge the code written for the Teensy, to read the buttons via SPI http://forum.il2sturmovik.com/topic/1790-there-any-better-joystick-ms-sidewinder-force-feedback-2/#entry46472 with the above USB output code? In USBAPI.h, the main joystick-related code seems to be: // Joystick // Implemented in HID.cpp // The list of parameters here needs to match the implementation in HID.cpp typedef struct JoyState // Pretty self explanitory. Simple state to store all the joystick parameters { uint8_t xAxis; uint8_t yAxis; uint8_t zAxis; uint8_t xRotAxis; uint8_t yRotAxis; uint8_t zRotAxis; uint8_t throttle; uint8_t rudder; uint8_t hatSw1; uint8_t hatSw2; uint32_t buttons; // 32 general buttons } JoyState_t; class Joystick_ { public: Joystick_(); void setState(JoyState_t *joySt); }; extern Joystick_ Joystick; and in HID.cpp: // Joystick // Usage: Joystick.move(inputs go here) // // The report data format must match the one defined in the descriptor exactly // or it either won't work, or the pc will make a mess of unpacking the data // Joystick_::Joystick_() { } #define joyBytes 13 // should be equivalent to sizeof(JoyState_t) void Joystick_::setState(JoyState_t *joySt) { uint8_t data[joyBytes]; uint32_t buttonTmp; buttonTmp = joySt->buttons; data[0] = buttonTmp & 0xFF; // Break 32 bit button-state out into 4 bytes, to send over USB buttonTmp >>= 8; data[1] = buttonTmp & 0xFF; buttonTmp >>= 8; data[2] = buttonTmp & 0xFF; buttonTmp >>= 8; data[3] = buttonTmp & 0xFF; data[4] = joySt->throttle; // Throttle data[5] = joySt->rudder; // Steering data[6] = (joySt->hatSw2 << 4) | joySt->hatSw1; // Pack hat-switch states into a single byte data[7] = joySt->xAxis; // X axis data[8] = joySt->yAxis; // Y axis data[9] = joySt->zAxis; // Z axis data[10] = joySt->xRotAxis; // rX axis data[11] = joySt->yRotAxis; // rY axis data[12] = joySt->zRotAxis; // rZ axis //HID_SendReport(Report number, array of values in same order as HID descriptor, length) HID_SendReport(3, data, joyBytes); // The joystick is specified as using report 3 in the descriptor. That's where the "3" comes from }