Hey all! We've seen some reports about weirdness on the GTN. In particular, players might see one of the following: Your search results show an item as listed, but with 0 quantity. A search listing may list a lowest price, but when you click to buy the item, the detailed listing doesn't show anything at that price. Your claim may show an auction where all the items have sold, but the listing still claims that it's active. First, don't panic, as much as this may be confusing, all the auction data is safe. What's happened is that some auctions which have already been sold got marked as "active" when we restarted the servers on Tuesday. Because those auctions are considered "active", they show up in searches and when you look at your claims, they also get shown as "active". The really good thing is that although they may look active, as soon as they get touched, either because someone tries to buy the auction or because the owner claims the credits out of it, the server will correctly realize that the auction is complete and will clean everything up. We're doing further investigation and when we know more, we'll be updating this thread.

Thanks everyone for the information on the bug. Particular thanks to klizilii who gave me the most thorough answer to the focus target question Jackie forwarded on our behalf. I also appreciate the videos from Jerba, although unfortunately you didn't have your target or focus target in the videos, so they didn’t provide the information we needed. I wanted to take a minute to respond to a couple of the comments with some additional information so you folks can get a better feel for why this bug is tricky and why I particularly asked about focus target. First a bit of background information - there are many servers that make up the SWTOR backend, and they communicate with each other through a fairly complicated system of messages and replication of data. The simplest of those is that your character data is on the Area Server for whatever world you're in, say Hutta, but there are also copies of that on your computer and partial copies of it on the computers of your group members. Now where things get complicated. We use messages from our group server to let you see information like group member hit points when you’re in a different area or a certain distance away from them. A lot of you have noticed that the bug is particularly happening when there is a long distance between the death and the respawn points, and that is likely related because that's one of the times we switch from "area" information to "group" information. We are unable to reproduce this because this only happens when one of the "area" or "group" updates is slow due to one of those servers being overloaded. This Is almost impossible to simulate in our development environment. I asked about focus target because if your client was stuck trusting out of date "group" information, then setting the not-dead person as your focus target would force the client to get a new copy of "area" information. So if you use focus target and the focus target has hitpoints, that tells me that the version of the data on the server is correct, and it's just the UI communication that's out of sync. So what are we doing now? First, we turned on some more powerful error logging last night (which is a bit laggy, so we don't have it on often) and we're going to see if we see something in those logs that points us in the right direction. Additionally, I've been using the various information in the thread to look through the code to see if I can spot anything wrong. Because SWTOR is a distributed system with messages that can arrive in various orders, code inspection like this is not efficient and often doesn't find the problem, but we're definitely not giving up on it.

Hi everyone! I know the guild ships have been disappearing for a lot of guilds lately, and it seems like it's been around forever. The good news is that things should be much better after the release of 6.1.4. Since this has been around a while, I wanted to take a bit of time to give you all a peek behind the curtain to help explain why it was so hard to track down. I also really want you to understand just how much we appreciate your forum posts and bug reports. Even when we don't reply, as a developer my first stop in investigating a backend issue is always looking at logs, and the more detailed the reports are, the easier it is for me to find something. A bit of background on the Backend Like many games, we store our persistent character data in a database. To make updates faster, we have a cache layer between the game and the database that batches up updates. Then we write the batch to the database. The benefit is we get better performance, but the drawback is that if there is one bad update in the batch, we abort the entire batch. Most of the time, the effect of aborting is that characters get kicked to character select, which isn't great, but is better than the data being corrupted. The good thing is, these errors are pretty rare, and are always the highest priority for us to fix. So why might an update fail? Well, one of the nifty things you can do with a database is define a constraint on your data. That's a rule that can never be broken. Now the database is your last line of defense against something going wrong and your data getting corrupted. For this story, the important constraint is on unique character names. If we try to write a batch of updates, and one of the characters in that update has the same name as someone else in the database, the batch gets aborted. A Victim of our own Success Now, you all might remember some complaints on the forums lately about character renames not working. Behind the scenes, we have a big list of all the names on each server, so that if someone tries to use a name that's taken, the rename gets rejected before it gets anywhere near the database. Well... how does that list of names get built, you might ask. Basically, before we let you guys into the servers after a restart, the servers ask the database for that list of names so that they can make quick decisions later. Here's the part where we have become a victim of our own success. It turns out that the programmer who wrote that database query back in 2009 or so added a parameter for how far back in the past to search for taken names. He happened to put 3000 for the default number of days. Yup, that's a bit over 8 years, and we launched a bit less than 9 years ago. It's a bit off because of some database maintenance we did the first year, but you get the point. So anyone who tried to rename a character with one of the names that was last played 8+ years ago would have the rename look like it succeeds, but then the database says no. Luckily, that was a pretty easy fix, just increase the number. (Although if we start having rename issues in 2093, feel free to yell at me!) OK.. but why would this have anything to do with guild ships?? Well, it turns out that sometimes the data that stores info on your guild ships was part of the batch that was being kicked out because of a bad rename. Yes, I know the guild ship problems have been happening for years, but that's because anytime we were having database errors, sometimes the guild ships were being caught in the crossfire. However, like I mentioned above, we always fixed the database errors super quick, so people would complain about guild ships, but then we couldn't reproduce it and they died down, because we'd already fixed the database error. Here's the good news, this time it's really fixed. We've both fixed the rename error, and thanks to the guilds who have given super timely info, we were able to spot the guild ships getting caught in the crossfire. Now that we know what's going on, we were able to make it so that if the guild ship does get batched up with a bad batch, it will be automatically reloaded. So, no more disappearing flagships even if we have database*errors in the future. For realz this time.* (We hope!)

Thanks for the detailed information, this is exactly what we need! I talked to the platform and web folks, and what's happening is that failed transfers are being interpreted as permanent failures that can't be retried. In the case of character counts, that's invalid, since you should be able to free up slots on the destination server or buy an additional character slot and retry the transfer successfully. With the next code publish we're going to fix that behavior, but in the short term, we're going to start cleaning up failures occasionally so that you can retry the failed transfer. Just be sure to check that there is space available on the destination before you retry, or you'll get stuck again until the next cleanup! : )

Hi guys, Sorry about the troubles today, but we are actively working to get you all into the game and onto the servers you select. First of all, we were having an issue earlier where the website was preventing moves if you had 12 characters on the destination, even if you had purchased character slots. That issue should be completely resolved, so if you have purchased additional character slots, you will be able to transfer characters up to that limit. Next, we did have a problem early yesterday where if a transfer failed for any reason (most were due to having all the character slots full on the destination) the source character was being locked, which also locked the account. When that happened, you would get kicked back to server select each time you tried to log in with a maintenance message. We looked into that yesterday, found a problem, and fixed it. However, it sounds like many of you are still having lockouts. We’ve looked at the server logs for almost all the people who have posted since we put in the fix, and we know this is a different problem from the original one, but we don’t have enough information yet to narrow down the problem. If you are still having issues with logging into Australia servers after a failed transfer, can you give us the following information? 1. Can you try relaunching your client and connecting to the AU server? 2. When you connect to the server, do you get immediately kicked back to shard select? If so, is it the same maintenance error from earlier? 3. Did you try your first transfer early in the transfer process? Is there anyone who is having the lockout problem who didn't try a transfer shortly after they opened? 4. Can you post in a spoiler tag the contents of the most recent client log file (for default installations, it’s located in C:\Program Files (x86)\EA\BioWare\Star Wars - The Old Republic\swtor\retailclient\swtor\logs) Thanks for the help, and we’ll try to get you in and playing as soon as possible!