Legacy items
|
Rhys never said it was impossible, that is a straw man you created. He said that the effort required to do the change is not worth the benefits
Also you cant state with any validity that you know the operation is trivial. PoE database is likely to be ridiculously huge, and things get more complex if they did sharding. What you are saying may apply to some toy Ruby on Rails website you have sitting on your laptop, not a complex game that is in production that has a massive number of accounts I call a spade a spade, what Chris says about desync is largely balony, what Rhys is saying right now is not Last edited by deteego#6606 on Feb 11, 2014, 3:59:43 AM
|
|
" What did Chris say about desync that you think doesn't have technical merits? IGN : Ericaa
My Store! /108685 My Rain of Arrows Evasion build guide! https://www.pathofexile.com/forum/view-thread/791798 Twitch! http://www.twitch.tv/samfishersam |
|
" I agree it probably* wouldn't be a coffee break job, but I don't agree about the benefit. Once you have legacy items in the game you have to live with it forever, it's one of those things that can't really be swept under the rug, either you have them in the game or you don't. * Probably, I say, I have no idea about their database model but the problem might be upscaled a bit, if I wanted to justify not doing something I'd put some bullymong fur on my hat too :) Wish the armchair developers would go back to developing armchairs. ◄[www.moddb.com/mods/balancedux]► ◄[www.moddb.com/mods/one-vision1]► Last edited by raics#7540 on Feb 11, 2014, 4:47:08 AM
|
|
" Because gem skills use a lookup table where as item mods are unique for every item. When an item is dropped, a database entry is created for each mod, that the item has, for that item. On the other hand, there is only a single entry for each skill gem, which points to a single item in a lookup table In order to remove legacies, the database query would either need to go through every single legacy items mods in the entire database. On the other hand, with purity, the only think that needed to get changed was a single row in the database (if its even in the database, the lookup table may be hardcoded) This was already explained by Rhys, its just how PoE structured the database. Gems are structured completely differently to items in PoE. Each gem of the same type (i.e. purity), is considered the same. On the other hand, every item is considered unique. Even though every single khaoms may have the same stats, as its structured in the database, every Khaoms is actually a unique entry, and so to change every legacy Khaoms, you have to manually change every single legacy Khaoms in existance Last edited by deteego#6606 on Feb 11, 2014, 5:07:01 AM
|
|
|
@Deteego
What he said about cheating is in a way correct. It may not be a direct result of it, but it opens up an avenue for it. For a game to not lag/desync/rubberband, more calculations have to be done on the client side. The more of that happening client side, the more exploits can abuse it. Just like how CS and BF do it, server side hit detection. IGN : Ericaa
My Store! /108685 My Rain of Arrows Evasion build guide! https://www.pathofexile.com/forum/view-thread/791798 Twitch! http://www.twitch.tv/samfishersam |
|
" sigh... it's like half of you understands what's going on and other half doesn't. Purity implementation from database POV: item: id: 2347862384762387 type: PURITY xp: 1.000.000 quality: 15% Everything else is derived from the above (radius, resists, screen name). Item has sockets, sockets point to items which must be gems. ---------- It was spelled very explicitly. Item stats are separate entity which are decoupled from brackets once stat is rolled. That is why divining legacy Kaom gives you +500 HP and NO fire damage. Migration code wasn't written for some reason. | |
|
Spoiler
" Ok, that structure makes sense. But the process would still be automated and fast, even though they would need to search for each unique. First you upload the patch (to get the new base stats online), then search for uniques and execute whatever script divine orb executes when used on an item. Imo, they just went for the technical excuse, as a "middle solution" to not piss off people too much (and people were still really pissed off, for some reason). As I said, I think it was the right decision to not nerf legacys - it would be a FUU to the whole OB and "this is the last wipe ever" CB statement. When night falls
She cloaks the world In impenetrable darkness |
|
" Have you ever did any kind of work on a database before? Odds are, the mod tables (in the database) aren't even index'ed (for performance reasons), because they don't normally need to be (when you load a character, you would just read the mods for an item once, and they would only ever change when you roll something like a divine orb on an item). This means doing a manual query of getting every single mod, of every item X, for every user, is going to be really slow Even if they are indexed, the query would still be slow. And thats not even getting writing a *correct* migration script, creating a backup of the entire database (increase the migration script fails, because thats does happen in reality) " No, you are looking for an excuse to try and paint something in a different manner because you don't agree with it. Anyone with any knowledge of database in non trivial systems knows immediately why its not a trivial task, and also knows immediately that you don't know what you are talking about My advice is to not get into an argument when its clear you don't have a proper understanding of what you are arguing about Last edited by deteego#6606 on Feb 11, 2014, 5:23:06 AM
|
|
" Yes " 1.) "correct migration script" is already written -> divine orb 2.) You don't create backups of a database, you create a transaction, and if something fails you rollback the transaction. This mechanism is supported by all major database systems. Even by opensource lightweight ones like SQLite. In any case the backup already exists on redundant servers. How many legacy items (Kaoms, Shavs, Soultakers..) are there? Lets say 100.000 (and imo thats grossly overestimating). Executing 100k queries and scripts on a modern database system and hardware is peanuts. E: Nothing needs to be indexed either, since this is a one-time event, not data you access all day long. When night falls She cloaks the world In impenetrable darkness Last edited by morbo#1824 on Feb 11, 2014, 5:38:20 AM
|
|
" Thats not the correct migration script " Actually you do. You never trust the rollback of transactions, especially in a database like SQLite/MySQL, which have terrible reputation when it comes to data consistency and reliability, and especially with a migration of this size. Furthermore, as far as I am aware, there isn't a single SQL database that does ACID transactions if the database is sharded/distributed, which means that if the SQL script fails, and the transaction rollback fails, you have just completely screwed up the database (good work!) There is a reason why companies do full database backups. " You have to alter every single mod for every item, its not just alter item, its alter item*number of mods for that item (which have to be specifically looked up for that specific item.) Of course, this is completely ignoring how the database is indexed, and how many joins need to be done. That, and if we are going to be consistant, we should nerf every single legacy item. May not be a lot of Kaoms, but how about silver branches? Last edited by deteego#6606 on Feb 11, 2014, 5:47:51 AM
|
|
