mhe

Since 1.2.6 or so the clickable radio mod no longer works as simply as it did previously. There is a workaround by PeterP using a tool called AutoHotKey, but I didn't like that. So I settled with moving the radio text to the area on the touchscreen, but it is not clickable. I have made a customized Loz profile which reveals a block with the F-keys next to the radio messages in the area that disappears when pushing a mic switch.. I don't longer know the details of how I modified the files themselves, I have packaged that modification as a JSGME mod and only enable/disable it nowadays. I have to look what is modified - I use a vertical screen arrangement, so my files won't be much use to you in that case. UHF panel = UHF panel cover if I remember correctly. I am not at my flight sim rig today, so I can't look it up at the moment. Don't remember the ladder control name at the moment.

Hi there, The viewport names in the monitor config must match the names of the viewports the instrument init lua tries to send the output to. So for example, in your Gadroc-modified AN_ALR69V init lua, line 72 says vp = env.RWR So it is looking for a viewport named "RWR" in your monitor config. Renaming the files themselves does nothing as you will surely have found out. You don't have to touch the master.lua at all! It is the viewport name in the lua config and the viewport name in the monitor config that have to match. So in my file, you would have either have to rename "RWR_SCREEN" to "RWR" or change aforementioned line 72 to vp = env.RWR_SCREEN The Gadroc file you uploaded contains extra code to export it to an extra viewport, so it is a lot longer. You have to rename it and replace the original instrument init lua with it. There are several instrument init luas you have to replace (while you're at it, you might want to look into the JSGME tutorial by Ebs, makes modding DCS a lot easier and less time consuming, especially when updating, because the auto-updater will break your tweaks to original game files every time an update is performed). My file is actually not for the Gadroc profile but for Loz' 2.1 config (which looks a lot better and is in my opinion the best A-10C profile for Helios out there, find it here). The monitor config I posted you should work right out of the box with that profile on a 1920x1080 side-by-side screen config. Sorry, I simply overlooked "Gadroc" in the profile name, mainly because for me Gadroc is the guy who made Helios, but I always used the Loz stuff. The screen configs are similar but not the same. You can either use Loz' profile (which I highly recommend over any other A-10C profile out there) or you can tweak the settings above to match your config. Please also check that your overall DCS resolution is set to 3840x1080, fullscreen is disabled and that the Windows Aero interface is left running while playing DCS. If you disable Aero, performance with Helios goes down the drain. PeterP's tweaks with the aircraft name in the viewport is mainly there to make a difference between multiple aircraft, so one can switch between the Shark and the Hog without changing the monitor config in the options menu, so it is a nice comfort tweak. Files in different tutorials are not necessarily interchangeable, due to the flexibility of DCS there is usually more than one way to achieve something.

That should work nicely: _ = function(p) return p; end; name = _('Helios Touchscreen Side-By-Side'); Description = 'FullHD Main Screen + HELIOS Touchscreen Interface horizontal arrangement' Viewports = { Center = { x = 0; y = 0; width = 1920; height = 1080; viewDx = 0; viewDy = 0; aspect = 1.777778; } } GUI = { x = 0; y = 0; width = 1920; height = screen.height; } RIGHT_MFCD = { x = 3326; y = 120; width = 445; height = 445; } LEFT_MFCD = { x = 1987; y = 120; width = 445; height = 445; } UHF_PRESET_CHANNEL = { x = 2668; y = 477; width = 30; height = 30; } UHF_FREQUENCY_STATUS = { x = 2555; y = 565; width = 120; height = 30; } UHF_REPEATER = { x = 2576; y = 695; width = 110; height = 30; } DIGIT_CLOCK = { x = 2400; y = 828; width = 122; height = 122; } CMSP_SCREEN = { x = 2995; y = 190; width = 270; height = 70; } CMSC_SCREEN = { x = 2784; y = 141; width = 211; height = 50; } RWR_SCREEN = { x = 2514; y = 156; width = 186; height = 185; } UIMainView = GUI Note that the Viewport names (e.g. "RWR_SCREEN") must match the target in the patched instrument exports. So you might have to rename the viewports either in this monitor config or in the respective instrument init lua. I have an extensive tutorial written in another forum, but unfortunately it is in German. :(

Didn't know it went that far. What were people thinking? "You need to be motivated to do great work - so I'm here to demotivate you just because I feel entitled and want my stuff NOW!" :doh: This was exactly what I meant. Giving constructive criticism is one thing, but harassment and threats are simply a shame and I would assume this kind of behaviour is what keeps some developers afraid of being open and direct about things. Actually, the entitlement/harassment crowd is worse at communicating than the developers they blame. The customers have a need they want to see filled and their only known way of asking for it is in a way that makes it highly unlikely that they get what they want. Everybody loses that way.

I don't say that SOME of the problems pointed out so far are not legitimate, of course they are. The point I was trying to make is that no matter what a developer does, there will be always someone who gets pissed of for some reason to the extent of throwing tantrums, which nobody benefits from. I have had my P-51 key for a long time now - not that it matters, I had the aircraft for much longer and simply gifted the additional key to a friend - and the Skype thing doesn't affect me. But yes, they made some promises they didn't make good on as of yet. But I assume this is not intentional. The problem is they are behind schedule and they have a lot on their plates now with demands coming from several directions simultaneously. Once you are behind schedule, you only can do so much. It is perfectly understandable that people are disappointed, but the anger or demands directed at RRG at the moment do nothing to remedy the situation. A more constructive way would be to offer help as much as we can - regardless of the "paying customer" dogma. If I want my stuff quicker, then it is best to let the guy responsible for delivery do the work and perhaps sometimes ask for status reports (which we get, but not at intervals on par with everybody's expectations I guess), but flooding him with inquiries just because I am impatient does not help me get things quicker. One may feel entitled to something or don't, but the feeling of entitlement does little to change reality. tl;dr: The shit has already hit the fan, let's try and clean up the mess instead of making even more of it.

Of course the progress is not as quick as some people would like, nevertheless they are making progress and keep us informed of it. Large projects like this can be frustrating, especially so if there are a lot of factors at play that you only have limited or even no influence over (like EDGE progress perhaps). If people want their stuff on time and no delays, crowdfunding might not be for them. It is the same old game. If you say nothing, people complain about the lack of info or interaction. If you say something, people complain because you said something different that they wanted to hear. It is simply impossible to please everyone, so why blame a guy for not attempting the impossible? Of course there were some mistakes made like the surrealistically optimistic timescales, but I doubt there is a way Ilya could make up for it so that the whining stops. Not to offend anyone, but bitching and whining seems like an integral part of the simmer community to me - a and I've been flying virtually for over 20 years now. Funny how some things change and progress over the years and other things stay the same. Very much looking forward to the Beta!

Why not have a Beta and let us tweak it and gather some performance stats on various setups? I can imagine that the speed might have something to do with video memory, DCS is eating VRAM like crazy on higher settings. Given the much higher detail in the EDGE footage so far, I would suspect it to be even more extreme in that regard. Not many people have more than 2GB of video memory for a single screen setup, so that might be a reasonable goal to optimize towards. I wouldn't mind to have to go crazy on hardware to have the best DCS experience possible, but a lot of people wouldn't be willing or able to put that kind of hardware into their rigs just to fly. It is a hobby after all and budget is definitely a point to keep in mind.

I do remember these screenshots, or at least some very very similar to those. As far as I know this is just beautifully tweaked profile for the ENB series mod. Adds a lot of niceties to DX9 graphics engines via DLL injection.

The good old Supermicro servers. Worked with that stuff back in the day. The ones lower with the blue parts are Chenbro cases, several manufacturers used these. That tech was more or less the budget solution back then in approx 2004. If I look the servers I work on now, they have several orders of magnitude more power in about a quarter of the rackspace. And given what can be done graphically today, no footage we've seen so far is impossible on consumer hardware at the moment. If there are some impossibilities, I would assume them to be more on the CPU side.

What bothers me a bit is that Wags himself said in November that it's "that last 10%" that. Perhaps I'm reading a bit too much into it, but it would indicate to me that it is at least close to be complete (whether this means feature complete, release complete, ready for alpha/beta/whatever I do not know), but it is little things like this that make the long wait all the more painful. Since I didn't have the Warthog Beta, I'm not entitled to anything regarding the terrain in question, but I would gladly throw money at ED for that new map and a more modern IG. And I don't even demand they make it cheap. The price of a full DCS fidelity module would be completely justified for an area the size of Nevada. I think the price level in the flight simulation world for scenery is pretty reasonable most of the time. The Hog and the civilian PMDG planes for FSX/P3D are on par with each other detail-wise, the PMDG stuff costs twice as much, just saying. If anything, I might argue that if we'd pay higher prices for that stuff, ED might have more staff/resources to bring us the stuff we want quicker. As Sobek's signature correctly states: "Cheap. Fast. Good. Choose two." Since we get great products an we get them cheap, demanding to get them fast on top of that seems a bit drastic to me. So ED, bring it on. My wallet is ready.

Nice! May I ask which printer you are using? And good choice on the Taulman Nylon, incredibly tough stuff. Do you print these parts solid or what infill percentage is used?

That's a shame, hope they get a working one to you asap. Flying the Hog with proper controls is a joy to behold.

SoftKinetic might solve our problems with switchology in VR, here is an interview about the tech: http://www.roadtovr.com/softkinetic-aims-help-us-reach-virtual-worlds-interview/

Ah, sorry, I read that wrong, it was a loooong day... In that case, just go into the game controller settings in the Windows system settings. There you see whether the system recognizes the mini stick movement. If it does, your problem is in DCS, if it doen't, the problem is with your throttle.

I haven't used an X52 for quite some time, but from the past I remember that the small mini stick actually moves the mouse. Perhaps you can make it appear as a real stick to DCS rather than a means of moving the mouse cursor? As long as this mouse emulation is running, I doubt you can assign it to HOTAS slew because you can't do that with an actual mouse.

Of course - the saitek nipple (I won't even call it a stick) sucks. Agree with what you were saying. Because of calling it mini-stick I like many people maybe associate it with the slew function of the Warthog's throttle. And you don't want to have slew on a trackball. But a trackball is great for moving the mouse in the cockpit, no doubt. Cyb0rg: Your Youtube link is broken. ;)

Either these or the "Slaw Device". Both are brilliant.

Your memory serves you right, they don't make them anymore. The guy who designed and produced them passed away and his family didn't want to continue the business with the pedals.

For me the first addiction was Strike Commander and some Jane's stuff, later followed by MSFS. DCS brought me back to my roots, military sims.

Congratulations on your rig! :) But be warned, you get used to that kind of performance...

If you have a finite size surface to with, a first order input device as a mouse is great. If you have to steer something over an more or less infinite area, second order input devices (e.g. sticks, directional pads etc.) are better most of the time. So a trackball for the virtual cockpit makes sense, the "canvas" you work on is not too big. But a trackball for TGP slew would suck balls imho because it would be impossible to maintain scroll speed over some distance.

I can't blame ED for not providing as many updates as we'd like for various reasons. 1.) There can never be enough updates on a product as highly anticipated as EDGE 2.) If they give us no info, we complain 3.) If they give us info, we either complain that it is not enough or the info contains something we complain about (dates, prices, whatever) Regardless of what they do, whining continues. And hey, look, I'm complaining about complaining! WHINECEPTION! On another note: Can I please have some more EDGE screenshots or videos pretty please? :D</irony>

That's much better, thanks!

Skate, the link is broken.

Never tried if it makes any difference, but you might have switched from laser to IR pointer with DMS right short? Never tried if autolase is able to override it if you set the TGP pointer to IR, but it's worth a try I think?