Jump to content

Number Six

City Council
  • Posts

    714
  • Joined

  • Last visited

  • Days Won

    15

Number Six last won the day on March 14

Number Six had the most liked content!

Reputation

2591 Excellent

About Number Six

  • Birthday 01/01/1004

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. FYI, this just went to beta: Of interest may be the new slash commands that were added. These function like /show_bind in that they show the "winning" bind for a given key, except they do it for all keys, so they produce output equivalent to the old /bindsave. Since they work like /showbind, they're named similarly to that command. There's one command that simply shows the list, while the other saves it to a file suitable for offline editing. I think it's important to note that the output shouldn't be fed to /bindload unless you know exactly what you're doing -- it's intended to use to as a starting point to build your own custom file to load, or to dump the list of defaults for purposes like populating a wiki page. Like the old /bindsave, it suffers from some gotchas that may come back to bite you, especially if you switch profiles. Anyone who's not doing advanced offline editing probably should stick with the /bindsave family of commands. Since it works like /bind_save used to, it's subject to the same oddities and bugs. One I found in about 5 minutes of playing around is that if you unbind a key in the UI, either by pressing escape or by binding a different key, then use /showbindall, that key will be missing entirely instead of bound to "nop". Once you log out and back in to the same character, saving it then includes the "nop" as it should. The same bug existed in the old /bindsave but I don't know if it was discovered or it documented anywhere -- that bug doesn't exist with the new version because it works differently.
  2. So, going to quote this because it isn't quite accurate and use it to springboard off onto a deeper dive into how the keybind system works. I explained a lot of this in the OP's previous thread on this topic but judging from the replies it looks like some of it bears repeating. I see some comments like 'the new system is less transparent' or 'it worked fine forever and was simple, why add this complex system' or 'the ebil devs dont want us to be able to see the defaults for reasons, that's why' (paraphrasing), but the thing is, none of that is really true. The profile system has always been there, the defaults being separate from the user binds was always a thing, no new systems have been added, no more complexity was added. Prior to page 7 they were just hidden from view. The /bindsave command was lying to you and pretending the system is much simpler than it really is. By papering over how the system actually works, it created a lot of incorrect assumptions and expectations. And while hiding those details usually worked okay, when something went wrong it resulted in completely opaque error states that led to people having to reset binds because the system wasn't behaving as expected but nobody knew why. So, while it may sound counterintuitive at first, I maintain that the new file format is actually more transparent because it's telling you what is actually happening and giving you visibility into how it really works instead of pretending to be something that it isn't. And let me reiterate, it's giving you visibility into how it's always worked. So, bit of a technical deep dive here, the keybinding system is built on layers. In most cases there will be two layers, but sometimes there can be more. Layer #1 - The default binds. These are read-only and are built in to the client. The server is not aware of these at all. The drop-down in the keymapping menu lets you select a different set of defaults (what we've been calling profiles). The server dutifully saves the name of your selected profile in your character record, but has no idea what it actually means and can't even validate that it's a real one. Layer #2 - Character binds. These are any custom binds that you've created with the /bind command and/or the options menu. They're a simple list of key name and command. Up to 255 of these can be saved in the character record on the server. When you're actually in-game, the client applies these layers such that the default layer sits at the bottom of the stack, then applies your character's binds on top of that. Again, this is not new, it's how it's always worked. That's also why you've never been able to /unbind a default key and instead have to /bind the key to "nop". The /bind and /unbind commands operate purely on layer #2 since that's what you have access to modify. Sometimes, additional layers can get added on top. A common example of this is the SG base editor, which adds a Layer #3 that contains the editing shortcut keys. Context menus also add a layer to the stack for keyboard shortcuts for menu items. There's a few other miscellaneous cases like that where the game adds another temporary layer on top of the stack. If you had a context menu open while in the base editor, there would be 4 layers -- two of which can override your custom binds on layer 2. The way the /bindsave command was working was to save the apparent binds -- the result of mashing the entire stack together. Which is convenient if you want to edit them by hand, I agree. But it also causes some issues. One edge case I've personally seen bite somebody is saving keybinds from the options menu while in the base editor, which caused that temporary overlay with the edit keys to be saved to the file, overwriting some of their actual gameplay binds. The other part of the problem is /bindload. Since it's dumb and just issues /bind commands for each line, what it's effectively doing is loading the contents of the file into Layer #2. It's a bit more complex -- /bind tries to ignore a bind that already exists in some form so the defaults tend to avoid getting duplicated, but there are some caveats and various conditions that cause something saved from layer #1 to bleed over and end up getting copied into layer #2 by loading a file. That not only wastes one of your 255 slots but also means that swapping profiles won't work, or worse, may only partially work (which, one more time, profiles are not a new thing even if they were underused). The way the command works now is to save the profile name, as well as the contents of Layer #2. Basically the exact same thing that is saved in the character on the server, and the only part that can actually contain any custom data. It's a bit less convenient if you want to see the defaults for easy editing, but it gives you visibility into what's saved on the server and knowledge that the layer you can fully control (layer #2) is exactly what you want it tot be. Before I27P7 there were 3 sets. Now there are 4. There were: Default Joystick Original In I27P7, Modern was added and made the default for new characters (unless you have a keybinds.txt with a KeyProfile line in it!). Default was renamed to Classic. And Original was renamed to Issue 1 because it would have been really confusing if there was both Original and Classic. I can get those if you really want them to document them. Very few people were using them and Joystick probably needs a serious look to revamp it for modern game controllers (that's a whole other can of worms). As I mentioned when I replied to you, as well as in the OP's original thread on this, I did say that we're going to add a command to save the defaults out to a file to make it easier to get those. It hasn't been a super high priority in the rush of post-page7 fixes because it's an inconvenience that can be remedied by copying from the wiki page and there are a lot of other gameplay affecting things that needed attention, but I did say I'd add one and intend to follow through. They're actually in data/kb.bin on the client - remember I mentioned the server doesn't know about their existence at all. They could probably be decoded from there, I know a couple people have bin file readers to parse powers data, but probably not worth the effort if a command to dump them is coming soon. Don't know about sharing them ingame, would be tricky since they're purely clientside. That's something that with a little bit of code support could be done with client mods though. That's an oversight. I'm going to add an optional UnbindAll keyword to the file the /bindsavefile automatically sticks in there in order to make it work as it should. It needs to be optional to avoid breaking bind files that intentionally depend on not resetting and only swap a few keys around.
  3. It's not supported as in we don't offer technical support or help with it other than help migrating. We do still publish manifest updates for it and will publicly announce before that practice is discontinued. However, it's not integrated into our automated build & deploy system and requires manual steps to update. Availability of the people who can run those steps varies, so updates after a patch may be delayed.
  4. @ZemX If you're not doing manual editing out-of-game, you should see no difference at all (and if you do please report it as a bug!).
  5. I checked the database and it appears to be a legitimate transaction. The lucky bidder on Reunion has a number of standing bids for that item at similar values, and the seller on Excelsior listed the item for a lower price, looks like the stars happened to align.
  6. It was a case of the auction server creating a hash table using the old Cryptic StashTable implementation, which defaults to storing pointers to string keys instead of the actual string. That's fine for read-only data that's always in memory, but not when the table is being populated by a small number static memory buffers being filled out by a function to generate the key. In this case a set of static buffers on a rotor so that recursion could work for a few levels. That in turn caused hash key collisions - which are normally resolved by comparing the actual keys - to sometimes get a false match on the comparison function if the same buffer was used twice in a row due to the rotor wrapping around, or if multiple slots were filled by the same temporary copy of the key. When that happened the two items with the colliding keys would be considered as equal when they really weren't. It could also cause false negatives where no item would be returned at all because it was comparing the wrong string. The irony there is it meant that spamming the "Find" button to try to refresh history made it more likely to return the wrong history, but only if the table was already at a certain size so that there were colliding keys, and there was a fair amount of other traffic hitting the server to increment the rotor. That's why the UI enhancements to automatically refresh the display seemed to make it get worse instead of better. The fix itself was incredibly simple -- just have the StashTable copy the keys instead of storing a pointer. We do have a better hash table that newer code like the launcher and some newer game featuers are using that it could have been switched to. That implementation uses fancy strings that have automatic memory sharing and copy-on-write semantics. Switching to that would have also resolved it, but in the middle of a page I opted for the conservative route to just do the simple fix.
  7. And fwiw I 100% agree that anyone doing any kind of non-trivial key binding should be using /bindsavefile very intentionally. But that's always been the case, because /bindsave has always blindly overwritten a single file and destroyed anything you have set there in favor of the currently logged on character.
  8. It's not annoying, and I've been trying to stay out of it because you're entitled to your opinion. Just want to make sure players have accurate information about what exactly happens when they save files rather than uncertainty that they "might lose something", so they can make an informed choice.
  9. I know you're campaigning against something you don't like, but this is bad advice. Bindsave works perfectly fine for what the command says it does - saving the binds on one character (regardless of how they came to be), and reproducing them exactly on another. The generated files are as functional for that purpose as they always have been. ANY customized binds that are loaded on the character will be saved when you use the command. The only thing you "lose" when saving is the list of defaults if you had them, which is only relevant if you plan to hand edit the file outside the game, and can simply be copied and pasted from here instead. If someone can find a way to reproduce behavior where any existing binds on a character are lost after a save/load cycle, please report it so we can fix it!
  10. What people are describing sounds more like the behavior of the "free camera movement" option that was enabled by default for new characters. Without that, all movement is relative to the character's current facing rather than the camera (aka "tank controls"), which can be disorienting or annoying unless you're used to that. The camturn forward bind is only a small piece of it and just serves to cover a few edge cases where the free camera movement setting doesn't get you 100% there.
  11. Probably. Hopefully. Fingers crossed. It should be, but it's not really possible to test on beta due to high traffic conditions being part of the set of circumstances that trigger it to start happening.
  12. No, that's launcher stats, and that's why I said it's a rough guess, because it can only disambiguate based on source IP. But people change IP address within a month all the time, either playing from a different computer or moving to a different network. It also counts people who simply open the launcher - maybe to check for news - but never actually run the game.
  13. Yes, it means the original Windows 8, not the 8.1 update. vNext shows up in the launcher stats as "Windows 11 Server" but what it really means is a server OS with a build number >= 22000. AFAIK there isn't a release or LTS yet with that build number and it's preview releases that are sometimes referred to as "vNext".
  14. If anything I'm more surprised at how low the win7 numbers are. I thought there were more die-hards. Although, there may be a significant overlap between win7 die-hards and players who will cling to Tequila until the day the manifests stop being updated, so they wouldn't show up in these stats. Still about 5,000 uniques in that same time period hitting the old manifest urls.
  15. You're remembering wrong, the absolute minimum requirement for HC is Windows XP, Service Pack 2. It uses API calls that did not exist prior to that version. The 64-bit build requires either Windows 8.1 or Windows 10/11. It might run on 64-bit Windows 7 -- I don't remember the exact details of which features were added when and which specific SDK version dropped support for 7. But the 32-bit client is explicitly built using a toolchain that supports those older versions for compatibility. Not saying it will be the case forever, but our general rule of thumb is to try to make it so that if they could run it at shutdown in 2012, they can come back in now on the same machine. As for how many people are using it; we don't have exact numbers because we don't collect that kind of detailed information. The launcher does include OS version in the user agent string so we have a rough aggregate guess based on that. Over the past 30 days: Windows 11 (64-bit) 30189 Windows 10 (64-bit) 36042 Windows 10 (32-bit) 194 Windows 8.1 (64-bit) 207 Windows 8.1 (32-bit) 6 Windows 8 RTM (64-bit) 8 Windows 7 (64-bit) 619 Windows 7 (32-bit) 58 Windows Vista (32-bit) 4 Windows XP (32-bit) 1 Windows Server 2012R2 (64-bit) 6 Windows Server 2016/2019/2022 (64-bit) 2 Windows Server vNext (64-bit) (lolwut) 1 Wine (Mac/Linux) 4843 Note that just tells us the OS, not if someone is running the 32-bit client on a 64-bit OS, which might be done for a variety of reasons including some older graphics drivers that don't play nice. Though at least in that case, if they're on a 64-bit OS, the 32-bit client can use up to 4GB of address space instead of 2GB, which is less problematic. Also a glance through the support forums and discord to see a number of people reporting "Out of memory" errors when running the 32-bit client confirms that it's at least a decent number.
×
×
  • Create New...