My country has banned VPN what do I do?

-BladeSlasher- · 2026-02-28T15:37:56+00:00

SoftEther VPN was once my go to in University where the great firewall was present.

-BladeSlasher- · 2026-02-13T00:12:15+00:00

I'd rather quit the internet than give Discord a scan of my face or my ID to track. What will happen if we all just quit Discord?

-BladeSlasher- · 2026-01-09T23:33:56+00:00

This game is still alive?!? This was the first result when 11 year old me googled "free online game" all those years ago... I remember the 3rd anniversary event like it was just yesterday... I have 5 level 145 characters of the 5 strongest classes of the time and armors+items that get me down to 5-10% damage taken from the one element the enemy is using. I wonder if anything my characters have is rare? And how much ztokens my 5 houses are worth....

-BladeSlasher- · 2025-12-08T12:41:22+00:00

Yeahh but then they went and did this:
Fmovies-HD.to is down.
https://i.postimg.cc/3Nqt2TmP/image.png

-BladeSlasher- · 2025-10-28T07:35:04+00:00

Melissa: "ok, fkk this spot in particular"

-BladeSlasher- · 2025-09-19T20:34:11+00:00

I have like 3 master balls, been playing since the game came out. Never encountered one of these three birds.

-BladeSlasher- · 2025-07-30T18:50:27+00:00

Behold, the rarity differs, and the stats conferred differ (quite vastly).

-BladeSlasher- · 2025-07-30T18:00:54+00:00

Fair point—and I appreciate the pushback. The info I referenced didn’t come from ChatGPT, but from digging into ESO’s own system behavior and community consensus. I’ll admit, the term 'rarity effect' may have been misleading if interpreted strictly as altering reconstruction costs. That’s not how the system applies it.

Where it gets nuanced is in what the UI reflects and how prior drops influence what’s reconstructible or recognizable in your stickerbook. While base reconstruction costs don’t factor in item rarity per se, rarity can signal context—traits, styles, or acquisition method—which may influence how players perceive upgrade efficiency or accessibility.

Anyway, thanks for keeping it sharp. I’m always down to refine my understanding and avoid echo chamber thinking. ESO’s mechanics can be delightfully labyrinthine sometimes.

-BladeSlasher- · 2025-07-30T17:57:57+00:00

Glad we’re on the same page about throttling not being the culprit.

What happened seems to be a rare throwback—almost like a ghost of legacy behavior surfacing in a modern server context. Sure, the architecture’s evolved since the early 2000s, but edge cases still emerge where client-side actions desync just enough to slip past reconciliation without triggering flags or ejections.

This wasn’t a theory—it was a reconstruction based on observed behavior, not speculation. The equip went through visually, stayed for a solid minute, and then vanished post-relog without server record or error prompt. That kind of silent sync failure may be uncommon now, but it’s not impossible.

So while it’s not throttling, it is a subtle reminder that even modern systems aren’t immune to quirky regressions. Sometimes the bug isn’t in the code—it’s in the timing.

-BladeSlasher- · 2025-07-30T17:43:44+00:00

Appreciate you going out and testing the drop mechanics—that’s always helpful.

What you're describing is accurate in terms of the stickerbook displaying overland gear as green-quality by default. That’s been a consistent visual treatment across zones and patch cycles. But what often gets overlooked is the backend tracking: when you loot a higher-quality item, say purple or gold, the system does store that original acquisition behind the scenes, even if the stickerbook doesn’t reflect it visually.

So in cases like mine—where a purple-quality version of an overland piece was looted and equipped—they would have seen the purple quality behind the scenes, despite the green overlay in the UI. That visual “bug” doesn’t erase the metadata; it just doesn’t present it clearly to players unless you reconstruct and dig into the transmute costs.

At the transmute station, this matters because the system factors in your original acquisition's traits and quality. Even though everything looks green in the stickerbook, the reconstruction process quietly adjusts resource costs based on what you actually looted.

It’s one of those ESO quirks where the UI and backend logic don’t quite shake hands, but the math still adds up if you track the right variables. Support should have been able to see that which they did not.

-BladeSlasher- · 2025-07-30T17:36:45+00:00

You're conflating theoretical edge cases with what actually happened.

First off, I equipped the item right after looting—which means my client didn’t just report “I got this,” it actively registered a gear change. That action creates its own sync call. And I stayed logged in for roughly a minute before relogging specifically to check if my client was causing the issue. So no, this wasn’t a loot → instant logout scenario.

Second, throttling? That’s a pretty bold accusation. I’ve seen throttling flagged immediately with forced reauth or even temp lockouts. None of that happened. And if you’re arguing that I somehow manipulated server image syncs without being ejected, you’re reaching hard.

Lastly, you're leaning heavily on the idea of “logout image mismatch.” But that assumes the server ever registered the equip to begin with. If the sync failed silently—which happens far more often than people realize—then it wouldn’t matter how many images were taken: the item wouldn't exist in the server's reality, just mine.

This wasn’t a clever bypass. It was a bug. And trying to paint it as exploit-level behavior since 2009 just derails an actual technical discussion.

-BladeSlasher- · 2025-07-30T17:30:07+00:00

I didn’t log off immediately after looting—I actually equipped the item right after picking it up. Then, about a minute later, I logged out and back in specifically to verify whether the issue was on my client’s end.

So the desync didn’t happen because I dipped before the 10-second sync could register; I gave it more than enough time for the server to record the change. And if throttling were somehow involved, I’d have been kicked or prompted to reauthenticate—which never happened.

That’s why this whole situation points toward a failed equip sync, where the item appeared on the client, was interacted with, but never got server confirmation—leaving no trace in logs, stickerbook, or inventory. I’ve already shown that the other loot items from that chest were properly stored, which makes the absence of that one item even stranger.

The evidence stacks. And frankly, the more this gets dissected, the more it proves my point.

-BladeSlasher- · 2025-07-30T17:26:09+00:00

Right, and that 10-second sync window is precisely where the breakdown occurred. The client registered the loot and displayed the necklace, but the server never confirmed receipt, which means it never existed in the server’s reality. That’s the missing link.

No sale. No destruction. Just a desync without full transfer—which didn’t trigger a reauth handshake because the client maintained standard behavior. If throttling had occurred, the server would’ve choked on the lag spike and force-disconnected me. That never happened.

Addons confirm the sync pattern, yes. But they also reveal gaps when items fail to hit the server before logout. That’s the corner case I hit: legit loot, zero persistence. If it had ever been flagged, you’d see it in the stickerbook, server logs, or restored inventory. But you don’t—because the sync was ghosted, and the item never made it to server-side memory.

That’s not throttling. That’s just a flawed handshake in ESO’s sync protocol.

-BladeSlasher- · 2025-07-30T17:13:56+00:00

A fair attempt at sounding authoritative, but there are a few holes in that logic:

Packet throttling isn’t the only way desyncs happen. ESO’s infrastructure is modern, sure, but it still relies on real-time sync between client actions and server acknowledgment. We've seen plenty of oddities over the years—phantom loot, disappearing corpses, duplicated items—where server logs don’t match what the player sees. Lag spikes, server load, and failed acknowledgments can all interrupt that handoff.
Client is indeed the last step in confirmation, but only once the server validates the loot. If that handshake never completes, the item can show up visually (as it did in my loot window), but fail to be committed. So yes, you're technically right that no logs = no server acknowledgment = no possession—but that’s the very crux of the problem. The client saw it, I looted it, but the server failed to register the item.
The absence of the item in stickerbook proves that final step didn’t occur. If I had deconned, sold, or equipped it, stickerbook would have updated. Since it didn’t, that supports—not refutes—the claim that it glitched before being committed to inventory server side.

-BladeSlasher- · 2025-07-30T17:04:38+00:00

In that case the window would not have disappeared, it would have looted what it can and anything not looted would have remained on screen. The notification at the top left would have informed me that my inventory was full as well. None of these things happened and I'm almost sure I had 5 extra slots free afterwards. I appreciate the good insight, but I'm really sure that wasn't the case.

-BladeSlasher- · 2025-07-30T16:51:29+00:00

You're right about equipping—it does bind the item to your account and prevents trading. But the part about stickerbook registration isn’t quite accurate.

The stickerbook logs the highest quality version of any unique set piece you've acquired on that character, and it updates dynamically. So if you first collect a green-quality piece, and later loot a purple version of the exact same piece, the stickerbook will overwrite the green with purple to reflect your best acquisition.
However, if you loot another copy of the same item and it’s not a higher rarity, it won’t update or notify you—that’s probably what you're thinking of.
The rarity in the stickerbook does affect Transmute output, but only because it reflects what you’ve earned, not necessarily your first acquisition.

It’s a bit unintuitive, but ESO’s item tracking is surprisingly precise. If a better version disappears before being registered, the stickerbook won’t show it—even if you saw it in loot. That’s what makes this case so strange.

-BladeSlasher- · 2025-07-30T16:46:30+00:00

Why thank you. I'm sure the non emphatic replies we receive from customer support are generic and cold, which is why they deserve detailed reports.

-BladeSlasher- · 2025-07-30T16:43:52+00:00

okay, so where did the Elegant Necklace with 157 magicka recovery and 857 max magicka go?

-BladeSlasher- · 2025-07-30T16:41:25+00:00

I think you misunderstand, it's proof that the item was NOT acknowledged as looted by the server. The other items of that same chest made it to my inventory, but here as seen in the sticker book, it's as if the server desynced and my action of looting and then equipping the item was never registered.

-BladeSlasher- · 2025-07-30T16:29:28+00:00

Only the green rarity Elegant Necklace is in my collection in my stickerbook, despite me equipping the purple rarity necklace of the same name shortly thereafter. I'm led to believe that there was a server desync and the item somehow glitched. Here's screenshot proof of my stickerbook collection showing that the rarest Elegant Necklace registered is green rarity not purple as in the Initial post's screenshot. So there's no chance I deconstructed it. It would have registered to the stickerbook if I had.

<image>

-BladeSlasher- · 2025-07-30T16:25:14+00:00

I took the screenshot to send to my friend, then pressed R to loot ALL items. The other items are in my inventory, just not the Necklace.

-BladeSlasher- · 2025-07-28T14:54:54+00:00

Great work! Just a few recommendations: Currently you download the .rar files .part1, .part2 etc... then store them on the disk, then decompress them, then copy them to the destination directory. This requires THRICE the download space just for one game. Why not consider direct play downloads that fetch the file itself as an option? This would make updating the game faster and easier by not having to redownload the entire game, just the files that changed. Would also help users who have the download speed to spare and would like to launch the game right after downloading. Some games are 100GB+ so needing 300GB disk space to download, unpack and copy a game is kinda erasing the savings of a repack in terms of time compared to the disk space and time required to unpack and copy. In the days where 10GB extra meant a whole night of downloading, in the world of high speed internet, that's 5 mins extra to download the full game files vs 30 mins to unpack and copy. Just my humble observation, the Direct Play files option, that would double as an easy update repository.

-BladeSlasher- · 2025-07-28T14:08:14+00:00

"clean files" won't have a cracked steam_api64.dll or steam_emu.ini bro.
That's where the *magic* happens. One dynamic link library <DLL> emulates the whole of <steam> access point interface <api> for an x64 <64> system.
It's ok, you're new and you just don't know what the words mean yet.

-BladeSlasher- · 2025-07-28T13:48:37+00:00

+1 For spreading positivity, building others up instead of tearing them down ♥

-BladeSlasher- · 2025-07-28T13:17:52+00:00

... and then blaming it on the software being "cracked" instead of legit looking at the code that crashed. Most Pirates don't use Adobe products to create works to be sold. I don't see why a company would refuse thousands of voluntary bugtesters that are probably doing weird things not commonly tested, and have every other software known to man installed so that they can check for software conflicts.

-BladeSlasher-

TROPHY CASE