Author Topic: Brick limit  (Read 6891 times)

If you are no fancy of my idea, then you come with something better.

I don't even understand why you're telling us your "idea" - nobody asked for it and it doesn't solve any sort of problem that anyone's mentioned.



I'd like to point out that the ability to get to the 128k limit without running out of ram is a relatively recent development.  How quickly such things are taken for granted.

I know that you don't want to change in the engine, but I think there is a way of fixing this.

Fixing what?

Even if dedicated servers could have a higher brick limit, the client still have to see those bricks.

To fix more problems on my idea, the client have the original limit on 128k bricks, but when it reaches it, it moves brick from RAM to HDD that is out of sight. If bricks are removed, it takes the closest brick and fetches it back from HDD to RAM. If some bricks come in sight, and others are out of sight, it makes the same swap as above.
When it saves, it takes bricks from both RAM and HDD and merges them together to the file it saves to. (Ouch for events and owners)

If you are no fancy of my idea, then you come with something better.
What happens when we get a bunch of new bricks in sight, but we don't have any that have moved out of sight?

I know you can go beyond the limit in offline mode.

Although, there was this one time where my friend had a messed up creep mod. It would add to the brick count, but not subtract once you killed the creep. Blockland said his emtpy server had over 800,000 bricks.

Rephrasing:

This is used to increase the possibility to have more bricks on a server and the client may still receive and see them. In this case dodge the brick limit of 128k.
A dedicated server stores bricks on the HDD if it reaches the brick limit. HDD is still faster than an internet connection, so having a dedicated server with 1 Gbit/s upload wouldn't help if the HDD have 3Gbit/s(As I assume most dedicated servers have).
The client receive all bricks from the server. If it reached the brick limit, it caches it on the HDD depending on the distance from the client. If the limit is reached within a certain area, you are not allowed to build there. This area is the closest bricks in a radius from the brick you plant. When the client moves through the server, bricks that will be in sight are fetched from the HDD and those out of sight cached to the HDD.
This does also means that if you teleport from one place to an another, first time you will load the bricks. Next time it will also load the bricks, but do it a lot faster, or not even noticeable.

If this is made correctly, there wont be any problem causing you lag when caching or fetching bricks.

If there still are questions about this, notice me.

You're very persistent aren't you.

The biggest reason why this is totally not feasible is because of the processing involved of calculating which bricks are within your range and which are not. This is a lot of processing and would slow down everything considerably. I think you should leave network architecture to the people who have professional experience.

You're very persistent aren't you.

The biggest reason why this is totally not feasible is because of the processing involved of calculating which bricks are within your range and which are not. This is a lot of processing and would slow down everything considerably. I think you should leave network architecture to the people who have professional experience.

I agree. Also, he overlooked/assumed some parts of Torque's networking architecture.

You're very persistent aren't you.
I do my best.  :cookieMonster:

The biggest reason why this is totally not feasible is because of the processing involved of calculating which bricks are within your range and which are not. This is a lot of processing and would slow down everything considerably.
That might be a problem. But problems are there to be solved! Use your brain to solve this instead of working against this.

I think you should leave network architecture to the people who have professional experience.
I agree. Also, he overlooked/assumed some parts of Torque's networking architecture.
You seriously didn't read what I wrote, or you misunderstood me. It transfers all bricks as usual. Not removes brick and resend them as I believe you understood it like.

I do my best.  :cookieMonster:

It was not a compliment.

Use your brain to solve this instead of working against this.

It's not my job to come up with ways to optimize the game. Nobody asked you to solve this non-existant problem either. It is also an inherently terrible idea - which is why no other game I've ever seen caches network data on the user's hard disk. You have not just invented some revolutionary new idea that every software designer is going to leap on - it's just bad.

You seriously didn't read what I wrote, or you misunderstood me. It transfers all bricks as usual. Not removes brick and resend them as I believe you understood it like.

Networking also covers the management of ghosted objects on the client, not just the transmission of data. I have not misunderstood you at all, you're just persisting in pushing this terrible idea and ignoring all the points I make trying to show you how bad it is. Caching networked data is totally counterproductive because you then have to check with the server to see how much of that cache is outdated next time you want to use it.

I'm trying to explain things to help you understand why this is wrong but you're being incredibly ignorant. You should try not to be so ignorant of the facts and maybe you'll further your understanding of the subject.

It's not my job to come up with ways to optimize the game. Nobody asked you to solve this non-existant problem either. It is also an inherently terrible idea - which is why no other game I've ever seen caches network data on the user's hard disk. You have not just invented some revolutionary new idea that every software designer is going to leap on - it's just bad.
Only came with an idea of how to raise the brick limit by bypass the limit of RAM. Never said that it has to be implemented.

Networking also covers the management of ghosted objects on the client, not just the transmission of data. I have not misunderstood you at all, you're just persisting in pushing this terrible idea and ignoring all the points I make trying to show you how bad it is. Caching networked data is totally counterproductive because you then have to check with the server to see how much of that cache is outdated next time you want to use it.
It still does that. I know how the networking on BL work. You're just so convinced that I don't.

I'm trying to explain things to help you understand why this is wrong but you're being incredibly ignorant. You should try not to be so ignorant of the facts and maybe you'll further your understanding of the subject.
You don't have to talk about yourself in first person.
Oh, I'm sorry. Did I hurt your feelings?

You can go above 128k without lagging easily. It just requires things to be spread out so that you can't see them.

They wont ghost after 130k and you will have problem spawning. (What I have heard)

Oh, I'm sorry. Did I hurt your feelings?

I was just explaining that I'm trying to talk to you politely but you seem to be pretty self-confident about what you think you know. Next time you suggest something maybe you should leave a footnote stating that you quite enjoy it in your bubble of ignorance and that maybe nobody should explain the reality of things to you, lest we have a repeat of the demonstration of your lack of understanding of basic networking again.

I am also trying to be nice, but you offended me.

Also, give me correct information of how TGE networking works and we'll see who is right.

It's not like that. I can't just sit here and explain TGE Networking in a forum post. I'm saying that using a hard drive to cache critical networked data that goes out of date near immediately in most situations is useless and I've never seen anyone do anything like it before. It's not tge-specific - this is common sense.

im referring to a REAL rented server, with lots of bandwidth. not some kid's extra computer he found in his grandmas basement.
Which would limit the use of this down to.... 1 person.