Jump to content

PiedDroit

Members
  • Posts

    1606
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by PiedDroit

  1. yes you need steam, it uses steamvr. Stand alone works fine but it needs to launch steamvr

     

    Yep exactly.

    I'm DCS non-Steam user. What I did to make it run:

    - Configured the Windows Mixed Reality environment as instructed when plugging the headset.

    - From Steam, installed "Windows Mixed Reality for Steam" (had to search manually for it in the store)

    - When I play, I first start "Windows Mixed Reality for Steam" (which also starts the WMR envirnment), I wait for the headset to hook up and then I start DCS, works like a charm.

  2. Hi folks,

     

    I finally got the chance to get the Odyssey, I'm posting here to give detailed feedback about wearign it with glasses, as it was very difficult for me to get info on that.

     

    They fit much better than in the Oculus Rift, putting it on and removing it is a breeze too thanks to the "crown" design.

     

    The Odyssey's space is 140 mm at the widest point without compressing the foam.

    The width of my glasses' frame is 135 mm, height 35 mm. I think they are wider than average and yet they fit well.

    The lenses didn't touch each other either (they were with the Oculus Rift), but I guess this might depend on each person's morphology.

     

    Funny detail, in the manual they explicitely tell to not wear the HMD while wearing glasses, as doing so "may cause facial injuries". Covering all the bases I guess :D

     

    Hope this is useful.

    Cheers,

  3. If you can run DCS World with an Oculus Rift, at a pixel density setting of 1.7, you should be able to run the PIMAX 8k.

     

    Currently at 1.7 pixel density we have a resolution of 3672x2040, which makes 7,490,880 pixels.

     

    At a combined resolution of 5120x1440 the PIMAX 8k will run 7,372,800 pixels.

     

    On the higher FOV picture, there will be more objects to display, so at equal resolution, I assume the performance should be worse with the higher FOV.

  4. Also, make sure the LEDs on the camera are OFF by selecting "Track clip" on the TIR software (if you see four red dots on the camera itself, it means it's emitting IR light, you don't want that when using the track clip).

    It's still possible to have parasitic reflections though, from the sun, as the other said, the best way to diagnose the problem is to have the camera view selected and look for any masking / parasites (red).

  5. IPD does not change world size, it only affects to the "depth experience" (what is little wrong too as human brains calculate distance not by two eyes alone, but two eyes and their angle to focus point).

     

    If you cover your other eye (like tape it to shut if you will) and then place a VR on, you can adjust as much as you want the DPI and the world scale does not change.

    You can as well do the same thing in the reality, world scale doesn't change.

    Despite all the other ways of perceiving depth, I think binocular vision is the major contributor, not focal length.

    Chaning world scale with camera separation works, it has been done in other sims.

  6. I’ve wanted such a feature in DCS for a while now.

     

    Barrel distortion is used in DCS for VR though I think it is performed using the Oculus SDK. I’m not sure if that same method could be applied for monitors though. It would be a amazing for those of us with 21:9 curved ultrawide displays.

     

    It has to be provided by the graphics engine, I assume that doing such transformation after rendering is quite costly in terms of processing power.

    Or maybe it's not that costly, but it still has to be applied after rendering. Which means new software development.

     

    The day graphics API (DirectX) and 3D game engines will be able to render pictures directly with barrel transform applied then it will be possible to add this even for monitors quite easily.

     

    Good thing is that VR is pushing us right in that direction :thumbup:

  7. There is the third as well, that is really the world scale.

     

    1) IPD (HMD optics separation to wearer eyes)

    2) Virtual Cameras separation (it says it all)

    3) Virtual Cameras Focal Length (zooming, FOV)

    4) Virtual Cameras Nodal Point

    5) The virtual world scale.

     

    I was assuming 3) FOV is tied only to the headset and not to the user.

    If in the real world my vision is already distorted by glasses I thought it would not matter too much in the headset as I'm used to this distortion (I'm already seeing the world smaller than it actually is because of the glasses), but maybe it has more impact.

     

    I think 2) and 5) are the same thing, the ratio between them is the actual parameter.

     

    I'm more curious about 4), isn't that an optical thing? How would that affect the rendered picture?

  8. Gotta love it when a 'tester' tells someone that their problem does not exist because he does not see it and, for that reason alone, will not be reported.

     

    The physics of binocular vision, in a VR headset, has nothing to do with IPD but is directly tied to the spacing of the two virtual cameras used to generate a 3d perception. The fact that some devs choose to ignore this reality does not make it correct.

     

    But the link he posted shows an "IPD" setting in DCS, that would be the camera spacing! - or world scale, or viewport separation, or rendering IPD, whatever. The IPD term is used for too many things :D

    It's not available yet, it's for 2.5.

  9. Thx, Jabbers.

     

    Just generally: Wolrd Scale, its not what it might sound like. They dont scale the world, I think they are simply changing the IPD, but calling it something more 'tangible'. I cant imagine the consequence actually scaling the world would have. So much to take into account and fudge, and yea, just wouldnt be practical.

     

    And Im pretty confident that everything is modeled to scale in DCS, or very very very close.

    But Im also very confident that I perceive the DCS World smaller trough VR.

     

    Hi, that's exactly this.

    There is a confusion of terms I think, I see this kind of questioning coming back every now and then because there are actually two settings related to the distance between eyes, not just one.

     

    The IPD is more the optics side, having proper IPD on the headset means your eyes are well aligned with the lenses and the screen, which is better for comfort, but this will not drastically affect the sense of scale because the images on the screens will be not be modified by this.

     

    World scale, on the other hand, is on the rendering side, it is the distance between the two rendering viewports.

    If the distance between the two viewports is too large, the world will appear very tiny (think of looking at a toy plane), and vice-versa.

     

    The size of the world itself has nothing to do with it, it's the relation ship between the world "size" and the distance between the two rendering viewports that matters.

    This setting should be unique to each person, currently I understand it is fixed in DCS, that's why some people complain about the world scale and some other not.

  10. Personally I doesn't bother me either way, I wouldn't buy it, but because of the amount of vicious rants I have seen in in-game chat from experienced players at noobs due to their noobishness, makes me wonder why people don't support the training aspect.

    Sitting in a trainer aircraft does not magically train you, the instructor does.

     

    The problem in that case is unused and/or insufficient training missions, not the lack of training aircraft - DCS is virtual, so, many platforms can be trainers, from basic training to advanced training, there is no cost issue, safety issue nor dual-seater limitation.

    With the curent status of DCS (counting the Hornet), between more aircraft and more content, I favor the latter personally.

  11. There is no value whatsoever in the airplane voluntarily deviating from the captured localizer in order to satisfy some erroneous inbound course setting. I can't say for certain that every aircraft and avionics manufacturer feels the same way, so it's conceivable that maybe an A320 will wonder off...but the A-10 doesn't.

    I saw that happen (veering off due to incorrect course setting, then correcting back to compensate for the deviation it generated), I think it was on a A320 but not sure :)

    Not real airplane, a simulator, but using a real autopilot software (I think it was before capture, but it's been a while, I don't remember the test conditions).

  12. It looks like there are two different discussion going on here, hence the diverging opnions.

    - Is the course value needed for an accurate LOC capture? Yes - but maybe not on all A/C types, on my side I can only guarantee it is need for airliners.

    - Is the HSI course value used for that? Probably not, that's a different instrument - On airliners again, the only places you can tune that course is through the radio management panel (in manual mode) or through the FMS (in managed mode).

     

    So, I'm not saying Piston85 is wrong about saying HSI course selector should not affect ILS' autopilot, I'm just saying that you can't justify this by saying no ILS autopilot ever uses a course value, this is something that depends on the A/C.

  13. This is totally wrong from my experience. Name one system that uses course selection please. After 15 years ive never seen one.

     

    One beam only, talking about LOC ofcourse..

     

    I can name pretty much all airliners ILS systems.

     

    The course setting might be hidden from the user's view, because it is stored in the navigation system.

    On an airliner, the FMS has this information and feeds it to the flight guidance system, I believe this is the same thing with military aircraft, hence the use of "airport" navigation points.

    The FMS also feed the ILS frequency.

     

    When in manual mode (standby nav), the user bypasses the FMS's settings and sets the ILS frequency from the radio management panel using the selection knob.

    Once the user validates the frequency (goes from standby to active), he can then set the course value.

     

    You might be very experienced as a user, but there are a lot of things going on under the hood that you might not be aware of.

  14. I'm nitpicking, but what do you mean about it being a "single beam"? The localizer and glide path(-slope for the non-ICAO folks) are two separate systems operating at different frequencies at separate locations. While it may appear as "one beam" to the pilot who just sets the LOC frequency in his/her nav receiver (with the corresponding GP freq being auto tuned due to standardized frequency pairing), saying that a 110.1MHz signal from one end of the runway and a 334.4MHz signal from 400-ish meters from the opposite runway end is a single beam is a bit of a stretch of the term "single".

     

    (and just for the record, I have been working for the world's largest ILS manufacturer for 10 years, in test and R&D, so I don't need to look up how it works)

     

    Hi folks, I don't know about the military systems but I can give some insights on the civilian A/C ILS systems, from the avionics point of view.

     

    The ILS is actually two beams, one for LOC and one for G/S, the G/S frequency is deduced from the ILS frequency (as in drPhibes's post).

    The ILS receiver can only compute a deviation value (angular deviation), one for each beam.

    This means it can tell you if if the ILS antenna is on the beam or not.

    If you get a zero deviation, then you are on the beam, if you get non zero deviation, you are not on the beam. It's quite simple

     

    The problem is that the deviation you get doesn't tell you anything about the orientation of the aircraft with relationship to the beam.

    This is where the course setting is useful, it gives the flight guidance computer that missing information.

     

    The autopilot will try to follow the course that has been input by the user, and also tries to keep the aircraft with zero deviation.

    If the course is totally wrong (against current heading), the autopilot might even refuse to engage the approach mode.

    If the course is off, the aircraft, while riding the beam perfectly, will try to follow the course, then leave the beam, then correct again because of the deviation, etc.

    When closer to the runway the deviations are given more importance than the course, because the aircraft is already well aligned and the course setting is usually not very accuracte (1 degree accuracy at best), but at the beginning of the LOC beam capture, the course setting has a significant impact on the autopilot and FD behaviour.

     

    So, unless you are using two ILS receivers (this is not the case on airliners, they only use one at a time), the autopilot and FD need the course information.

  15. I tried to re-read the manual more carefully and I found this:

     

    "In the HUD, the presence of the star representing the commanded slope, indicates the pilot that the autopilot is connected".

    Could that indicate that the flight director is the star?

     

    The other picture I have attached is for the visual approach, the text in the box says that autopilot is connected, and we can see the star in the HUD, and that the FPM should be put on the star.

     

    In comparison, the 2 pictures in the other post I made don't say that the autopilot is connected.

     

    The manual I have (m2000c.pdf found on the net) is a scanned document with no OCR, so it makes looking for stuff a bit difficult.

    The paragraph on the ADI ("spherical indicator") only state that it displays the ILS cues (Marker - LOC - Glide).

     

    My best guess woud be:

    * -> flight director

    box -> deviation indicator

    M2000CILS3.PNG.20ee8d29327c1f70c17fd9f78c25d4e8.PNG

    M2000CILS4.PNG.e7051548095c8cfab8b3e398cb32a216.PNG

    • Like 1
  16. That above is the one thing you're righr. Maybe that confirms everything about me being wrong.

     

    What does the real manual say aboout the indications in the ADI? I find those to hardly be deviations, all yellow needles are directors for international convention.

     

    Can you find that? I could not get to the real manual online, dont know where else to look.

     

     

    Sorry for before.

     

    No problem, I'm a patient person and can deal with that, I apologize for my reaction.

     

    The manual has no details about the ILS, the only thing are these pictures.

     

    The fact that there is an autopilot that can follow a glislope would be a good argument to say that the box is fligth director, because after all, why not display the flight guidance commands when you have them? It's much better than a raw deviation.

     

    The data from the manual is just too scarce to conclude anything.

    I have been advocating for an ILS deviation indicator because of the way the drawing is done and the terms presented in the manual, but it is very thin. I'd love to have more data from a SME.

     

    I don't have anything more to add here, next move is RAZBAM's choice, I only wanted to expose that because I had the feeling that this HUD footage from an Airbus had been taken too lightly.

    I deal with avionics systems every day and even with a same type of aircraft you can have a lot of tiny differences to be looked at with a magnifying glass.

  17. Good, very good, I prefer tackling problems rather than people :)

     

    If RAZBAM have a SME that confirmed it, it's OK, but otherwise we have to rely on the manual.

    I have attached the two pages on ILS I have from the real manual.

     

    This is where I think the confusion is coming:

     

    If the manual (written by Razbam not the real plane) says to actively put the fpm inside the box they are referring to FD, otherwise it would say put THE BOX in the center of the HUD and then keep the FPM inside.

     

    You seem to be sure that if the indicator is relative to the FPM, then it is a flight director and if the box was a deviation indicator, it should be put in the center of the HUD, but I disagree here.

    A deviation indicator is not necessarily to be put in the center of the HUD. It might be true for an Airbus, but we're talking about a different beast here. The deviation indicator could very well be tied to the FPM. There is no other indicator on the Mirage's HUD (the Airbus has the vertical deviation on the right of the HUD).

    At the same time, for example, a flight director is not necessarily tied to the FPM. On an Airbus' primary flight display (not HUD), the fligh director is a green cross that you need to put in the center of the display, it's not tied to the FPM.

     

    The real manual says:

    "Put the aicraft model in the guiding window". That kind of sentence could apply to both a flight director (commands from flight guidance computer) or a deviation indicator (raw deviations from ILS receiver).

    If you maintain the FPM in the box, then you're on path, it works for both.

     

    There is also a little triangle on the picture that says "Excessive LOC deviation (flashing)". That kind of terminology is associated to a deviation indicator, not a flight director.

     

    So, if the box is a deviation indicator and tied to the FPM, there is no need to put it in the center of the HUD. If the box is on the right of the FPM, then it means that you are to the left of the path, vice versa, same in vertical.

    That works for both a flight director and a deviation indicator.

     

    The proof that is needed is a SME that confirms either possibility.

    What I'm saying is that the instruction to put the FPM in the box is not enough to decide this is flight director. Especially when this box can have a little triangle that says "Excessive LOC deviation".

    M2000CILS1.PNG.ca32acfe2c0d184d5db95ba900731dc5.PNG

    M2000CILS2.PNG.d34dd93a28ec60ee381f01f996b6bded.PNG

  18. Yet I fully understand the topic, take some time to think about it.

    There is no conclusive data that goes one way or another (sorry but an A319 HUD footage doesn't prove anything), I'd love to see something more solid than that.

    • Like 1
  19. The video you posted above is a good example of what I'm talinkg about, in the attached picture I just highlighted some elements, in red some that are attached to the HUD frame, in blue some that are mapped to the actual flight vector.

    But I'm just stating the obvious anyway.

     

    I never said it's not fpm related, actually it should be. If the box is in relation to FPM then it must act as a director (otherwise we would be talking about apples and oranges). If the box is not FPM related then it could act as loc/gs deviaton indicators; Period, there is not really much to discuss in that regard.

    This is where there is a confusion I think.

    "If the box is in relation to FPM then it must act as a director" - why must?

    Flight director and deviation indicator are two different things, the flight director show deviation between flight path computed by the flight guidance versus actual flight path, where deviation is a raw value that shows the angular difference between the localizer beam (and g/s) versus your current position.

     

    So having the box, let's say on the right of the FPM could very well mean two things: in case of a flight director implementation, it would be a command from the flight guidance to go right in order to catch the computed flight path.

    In case of a deviation indicator, it would simply tell you that the localizer beam is on the right.

     

    If the FPM is on top of the box, it just means deviation is 0. lets says you are on a 90° course in relation with the runway, and your position is right on the runway axis (runway in your 3/9 O'clock).

    In that case the deviation indicator will show zero (FPM on top of the box), but a flight guidance system would put the flight director to the left or right of its anchor because obviously you'd need to do a turn to catch the loc beam.

     

    Sorry, I just realized that Razbam already agreed this was a bug https://forums.eagle.ru/showthread.php?t=172120&page=3

     

    There is a video of the same system and how it is supposed to behave (already posted that video in the first post)

     

     

    :)

     

    If the real manual says it's a deviation from the LOC beam, then it is, it is not a flight director and you can't use another aircraft's footage to prove your point...

    If RAZBAM acknowledged the above as bug, then I think it's a mistake (unless they have data that we don't have).

    The only thing is that the manual is not 100% clear, I think this has been discussed in another thread, I'll to dig a bit to find it.

    HUD2.thumb.png.153040d5ce46130255cadcf77a9ae037.png

  20. Ive been flying (real life career + air force) for more than 15 years and this is the first time I hear something like this :)

     

    Have you ever seen a plane that behaves like you say? It goes against the conception of a HUD.

     

    THanks anyway for your kind reply.

    What I mean is that you will not have the FPM used as a pointer for a fixed point in the HUD.

    You will have either:

    - a fixed point in the HUD matched against HUD-centric cues, or

    - the FPM matched against FPM-centric cues.

    Not a mix of both.

     

    Your mileage may vary I guess (mine in that case). I also saw my share of flight directors, HUDs and stuff alike (I work with avionics, not for as long as you did though), never saw anything that requires you to put the FPM into something that is not relative to the FPM.

     

    Anyway, for the ILS we're talking about, what I'm saying is that the box is FPM-related, so asking to put the FPM in the box to obtain zero deviation is normal.

  21. Everything looks good,

     

    The manual clearly states that the box shows glideslope and course deviation.

     

    It indeed says that for a perfect approach you have to place the FPM inside the box, but you have to read this as "you have to maneuver so the FPM is inside the box".

    The box is not a flight director (also no flight director would work by using the FPM as pointer anyway, it would be a fixed point in the HUD).

     

    1. ILS Guide

    Visible only when both localizer and glideslope have been captured. It moves in

    relation to the FPM showing both glideslope and course deviation. To maintain a

    perfect approach, you have to place the FPM inside the box.

     

    If the deviation from either glideslope or course is too large, a flashing triangle (not

    shown) will appear indicating that a course/elevation change is required.

     

    Therefore placing the FPM inside the box makes no sense as the box will always be deviated as long as the localizer is; same for the vertical component (GS).

    Actually the box is displayed relatively to the FPM, so when the FPM is in the box, deviation is exactly zero, so you're on flight path.

  22. Ah, so you want TARGET device and the "natural" device working simultaneously. It is sort of possible in a very buggy way when the filter driver fails to correctly replace the standard driver. You would get natural device and TARGET device at the same time. But it is very buggy, the TARGET output was not doing anything despite the device being present. It's not practical.

     

    There is a way to do it, it's not buggy at all.

    https://forums.eagle.ru/showpost.php?p=3212573&postcount=8

     

    Hi all,

     

    Sorry I'm a bit late to the party.

    Yes, you can totally do that, using MODE_FILTERED.

     

    Here is a sample script that I'm using it for the P-51D (I just tweaked it so it doesn't depend on other includes), in which I set up:

    - a few special commands that call keyboard shortcuts (for snap views, teamspeak, trackIR)

    - a customized axis (MAP_RELATIVE) to use the ministick for target range

    - a virtual axis that is activated through the Coolie switch left and right (for target size)

    - a filtered slider (through an hysteresis) because my throttle slider is a bit jittery.

     

    I just launch the script, the "Combined" appears and the other two stay and work as usual.

    In game I map the zoom on the SLIDER1 axis of the "Combined", and the RY for target range, RX for size.

    Everything else I map it directly on the "Throttle" and "Joystick" devices, in DCS.

    Except I don't map anything on the Joystick's S1, H2L, H2R and Throttle's CSL, CSR, MSP and MSU because these will trigger some keypresses that I set up in the script, but this is just an example, if you use the A-10C just delete these lines from the script and map the keys to your liking (as in your originial question).

     

     

     

    include "target.tmh"
    
    // Standalone DX mappings
    
    int ThrottleMap1[]={
    
    SC,DX1,
    
    MSU,DX3, // Mike Switch
    MSD,DX5,
    MSL,DX6,
    MSR,DX4,
    MSP,DX2,
    
    SPDF,DX7, // Speed Brake
    SPDM,0,
    SPDB,DX8,
    
    BSF,DX9, // Boat Switch
    BSM,0,
    BSB,DX10,
    
    CHF,DX11, // China Hat
    CHB,DX12,
    
    PSF,DX13, // Pinky
    PSM,0,
    PSB,DX14,
    
    CSU,DXHATUP, // Coolie Switch
    CSD,DXHATDOWN,
    CSL,DXHATLEFT,
    CSR,DXHATRIGHT,
    
    LTB,DX15,
    
    EFLNORM,DX16,
    EFLOVER,0,
    
    EFRNORM,DX17,
    EFROVER,0,
    
    EOLIGN,DX31,
    EOLNORM,0,
    EOLMOTOR,DX18,
    
    EORIGN,DX32,
    EORNORM,0,
    EORMOTOR,DX19,
    
    APUON,DX20,
    APUOFF,0,
    
    LDGH,DX21,
    
    FLAPU,DX22,
    FLAPM,0,
    FLAPD,DX23,
    
    EACON,DX24,
    EACOFF,0,
    
    RDRNRM,DX25,
    RDRDIS,0,
    
    APPAT,DX27, // PATH
    APAH,0,     // ALT/HDG
    APALT,DX28, // ALT
    APENG,DX26,
    
    IDLELON,DX30,
    IDLERON,DX29
    };
    
    int JoystickMap1[]={ // Actually the same as JoystickMap
    
    TG1,DX1,
    
    S1,DX5, // Side
    S2,DX2, // Red
    S3,DX3, // Pinky
    S4,DX4, // Paddle
    
    TG2,DX6,
    
    H1U,DXHATUP, // Trims (upper right)
    H1D,DXHATDOWN,
    H1L,DXHATLEFT,
    H1R,DXHATRIGHT,
    
    H2U,DX7, // TMS (lower right)
    H2D,DX9,
    H2L,DX10,
    H2R,DX8,
    
    H3U,DX11, // DMS (lower left)
    H3D,DX13,
    H3L,DX14,
    H3R,DX12,
    
    H4U,DX15, // CMS (thumb)
    H4D,DX17,
    H4L,DX18,
    H4R,DX16,
    H4P,DX19
    };
    
    // empty maps
    
    int ThrottleMap0[]={
    
    SC,0,
    
    MSU,0,
    MSD,0,
    MSL,0,
    MSR,0,
    MSP,0,
    
    SPDF,0,
    SPDM,0,
    SPDB,0,
    
    BSF,0,
    BSM,0,
    BSB,0,
    
    CHF,0,
    CHB,0,
    
    PSF,0,
    PSM,0,
    PSB,0,
    
    CSU,0,
    CSD,0,
    CSL,0,
    CSR,0,
    
    LTB,0,
    
    EFLNORM,0,
    EFLOVER,0,
    
    EFRNORM,0,
    EFROVER,0,
    
    EOLIGN,0,
    EOLNORM,0,
    EOLMOTOR,0,
    
    EORIGN,0,
    EORNORM,0,
    EORMOTOR,0,
    
    APUON,0,
    APUOFF,0,
    
    LDGH,0,
    
    FLAPU,0,
    FLAPM,0,
    FLAPD,0,
    
    EACON,0,
    EACOFF,0,
    
    RDRNRM,0,
    RDRDIS,0,
    
    APPAT,0,
    APAH,0,
    APALT,0,
    APENG,0,
    
    IDLELON,0,
    IDLERON,0
    };
    
    int JoystickMap0[]={
    
    TG1,0,
    
    S1,0,
    S2,0,
    S3,0,
    S4,0,
    
    TG2,0,
    
    H1U,0,
    H1D,0,
    H1L,0,
    H1R,0,
    
    H2U,0,
    H2D,0,
    H2L,0,
    H2R,0,
    
    H3U,0,
    H3D,0,
    H3L,0,
    H3R,0,
    
    H4U,0,
    H4D,0,
    H4L,0,
    H4R,0,
    H4P,0
    };
    
    // Special keys
    define KPslash					USB[84]
    define KPstar					USB[85]
    define KPminus					USB[86]
    define KPplus					USB[87]
    
    define TeamSpeakPushToTalk		CAPS
    
    define TrackIrCenter			L_ALT+SCRLCK
    define TrackIrDisable			L_ALT+BRK
    
    ////////////////////////////////////////////////////////////
    
    define TPULSE 70
    define TDELAY 50
    define T (TPULSE+TDELAY)
    
    define SHORTTEMPO 300
    define LONGTEMPO 1500
    
    ////////////////////////////////////////////////////////////
    int hysteresis(alias dir, alias cur, int val, int delta){
    if (dir<0){
    	if      (val<cur      ){ cur=val;         }
    	else if (val>cur+delta){ cur=val; dir= 1; }
    }
    else if (dir>0){
    	if      (val>cur      ){ cur=val;         }
    	else if (val<cur-delta){ cur=val; dir=-1; }
    }
    else{
    	if (val>cur){ cur=val; dir= 1; }
    	else        { cur=val; dir=-1; }
    }
    return cur;
    }
    
    ////////////////////////////////////////////////////////////
    int s_THR_FC_dir=0;
    int s_THR_FC_cur=0;
    int hysteresis_THR_FC(int axis)
    {
    return TrimDXAxis(axis,
    	SET(
    		hysteresis(
    			&s_THR_FC_dir,
    			&s_THR_FC_cur,
    			Throttle[THR_FC],512
    		)/32
    	)
    );
    }
    
    ////////////////////////////////////////////////////////////
    int snapviewlist;
    int snapview(int s,int hold,int release)
    {
    snapviewlist = SEQ(KP0,KP1,KP2,KP3,KP4,KP5,KP6,KP7,KP8,KP9);
    
    if (hold)
    {
        ActKey(KEYON+CHAIN(
        	PULSE+R_CTL+KP0			,D(T),
        	PULSE+X(snapviewlist,s)	));
    }
    else
    {
    	if (release)
    	    ActKey(      L_WIN+X(snapviewlist,s));
    	else
    	    ActKey(KEYON+L_WIN+X(snapviewlist,s));
    }
    }
    
    ////////////////////////////////////////////////////////////
    
    int main()
    {
    /////////////////// Setup and initialisation ///////////////////
    Configure(&HCougar, MODE_EXCLUDED);
    Configure(&T16000, MODE_EXCLUDED);
    Configure(&LMFD, MODE_EXCLUDED);
    Configure(&RMFD, MODE_EXCLUDED);
    
    Configure(&Joystick, MODE_FILTERED);
    Configure(&Throttle, MODE_FILTERED);
    if(Init(&EventHandle)) return 1;
    
    SetKBRate(TPULSE, TDELAY); // Keyboard pulse and delay times in ms
    SetKBLayout(KB_ENG);
    
    /////////////////// Empty maps ///////////////////
    
    // Empty maps
    MapList(&Joystick,&JoystickMap0);
    MapList(&Throttle,&ThrottleMap0);
    
    /////////////////// Mappings ///////////////////
    
    //MapKey(&Throttle, CSU, REXEC(0, 75, "TrimDXAxis(DX_SLIDER_AXIS,  16);")); // DX_SLIDER_AXIS = slider2
    //MapKey(&Throttle, CSD, REXEC(0, 75, "TrimDXAxis(DX_SLIDER_AXIS, -16);"));
    
    MapKey (&Joystick, S1, EXEC("snapview(8,0,0);"));
    MapKeyR(&Joystick, S1, EXEC("snapview(8,0,1);"));
    
    //MapKey (&Joystick, H2D, EXEC("snapview(2,0,0);"));
    //MapKeyR(&Joystick, H2D, EXEC("snapview(2,0,1);"));
    MapKey (&Joystick, H2L, EXEC("snapview(1,0,0);"));
    MapKeyR(&Joystick, H2L, EXEC("snapview(1,0,1);"));
    MapKey (&Joystick, H2R, EXEC("snapview(3,0,0);"));
    MapKeyR(&Joystick, H2R, EXEC("snapview(3,0,1);"));
    
    /////////
    // TDC //
    /////////
    
    //MapAxis(&Throttle, SCX, DX_XROT_AXIS, AXIS_NORMAL, MAP_RELATIVE);
    //SetSCurve(&Throttle, SCX, 0, 40, 0, 0, -10);
    MapAxis(&Throttle, SCY, DX_YROT_AXIS, AXIS_NORMAL, MAP_RELATIVE);
    SetSCurve(&Throttle, SCY, 0, 40, 0, 0, -10);
    
    MapKey(&Throttle, CSL, REXEC(0, 50, "TrimDXAxis(DX_XROT_AXIS, -8);"));
    MapKey(&Throttle, CSR, REXEC(0, 50, "TrimDXAxis(DX_XROT_AXIS,  8);"));
    
    ////////////
    // Slider //
    ////////////
    
    KeyAxis(&Throttle,THR_FC,0,AXMAP1(512,
    	EXEC("hysteresis_THR_FC(DX_THROTTLE_AXIS);"),
    	EXEC("hysteresis_THR_FC(DX_THROTTLE_AXIS);"),
    	EXEC("hysteresis_THR_FC(DX_THROTTLE_AXIS);")
    ));
    
    /////////////
    // TrackIR //
    /////////////
    
    MapKey(&Throttle, MSP, TEMPO(TrackIrCenter,TrackIrDisable,SHORTTEMPO));
    
    /////////
    // Mic //
    /////////
    
    MapKey (&Throttle, MSU, TeamSpeakPushToTalk);
       
       return 0;
    
    }
    int EventHandle(int type, alias o, int x)
    {
       int rc = DefaultMapping(&o, x);
    
    if(&o == &Throttle & x == THR_FC) return rc;
    
    GameOutput(&o, x, o[x]);
    return rc;
    }
    

     

     

     

    P.S.:

     

    This snippet makes the thrustmaster combined silent by default (no DX generated by the combined on button actions):

    	MapList(&Joystick,&JoystickMap0);
    MapList(&Throttle,&ThrottleMap0);
    

    If you want the combined act as usual (by default, all joystick DX buttons available + a few of the throttle DX buttons), remove the lines entirely (this is default).

     

    If you want the combined to only act as the throttle (all throttle DX buttons available), replace with this:

    	MapList(&Joystick,&JoystickMap0);
    MapList(&Throttle,&ThrottleMap1);

     

    P.P.S.: Adding a simplified script that doesn't have all the gizmos, to serve as template:

     

     

    include "target.tmh"
    
    
    define TeamSpeakPushToTalk		CAPS
    
    define TrackIrCenter			L_ALT+SCRLCK
    define TrackIrDisable			L_ALT+BRK
    
    ////////////////////////////////////////////////////////////
    
    define TPULSE 70
    define TDELAY 50
    define T (TPULSE+TDELAY)
    
    define SHORTTEMPO 300
    define LONGTEMPO 1500
    
    ////////////////////////////////////////////////////////////
    
    int main()
    {
    /////////////////// Setup and initialisation ///////////////////
    Configure(&HCougar, MODE_EXCLUDED);
    Configure(&T16000, MODE_EXCLUDED);
    Configure(&LMFD, MODE_EXCLUDED);
    Configure(&RMFD, MODE_EXCLUDED);
    
    Configure(&Joystick, MODE_FILTERED);
    Configure(&Throttle, MODE_FILTERED);
    if(Init(&EventHandle)) return 1;
    
    SetKBRate(TPULSE, TDELAY); // Keyboard pulse and delay times in ms
    SetKBLayout(KB_ENG);
    
    /////////////////// Mappings ///////////////////
    
    /////////////
    // TrackIR //
    /////////////
    
    MapKey(&Throttle, MSP, TEMPO(TrackIrCenter,TrackIrDisable,SHORTTEMPO));
    
    /////////
    // Mic //
    /////////
    
    MapKey (&Throttle, MSU, TeamSpeakPushToTalk);
       
       return 0;
    
    }
    int EventHandle(int type, alias o, int x)
    {
       int rc = DefaultMapping(&o, x);
    //
    GameOutput(&o, x, o[x]);
    return rc;
    }
    

×
×
  • Create New...