Number Six

Run it with the -noselfupdate flag. That will suppress even checking if launcher updates are available, much less installing them.

@TemporalVileTerror It looks like you have an old hcinstall.exe in your game folders somewhere and are running from that rather than the main launcher.exe in bin/win(32|64)/ As a result you’re running quite old code that’s missing some functions needed by the UI. Delete any copies of hcinstall.exe you can find and run the launcher out of the bin/ subdirectory instead.

Maybe try adding -compatiblecursors to the extra options in whatever launcher you're using?

What OS? That was reported by someone else as well, but after a wine update on Linux. Can you PM me a copy of your launcher.log file?

There have been a couple of small updates over the last few days but there is not currently a patch notes thread. 3/4 Code build 3792: Tweaks to the way version numbering is handled to support some changes in the automated build/deploy infrastructure for the game. There were some edge cases where building things in the "wrong" order could cause a publish not to be detected as new, with these changes that will no longer happen. 3/4 Data package 3797: Re-introduce THIRDPARTYSOFTWAREREADME.txt which got inadvertently lost in the switch to the new launcher. 3/7 Code build 3827: When the launcher self updates, no longer immediately trigger a reload (for data changes) or restart (for code changes). The reload caused disruptive and sometimes confusing behavior where the launcher started, suddenly disappeared, then came back. Instead, defer the reload until the user either exits the launcher, launches the game, or is idle for 1 hour without launching anything. 3/7 Data package 3828: Updates to the UI scripts to support the reload-on-launch behavior in the last code update. The code build is displayed in the settings page of the launcher. I don't think the data package version shows up anywhere.

@Sovera I deleted the attachments you posted. We have a copy of those anyway since they look to have been submitted through the crash reporter, and those memory dumps may contain account info that you really don't want to be posting on a public forum where anybody can download them. I see a number of crash reports in the system submitted by you lately. They're from different and seemingly random places in the code that don't make a lot of sense if things are working normally, and looking at a couple of memory dumps points toward heap (memory) corruption of some kind. I'm focusing on one in particular right now because it's a code path that I've seen several crashes submitted by different people encountering - it's in the code that draws the window borders. It seems that in that particular crash the hash table that tracks your option settings is being corrupted. I see in the last dump you uploaded, the first part of the options table has been overwritten by part of a chat message. A couple of your other crashes are also related to chat message processing - specifically the parser that handles the pseudo-HTML sequences the game uses for formatting. Based on that my current working assumption is that there's a buffer size calculation problem somewhere in the chat message parsing and it's causing chat to overwrite whatever happens to be in memory next to the buffer. So your first hunch wasn't far off and RP is actually corrupting the game...

A few additional bits: There are some references in the translation files to a place called “The Fringe”. It was apparently scrapped early on so there isn’t much there aside from contact introduction text, but it appears to have been meant to be a higher-level hazard zone where the Praetorian military directly engaged the Devouring Earth to keep it at bay. Similarly, some other unused text strongly indicates that the Rift Enclosure was originally going to be a physical place accessible outside the going-to-primal-Earth mission. It looks like it was planned to be a high security complex made up of multiple buildings and serve as a mission hub for Praetorians, a la Portal Corps. There’s even text and badge art for an unused day job and accolade associated with it.

Honestly kinda surprised that apparently nobody has dug up the previs model that goes with that map yet.

Swan did get an update at some point. Take a look at the picture of Swan from the wiki, taken before shutdown. And from just now in Brickstown: Not sure exactly when it happened it but was sometime between Issue 24 and 25.

A number may have still been running the old build as well, since the manifest for tequila, etc., wasn't updated yet, so depending on which launcher they were running may not have had the possible fix. It has been updated just now. More people should get the newer version over the course of the next day or so, at least once they log out and let their updater run. Haven't gotten any crash reports that look hami-related from the new build yet - however - that may be misleading as it was a stack overflow that the crash handler couldn't reliably trap and it was really hard to get dumps from in the first place.

Stability Replaced an internal function related to sorting models for rendering that may be responsible for the hami bud crash.

This is a very difficult question to answer not because it doesn't have an answer but because it's such a huge question. We could write pages and pages on the topic and still feel like it's not a fully satisfying answer. As Naomi mentioned, we're also not a hive mind (FAR from it) and different people have different priorities even if that doesn't always show in the final product. For myself, personally, the core philosophy is "try to continue the game in the spirit of the original Cryptic & Paragon developers as best as we can". I recognize that's a highly subjective statement and doesn't mean the same thing to everyone. So I'd break it down into a few key areas. Game balance wise, trying to keep the game relatively well balanced. That means no "I win" buttons, no AT or power combinations that eclipse everything else. That doesn't mean that there can't be variances so long as they're not extreme - it's not possible or desired for everything to be equal - but well designed characters should still be rewarded by feeling powerful. It means that the meta-game should be interesting and there should be build choices to make with tradeoffs for making them, and that there shouldn't be one answer that's always right. There are also traditions to be maintained, so while things like MOAR RECHARGE almost always being better would seem to violate that philosophy, it's also extremely unlikely that I'd endorse any attempt to change it. A high priority for me at least is to make sure that nobody logs in one day and is dismayed to find their character plays completely differently (principle of least astonishment). That means small incremental changes rather than sweeping remakes of entire systems, and preferring to add new things rather than fix something that isn't broken. When things are broken or systems do need sweeping changes, try to keep them familiar, intuitive, and true to the subjective 'feel' of the game. When we have internal discussions, I often like to play devil's advocate and demand a good reason for doing just about anything. I'm an old school wow player and I always dreaded expansion packs when the talent trees would be remade from scratch and sometimes entire game mechanics and character stats would be changed or removed. While this is a goal, the game does have to move forward and cannot stay frozen forever. The desire is to provide this for the vast majority - I'm painfully aware of cases already when some people feel that what I consider relatively minor changes completely ruin a character - but we sadly can't please everyone all the time. On the technical side, I place a high priority on making sure that the game continues to run on machines that people have been playing it with for years -- that's why we take steps to try to keep it running on old clunkers even though MS has long dropped support for their operating systems. Backwards compatibility is a Big Things for me and I always try to push for maximizing it. At the same time, I want a cleaner, future-proof framework and have been the driving force behind a lot of the modernization project: the 64-bit port, upgrade to using more modern tools (there's a sweet spot where XP cross builds are still possible), refactoring into new cross-platform libraries, and reorganizing the source tree to make it easier to navigate. Those 3 big points - told from the perspective of someone who works mainly on engine code and backend server stuff - probably don't even scratch the surface of what you're asking. What about new powerset design, priorities for costume parts, story content, animation and mission maps? There's a ton of stuff I'd love to write a novel on but it still wouldn't feel finished, and there are other complicating factors as well that will sort themselves out in time. So for now I'm going to just keep doing what I'm doing and hunt for bugs to be fixed, create new toys to give to powers designers (hint: keep an eye on Singularity), and slowly clean up the code base while the content team gets to do the fun stuff.

Nothing compared to how insane it would be to try to implement something like that using pseudopets. 😄 The chain expressions may look complicated but are doing a lot of heavy lifting that used to be impossible.

OVH is reporting a network backbone outage in Dallas that is very likely the cause of this.

Build 27.1.3738 NOTE: This patch is currently only in testing through the Homecoming launcher. The prerelease/staging manifest for Tequila & others has not been updated. Stability Possible fix for crashing when hami buds spawn in raid conditions. This involves a changes to a low-level sorting algorithm that is heavily used by the graphics engine and needs testing to make sure it doesn't break anything else.

The Cryptic devs had a rule that attribmods should never be removed from a power, so in cases where an effect was removed and there was nothing to put in its place, things were often changed to kNull or a 0% chance. While I don't have complete information from anyone with firsthand knowledge, I can speculate with some degree of certainty as to the genesis of that rule. There are a number of places in the code that directly use an index to the power's attribmod array as a shortcut. Even in the modern framework with nested effect groups, the engine creates a synthetic flattened list of attribmods for compatibility with that code. It's used for a number of things such as the network protocol for sending buff icons, but the one relevant to this rule is that references to that index are persisted in the database for long-duration buffs/debuffs that last across play sessions. That means that if order of the mods in that list changes between versions, when the server is started up, as players load in they can end up getting attribmods attached based on indexes from stale data. In the most benign case, later mods in the same power are shifted up the array, and the index ends up pointing at the wrong mod. That would manifest as an unexpected effect, with the magnitude and duration from before the character logged off, but the type of the effect switched to whatever is now in that slot. A much worse version happens when the list is shortened and the index now points off the end of the array. That's almost certain to cause a mapserver crash. Strictly speaking, I don't think that rule is needed anymore. We ran into those issues a couple of times since HC went live, because power developers were not aware of the rule and removed effects from the middle of the list. The details are a little fuzzy, but I remember one instance where a fairly common inherent power had saved mods that changed types across releases and caused weird issues. Later there was a case of a small number of unlucky characters (I want to say one VEAT in particular) that would cause a map crash when they tried to log in after a patch. As a result of those issues, we added code to the dbserver to clear saved attribmods on server startup. That means that long-running buffs still last when you log out for a while, but they don't persist across server restarts. That makes the rule obsolete and those can be removed.

The seeded price needs to be changed. The person who was going to do it yesterday ended up not having time to get to it, so it will likely be fixed this evening.

It is with great sadness that I must report the passing of @Justaris. Those are words I never expected to have to write, and I've written this post in my head a dozen times over the last week but it never seemed adequate. It still doesn't quite seem real. Joel was a long-time COH player, starting from beta. Those who played on Triumph may know him as Tetujin -- his badging character. He ran often with Triumph Watch and was always happy to bring along some rad/rad defender goodness when people needed more. He was also involved with the Justice Knights supergroup on Justice and some may know him from there. Others may remember him from the forums, where he was always an active participant and loved to help people with builds for their characters. What I'll always remember is the many static teams he ran with a small group of us. From the early days of Team Go & Team USA to steamrollers like Omega and theme groups - some of his personal favorites - like Graves' Posse and the Tin Mage Corps. We had started to resume the tradition on Indomitable and it's very sad that he won't get to lead the mad scientist villain team we had been planning to play next. The thing that comes to mind though is how he was always going out of his way to help others. It was something of a recurring joke in our group - Tet would stop moving for some time (especially noticeable when he was tanking) - and somebody would make a snarky comment. Inevitably, a few seconds later, we'd all see in our chat windows the long reply he had been typing in the Help channel. Often he was helping a new player with some not-very-obvious aspect of the game. Reflecting on it, it shouldn't come as a surprise given his chosen profession. A doctor who served in the military and spent years in Afghanistan - of course he would be the type to always help out when he could. There is much more to his remarkable life outside of the game - his sister wrote a post on his Facebook page with more details. There will be an in-game memorial held on Saturday, December 12, in Ouroboros on Torchbearer. A number of us who knew him are planning to gather at the traditional Weekend Knights start time of 22:00 GMT (2PM Pacific, 4PM Central, 5PM Eastern). The memorial will remain up for a while afterward for anyone who wants to stop by and pay respects. We will miss you.

Error code 18 means a partial file was received. It probably means some sort of Internet connectivity problem. Looking at the log file, there are a number of downloads that all seem to time out right around 4 minutes and 15-25 seconds after the download starts. That smells like a problem with some sort of firewall or transparent proxy that is interrupting the transfer after a certain amount of time. I'd start with rebooting your router.

Those powers were all already there and had been there for a very long time. The only new power added was the summonable base portal. The thought process is to try to not remove or fundamentally alter powers that have been around since the Paragon/Cryptic days unless there are very compelling reasons. Even streamlining the Pocket D VIP pass into LRT generated quite a bit of controversy. /ebfp was a post-shutdown addition that never should have been implemented that way. You can't compare it directly with the travel methods that existed for most of the life of the game and are now suddenly relevant again.

Back when I posted that, I wanted to make it clear that the behavior of enterbasefrompasscode was not intended, and using it for fast travel was technically an exploit. It wasn't (as far as we knew) a game-breaking one, so it wasn't a high priority to fix, especially because fixing it properly would be a non-trivial task. However, it needed to be said because metagame commands like that are too sandboxy and not consistent with the game design philosophy of the team, so it was destined to be removed eventually. The intent was to come up with some general travel improvements to soften the blow - probably something relating to the clunky base teleporter power - and fix the command then. In the back of my mind was the Long Range Teleport exploit, a related one that was also not considered serious because while it enabled travel to places you normally can't go, it was fairly harmless and had barriers to using it that made it annoying. It wasn't until I finally set out to fix both of those that other, related problems were found. More than one - quite a few actually. Only then did we realize the true scope and severity of what you could do with it. A new subsystem was created to solve the underlying problem rather than putting more band-aids on it like the original developers had done, and that system was hooked up to all of the affected parts of the game: enterbasefrompasscode, the back-end of Long Range Teleport, and at least half a dozen other places. There's been a lot of confusion about the issue, partly because of our policy about discussing potentially severe exploits, partly because people want a simple and clear target to place the blame on: pvp, devs hate players, game breaking exploit, and so on. The reality is much more complex and nuanced than that. It's a combination of many factors, including a conscious game design decision, the rework of the Teleportation pool that was started independently from the EBFP fix but crosses paths with it, and changes of the underlying systems that the command uses in order to solve other issues.

We'll say some more about it at that point, but aren't going to go into a ton of detail because it's a bug that has existed since the retail days and there are other servers out there that haven't patched it. I know it has been talked about a few places so the information is out there, but we don't want to amplify it unnecessarily.

This is something I've kicked around a bit internally, but with a twist. The idea is to make to-hit chances above 95% possible, but not easy. It wouldn't simply be a matter of just getting 5% more tohit, but applying some sort of severe diminishing returns curve for every point past 95% you push it. Ideally it would be tuned so that if you're a level 50 in Atlas smacking hellions around, you get either 100% tohit or close to it. But if you're fighting a +4 AV, it would be nearly impossible to get close to 100 unless you have massive buffs. In between, could be something you could choose to build for -- maybe put all of those purple +Acc bonuses to use somehow. It's not a very well fleshed out idea at this point, just something that I threw out there and got some commentary on.

Please, the city has a budget to worry about. It was just a cheap facade stuck to the globe for decoration.

This one is done.