Changes I'd like to see reverted once the Unity Client is out

#57

Didn’t you just… prove yourself wrong here?

#58

RWT is very much alive. Just check the two biggest platforms. Those buyers want the item instantly, not days let alone months.

#59

I don’t understand it? Really, you seem not to understand it. Or at least you have not explained how it will e.g. do this:

There is no way to detect when a crash will happen in advance. If there were a 100% or even 10% reliable way then it would make to insert code to stop it crashing, or take whatever other steps are needed such as stopping whatever behaviour or trigger causes it.

The only way therefore to do what you suggest would be to store data continuously, but the game already does this – it has to so it can recover from crashes, as well as resets, lost connections and similar.

So how is your proposal different? How will your simple, lightweight code change this to suddenly make duping impossible. I suspect when you try and think it through you will realise there is no simple coding change that can magically fix this. If there were don’t you think it would have been added years ago?

#60

Well yes, my explanation has been rather reductionist.

When I say “detect when a crash will happen”, I’m more accurately saying to trigger the code when a certain server load is reached. However, this cannot occur too late into a possible crash, since the server, well, crashes. This could be manually timed, but would rather be better yet adjusted by machine learning after it watches the server crash naturally numerous times, to calculate when last code could be effectively run during high loads before reading data from the server becomes impossible to do. But all of this is moot because something you said in your last reply changed everything.

I am a junior developer at the moment, and I also do not claim to know a fraction of the game’s inner workings beyond what is publicly leaked, version of the game years old. So imagine my immense face palm when you mentioned continuous saving… this changes everything! Instead of having to write a timing mechanism for the snapshot, catalog, whatever vocabulary I’ve used in the past, we can just run continuous data entry upon high server loads. And I mean high, during rubber banding kind of latency issues. And then you simply compare 80, 40, etc. ms before the crash and after the crash. If the server recovers, dump the memory. If a crash occurs, write the data to each user’s entry in the database, and discard that after they reconnect.

I do however see an issue with the proposed change. Make the requirement to start the code (and end it), at a too high of a thresh hold of server lag, and it wouldn’t help a damn thing since the intervals between continuous snapshots would be too high to account for human reaction time. Make the requirement too low, and you’re wasting server resources, granted a continuous system would tear through kilobytes like fire.

Actually, no, I’m wrong again, and I’m happily wrong! From what I can tell, the server checks are about every 1 second. I can’t give an average just based on a small sample size, but I know the client checks are nearly every 100 ms. Wait… I wish I had an environment to test this on, but in theory, in a server crash scenario, player data is stored by the server, say when the server tick rates jumps up to 1 tick per x seconds, lets say 3. From the moment the server is unable to run checks on inventory to the crash, within a maximum y, that information is ignored.

In a practical situation, x would be somewhere within 3 - 5, where as code can still be executed, but the tick rate doesn’t normally reach. When y hits 10+ (as a theoretical example), the server ignores all vital client information about inventory until a. the servers crash, and then the last snapshot taken is compared, or b. the servers return to a healthy tick rate below the value of y, and any inventory data the client is rolled back to before the value of y was reached.

In practice, y would be set to a number where realm becomes unplayable, so that players cannot claim that they lost white bags, etc. Mind you, when server lag is occuring, such as a tick every ten seconds, the game is effectively running ten times slower. I can’t give you the y value when enemies and players start moving off screen, perhaps y, or x for that matter should be increased or decreased, as were used for examples purely, but at a certain point no player can do much of anything during server lag. Items won’t drop, SB is ignored, requests to use abilities, nexus, death, etc., are all ignored, until the server either crashes or “snaps” back.

Sorry if I’m repeating myself, but:

  1. If it crashes, the last inventory check is cross referenced to the next reconnection.
  2. If it lags but then “snaps back”, all client data during the miscommunication is ignored and reset back to the moment the lag begun. Thanks to code implemented by Deca in a previous QoL update, players who experience such latency issues (server side only) are invulnerable until they come to. In such a case as last year’s infamous ice cave deaths, this would give a grace period of perhaps a second or so to nexus after the snap.
#61

yikes xd

#62

Interestingly, one of the RWT spammers recently began advertising that s/he is selling the site itself. I wonder if that is random timing or related to the unity port or the buffed drop rates (though those are now fixed)?

#63

Absolutely, no I agree, but I just don’t think its as large of a problem before, I think i’ve heard some of these are going out of business (remember a site like this costs money to host, and a lot of time to run and supply the customers and the way they get most of their items is by duping, which isn’t always consistent.)

I’m saying that DECA themselves have made RWT less profitable. Do you remember when WC tops were rare? I do. They used to be worth many life. GGen went from 3 life to 1 this past year.

That means it is 1/3 of the price it used to be. Because of how much more common it is and easy to obtain.

#64

It’s so complicated with the positives and negatives of sb/unsb. RWT can exist in either world, so that’s not really a reason for or against (selling items vs selling accounts). I still think the upsurge in playerbase from unSB and the money payers bring in, (vaults/pets/etc), makes it worth tolerating the inevitable RWTing of individual items.

It’s still the inconsistency of some-soulbound, some-not, more than anything that continues to irritate. If SB UT is a good thing, then by extension SB all ST UTs would be an improvement, and the T6 rings, and abilities, (since they’re the best of their category and we have the LH top weapons/armours SB). Maybe even go as far as just keeping 0% fame items available for trade. Or the opposite and unSB the lower fame % UTs. Honestly why can I trade a noob a Cosmic but not the Jungle UT staff, it’s dumb.

Whereas duping of course is entirely bad, so item IDs? Yeah I’d love that to happen if it gave the game better security! They could maybe transfer some server resources/costs by ditching half of the tumbleweed EU servers for a start…

#65

if UTs do ever become UNSB it will kill the player base overtime. As of right now lots of players without a doubt play the game to collect and grind rare UTs. So if UTs do become UNSB that will leave nothing for players to grind. I know you could say instead you’ll grind to be able to afford buying UTs but that will leave players to grind the dungeons that will give them the most profit the fastest and repeat.

Part of why the UT grind is fun is because of the variety of places that drop good UTs. If you want X UT then go to X dungeon and grind that until you get it, if you want Y UT then go to Y dungeon and grind until you get it. Instead it’ll be go to Z dungeon and grind till you get rich then go buy X UT, Y UT. Even worse if players choose not to do the most efficient dungeon to get rich then they will be wasting their time, there wouldn’t be a reason to do any other dungeons than the most efficient one to make profit.

#66

I hope the thing they tease-mentioned about new game versions (or something) will allow either option to be possible, if you like the PPE style of getting your own loot, or you prefer the FFA of being able to try any item (vault wealth permitting!).

I hate the grind of going to dungeon X for item Y. I personally much preferred the past where I could go to dungeons A, B, C, D,… (the ones I found the most enjoyable) and trade everything I earned for item Y, from a player who had no use for Y, making us both happy.

Fun is the thing missing from your analysis, if you have more fun in tombs, you can run 24-7 tombs, sell off your prots and pyras to the guy who likes doing 24-7 Shats (etc). But what’s fun to one isn’t to the other! So if you have fun grinding for your own personal wb (people did used to do this in 2012 era) you can still do so.

So yep I hope they some how find a way we can both be catered for! :rocket:

#67

I hope so too, adding an official mode where you have to earn everything yourself would be great nonetheless, but I feel like the whole game should be like that to a degree.

Yes, grinding a fun dungeon to get rich then buying UTs from boring dungeons sounds great and more fun. I understand that, but efficiency still plays a big part of whether you will end up doing that. Even if you find X dungeon fun to do, you’d still be missing out on even more profit by doing the most profitable dungeon that you might not find fun.

In the end my problem is if I find a certain dungeon fun that’s not as profitable as another then I’ll have a hard time justifying spending my time doing it when I could be making more doing the other dungeon. Having UTs be SB would solve that problem easily. I wouldn’t have to worry about that, since I’d have to grind every dungeon that I want the UTs from and it will all be justifiable.

#68

This depends on your definition of fun. I certainly enjoy some dungeons more than others. But I also enjoy the variety of dungeons and environments, and the fact you have to do a variety of them to max all your stats, to collect items for sets and unique UT items you particularly want.

If everything could be traded there would be no need for any of that. You could just do the same dungeon over and over again, selling whatever you find, collecting life pots (or whatever) towards the item you need. You would not do the dungeon you find fun, but the one one you can farm most efficiently, over and over again. Even if it’s fun at the start it would likely not be at the end. If it ever ended – you might find yourself doing that dungeon all the time, as the best one for earning wealth.

#69

I also believe that the revenue is going down.

However, RWT shoes sites have been opening and closing over the years. This shouldn’t be taken as a sign of anything. Perhaps your dupe method is patched and you run out of stock. Or you get worried about the legal consequence of running the business.

The cost of running such a site is small once the site and bots are fully set up. Pretty much everything is automated other than customer support and solving captcha for new mules.

#70

This can also be automated with money.

#71

I’d like to see the frames uncapped from 60 personally

#72

It’s not a change to be reverted, but I would love to see enemies that can dodge bullets. I feel like I would stop loving it whenever I had to fight them, but it would be cool.

#73

A bit pessimistic, but maybe this might spark auto dodge hacks that will copy the enemy behaviors.

#74

Amen. It also means you can do consistently dumb shit like EPing the mad god, and gonna buy a new EP. They’re cheap. 8)
…but of course, the kids playing this these days don’t know jackshit about having fun.

#75

Why? 60fps is enough for this sort of game. Not sure what is viable with Unity but the cost of higher frame rates is non-linear in games. Unless you actually need it pushing the frame rate higher can be damaging to performance for no good reason.

Rendering takes a certain amount of CPU time. 10ms say. So if you have 30fps that’s 30 x 10 = 300 ms for rendering, 700ms for game code, 700 / 30 = 23ms per frame. If it’s 60fps that’s 60 x 10 = 600ms for rendering. Only 400 is left for game code, 400 / 60 = 6ms per frame. About 1/4 the time for game code from doubling the frame rate.

Those are made up numbers, but the logic is from experience. You need a very good reason to go over 60fps, as the impact is so high on your game code. You can’t just uncap the frame rate and expect everything to run more smoothly.

edit: There is another reason. Modern PC displays tend to have fixed refresh rates of 60Hz. While CRT displays supported a wide range of resolutions and refresh rates, for LCD displays it is fixed in hardware, as the pixels don’t change size and are refreshed at a particular rate. The rate they choose is 60Hz as for most people that’s all that’s needed.

Yes, you can get displays with higher refresh rates, but no-one is going to buy one just to play ROTMG. They will play it on their laptop, or a standard PC display, which is limited to 60Hz no matter the frame rate of the game.

#76

I have a 144hz monitor. The more smooth the gameplay is, the easier it is to do things such as dodge, at least for me.