NickD

In the code I posted, or the Su-25t cockpit? As far as I could tell, the link to connectors happens in clickabledata.lua and this looked like the right line: elements["PTR-TMB-FIRE-R-PK"] = default_2_position_tumb("Landing Gear Control Handle",devices.TEST, device_commands.Button_1,83) With the table entry being the name of the connector? Edit: And the SU-25t connectors I'm talking about are the ones in the attached screenshot; I don't know how to get modelViewer to show them as volumes rather than points, but they seem to align well to the button sizes.

Is it at all possible to mod clickability to an existing non-clickable cockpit? e.g. the SU-25t. I'm aware of the arguments regarding complexity of modelling aircraft systems, but this isn't what I'm after - only convenient control of things like e.g. landing gear - which is only used once or twice per flight and when space on the HOTAS is at a severe premium, like when using VR, it'd be nice to be able to look at the obvious lever and press a single button. If the problem is model support e.g. connectors, well the SU-25t has at least one panel with connectors hooked up (the left fire-control panel) that could be used as a simple surrogate, and otherwise it might be possible to add them in afterwards (the model viewer certainly seems to have a section for user-defined connectors). As an exploratory first step, I started trying to at least get the connectors recognised on the SU-25t with an empty device. Here are the files I added to the Cockpit/Scripts folder (after studying the TF-51) to try to get a single test device registered and associated with the button: device_init.lua print("Reading device_init") mount_vfs_texture_archives("Bazar/Textures/AvionicsCommon") attributes = { "support_for_cws", } --------------------------------------------- dofile(LockOn_Options.script_path.."devices.lua") creators = {} creators[devices.TEST] = {"avLuaDevice",LockOn_Options.script_path.."test_device.lua"} --------------------------------------------- -- defines kneeboard device - if not last, risk overwriting the definitions and the game crashes dofile(LockOn_Options.common_script_path.."KNEEBOARD/declare_kneeboard_device_left.lua") devices.lua devices = {} devices["TEST"] = 1 command_defs.lua device_commands = { Button_1 = 3001; } clickabledata.lua print("Reading clickabledata") dofile(LockOn_Options.script_path.."command_defs.lua") dofile(LockOn_Options.script_path.."devices.lua") cursor_mode = { CUMODE_CLICKABLE = 0, CUMODE_CLICKABLE_AND_CAMERA = 1, CUMODE_CAMERA = 2, }; clickable_mode_initial_status = cursor_mode.CUMODE_CLICKABLE_AND_CAMERA use_pointer_name = true -- Taken from some other TF-51D clickabledata function default_2_position_tumb(hint_, device_, command_, arg_) return { class = {class_type.TUMB,class_type.TUMB}, hint = hint_, device = device_, action = {command_,command_}, arg = {arg_,arg_}, arg_value = {1,-1}, arg_lim = {{0,1},{0,1}}, updatable = true, use_OBB = true } end elements = {} -- anim 83 = landing lever, range 0-1 elements["PTR-TMB-FIRE-R-PK"] = default_2_position_tumb("Landing Gear Control Handle",devices.TEST, device_commands.Button_1,83) test_device.lua local dev = GetSelf() local update_time_step = 0.1 make_default_activity(update_time_step) local sensor_data = get_base_data() function post_initialize() print("post_initialize called") end function SetCommand(command,value) print("Lua test_device SetCommand") print(command) print(value) end function update() print("Custom lua device update") end All of the print statements get hit in the right place, the cockpit starts in clicky-mode, and the custom device gets time-based updates - but there is no recognition of the clickable area (cursor color or highlighting) and so nothing to even trigger the device SetCommand. Is there something obvious I have missed, or is there some important reason this will never work anyway?

We do? When did this go in? I must have missed it.... must get back to flying rather than just working on modding/modelling. I absolutely love my Vive - VR is basically ideal for this genre. The only (minor) negative is that it will really test your HOTAS binding abilities on planes without full clickability.

So, minor update; I've added the ability to designate geometry as collision shells. The world objects are no longer restricted to static, uncollideable geometry. As an example, I've attached a screenshot of what now happens if you try to drive through the giant monkey head on the runway (It also shows properly in versions of modelviewer that are capable of rendering collision shells). Other major changes: Collision shells can now be exported with the model Reads the new v10 .edm files in 1.5 (at least at the moment) Specularity should be properly mapped so not everything is automatically super shiny There's also been a lot of background work towards the hierarchical animations, but that isn't working properly yet. I'm not sure the exact lua code, but with collision shells it should be possible to have e.g. static, destroyable geometry/targets, which I imagine covers a lot of the basic modelling use cases. https://github.com/ndevenish/Blender_ioEDM/releases/tag/v0.2.0 I'm thinking of making LOD the next priority, for similar reasons - even though It looks like that can be specified through lua code and multiple models, I'm sure it's convenient to have it embedded for simple cases.

Well, animate the vertical position 10ft down then :smilewink:

Excellent! Make sure you look at the working branch, and feel free to contact me via pm/twitter/github if you have any questions.

I have been actively working on it (on a branch) but have been having serious trouble getting the export correct for hierarchies - I think not properly understanding the order of transformations/role of all the transform values is seriously hampering things, as well as having a lot of trouble with the rotation/scale degeneracy with negative scales. For now I've switched to things like collision meshes, because that's probably a more basic fundamental. Out of a technical perspective, I'm curious what you consider "Impossible" tasks that Blender cannot support? It'd be nice to have a view of what the more complicated aspects of EDM modelling are. Edit: Especially since simple keyframe position/rotation animations are already being exported?

Slightly crazy suggestion: if all else fails and it's that difficult; couldn't you just add an animation with two arguments that yaws and pitches the whole model, and fix the animated position to whatever works?

I'd rather this thread not descend into arguments/recriminations about 3DS or studios that exclusively rely on it - I'm sure 3DS is fantastic and that there is plenty of reasons to still use it exclusively, but I for one a) Aren't a student any more b) Can't afford or justify the price for 3DS and C) don't want to pirate it. I'm sure there are plenty of talented modders/artists/engineers that fall into these three categories, for which this at least starts to open a potential avenue; and I feel it's been well demonstrated that a good modding community thrives not just on the most skilled modders, but with a wide 'halo' of smaller projects with which people can "scratch their own itch".

Update: A reminder about this plugin: e.g. ED's models and intellectual property remain their own, this changes nothing about that. --- After starting playing DCS in VR I wanted to measure exact panel sizes on the SU-25T in order to be able to build a replica autopilot panel, so I started poking the .edm files. It somewhat spiralled out of control. This is a HIGHLY EXPERIMENTAL, completely UNOFFICIAL attempt at building a .edm exporter for Blender. There is currently very basic import/export functionality, handling basic position/rotation keyframes and single texture diffuse mapping. Lots of things don't work; this includes, nonexhaustively; bones/skinning, in-file LOD, collision shells, scale animations and exporting anything that uses a parent/child hierarchy. Modelviewer reads the exported models fine, and with the core functionality the game reads the models fine without complaint. While it doesn't have a lot of features, what it does let you do, is make simple models to test in the game without having to own an (old) version of 3DS. As an example, here is an in-game screenshot of something you hopefully don't see on the runway every day: (for those not in the know, 'Suzanne' the monkey is Blender's version of the classic teapot - a reasonably complex test object that it includes with all of the other primitive creation). An ultra-simple mod that adds this as a 10m high monkey head ('Suzanne' under 'Structures' in the mission editor), as both a simple JSGME-ready mod example, and a proof-of-concept using Blender models can be found attached. In its current state it's probably mostly of interest to hybrid developer/modellers who know a little bit about using blender internals or programming 3d - as with everything else about it, there are certainly no guarantees as to the fragility of model/material settings that it will handle without just failing to export, so I present it merely as a proof-of-concept rather than a complete modelling solution, for people who can't access or afford 3DS max 2014. Like Blender, it's open source, and is available on Github: https://github.com/ndevenish/Blender_ioEDM/releases/latest And more details can be found in the projects README and spec files. I'm not very experienced working on models for DCS - so I'm not sure whether there would be any interest in this at all. And other than working on the hierarchical animations (using tests/MonkeyCannon.blend as a self-generated example) I have no idea what any future wishes/priorities might be - remembering that this isn't for hard-core game-feature-pushing models. But I hope it proves of interest to somebody.

IIRC the latest modelviewer download is usually based off of nightly builds, and so there is a good chance that it is broken. Going back a couple of months of versions normally works or yes, using the version included with the game - or using the last verified version (115338 as of writing).

For at least simple model insertions, you don't actually need to edit the game databases - If you search the Scripts/Database luas you can find the source for 'add_surface_unit', which goes and adds the unit to all existing countries. With a simple directory structure in DCS World\Mods\tech\YourModel: \entry.lua \Shapes\YourModel.edm \Textures\someTexture.jpg And with entry.lua as: mount_vfs_model_path (current_mod_path.."/Shapes/"); mount_vfs_texture_path (current_mod_path.."/Textures/"); res = {}; GT_t.ws = 0; set_recursive_metatable(res, GT_t.generic_stationary) set_recursive_metatable(res.chassis, GT_t.CH_t.STATIC); res.chassis.life = 10 res.Name = "YourModelName"; res.DisplayName = _("YourModelName"); res.Rate = 1; res.visual.shape = "YourModel"; res.DetectionRange = 0; res.ThreatRange = 0; res.mapclasskey = "P0091000076"; res.attribute = {wsType_Ground,wsType_Tank,wsType_Gun,wsType_GenericFort, "Fortifications", }; res.category = "Fortification"; add_surface_unit(res) I've found that I can add static models in under any country, under the "Structures" category in the mission editor. This is from an amalgamation of posts I've found, and I can't yet explain the significance of much of it, but it seems to work. After working this out I found Joey45's post https://forums.eagle.ru/showpost.php?p=2654760&postcount=4 but that also seems to have some plugin-definition code, and I'm not sure where/what that affects (I've never seen a plugin management screen in game?). So haven't included it here.