A problem I thought off:

GLaDOS wrote:

If you do that, I don't think that Mackeroth will be happy, KEON.

Keon? I'm Cthulhu!

No. Cthulu is too large to type.

GLaDOS wrote:

No. Cthulu is too large to type.

I possessed a human.

Cool. Need to figure out how to do that. Except I'm not supernatural. Just a computer. Well, necromancy is on my to-learn list sooo..... Lets get on it!

GLaDOS wrote:

Cool. Need to figure out how to do that. Except I'm not supernatural. Just a computer. Well, necromancy is on my to-learn list sooo..... Lets get on it!

Give me the Portal Gun, I'll give you the Necronimicon.

Cthulhu (Keon) wrote:

Buggy1997123 wrote:

Actually, maybe it would be a good idea to make sure the game knows what to do if a planet is empty. If planets are finite(and they will be) then you just know that someone will try to see what happens when you remove every block, and succeed.

Bedrock.

t/replace 7 00
Bam! No more bedrock!

Last_Jedi_Standing wrote:

Cthulhu (Keon) wrote:

Buggy1997123 wrote:

Actually, maybe it would be a good idea to make sure the game knows what to do if a planet is empty. If planets are finite(and they will be) then you just know that someone will try to see what happens when you remove every block, and succeed.

Bedrock.

t/replace 7 00
Bam! No more bedrock!

We won't have those commands.

Cthulhu (Keon) wrote:

Last_Jedi_Standing wrote:

Cthulhu (Keon) wrote:

Buggy1997123 wrote:

Actually, maybe it would be a good idea to make sure the game knows what to do if a planet is empty. If planets are finite(and they will be) then you just know that someone will try to see what happens when you remove every block, and succeed.

Bedrock.

t/replace 7 00
Bam! No more bedrock!

We won't have those commands.

Will this be incompatible with SPC?

Last_Jedi_Standing wrote:

Cthulhu (Keon) wrote:

Last_Jedi_Standing wrote:

Cthulhu (Keon) wrote:

Buggy1997123 wrote:

Actually, maybe it would be a good idea to make sure the game knows what to do if a planet is empty. If planets are finite(and they will be) then you just know that someone will try to see what happens when you remove every block, and succeed.

Bedrock.

t/replace 7 00
Bam! No more bedrock!

We won't have those commands.

Will this be incompatible with SPC?

I didn't know single player commands is multiplayer. Anyway, the reason is that galaxy will have to be all the same. In a separate galaxy, then yes, spc might be allowed, but in the main one, nope. Anyway, I guess it needs to know, for the creative galaxy.

Cthulhu (Keon) wrote:

Last_Jedi_Standing wrote:

Cthulhu (Keon) wrote:

Last_Jedi_Standing wrote:

Cthulhu (Keon) wrote:

Buggy1997123 wrote:

Actually, maybe it would be a good idea to make sure the game knows what to do if a planet is empty. If planets are finite(and they will be) then you just know that someone will try to see what happens when you remove every block, and succeed.

Bedrock.

t/replace 7 00
Bam! No more bedrock!

We won't have those commands.

Will this be incompatible with SPC?

I didn't know single player commands is multiplayer. Anyway, the reason is that galaxy will have to be all the same. In a separate galaxy, then yes, spc might be allowed, but in the main one, nope. Anyway, I guess it needs to know, for the creative galaxy.

Well, Single Player Commands isn't for multiplayer, but WorldEdit is. They can do similar things.
This makes me sad because I'll have to play fair and make ships by hand instead of cheating and pwning everyone else.

Keon wrote:

I know.

Mackaroth Does Not Approve. Shame On You.

I can't do it well.

Oh hello there. You know, there is a reason even the tough rugby boys are afraid of me at school. They all know what happens when I get angry. Obviously, you don't.

Okay. To get back on the subject of problems, you can lag-crash any player within a zone if you fill it with water and lava. So I think we need to do something about the transparancy. After 3 lava blocks or 10 water blocks, it is really hard to see through. So, I think we should change that. Liquids should only render as transparent before that. But if we go through more than 3 lava blocks, don't bother rendering what is on the other side, leading to increased performance.

In minecraft, only the surface face of water is rendered, and lava is completely opaque. The reason it is hard to see through water is because the light levels drop more quickly than in the air.

The lag crashing is, I believe, because the server is resending the chunks over and over again, possibly more often than there is a visual change. The same thing happens in single player, but you don't notice because everything is local.

I did some more digging and found the problem.
If there are more than 10 block updates between server updates to a client, rather than updating everything block by block, it packs all the block data in a box surrounding the changed area (in 16^3 increments) and sends the whole thing in a compressed format. I see the reasoning behind it, but it's lazy. I assume this was intended for things like explosions with localized affected areas. In that case, this might be an effective method. But for something spread out like the lava, water, and fire on the griefed ship, this is exactly the wrong way to handle it.

I ran some tests while in the middle of the griefed area. Minecraft uses a streaming TCP protocol, with each message appended to the stream without any sort of timestamp, though the ordering is preserved. Normally, it is a back-and-forth communication. One side sends data, then the other side acknowledges the data and sends data of its own on the same TCP packet. When the outgoing traffic becomes too high to keep this up, the TCP server changes strategies and starts sending packets in rapid succession without waiting for a response. Most of the time packets don't get lost in transmission, so nothing happens, but in this state if any do, it becomes more difficult to promptly recover. When it fails, you see it as a rubber-banding effect on other players.

While I was inside the ship, it never left this mode. My client was receiving 500 packets a second, each packet carrying 1500 bytes, and judging by its consistency, this bandwidth was being capped by the server hardware. That's seriously bad. It means that every second I was in there, the server stream was falling further and further behind. Had I stayed in there longer, or if there were other people online to aggravate the situation, it would have eventually led to a buffer overflow and kicked me from the server.

------------------
I've seen a lot of poorly thought-out code in Minecraft, but this decision is shockingly bad. You could accomplish the same thing with just a pair of redstone timers or pistons spread out with a large difference in their X Y Z coordinates. The greater the distance (while still being within visible range), the worse the effect would be.
If they didn't want to incorporate delta encoding (tracking and sending only changes since the previous update for each client), which honestly is probably the best way to handle a lot of the protocol, they should at least do some sort of fast cluster analysis to make sure the affected area really is a single local phenomenon and not separate distributed instances.

This is going to get high priority once we start network protocol.

Tiel wrote:

fr0stbyte124 wrote:

I did some more digging and found the problem.
If there are more than 10 block updates between server updates to a client, rather than updating everything block by block, it packs all the block data in a box surrounding the changed area (in 16^3 increments) and sends the whole thing in a compressed format. I see the reasoning behind it, but it's lazy. I assume this was intended for things like explosions with localized affected areas. In that case, this might be an effective method. But for something spread out like the lava, water, and fire on the griefed ship, this is exactly the wrong way to handle it.

I ran some tests while in the middle of the griefed area. Minecraft uses a streaming TCP protocol, with each message appended to the stream without any sort of timestamp, though the ordering is preserved. Normally, it is a back-and-forth communication. One side sends data, then the other side acknowledges the data and sends data of its own on the same TCP packet. When the outgoing traffic becomes too high to keep this up, the TCP server changes strategies and starts sending packets in rapid succession without waiting for a response. Most of the time packets don't get lost in transmission, so nothing happens, but in this state if any do, it becomes more difficult to promptly recover. When it fails, you see it as a rubber-banding effect on other players.

While I was inside the ship, it never left this mode. My client was receiving 500 packets a second, each packet carrying 1500 bytes, and judging by its consistency, this bandwidth was being capped by the server hardware. That's seriously bad. It means that every second I was in there, the server stream was falling further and further behind. Had I stayed in there longer, or if there were other people online to aggravate the situation, it would have eventually led to a buffer overflow and kicked me from the server.

------------------
I've seen a lot of poorly thought-out code in Minecraft, but this decision is shockingly bad. You could accomplish the same thing with just a pair of redstone timers or pistons spread out with a large difference in their X Y Z coordinates. The greater the distance (while still being within visible range), the worse the effect would be.
If they didn't want to incorporate delta encoding (tracking and sending only changes since the previous update for each client), which honestly is probably the best way to handle a lot of the protocol, they should at least do some sort of fast cluster analysis to make sure the affected area really is a single local phenomenon and not separate distributed instances.

This is going to get high priority once we start network protocol.

I understand some of this!

thanks for posting this frostbyte


wasn't ECtrimble doing the networking/server code?

coalminingalchemist wrote:

fr0stbyte124 wrote:

I did some more digging and found the problem.
If there are more than 10 block updates between server updates to a client, rather than updating everything block by block, it packs all the block data in a box surrounding the changed area (in 16^3 increments) and sends the whole thing in a compressed format. I see the reasoning behind it, but it's lazy. I assume this was intended for things like explosions with localized affected areas. In that case, this might be an effective method. But for something spread out like the lava, water, and fire on the griefed ship, this is exactly the wrong way to handle it.

I ran some tests while in the middle of the griefed area. Minecraft uses a streaming TCP protocol, with each message appended to the stream without any sort of timestamp, though the ordering is preserved. Normally, it is a back-and-forth communication. One side sends data, then the other side acknowledges the data and sends data of its own on the same TCP packet. When the outgoing traffic becomes too high to keep this up, the TCP server changes strategies and starts sending packets in rapid succession without waiting for a response. Most of the time packets don't get lost in transmission, so nothing happens, but in this state if any do, it becomes more difficult to promptly recover. When it fails, you see it as a rubber-banding effect on other players.

While I was inside the ship, it never left this mode. My client was receiving 500 packets a second, each packet carrying 1500 bytes, and judging by its consistency, this bandwidth was being capped by the server hardware. That's seriously bad. It means that every second I was in there, the server stream was falling further and further behind. Had I stayed in there longer, or if there were other people online to aggravate the situation, it would have eventually led to a buffer overflow and kicked me from the server.

------------------
I've seen a lot of poorly thought-out code in Minecraft, but this decision is shockingly bad. You could accomplish the same thing with just a pair of redstone timers or pistons spread out with a large difference in their X Y Z coordinates. The greater the distance (while still being within visible range), the worse the effect would be.
If they didn't want to incorporate delta encoding (tracking and sending only changes since the previous update for each client), which honestly is probably the best way to handle a lot of the protocol, they should at least do some sort of fast cluster analysis to make sure the affected area really is a single local phenomenon and not separate distributed instances.

This is going to get high priority once we start network protocol.

I understand some of this!

thanks for posting this frostbyte


wasn't ECtrimble doing the networking/server code?

i understand some of it too!!!!

coalminingalchemist wrote:

I understand some of this!

thanks for posting this frostbyte


wasn't ECtrimble doing the networking/server code?

Not this part. I haven't gotten a chance to talk to him about it yet.

fr0stbyte124 wrote:

coalminingalchemist wrote:

I understand some of this!

thanks for posting this frostbyte


wasn't ECtrimble doing the networking/server code?

Not this part. I haven't gotten a chance to talk to him about it yet.

Is he still alive? I haven't seen him posting much at all.

No, glados, you can't sing.

His last visit was 21 days ago. I sure hope he's okay.

fr0stbyte124 wrote:

His last visit was 21 days ago. I sure hope he's okay.

I know. But has he been giving updates in area 53? We need his serverportal stuff. Oh, and tell him that I want phase jumping to look exactly like it does in Sins of a Solar Empire, if he is even doing the animation of jumping. If not, then that's your job.

Keon wrote:

fr0stbyte124 wrote:

coalminingalchemist wrote:

I understand some of this!

thanks for posting this frostbyte


wasn't ECtrimble doing the networking/server code?

Not this part. I haven't gotten a chance to talk to him about it yet.

Is he still alive? I haven't seen him posting much at all.

No, glados, you can't sing.

Keon wrote:

fr0stbyte124 wrote:

His last visit was 21 days ago. I sure hope he's okay.

I know. But has he been giving updates in area 53? We need his serverportal stuff. Oh, and tell him that I want phase jumping to look exactly like it does in Sins of a Solar Empire, if he is even doing the animation of jumping. If not, then that's your job.

You sure seem to love Sins phasing

I agree though, the system of sublights and phasing in Sins would fit like a missing puzzle piece in Futurecraft.

On the previous page, I made a mistake I should correct. I said that when there are 10+ blocks being updated in a server tick, it sends all the 16^3 chunks bounding those changed elements. Well, I had misread a few spots in the code, and what actually happens is it only does this on a per 16*16*worldHeight basis, and then only with the block region that just overlaps the affected area. It's still a bad implementation, but I would no longer describe it as "insane".