Jump to content

dwpenney

Members
  • Posts

    178
  • Joined

  • Last visited

Posts posted by dwpenney

  1. 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.

  2. 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'.

  3. 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.

  4. 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.

  5. 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.

    Run_Script-Advance_Waypoint_Action-Issue.zip

  6. 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.

  7. 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.

  8. 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.

     

    http://wiki.hoggit.us/view/RespawnGroup

  9. 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.

    DCS_Hidden_Units_Pos.png.07ed4980d6330280b219e64e6d2d4f02.png

  10. 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!

×
×
  • Create New...