NickD

Older? It's dated October 2016?

It was added in some patch within the past month or so. I'm assuming that 2.0 isn't updated yet.

This is especially true, as the actual rules are something like the following: "3DS and Blender use Z-up, the game uses Y-up for coordinate axis (and Z=-Y when converting). Data is saved in the EDM file in game-space, unless it is animated, in which case it is saved in 3DS-space, and a base argument of the animation is used to flip the geometry into game space. UNLESS it is an animation that is also animated by a different animation, in which case the base animation argument DOES NOT flip the axes." This is also made more complicated by the fact that the actual parameters of animation (all in 3ds-space) have to be applied in the correct way. Combine this with the fact that there is *no* documentation on how the format/dcs internals work, and you can see something of the problem (there is still an animation rotation parameter that I have no idea at all what it does). Without the modelviewer and a way to actually quickly view the attempts (and modelviewer's useful crash messages) it would be much, much harder to decode.

Enjoy! You didn't list it, so I'd probably say the most important thing is a HOTAS - barring the very few occasional commands (that you can peek out under the nose for) you don't want to be relying on the keyboard. But with a brand new system like that I'd assume you have/left room in the budget for one :) For FC3 craft without clickability, I find Voice Attack can also be useful - I use it as an alternative to binding commands you really only use once or commands with several variants (e.g. all the different kinds of autopilot, "start engines", "close canopy"). No idea how well this works for other craft; though I know of things like VAICOM I only use simple comms voice commands ("start comms", "one", "two", etc) currently.

a) You wouldn't need to, necessarily. A list of changes for the user to apply wouldn't be distributing anything of the original file. b) I don't see that in the EULA. In fact, the terms "edm" and "3ds" don't actually appear in the EULA. In fact I was referring to the sticky post stating Regarding the edm files - although I'm not sure how official that statement is (AFAIK Skatezilla does not speak officially for ED usually?) - for a start, modding is basically impossible without copying parts of the lua code, legal ambiguity with api calls notwithstanding. And I believe I've seen at least one popular mod distributing the FC protection dlls - perhaps it's not possible to use the flight model without it?

Hello! I'm wondering what font's you've used for this?

This has been some fascinating replies! Thanks all! Warhog: I see all your buttons look like they are acrylic - a lot of the panels e.g. UFD look like they are the 'rubberized' style of button - have you looked into manufacturing it like this directly? I imagine (in my naivete no doubt) that you could cnc the rubber, and if it had a conductive back/could be painted then you'd eliminate the step of having to solder every switch? Looking at your backlighting posts, you put the lights on a separate PCB. Is there a reason that you aren't just using a double-sided PCB for the same purpose, and reducing parts? Annoyingly, the "Two threads" you link in https://forums.eagle.ru/showpost.php?p=2690141&postcount=7 are just the same thread... any idea what the second one you meant to link to, was?

You could always have the collision shell hovering just above the water?

Which is this "Law" you are referring to? I suspect the rule against distribution of ED Assets?

Oh, I wasn't blaming SteamVR for the DCS performance issues, only the exact fact that the update I linked to specifically introduced the annoying dialog box that we've been seeing where before, the framerate would just slow down. I'm pretty sure CPU is the limiting factor with DCS world because e.g. it is an ancient single-threaded engine with out-of-date draw idioms (if the batch-drawing hyperbole is to be believed). This is a completely understandable problem, as AFAIK the current implementation directly dates back to at least 2009/10? (Thinking original Black Shark), and up until now the engine could keep pace with graphics card development. All of a sudden, there is a leap from the high end users being happy with an average 60fps all the way to 90fps, from two perspectives instead of one. Sure there is lots of things that could probably be done, but from the sparse updates I get the impression that VR support is probably just a single developer, (probably who owns an Oculus rift), who works on VR support as a secondary-priority task.

In which way? The purpose of the program as a whole, or the specific update things I'm talking about? If the latter, I try and explain in regular edModelTools terms when I release an update. Or was there something more specific?

Minor update to this - I have not been idle! A couple of bugs and incompatibilities with older versions of Blender led me to provide a couple of interim versions: https://github.com/ndevenish/Blender_ioEDM/releases/tag/v0.2.2 I've got most of a new release in place, including lots of bug fixes, new documentation, LOD import/export and UI (preview: https://ndevenish.github.io/Blender_ioEDM/modelling/lod.html), Damage arguments, connector writing and mostly simple hierarchies are working properly (almost solved the problem with hierarchical animations). I just have a load of testing to do to make sure that I haven't messed up the exporting!

This was basically the entire motivation for me starting my Blender Import/Exporter: https://forums.eagle.ru/showthread.php?t=178430. The published release version doesn't yet load the A-10C cockpit, but if you know how, the in-development version should load it, and direct measurements can be taken on the actual in-game model (I don't believe there is any in-game scaling usually, but there potentially could be, so you might need a separate reference length).

I'm considering getting into homepit construction, mainly for VR but I have a problem of wanting it to also look good... I was under the impression that most of the panels people produced were e.g. Aluminium with silk-screened text, but lately have seen lots of different sources where they can be backlit - and the only thing I can imagine is a very thin aluminium layer bonded to a translucent plastic layer and then drilled into with e.g. a CNC router. And this seems like it would be very hard to get good quality text, especially with the insides of letters like "A, O, e" etc. Except the style seems quote common. What am I missing? What sort of processes are normally used for these panels?

This is, indeed useful, but you can do this entirely within DCS, right?

It's actually a drawing as I couldn't work out how to take a screenshot of it - it doesn't show on the desktop. I think I narrowed it down to a SteamVR patch on the 4thhttps://steamcommunity.com/games/250820/announcements/detail/276242807866324750: It's be really nice if DCS worked a little like e.g. The Lab and automatically scaled the pixel density according to average performance, but then that'd have to go on the back of a long list of engine improvements that they aren't able or willing to implement, currently.

Hmm, does it look something like the attached image? (background is my vive lobby, which might be black for you). Because I'm trying to work this out also; it only started happening within the last month for me (whenever framerate drops, it switches to this which only exacerbates the problem because now instead of a dropped frame the view flickers like crazy back and forth).

So, I haven't used my vive for this in about a month... When I just played to try out the new zoom (bit weird, but okay - snap might be better) I find that now, whenever the framerate drops, the entire image disappears to the vive "Lobby" space, with a weird hovering dialog with three pause-like-looking bars. This is particularly noticeable whilst zooming, as the image flickers back and forth to this. Any idea what is causing this/a solution?

Right, but this is self-inflicted, you presented it as though you HAD to spend $150 on adapters to actually get your HMD working, and that it was HDMI's fault. And I'm still not sure what this has to do with the Vive anyway, and why you'd expect a massive redesign eight months after the original launched. Except you were implying that HDMI fees had something to do with making the units costly. And I'm sure that as time goes on and the options mature the VR manufacturers might pick them up, if it makes economic and engineering sense - not because they have been "Limiting themselves". Tiny proof-of-concept manufacturing runs don't prove anything about long-term feasibility/yields/lifetime, and I can guarantee that lots of extremely smart people (a) spent a lotlonger than anybody outside the VR manufacturers thinking about the advantages/disadvantages of every alternative, and (b) are continually evaluating new options that come up. But certainly don't expect fancy brand-new low-volume VR-only screens to drop the price (which is why you were saying they should). They are expensive because they are a niche market with massive amounts of up-front R&D, as well as the hardware (which includes the lighthouses for the vive). Right, I don't think anybody spending up to £1000 to get the Rift/Vive (assuming touch controllers makes them mostly parity, and including the cost of a graphics card capable of doing it justice) is under the impression that they aren't early-adopters of a first-gen technology. But it's still amazing.

Which was five weeks ago - way too short a timescale to be integrated into any current product development. It also doesn't mention costs - which for a cutting edge display type could easily be much more (I assume that if the point of the display was low cost, then they would have advertised that fact in the press release).

Yes, they'd need to custom-manufacture displays AND the controller boards, which I'm sure would not be a massive expense that would increase the price of the units. How on earth would adding the R&D make things cheaper? At least using standard parts they can just sit and wait around until the rest of the market makes the displays cheaper and drop prices accordingly. Or are you one of those people who thing summing the literal cost of parts together gives you the "real" cost of a device? Which are apparently < $0.15 /unit to throw away one of the most common video connectors in the world. Great saving! Source? As far as I'm aware, the problems cards were having were mostly driver-fixed. And as for older cards, I thought almost universally the minimum recommended setup is GTX970/equivalent? Also, I have no idea about the Oculus but the vive supports both DP AND HMDI. It's convenient because it's less disruptive on anything else you might be plugging into. And there seems to be more issues reported with displayport side of things anyway (I had a driver issue at the start regarding both hdmi/DP in use, but they fixed that in an update). The displayport standard wasn't even finalised until 2006, and the first devices only appeared in 2008, before the first GPU's. It was certainly a few years before it became common. So 2005 is a complete fabrication. That's... insane - that's like 1/3 the price of actually buying a modern card. Why on earth was it that expensive for you rather than just a £10 cable?

I'd expect if anything, minor changes to shell/construction, and perhaps a small price drop. It's cutting edge stuff, and computing power barely exists to run the current generation, let alone anything higher rez in a mass-market affordable way. I mean GPU-supported techniques like foveated rendering might help, but existing applications don't even use the vr-specific tech in this generation of graphics cards, so that's certainly a way off.

No, exactly the same - the scripts are hit, the custom device gets updated, but no luck with the UI elements. Edit: Even tried with a separate, unused animation argument - in case the gear lever was reassigned/protected or something. No luck either.

Right, but most of those are full-size (e.g. diameter = 1.0m) dummy objects for positioning e.g. to tell the center of the TV, HUD, etc. It seems connectors used for buttons are actually sized so that the whole volume of the box is covering the switch position like in the attached screenshot. Also, I forgot a couple, there is actually eight - a light on the right and the vent/fan switch under the fire panel. You are right about the F-15 though - it looks as though at some point there was an effort to make connectors for every button, but was never followed through with proper clickability. Hmm, thanks - this appears to me to be exactly the steps that I am following. I've noticed that the SU-25t/FC3 aircraft tend to have nil for their flight model in make_flyable... perhaps this is a special case that overwrites the clickable data? The F15 actually seems to have it's flight model specified in lua, I'll see if the same process actually works for that aircraft.

Of the right sort of connectors, I think the SU-25t only has six. But still, ignoring the possibility of expanding this, that's still six extra buttons that don't need to be bound on the HOTAS. I'm just trying to work out what's stopping this from working. Are there *any* examples of community aircraft with even partially clickable cockpits? I keep cycling back round to Wunderluft, which, depending on which version you get linked to, has various parts out of date or just never implemented.