How to avoid item duplication w savecodes?

[CarlosCepinha]

If you load a developed Hero, drop great items, and load another one and save, now 2 heroes have the said items.

I can limit 1 load 1 save per game, still the problem persists.

You load a hero that has a great item, give it to a friend, he saves, you both exit.
Now enter again and give +1item, etc...

You can repeat this process (even if lenghty and boring) to the point where you duplicate as many times as you want any item that can be saved.

This whole thing defeats the purpose of endgame hi level gear and the rarity of gems to upgrade items etc...

Is there any workaround?

 

[Wareditor]

Bind the items to the player.

 

[CarlosCepinha]

Thanks but I don't know how to bind items to players.
I was hopping I could let players trade items.

 

[Pyrogasm]

Item trading and avoiding item duplication likely can’t coexist in your map.

What I assume Wareditor is suggesting is to save some data about the items ‘owner’ in a hashtable and then read this data when units try to pick up items. This would disallow trading entirely. Perhaps a middle ground would be the following:

• When an item is spawned/dropped/given from a quest make an entry under its handle id in a hashtable that tells the game this item came into existence in this instance of the game. A boolean flag will do, say you set it to true.
• When a player drops an item from their inventory, check that flag you stored for that item.
  • If false, the item has been loaded from a previous game and can not be traded. Store the unit that dropped it in the hashtable and prevent any other unit from acquiring that item.
  • If true then the item is new to this instance and can be freely traded in this game instance until someone saves with it in their inventory.
• When a player saves, automatically set the flag for every item that is saved to false so it can no longer be traded.
• When a player loads, the flag in the hashtable will default to false so trading that item is disallowed by default, no actions necessary to prevent.

The possible exploit here is no longer item duplication (saving prevents trading the item back), but instead that you can ‘claim’ an item by being the first one to pick it up and immediately saving. You can troll people by stealing their items, saving, and then dropping them on the ground afterward where they can see it but not pick it up.

 

[CarlosCepinha]

Wow pyrogasm!

Very interesting ideas you came up with, I couldn't even come close to that.

I was thinking if there was some "unique ID" I could add to an item, and save it along the item (it would be heavy on the savecode, I would need to save another integer for every item saved) and them compare "unique IDs" of items and make sure no one had the same Id, but I would need to be sure that the system would create something diferent every time, and if 2 IDs came up the same by random chance it would be a problem.

The "save exploit" for "item stealing" wouldn't work if I make it so that you can only load and save once (this was already to reduce chances of duplication, since both players would need to exit game and get back into it)

also loading and saving only once makes it so that people can't just keep trying something they're maybe not suposed to and just load everytime it fails, stuff like that.


I never used the function to change ownership of items, I supose it's going to prevent someone else from aquiring the item.

Your solution is really clever! thank you so much for the ideas!

 

[McPhisto2051]

I know im wasting the "item custom value" for it but if you set this to the player number you can easily forbid players to take other players equipment

 

[Cespie]

If you want trading... this could be a solution:

You could design it so that you aren't binding the items to the player, but instead just assigning a unique random ID to each item in a save.
So, lets say you have an item named SUPER HAMMER on player 1's character.
SUPER HAMMER has the random ID: "awf213xa43".
Player 1 saves with Super Hammer awf213xa43
Player 1 then boots up a game with player 2.
Player 1 gives player 2 Super Hammer awf213xa43
Player 2 saves.
Player 1 leaves without saving.
Player 1 boots up a new game and loads his save with Super Hammer awf213xa43
Player 2 who is in the same game, tries to load his save, which also has Super Hammer awf213xa43
Player 2 is denied to load the item, and the item is removed from the character that he loads.

This way, the item Super Hammer awf213xa43 could indeed be owned by multiple saved characters, but it can only ever be loaded once into a single game, so duping items becomes virtually useless in multiplayer, even if you still have the option to give out "dupes" to friends for single player farming, but I don't see a way that you could ever prevent that while also allowing trading.

 

[CarlosCepinha]

Thanks Cespie that was a nice idea that I tought but how do I make the ID so unique that if the same item drops on diferent maps the players won't be acused of duplication. I'm afraid that by chance the "random" ID even if 1 in 1 milion can turn out the same for 2 items and if it's an import item players will get mad.

McPhisto I'm using the item custom value for a item cleanup timer where I increase the value every 10 seconds so items last 2m on the ground and then dissapear.

In the end I don't want to forbid anything else other than loading and giving items for free while keeping them, since the loading screen is long, if I limit load/save to 1 per game, this would make item duping extremely boring.

 

[Cespie]

Thanks Cespie that was a nice idea that I tought but how do I make the ID so unique that if the same item drops on diferent maps the players won't be acused of duplication. I'm afraid that by chance the "random" ID even if 1 in 1 milion can turn out the same for 2 items and if it's an import item players will get mad.

Using the numbers 0-9 and the letters in the English alphabet (26), then that's 36 combinations per digit. In terms of combinations per digit, that gives you:

1. 36
2. 1.296
   
3. 46.656
   
4. 1.679.616
   
5. 60.466.176
   
6. 2.176.782.336
   
7. 78.364.164.096
   
8. 2.821.109.907.456
   
9. 101.559.956.668.416
   
10. 3.656.158.440.062.976

This means that if you think "even 1 in a million" is too low, then that would be less than what you have at 4 digits. At just 6 digits, you are above 1-in-2-billion, which is such an unfathomably small chance that it's hard to put into words.
For example, you are 3100 times more likely to be struck by lightning in your lifetime than to roll the same ID twice (1 in 700k).
But even then, at 10 digits, you are way past 3 quadrillion. A number so incredibly big, that a lot of people don't even know the name of it.
To put that number into perspective, you are 38.000.000 times more likely to win the EuroJackpot, for which the prize is 90 million Euro.

I think it's worth exploring.

 

[CarlosCepinha]

wow that was a surprising explanation I have very little understanding of maths but makes sense that the exponential increase of combinations becames unfathomable after a while. It's an interesting idea however I would have to limit a bit the number of items saved since for each item I would be saving it's own code, wich duplicates the values to save, the code would have to save 100 integers for 50 items. If it can be done it could be outstanding.

 

[Dr Super Good]

Problem is seeding such a random ID. One can only generate pseudo-random 32bit integers. Due to how pseudo-random number generators work one cannot simply generate 2 numbers in row to merge together into a bigger number since there may be far fewer such possible numbers than the number of bits that could be represented. Hence one would also need a custom random number generator which can generate bigger than 32bit integers.

What one can do is generate a unique ID by hashing the player name and combining that with a counter which is randomly seeded to start with and persistently saved. The chance 2 players hash to the same integer is very low and if they do then the chance that their counter ranges will ever intersect is also very low. Result is a 64bit unique identifier which can be assigned to each item. As long as the player keeps loading the same base code (which contains the counter) this would work fine. It would also discourage save scumming (loading older saves) since those will cause counter overlap with the items that spawn.

 

[Cespie]

Problem is seeding such a random ID. One can only generate pseudo-random 32bit integers. Due to how pseudo-random number generators work one cannot simply generate 2 numbers in row to merge together into a bigger number since there may be far fewer such possible numbers than the number of bits that could be represented. Hence one would also need a custom random number generator which can generate bigger than 32bit integers.

What one can do is generate a unique ID by hashing the player name and combining that with a counter which is randomly seeded to start with and persistently saved. The chance 2 players hash to the same integer is very low and if they do then the chance that their counter ranges will ever intersect is also very low. Result is a 64bit unique identifier which can be assigned to each item. As long as the player keeps loading the same base code (which contains the counter) this would work fine. It would also discourage save scumming (loading older saves) since those will cause counter overlap with the items that spawn.

I mean, personally, I'd generate each digit and concatenate them, but that's partially because I'm not sure how this would otherwise be done, but it would certainly solve the integer length issue.