Agreed. Just turn it off. Peaches

Companion gift prices are incomprehensible. With a large number of alts I had a plan, at one time, to try to raise all my crafting alt companions 50. It was gonna take about a year. Not sure if that will ever happen now. Peaches.

Windows (10) reports that uninstall of Bitraider is blocked by another program. This can probably be bypassed, but will the newer 5.0 stuff run without Bitraider? Peaches

Got it to work, don't use the new clicky drop down invocation, instead press B for "toggle crew skills pane" - that still works. It looks as if the new clicky drop down crew skill function doesn't actually have a symbol in the parentheses. Peaches

Confirm. Crew skills blank, however, the trainers see them, and one of my trainers was kind enough to train rank 10 stuff . No amount of reclogging/restarting fixes this one. All toons show no crew skills. Peaches

in fights. Over time I've grown more and more curious about why it is that at the conclusion of many fights, the first command to "proceed straight ahead from where you are" fails to yield such travel; which you ruefully note as your toon walks off a high bridge("noooo, the OTHER way). As near as I can tell, the reason for this is that not every piece of code utilizing character orientation has access to the same "current player character orientation" data. This failure to use best data also interferes with combat itself in another way. The below example using a Sith Marauder easily demonstrates both issues: 1. Sith Marauder (Player Character) starts fight with two enemy npcs. 2. After fight proceeds for several seconds, an opportunity to use Sweeping Slash appears; two enemy NPCs rush up to frontally attack PC. Enemy NPCs are clearly in the effective cone of damage area for a Sweeping Slash (current graphical orientation). 3. My PC executes the Sweeping Slash command. One NPC is hit, the other is not. 4. Sensing the positioning of the PC is wrong, I venture to point my PC in a different direction. 5. INSTANTLY, the current graphical orientation SNAPS to match the (somehow hidden) true graphical orientation and my PC is facing where it should have been all the time; a totally new direction. 6. The action of pointing the toon in a different direction now begins to take hold. I stop at this point because my PC is not facing the two NPCs, nor is it moving the right way to face them. The updated current graphical orientation forces a re-evaluation of where "straight ahead" is. 7. I now move my PC to face the two NPCs properly, and NOW Sweeping Slash is hitting them both, correctly. 8. Fight goes on for a while; including more battlefield maneuvering and direction changes, and finally both NPCS fall down, go boom. Voila! 9. It is now time to move my PC again.. Noting that my PC is facing the length of the bridge it is standing on, I command it to "move straight ahead" - up arrow. 10. PC begins to move, but not straight ahead. It turns out that the present "current graphical representation" of the toon is once again not the "true graphical orientation." Instantly, the current graphical representation SNAPS to the true graphical representation - which is that my PC is facing the side edge of the bridge. 11. My PC steps off the bridge and dies horribly at the bottom of a crevasse; probably on Hoth =p. 12. I write this information down in hopes that it will help, er, somewhere. This seems simple enough to fix, i.e. have all the code entities which use infos on which way a toon is facing use the same data set. But then, maybe it isn't that simple. Remember, the idea that a fix is simple came from an individual that fell off a bridge. Peaches

Actually I've seen those failures as well, which is why it took so long to post; to get a perfect case that rules those out. The reporting case from today, fortunately, was not LoS or 30 range; Kira is standing right beside me. And she did as others have noted in their case; was spamming a mild (her only?) attack. Peaches

Standard quest, storyline on Ilum - killing Minion of Pain; whatever point of progress that is. Not a flashpoint. Guess I'lll keep gathering info and see if there is any way to narrow it down. Peaches

Like so many things of this nature it took a while to be certain. Healers (recently?) become stuck/wedged in a state of "fighting is ok, but healing is somehow blocked." I caught Kira Carsen today not healing, and not healing so badly that in a tricky fight she began to complain she needed help. I had to heal her. Yes, I am absolutely certain she was not set to "passive", nor stunned, nor subject to any of the myriad other conditions which block healing. Even after the fight while we're both standing there with 20% health, she stood stock still and would not heal. Conversation failed to shake her healing loose. I've seen this several times recently, and each time did a very thorough check on conditions that would prevent healing. Kira's control boxes were all in the "enable" position. Posting now because of certainty - it IS a bug. Once in this state Kira had to be re-summoned before she began healing properly once again. This seems new, but if it isn't it won't be the first time I've been a day late and a dollar short. So ok, anyone else seeing it? Peaches

doesn't use its blaster rifle. It doesn't use a replacement blaster rifle. It never shows any blaster rifle other than the one it is furnished with, whether or not it is actually equipped. It simply shoots, with or without rifle. Now... I know the push to get KoTET out the door is, ah, grabbing all the man-hours, but common guys, would it have been so painful to make even this one tiny product decent? Peaches

Anyone else seeing this; port from just completed heroic to stronghold, fuss with stuff, now port to next heroic... BUT it takes you back to the previous heroic; exact departure spot? Been seeing this more often recently, seems to have started a few weeks ago? Peaches

After a bit of digging I've found out more about the curious linkage between these two weeklies. For some time now I've noticed that trash killed for "Search and Rescue" bonus quest "Blitz Twin Suns" counts toward completion of "Reap the Whirlwind" bonus quest "Body Count." It is not, however, true of the reverse. Killing Twin Suns mobs for "Body Count" adds nothing toward completion of "Blitz Twin Suns." Today's research went further - it turns out that only some of "Blitz Twin Suns" trash also adds into "Body Count." The mobs that work for this are those that are directly guarding prisoners at or around location X418, Y-802. Mobs outside this area, for example those north of the chasm bridge at X418, Y-802, do not manage incremental progress for quest "Body Count." In order for this to happen, both root quests must be opened simultaneously with neither one's main objective completed. Fwiw, the reason for digging into this in the first place was that "Search and Rescue" is also a weekly that doesn't appear on the fleet terminal. This seems to qualify as one of the oddest coding errors ever; certainly a candidate for inclusion in the hall of fame of "oops". Enjoy! Peaches.

As of a week ago Star Fortress bonus missions were/are also still broken, returning 20 credits vice the 12,240 advertised. Apparently these bonus missions were silently nerfed as part of the Heroic mission reward nerf of mid-summer - but were not repaired when Heroic mission rewards were. No idea why Bioware never discusses them, either to mention they were nerfed, or to mention they will or won't be fixed. The lack of working bonus missions tends to keep me out of the Star Fortress weeklies; since they make the difference between time reasonably spent and time wasted... your mileage may vary. Peaches

Curiously, its associated Bonus quest "Body Count" (eliminate twin suns forces x/40) is also available as a Bonus from the Tatooine weekly Heroic "Reap the Whirlwind." In fact, trash kills from either Search and Rescue or Reap the Whirlwind add into Bonus running body count. I wonder if that cross pollination has anything to do with Search and Rescue's absence from the fleet terminal. Peaches

Resurrecting this again, 9/12/16 for another input. The issue is ~still~ there. The variable setting in (on my computer), C:\This PC\Users|Owner|AppData\Local|SWTOR\swtor\settings\YOURLEGACYNAME_Account.ini called (default) Controls_CameraRotationSpeed = 3.09999990463 had to be reduced to 0.57 in order to prevent instantaneous camera excursions that force the screen view into full top down or under floor up, when adjusting camera pitch. ("Pitch" = depress and hold mouse button 2 and then move the mouse in order to change perspective from higher above and behind toon (third person view) to lower, or vice versa.) This seems less an issue of mouse pointer speed and more one camera pitch speed. In any event, the fixed variable works to adjust the insidious "I'm suddenly looking down at the top of my toon's head" problem, as well as others above. Ruletide

If you did the Star Fortress bonus quests, those have never been repaired - 12k credits promised, 20 delivered. Peaches

are still rewarding 20 credits vice the advertised 12,240 - they weren't repaired when the weekly Heroics were. Anyone know if this situation is permanent? Peaches.

Another nerf; Star Fortress bonus mission rewards were cut to 20 credits about the same time the Heroic mission reward cuts were made. Later, when the Heroic mission issue was resolved in favor of restoring rewards; the Star Fortress bonuses were not mentioned. Failure to disclose the Star Fortress bonus reward cut at onset (and the failure to fix it Aug 9th) just leaves the door open to more unfavorable speculation. It is becoming difficult to believe that undisclosed credit system nerfs are anything but some kind of tomfoolery method of dumping bad news - anything to avoid being upfront about it. T&A (transparency and acknowledgement) seem to be fading guys; a potent sign of decay of the business model and of corporate integrity. Peaches

8/1/16 - Happened today to lvl 65 Sniper on Ilum, quest to kill Admiral Shai. Relogging "fixed" it. Peaches.

7/28/16 - Still hosed, but differently from above. Now, you cannot get enough Mercenaries - they are in the dungeon, but to get to the required count you need to kill all wandering Mercs, and all Mercs locked in Kolto suspended animation tanks. The tanks, however, will no longer unlock when the main quest goal of 6 tanks (opened) is achieved - leaving 4 mercs not accessible. So, still no bonus. Peaches

Bit Raider sometimes causes this - go into your task manager and disable BitRaider Distributon Web Client. This has helped some of the Belsavis stuttering for me. Peaches.

Flying fixes everything. Peaches

I must have missed something - the bonus missions inside Star Fortress Flashpoints, such as "Sinister Experiments" in the Nar Shaddaa weekly, are not rewarding the advertised 12,240 credits. I'm receiving 20 credits on all six of them. I've checked this carefully on all them today. As usual, it is written somewhere that this is normal, yes? Peaches

Anyone else seeing what must be new or reworked bonus events in the freshly payout-nerfed Heroics? It appears that Bioware has selectively added or reworked bonus events in some Heroics to ease the payout nerf? One example of this is "Taking the Heat", which prior to June 28 required only that 3 drills be smashed and 3 saboteurs be killed. Today, June 29, there is an added event called "Extreme Prejudice" that adds payout if you kill 7 republic soldiers. I'm pretty certain that was never there before and that they had to actually add soldiers to have 7 to kill. So did Bioware deliberately leave some meat on the bone in the form of new/reworked bonuses in the Heroic weeklies, or am I seeing things... bleh! Peaches

On behalf of the idea that this particular item's (full name "Corellian Museum Crystal") location can be elusive, here's some info I gathered after several hours detective work in Axial Park in Correlia and across several internet game information sources. I doubt at this point that it spawns in different locations but that is STILL a possibility. Indeed, its spawn location appears to have been changed at least once by BW Developers. However, barring all of that, the present state of affairs is influenced by a map bug that causes the crystal's spawn location to be associated with more than one set of spawning coordinates. Example: you arrive at or spawn from login at a location we can call "x, y." However, if you take one step in any direction, sometimes the "y" vector changes to something vastly different, as if on another map or something similar. During the search for all Datacrons I've seen this map bug many times; and what ends up happening is that you need to move your toon around a bit until the map "settles down" and decides what "y" vector it is happy with. Thereafter the map appears well behaved, but using that "y" vector without checking to see if the map is solid can be trying... Today, 6/4/16 I found the crystal initially in an archeological crate (which also contains a dinosaur skull) at map coordinates 690,34 in the tunnel between the Coronet Zoo and Archive Square - all of this in the Axial Park area of Corellia. However, if I took one step in any direction, the map coordinates changed to 690,-2197. I found that this map behavior can be induced repeatedly by relogging. After login the map's player x,y location is solidly broken at 690, 34. Moving one step fixes the "y" vector and the correct location vector of 690,-2197 appears (if you stepped in that direction; variations on the "y" vector are possible because of direction of stepping, etc.). Hope this helps - that map bug is only a nuisance until it gets plugged into internet data sources; whereupon it becomes deadly. Good luck out there! Peaches.