Number Six
-
Posts
719 -
Joined
-
Last visited
-
Days Won
15
Content Type
Profiles
Forums
Events
Store
Articles
Patch Notes
Posts posted by Number Six
-
-
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.
-
1
-
3
-
-
14 minutes ago, Stormshout said:
Just logging in right now and noticed another patch downloaded since yesterdays. Any notes on that?
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.
10 minutes ago, Savantir07 said:No way just to revert back to the way it was? Seems like a hassle.
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.
-
3 hours ago, Coyote said:
As I understand, several of the -Res "procs", including the Tanker Bruising effect, aren't direct debuffs from you to the target. Instead, they trigger the target to cast the debuff on itself. This has two corrolaries:
1) Because it's the target casting the same debuff on itself, it will only refresh rather than stack.
2) Because the source of the debuff is the same as the target, the debuff is always at even level... so if you're 48 and trigger Achilles Heel on a level 50 mob, the debuff should be -20% rather than -16%.
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.
-
1
-
1
-
-
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.
-
3
-
-
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.
-
2
-
5
-
1
-
-
Team Teleport has never prompted. Either they get teleported immediately, or if they have disabled group travel powers via Null the Gull, nothing happens.
-
1
-
-
Just now, Apparition said:
Yeah, something in the 08/27 patch lowered my FPS at times as well, but not all the time. Not even most of the time. Just enough to be noticeable. It'll be normal the vast majority of the time... then *WHAM* 5 FPS for several seconds. Then it goes back to normal. It's like being in a Hamidon raid for a few seconds every ten minutes or so.
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.
-
1
-
-
2 hours ago, Amatyr said:
Well, quite. Aid Self will need some love if you can't reduce the interrupt.
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.
-
6
-
-
3 minutes ago, Fedifensor said:
What is the purpose of Interrupt IOs (including Interrupt in Snipe sets) now that we have fast snipe?
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.
-
10 minutes ago, davidcu said:
Interested to see how the change to fast-snipe is going to play out, I made sure to slot +tohit on my empathy buffs for blasters to get that fast-snipe bonus. Guess that will change now!
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.
-
4
-
-
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.
-
3
-
1
-
5
-
-
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.
-
3
-
6
-
-
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.
-
2
-
-
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
-
5
-
3
-
18 hours ago, ineffablebob said:
The bad news is that I have no idea how to get HeroStats working with the other builds, either 32 or 64 bit mode. I don't know what "based on modern development tools" in the patch notes means but whatever it is, it completely changed how the internal client memory structures look. I can't find the combat log messages that HeroStats relies on any more. If any developers want to clue me in, I'm happy to listen, but for now the other builds simply will not work.
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.
-
1 hour ago, The Philotic Knight said:
Hmmm.... wasn't someone, I think it was either Number Six or Cipher, saying that they wanted to just put this type of functionality in-game anyways? Regardless, since this looks like something that's wanted, if it's okay with you Bob, I'd like to take a gander at your source code and the game's code and see what I might be able to do, since my other projects are effectively on hold due to lack of resources...
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)
-
2
-
To help clarify the difference between the now 3 different clients, there are two different branches:
New client: The new client (and server) have undergone a significant amount of modernization work and this is our "future-proof" branch for ongoing development. It's built with a much newer compiler & development tools, has support for modern operating systems, has been reorganized and had a lot of old and useless code removed, has undergone a lot of cleanup to fix problems that made it incompatible with 64-bit architecture, has upgraded third-party libraries, etc. It also integrates some changes to make development easier. For example the memory allocator was replaced with one that allows us to do memory profiling in production mode without a significant performance impact - an invaluable tool for tracking down memory leaks that only show up under real-world load conditions and can't be reproduced on a developer's PC or even the test server.
As a result of shifting so much around, it's also uncovered a lot of bugs that have been present in the client forever, but were rendered harmless or just never noticed by chance. A good example is off-by-one buffer issues that write 1 byte too far, but due to how the old compiler laid out memory never overwrote anything critical. We've fixed a number of these, but there may be more lurking. There are two builds of this client:
-
64-bit: The preferred client going forward. Supports Windows 7 and later. Requires Visual C++ 2015/2017/2019 runtime installed (included by default in Windows 8+, can be installed on 7 and most people should already have it).
- 32-bit: For compatibility with systems that do not have a 64-bit OS installed, or rare cases of other incompatibility. Supports Windows XP and later. Does not require any external runtime.
Both of these builds will get all new features and enhancements; though some features like XInput controller support require newer operating systems to function.
Legacy client: This is the current client being used on the live servers. It's built with the old compiler. The data format changes necessary for the 64-bit client have been backported in order to make it continue to work. It is being provided as a fallback in case people run into compatibility problems on the new branch.
This client will not be getting any new features. As it requires extra work to backport fixes to this branch, it is being provided as a temporary measure to keep people running and will not be maintained indefinitely. The goal is for all systems to be able to run either the 64-bit or 32-bit build of the new client.
If you find that you cannot use at least the new 32-bit client for some reason and must use the legacy client, please let us know! We're working hard to make sure that there is an upgrade path that will work for everyone, so we need to find out about any issues with it and resolve them before the legacy branch is retired.
-
3
-
64-bit: The preferred client going forward. Supports Windows 7 and later. Requires Visual C++ 2015/2017/2019 runtime installed (included by default in Windows 8+, can be installed on 7 and most people should already have it).
-
21 hours ago, Abraxus said:
I was wondering 'twixt myself about the benefits of the 64-bit client down the road. As we know, it gives the client access to hardware resources beyond those restrictions dictated by the 32-bit version. So, I wondered if, perhaps, a 64-bit server client makes it possible to consolidate servers to host more players, with less resources necessary? There is much I don't know about the back-end operations, so it could just be ignorance on my part, and much more would have to be done for this old code to take full advantage of modern hardware. But, follow me here.
The 64-bit client won't impact server load any -- as far as the server is concerned it is no different than the 32-bit client.
The 64-bit mapserver (also being tested on the beta server) has a much bigger possibility of impacting server utilization. The most obvious effect is there should be fewer instances where a long-lived map reaches the danger level (1.8GB private memory usage for 32-bit) and goes into drain mode -- forcing everybody to for example Atlas Park 2.
However, consolidating shards doesn't really make any sense due to how the COH server architecture works. All of the shards in a region share a pool of mapserver hosts, and the map instances on each physical server use shared memory so they only need to load the static assets once. For example, Atlas Park on Torchbearer could be running on the same server as Port Oakes on Excelsior, an Incarnate trial on Indomitable, and a mission that somebody on Everlasting is running.
Shards themselves are fairly lightweight as a result -- the only piece unique to the shard is the dbserver, and that can be virtualized. The only shard that has dedicated mapserver resources is Reunion, because it's in a different datacenter on the other side of the planet. Shards exist because the dbserver, which has always been 64-bit, tends to get unstable around 2,000 concurrent players.
This is the same reason that server merges were never going to happen on live and would not have been a cost savings. There's a ton of downside and support nightmare dealing with name conflicts, and little to no benefit from doing it.
-
3
-
Tequila and CreamSoda Security Issue? Launchers compromised? [Mod Edit: They aren't.]
in General Discussion
Posted
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.