-
Posts
178 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by dwpenney
-
-
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.
-
Hi Gotwake, about to go on vacation, I'll look into this when I return.
cheers
John
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.
-
Thanks Grimes!
If there is anything I can do to help, let me know.
-
It looks like the Run Script Advanced Waypoint Action is broken in DCS World 2.2.0? This may be a known issue as I would guess this may impact mission designers and may be reported internally already.
Summary: This issue pertains to the 'Run Script' Advanced Waypoint Action either as specified in the mission editor (Perform Command -> Run Script) or via code (MOOSE in this case, which is why I was replicating it without MOOSE and started with the Advanced Waypoint Action).
Steps to Reproduce in Mission Editor:
1. Start a new mission (on Nevada in my test);
2. Add a new Vehicle Group with two waypoints (in addition to the starting position);
3. At WP#1 (middle waypoint) add an Advanced (Waypoint Action) -> Perform Command -> Run Script -> env.info ( "Vehicle: WPT Run Script Call: At Wp#1" );
4. Repeat this step at WP#2 with code: env.info ( "Vehicle: WPT Run Script Call: At Wp#2" )
5. Run the mission and monitor the log - the message is never generated even after WP#1 is passed and WP#2 is reached (at which point the test vehicle will stop);
Experienced Behaviour (Advanced Waypoint Action):
- Correct Behaviour: In DCS World 1.5.8, Vehicle 2 reports in the DCS.log file when it passes WP#1 and when it arrives at WP#2;
- Incorrect Behaviour: In DCS World 2.2.0, Vehicle 2 _does not_ report in the DCS.log file when it passes WP#1 or when it arrives at WP#2;
Experienced Behaviour (MOOSE):
- Correct Behaviour: In DCS World 1.5.8, Vehicle 1 is assigned a route from it's start POS to one of the target areas. The second WP in that route is given a TaskFunction to call a function to calculate a new route to a random target. Once Vehicle 1 reaches it's first target zone, a second route is properly generated to a subsequent target zone. This repeats ad infinitum;
- Incorrect Correct Behaviour: In DCS World 2.2.0, Vehicle 1 is assigned a route from it's start POS to one of the target areas. The second WP in that route is given a TaskFunction to call a function to calculate a new route to a random target. Once Vehicle 1 reaches it's first target zone it stops and never executes the WP2 TaskFunction to set a new route;
Note:
- This works in DCS World 1.5.8;
- This does not work in DCS World 2.2.0;
- In the attached .zip please find two missions (these missions are based off of a MOOSE test mission and contain both the MOOSE code _and_ a simple unit created with the above mentioned steps)
- The MOOSE code can be ignored if you focus on Vehicle 2 (group name) in both missions as that group is limited to only env.info LUA calls to attempt and replicate the issue experienced with MOOSE. I specifically left the MOOSE code in as it may help debug the issue and I hope that does not confuse anyone testing this;
- For DCS World 1.5.8 (Georgia): GRP-502 - DCSW-1.5.8 - Route at waypoint to random point.miz
- For DCS World 2.2.0 (Nevada): GRP-502 - DCSW-2.2.0 - Route at waypoint to random point.miz
- Vehicle 1 uses MOOSE code to attempt to generate another target location when the current one is reached. It does this by creating a route from it's current POS to a random target zone, injecting a TaskFunction at WP#2 that will re-execute that logic. It's not terribly complex but it led me to find that I could not get the TaskFunction at WP#2 to ever execute. That lead me to create...
- Vehicle 2 which uses only the Waypoint (Advanced Actions) functionality to attempt to have Vehicle 2 report as it passes WP #1 and reaches WP#2 - it does neither;
- For reference there are a number of lines output to the dcs.log file by the LUA code that were helping me debug the issue. These lines are prefaced with GRP-502 (so if you use a log monitoring software (ex: glogg) then you can easily pick those lines out;
- All LUA code is contained in the zip as well. Both functions should work out of the box and require no modification.
If there is anything that I can add, please let me know.
-
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:
VKB Gunfighter Pro (bundle with Knuppelgriff KG12)
Disclosure: I wrote the VKB review.
-
EDIT: Turns out I missed the 'true' boolean from the respawn function. Units will now respawn on the ground as expected...
Can you expand on this a little? Which value were you missing/setting incorrectly?
I am looking at the MIST respawnGroup docs and the correct use of the boolean value is not clear to me :-)
I see what the delay does but I don't understand the boolean.
-
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)
-
Oh. Odd. I had thought I that I had retested it shortly after the 2.5 release and it was thought it was fixed. I may have been mistaken, though, as i keep dipping back to 1.5.x. I will wait patiently then.
Thanks for the update! :-)
-
I realize that this is not a high priority fix for non-mission designers but I would like to note that groups set to 'Late Activation' are moving during their 'hidden' period. This is the same bug that appeared in 2.0.4.59428 and was fixed shortly there after.
Here is a screenshot (attachment) of a dump of unit positions. There are two sets of units in each of the output groups (noted with a P and an A). If you look at the P groups, you will see that the lat/lon positions move between the two dumps (taken a few seconds apart). The A groups are just re-dumps of the P groups ... because I was too lazy and was reusing my code :-)
Also, reference this thread: https://forums.eagle.ru/showthread.php?t=177975
EDIT: This is not an issue with the 1.5.x codebase.
-
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!
PointCTRL - Finger Mounted VR Controller
in PC Hardware and Related Software
Posted
Can you add me to the list as well?