Flomix.3982

They fix some bugs but also introduce others, which is why I'm concerned too about the announcement. My account can't play the game on dx11 at all since like 2 months, i have to use dx9 currently. dx11 crashes on startup still today. And I specifically say account, because a.) Alt accounts and accounts of friends start just fine, just my main account crashes on startup even before the char select screen, and b.) that account crashes on other computers too, exact same behavior. Mine is brand new hardware from 2022 btw. So it can neither be a driver nor a corrupt-game-data nor a too-old-hardware problem. All I can do is pray what will happen in 3 weeks...

No I didn't. And I didn't see that I was logged in on my alt before sending and there is also no deleting of posts, so not much I could do anyway

I think you misunderstood the issue, it's nothing server related and it didn't happen before the char select screen redesign. Please watch the video, it both shows what the problem is and also why it happens.

Mmh but that would also mean that transfering your ascended gear from one char to another would cost you 15 transmutation charges now, I don't know if I would like that better, I like to switch the character "inside" my gear from time to time, without changing the skins. It would make sense for the new shared legies only, but not in general.I could rather imagine something like a "unlock skin" storage for every individual item, where you pay transmutation charges to reskin an item as before, but you can switch back to previously payed skins for that exact item. That way transmutation charges wouldn't become worthless, but the skin problem would still be addressed.

Ofc i know what you mean, but that's the case on everything. I know how much work it is to craft multiple sets, so what? That same argument could be used against making the core game free and then HoT free; those who bought those before also didn't get a refund years later. But crafting 6 or 20+ legy sets just for the added QoL is an absolute premium, and sure, those 0.04% of the players who spent that much gold might say "If I knew before...". But they still got the QoL way earlier than those who would benefit from this addition.I wouldn't have bought HoT multiple times if I knew I would get it for free with PoF. And I wouldn't have bought those fancy expensive skins and dyes that got in the Black Lion Chest rotation 2 days after, so the prices went through the floor. But It still wouldn't even cross my mind to ask for a refund.

I actually don't understand why people complain that they want a refund. It is a cool feature for everybody. I bet the same complaints were done back then when legendary weapons were made Accound bound instead of soulbound, and there were also no refunds for people who bound one legy multiple times before. And still nobody would want the old times back.

If I'm not mistaken there are a lot of endpoints that are cached, so the result might be off by up to 5 minutes or so.It would be really helpful if that could be reflected by header values, so it is transparent if / when / how long data is cached. Example: I access https://api.guildwars2.com/v2/account/raids to get the raid progress. The first call takes a bit longer than subsequent calls, sometimes 5000 vs 100 ms, so I assume the first call has fresh data, subsequent not.I finish a raid encounter.I access /account/raids again, but the just finished encounter is missing.I have to poll /account/raids for up to 5 minutes to see the updated encounter list.What that implies is that whenever I read such data, I have to delay for at least 5 minutes and read the data again, to be sure that the data is current and not cached. Suggestion Add a header value indicating the "age" of the data. I first thought of the "Last-Modified"-Header you recently added to some endpoints. (But maybe a different header would be more useful, see explanation below)In cases where you know the caching timings, add an "Expires" header. If the resource was cached at 12:00:00 and I access it at 12:01:00, the "expires" Header could be 12:05:00, so I would know that polling the resource for the next 4 minutes would be of no value, reducing your server load.That would also mean that caching mechanisms like "If-Modified-Since" would work. A 304 for a large resource like /account/achievements would also reduce server load quite a lot.Last-Modified or other Header?There is a scenario where it would be better to use a separate header than Last-Modified, because both informations (cache date and actual modification date) are needed."This achievement list did not change since 5 days" and "this achievement list is from 2 minutes ago, so fairly up to date but not entirely fresh" are two completely different informations that are both valuable.If I use an endpoint like /account/achievements, which can be quite large and expensive to build / parse, using the If-Modified-Since mechanism can be quite powerful. That means I want to get a 304 as much as possible until the locally cached version did not change. But I still want to know if the resource is fresh or deprecated, for reasons stated above. With 2 different headers I could know how up-to-date the information isknow when I can re-read the resource to get a fresh version to minimize pollingstill use the If-Modified-Since-Header to drastically save up bandwith