doveman

Thanks. I did the edits myself first and tested and then tested with your v.538 standard and it works great :thumbup:

Whilst apparently not completely accurate and more of a docu-drama, I caught "The Arrow" featuring Dan Aykroyd, about the development and subsequent cancellation in the 1950s of the Avro Canada CF-105 Arrow on TV last night. Very interesting watch. It appears the cancellation of what was a very advanced aircraft for the time (the end credits even claimed the F-18 doesn't achieve the performance the Arrow was on target to hit and in test flights it had reached 1,600km/h at 50,000ft whilst climbing and accelerating and a top speed of Mach 1.98) was mostly a political decision by an incoming Conservative government, led by John Diefenbaker, trying to look tough and rein in "rampant Liberal spending" and instead become a partner in NORAD and the SAGE air defence missile system (they ended up spending more buying missiles and arguably inferior aircraft from the US) and all trace of the programme was ordered scrapped. Following cancellation, a large number of the engineers on the programme went on to work for NASA or went to work elsewhere in the US and UK, losing Canada a massive amount of talent, not to mention the 14,000 jobs lost at Avro and estimated 35,000 jobs in supporting industries. https://en.wikipedia.org/wiki/Avro_Canada_CF-105_Arrow Ironically, in 1962 it seems the US subsequently plotted the overthrow of Diefenbaker, due to his anti-nuclear stance (he refused to accept nuclear warheads on the Bomarc anti-air missiles) to replace him with the newly pro-nuclear Liberal Lester Pearson http://www.peace.ca/regimechangeincanada.htm However, by 1964 it seems the US had decided they didn't like Pearson anymore. Another film I saw recently is "Agent of Influence" http://www.imdb.com/title/tt0307934/?ref_=fn_al_tt_1 which, although speculative in part, details how, in 1964, the Canadian RCMP collaborated with the CIA to kidnap and interrogate the former Canadian Ambassador to Russia, John Watkins, apparently in a CIA-led attempt to smear the Prime Minister, who was a close personal friend and whom they considered to be a "Red". Mr Watkins died during this interrogation but this was covered up until it was exposed in 1980. I'm not sure who comes out looking worse from these events, the US for putting pressure on and meddling in Canada, or Canada for being weak and letting themselves be manipulated.

Thanks, I'll get my head round all this one day ;)

OK, so this export.lua is just to enable the exporting of gauges/instruments, whilst export of displays (MFDs, Shvkal, Abris) is enabled by default and to export the Kneeboard and other stuff we need to edit specific files for each aircraft, as Abnaxus has done here for his Huey profile? http://forums.eagle.ru/showpost.php?p=2009903&postcount=88

Actually I just got round to testing this and it doesn't seem to work! Maybe if I remove the ZIP file and just have the loose files present (Devrim's plus the originals where he hasn't modified them) that will work. We can have JSGME automatically remove the ZIP file at the same time as dropping the loose files in the folder by adding an empty file named like this: SU-25T-CPT-TEXTURES.zip-remove EDIT: Nope, that didn't work either. I just ended up with the cockpits having no textures (I made separate JSGME mod folders for each aircraft, with the appropriate files and .zip-remove in each). Maybe the only option is to put Devrim's files in a Zip, which we should still be able to use JSGME for, just copy the original ZIP to the JSGME mod folder and put the modified files in that and then enable it.

I'm a bit confused by this going in Bazar/World/Textures as some FC3 aircraft have their own zips in Mods\aircrafts\Flaming Cliffs\Cockpit\Resources\Model\Textures, so how does DCS decide which files to use?

I was looking at getting a projector instead of a 50" TV but lost interest due to the cost of replacing bulbs. The LED projectors got me interested again, as they don't have any bulb maintainence/replacement costs, until I found out that they're considerably less bright and need a totally blacked out room (like a basement with no windows). Laser projectors might be OK but they're rather expensive (at least £1000 I think), so there's nothing suitable in my price range at the moment unfortunately, as it would have been cool.

Thanks Mustang. I tracked the fix down to this post http://forums.eagle.ru/showpost.php?p=1865107&postcount=110 He doesn't explain exactly what he did to fix it but the rar contains "HDR with a 'D' like Dynamic for DCS WORLD" and "Version for HD 69XX GPU Users" (it seems to only affect 69xx users, as PeterP was using his 7950 without having this problem). I compared the hdr.fx and that just seems to have two lines modified, line 313 is commented out and replaced at line 314 with float mask = clamp(lGlow * pow(abs(0.0), glowRadius), 0.0, 0.6) * 0.8 * (1.0 - clamp(SunPower, 0.6, 1.0)); and line 334 (or 335, depending on line spacing) "composite = composite + blur;" is commented out. So assuming the fix is just in that file, that appears to be the only changes required. I'll try making those edits to your mod and check if that fixes it, as you probably don't have a 69xx card to test it with. Hopefully those edits don't negatively affect anything for anyone else, as it would be great if you could incorporate it into your releases but if not, I appreciate it would be a bit of a pain to have to make two versions of every release.

Thanks for this Mustang. I seem to recall previously you incorporated PeterP's HDR with fix for the flashing white dots we get with ATI cards when enabling HDR (HDR with a 'D' like Dynamic for DCS WORLD) but your recent version with his HDR merged resulted in the white flashing dots again, so maybe the version you merged didn't have the fix. If you could possibly merge his fix with your mod in future that would be great, as I know they share some files so I can't just enable his mod on top of yours without partly breaking it. EDIT: Actually, looking at the thread for that mod, I can't see any mention of a fix for the flashing white boxes, so maybe it was another mod?

Ah OK. I thought it must have as I have a Helios profile (made by Abnaxus) for it, which I guess sends keyboard commands when I press the buttons and I thought the exports were not dependent on Helios but simply displaying certain cockpit instruments in a particular screen position.

I'm only running DCS on one monitor but have a secondary running Helios with some instruments exported to that, so have to run 3840x1200. However, this results in the map opening on both screens, half under Helios and thus not visible, making it unusable as I can't even drag it across to move the obscured part onto my main monitor. I guess I'll have to just fly FC3 planes (which I don't have any Helios profiles for, so I can run at 1920x1200) for now and hope this gets fixed sometime. How are other Helios users managing to cope with this? Just doing without the map completely or just not exporting any instruments and setting DCS to just use the single monitor resolution?

Just wondering if you might be able to include the UH-1H in this?

Insane that this isn't fixed yet. I'm using Helios on my secondary screen and half the map is buried under that, making it impossible to use.

I very much like what you've done with the Hempstick and it certainly makes sense to use an interrupt-driven system rather than loop polling. However, I'll only be using the switches from the F16 stick, as the FFB2 needs to handle the pots so that the FFB works, so I'm not there'd be any real-world benefit in using the Hempstick just for that. I can get an Arduino Due for as little as £12 (or £15 from the UK) http://www.ebay.co.uk/itm/DUE-R3-Board-SAM3X8E-32-bit-ARM-Cortex-M3-Control-Board-Module-For-Arduino-Z-/201105636770?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item2ed2d47da2 so the cost of buying another board isn't really a factor but if I can use a smaller board, maybe one of the Pro Micros I already have (I'm only using the Mega for testing and don't intend to use it for the long-term unless I have to), then it might help with the layout and keeping things tidy in the box I'll need to build to hold the electronics and motors. Having said that, if I find I need to buy another board for this project (i.e. the Pro Micro isn't suitable and I don't want to use the Mega), then it would probably make sense to buy an Arduino Due and build a Hempstick rather than spend about the same on a Teensy 2.0, so I may do that. EDIT: I note you say that a separate programmer/debugger is required for the Arduino Due, which cost quite a bit and would make it too expensive for me, for this project at least. I can't really get my head round an Ardunio board that can't be programmed via USB like all the others and sites selling them, like Sparkfun, don't appear to mention this important limitation https://www.sparkfun.com/products/11589 but if that is the case, then it would be cheaper to use the SAM4S XPLAINED Pro instead but they seem to cost about £30, which is really more than I'm aiming to spend and there don't seem to be any cheap Chinese clones on e-bay.

It seems every update breaks missions and it's very annoying to play a mission only to find, sometimes after wasting considerable time, that it doesn't work properly. The solution appears to be to load the mission in the ME and re-save it but that's obviously rather tedious if the player has a lot of missions and he can't really be expected to do this for every mission after each update (adding a tag to each mission when saving, to keep track of which have been updated). So my wish is for a batch mission updater, that users can run either from a Start Menu link or an option in the GUI, that will automatically re-save every mission/campaign with the current version, so that the user can just do this once after each update and after that, choose and play any mission without having to worry that it might not work.

Still doesn't help if ED update the lua though surely, as your outdated lua in saved games will be used instead of the updated file ? Hence why I suggest it would be better if we could use a separate file to put all our tweaks which is loaded last and uses any settings within instead of those contained in the original files. I've also tried what you've suggested in the past and found it only worked with specific files that DCS is programmed to look for, as I tried putting all my mods with JSGME in saved games and it didn't work for many of them.

Even using JSGME though, if ED update the lua files we need to copy the updated files to the Mod folder and edit them as required again, otherwise when we enable the mod after updating it will overwrite the updated files with outdated ones, potentially breaking something. It would be much better if we could make all our tweaks in a separate file in Saved Games to avoid this hassle.

Never mind. I seem to have fixed it by creating a new profile with EMC. Only did the Shkval and Abris so far but it should hopefully still work once I add the other stuff back in. _ = function(p) return p; end; name = _('Zeen'); Description = 'KA50' 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 = -1; width = 587; height = 838; } GUI = { x = 0; y = 0; width = 1920; height = 1200; } UIMainView = GUI

I'm having a weird problem. I did have everything exported to my second monitor before, so I'm not sure what's changed (maybe the update to 1.2.10) but now the Shvkal appears in the upper-right on the primary monitor, whilst everything else shows up where it should. If I open EMC, it shows the Shvkal in the correct position. I'm using this config (I think I manually added some alternative references in case the auto-generated ones weren't right): _ = function(p) return p; end; name = _('Zeen KA50'); Description = 'Helios Zeen KA50'; Viewports = { Center = { x = 0; y = 0; width = 1920; height = 1200; viewDx = 0; viewDy = 0; aspect = 1.6; } } LEFT_MFCD = { x = 1920; y = 0; width = 921; height = 730; } RIGHT_MFCD = { x = 1920+1272; y = 0; width = 648; height = 812; } UV26 = { x = 1920+1030; y = 610; width = 120; height = 60; } PVI = { x = 1920+15; y = 726; width = 255; height = 90; } EKRAN = { x = 1920+1745; y = 955; width = 95; height = 57; } Shkval = { x = 1920; y = 0; width = 816; height = 659; } 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; } UIMainView = Viewports.Center

That's great. Thanks for the info.

You may well be right. Maybe the advantages of using Ethernet are more for panels with both input and output and for simple output for a stick, USB will suffice. The Megas weren't particularly expensive, so I'm not totally averse to using one for the stick (and maybe using the spare inputs for a panel) but it might be more sensible to use something much cheaper, like a ATtiny2313 and save the Mega for where it's really needed. I've already got them though and I'm not using them for anything else at the moment, so I might as well use one for the stick for now and think about changing it later, when I get round to building my panels. Anyway, I'll have a play with the code and see if I can get anything out of it :)

Nope, the F16 stick is gameport based. The FFB2 is USB but I'll be using that just for the pots and wiring up a separate button box to use the button inputs from that, so the F16 stick buttons/hats will have to go through a separate device. I'll eventually be building panels and running them via the Ethernet shield using Arduino2DCS or some other bridge application, so I'm not sure it would be worth setting up a separate board as a USB device when I could use a shared Mega to run both some panels and the stick, although if I can use something cheap for just the stick it might be worth considering. I'm not sure what advantage there is from making the stick appear as a USB device though. Certainly using the Ethernet instead of USB avoids the issue of devices changing assignment when replugged and I understand there's less issues with bandwidth or something using Ethernet. This tutorial http://codeandlife.com/2012/01/25/avr-attiny-usb-tutorial-part-2/ is using an ATtiny2313, which I could pick up for about £2. It needs some other components but it will still probably be a lot cheaper than a Teensy 2.0. I'm not sure if the same thing could be done with a Mega and whether it would need all the external components or if the Mega already has those built-in, so I'd need a tutorial written for doing it with the Mega, or someone who can translate that one where necessary, if I were to try it. I'm seems like it might be a lot of work though, compared to just running an Arduino the normal way, via USB which shows up as a COM port, or via the Ethernet shield, and then using a bridge to translate between either of those into language DCS can understand.

OK, I have to admit I'm a bit over my head here and need some help adapting the code to my Arduino Mega. I might end up buying a Teensy or something else cheap to use with the stick, as it might be a waste to use a Mega for it, even if I do wire up the original FFB buttons to it but all I've got is three Megas (with Ethernet shields) for now, so I want to test it with that to start with. Comparing the pinouts of the Teensy 2.0 https://www.pjrc.com/teensy/pinout.html and the Mega http://arduino.cc/en/Main/arduinoBoardMega , I can see the latter uses pins 50-53 for the SPI (MISO, MOSI, SCK, SS), whereas the Teensy uses Pins 0-3 (SS, SCLK, MOSI, MISO). The only pin assignment I can see in the code is for SS: const int slaveSelectPin = 0; so do I just need to change this to const int slaveSelectPin = 53; for the Mega? Another thing to be mindful is that simFFB only allows for assigning a trim button from those on the FFB joystick, so if I wanted to use that (which I'm not sure about at the moment), I'd either need to add an extra button to the F16 stick which is wired to the FFB2 board, or disconnect one of the F16 buttons from it's matrix and wire it directly to the FFB2 board, assuming that won't mess up the matrix and stop it working that is.

It's all very well using dots/labels in SP but most, if not all, servers don't allow this. So there's probably a lot of people for whom MP is not an option and ED really need to try a find a solution to help the MP aspect grow and thrive.