Regarding new dupes

Well, obviously it is tragic…

Now it entirely depends on AGS. How will they respond?

I think they should remove every duped item, and the gold paid for them (if trackable).
Or, r-r-r-roll back! I rather lose some of my progress than have a fudged economy for the long term.

Please just do not let the economy go on untouched on the fresh start servers.

3 Likes

They willl say all the exploited items were removed successfully just like they always have but in reality they haven’t :laughing:.

7 Likes

They disabled trade ~18h after first reports of the dupe, and they didnt roll back, so that is not going to happen.

Thats not possible becuase that are stackable item without item ids, they cant track it.

I think we need to get more information. Like when did they identify this exploit? etc etc…

IDK about not possible… can you not be tracking quantity from its source at generation?

Nope, that would require huge logging of everything that would cause massive performance issues.

I mean, do we know for sure AGS does not log this data?

Because if I were AGS, i’d be logging everything I possibly could. And would create systems that would allow for that. It is certainly possible imo.

so many experts here. :rofl:

1 Like

Logging absolutely everything on a database costs a significant amount of processing power.

That is not what I am debating. Yes, it is resource intensive, but if you are a studio investing in an MMO, looking to make it long-term… you would think an investment in such systems would make sense for exactly the situation that is occurring right now.

I totally agree, but you always have to weigh up how much data you absolutely need. That AGS would like to log absolutely everything of changes is sure, but that is simply not possible without significantly affecting the performance.

Imagine a MMO economy that was entirely blockchain every item is verified against the chain. Duplicates cannot exist.

1 Like

Well, the current problems with blockchains is the performance bottleneck, so I highly doubt that is viable for a real-time game right now. Maybe if the technology improves?

1 Like

Bro what? :sob:

1 Like

Fortunately, blockchain systems do not involve significant calculations (PoW) or require a position of trust (PoS)…

Right now, my hope is that AGS did not roll back because they are working to patch up the problem first, because what would they do otherwise? Shut the game down while they work on it? So, I don’t think them not having roll-back’d already means 100% they will not, so I will hang on to my little belief.

At most, I’d imagine major MMOs record a ledger of “User A generated qty X of item Y”, “User A traded qty X of item Y to user B”, and so on. If you keep that level of record keeping, you can always determine who duped an item by running through the ledger, re-applying all the transactions with additional authentication. It doesn’t require keeping track of every last instance of an item. It allows stacking and splitting. It’s also useful for things like currency - if you have WoW-style copper, silver, and gold, you don’t have to treat 1 gold as the equivalent to 1000 individual copper ID tokens, and don’t have to brainstorm weird item exchange processes that will only further bloat your data and your transaction logic.

1 Like

AGS certainly have such a system.
But now the problem, the current dupe was to cancel a sellorder and because of “server lag” the “refund” of the items was executed several times due to a bug/bad implementation.
This is an error case, the normal logging then does not work cleanly.

1 Like

@Deramond
Wouldn’t the refund be logged twice then?
The system should force log on certain actions. As in, you cannot have a refund issued without it being logged, they would be in the same block of code execution. How would this create an issue?

I can only guess here, but it is absolutely possible that the items are refunded multiple times but there is only one refund in the log.

Very simplified the code would then probably be like this:

item in tradepost → cancel button triggers → refund item → parse to log

The refund item part is executed several times due to lag before it is finally written to the log.