Fr0stbyte's Development Log

i...can't.....UNDERSTAND ANY OF YOU!!!!!

ipel4 wrote:

Also about mod compatability either you should directly add something like buildcraft to mass produce ships or make something that does the same.Otherwise it will get really boring really fast.There should be something like a conveyor belt going to a robot arm which builds it(made up while writing).

My job, see shipyards.

Alright, I'm back, let's do this.

Keep in mind that this may all change in the next few updates, but for now there are 3 different ways entity movement is handled in multiplayer protocol. It's been a while, so I might get a few details wrong, but bear with me.

The first way is "Entity Velocity". It is an 11 byte packet describing velocity in increments of 1/32000 per 1/5 of a second (a server tick = 4 client ticks). Because of the 2 bytes per axis limit, velocities can only be expressed up to 0.9 blocks per server tick, or a little under half the top speed of a minecart. Anything faster must be handled with one of the other movement methods.

The second method is "Entity Relative Move" and "Entity Look and Relative Move", which are 8 bytes and 10 bytes respectively. The position update is relative to the entity's previous position and can range from +4 to -4 blocks at increments of 1/32 of a block. If the entity has an associated pitch and yaw, those are also included with the "Entity Look" version. For any motion farther than 4m.

For distances farther than 4m, the third method, "Entity Teleport" is used. It is a 19 byte packet and has a resolution of 1 block, but you can place the entity anywhere in the world. It is rarely used for normal movement because it looks terrible, but it is available for particularly fast entities.

Fast-moving missiles would look terrible under the current system, which can't support high velocities very well. The reason for the "rubber banding" effect in the first place is from "Entity Relative Move" packets getting stuck in the transmission stream behind bulky chunk update. In a TCP stream, there is no way around this either. Objects enter the stream and get fired off in the order they were inserted. No timestamps or guaranteed delivery time, but all the data will get there and in the correct order, which makes it easy to work with. But that's not good enough for a real-time video game. Some packets are more important than others and should be sent out first even if others are earlier in the queue. Some packets are worthless after missing a deadline, but are getting sent anyway. Sometimes an object will get updated multiple times in the same TCP packet, and those changes are never consolidated. In short, it's wasteful, and it needs to go.

I've talked about this at length before, so I'll be brief this time. The network protocol needs to be switched over the the bare-bones UDP protocol, and the game needs to take a more active role in efficiently communicating between client and server. There will be no built-in guarantee of delivery, so there must be error checking and packet recovery measures for those that must be delivered. There's no guarantee of delivery order, so the engine must be able to support retroactive changes. But even with all of that, it would be much faster and far more flexible than TCP.

For missiles and ships in particular, I would like to have a special protocol unique for them.
For the most part, the entities are going to be moving at high velocities along fully predictable courses (barring the occasional pilot adjustments). So what I would do is send the packet as a curve of some sort in 3D space, probably a Bézier. Additionally I would send the entity's position, velocity, and first-order acceleration along that curve, as well as a timestamp to ensure you will have the right numbers for whenever you receive the packet. Instead of sending updates every tick, you only need to send one every time there is a course change, which for something like missiles will not be terribly often.

From a collision standpoint, this is also good, as you pre-calculate the entire course and look for objects that might come in contact at different points in time. For the first pass, you can use large, inaccurate but easy to calculate hitboxes to see if anything is in the area, and then refine potential collisions later on, and since all of this is happening ahead of time, there is no rush to locate all the nearby object every tick like there is in the stateless model. You just find them once and keep an eye on them. The system could be expanded to work as an early collision warning system for pilots, or you could make the courses more elaborate by adding additional offset functions to the initial curve to produce more complex motions, like missile clusters moving as a swarm.

So that's missiles in multiplayer, and to to a lesser degree, space ships. From the beginning, this was always more or less the plan.

Frost, how significantly will this multiplayer change affect Copernicus? Will it break everything, or what?

What I outlined here was an element of the Copernicus framework before Copernicus was an element of Futurecraft. So no, not really.
And I'm sure this isn't the first time I've talked about this (though the forum search is crap so I can't be sure).

Or do you mean the new thin-client model Mojang is trying to develop? Because that's going to complicate matters a ton.

I indeed was refering to Mojang's thin-client protocol. In the long term, I like it, since all mods will practically be forced to support multiplayer, but I also dislike it, because its going to break EVERYTHING.

http://www.minecraftforum.net/topic/697371-125-ships-and-boats-version-094-new-boats-submarines-airships-and-cannons/ seems to be doing well so far, maybe check on them now and then to see what they are doing? Dunno if you already have or not.

Robinton's compressed distant chunk rendererthingy is.... progressing....

Spoiler:

Kinda

yeah, I was a bit disappointed by the results after all that build up. On the other hand, it looks like it could work alright without much tweaking. FIrst, the resolution needs to be higher closer to the player. 2x2x2, then 4x4x4 and so on. And the coloring looks to be done simply by biome color, rather than material. Really, you should be able to blend the biome color across the cube just by specifying it at the corners. Finally, the blocks don't have a good representation of the terrain volume, seemingly getting generated if there is even one block in the volume.

It should be possible to handle all of this stuff from within the initial steps of the world generation algorithm, and never mess with full-fledged world generation to produce them. Robinton's a smart guy, so I'll give him the benefit of the doubt on this one and assume what he has is more placeholder than final product, but it definitely needs some some work.

Buggy1997123 wrote:

Robinton's compressed distant chunk rendererthingy is.... progressing....

Spoiler:

Kinda

What the Sukolov?

Lord Mackeroth wrote:

Buggy1997123 wrote:

Robinton's compressed distant chunk rendererthingy is.... progressing....

Spoiler:

Kinda

What the Sukolov?

The what? I didn't take this screenshot btw.

Buggy1997123 wrote:

Lord Mackeroth wrote:

Buggy1997123 wrote:

Robinton's compressed distant chunk rendererthingy is.... progressing....

Spoiler:

Kinda

What the Sukolov?

The what? I didn't take this screenshot btw.

I'm just amazed at its lack of cohesion.

Frost, I have more of a future request than a question: If your the one to create the single-person entity based fighters, would it be possible to allow it to kill players by flying into them? Without taking self-damage, assuming you don't hit the ground as well?

I ask this because, you see, in other games it's become a bit of a sport of mine to kill players by only hitting them with flying vehicles(its called booping, as named by its original inventor, Bigirpall), ideally without hitting anything else and exploding, and I've gotten good at it. Very good. To the point that I can get a k/d ratio above four and do better than the top players with what is essentially a scout-fighter, without firing a single shot.

Seems reasonable, though the implications are troubling from a balance standpoint.

maybe theres a way to get chunk height based on the seed, project a curve on a flat plain to represent it, then apply a texture like the one you see on a map.. just an idea

Krade wrote:

maybe theres a way to get chunk height based on the seed, project a curve on a flat plain to represent it, then apply a texture like the one you see on a map.. just an idea

That sounds like genius, but wouldn't you still then have to generate the world?
Oh, and this topic just passed 11,111 views.

For a perfect sphere, it's not too difficult to generate the surface textures, but getting details and block information from the blocks that are not the top block requires a lot more work, and a lot more geometry. Still, something like that may be necessary regardless.

fr0stbyte124 wrote:

For a perfect sphere, it's not too difficult to generate the surface textures, but getting details and block information from the blocks that are not the top block requires a lot more work, and a lot more geometry. Still, something like that may be necessary regardless.

If we made every world a flat world, would that help?

This would be a simple way out, make planets a different world, and have a non seamless transition for your ships, and go to a flat surface planet. It would be so much easier then dealing with all the geometry.

Spoiler:

I said this the first day I came too, along with somebody else. It is in the space topic.

hyperlite wrote:

This would be a simple way out, make planets a different world, and have a non seamless transition for your ships, and go to a flat surface planet. It would be so much easier then dealing with all the geometry.

Spoiler:

I said this the first day I came too, along with somebody else. It is in the space topic.

I think he means the following:
the entering and leaveing of the atmosphere gets managed by the ships computer system, so basically you don´t have to do anything meaning you could just make planets the previously stated cylinder- form with polar storms and do it in a way so people like enter a different world when going into/ out of the planets atmosphere but the surface of the planet can still be seen fuzzyly from space.
any questions?

Ivan2006 wrote:

hyperlite wrote:

This would be a simple way out, make planets a different world, and have a non seamless transition for your ships, and go to a flat surface planet. It would be so much easier then dealing with all the geometry.

Spoiler:

I said this the first day I came too, along with somebody else. It is in the space topic.

I think he means the following:
the entering and leaveing of the atmosphere gets managed by the ships computer system, so basically you don´t have to do anything meaning you could just make planets the previously stated cylinder- form with polar storms and do it in a way so people like enter a different world when going into/ out of the planets atmosphere but the surface of the planet can still be seen fuzzyly from space.
any questions?

Please restate that, I somewhat understood it. It is written well, but my mind is somewhat muddles with othere thoughts. So could you or someone else possibly rewrite this? Thank you. (I am NOT trying to b**** to anyone here)

~ Khmac

I really want to do seamless travel though. That's one of the major points of this mod.
Besides, it's more an issue of preserving details at a long distance than it is morphing the geometry.

(USEFUL (hopefully) NECRO)


wait, could you have a non-seamless thingy that would look seamless?

IE:

you take off, and slowly float towards the height limit, once there, you enter into a kind of empty space instantly, that has a sky box ( I think that's what it's called) showing the planet you're on below you, and a 2d representation of whatever's in orbit. And all the loading or whatever is done while you slowly float up, so it seems like there is no transition. that could be used for balancing stuff too (like different tier cores, or whatever)



of course i'm making the assumption transitioning to this empty place would take so little resources as to make it virtually instant, also that the "background work" for getting into space could be done without anything in the UI changing (other than an altitude sensor or whatever) until the last second.

Would it be possible to have flat worlds at a certain height, and when you rise higher, the chunks that you couldn't see begin to form the other cube faces? Then each face could have, say, 16 chunks, and if you traveled low or on foot, the world would be flat, but from a higher point or in space, the other chunks are the other cube faces. And the face you ascend from is the top face. I think this has been discussed before, though.

It would be easier to bend the geometry in the shader itself, and that will be a function of height. Hopefully, it will be subtle enough that it doesn't look weird. Then again some people play with quake pro DOF, so clearly it's an easy thing to get used to.