Jump to content

Jerba

Members
  • Posts

    4,746
  • Joined

Reputation

46 Excellent

Personal Information

  • Location
    Germany

Recent Profile Visitors

621 profile views
  1. To clarify @JenHarkness, since I fear there is still a misunderstanding: Your post reads like you consider a character dead if they are at 0 HP, but that is not the case! Whether or not a player is dead has nothing to do with HP, in fact: A dead player can be at 10% HP or even full HP if they are being healed after the killing blow. This is caused by race conditions in the effect system, where the heal action is queued up while the player is still alive, and executed after the killing blow. An alive player can be at 0 HP! Let's assume they start with 100/100 HP and receive 100 damage; they are now at 0/100 HP but they are not dead! The game client will still show them alive and they can run around and cast abilities. To reiterate, the minimum amount of hitpoints of an alive player is not 1/100 but 0/100, and they'd have to receive 101 damage to die. Unfortunately, many game systems rely on checking whether the player has 0 HP, instead of checking whether the brain state is set to dead, for example: If an alive player is at 0 HP, then jumps (by pressing spacebar) and lands on the ground, the client will play the faint animation (assuming they died), blocking abilities for a second until the animation to get back up has finished playing. Here, the animation system clearly checks the HP instead of checking the brain state. If a boss uses an AoE to target nearby players, alive players at 0 HP will not be considered, and will not receive cleave damage. The targeting system ignores players at 0 HP, instead of checking the brain state. These edge cases are obviously super rare, but anyone who's been around long enough has experienced them. Please forgive me if I'm wrong but your reply sounds like you are making the same fallacy, thinking that if we're seeing dead players, the hitpoints must be wrongly replicated when in fact, the brain state is wrongly replicated. I don't mean to be rude, I honestly want this bug to be fixed, so I hope I could explain it correctly. Please let me know if anything is still unclear.
  2. Thanks for your detailed reply @JenHarkness; I totally understand why this is so difficult to debug. We were very confused why you asked about the focus target because the hitpoints have always been correctly replicated; only the brain state (dead/lucid/stunned) is out of sync. When I put a "dead" player in my target or focus target, it shows them at full HP but that is no indication it forced a replication of the character; the hitpoints were correctly replicated the whole time. The reason why the player shows zero HP in the ops group frame is because that UI element is coded to hide the HP bar if the player is in the dead brain state. However, the target & focus target frame always show the HP bar, regardless of the brain state. You can see it in this video: https://www.youtube.com/watch?v=bXy_pBqH9KU At 0:11 I hover over the player in the ops frame; note how the tooltip correctly shows them at full HP: At 0:19 I put them in my focus target, and yes it shows them at full HP in the focus target frame but the bug is still present - the player remains in the "dead" brain state. At 0:47 it still shows them dead in the ops frame (despite tooltip, target frame and focus target frame showing them at full HP) and the cursor has the revive icon: Here's another video: https://www.youtube.com/watch?v=m08MMS7VRpo Sadly, the player did not use focus target but you can see at 0:26 that the hitpoints are correctly replicated in ops frame, character frame, target frame and target of target frame; only the HP bar below the nameplate is bugged. (But that might be a different issue and not related to the "dead" player bug; not sure.) I do not think there is more information we can provide but if there is any way we can help further, please let us know! And also, please talk to the designers about adding a workaround, e.g. adding an item to stun oneself, or a command similar to /stuck for either stunning oneself, or killing oneself out of combat. (Obviously, care must be taken to not trigger any effect procs or adding Resolve, so it is not abused in PvP etc.) That way, we can quickly work around this bug without wasting minutes on it every time it occurs.
  3. I'm very glad that you haven't forgotten about this bug. Today, we specifically ran R-4 to discover steps to reproduce. First, to your question: When targeting a "dead" player, they have the correct HP in both the target frame and the focus target frame. Putting the "dead" player in the focus target (aka pressing Alt+F) does not make any difference. In the operations frame, they are still at 0 HP, their nameplate is grey and when using an ability on them, the red error text says the player is dead. From the videos linked below: https://www.youtube.com/watch?v=bXy_pBqH9KU&t=17 Sadly, we still cannot isolate the root cause but we have verified our previous findings: This bug only occurs in phased areas (flashpoints & operations) where the respawn point is far away from the death location. For example: R-4, TFB, S&V, Denova, Dxun. On the other hand, it never (or only very rarely) happens in DF or DP. The bug randomly occurs during the raid night. E.g. today we started R-4 at 8:42pm and the first dead player occurred at 8:55pm, the second at 9:36pm and the third at 10:03pm. If this bug occurs, the player will show up dead for 1-4 other players (in a 8-player group). In other words, if the bug happens, multiple players get it at the same time. It's not like player B gets a bugged player A, then ten minutes later, player C also gets a bugged player A. No, player B and player C will get the bugged player A at the same time. However, they may not notice it immediately, because they were the last to return to medcenter, and only notice it on the subsequent wipe etc. Once the bug occurs, we can 100% reliably reproduce it by having the "dead" player be the last to release to medcenter. And we can 100% prevent it by having the "dead" player be the first to release to medcenter (prevent = so they do not show up as dead; this is only temporary and does not fix it). When you see dead players, the only way to fix it is for you to restart the client. In other words, the "dead" player bug is now inside SWTOR's process memory, and there's no way to get rid of it: Switching to a different area, leaving group, switching to a different character etc. all do not help. For example, you can see a player B dead in an operation, leave group, queue for warzone (with player B appearing on the enemy team), and then that player B will also show up dead inside the warzone and you cannot attack them. Frequently, whenever you see a dead player, on the next area load screen, the loading screen will be stuck at 90%. This is not guaranteed; you can see dead players and not get a stuck loading screen; not sure why. Here are some videos: The bug first occurred at 8:55pm: https://www.youtube.com/watch?v=GQgCnQtquiw After taking the tram, the character Charmaf showed a broken animation on mine (Theho's) and Vêrve's screen (seen at 0:40 in the video). In other words, the character would play the "standing still" animation even though it was moving. After the next wipe, the same character Charmaf showed up as dead on both mine (Theho's), Vêrve's, Boiaki's and Devilex's screen, and the animation was still buggy: https://www.youtube.com/watch?v=VxHUTHl2KdM Here you can see the second video from Charmaf's perspective, as well as afterwards on Mek-Sha (next bullet point): https://www.youtube.com/watch?v=0bTbMaGD_TI Afterwards, we all exited area: https://www.youtube.com/watch?v=bXy_pBqH9KU Note how Charmaf is invisible (aside from the snowball from his Life Day outfit), and whenever I target the player, I see their "Exit area" cast bar appear even though that was from the previous area (inside R-4). My character is stuck in their animation and not moving. After loading into R-4, my character was still stuck: https://www.youtube.com/watch?v=Ud1iSN2ch6Y But as soon as I used my Scamper ability (Scoundrel roll) at 0:03, animations were working again. Then I exited area again but my loading screen was stuck at 90%. Vêrve and Charmaf had a stuck loading screen upon first exiting R-4 to Mek Sha. I'nfinity and Soorah reported the same bug (character stuck in animation) while on Mek-Sha and had a stuck loading screen when loading back into R-4. These videos show workarounds on how to get a dead player to show up alive again: Dying to a trash group, releasing to medcenter, and showing up alive after taking the tram: https://www.youtube.com/watch?v=R84zpsSeAAk Dying to fall damage, then also releasing to medcenter and showing up alive after taking the tram: https://www.youtube.com/watch?v=QrWhmUNm5H0 Dying to an exhaustion zone, then releasing to medcenter (while in range of me) and immediately being alive: https://www.youtube.com/watch?v=S1nijGfdBRg Another video of an invisible character (that also showed up dead after the previous wipe): https://www.youtube.com/watch?v=LzsHpJrvqxI Note how the tooltip of the bugged & dead player is different: https://www.youtube.com/watch?v=TJeNmfTRuPg Houy has the correct tooltip for a dead player out of range: Orange nameplate, and guild tag & Legendary status are missing. But the bugged player, Vêrve, has a gray nameplate and displays the guild tag & Legendary status, as if they were in range, while in fact they are not in range. This screenshot from the bugged player shows how they are at 51% HP, but the HP bar in their nameplate is at 100%: https://i.imgur.com/bHOyN4n.png. And here's a screenshot by Vêrve (who saw Charmaf dead before) inside R-4: https://i.imgur.com/kzURCWW.jpg. Note how it says that the character was down-leveled to 75 but they are standing inside R-4. Only Mek-Sha downlevels to 75; R-4 is at level 80. So it looks like the downleveling from Mek-Sha was not (visually) removed when they entered R-4. Here are our combat logs but I didn't see anything noteworthy: https://parsely.io/parser/view/858489/17/688230463038521 & https://parsely.io/parser/view/858634/2/689220910926598 Based on today's testing, my best guess toward the root cause is: This bug is not triggered by player death. Instead, it is triggered by group members getting in or out of awareness range (~135m). What I mean by that is: Nearby group members have their full information replicated (position, stats, effects), while for players out of range, you only see limited information (low-frequency position updates and hitpoints). I'm thinking that this bug is triggered at the precise moment a player enters or exits this range. At this point, the server must switch from the little information to the detailed information (and vice versa), and apparently there is a low chance for this switchover to fail, after which the group member will be in a bugged state (and show up dead, have a stuck animation etc.). In R-4, this typically manifests by players taking the tram. In TFB, it manifests by players approaching the boss room after taking the taxi. And to repeat what I wrote earlier: If you are unable to reproduce this bug soon, please add any of ^ these ^ workarounds. It's not a fix but it would save every raider an enormous time to have an easier workaround. You're correct; I must have confused the dates. But we have definitely seen the bug on live 7.0 in TFB, on PTS 7.1 in R-4, and on live 7.1 in R-4. And when we encountered it in TFB, it was definitely the same bug as in R-4 and nothing that could be fixed with /follow (that's a different bug, related to players appearing in the wrong position after a teleport, and has nothing to do with this bug).
  4. You gotta be kidding me; players like me spent $100 on this pet and now they're giving it away for almost nothing? They could have at least priced it at 240 CC like all the other pets. Gonna need to put another pet on my quickbar now; the Zonian was my favorite but it's lost its exclusivity now. It's a shame they chose this pet to be the first to be re-released; there are so many more likely candidates that would not upset any players, like the LU-20 Builder & N4-SW Runner which everyone has forgotten about. Or actually unreleased pets, like the D4-V3 Pirate Astromech Droid, Juvenile Marsh Rancor or TR-U4 Astromech Droid.
  5. Yes, you need the exact number, aka do multiple playthroughs, it's always been this way.
  6. What role were you when you attempted the world boss? Healer How many players and companions were with you when you fought the world boss? 1 tank, 1 healer, 4 DPS, no companions. Did you find the world boss appropriately challenging? Yes, at 12 million HP it was easily beatable by our group but I think that is an appropriate difficulty. We certainly do not need more Ossus world bosses; those are way too difficult. Were any of the world boss abilities confusing or unclear? The boss will leap towards a player but sometimes it felt like he casted his frontal AoE in a random direction, aka he leapt to a random spot and did his AoE in a direction no one was standing at. Surely this AoE is meant to be targeted at a player? Might also be related to his leap having a maximum range; not sure. Were you able to successfully defeat the world boss? Yes; we had a few people dying due to Suppressor Missiles lag (see below) but they were able to release to medcenter and return. What did you like and dislike about the world boss? I liked that it had very few mechanics, was easy to kill, so will be a good world boss, especially at times when there are only few players online, so you don't need high skill or long explanations to beat it. I'm not too happy that you can use companions to kill the world boss; similar to Kithrawl, this means it is better for everyone to drop group and summon their companion. Game mechanics should always encourage players to group up! Otherwise, we'll end up in the same situation like on Ruhnuk where players will stop using chat but just wait near the world boss until someone starts attacking. (And also, as a healer I feel totally useless if I don't have an ops frame, and also don't need to heal anyone since everyone has their healing companion out anyway.) Were there any issues or bugs you encountered with the world boss? Only players from the same faction get loot. E.g. if an Imperial and Republic player kill the boss, only the player that first attacked it will get loot. All the other world bosses have it set so the loot is shared across all factions; I assume you just forgot to set the flag here? And as mentioned already by other players, the Suppressor Missiles ability is bugged; it results in an exponential amount of AoEs being placed on the ground, causing a lot of lag.
  7. In addition, this mount cannot be activated while moving, despite having the Improved Mounting legacy unlock. It works fine for all other mounts.
  8. Two things I forgot to mention in my previous post: Sometimes, a player will show up as dead in the group frame but when they take the elevator (entering awareness range), they will become alive. In other words, it is more complicated than I described. To reproduce: Player A releases to medcenter, player B stays dead and does not release. Player A is now alive but still shown as dead in the group frame for player B. As soon as player A uses the elevator, they'll be alive for player B since player B was in the range of the corpse during release. It is possible to get a stuck loading screen even when not seeing any dead players (because you were always last to release). In other words, the bug occurs in the background: Certain players will be bugged and later receive the stuck loading screen. The dead players are just a side effect but not the cause of the bug.
  9. I would like to reaffirm that this bug is still present. We see it every week and waste at least 20 minutes of our raid night working around it. This is not an isolated issue; it affects every raid group that frequently wipes on bosses, and it is incomprehensible how this bug has been in-game for over a year and is being ignored. In the hope of getting it fixed, here is all the information we know about it. This bug was introduced with Game Update 7.0. It was present on 7.0 PTS (during R-4 testing, this was before R-4 Anomaly was pushed back to GU 7.1) and it arrived on the live servers with 7.0. Many players say it started with 7.1 because they only started raiding again during 7.1 (when R-4 Anomaly was released to the live servers) but it started with 7.0. For example, we have seen this bug on PTS 7.0 in R-4, and on live 7.0 in the Terror from Beyond operation. This bug ("seeing dead players") is closely related to another bug ("stuck at 90% in loading screen"); they always appear together. For this bug to happen, the following conditions must be met: 1. The player must be in a group (either a 4-player party or an operation group; this does not matter) and 2. The corpse (death location) must be more than 135 meters away from the respawn point (area start in operations, medcenter in flashpoints). After every wipe, there is a small chance for the bug to occur. In other words, it can occur after the first wipe, or it can occur after 5 wipes. The longer the raid goes on, the higher the chance that this bug happens. At first, it will only affect a single player, then the longer the raid goes on, the more players are affected by it. Typically, this bug affects at most 3-4 players in a 8-player group; in other words, these players will sometimes have dead players in the group, and they'll get the 90% stuck loading screen. Everyone else is not affected; they can play normally. Those players might show up as dead to the bugged players, but on their screen, everything is normal. Note that a player might see other dead players, and they can show up dead for someone else. In other words, there is no dichotomy between bugged players and the dead players. Note that the dead players are the same for all bugged players. They might not show up dead at the same time, but across several wipes, it will always be these 3-4 players that are the dead players; everyone else is always displayed correctly. Also, during different raids, it is always different players getting the bug, so we can rule out any hardware or software issues tied to certain players. Specifically, if player A has the bug, and player B is one of the "dead" players, the bug can be 100% reproduced as follows: Player A must release to the respawn point before player B. On the other hand, if you do it in reverse order (player B releases before player A), the bug is guaranteed to never happen. To understand this, we must consider the release not as an atomic action but as two actions: 1. player is revived, 2. player is teleported to area start. So to reproduce the bug, player A must be out of awareness range of player B while the revive happens (1). My theory is that the root cause is as follows: Ever since 7.0, the game may enter a state where it loses track of certain group members. In other words, on the server side those players are still in the group, and the client UI shows them in the group frame, but somewhere in the internal memory, the game no longer considers them to be a group member. This has an impact on the characters' "brain state" field (lucid, stunned or dead): Usually, this field is replicated if a character is inside the awareness range (< 135 meters) or if they are a group member, it is always replicated, without any distance checks. If my theory is true and the game no longer considers them to be a group member, the character's "lucid" state change is not replicated when they are outside of awareness range, and they'll stay in the "dead" state. This theory would explain why this bug is range-based, why it can be worked around by stunning the player, and possibly also why the "stuck in loading screen at 90%" bug only happens while grouped. Note that this bug is not isolated to operations, it can occur in flashpoints as well. For example, we encountered this bug in the Esseles flashpoint when wiping on Ironfist. This happens very rarely, since you usually don't wipe in flashpoints, and frequently, the medcenter will be inside of awareness range of the boss room. In the case of Ironfist, the medcenter is in a different level and you need to take an elevator to get to the boss, that's why this bug can happen there. When we say "a player shows up as dead", we mean the following: The player has a gray nameplate and they'll show up as 0 HP in the group frame. However, when targeting the player, you can see that they are at full HP in the target frame as well as the tooltip. In addition, you can see that the player is moving around, though their movement may be laggy or the character animation might bug out, since dead players are not supposed to be moving. When attempting to resurrect the player, the server will respond with an error "player is not dead". When trying to use an ability on the player, the client will refuse to activate the ability since the player is dead; the rare exceptions are a Sage's Force Armor, and AoE abilities. Specifically, the bug is that the game client considers this character to be in the "dead" state, while the server considers the character to be in the "lucid" state. Note that if a character shows up dead, this bugged state will persist across areas; they will stay dead even when both characters leave group and exit area, the character will still show up dead in the next area even when ungrouped. We are aware of three workarounds (when a player already shows up dead, aka the healer forgot to be the last to release to area start): 1. The "dead" player must die again and then release to the respawn point (or be resurrected by another player) while the player with the bugged client is in awareness range of the corpse. That way, on the client the state correctly changes from "dead" to actually "dead" to "lucid". For example, the player can enter an exhaustion zone where they die, or they can jump down and die from fall damage. Or they can aggro an enemy and /stuck. 2. The "dead" player must be stunned while in range of the player with the bugged client. That way, on the client, the state changes from "dead" to "stunned" to "lucid". For example, the "Titax Strike" ability in Nature of Progress stuns the player and fixes the bug, as well as the "High Voltage Line" ability in the same boss room. Also, activating the "Recovery Jetpack" by falling down in the Lady Dominique boss room stuns the player. When dueling, any of the class abilities that deliver a hard stun (4s) or a soft stun (8s) will work, while knockbacks or roots do not work. Also, Cybertech Electro-Stun Grenades can be used even by players with a bugged client since those are AoE. Previously, it was possible to duel players in R-4 Anomaly as a quick workaround but ever since dueling was removed in 7.1.1, we now have to resort to workarounds #1 or #3. 3. The player with the bugged client must restart their game, either by Alt+F4ing (causing a disconnect) and restarting, or by cleanly exiting and restarting. Going to character selection or server selection is not enough; they must quit the game. On restarting, each group member's "brain state" will be correctly loaded from the server. However, note that each of these three workarounds is only temporary. On the next wipe, the client can once again enter a bugged state. As mentioned before, the other bug ("loading screen is stuck at 90%") is closely related to the "dead players in group" bug: Whenever a client has entered the bugged state (aka they have been seeing "dead" characters), the next time the player enters a loading screen while inside a group, the loading screen will get stuck at around 90%. The game window does not freeze, it is not at 100% CPU usage, the loading bar just stops moving. It is as if the client enters an invalid state from which it cannot recover, and then stops loading the area. Note the two preconditions: 1) The player must enter an area load screen (exiting to character select does not count), and 2) The player must be inside a group (does not matter if it is a party or an ops group). For example: - A player has a bugged client inside R-4 Anomaly and exits area while grouped → stuck at 90% - A player has a bugged client inside R-4 Anomaly and travels to their stronghold while grouped → stuck at 90% - A player has a bugged client inside R-4 Anomaly, leaves group (starting the 30s timer), then exits area → area load goes through - A player has a bugged client inside R-4 Anomaly, leaves group (starting the 30s timer), then exits area, then accepts a group invite and travels to a different area → stuck at 90% - A player has a bugged client inside R-4 Anomaly and logs out to Character Select → they load into Character Select - A player has a bugged client inside R-4 Anomaly, logs out to Character Select and logs onto a different character → they load into the other character - A player has a bugged client inside R-4 Anomaly, logs out to Character Select and logs onto a different character, then accepts a group invite and travels to a different planet → stuck at 90% In other words: Once the client is in the bugged state, even switching to a different character does not help. Even disbanding the group and joining a different group with different characters does not help; the next loading screen (while grouped) gets stuck. You can't wait it out either; like you could be playing normally for 2 hours after the operation ended, and you would switch areas normally without being in a group, then eventually you group up again and will always get stuck in the next loading screen. The only workaround is to restart the game client. There are two other bugs which occur since 7.0 and might be related. The first bug occurs as follows: A player is inside an operation, then they have a disconnect or they Alt+F4 and restart the game. They are able to login within 1-2 minutes, so they should load into the operation, right where they left off. Instead, they will spawn outside of the operation (e.g. for R-4 Anomaly, they'll load into Mek Sha in front of the operations entrance). However, to their group members, they show up as being inside the operation (when moving the mouse over the group frame, the tooltip will say they are inside R-4 Anomaly). Once they enter the operation, everything appears to be normal. However, exactly 20 minutes after they logged in again, the player is automatically brought to character selection due to inactivity. In other words, even though they've been actively playing, the inactivity timer is erroneously started and never reset. This bug happens very rarely, e.g. once a month, but often enough that we can easily identify when it happens (= spawning outside of the operation after a client restart and group members see them as being inside the operation). The second bug occurs as follows: A group leader invites another player into an operation group. In chat, they see the message "You have invited ... to join your ops group." but even though they accept the invite, the group leader sees no chat message "... joined the ops group." and they don't see the player in the operations frame; the slot shows up empty. The other players in the group can see the newly joined player. As a workaround, one of the other players has to move the "invisible" player to a different slot in the ops group, then they'll show up to the group leader as well. We have seen this specific bug a single time before 7.0 (sometime during 3.x/4.x), but ever since 7.0, it appears regularly. It is rarer than the first bug but also frequently enough to identify it. It would be great if these two bugs can also be fixed, or maybe they are caused by the original bug and will automatically disappear when the original bug is fixed. However, they are not nearly as annoying as the original bug. I hope that with this additional information, you will be able to identify and fix the bug. As mentioned above, it is very frustrating, it costs us a lot of time in every single raid, and not just our group but every raid group during progress (aka during frequent wipes). If you are unable to identify the bug, I ask that you make it easier to work around the bug, e.g.: Allow players to once again duel inside of R-4 Anomaly (and inside other operations), so we can stun other players. or In every boss room, add a mechanic for players to easily stun or kill themselves without aggroing the boss. Specifically in R-4 Anomaly, make it possible to use the elevator to return to area start (where there's an exhaustion zone to easily kill oneself), or add an exhaustion zone in all taxi tubes. or Create a new item with the following "On Use" ability: Stuns yourself for 1 second. Does not create resolve. Cannot be used in warzones/arenas. Cannot be used during combat. Has a 30 second cooldown. Alternatively, create a chat command similar to /stuck that activates the same ability, or at least causes the server to send the correct "brain state" for all group members. Any of these three workarounds would be a huge relief. Please add one of these workarounds ASAP. We really enjoy the game, specifically operations, but this bug is killing our motivation to progress on bosses. Note that this bug was included as part of the 7.1 Known Issues (even though it first appeared in 7.0, not in 7.1), but you forgot to carry it over to the 7.1.1, 7.2 and 7.2.1 Known Issues. Adding this bug to the current known issues would be a great sign that you are aware of this bug. Here are some more threads about this bug: R-4 Boss: IP-CPT Feedback Thread (March 2022) Other players staying dead in the ops frame after rezzing (May 2022) Players Show as Dead in Ops Frames [Not Fixed on PTS] (June 2022) Endless loading and dead player in operation group (August 2022) R-4 Anomaly Bug Collection (September 2022) Dead Players in Operation Frames R4 Vet Mode (October 2022) Dead Bug and Infinite Load Screens (December 2022) any chances to fix game breaking stuff? (January 2023) Infinite loading screen and Dead people in raid (January 2023)
  10. Same, I did not receive the Opal Vulptilla from the Alderaan WZ testing even though I played a warzone on the PTS on February 9, which was inside the testing window. Similar to Twelfthdoctor, CS told me they have no way to verify this.
  11. I've noticed one bug: In the bottom-left of the map window, the thumbnail is black instead of showing the map: https://i.imgur.com/ie1JFdY.png So far, I'm not noticing much of performance improvements; worse, loading into areas takes much longer now, e.g. for Corellia I had to wait 1m50s (stuck at 40% for most of it); on the second attempt it only took 17 seconds. I assume that's because there's not many players online, so it takes a while for a new area server to spin up on AWS. I do hope that on the live servers, there'll be some hot spares so we don't have to wait that long.
  12. Taxi and Quick Travel still show the world map in a window but now that the background is missing, the window is harder to recognize: https://i.imgur.com/C18XP7B.png Can you please add either the previous fuzzy background, or some dark blue gradient like on the character sheet? In addition, I found a bug: When pressing M while the taxi or Quick Travel window is open, the map switches from the world map to the current area's map. I believe this bug already exists on live but now that the map is being reworked, maybe this can be fixed? https://i.imgur.com/hsoEy3z.png Also, I feel that if the map type is set to rotation, the map should only rotate if the character is moving at the same time. For example, during combat or when clicking on objects, the character will automatically face the target. Right now, this automatically rotates the map which is very confusing because the player did not intentionally rotate the character. Finally, it looks like you removed the tooltip with the character's current position from the map. This was the only place where you could see the X, Y and Z coordinates; the map pane only shows the X and Y coordinates. Can you please restore this tooltip, or alternatively add the Z coordinate to the map pane? When hunting for rare objects, knowing the Z coordinate is important so you know you are on the wrong level. (In fact, there's still a preference "Reverse Y and Z coordinates on coordinate displays" which refers to this tooltip) One more thing, I feel like there should be a preference to always open the map pane as the world map. That way, I can see the area map on the map overlay, and if I need the full map, I can open the map pane to see the world map. Right now, there's a preference "Exterior Map Defaults to World Map" but it also affects the map overlay. And unfortunately, it looks like map overlay and map pane are synced: If I switch the map pane to world map, the overlay also switches to world map, even though I want the overlay to stay at area map.
  13. First impressions: Group Finder should be called Activity Finder. Existing interfaces start out with empty utility bars. Can custom interfaces (that have not yet set an utility bar) please start out with the default utility bars, so that players do not have to redo this on launch day for all interfaces?
  14. If a player receives a battle rez but does not accept it and instead returns to area start, they keep their battle rez lockout. This means that in the next attempt, if that player dies, healers cannot rez them because they get a "Already being revived." error message. Please ensure that if a player does not accept a battle rez, the lockout expires on revive.
  15. I can confirm that the reputation track is not visible but Ki'at Thavo is working fine, it is selling the new S3 items (Voracious Rodir).
×
×
  • Create New...