Inter-Level Experience Reset - A Possible Solution

[Sighearth]

I mean, yea anyone with minimal programming background knows that in theory should be easy enough. That includes SE, if they are not taking the route of recrawling all the new values its obvious that is something else that we don't know about. And its better we don't know, the little they advertise their infrastructure the better. Now based on wild speculation I think that they will need multiple read and write actions per character ( as any character could have up to 17 battle jobs + all DoH and DoL jobs). Probably its calculated in relation to an exponential curve and that curse will most likely change per expansion (by level interval). My guess is that you would need multiple different calculations per level interval/per job/per character/per something else. SO maybe having to look up some many things would lead to combinatorial explosion. Thinking that solving the problem with hashes/3-4 hours of programming and SE haven't done that because it didn't know better its really naive. They know how to do it its just not worth it.

[Ryvick]

Yar, clearly all they need to do is take a meat cleaver to the end of all the numbers in this game and chop off the last 2 digits from everything. That would be far faster than your lolly-gagging. I'm a butcher by trade so clearly I know the best way to code an MMORPG. Yar!

[Sighearth]

Yar, clearly all they need to do is take a meat cleaver to the end of all the numbers in this game and chop off the last 2 digits from everything. That would be far faster than your lolly-gagging. I'm a butcher by trade so clearly I know the best way to code an MMORPG. Yar!

You, I like you

[DrWho2010]

the solution most likely exists, but is ultimately not worth the doing. easier to take the path of least resistance for something of this nature.

[Anonicat]

The calculation is the part that takes a long time, and if they’re doing it for every data point, there’s bound to be repeat calculations in there. So instead, make a solution lookup table.

You calculate every possible value and what it maps to in advance and store them in a separate table. Going by this chart, the table would only need ~325M rows (not nothing, but also not unreasonable, especially if you partition it right), and would be fully static. This would mean that it could be indexed extremely easily, and the indices would have zero chance of going stale. Rather than calculating everything, you’re just joining another table, which is extremely simple in terms of design, implementation, operational complexity, and execution.

Doing a full table update over ~2B rows without any math would take maybe 15 minutes.

And perhaps they did consider it, but perhaps not. I just saw the operational complexity and know there’s an easier way to do it (because I’ve done it).

You're not suggesting making a table row for for literally every experience point are you?.... then trying to join it... with other tables are you....

[arathald]

If there’s anything I’ve learned in over a decade working in professional software development, it’s that someone else’s backend is never as simple or clean to worth with as you assume it is from the outside.

[Anonicat]

--snip--

First. HP isn't all calculated on the client side. The items are being stat squished so a calculation is being ran against those stats for sure. And HP is calculated from items, levels etc. Levels arent being stat squished per say.

They are just taking out the calculation in the loop. If im honest a gut feeling tells me what you are suggesting may be more time expensive. It'd be easier to run through and just normalize everything.

Say level 79 with 37,650,000. if you have 16,500,000 EXP out of 37,650,000 , just divide and multiple. 16.5/37.65 = .438. Take that value and multiply it too the max value of the new exp value table would only need 90 btw. Just a tad smaller than 325 Million rows. This calculation is easily performed in an UPDATE SQL statement im sure, or an SQL script for that matter.

^ That would be easier.

But now take away that last part, and its just Number of Characters times the # of datasets/points they have to affect with it, and just set to 0 that is no calculation, and its faster.
If you start adding in joins, you will start incurring huge time penalties.

[Anonicat]

Also No-SQL is Document Based .... IMAGINE like your character info and everything is stored in document in JSON format would be nice. You can add or remove as you see needed. But that comes at a cost (performance and potentially bug prone if not handled correctly.) Honestly it would be more beneficial to use in MMO's, but not completely. Having to join tables over and over. If its not cached just takes too much time. Also caching takes too much memory. Alot of companies go the route of SQL, which is relational which is fine for the most part... but i don't think all my character data should be stored across multiple tables that seems costly as hell to query, and takes up precious computing time on the servers. I would actually use No-SQL for certain parts of the MMO backend and SQL for other parts (say the data analytics they gather.). I don't know why tbh they don't having to deal with all the joins and stuff is annoying programming, and im almost certain things could be made alot faster if programmers made NoSQL and SQL work together.

Like for example assuming that character data is all relational and items etc.
You have to join the character table on the items table. (Again performance cost.)
Now however that is assuming their is one table for items, and 1 for character. but say they have 10 columns or whatever.. for the individual items they have. They could just pull it from one table. Which would be alright. But if its seperated into rows, oh buddy...

In a NOSQL - SQL hybrid you could be like CharacterItemsEquipped = 1,2,3,4,5,6,7,8,9 (being item indexes) do an SQL QUery where ItemIndex = CharacterItemsEquipped and return the items pretty fast, then it simpler to just update the table of items when a stat squish is needed.

[Floortank]

Maybe it's not a problem worth going out of their way to solve.

[weebtext]

dude just level up lmao