So, what _actually_ causes respecs to fail?

[KeepDistance]

On 3/30/2021 at 4:54 AM, thunderforce said:

I don't think I've asked that the devs do _anything_ (although now I think about it, it does seem like a bit of logging would very rapidly shed light on what the causes are, if it's anything but bad luck).

 

I was curious enough about this to read the source code on Ourodev (not the HC code exactly but probably equivalent in this case). Turns out there is already logging that happens whenever a respec fails, on the mapserver. Some observations about the process as I understand it:

 

1) It's the mapserver that runs the respec, which explains why different zones might have different behaviors. If the mapserver flakes or packets get dropped for other reasons, the validation part of the respec will likely fail, although I don't know the code well enough to say exactly how.

 

2) There's a _lot_ of validation that happens as characters level. I don't know all of what's being checked (what exactly is a "pile boost", I have to wonder...), but it looks at a super high level like the mapserver is protecting against respecs from a hacked client that is attempting to create an invalid character.

 

3) Some of the validation does indeed special case the "character can level" / "character is leveling" situation. So the GM advice about claiming all levels is not entirely unfounded, though it's pretty unclear to me why that code path would randomly fail more frequently than the other code path. Possibly there is some specific combination of powerset, active toggles, and unclaimed levels that is in play, and that it's not actually random but the combination doesn't happen frequently enough to identify.

 

If I were a dev and this somehow got to the top of my list, I'd look at sending a reason code back to the client instead of just logging it on the server. Then the pattern would be more apparent to the player the problem actually affects. Snorkeling through what must be a massive trove of logs might illuminate trends, but there's a lot of context the server doesn't have; the players might make connections more easily since they have all the context on what the character was doing at the time.

[Six-Six]

On 1/23/2021 at 1:51 AM, tidge said:

Is it possible that (aside from the untrained levels) that some of the failures being observed are due to having an unclosed/unresolved UI window?

I rarely have respec fails.

I've done it in SG bases
I've done in RWZ while an MSR was going on outside (I think, I'm pretty sure there was)
I've done it in the middle of the street.
And yes, I've done it with untrained levels

I had one fail the other day (first one in maybe half a year), and I kinda remember having AH window open. So @tidge may be on to something.

[CaptA]

On 1/21/2021 at 7:49 PM, SuperPlyx said:

Altho I am guilty of repeating the "Don't be in SG base" multiple times. I always respec in the base and respec a fair amount. I did a respec this morning to move one slot on my farmer.

I have never had a respec fail.

Now I assume it was a "busy" base or something of the sort. I have a very simple base that only I use. 

 

I ONLY respec in my base. Don't recall ever having an issue. 

[Solarverse]

I have never had a respec work if I had untrained levels. I didn't even think it was possible. I have done this several times when I didn't realize I had untrained levels since relaunch. I guess I am just not one of the lucky ones.

[tidge]

RE: SG bases, failed respecs.

 

My original post about unclosed/unresolved UI windows may not have made these point specifically:

• SG bases can have lots of things to click on that open UI windows (specifically multiple types of storage, but also vendors, tailors, etc.)
• Even if a player "closes" a (storage) window, I don't think that the server has resolved closing the window.

The second bullet point is (in my experience) the cause of "failed catalyzation", because catalysts require a different storage type than (catalyzed) enhancements. I want to say that I saw a similar effect with enhancement boosters, but once I learned to physically move my characters away from whatever device I had been using (storage racks to grab boosters/enhancers, storage racks for enhancement pieces, merit vendors) I simply started doing that automatically and I've never had a failed catalyst/boost since I started doing that. I use the vault so infrequently that I can't say anything about THAT. It feels to me like the vault has behavior rules all of its own distinct from storage racks.

 

Physically moving away from storage/vendor objects closes open UI (as seen by the player), my suspicion is that this (server side closure of a UI window) is the actual 'resolution' of the window instance no matter what the client side is displaying... i.e. just because a player closed a window on their UI it doesn't mean that the server side has done the same thing.

 

The only other area (besides storage racks, possibly vendors) where I have seen potentially similar odd behavior is when physically present at a Wentworth's/Black Market and opening the AH via a click (as opposed to a slash command). Practically speaking: the slash command removes the need to use click interfaces, so there isn't much opportunity to mess around with this... but I want to say that when I've done so I have seen some peculiarities (in both items and count) between what I've tried to put in the Auction House and what actually went into the auction house.

 

[thunderforce]

On 1/6/2022 at 2:33 PM, tidge said:

My original post about unclosed/unresolved UI windows may not have made these point specifically:

• SG bases can have lots of things to click on that open UI windows (specifically multiple types of storage, but also vendors, tailors, etc.)
• Even if a player "closes" a (storage) window, I don't think that the server has resolved closing the window.

 

The latter is certainly true; we have multiple humans in our supergroup, and if A opens a rack then closes the window, B still can't access it - being told A is still interacting - until A moves away from it. Every single time, AFAICT.