Jump to content

Number Six

City Council
  • Posts

    714
  • Joined

  • Last visited

  • Days Won

    15

Posts posted by Number Six

  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.

    • Thanks 4
    • Thumbs Up 2
  2. On 3/19/2024 at 1:19 AM, BlackSpectre said:

    Right now, we can't see what keybinds are loaded into the server for our characters.

     

    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.

     

    13 hours ago, BlackSpectre said:

    Before I27P7 there was only one set of default binds, now there are 4.

     

    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.

     

    12 hours ago, BlackSpectre said:

    You can look up 2 (Classic and Modern) out of the 4 sets of default binds. The other 2 have not been shared, and thus we have no information on them. We might be able to reverse engineer them, meaning press a key or button and record what happens, or use /showbind on every single key, button, and key/button combination... but that's a pain in the neck to do. Very time consuming.

     

    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.

     

    12 hours ago, BlackSpectre said:

    On the other hand... the idea of keybind profiles, especially CUSTOM keybind profiles, has a lot of potential, especially if players could share them with each other right in the Options window (probably through global email).

     

    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.

     

    On 3/20/2024 at 8:07 AM, Digirium said:

    NB I checked KeyProfile, it does not appear to implicitly reset bindings. An UnbindAll can be added by the user to the bind file, if they chose. The cycle of save/modify/load misses that crucial step, it should be save/modify/reset/load. My own process is modify/reset/load.

     

    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.

    • Like 2
    • Thanks 6
    • Microphone 1
  3. 1 hour ago, Andreah said:

    Is Tequila still supported as of this patch? Those of us using it are not getting today's version.

     

    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.

    • Like 1
  4. 25 minutes ago, Hedgefund said:

    I did see something suspicious just now, this is a rare, popular piece.  I find it unlikely (though not impossible) that a successful sale of 56,009 went through.  I could go through the motions of acquiring and selling a bunch of these to see the floor but... I'm not.

     

    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.

    • Like 3
    • Thanks 1
    • Haha 1
  5. On 3/12/2024 at 3:56 PM, Yomo Kimyata said:

    I would love to hear as much as you are willing to tell about this.  I've had plenty of personal theories!

     

    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.

    • Like 4
    • Thanks 2
    • Microphone 1
  6. 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.

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

    • Thanks 2
  8. 33 minutes ago, Shenanigunner said:

    bindsave should essentially never be used any more.

     

    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!

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

    • Like 1
  10. 5 hours ago, golstat2003 said:

    Does the below mean this long standing AH bug is fixed? Cause if so that is awesome!!!!

     

    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.

    • Thanks 1
    • Thumbs Up 2
  11. 36 minutes ago, Techwright said:

    Curious.  The article lists 42,000 players, but then we have Number Six's comment from yesterday that tallies up to over 71,000 computers (or more accurately, operating systems) being used.  Are the majority playing on two computers?

     

    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.

    • Like 2
    • Thanks 1
    • Thumbs Up 1
  12. 2 hours ago, strix_ said:

    RTM was just the name for the final version of Windows 8 that shipped packaged with computers of the time, iirc. It's the release-to-manufacturer version, so it probably just means people are playing the game on PCs they never updated to Windows 8.1/10. vNext means some SysAdmin's been playing Homecoming on their work computer. 🤣

     

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

  13. 11 minutes ago, eqspeef said:

    I'm not amazed that win7 still has some die-hard users, though.

     

    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.

  14. 12 hours ago, GM Crumpet said:

    Cipher did a look-see a while ago and there are actually people playing this on Windows 95 🙂 

     

    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.

     

    15 hours ago, eqspeef said:

    I know it's a 20 year old game, but 20 years ago is about the same time home PCs started going 64-bit, and I have a hard time imagining someone playing COH on a P4 with a CRT monitor when they could get a vastly more capable 10 year old PC for $25 on Ebay.

     

    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.

    • Like 1
    • Thanks 4
  15. 13 minutes ago, AboveTheChemist said:

    This is perhaps the glimmer of hope needed that a fix for the display bug(s) may be somewhere out there on the horizon.

     

    It's a bit more than a display bug, and I suspect I may know what's going on, but it's proving to be difficult to reproduce in a lab environment or even on the beta server because it's something that can only happen when there's a lot of item histories getting recycled at once due to ongoing transactions.

    • Like 4
    • Thanks 3
  16. 5 hours ago, Herotu said:

    Like when you have a badge window open and you mouse over a badge and it grows in size and the name underneath is dark instead of light and you can't read it. people deny that it's a thing, but I know different.

     

    Have you tried that since the update? That was one of the UI bugs fixed in page 7.

    • Like 1
  17. 3 hours ago, Oklahoman said:

    Also, I really need a /windowscale for every single window in the game at this point. I know there is a list of many of the window names, but not all of them.

     

    Pretty sure the list on the wiki is it. If it has a name it's there. Not all windows have names, not all of them can be scaled individually, not all of them are saved and persistent across game sessions, and not all UI elements are even part of a window.

     

    The lack of the ability to scale everything is the entire reason the global UI scale setting was created. Maybe there's a way you can leverage that to hit the windows you can't access, then individually scale the rest of them back down.

    • Like 2
  18. On 3/2/2024 at 8:04 PM, insulinboy said:

    I'm also facing a hard to describe issue, it feels like something is off with the daytime schedule.  Most of my missions are very dark.  I've checked through all the graphic settings and can't seem to find what is causing it but something feels very off about it.  I have a screenshot of what it used to look like but the new screenshot isn't doing the in game feel justice.  It's just like everything feels really DARK compared to previous.  And it's straining my eyes quite a bit.

     

    Can you post them side by side? At 100% gamma there should be no difference between page 6 and 7 as none of the rendering changed at all, at least not after the first post-page 7 patched rolled back the problematic shaders.

     

    As for the setting not affecting the UI, that's one of the downsides of the way it's being done now. Since it was completely broken for maybe 50% of people before and the slider did absolutely nothing at all, it's kind of a tradeoff in order to have a working setting. In time it may be possible to change the way the UI is rendered so that it can be affected as well, but it will take some very careful testing to make sure it doesn't knock anything else in the house of cards over.

  19. 1 hour ago, BlackSpectre said:

    So does this mean that if I bind, say, the W key to "+forward" and then save it to keybinds.txt that if I switch over to the joystick keybind profile I will be unable to move forward using my game controller because that action is already bound to the W key? I suppose, we COULD use a secondary key for the joystick binding, but that would also prevent easily switching to other profiles.

     

    Not quite because the profiles and the bindings describe it in two different ways and it's a bit more complex.

     

    The Classic profile for instance binds w and uparrow both to +forward. That gets mapped into an internal table that manages a primary and secondary binding for the command itself (the +forward part). This mirrors how things appear in the options menu and is what drives that interface, but it's also used to manage the bindings for commands that have a specific name in the profile.

     

    When you bind W to something else, the bind that gets stored in the character is a straight key to command mapping like you're used to seeing. So if you /bind W foo, "W foo" gets saved on the server in the keybinds list. The internal mapping table removes W from +forward, so the +forward command has no primary, and uparrow as its secondary bind.

     

    If you then switch to the Joystick profile, it has two binds for +forward in it: w, and joystick1_up.

    Those get loaded into the internal state table first, as primary and secondary. Then the game loads in your "W foo" binding on top, so it removes w from +forward, leaving just joystick1_up.

     

    If you already had a manual "W +forward" binding then it would just do nothing with that one, because W is already assigned to +forward in the table. So both W and joystick1_up would work in that scenario.

     

    That all sound kind of convoluted, but the end result is that when you change profiles it actually ends up doing what you intuitively want it to do. W will still be bound to what you told it to, and the joystick mapping from the profile works correctly.

    • Thanks 3
  20. 1 hour ago, Shenanigunner said:

    Did we gain some new control over "profiles" that's eluded me, here? Those seem to be wholly internal, Dev-managed constructs to allow that "Classic" setback. For the 73 charter players who will use it.

     

    The characters created in the last 2 weeks would disagree with that assumption.

     

    image.png

     

    And no, the selector is not new. It was always there. Just very few people used it because the options didn't really add much, and possibly also because it was somewhat broken.

     

    Yes, you did gain more control. Now what's the in the saved file represents reality rather than some artificial construct, which gives you more control as well as visibility into what's really going on. That's important when you start running into things like the server-side limit on number of saved key bindings. Previously the common consensus around key bindings was that it mostly works, but behaves oddly at times and nobody really knew why.

     

    1 hour ago, Shenanigunner said:

    To boil that down to one serious question: was the need to have an instant "Classic" revert-setting for this, or really for any of the other UI tweaks that were assigned this nearly meaningless label, so special and essential that breaking a key method of customizing the interface had to get scrapped?

     

    This is hyperbole to the extreme. Nothing is broken. All your existing hand-curated bind files still work absolutely fine and you can load them with no change whatsoever in how it works. As a bonus, you can add the KeyProfile line if you want to select a specific profile when the file is loaded, but it's optional.

     

    If you want to edit the whole list at once, you can still do that too. There's a copy of the Classic keybind list on the wiki. I posted the list from Modern on the forums (exported using that existing dev-build command I mentioned earlier) and I'm sure it will be added to the wiki soon also if it hasn't already. Copy and paste it into notepad and you're good to go. I already said we're going to add a command to export it from in-game in case those defaults ever change, so that small extra step is temporary.

    • Like 1
    • Thanks 2
    • Thumbs Up 2
  21. No, the reason is that the bind list saving was completely broken / unfinished, and that loading that saved file back in had bad effects that aren't immediately obvious but can bite you later.

     

    The way key bindings work in this game is that there's a default profile -- which the user can select -- that provides the base layer. When you customize your keybinds either through the options menu or the /bind command, only the changes you make are saved as part of your character record on the server, then layered on top of the default. So if you change two of the default bindings, your character record on the server only has 2 keybinds, in addition to the reference to which profile you have set.

     

    This is exactly why /unbind doesn't do what you might think and instead resets a key to default, because it's removing that saved key binding which no longer overrides the default. That's why since day one you've always had to bind something to "nop" to actually make it do nothing.

     

    There's some more subtlety to that, for example the SG base editor adds another temporary layer to remap some of the keys to edit commands but be able to change them back later, but that's the basics.

     

    The bind_save command on the other hand, didn't work like that at all. It scanned through every key possible and wrote out the command for that key, mashing all the layers together and saving whatever happened to be the result. You might say, that's great, it shows me what every key does and that's what I want, so give me that!

     

    Sure, but think about what happens when you then load that file back in. /bindload and the automatic equivalent that happens when you create a new character is really stupid, it just reads the contents of that file, slaps a "/bind " at the start of every line, and executes it. Incidentally, that's why with careful use of the $$ token, bind files can and have sometimes been abused to work as longer macros -- for years I've had a "bind" file I load on new characters that issues all sorts of non-keybind commands to set up options and windows and stuff.

     

    You're loading in all those default key bindings and then saving them to your character as if you had defined them as custom binds. That works okay so long as 99% of players use the Default profile and never change it, maybe somebody uses Joystick, but that's about it. Consider this scenario however:

    1. Joey create a new character on a new account with no saved binds, they get the Modern profile by default
    2. They change 1 or 2 key bindings and hit the button to save defaults, which writes out ALL the default keys, in this case the keys from the Modern profile
    3. They create another character, load the bind file, and it creates custom bindings based on every single key
    4. It turns out they actually played COH a lot back in 2009 and really hate all this newfangled crap, so they change the profile to Classic
    5. ... nothing happens? what is wrong with this game? Turns out switching to Classic can't do anything if every single key is already overridden from the file they saved!

    If Joey had never used /bind_save it would have worked fine, but because they did it invisibly broke profile selection with no obvious reason why.

     

    The change to the way the file works is two-fold:

     

    1. Adds a special token to actually save the profile to the file, which it wasn't doing before. This is specifically to make it possible to have your preferred choice of profile as the default for newly created characters without having to change it every time, and to make setting that up as easy as selecting Classic and clicking the "save to default" button that's right next to the dropdown.

     

    2. Makes the contents of the file match what is actually saved on the server in your character. That is so that loading binds accurately recreates that state, instead of doing something completely different that just happens to kind of look the same if you squint. I can't emphasize enough that this is a fix to make the command actually do what it says it does and should have always done from the start.

     

    The only real loss is the ability to easily see the default keybinds. I don't mean to downplay that because it is an inconvenience, but that's something that can be easily addressed without breaking the whole system again. There's already a separate command to print out the current state of all the keys, just like /bind_save_file used to do, but it's locked behind development mode for some weird reason. With only a few minor adjustments that could easily be adapted to be player-usable and/or save to a file -- just don't stick the entire contents of it in your keybinds.txt without being aware that it will break profile selection!

    • Like 1
    • Thanks 3
    • Thumbs Up 2
  22. 7 minutes ago, Chris24601 said:

    Anyway, the better you can describe HOW it is crashing, the more easily the issue can be diagnosed. Don’t presume it’s necessarily a graphical setting issue when there are so many other things that can potentially go wrong.

     

    I'm pretty sure I managed to find the crash reports @funcleb sent in (were 2 of the 3 on a character who name is a pun on a popular singer best known for hits in the 80s?)... but they're kind of all over the place. Each is in a different and seemingly random place in the graphics code, with "impossible" conditions. One was checking texture flags to see if it needs to be alpha sorted, one was calculating clip planes for Z-occlusion.

     

    The third one happened while decompressing model data from the disk files -- revalidating files may be warranted here but that's usually the first advice given out so I have to assume it's probably already been done.

     

    That kind of random behavior sounds like something may be corrupting data in RAM. It could definitely be a bug somewhere in the code and you just happen to be unlucky or really good at hitting a particular trigger, but since it's happening so frequently may also be worth running memtest just to be sure.

    • Like 1
×
×
  • Create New...