How do you interpret the re-discovery of items?

[SnowLeopard]

Generic Leather Texture was discovered again in the last 24 hours. This is not the only item that has been discovered more than once. Undoubtedly, this is the result of some sort of bug, but that is quite vague.
I'd like to hear theories as to the details of the exact reasons behind it.

Off the top of my head, database corruption is one obvious possibility, but that leads to another question: how is the corruption happening and why aren't many other items affected?
Maybe there is a counter that is reaching reaching the upper limit of acceptable values and rolling over. When that happens, the item gets re-discovered?

 

[ranpha]

This may sound stupid ... but maybe the texture has been looted and th system sees it as new ?

But indeed it is a bug and not the first re-discovery

 

[AlphaGeek]

"Discovery" = "first time found since server reboot".

 

[Mega]

I've no idea - maybe raise a support case, I'd be interested in what their reply would be.

Filters is another one I've seen a few times being discovered.

 

[ranpha]

Oh maybe they got re-discovered on RT ?

 

[SnowLeopard]

"Discovery" = "first time found since server reboot".

Doesn't fit the pattern -- every single item would pop-up and discovery message the first time it is looted or crafted.

I've no idea - maybe raise a support case, I'd be interested in what their reply would be.

Filters is another one I've seen a few times being discovered.

Raise a support case? I'd rather have a root-canal.

 

[AlphaGeek]

Doesn't fit the pattern -- every single item would pop-up and discovery message the first time it is looted or crafted...

Ok, how about "First time it's looted after loot server (Jan's Preccccciousssss...) gets rebooted."?

 

[Bones]

Maybe it has a different polygon count.

Maybe the balance manager has changed a looting specific.

Maybe it has been added as an ingredient to a new upcoming bp.

Maybe a hamster got out of its wheel and ran across a keyboard and something got deleted.


Bones

 

[Ciobyna]

"loot-lag" from the "is it discovered?" database querry.

Ciobyna

 

[Falagor]

There is 0.05ped Lysterium Ingot right?

Mayby its something similar . Specific texture with different TT value mayby?

Falagor

 

[mantra]

It happened with basic filter many times as well. I believe it happens when the item completely deleted from the ingame system.

The only reason the basic filter not discovered is because some one keeps some good old basic filter in storage.

 

[GoNi]

It happened with basic filter many times as well. I believe it happens when the item completely deleted from the ingame system.

The only reason the basic filter not discovered is because some one keeps some good old basic filter in storage.

Well that would mean if every existing item of one kind finds it way to TT, the discovery counter is set to "Not discovered", what doesn´t make sense to me.

But if it is just a query, if any item already exists when it is looted, then it explains the loot lag, and produces the re-discovery effect

BTW, very unlikely that all generic leather texture or all lyst stones got eliminated, due to TT

Seems more like a serious bug to me, no clue how and where it happens atm.
To find that out, I would need the code, and the database structure.

 

[GeorgeSkywalker]

The fact that it only happens to few items filters and generic texture looks very suspicious

 

[malasuerte]

Those two (filters and leather texture) must be the most grinded BPs due to been very cheap to craft and used to skill. Maybe something to do with that. After 99999999999999 are crafted the counter resets to 0 and BAM! they get rediscovered.

 

[Falagor]

Those two (filters and leather texture) must be the most grinded BPs due to been very cheap to craft and used to skill. Maybe something to do with that. After 99999999999999 are crafted the counter resets to 0 and BAM! they get rediscovered.

Aww if you are right then we could easily spot cycles on them . This way "IF" there are any cycles we might be able to predict global timing

Falagor

 

[slupor]

Sloppy coding.
poor QA.
Other priorities for maintenance team.

 

[GeorgeSkywalker]

Those two (filters and leather texture) must be the most grinded BPs due to been very cheap to craft and used to skill. Maybe something to do with that. After 99999999999999 are crafted the counter resets to 0 and BAM! they get rediscovered.

sounds very plausible but i'm not buying it

Because oa101's are probably crafted even more. Besides some other BP's must surely reach that limit sooner or later but it never happens to any other BP!
So perhaps you are partially right.

 

[steffel]

folks who rediscover were due to a hof but MA didnt want to give them big loot, so they got disco instead

 

[Sircus]

folks who rediscover were due to a hof but MA didnt want to give them big loot, so they got disco instead

Best answer so far Yay the hof sound, wtf I discovered basic filters?! AGAIN?!

 

[Pirx Danford]

sounds very plausible but i'm not buying it

Because oa101's are probably crafted even more. Besides some other BP's must surely reach that limit sooner or later but it never happens to any other BP!
So perhaps you are partially right.

Well maybe the "item count" is counted, so even as OA101 gets crafted more in clicks there are less "item points" happening.
You get like over 20 textures on success quite often.
So lets assume they used a default unsigned medium integer value as counter as used in mysql, that means the database entry can hold up to 16777215, so after that it starts again at 0 and they increase it at every success in crafting.

This would be a completely stupid way of coding it.
I would set a datestamp that is set to NULL by default and when someone has success for the first time I would set that value to the datetime of success.

No counter, not even a boolean flag, just the datetime of success, as when this is set to something other than NULL it has to have been discovered.

Every item that has a null datestamp in the success table would run the check at crafting, but every item that was discovered already would not even run that check anymore.

There are multitude of ways to do this in the right manner without leaving the chance of having a mistake happening... but with a combination of bad database design and sloppy coding you are able to have bugs that work in miraculous ways!

 

[Miss Scarlett]

maybe the system keeps count of number of each item in universe with in a 32bit integer, when more than 2^32 (+/- 2,147,483,647) of them are created the counter resets, raising an event that so and so descovered basicFilter(1)

 

[Falagor]

Well maybe the "item count" is counted, so even as OA101 gets crafted more in clicks there are less "item points" happening.
You get like over 20 textures on success quite often.
So lets assume they used a default unsigned medium integer value as counter as used in mysql, that means the database entry can hold up to 16777215, so after that it starts again at 0 and they increase it at every success in crafting.

This would be a completely stupid way of coding it.
I would set a datestamp that is set to NULL by default and when someone has success for the first time I would set that value to the datetime of success.

No counter, not even a boolean flag, just the datetime of success, as when this is set to something other than NULL it has to have been discovered.

Every item that has a null datestamp in the success table would run the check at crafting, but every item that was discovered already would not even run that check anymore.

There are multitude of ways to do this in the right manner without leaving the chance of having a mistake happening... but with a combination of bad database design and sloppy coding you are able to have bugs that work in miraculous ways!

Agree that this may generate serious bug . First example that comes to my mind:
I am in possesion of basic filter nr 183666,
Then there are so many crafted it resets to 0 and starts over again as Pirx sugested (it really is reasonable this may work this way).
Then somone also gets basic filter nr 183666 and then drop it to TT. Who gets peds?

Even if only "free" slots would get numbers (so new basic filter can get only number of basic filter that has no owner or its stated that TT is the owner) is still dangerous. 10k click run is common on basic filters. This generates ~270ped of filters when crafted on quantity = 27k of filters. If ~620 people would do a 10k craft run aproximatly at the same time all "free slots" would be used and probably caused database crash (remember that often someone might just start the run and then not log for a week or so and keep those stacks of filters in their possesion)

Lets crash the system... start crafting filers now and do not TT hem ...

Falagor

 

[Mega]

Well, next time it happens it might be an idea to ask Mindark directly via a support case (preferably the re-discoverer) otherwise we'll never know why this happens every 6 - 12 months.

malasuerte and steffel's theories are interesting though.

 

[SnowLeopard]

Another rediscovery: Basic Auxiliary Socket

Several plausible theories... keep them coming.

So if there are are bugs like this, isn't it equally possible that the data defining our avatars also gets corrupted on a semi-regular basis? Might that have a negative effect on returns?

 

[Ed Ward]

might be silly but be happy to rediscover gen leather than discover nothing

 

[Skippie]

when i "re-discovered" basic filters a couple years ago, it was during a massive lag period according to a couple ppl that pm'ed me after it happened. the other day when the gen leather texture went off, i was experiencing some pretty massive loot lag, as well.

 

[Pirx Danford]

I think I found a better explanation.
Probably MA decided that the discovery check is not mission critical and thus to let it be checked client side.
There are a lot of things that can go wrong either while the client is initialized, or while running EU (faulty memory makes funny errors sometimes) also maybe something is wrong with the push event that is also triggering the discovery notification.

Anyway should MA leave the check to the client and just accept a discovery event on the server side without double checking it, then it would explain the erratic behavior.

It would not even be completely bad coding, a much bigger company made the mistake of transferring complete map data to the client in a game you usually had to explore the map first to clear the fog of war.
Some of the million players found out about that and in no time there was a map program showing you the map right after loading a level

To have unimportant stuff happen on the client side can be a good choice...

 

[SnowLeopard]

I think I found a better explanation.
Probably MA decided that the discovery check is not mission critical and thus to let it be checked client side.

I know some people that work for Ubisoft in Montreal and I asked once if the client-side clock could cause server-side problems. The answer was a categoric "No, the server-side trusts as little information from the client as possible".

 

[Lugzan]

since the same error keeps reappearing since... forever, I can only make one conclusion - the error is in the core


J.

 

[Talania]

I think that it happens when there is no new discovery item inserted by the loot manager. It has to give something since the player hit the magic numbers so it just gives something else available.