At this point I'm getting the 0xc000007b error (despite uninstalling and reinstalling all of the Visual C++ redistributables through 2022 and updating DX9 multiple times), so hopefully updating my NVidia drivers and doing a reinstall of SWTOR might do the trick.

At this point I'm almost certain it's an issue with the launcher, not the game or anyone's OS.

I made a one-time exception to disabling Windows Update to get this working. Says I already have it installed (I must have done it at some point in the past). I've been eyeing an upgrade to Windows 11 for some time, so maybe that will solve my problem when I get around to it. As for requiring an upgrade to Windows 10, that's not actually a concern of mine; SWTOR has always been geared towards reaching the most number of people/the broadest audience possible, and as of this past summer, over 70% of Windows machines run Windows 10, with Windows 7 at a distant 13% and Windows 11 at around 10%. So SWTOR trying to gear itself towards Windows 10 users is fine, but its engine and reliance on DX9 is problematic (DX9 was originally released in 2002 for WIndows ME/XP, and the Hero engine is nearly as old).

It only happens with SWTOR, not with any other games, and that update requires enabling Windows Update (the package downloaded from the Download Center gives me the 0x80070422 error, which is a Windows Update error), which is itself a security risk. I might try it and see if that fixes my specific issue, but I'm not hopeful.

That's...not exactly a solution. This now appears to be an issue with the "new" launcher, not the game or Windows 7 x64. The new launcher has been problematic since it was introduced (e.g. forcing the use of the same loading screen/constantly replacing custom loading screens, increased delays due to the launcher "searching for updates," and so on), and I am relatively certain that the 64-bit update would have worked just fine with the prior iteration of the launcher.

That's not how it works - basically you're updating already-existing DirectX 9 files (if your DX12 is an upgrade from previous versions) or installing them (if your DX12 is the only version on your machine). Programs that are written to utilize the highest-version of DirectX on your machine will still use DX12. SWTOR, on the other hand, is still written to use DX9 (an update to use higher versions of DirectX may be in the works for the distant future) and thus requires DX9 files on your machine to run.

Yes. Just out of curiosity, I ran swtor.exe (from the retailclient folder) and got this error: "The procedure entry point ucrtbase.terminate could not be located in the dynamic link library api-ms-win-crt-runtime-l1-1-0.dll" - which is not a problem that occurs with any other program/game on my machine. I have emailed support with the same information (my OS, when I patched, what happened afterwards, disabled antivirus/firewall, manually installed DirectX runtime, uninstalled and reinstalled with the same problem, uninstalled again and attempted to run the game from the copy I archived after patching this morning) and attached the complete launcher log file.

Nothing happens. I patched this morning, and after patching finished, clicking on the play button didn't start the game as usual (which normally would have taken me to the server select screen showing all servers down as I patched during maintenance). Looking online for solutions, I came across the DirectX 9 issue that corrected the problem for some people; this did not work for me (I updated it, yes). I have disabled both my firewall and my antivirus. I never ran SWTOR in compatibility mode, and I checked again to confirm this. I am running Windows 7 Pro 64-bit. For reference, this is the part of the launcher log file that I think may be relevant (in bold and in red): 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Task.7cd85b04.launch - Not waiting for process to exit 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Task.7cd85b04.launch - Successful 1 ExitCode -1073741511 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Task.7cd85b04.launch - Error - Launch_Error_UnknownCode 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Event launch completed in 0s (0) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - successful=false (Boolean) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - cancelled=false (Boolean) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - errors (List) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.04207174 - =Launch_Error_UnknownCode (String) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - name=launch (String) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - workflow=8ea8790d143c754eb269c12df329c3d4 (String) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - exists=true (Boolean) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - global=true (Boolean) 03/28/2023 14:51:21 CONSOLE - WorkflowManager - Event Complete - {"successful":false,"cancelled":false,"errors":["Launch_Error_UnknownCode"],"name":"launch","workflow":"8ea8790d143c754eb269c12df329c3d4","exists":true,"global":true}

"poorly thought out" I think you misunderstand - you don't need to do lots of damage. I think it's actually either damage (any damage) or objective points (i.e. sitting on a satellite). Obviously in TDMs there are no satellite objective points, so it's easier to get kicked from a TDM match. I do agree with you that the idle timer tends to penalize new/novice pilots more, as they will have a harder time landing hits and therefore getting damage in TDMs. As for "damage farmers," I don't think you understand what you're talking about. All damage in GSF is aimed at a specific objective: to help clear opposition ships/mines/drones/turrets, either in defense (e.g. a satellite or bomber nest) or offensively. Therefore, there's no damage that could be considered "bad damage" or "damage farming." If you do a lot of damage (e.g with AoE ion rail) but aren't successful enough to land the kill, you have hopefully softened up your target(s) for your teammates and will get the assist. If you're referring to pilots who continue to plug away at the same heavily-defended satellite despite never actually taking it or getting a kill, only novice pilots (or veteran pilots who know their team has zero chance of victory) will do this, and in the case of novice pilots, they will do so little damage that it can't really be called "farming." In the case of veteran pilots who queue into a lost match, they can't be blamed for doing this.

That can be corrected by changing instances (e.g. traveling to fleet or your ship) if the queue button is locked. It's happened to me a handful of times (yes, I've also been booted for going AFK during some matches; if you ask me, I think the idle timer is a little too short, and it doesn't solve the problem of SDers or people who do just enough not to get flagged for idling yet make exactly zero contribution to the match), and changing instances fixed the button lockout.

Dunno if anyone's posted about this - I don't fly (or play SWTOR) all that much anymore, but I noticed today that I couldn't link GSF stats on my toons to show a guildie who's just getting into GSF what that looks like. Has this been a thing for a while and I just didn't notice, is this a me-only problem, or is this something new?

It's not just Strongholds that I'm having issues with - I'm also unable to use legacy transport, and unable to accept GSF queue pops. Something is wrong with the game's buttons, it seems.

Don't look at me; I agree with you (and I've been inconvenienced by it as well); from what I understand some players were using legacy gear to transfer cartel market color crystals between toons in order to perform a toon-specific unlock instead of using the cartel coin method in collections to do a legacy-wide unlock, basically generating color crystals out of thin air without incurring the CC cost normally required to do so (i.e. this could be noticed as a deflationary pressure on cartel market color crystals). I agree that the devs' method of dealing this this issue is very crude. I don't know what goes into what must now be the very-convoluted SWTOR CM/collections code, but I can't imagine it would be that difficult to keep track of a variable for each CM color crystal owned by any toon in a player's legacy indicating whether or not that color crystal has been legacy-unlocked by CCs (if not, no toon on that player's legacy would be permitted to put that specific color crystal in a legacy weapon and store it in a legacy cargo hold/mail it - in effect ensuring that every player who exploited the legacy weapon to perform a toon-specific color crystal unlock on each toon would still have to pay CCs to legacy-unlock it for storage/mailing, like the rest of us have done).

Basically this has turned into a money sink for any player who's put in any collections-unlocked (i.e. legitimately unlocked using cartel coins) color crystals in legacy-bound weapons. The only viable/non-exploit workaround to the restriction is to craft your own color crystal (this of course requires that you have an artifice toon that can craft color crystals) and put that into the legacy weapon, overwriting the collections-unlocked color crystal there; buying a crafted color crystal will almost certainly be more expensive than just pulling out the collections-unlocked crystal.

These 3 things are probably my biggest pet peeves about the strongholds in general. And it's not just things that I set to 20 auto-relocating to 19 (at least on the position bar; the true position of the deco is in fact where it's supposed to be, which can be confirmed when changing its position via the X or Y orientation on the position bar as applicable), it's also things set to 15, 10, or 5 appearing to auto-relocate to 14, 9, or 4 (same for X and Y positions set to -20, -15, -10, and -5). Like I said, the true position of the deco is where it's supposed to be, but its position bar doesn't display the true/intended position correctly until the stronghold instance is reloaded. Hook symmetry (rather, the lack thereof) is noticeable, and more glaringly so on Manaan than in any other stronghold. Because this doesn't affect a decoration's true position (but is bothersome to those of us who have even the slightest hint of OCD), I consider this a minor annoyance. The intro video is a really minor annoyance, since [Esc] nips that in the bud and takes you right to where you wanted to be. The Felusia Stato deco limit of 4, however, is still in place (as mentioned in the quote, a holdover from when there were only 4 strongholds available), and now the only general-purpose vendors that don't have such a limit are the 3 deco droid vendors (industrial, synthetic, universal). Still a relatively minor annoyance. Someone else mentioned in an earlier post something about the "pick up decorations in room" feature being bugged. I can confirm that this has occurred in strongholds since at least the Yavin IV stronghold was released; at the time I attributed this to the fact that none of the Yavin IV rooms are actually separated by true doors or elevators, but then I noticed this occurring on other strongholds (e.g. NS and Tatooine) where such separations existed (and therefore the "pick up decorations in room" should only have picked up decorations within a set radius of the player's position, not all of the decorations in the entire stronghold). So yeah, this is a major irritation because it limits what players can do when they want to make minor/room-specific alterations to their decorations in excess of, say, 5-10 decos - they can't pick up the decos in the room because that button will pick up all decos in the entire stronghold, so now they're forced to individually pick up every single decoration in a room that needs to be removed/relocated, which for some stronghold rooms (think the Tatooine hangar bay, or practically any space in the Yavin IV stronghold) is a massively time-consuming process (and one that the "pick up decorations in room" button was supposed to handle).

I first noticed this some time after 4.0, but certain objectives (such as destroying biotoxin containers on the Republic side of CZ-198 or destroying kolto containers on the Empire side of CZ-198) do not result in the appropriate saberstaff stab animation for Serenity Shadows and Hatred Assassins. The animation bug appears discipline-specific; I even abandoned one of my toons' Serenity Shadow discipline, switched to Kinetic Combat, and was able to see the animation work properly. It's a minor annoyance, but it's kind of odd to see your character just stand still (no hand motions or anything) and watch a canister explode.

Some of my simple (i.e. actually used) strategies are map-specific. In the Lost Shipyards TDM, the structure at D2 (I call it the "cage" or "D2 cage") near the upper Republic spawn can be used in multiple ways. The typical (and weak) defensive strategy is to mine/drone the cage itself, and use it as a sort of sheltered base. When this occurs, it is very easy to pin the defending team there by surrounding the cage, taking AoE ion shots at everything in the cage, and picking off stragglers that leave the cage. When spawning from the Republic side, the D2 cage is useful as a sort of sieve. By this I mean a bomber or two can set up some drones/mines as targets within the cage, but no other ships on my team actually go in there but instead set up around the cage or between the cage and the upper Republic spawn. As the most direct route for most opposing pilots to us will be through the D2 cage, basically those going through the cage will be subject to any mines/drones we have in the cage, and those who make it through can get picked off by my team as they do so. Going around the cage generally leaves opposing pilots exposed for an extended period of time, and only the strongest pilots will consistently flank the cage instead of going through it with success. This "sieve" employment can also be used offensively by teams coming from Imperial spawn points if they can capture it, though this sort of use is vulnerable to flanking/attacks from behind when the opposing pilots approach from the other Republic spawns. The key to the "sieve" employment is that the team using the D2 cage doesn't actually go into the cage (with the exception of the occasional bomber in order to replenish mines/drones) but uses it to trap/slow opposing pilots; otherwise the team using the cage runs the risk of being pinned there.

I've discussed this before, though I'm not sure whether or not I did so on the forums here - at some point while GSF was still being developed, the capital ships in TDMs used to fire like they do in DOM (satellite) matches. However, this led to a situation where teams who built up a lead simply hovering over their capital ships to end out a match since no opposing pilots could approach; this is why the capital ships/spawn points in TDMs no longer fire on opposing team pilots. That said, the elimination of cap ship turrets in TDMs made it very easy for dominant teams to spawn camp the capital ships (as they can do with impunity now). I would propose a sort of "deserter/spawn point debuff" like the deserter debuff in ground PvP that would come into effect over the specific map grids in which capital ships are located in TDMs. The debuff would have no other effect than to boot a player from a match if he/she does not leave the spawn area (whether it is an opposition or own spawn point) within a certain amount of time (say, 30 seconds). To prevent ranged spawn camping by gunships, the debuff would apply only to opposition players in grids immediately adjacent to those housing spawn points. Even though this is totally off the original topic, that's my two cents on TDM spawn camping. Regarding cross-faction GSF queueing: I am in favor of this idea. It has been implemented for Odessen Proving Grounds and while my own experiences in that specific map are limited, it seems to me that it works.

Unfortunately I do not (so it's all right it if doesn't make the lists) - and while I don't remember much about the match itself, I figure it must have been at some off-peak time or later in the evening (it looks like it was a pub v. pub based on the character names on both teams), so yes, weird.

Unjustified personal attack aside (and FYI I said 5557 matches, which is not "almost 6000+" but rather "almost 5600" or "almost 6000" if you're going to overgeneralize; I made no specific judgment about your experience of lack thereof), your gripe that "battlescouts shouldn't be a thing and fit no realistic meta ever" is restrictive/inflexible, untrue (if you've ever heard of a "recon in force" you'd understand; and yes, I realize that a recon in force usually means a bolstering by increased numbers/personnel than usual rather than any strengthening of a normal-sized scouting group, but the effect comparison is the same), and basically amounts to you presuming - whether or not that was your intention - to tell the devs and other pilots what they should and shouldn't be doing. I've already discussed in another reply about why your distinction between "battlescouts" and scouts and your contention that one has a valid place in a perceived meta and the other is performing outside of the meta are incorrect, but to reiterate: your definition of scout is largely restricted to reconnaissance, which is a major tactical function of scouts, but by no means is this their sole tactical function ("hit-and-run" is also a major tactical function of scouts that are equipped appropriately). An expectation that all things fit your tactical understanding is unrealistic and irrational. Lastly, I should note that you again missed the point and are complaining about T2 scouts instead of talking about ideas regarding how to make strike fighters more capable in the face of specialized ships like gunships, bombers, and the T2 scout (because at the moment, all else being equal, strike fighters just aren't making the grade against the other classes of ships, and we want to tweak strike fighters to make them at least a little more capable than they are now). Your continued insistence on taking things off-topic is not appreciated.

The idea that T2 scouts (specifically BLCs and clusters/rockets) do "so much more damage" than a strike fighter's weapons (typically HLCs + ions and concussions/protorps) is an inaccuracy of perception. I can't expect everyone to read the tooltips (from which you can figure most of this out), but as I said in a previous reply, BLCs are basically the laser shotguns of GSF. They do a high amount of damage only at the shortest ranges, and drain an incredible amount of power per shot such that most ships can sustain far fewer shots on full energy than with HLCs/quads/ions. BLCs are for most purposes defensive; it's just the T2 scouts that can use them offensively as a result of their speed and maneuverability. At the same sub-3000m ranges the BLCs do more damage per shot than any other laser cannon, but since their energy draw is so high the number of BLC shots you can fire on a full power charge is far less than the number of shots available on other laser cannons. So all told the total damage done by BLCs on a single full power charge is probably similar to that done by HLCs, but since they only need to fire a few shots (i.e. take less time) to do this, their DPS is going to be much higher at their effective range, which would be perceived by newer pilots as "so much more damage." Mathematically this is incorrect; the more accurate statement would be "BLCs do the same or similar damage over fewer shots and less time," which is the same as saying "BLCs have high DPS." T2 scouts do in fact maintain sustained fire in order to destroy their targets, but this also includes a barrage of missiles/rockets in addition to primary weapons. A good pilot can spread out/delay and reduce the damage that a scout would otherwise do (by maneuvering well, strike fighter pilots can also extend the range of an engagement, thereby reducing scout weapon efficacy, and more easily capitalize on any mistakes a scout pilot might make); in such a case, if backup is not forthcoming, the scout pilot will only be able to defeat the strike fighter pilot precisely because the scout outmaneuvered the strike and maintained enough damage/fire discipline to destroy the strike fighter. The reason why many pilots are destroyed very quickly by T2 scouts is because they failed to draw out the engagement, didn't capitalize on the scout's weapon/engine drain, and the T2 scout pilot was able to land many hits in succession (i.e. the target pilot didn't maneuver well/enough), not because the T2 scout does so much more damage than a strike fighter.

Here's the thing - scouts are faster, more maneuverable, and in the case of BLCs, carry the laser equivalent of a shotgun - if they get in close, of course they're going to destroy any ship in a handful of shots or less (assuming the ship is unable to adequately resist) because those are the ranges where the BLCs outperform all other primary lasers. BLCs are actually defensive weapons (cf. BLCs on gunships), but the great speed and maneuverability of T2 scouts enables them to use these defensive weapons (in terms of a meta, BLCs on a scout would be intended to be defensive in nature, just to ward off any interlopers who get in too close) in an offensive capacity, which is a tactical adaptation unique to T2 scouts but also sometimes employed by Condor/Jurgoran pilots. Let me repeat this for emphasis: BLCs are basically the shotguns of laser cannons, and if you've ever played other PvP games like CounterStrike, the way T2 scouts typically defeat their opponents is the equivalent of running up to an opposing player and throwing a HE grenade at them while firing a shotgun to the face). Very effective for shock tactics, but these methods are counterable.

I don't think you actually understood/read my 4-point post (and instead chose to quote its entire length verbatim). Therefore, I'll have to respond to your responses with shorter replies (for the sake of other posters as well). When you say "scouts are meant to check out the area ahead of advancing troops and report back enemy positions" you are basically outlining a subset of roles that I explained in point 4 ("scouts are supposed to be solo operators, advance parties, and movement spearheads") - my definition is more general/flexible and can encompass multiple roles for scout ships (e.g. simple reconnaissance, a recon-in-force, "hit-and-run"), whereas your definition of what tactical role scouts play is more limited and less accurate. The T1 scout (Novadive/Blackbolt) does actually fit your understanding of scouts fairly well, but your limited definition of scouts fails to incorporate the current tactical realities present in GSF maps (for maps that are limited in size relative to tactical range such as the ones in GSF, simple recon is basically replaced entirely by recon-in-force/"hit-and-run" as the main tactical role for scouts). The Wikipedia page on reconnaissance (specifically the sections on discipline and types) is actually fairly useful as a general primer on scout functions.

I have a lot of ideas for tactics/strategies, but most require teamwork and coordination (as well as a modicum of pilot skill and some ship upgrades); as such I haven't been able to try out any of them. The tactics/strategies that I have tried with some success are far simpler. For DOM (sat map) matches I try to get my team to run for all 3 nodes (with one of them as a diversion/delaying tactic, which will depend on which satellite the opposition rushes heavily) at first, then triage and defend/hold two for the match (taking possession of another satellite if need be, such as when the opposing team makes a concerted effort to take one of our satellites). A variant of this is a tactic in which I pose a credible solo threat to an opposing satellite (AoE ion shots plus rapid destruction of satellite turrets via slug railgun with armor penetration), causing the opposing team to dedicate 2 or more pilots to neutralizing me (thus leaving 6 or fewer opposing pilots for the other 7 members of my team to handle). While I call both tactics "baiting," they have different uses and different objectives. In both cases, however, while the original intent is not actually to take the satellite in question (rather the idea is to cause imbalance and induce disadvantages on the opposing team), should the opposing team fail to counter me, they will end up losing the satellite. In TDM matches, I sometimes fly out first as a T2 scout and head all the way to the opposing lines (especially if I can grab a DO while doing it) and cause confusion and mayhem; a kill or two in the process would be nice, but that isn't the point - the idea is to get the opposing team confused and cause them to hunker down where they are (either aiming at/laying mines against me or trying to dogfight me while I fly all over their back line) - with the effect of pinning them at/near their spawn when the rest of my team catches up. I should note that partly due to their simplicity and because I'm not the only one who consciously employs these tactics, these tactics are effective against less experienced teams and not as much against those full of skilled veterans.

This is basically PvE mode for GSF. But I do agree that it would be good for new pilots if they could practice against GSF bots before heading into PvP against veterans. In my mind, GSF PvE mode would be very similar to the Skyhook space battle in the N64/PC game "Shadows of the Empire." In fact, the AI mechanics could be identical, and so long as AI ships continue respawning from a variety of points, the flight AI doesn't have to be terribly complex or even mimic any skilled human pilot (i.e. crashes/self-destructs are okay for AI ships), there would be plenty of target practice (while evading AI fire) for new pilots.