dwpenney

Can you add me to the list as well?

Yeah I would love to see the STL to get an idea how you broke that model up into individual pieces to print and assemble. Very nice job!

My understanding from previous posts in the thread is that he is using ABS with and acetone vapour cleaning. I need to get an enclosure for my Ender 3 before I can get to ABS printing :-)

I may have it 'fixed'. I was using a powered USB hub but going direct to the motherboard has it working! Woo!

If it helps, here is what I have: And what I am seeing in the VKB Button Tester: And in DCS (not the Alt was as I was alt-tabbing to get the screenshot):

I think I understand. I named my device MBB_V01 and that column shows up in the DCS device list. I select that and try to map something and it does not respond. I am not sure of any way to trouble shoot this.

May be a stupid question but I thought I would ask here (instead of beating my head against my desk :-) ). I have my hardware all constructed and set up with MMJoy. Firmware loaded, config loaded and everything works in the Windwso and VKB Button Test Utilities. However, when I go into DCS ... it 'sees' the MMJOY device but does not seem to accept any button presses from it. I can manually map a button (ex: selected Master Caution in the F-18C, went to the MMJOY column, selected assign and selected button 4 from the drop down) but in game nothing from the MMJoy device responds. Is there some magic sauce I need to use? EDIT: It is a Teensy 2.0 USB device.

Same here :-)

Did you try removing the shaders (and when you restart DCS, it rebuilds them)? Try removing the following folders in your Saved Games folder: c:\Users\<your_user_name>\Saved Games\DCS\fxo c:\Users\<your_user_name>\Saved Games\DCS\metashaders2 And the next time you start, DCS will rebuild them. Looking through your log, I see that the EDCORE is dumping a stack trace that mentions AmsDxGsaFreeCompiledShader. Everything else looks 'ok'.

This is a pretty awesome project. I have been considering a switch box of my own and this thread has given me lots of ideas! How are you doing the electronics. I see that all of the boxes are connected by a 'bus'. Is that encoded somehow? In my box I was (am) considering shift registers to handle all of the buttons but yours has waaay more than what I have at the moment (30 buttons). Curious about how you are collecting all that data electronically. Plus, would love to eventually see the STL files in the future, however you want to make them available.

Could I offer a suggestion? Maybe a comms entry in the Carrier Info menu section for a Comms check. LSO could respond "5 by 5" or something. To make sure that the sound files are loaded. I'd like to find a way around having to add all those triggers by having some other script load them all at mission start.

Love it! Thanks!

These work for me: https://www.amazon.ca/gp/product/B0085I4D5C The link shows as unavailable (and I would not recommend this seller as the FedEX charges on receiving the package in Canada were excessive. There were caps thrown in with the devices, however, so that was nice.

Great to have you there! :-)

A little shameless plug for the Mudspike DCS Fall Fly-In that concluded late Sunday night. Not sure if RAZBAM knows about the site but there were a lot of people interested in flying and fighting the AV-8B in DCS 1.5.8. I was surprised at just how hungry people were to fly the Harrier! Sure, there were a few bugs but overall I can not remember anyone being unable to take part. We had a lot of people join and help each other out over the weekend, patiently learning the systems, the flight dynamics and how to implement the Harrier as the pointy end of the stick. Well done RAZBAM! Some great screenshots of the AV-8B over here: https://forums.mudspike.com/t/3rd-dcs-fly-in-screens-aars-thread/5179 I apologize if this seems like a self-serving thread but I wanted RAZBAM to know that their AV-8B was the star of the weekend and I did not want to reproduce all of the screenshots over here.

Just a guess but I would assume that you are moving your neck when attempting to 'roll' on the z-axis. Basically there are two ways to roll your head: 1) at the base of the skull; 2) farther down your neck where it meets your shoulders; With a Track Clip Pro, you are correct that it is on the side and will induce some level of yaw. You can mitigate this by rotating from the base of your skull as the TrackIR software takes into account this distance from the rotation point. You can try what I am talking about in the TrackIR software as it displays the axis and the disembodied heads. With the track hat the same issue should exist .. just in a different axis. The farther the sensor target is from the centre of rotation the more of an affect it will have on other axis.

Mudspike has a review up for each: Virpil VPC Mongoos T-50 VKB Gunfighter Pro (bundle with Knuppelgriff KG12) Disclosure: I wrote the VKB review.

Ooo. Any idea if we can export the display? That would make a cool home cockpit device add-on.

Do you know how the size (length) compares with the Thrustmaster Warthog stick? I am also curious about the hand rest and if it is removable/upgrade-able (thinking of potentially 3D printing a different version of the hand rest that may give more flexibility)

Hey FlightControl! Great work BTW! Now the questions :-) I am trying to task an air group to go to a given zone with the CONTROLLABLE:TaskRouteToZone() function. But ... it does not seem to work for air groups, only ground groups. Is this as intended? Are many more of the CONTROLLABLE class functions only usable by ground groups? In my case, this is what I am getting when I use the following code: do -- Set up the pool of spawnables based on the RED #001 group PatrolSpawnPool = SPAWN:New("RED #001"):InitRandomizeRoute( 1, 0, 50 ) --PatrolSpawnPool = SPAWN:New("RED #002"):InitRandomizeRoute( 1, 0, 50 ) if PatrolSpawnPool == nil then env.error ("DVD: PatrolSpawn is nil - the pool of groups we are spawning from.") end -- Grab the group whose path represents the 'polygon' PatrolZoneGroupRef = GROUP:FindByName( "PolygonZone #001" ) if PatrolZoneGroupRef == nil then env.error ("DVD: PatrolZoneGroup is nil - Could not find the PolygoneZone #001 group.") end -- Create the ZONE_POLYGON based on that group --[[ PatrolZoneRef = ZONE_POLYGON:New( "Zone #001", PatrolZoneGroupRef ) if PatrolZoneRef == nil then env.error ("DVD: PatrolZone is nil - Did not create zone from the Patrol Zone Group.") end --]] PatrolZoneRef = ZONE:New( "PatrolZone #001" ) if PatrolZoneRef == nil then env.error ("DVD: PatrolZone is nil - Did not create zone from the Trigger Zone.") end -- Spawn the instance from the spawn pool PatrolGroupRef = PatrolSpawnPool:Spawn() if PatrolGroupRef == nil then env.error ("DVD: PatrolGroup is nil - The group was not spawned.") end -- Assign the route PatrolGroupRef:TaskRouteToZone (PatrolZoneRef, true, 500, "Cone") env.info ("DVD: Patrol Group has been sent to the Patrol Zone Group zone.") end This is using the code from GitHub as of last week. The error I am getting is the following: 03876.854 ERROR DCS: Mission script error: : [string "C:\Users\penney\AppData\Local\Temp\DCS\/~mis00002DCF"]:15733: attempt to index local 'UnitPoint' (a nil value) stack traceback: [C]: ? []:15733: in function 'GetVec2' []:14611: in function 'TaskRouteToZone' []:40: in main chunk In my test mission, RED #001 is an aircraft and RED#002 is a ground unit. If I use RED #002 it works and if I used RED #001 it does not. Also ... a general call to all MOOSE developers. Is anyone using those CONTROLLABLE functions to create routes for air units because I would love to see some example code that implements those calls :-) Thanks for working on this framework FlightControl! The potential is huge! I have been working on making some dynamic missions for helicopters and fixed-wing aircraft and as I am learning the framework, a lot of the tediousness of working in Lua has been taken away!

It's a way around the multiplayer issue of creating a menu for a client that has not logged in (ie: nobody is occupying the slot). If no one is occupying the slot, you can not (I think) set the menu for that particular client. You can use the global menu (ie: game, or coalition) no problem. That means if someone was to join that slot with the mission already in progress their comms menu would not be complete. A hack around this is to rebuild the menu every little while. I am thinking that there may be a way to set the menu once at the mission start and then detect players joining with the ON_BIRTH event to set the menu at that point - to get around both issues but I have not had time to try this in/with MOOSE.

DCS 1.5.6; I am running into a weird issue with regard to MENU_CLIENT_COMMAND. I realize that the client code is only partially working until the final few related DCS bugs are addressed but I was using the example code in MOOSE as a baseline. So, here is what I was doing. I was creating a training mission with 4 client player aircraft and I was choosing one of those (by name) as the training master. I wanted this client to have access to menu commands to spawn adversary aircraft on command while the other 3 client player positions were for the trainees. I used the same method in the MOOSE test missions: create a scheduled function call to generate the menu items every 30 seconds. The function would create/re-create the top level Flight Lead Commands menu item with a Spawn Active and Spawn Passive menu under that. In each of the Spawn Active and Spawn Passive menu options would be the actual spawn commands. In this case there were 8 of those. Going through the menu would be like this: F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F1. Spawn Su-17 Defensive; F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F2. Spawn Su-17 Offensive; F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F3. Spawn F-5E-3 Defensive; F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F4. Spawn F-5E-3 Offensive; etc The menu items were created correctly with the correct names. The problem was that, randomly, the list would be reversed but not reversed in the F10 menu. Normally, following this chain would spawn the first item (F10 -> F1 -> F1 -> F1) and this would spawn the last item (F10 -> F1 -> F1 -> F8) but every now and then the items were switched even though the menu text was not switched. Meaning that the following sequence (F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F1. Spawn Su-17) would actually execute the expected result from this sequence (F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F8. Spawn Mig 29); This is weird and I could not figure out if it was a MOOSE issue or if it was related to DCS. As I understand it, the pattern portrayed in the MOOSE Test code creates a scheduled task to create the menu hierarchy and this hierarchy is recreated each time that the scheduled function is called. Sometimes it seemed that although it was creating the list in the correct manor, DCS was interpreting the underlying calls to be in the reverse order. DCS would display the menu in the correct sequence but when the sequence was called it would be, in effect, reversed. I was wondering if that seemed plausible from the MOOSE framework point of view. I was thinking that maybe I was hitting a spot where I was accessing the menu items at the same time that it was being re-written so I extended the time between the scheduled function calls and could reliably get the right spawns about 70% of the time. Weird? In the end I removed the scheduled function calls to create the MENU_CLIENT_COMMAND and replaced it with a static global set of MENU_MISSION_COMMAND calls. I will attach my code but I would guess a mission would be better? The commented code at the bottom replaces the code just above it. I do not think it is the MOOSE calls as I am using them sequentially and unless MOOSE is caching them (?). Instead I think that it may be related to the nature of having a scheduled function replace the menu structure every 20 seconds or so - ie: replacing the menu structure repeatedly is causing DCS, from time to time, to get confused. Side note: I was considering using the scheduled task once to establish the menu structure and then relying on events (ON_BIRTH, ON_DEATH) to detect the client 'logging on/off to the server since this is targeted at a multiplayer environment. For the mission I have 2 sets of route groups/units (ie: groups with the name Passive Route #001 and the unit name of the single unit in the group set to the same name (note the comments below where I need to change this!)) and a second set of template groups named as Passive_TargetRoute. PS: My earlier problem with DCS World 2.0 with 'late activation' units moving before they are activated is back again :-) do -- TargetRoutes are single unit groups with the group name matching the unit (pilot) name. THIS NEEDS TO CHANGE! Passive_TargetRoutes = { "Passive Route #001", "Passive Route #002", "Passive Route #003", "Passive Route #004" } -- Unit/Group names Passive_TargetGroups = { { spawn = SPAWN:New("P-Su-17M4 01" ):Limit( 10, 10 ), txt = "Su-17M4 Single" }, { spawn = SPAWN:New("P-Su-17M4 02" ):Limit( 10, 10 ), txt = "Su-17M4 Pair" }, { spawn = SPAWN:New("P-Su-17M4 01A"):Limit( 10, 10 ), txt = "Su-17M4 Single AA" }, { spawn = SPAWN:New("P-Su-17M4 02A"):Limit( 10, 10 ), txt = "Su-17M4 Pair AA" }, { spawn = SPAWN:New("P-F-5E-3 01" ):Limit( 10, 10 ), txt = "F-5E-3 Single" }, { spawn = SPAWN:New("P-F-5E-3 02" ):Limit( 10, 10 ), txt = "F-5E-3 Pair" }, { spawn = SPAWN:New("P-F-5E-3 01A" ):Limit( 10, 10 ), txt = "F-5E-3 Single AA" }, { spawn = SPAWN:New("P-F-5E-3 02A" ):Limit( 10, 10 ), txt = "F-5E-3 Pair AA" }, } Active_TargetRoutes = { "Active Route #001", "Active Route #002", "Active Route #003", "Active Route #004" } -- Unit/Group names Active_TargetGroups = { { spawn = SPAWN:New("A-Su-17M4 01" ):Limit( 10, 10 ), txt = "Su-17M4 Single" }, { spawn = SPAWN:New("A-Su-17M4 02" ):Limit( 10, 10 ), txt = "Su-17M4 Pair" }, { spawn = SPAWN:New("A-Su-17M4 01A"):Limit( 10, 10 ), txt = "Su-17M4 Single AA" }, { spawn = SPAWN:New("A-Su-17M4 02A"):Limit( 10, 10 ), txt = "Su-17M4 Pair AA" }, { spawn = SPAWN:New("A-F-5E-3 01" ):Limit( 10, 10 ), txt = "F-5E-3 Single" }, { spawn = SPAWN:New("A-F-5E-3 02" ):Limit( 10, 10 ), txt = "F-5E-3 Pair" }, { spawn = SPAWN:New("A-F-5E-3 01A" ):Limit( 10, 10 ), txt = "F-5E-3 Single AA" }, { spawn = SPAWN:New("A-F-5E-3 02A" ):Limit( 10, 10 ), txt = "F-5E-3 Pair AA" }, } local function SpawnControl_spawn ( _data ) -- Expects : _data._client = _data._client or nil -- Reference to the client, if it exists. Will be nil if it call is from 'global' message command pool _data._spawnobj = _data._spawnobj or nil -- Reference to the MOOSE SPAWN pool object _data._routelist = _data._routelist or nil -- Reference to the list of routes (list of unit names that map to groups) _data._txt = _data._txt or nil -- Basically the Menu Command text _data._grp = _data._grp or nil -- Basically the index of the menu parent entry _data._idx = _data._idx or nil -- Basically the index of the menu entry if _data ~= nil then -- Get the Route Unit (unit whose route we will clone) -- TargetRoutes are single unit groups with the group name matching the unit (pilot) name. THIS NEEDS TO CHANGE! local idx = math.random( #_data._routelist ) -- OLD local UnitName = _data._routelist[ idx ] local RouteUnit = UNIT:FindByName( UnitName ) local RouteGroup = GROUP:FindByName( UnitName ) -- NEW -- RouteGroup = Get Group by Name from Route List (So Route List is a Group List) -- RouteUnit = Get First Unit in Group as the spawn unit (position where the cloned group will spawn) -- Check to see if we have a _client client_txt = "<MISSION cmd>" if _data._client ~= nil then client_txt = "" .. _data._client:GetName() end env.info( "SpawnControl_spawn: Call from client " .. client_txt .. " requesting spawn of " .. _data._txt .. "[" .. _data._grp .. ":" .. _data._idx .. "]" .. " to route unit " .. UnitName .. "[" .. idx .."]" .. " - spawn obj ref: " .. _data._spawnobj.SpawnTemplatePrefix) if RouteUnit ~= nil and RouteGroup ~= nil then local RouteRef = RouteGroup:GetTaskRoute() if RouteRef ~= nil then if _data._spawnobj ~= nil then -- Spawn From Unit (clone from unit ref) and assign the route from the Group that contains the Route Unit local spawn_ref = _data._spawnobj:SpawnFromUnit( RouteUnit ):Route( RouteRef ) if spawn_ref ~= nil then env.info( "SpawnControl_spawn: Call completed with no errors." ) if _data._client ~= nil then -- If there is a client, send a client message _data._client:Message( "Group Spawned via call from: " .. client_txt .. " - Spawned Group " .. _data._txt .. " (" .. _data._spawnobj.SpawnTemplatePrefix .. ")" .. " to route " .. _data._routelist[idx], 15 ) else -- Else send a general message MESSAGE:New( "Group Spawned via call from: " .. client_txt .. " - Spawned Group " .. _data._txt .. " (" .. _data._spawnobj.SpawnTemplatePrefix .. ")" .. " to route " .. _data._routelist[idx], 15 ):ToAll() end else MESSAGE:New( "Failed to Spawn Group; spawn_ref empty after spawn req. Request from: " .. client_txt, 15 ):ToAll() env.warning( "Failed to Spawn Group; spawn_ref empty after spawn req. Request from: " .. client_txt ) end else MESSAGE:New( "Failed to access spawn obj (from menu call data). Request from: " .. client_txt, 15 ):ToAll() env.warning( "Failed to access spawn obj (from menu call data). Request from: " .. client_txt ) end else MESSAGE:New( "Failed to get ref to route: " .. RouteUnit .. ". Request from: " .. client_txt, 15 ):ToAll() env.warning( "Failed to get ref to route: " .. RouteUnit .. ". Request from: " .. client_txt ) end else MESSAGE:New( "Failed to get ref to route unit or route group: " .. _data._routelist[ idx ] .. ". Request from: " .. client_txt, 15 ):ToAll() env.warning( "Failed to get ref to route unit or route group: " .. _data._routelist[ idx ] .. ". Request from: " .. client_txt ) end else MESSAGE:New( "Failed to Spawn Group; no _data from menu call. Request from: " .. client_txt, 15 ):ToAll() env.warning( "Failed to Spawn Group; no _data from menu call. Request from: " .. client_txt ) end end local function SpawnControl_check () local msg = "Active Spawns:\n" for idx,val in pairs (Passive_TargetGroups) do local GroupPlane, Index = val.spawn:GetFirstAliveGroup() while GroupPlane ~= nil do msg = msg .. "P:" .. idx .. ":" .. Index .. "-" .. GroupPlane.GroupName .. "\n" GroupPlane, Index = val.spawn:GetNextAliveGroup( Index ) end end for idx,val in pairs (Active_TargetGroups) do local GroupPlane, Index = val.spawn:GetFirstAliveGroup() while GroupPlane ~= nil do msg = msg .. "A:" .. idx .. ":" .. Index .. "-" .. GroupPlane.GroupName .. "\n" GroupPlane, Index = val.spawn:GetNextAliveGroup( Index ) end end MESSAGE:New( msg, 15 ):ToAll() end --[[ --]] local grp = "B1" env.info( "SpawnControl: Adding MENU_MISSION commands" ) local MenuBSpawn = MENU_MISSION:New( "Flight Lead Commands" ) local MenuBSpawnPassive = MENU_MISSION:New( "Spawn Passive Group", MenuBSpawn) local MenuBSpawnActive = MENU_MISSION:New( "Spawn Active Group", MenuBSpawn) local MenuBSpawnPositions = MENU_MISSION_COMMAND:New( "Debug: dump route unit positions", MenuBSpawn, SpawnControl_GetRoutePos, nil ) local MenuBSpawnPositions = MENU_MISSION_COMMAND:New( "Debug: dump spawned list", MenuBSpawn, SpawnControl_check, nil ) if MenuBSpawnPassive then for idx,val in pairs (Passive_TargetGroups) do MENU_MISSION_COMMAND:New( idx .. ": " .. val.txt, MenuBSpawnPassive, SpawnControl_spawn, { _client = nil, _spawnobj = val.spawn, _routelist = Passive_TargetRoutes, _txt = idx .. ": " .. val.txt, _grp = grp, _idx = idx } ) end end grp ="B2" if MenuBSpawnActive then for idx,val in pairs (Active_TargetGroups) do MENU_MISSION_COMMAND:New( idx .. ": " .. val.txt, MenuBSpawnActive, SpawnControl_spawn, { _client = nil, _spawnobj = val.spawn, _routelist = Active_TargetRoutes, _txt = idx .. ": " .. val.txt, _grp = grp, _idx = idx } ) end end --[[ --]] --[[ SCHEDULER:New( nil, function() local PlaneClient = CLIENT:FindByName( "Trainer #001" ) local grp = "C1" env.info( "SpawnControl: Refreshing Comms Menu for " .. tostring(PlaneClient:GetName())) if PlaneClient and PlaneClient:IsAlive() then local MenuCSpawn = MENU_CLIENT:New( PlaneClient, "Flight Lead Commands" ) local MenuCSpawnPassive = MENU_CLIENT:New( PlaneClient, "Spawn Passive Group", MenuCSpawn) local MenuCSpawnActive = MENU_CLIENT:New( PlaneClient, "Spawn Active Group", MenuCSpawn) local MenuCSpawnPositions = MENU_CLIENT_COMMAND:New( PlaneClient, "Debug: dump route unit positions", MenuCSpawn, SpawnControl_GetRoutePos, nil ) local MenuCSpawnPositions = MENU_CLIENT_COMMAND:New( PlaneClient, "Debug: dump spawned list", MenuCSpawn, SpawnControl_check, nil ) if MenuCSpawnPassive then for idx,val in pairs (Passive_TargetGroups) do MENU_CLIENT_COMMAND:New( PlaneClient, idx .. ": " .. val.txt, MenuCSpawnPassive, SpawnControl_spawn, { _client = PlaneClient, _spawnobj = val.spawn, _routelist = Passive_TargetRoutes, _txt = idx .. ": " .. val.txt, _grp = grp, _idx = idx } ) end else PlaneClient:Message( "Unable to add Passive Comms Menu for Client: " .. tostring(PlaneClient:GetName()), 15 ) end grp ="C2" if MenuCSpawnActive then for idx,val in pairs (Active_TargetGroups) do MENU_CLIENT_COMMAND:New( PlaneClient, idx .. ": " .. val.txt, MenuCSpawnActive, SpawnControl_spawn, { _client = PlaneClient, _spawnobj = val.spawn, _routelist = Active_TargetRoutes, _txt = idx .. ": " .. val.txt, _grp = grp, _idx = idx } ) end else PlaneClient:Message( "Unable to add Active Comms Menu for Client: " .. tostring(PlaneClient:GetName()), 15 ) end end end, {}, 10, 20 ) --]] end

I did not think that it was possible to access the resources of the airbases from within Lua. Is that a thing now?

Thanks for the hard work and dedication FlightControl! It is appreciated!

Forum moderation is a thankless job. Really. And I think that the moderators here have a very fine line that they are trying to follow. I do not envy them their task. They are never going to be seen as right when they have to intervene and us simmers can be a passionate, passionate group. They need to protect the brand and the atmosphere while striving to find a way where critical feedback (beneficial criticism) can occur without getting out of hand. And that ain't easy. Hey! We love our hobby! We want to see more! We want to see better! I would love to see forum software that could detect tone and institute a cool down period before some people could throw up a post. Then, if you still want to do it, well that is up to you. The largest problem we fall into as a group is being so passionate about what we want and often, instead of admitting that we might have been aggressive or personal with post we get defensive and double down on the rhetoric. That and we fail to manage our own expectations. I am thankful for the moderators here. I might not agree everything that happens but I would rather this than having a steaming pile of aggressive negativity permeating the group. I just wish that people would be less polarizing in expressing their opinions and that they stay away from trying to be the loudest voice in the room - that is not how you get results.