Number Six

Not currently, but we have something nearly ready for this that is just waiting on the updated privacy policy that covers crash dump data. So... soon, and not the trademarked variety.

Tequila doesn't need to, and if someone wants to put together a band-aid for that particular issue and submit it as a PR on GitHub, it would likely be accepted. Tequila isn't something we developed, it's just something we happen to be using at the moment. As for whether or not we should redirect any of Homecoming's resources to fixing that particular issue, that's an open question. It's certainly doable and may end up being a quick fix, but given the number of other issues with Tequila and the fact that we'd like to dump it in favor of something more robust anyway, it's a question whether dealing with the logistics of rolling out a new version is worth spending time on.

The draft spec I've been working on for the next-generation manifest does not include the capability to touch files outside of the base directory of the package in question. I believe Island Rum has some legitimate use for that as it also handles installing wine and some other housekeeping necessary for the Mac version. For that it may require creating some extra packages with a more expansive scope to handle it, but we're not to the point of looking at it just yet.

The issue that was brought up isn't really a 'vulnerability' per se, it's simply the nature of automatic downloaders. If you are trusting a program to automatically download updated executables, those executables can do anything they want to your system, including downloading malware. There is an implicit trust in any manifest you add to something like Tequila, and users should be fully aware of just what they're signing up for. tl;dr: if you're worried about somebody putting absolute paths in a manifest file to overwrite files in system32, you should also be worried about what the exes they're downloading and running can do. We have always recommended running the various downloaders as non-privileged users (do not use "run as Administrator"). That mitigates the damage to the OS that can be done, but even non-privileged programs can access data files which are what most people care about. It does not appear that this new patcher addresses the real weakness in all of the updaters available to date -- the possibility of man-in-the-middle attacks or DNS hijacking. That's something that we've been concerned about for some time. Due to that, as well as Tequila being generally lacking in other features that we would like to have, the team's consensus has been to consider it a temporary utility until the new community patcher (Sunrise) was finished. Unfortunately Sunrise development seems to have stalled as far as I can tell. We had some plans for our own updater in the future that we had been holding back on to avoid duplicating effort, but those will likely move up in the priority list.

It was just a reversion of the font rendering library upgrade that had not undergone any QA testing and shouldn't have been part of the original patch. Otherwise identical.

Try /windowscale compass 1 (or a number between 0.75 - 1.25) and /windowscale mapselect 1 I don't think you'll be able to get those two exactly like they were before. Both of those windows did not properly scale their font size to the window and would always show the text at a fixed size regardless of windowscale. That's a bug and was a problem for anyone who needed to scale them up for super high resolutions. Most of the instances of text not scaling with windowscale have been fixed, and those that haven't will be as soon as we find them. Also it looks like mapselect doesn't save its window state to the server, so the scale for it will reset every time you log out (it inherits from whatever you have the "status" window set to).

UI scale is a new option, it didn't exist before. If you change it, it affects chat bubbles and healthbars, etc. If you're talking about the "window scale" option that was there previously, it's hidden if your window scale is set to 100%, so if you had it set to a non-default value it should still be there. It scales some but not all windows. Try /windowscale status 1.25 Then go into the options menu and see if you have a "Window Scale" option (separate from "UI Scale"), which may do what you're expecting if you keep UI Scale at 100%.

Sounds like you have a high DPI monitor and your display scaling in Windows is (either manually or automatically) set higher than 100%. The game respects that now and is fully DPI aware. This change is mainly so people with ultra-high DPI 4k+ monitors can just run the game at native resolution without everything being too tiny to read, and not have to mess with any compatibility settings or get part of the screen cut off. Yes, just turn off "Automatic UI Scale" under the Window tab in the options menu, it's the first one on the list. Then set UI Scale back down to 100%. Or simply type the command /uiscale 1 Either method will set it back to exactly how it was.

Bruising is a direct debuff on the target, and combat modifiers from level differences apply. I believe it may have been the hacky grantpower trick at some point in the past - back before the engine had the more advanced stacking rules like Collective and key-based stacking - but that approach had a number of problems of its own. Bruising still won't stack with the same effect from another player, it will be replaced by the latest application of it. The Achilles' Heel proc is similar. It's a direct debuff, but won't stack from multiple casters. It's a different stacking key than Bruising though, so it will stack with that.

Pet window was already fixed - along with a few other things - but didn't make it in time for this build currently on Justin. Do keep an eye out for things that aren't scaling properly. We fixed a lot, but the UI is a bowl of spaghetti and there are probably still a few things lurking that don't pick it up.

Maybe a dumb question, but do you have it toggled on? Hard to tell for sure since the screen is cropped but I don’t see it in any of your visible power trays.

That's all kind of a red herring, since players falling out of it is another reason that it isn't even useful for niche things like fighting rikti dropships.

One other thing I want to do is to add a thin shell of inverse Repel to the outer edge of the Group Fly effect, applicable to friendlies of course. One of the big issues with it, especially for masterminds and their pets, is stuff falling out of the bubble. That would give it a bit of cushion, so entities about to fall out of the flight field would get a gentle nudge back inside. Low enough magnitude so that a player could push through it to get out if you want.

Let me clear up a few things. There are 3 relevant character attributes in the game engine: Knockback, Knockup, and Repel. These can have a numerical value added to them by power effects (what we tend to refer to as an 'attribmod'). Positive magnitude on these effects do exactly what they say -- the higher the magnitude the further the knock distance (or repel speed). Negative magnitude on them produce no visible effect, but serve to counteract positive magnitude from other effects. This is how Knockback and mez protection function -- by starting you off at a negative number that must be pushed past to get the attribute above 0. So that's why negative repel isn't a thing, because negative repel is actually repel protection. That said, we don't need hacky pseuedopet workarounds. The Issue 25+ engine has a revamped powers system with a bunch of new features that have not yet been utilized by many, if any powers. One of features of the new framework is the ability for any effect (or mod) to take arbitrary extra parameters, which makes it easier to implement variations. There are plans for some point in the future to leverage that to add vectorized knockback and repel. That would take the form of an extra parameter on Knock and Repel effects that powers could use to set the direction of force to apply. The default of course would be along a line from the source to the target -- exactly how KB and Repel currently work. But there are a lot of possible options that could be set including a reversal of that, and various other vectors relative to that one, or to world space. Such a feature would essentially make the Knockup attribute obsolete, as it would be redundant with Knock with a vector of straight up. One other interesting thing this would enable is the possibility of powers that deliver high-magnitude knockdown.

Team Teleport has never prompted. Either they get teleported immediately, or if they have disabled group travel powers via Null the Gull, nothing happens.

5fps sounds like the issue with the PhysX lock being held that is still happening intermittently, though not as much as before the hard sync requirements with the main thread were removed. Try setting your particle physics quality to medium or low and see if that clears it up.

To be honest I’m not convinced Aid Self should be interruptible in the first place. But yeah, my comment about the enhancements isn’t something that would happen if they still served a useful purpose of any kind.

Bling? Though more seriously it does provide some small benefit when using out of combat slow snipes, but was never that especially useful due to the weird way interrupt reduction works. It's something that might eventually go the way of Intangibility IOs.

You still get extra damage for having +tohit, so it probably won't change that much. Though you have the flexibility of going slightly under the cap if you can get more benefit elsewhere rather than having it be so binary.

Yes, it would have been better to do it quickly before it really took off. The timing was really bad because we’ve been focused entirely on getting the 64-bit conversion done, as well as the inevitable bug fixes after go-live that come along with doing something so massive. Generally the policy is that exploit fixes are not pre-announced, even talking about it now in this thread is an exception because of extenuating circumstances.

It’s a bug, and the macros are an exploit, sorry. The passcode mechanic is something that was not available on the retail servers but is new here. The macros are using an internal command that was added to be used by the base portal dialog box and it never should have been usable when the dialog is not displayed. There is at least one permanent teleport to base power available, and maybe a day job version as well. It’s possible that in addition to working while next to a base portal, the command can continue to work while inside a base to facilitate direct travel between bases, but it depends on the implementation details.

The client patch for this will be deployed later today; it didn't go out as part of the server restart. Once the patch notes appear, you'll need to restart Tequila to get the new client update.

Input Fixed ability for the game to distinguish between the right shift and left shift keys Fixed Num Lock and Pause/Break being swapped in key bindings (Windows itself has this backwards for some reason) Added special handling to make bindings with Shift+Number Pad keys work (more fun legacy MS-DOS leftovers) Controllers in rawinput mode will now properly report D-Pad directions Added button debounce for rawinput mode to handle hardware with noisy button switches Reduced analog stick dead zone for XBox controllers in native (XInput) mode Mission Architect Stability enhancements for searches of AE missions; should hopefully prevent the crashes that were happening yesterday Rewards Fixed special enhancement rewards not dropping when exemplared (mostly affected Summer Blockbuster event and DfB) Fixed reward flags that were preventing merits and other rewards from dropping in some circumstances The reward fixes were applied as a hotfix yesterday, but may not have affected all outdoor zones until this morning's restart

It'll be a bit problematic. The information should all still be there, but the new compiler is much more aggressive when it comes to optimization, including eliminating unnecessary variables and re-ordering things for cache locality. So the memory layout may not exactly match what's in the code.

It was me, and it's still on my list, but the 64-bit porting project was a much higher priority and required the majority of our development resources. There are still some lingering issues that need to be fixed, but once those are taken care of this is something I want to look at doing. The most likely form this will take is a listening socket on localhost with a tiny embedded HTTP server and a REST API for pulling stuff like character information in JSON form -- basically the same thing we already do internally for our server status API. We have the pieces in place to put it together so it's not a huge amount of work on our side, and there are a million libraries that add-on authors can leverage to talk to that. Example flowchart: Addon connects to something like http://127.0.0.1:[port]/api/, POSTs some json with stuff like the name and version Player gets in-game prompt that an addon wants to access their character info, can accept or deny Addon gets a token to add to the Authorization header of future requests Addon can query URLs like http://127.0.0.1:[port]/api/character/info to get basic character info, maybe stuff about powers and build, etc Addon can optionally upgrade the connection to a websocket in order to get a real time feed of combat logs, power recharge status, etc. (may require additional consent prompt if it wants chat messages)