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