1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. Two Factor Authentication is now available on BeyondUnreal Forums. To configure it, visit your Profile and look for the "Two Step Verification" option on the left side. We can send codes via email (may be slower) or you can set up any TOTP Authenticator app on your phone (Authy, Google Authenticator, etc) to deliver codes. It is highly recommended that you configure this to keep your account safe.

Major (arguable) bug in Community Edition 2013

Discussion in 'Troubleshooting' started by Ironword300, Apr 13, 2016.

  1. Ironword300

    Ironword300 Member

    Joined:
    Mar 2, 2016
    Messages:
    55
    Likes Received:
    0
    I've found a serious problem with Community Edition 2013. This is in addition to the issues identified in https://forums.beyondunreal.com/threads/inf-2-9-ce-2013-game-breaking-bug.201789/ (Note: I did not play enough to confirm or disconfirm those issues--as the paragraphs below will make clear, I never even got that far.)

    To be fair, the CE2013 compilers may have considered the following problem a "feature". But it is such a major change in UT99 client-side operation that it should have been documented in the readme, and it wasn't. Because it is such a huge change under the hood, it is at least plausible that somehow it was a mistake that they didn't catch (although it's hard to see how they'd have missed it). At any rate, it represents a very big shift in the user interface of UT (and Infiltration), totally screwing people who do advanced keystroke customization and aliases.

    Here's the skinny:

    In CE2013 it looks like all keyboard commands are hardcoded to be set via hex in the menu system and then recorded somewhere else (location unknown), totally bypassing InfiltrationUser.ini (for initial steps in determining the uselessness of InfiltrationUser.ini, and the hex issue, see thread https://forums.beyondunreal.com/threads/clean-install-ce2013-with-no-console.204663/#post-2621124). I compared the InfiltrationUser.ini installed by the original (2004?) release of Infiltration 2.9 with CE2013's, and after the aliases, the entries come in a wholly different order. 2.9 has the same order that UT's default User.ini follows, but the CE2013 compilers decided to change that and reordered the entries to follow an alphabetical order. But one wonders why they bothered, as they have also hardcoded Infiltration to wholly ignore the file. Presumably InfiltrationUser.ini is included in CE2013 only because core Inf code checks for it and would probably error out if the file wasn't there. So they include the file, but it's nothing but a dummy placeholder. It has no real use whatsoever.

    Well, surely you can still customize keystrokes with the old standby, console > Preferences? Nope. CE2013 also appears to wholly bypass Advanced Options | Advanced | Raw Keybindings. If you clean-install CE2013 and open up Raw Keybindings, you'll find that the console is bound to the backslash. I changed it to the standard Unreal/UT tilde and exited. Nothing happened back in Infiltration.

    That was an eye-opener. I couldn't believe that Raw Keybindings could be jettisoned that way--it's too much of a staple in standard Unreal and UT--so I did a further experiment. First I checked Infiltration's GUI menus (Actions) to see what Grab/Use was. Turns out it's not set to anything. Then I went to InfiltrationUser.ini and found that it's set to "G". Third, I opened the console and did Advanced Preferences | Advanced | Raw Keybindings. In Raw Keybindings I found that Grab was set to "G".

    Staying there, I cut Grab from G and copied it into Enter, then exited Infiltration. Now, under normal UT/Infiltration behavior (at least all the way through original Inf 2.9), this would have changed both InfiltrationUser.ini and the Infiltration GUI menus to reflect what was done in Raw Keybindings.

    But that's not what actually happened. Upon restart, I found that Grab had been reset to Enter in Raw Keybindings, just as I had specified; but when I started up the game, summoned a weapon, and tried to get it, nothing happened. I paused the game and checked the GUI, where I found that Grab was still set to nothing. So Raw Keybindings is not transferring over to the actual game. And, for the record, as expected, it was also still "G" in the (useless) InfiltrationUser.ini. So in CE2013, none of these communicate with each other. CE2013 has completely severed the links between all three of what should be mutually interchangeable user interfaces.

    As a result of this nasty bug, the only customization the user can do is through the options given in the Infiltration GUI menus, and those, of course, are limited. If you like to do any customizations beyond the most basic, you cannot use CE2013; most especially if you like to use aliases, you're hosed. I don't use aliases myself, but I do have a number of custom keybindings (mainly for switching to each weapon directly, using GetWeapon, rather than depending on weapon priorities or SwitchWeapon). First I bind the weapon's code to a key, using either InfiltrationUser.ini or Raw Keybindings; either should work. For example, I bind the SCAR-L to the "Z" key in InfiltrationUser.ini with Z=GetWeapon INF_SCAR.INF_SCARLEGLMRxSup. And if I go to Z in Raw Keybindings and type "GetWeapon INF_SCAR.INF_SCARLEGLMRxSup", it's the same thing (and indeed should immediately be reflected in InfiltrationUser.ini).

    But in CE2013 you can't even do this kind of basic keybinding--let alone aliases--because Infiltration will not take up the changes from either InfiltrationUser.ini or Raw Keybindings. It completely ignores both of those sources.

    To be completely transparent, I do not know about console keybindings. In normal Unreal/UT you can also bind keys via console with the "set" command, but if you're doing a number of customizations it's a lot more cumbersome to do it that way than it is to change InfiltrationUser.ini (or User.ini, for regular Unreal). So I have never used that method, and I didn't test it here. Therefore it may be that CE2013 still allows custom keybindings specified via console. If someone else can test whether that's possible or not, we'll have a complete picture of the state of advanced keybindings (or, rather, the lack thereof) in CE2013.
     
    Last edited: Apr 13, 2016

Share This Page