Arena Commander - Programming

  • CIGBrandonEvans

    Staff

    Posted:
    Posted:
    [hide]

    TheRealHuntokar:
    [hide]

    [hide]

    Would it be possible to make the gimbaled weapons (maybe optionally) converge on an optimal point, and maybe also auto-align (optionally) with the fixed weapons? So you would only have one lag indicator for all gimbaled and fixed weapons (as long as you only have one type of fixed weapons). I think this could really help if you have a lot of different weapons on a ship like the Hornet.

    Also are there any plans to balance the mouse+keyboard vs. the Joystick controls?

    Gimballed weapons have always converged and we added the ability to lock your gimbals to the fixed reticle (with convergence) in 13.2
    @TheRealHuntokar

    What about fixed weapons? Do they converge on target the same way?

    In other words, I play dual joystick so manually controlling the gimbals is pretty much out of the question. It may just be placebo but I seem to notice an improvement in performance when I replace the fixed mounts on the wings of my 350r with gimbals- i.e. gimbals appear to have improved convergence compared to fixed.
    Fixed weapons have a very small range of motion with which to converge I believe
    Nil sa saol seo ach ceo, is ni bheimid beo ach seal beag gearr.
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    Is it currently possible to use TrackIR to just look around and not aim? If not are there any plans to add this option?

    Hello @iHover,

    You can either toggle the free look mode (tab on default keyboard layout) or gimbal lock your weapons (left alt on default keyboard layout). Aim and look are currently tied together, so I don't think there is an option where you can use one method for look input and another for aim input at the same time.

    Cheers,
    Jens
  • CIGBrandonEvans

    Staff

    Posted:
    Posted:
    [hide]

    What colour scheme does Mark Abent use in visual studio at the Bug Smashers segment of Around The Verse?

    Salmon
    Nil sa saol seo ach ceo, is ni bheimid beo ach seal beag gearr.
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    Hi devs.
    would it not be possible to have a modifier key that switches yaw to roll on the x axis. Meaning, when I press say the x key when I move my joystick I roll instead of yaw, then when I let go of x key I yaw again.
    the only time I saw this done was in starlancer years ago, so it could be done again now yes.
    Pleeeeeze.

    Hello @TOMAAS-HAAS,

    That sounds a lot like how the default gamepad layout has been setup. Left thumb stick X controls yaw, but if you hold left trigger it controls roll. Unfortunately, it appears the controls customisation interface will not accept keyboard modifiers for joystick input. It works if you load the mapping via XML:

    <action name="v_roll">
    <rebind device="joystick" input="lctrl+js1_x" />
    </action>


    I'll see what I can do.

    Cheers,
    Jens
  • CIGBrandonEvans

    Staff

    Posted:
    Posted:
    [hide]

    Quick question about the new radar / scanner system (as outlined on Around the Verse episode 20).

    it was described as identifying ships that came within the range of the radar, and then checking whether they were visible. My question is around how radar 'range' is defined:
    *) Is it a hard range (ie nothing it detectable beyond that range, even if it would be immediately detectable as soon as it comes within range), or
    *) is it a 'soft' range (the distance at which a signal of XX strength can be detected - meaning that if a ship had a higher output than XX, it could be detected beyond the listed range of the scanner)

    It's more complicated than either of those and based on actual signal processing technologies
    Nil sa saol seo ach ceo, is ni bheimid beo ach seal beag gearr.
  • mabent_cig

    Staff

    Posted:
    Posted:
    [hide]

    TheRealHuntokar:
    [hide]

    [hide]

    Quick question about the new radar / scanner system (as outlined on Around the Verse episode 20).

    it was described as identifying ships that came within the range of the radar, and then checking whether they were visible. My question is around how radar 'range' is defined:
    *) Is it a hard range (ie nothing it detectable beyond that range, even if it would be immediately detectable as soon as it comes within range), or
    *) is it a 'soft' range (the distance at which a signal of XX strength can be detected - meaning that if a ship had a higher output than XX, it could be detected beyond the listed range of the scanner)

    It's more complicated than either of those and based on actual signal processing technologies


    Will there be IR imaging available to scan IR signatures, like a little FLIR screen or an IR filter for our HUD or whole cockpit? My thoughts on this system would be using it to seek out small hot spots against the cold of space for exploration/salvage/search and rescue. A nearly dead pilot with a dead transponder and no strobe beacon could be found with a FLIR camera floating in the endless black.

    Also might be useful for doing science, why not? :)

    Example FLIR image:

    opplanet-flir-hs-324-command-19mm-therma
    We had a talk internally about this very thing. It is entirely possible. :D

    We have all the input information one would need for the shader ( if not then it should be feasible to provide the extra information needed ).
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    Technical question: Could you give us a rundown on how Arena Commander determines the order in which it assigns Joysticks? This changed a couple patches ago, but I'm not sure whether this was something you guys did, or is from a CryEngine integration. Knowing how this process works would help us find workarounds for getting AC to actually detect the joystick(s) we want it to rather than randomly deciding that you should have to fly entirely with pedals. DirectInput seems to have like 4 or 5 different ways it provides joystick IDs, so it's not at all obvious how AC gets this info.

    Hello @Tei,

    This is all on us, but the change made is relatively minor. It still goes off the order in which windows lists the devices in the Game Controllers panel. However, if the device driver product name contains "throttle" or "pedals" it will try to relocate the device to js2 or js3. This is to fix an issue where the X55 HOTAS unit frequently appears before the flightstick device.

    I hope that helps! :)

    Cheers,
    Jens
  • CIGBrandonEvans

    Staff

    Posted:
    Posted:
    [hide]

    As we have to , on finishing a vanduul swarm session, reload the hangar module/scene , I assume that the Arena Commander Menu (GUI) functionality is located in the hangar module.

    To improve the Arena Commander experience it would really be a nice thing to have the Menu functionality also present in each Arena Commander scene. This so we can, after finishing up our session, immediately start another session using the Arena Commander Menu.

    I do not know if the Cry-engine supports additive element instantiating in seperate scenes ( you can for example simply achieve this in Unity3D ).

    Could something like this be considered? It would really improve the session transitions.

    (hope that this is the right thread to post this question .. didnt know where else to put it)

    That UI isn't in any scene, it's in the ship. It kicks you back to the hangar so the server can close the instance and free it for a new game rather than waiting to see if enough people want to continue playing on it. It's partly a backend decision and partly a design decision.
    Nil sa saol seo ach ceo, is ni bheimid beo ach seal beag gearr.
  • Jens_CIG

    Developer

    Posted:
    Edited: by Jens_CIG
    Posted:
    Edited:
    [hide]

    I run a multi-controller setup for nearly all sim games I play on:

    Logitech G27 for racing and rudder pedals (3 pedal set accelerator/brake/clutch).
    TM Cougar for throttle and flight stick.

    I have setup my HOTAS layout to work with SC and have been having a load of fun, but have found a few issues:

    At present SC provides you the option to assign the G27 pedals to the 'yaw' controls, but the pedals have got to be set in combined mode causing the accelerator and brake to act as one axis and the game completely ignores the clutch pedal. Also SC only seems to detect full left or full right from the pedals, so no smooth input, just jerk to the side at full thruster.

    A more usable layout is to have the G27 accelerator act as Yaw Right and the clutch act as Yaw left with progressive analogue input. This would be achieved by allowing the 3 individual pedal axis to be assigned to separate commands such as:

    Clutch pedal: Yaw Left
    Brake pedal: Boost
    Accelerator pedal: Yaw Right

    There is a 'Yaw left' and 'Yaw right' option provided already in SC but, these are only mappable to a button press not an axis.

    Would it be possible to allow all ship movement controls to be assigned to an axis input as well as a button press from a controller?

    This would allow those that have multiple controllers to assign specific axis to control the crafts movement with smooth inputs rather than relying on pressing a button.

    So a final control option would be Yaw Left / Yaw Right / and Yaw (override for single axis controllers).

    This could also be applied to the 'Roll' settings as well for those that prefer roll on the pedals.

    And a 'unbind' option to remove unwanted key/axis binds would be most useful.

    Hello Andy (@Mearcat),

    Good news! :) Both the ability to assign yaw left and yaw right (and a bunch of other actions) to axis input and the unbind functionality have been implemented. They are currently being tested internally, but should be available in the next major release.

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    Answer:
    [hide]

    Another Quick one is SC is not too friendly with the toe brakes on rudder pedals. is there a way we can set a forward only function or zero out Axis points so lifting your foot off the pedal doesn't set you to -50% axis.

    Hello @Answer,

    As mentioned previously (see https://forums.robertsspaceindustries.com/discussion/comment/3746660/#Comment_3746660) you can bind some single directional actions, like strafe_forward, to the pedal via XML. This will make the game treat the input as [0,1] instead of [-1,1].

    In the next major release, this will be possible to do via the in-game menu keybinding interface too (see https://forums.robertsspaceindustries.com/discussion/comment/3634130/#Comment_3634130).

    I hope that answers your question, @Answer.

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    [hide]

    [hide]

    I run a multi-controller setup for nearly all sim games I play on:

    Logitech G27 for racing and rudder pedals (3 pedal set accelerator/brake/clutch).
    TM Cougar for throttle and flight stick.

    I have setup my HOTAS layout to work with SC and have been having a load of fun, but have found a few issues:

    At present SC provides you the option to assign the G27 pedals to the 'yaw' controls, but the pedals have got to be set in combined mode causing the accelerator and brake to act as one axis and the game completely ignores the clutch pedal. Also SC only seems to detect full left or full right from the pedals, so no smooth input, just jerk to the side at full thruster.

    A more usable layout is to have the G27 accelerator act as Yaw Right and the clutch act as Yaw left with progressive analogue input. This would be achieved by allowing the 3 individual pedal axis to be assigned to separate commands such as:

    Clutch pedal: Yaw Left
    Brake pedal: Boost
    Accelerator pedal: Yaw Right

    There is a 'Yaw left' and 'Yaw right' option provided already in SC but, these are only mappable to a button press not an axis.

    Would it be possible to allow all ship movement controls to be assigned to an axis input as well as a button press from a controller?

    This would allow those that have multiple controllers to assign specific axis to control the crafts movement with smooth inputs rather than relying on pressing a button.

    So a final control option would be Yaw Left / Yaw Right / and Yaw (override for single axis controllers).

    This could also be applied to the 'Roll' settings as well for those that prefer roll on the pedals.

    And a 'unbind' option to remove unwanted key/axis binds would be most useful.

    Hello Andy (@Mearcat),

    Good news! :) Both the ability to assign yaw left and yaw right (and a bunch of other actions) to axis input and the unbind functionality have been implemented. They are currently being tested internally, but should be available in the next major release.

    Cheers,
    Jens
    @Jens_CIG:
    Please implement the Axis Invert too (a sorely missed feature), and also a "delete mapping" feature so we can actually REMOVE mappings we don't want to use at all (since using several commands on a single button is possible, that means when I use my main HAT for strafing left, right, up and down, I need to remove the mappings for 'look left', 'look right' etc).
    [hide]

    Still no delete function for default key bindings!!

    Arena Commander is out since 6 months!

    66 million dollar funds!

    I spend 320,-$ and still don't be able to bind keys to my HOTAS like i will.


    Is it possible to add a little delete button for default key bindings?


    Hello @skuripanda and @DerHesse70,

    Yes, the "delete mapping" and "delete function" will be available soon. That's what I meant by "unbind functionality" in my previous answer (see https://forums.robertsspaceindustries.com/discussion/comment/3909289/#Comment_3909289).

    Cheers,
    Jens
  • ABrown_CIG

    Staff

    Posted:
    Posted:
    [hide]

    To the devs:

    I come here as a long time contributor to the Hardware section of the forums (2 MVP's and 2 Sticky'd help threads), where we're often the front line for troubleshooting hardware related issues with the Hangar module / AC module.

    I only mention this because I'm here to strongly recommend that if at all possible, some efforts should be made to ensure that devices with discrete mobile GPU (in particular laptops) automatically select the discrete card rather than the CPU's integrated graphics card in order to run the current Star Citizen modules.

    I fully understand the fluid & very early stage that SC is in, but I assure you that every single day, there is at least one, and up to five people posting in the Hardware section assuming their laptop is broken or getting cranky at CIG because their 'elite gaming laptop' (whether that's true or opposite) runs the game at 3 fps thanks to defaulting to the integrated graphics card.

    I'm not sure if there's much CIG can do from their end, but even if it means getting onto Nvidia (who represent the extreme majority of gaming class mobile hardware) & AMD and asking nicely for some cooperation on this matter, then I think it's a worthy use of time - Because if there are several people a day asking for help in the Hardware forums, I can only imagine the amount of silent people who have to find the solution in the Hardware forum Sticky'd threads, or have to try either looking elsewhere, or not looking at all & giving up. It wastes a seemingly inordinate amount of user time (and forum user time to help out) for a trivial problem. To put it in another way - This could represent an easy multiple order of magnitude performance increase for the many laptop users who are unaware that Star Citizen's alpha modules are one of the rare games that don't correctly launch on discrete GPUs by default.

    I'm not sure if this is even the correct place to post this message - So please let me know if there is a more useful place to post this.

    Thanks in advance,

    CynicalCyanide.

    Hi CynicalCyanide,

    Thanks for raising this, I wasn't aware the issue was so wide-spread. I'll do my best to raise the priority of this and get it looked at as soon as practically possible.

    Thanks,

    Ali Brown
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    Greetings Jens (@Jens_CIG)

    Thanks for doing an awesome job keeping us updated both on existing and upcoming features.

    I am using a Saitek X52 Pro. This stick has a two-stage trigger.

    I have not been able to successfully add the second stage of this trigger to any functions ingame.
    I am aware there are some ways of solving this either through XML-editing or profiles for X52 mapping its buttons to keyboard inputs. However - I am a fan of being able to make these changes within the game itself.

    Today you can assign controls by selecting a function, and then simply using the control (click a button or move a stick).
    Would it be possible to, in addition, add a second option, where you instead of using the control, would select the appropriate control from a drop down menu?

    Do you plan on making game settings such as control configuration stored on a cloud solution and connected to the account?
    Some games have this today, where when you reinstall your computer or buy a new one, all your previous settings and configurations are stored on a cloud system and downloaded locally when you reinstall the game client.

    Sincerely
    Jergon Heckory

    Hello @Sjelden,

    I'm sorry to hear you are having problems mapping the two-stage triggers. It is one of the issues I recall fixing in 0.9.1 or 0.9.2. The game should let you map the first stage if you press the trigger in half-way and the second stage if you press it all the way in. I suggest you raise the issue with QA and they should be able to better explain how it is done.

    Adding additional methods for action mappings in the UI interface is definitely a possibility. Let's just say we are barely out of the driveway of the UI roadmap... :)

    Not sure about storing the control settings in the cloud as the devices you have connected to one machine might be completely different from your other machines. However, you will be able to export all your controls settings and re-import them after reinstallation.

    Thank you for your feedback!

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    Is there any way to currently back up modified controls so every time theres a patch I don't have to redo it?

    Hello @Dostro,

    You can export your current keybindings for a device using "pp_rebindkeys export" in the console command window. For example, "pp_rebindkeys export joystick" will generate a file called layout_joystick_exported.xml in the Controls/Mappings folder. You can then re-import it with "pp_rebindkeys layout_joystick_exported" after installing a new patch. This is only necessary if the patch installation deletes your USER folder. You might want to back the XML up somewhere outside of the Star Citizen folders before applying a patch; just to make sure it doesn't get wiped too.

    All the above functionality will soon be available in the UI as well. However, some patches may contain changes which render a previously exported file completely or partially unusable. It's all in the spirit of pre-alpha. :)

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    [hide]

    [hide]

    Is there any way to currently back up modified controls so every time theres a patch I don't have to redo it?

    Hello @Dostro,

    You can export your current keybindings for a device using "pp_rebindkeys export" in the console command window. For example, "pp_rebindkeys export joystick" will generate a file called layout_joystick_exported.xml in the Controls/Mappings folder. You can then re-import it with "pp_rebindkeys layout_joystick_exported" after installing a new patch. This is only necessary if the patch installation deletes your USER folder. You might want to back the XML up somewhere outside of the Star Citizen folders before applying a patch; just to make sure it doesn't get wiped too.

    All the above functionality will soon be available in the UI as well. However, some patches may contain changes which render a previously exported file completely or partially unusable. It's all in the spirit of pre-alpha. :)

    Cheers,
    Jens
    That is a really cool feature! Is there a way to export all possible keybindings? Right now it seems to only export what you changed. I'd rather have a full list of all options so that I can actually map my controllers outside of SC. (Makes it easier to reconfigure my controllers when needed as well)
    Hello @Forceflow,

    That sounds like a reasonable option.

    Did I mention we programmers in the UK office like cakes? ;)

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    Dakato:
    [hide]

    Hey Devs,

    why is there no action like "v_roll_mouse"? A lot of us Keyboard\Mouse players would like to roll with the mouse x-axis.
    Is there any reason behind this or did you guys just forget that ? :]

    Hi @Dakato,

    I don't think roll input is something that comes natural to our original two mouse control modes (virtual joystick and relative / drag to move). But I can see it working with the new fixed weapons / gimbal lock modes. It's more of a design decision though - I'll give them a nudge.

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    I would like an option to totally disable mouse input from the flight model in the options somewhere, maybe on the controller menu. I realize I could just technically load a keybinding xml file with all the mouse functions 'blanked out', but would be nice to have a quick option for it.

    Hi @Booyaah82,

    Try loading the CIG2 keyboard layout preset. It should clear the main flight control mouse actions. It will still control the aim reticle - unless you toggle the gimbal lock on (by default mapped to Left Alt on keyboard).

    Cheers,
    Jens
  • DrBone

    Developer

    Posted:
    Posted:
    xuohdx:
    [hide]

    Are there any plans to redo or optimize the holotable UI? It still acts a bit funky when scrolling through Weapons/Engines/Ammo etc. tabs.

    Yes, this was our "first pass" and done in the neolithic era of CIG and will be superseded by mobiGlas.
  • Jens_CIG

    Developer

    Posted:
    Edited: by Jens_CIG
    Posted:
    Edited:
    [hide]

    A question about the layouts, might be in the wrong thread:

    I got some question about the XML line: <CustomisationUIHeader device="" label="" description="" image="">
    device needed (keyboard/joystick/xboxpad)?
    label is to put a name on the dropdown menu in controlpresets. Ok.
    description Is @ui_KeyboardPresetCIG3Desc a specific format or can I type whatever I want?
    image:
    Can we please get access to the images used somehow without all the keybinds? So we can edit them on our own.
    And where can we put the image in the gamesystem to load into the game?

    Future: Could we get a way to easely share a zipfile with Keybinds including a image folder with the correct image.
    This might give newer players a way look through images on controls and import them with easewithout diving into all kinds of keybinds.

    Hello @Ferocitan,

    The device attribute is there for backward compatibility. You can put a single device in there, like xboxpad or joystick. However, if your XML makes changes to multiple devices you will want to list them so the import dialogue gets populated correctly:

    <CustomisationUIHeader ...>
    <Devices>
    <keyboad instance="1" />
    <joystick instance="2" />
    </Devices>
    </CustomisationUIHeader>


    Description is not used at the moment. The @ tells the game to perform a lookup query in the localisation database - rather than just display whatever text is in there.

    As of 1.0 I don't think the image attribute is used.

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    Hey,

    Forgive me if this is the wrong place to ask, but I've spent hours trying to figure out why I can't get the game to simply assign "roll" to a mouse's X Axis and work in both directions.

    I have seen previous attempts, that look like the following:

    <ActionMaps version="1" >
    <actionmap name="spaceship_movement">
    <action name="v_roll_left">
    <rebind device="keyboard" input="" />
    </action>
    <action name="v_roll_right">
    <rebind device="keyboard" input="" />
    </action>
    <action name="v_roll_right">
    <rebind device="keyboard" input="maxis_x" useAnalogCompare="1" analogCompareVal="-10" analogCompareOp="LESSTHAN"/>
    </action>
    <action name="v_roll_left">
    <rebind device="keyboard" input="maxis_x" useAnalogCompare="1" analogCompareVal="10" analogCompareOp="GREATERTHAN"/>
    </actionmap>
    </ActionMaps>


    .. but this doesn't seem to work (whether it's the new release or not). I only seem to be able to roll anti-clockwise with the above setup. If I add in the Invert attribute, then it will roll the other way, but as far as I can tell there's no way to assign two bindings to the same control, even with the above, different attributes set. How does SC read mouse input? I would have thought on the X axis it starts at 0 and goes to either positive values for left, and negative values for right (or vice versa), but judging from my attempts and failed findings, this doesn't seem to be the case.

    I can see there is a "v_roll" function, but this doesn't seem to work with the mouse x-axis as it does with a joystick's axis or a gamepad's axis. I'm unsure on the differences.

    I've asked numerous times on the ActionMap thread, but it seems I'm the only player actively seeking a way to do this.

    I would really appreciate some input, even if it's just a "yeah, this will be in a later patch".

    I've been supporting this game since the beginning and I've been waiting so long to finally get in and play, but this one hurdle is the only thing stopping me from enjoying it the way I want to play.

    Thank you in advance.

    Hello @FFLink,

    The rebind flow doesn't support AnalogCompare attributes. It's an interesting approach to the issue - but it feels impractical as your mouse input wouldn't be very smooth. It'd send either 0 or 1.

    You are not the only one after this feature. I did answer a similar request recently, see https://forums.robertsspaceindustries.com/discussion/comment/4059408/#Comment_4059408.

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Edited: by Jens_CIG
    Posted:
    Edited:
    StefanB155:
    [hide]

    Just noticed that there seems to be no inversion option for analog zoom, any chance we can get that in the near future ?

    I now use Fanatec USB Pedals, clutch for strafe back (thx btw that that this takes analog input although asking for digital, much appreciated), throttle for throttle and i wanted to try the brake for zoom, unfortunately all axis on those thing are inverted...
    (and no option in driver to invert)

    Zoom on pedal sounds strange, but i don't need the left foot while long distance targeting and it would make me back off the zoom automatically if i have to slow down when coming to close, also would free up two precious buttons on the stick.

    Hello @StefanB155,

    Yes, that should be no problem, I'll forward the request to the design team.

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Edited: by Jens_CIG
    Posted:
    Edited:
    [hide]

    StefanB155:
    [hide]

    First things first, merry Christmas to all and congratulations on 1.0, another big step forward after 9.2 !

    Is the new flight control sensitivity slider for stick/HOTAS working as intended ?
    I noticed that it cut's turn rate severely if you go under 0.50 and that seem strange to me, even more so because going over 0.50 does not increase it.
    With 0.50 set (in flight control yaw) i do a yaw 360 in 4.2sec at full stick deflection, with 0.25 it takes 8sec. !

    I've noticed the same after I set the overall sensitivity somewhere to 0.30. The Throttle range was only from ~25-75%. Can't tell about the other axis but this looks like linear which cut's the end of the axis. This way sensitivity settings doesn't just make sense.

    Cheers,
    Apollo4
    Hello @StefanB155 and @Apollo4,

    Thank you for your feedback. I'll raise it with design.

    Sensitivity for gamepad and joystick is currently pretty much just saturation. So the intended behaviour is that if you go below the default value (currently 0.5) you desaturate the stick and therefore reduce the output generated; when at full physical extension it will send a value less than the maximum (1). Basically, you will turn slower. If you go above (0.5) then the output is increased; it will hit the maximum value (1) before being fully extended. You won't turn any faster, but you will hit the max turn rate earlier. It's all linear.

    The way you guys describe sensitivity is achieved using the non-linearity curves. This lets you set custom output values across the range of the axis input. Unfortunately, this feature is currently only available in XML. Coming soon to UI!

    @StefanB155, can you raise your strafe issues with QA?

    EDIT: So on re-reading this as I was about to forward it on I had another look at @Apollo4's post and, yes, the throttle issue is a bug. The range should have changed to 0%-75%, not 25%-75%. This is due to the way the throttle remaps the [-1,1] input to [0,1] output. I'll see about fixing that.

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    StefanB155:
    [hide]

    @StefanB155, can you raise your strafe issues with QA?

    Sure, if you tell me who that is and how i contact him :-)
    (quality assurance/question&answer/bug report ? , sorry don't get it. language barrier)

    Sensitivity for gamepad and joystick is currently pretty much just saturation. So the intended behaviour is that if you go below the default value (currently 0.5) you desaturate the stick and therefore reduce the output generated; when at full physical extension it will send a value less than the maximum (1). Basically, you will turn slower. If you go above (0.5) then the output is increased; it will hit the maximum value (1) before being fully extended. You won't turn any faster, but you will hit the max turn rate earlier. It's all linear.

    I see, and am glad that i can adjust linearity it in Sidewinder software without cutting max. output.
    (I use between 0-25% standard 1:1 is WAY to sensitive for me)
    Maybe there should be a hint ? i can see people turning it down in game controls and then wondering/complaining why ships turn so slow with full deflection (going from a racer to a bigger ship especially).

    Regards, Stefan
    Sorry @StefanB155, Quality Assurance is where you want to go. :)

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    [hide]

    [hide]

    StefanB155:
    [hide]

    First things first, merry Christmas to all and congratulations on 1.0, another big step forward after 9.2 !

    Is the new flight control sensitivity slider for stick/HOTAS working as intended ?
    I noticed that it cut's turn rate severely if you go under 0.50 and that seem strange to me, even more so because going over 0.50 does not increase it.
    With 0.50 set (in flight control yaw) i do a yaw 360 in 4.2sec at full stick deflection, with 0.25 it takes 8sec. !

    I've noticed the same after I set the overall sensitivity somewhere to 0.30. The Throttle range was only from ~25-75%. Can't tell about the other axis but this looks like linear which cut's the end of the axis. This way sensitivity settings doesn't just make sense.

    Cheers,
    Apollo4
    Hello @StefanB155 and @Apollo4,

    Thank you for your feedback. I'll raise it with design.

    Sensitivity for gamepad and joystick is currently pretty much just saturation. So the intended behaviour is that if you go below the default value (currently 0.5) you desaturate the stick and therefore reduce the output generated; when at full physical extension it will send a value less than the maximum (1). Basically, you will turn slower. If you go above (0.5) then the output is increased; it will hit the maximum value (1) before being fully extended. You won't turn any faster, but you will hit the max turn rate earlier. It's all linear.

    The way you guys describe sensitivity is achieved using the non-linearity curves. This lets you set custom output values across the range of the axis input. Unfortunately, this feature is currently only available in XML. Coming soon to UI!

    @StefanB155, can you raise your strafe issues with QA?

    EDIT: So on re-reading this as I was about to forward it on I had another look at @Apollo4's post and, yes, the throttle issue is a bug. The range should have changed to 0%-75%, not 25%-75%. This is due to the way the throttle remaps the [-1,1] input to [0,1] output. I'll see about fixing that.

    Cheers,
    Jens
    @Jens_CIG and @StefanB155 and @Apollo4

    FYI, I have had that throttle issue. For me, it was a result of a custom curve that did not have full endpoints. Here is a post with a full explanation and example . . . its in the middle of the post
    https://forums.robertsspaceindustries.com/discussion/comment/3950976/#Comment_3950976

    Happy Holidays
    Hello @H-Edge,

    I'll have to look into that a bit further. The game automatically creates the (0,0) and (1,1) points; you should never need to explicitly create them. Possibly an issue with how sensitivity values and non-linearity curves co-exist.

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    @Jens Lind

    Not sure if your explanations has covered what I have said below (after trying to understand - Possibly an issue with how sensitivity values and non-linearity curves co-exist).

    ### My Testing ###
    Joystick - Logitech Extreme 3D Pro
    In Game Control - Joystick/HOTAS 1

    Master Sensitivity - 0.50
    Ship - Mustang Omega
    Top Speed - 270
    If you then use the W Key on the Keyboard you can reach the top speed of - 270

    Master Sensitivity - 0.35
    Ship - Mustang Omega
    Top Speed - 229
    If you then use the W Key on the Keyboard you can reach the top speed of - 270

    Result - The Master Sensitivity equals a 18% drop/loss in throttle which needs to be made up for by using the keyboard when changing down the Master Sensitivity.

    With the throttle bug this should not be limited, the throttle should always produce 0% - 100% no matter the joystick's master sensitivity.

    Hello @Mav-rick,

    The throttle action option is currently a child of the master sensitivity option, but not visible in the menu. So it is picking up the changes, but you have no way to individually tweak it or lock it; I don't think the designers meant for that to happen. I will see about fixing it.

    In the meantime if you save the following snippet to a file (for example, c:\test.xml)...

    <ActionMaps version="1">
    <options type="joystick" instance="1">
    <flight_throttle sensitivity="1.0" locked="2"/>
    </options>
    <options type="joystick" instance="2">
    <flight_throttle sensitivity="1.0" locked="2"/>
    </options>
    </ActionMaps>

    ...and run console command "pp_rebindkeys c:\test.xml" in game - the throttle sensitivity should be restored and it will now be locked from any future changes to the master sensitivity.

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    [Controls mapping - Game-pad]
    I would like to use an analog stick as a modifier button. Will that be supported in the next updates of AC?
    For example having Roll assigned to the right stick's x-axis and Strafe Left/Right too but with the stick been pressed.

    Hello @S-P-ACE,

    User defined modifier keys is on the long list of features we would like to add to the controls customisation interface. Unfortunately, I can't give you any promises of when, or if, this will happen. Button input that also acts as a modifier adds a fair bit of overhead and complexity, so I don't want to add additional ones to the default list at this time.

    Cheers,
    Jens
  • Jens_CIG

    Developer

    Posted:
    Posted:
    [hide]

    Hello,

    I have some more control question, wanted to submit this in bugs but have no idea if those 3 behaviors are intended or not.

    1.: When i have mouse and a joystick axis assigned to flight pitch/yaw, it seems that mouse gets locked out forever for flying and only works for aiming, after i made the first input to the stick. Only after a respawn mouse works again for flight.


    2.: While using look back (".") the pitch control is inverted.
    This is technically correct for [stick or virtual stick mouse] flight, but since we usually also aim with the same device this is just horrible to use when you want to shoot a target behind you in a ship that can turn it's turret back.
    (requires moving mouse up or pull stick back to get crosshairs down on a traget)
    I tried right shift to unlock mouse aim from flight for that, it gives me usable pitch aim but only allows me a very small window of movement for aiming for some strange reason, and i always end up with looking in a random direction when i go back to forward view. In short it is no real option.

    So would it be possible that the inputs for flight/aim get inverted while i'm in look back mode so that they work the same intuitive way as forward ?
    (Or to make that an option in the controller settings so that everyone can select what he wants it to do)


    3.: I can't use my stick's POV hat to look around when it is binded to look l/r/u/d correctly, like in any other "flight sim" i know.
    I always have to toggle free look for that which is totally illogical, superfluous, time-consuming and button wasting.

    I totally get that the free look toggle is needed for mouse to decouple look from aim/flight when all is controlled by the same axis, but if i have separate buttons (or axis) assigned to it that are used for nothing else, why i still need to toggle ?
    (i bet trackIR/OR rift users don't need to toggle if they assign that device only to look)

    Hello @SevenB,

    1: Joystick input for ship rotation takes priority over mouse input. But if there is no joystick input, the mouse input should be used. So if you have let go of the joystick, but it is still blocking mouse input, the joystick is most likely sending some very, very small values. Try increasing the deadzone for the relevant axis a bit.

    2: This is currently being looked at for mouse pitch input.

    3: There are a lot of different inputs that control the head movement. For example, the default is aim input; in "couple aim move" (look ahead) mode it's a portion of the ship rotation input; and in "freelook" mode it's the look input. In your case, I'd bind the POV to aim l/r/u/d too.

    I hope that helps! :)

    Cheers,
    Jens
  • craigg

    Developer

    Posted:
    Posted:
    [hide]

    Jens, Do you have any explanation for the decision to make landing gear deployment automatic? Can you confirm whether or not this is a temporary thing? This drives me nuts in two ways:

    1- I see the lack of landing gear manual deployment as a missing feature. Deploying landing gear is one of those things that really helps with immersion.

    2- The landing gear often displays silly behavior. It deploys when it shouldn't, deploys and retracts repeatedly, etc. This means the silly automatic landing gear on other people's ships will still damage my immersion even if I can make mine manual.

    You are doing an awesome job, thanks!

    Trip

    Hi Trip,

    We're on it!

    Manual landing gear deployment and retraction is an integral part of the new landing system; deploying your landing gear will now initiate a landing state which will swap out your hud and provide optional auto landing support should you want it.

    Once landed, you'll manually retract your gears to initiate take off again.

    Craig
  • ABrown_CIG

    Staff

    Posted:
    Posted:
    [hide]

    Hi programming team!

    Quick question regarding the recent Windows 10 announcements and especially DirectX12: Have you been keeping up to date with the news regarding DX12? Any idea how much work it would take to integrate on your end?

    Thanks, and keep up the great work.

    Hi Whiplash,

    The Windows 10 announcement is certainly very interesting for us as it suggests we might get a better take-up of DX12 than we'd otherwise have expected (as DX12 is locked to Win10). Adding DX12 support is no small task for such a large and fully featured engine & game, however it's also an extremely high priority for us because everything about our game design seems to increase the number of objects we need to deal with and one of the main benefits of DX12 is to significantly reduce the per-object CPU cost of rendering (often the bottleneck for games). Of course there are other funky effects and features we could implement with DX12, but how much time we spend on R'n'D for DX12-only features will be proportional to how many users are running DX12, and this latest announcement gives me more hope we'll be pushing DX12 features sooner rather than later.

    Cheers,

    Ali Brown
  • Lodown

    Staff

    Posted:
    Posted:
    [hide]

    Hey I have a more overarching question for you all.

    How does releasing incremental versions of arena commander change the way your testers are operating (if at all)?

    Are they able to re-allocate their time from certain tasks knowing that the backers will, for the most part, be covering the same areas?

    Hey Glaiwo,

    Our process for each Arena Commander version has remained mostly the same over the last few months - except for growing the team to keep up with the size of the game! The biggest change has been that we're more busy now than we were 6 months ago.

    Each new patch will introduce bug fixes for major issues (which can cause other, new bugs) and a handful of features that will need to be tested such new hangar flare items, ships and the like. We allocate the time to give them a thorough testing before they go out in a patch to ensure most of the major problems can be fixed and they release in a functional state. This testing is usually focused on this in the week after a patch goes out, as there isn't the pressure to get a build out we have more time for this kind of testing.

    As a release date approaches most of our time is switched to be spent smoke testing the builds - going through everything in the game testing everything to make sure it works, and bugging up anything that does not. As the game's expanded to have more hangars, game modes and ships since Arena Commander launched, our smokes have also started to take considerably longer. Ourselves in UK QA and the ATX QA team need to co-ordinate to make sure these smokes get finished. Though we often try to allocate at least one tester to going over any new ships or features at any given time.

    We know we can't find everything, so will generally keep an eye on the forums, chat, reddit and the like to see what issues people encounter and bug any new issues. A lot of people in the public take videos, write up handy bug descriptions and reproduction steps which really help when an issue we haven't seen is found.

    Hope that answers your question. Apologies for hijacking the thread for some QA time.

    Cheers!
    Geoff
This discussion has been closed.