Forums leading to topics about bugs, for forced compensation and when they pulled the bs move and made the excuse bugs was lagging the server. Nice

Want to know the real reason? The feature will be added back in a couple of months (after everyone forgets it was ever a thing) as a purchasable feature for your house and cost you 20k. Unixmad has gotta buy all that bread somehow you know.

Is there any links or proof to that claim? The only legitimate reasons I could ever think of are
1. It was removed because having to recatch bugs in your house was a hassle at times.
2. a possibility of a glitch that allowed people to get multiple bugs perhaps

But actual it "Caused server lag by that at most 3mb of data" is a little bit of a poor excuse. Even for making money because not many people are at all willing to pay for a 2500 cage for their 50g worth bug. Unless maybe a rare pillbug but even that isn't really worth it unless you got a well known house

Damn

Mind explaining how extremely low data consuming bugs somehow lag the server then?

Bugs move around and their positions need to be updated every single time so each player can see them in the same position(coordinate) they're at.
With this in mind you can sort of see that handling 10.000 bugs might put stress on the server by a huge amount.

This is just what I think the reason is though, not sure if it's correct and there's probably more going on

Because data has nothing to do with it? That's like saying "oh, my Pentium 3 computer can run GTA5 fine because I have a 1TB hard drive!" Data != processing power. While bandwidth(how much data is being sent/received) is always a concern when it comes to online that's not a major problem for Graal.

Concerns come in the form of processing power. Each bug has a script, a script that tells it what to do. The NPC-Server needs to parse/interpret this script, which means it has to convert the gscript to the lower level code that Graal runs in(c++). So while most games are already running natively in c++(or some other low-level language), Graal needs to perform an extra step of converting the entirety of most of the server into c++. Interpretive languages take a lot of processing power by themselves. Then you have the script itself. Each bug, running its own script telling it how to move. These run in something called loops, basically where an event is called, actions are done(in this case moving) and then they start over repeating the actions again and again. Otherwise the bugs would take one step and never move again. Loops are very intensive because it means the script has to run constantly, over and over. Every time this is done, the CPU needs to process this information and make calculations.

Right now there are ~4000 players on. Nearly 850 are in houses, meaning over 800 house levels are currently in memory and actively running scripts:
https://i.imgur.com/4uZAEdk.png
Let's assume half the players have bugs in their houses, after all it's free to catch bugs and it was free to release them into their houses before. They were practically free furniture. Let's assume they have 10-20 bugs in their houses. That's 4000-8000 bugs running their looping code to move around at the same time. Now they don't always run on the same tick, some only move every second or so but it was a problem because they were free. Don't believe me? One of the biggest mistakes that was made in the past was selling pets on Oasis for 25 gralats. I wasn't around for it, but now there are some houses with hundreds of pets moving around constantly. Because it was really cheap to do so. Their prices have since been changed and pets now move less frequently.

I can't 'mathematically show you why' because we have limited information when it comes to server cpu usage. All we can see are the top 10 NPCs(individual) that are consuming CPU, and if a furniture piece shows up in that list it's bad because it can easily snowball out of control since that can easily multiply out by hundreds depending on how many are in active houses.

TL:DR? Scripts matter as far as CPU usage goes on the serverside, not how large their image file is.

If this is such a big issue, why not just move the bugs movement to clientside WHEN they're inside houses.. ? Problem solved, no?

Ah, interesting, but wouldn't that be a problem anyway in the long run? I'd imagine graal will eventually grow, So pets and do on and accordingly tracking movements and probably among everything else. I didn't exactly take any server side CPU into account.

That's what I originally thought, I figured that would probably help would prob help bug catching as well since you don't have to fight 5 or 10 other people for 1 bug in the open world

There's a rule when it comes to online game design, and that is, never trust the client. If bug movement was moved to the clientside, people could potentially cheat using memory editors to make bug catching a lot easier.

No, I just like coming up with conspiracy theories to get a reaction out of people.

Thanks for the information. So it's settled.... No more bugs in our houses.

I hope your enjoying your millions of bread Unixmad :)

Well I obviously know bug movement in general shouldn't be trusted under the client, as in when it's being used for players to catch them. But, I fail to see how there would be any issues if they made it move on the client ONLY when they've already caught the bug and choose that they want to release it into their home for decoration. Simply make it use clientsided movement when it's released into their home and it would ultimately remove the option of being able to catch it again, unless you want to remove it from your home, which would ultimately just destroy the bug instead, making the bug almost like a "consumable" furniture item.

Because players would see bugs in different locations.

Keep in mind you could probably get pretty close in terms of sychronising clients via specifying a vector on the serverside every random x seconds for the bug's direction and duration to travel (could be stored in an attribute?), store the last x,y in other attributes and let the client handle the interpolation easing the load considerably compared to having to execute the script every frame or whatever the execution rate is on the server. Also I realise I've left out of a few details here in terms of players entering at different times, but surely such a scheme is achievable to offload a lot of work the server does on to the clients.