Fr0stbyte's Development Log

Kobialka wrote:

Last_Jedi_Standing wrote:

Kobialka wrote:

Are you working on fighters as well? I say you could use the plane mod with re-textured planes and a re-coded fuel system. Easier i guess.

The planes mod planes don't really look like starfighters. I think whatever fighters we get will look futuristic, not WWII era.

retextured. You could use all the fly coding though. Also, i hate it when people do not realize that in World War II planes were made of metal. Not paper like in World War I

No we can't.

The fly physics are for an atmospheric limited jet. A fighter could do so much more.

Keon wrote:

Kobialka wrote:

Last_Jedi_Standing wrote:

Kobialka wrote:

Are you working on fighters as well? I say you could use the plane mod with re-textured planes and a re-coded fuel system. Easier i guess.

The planes mod planes don't really look like starfighters. I think whatever fighters we get will look futuristic, not WWII era.

retextured. You could use all the fly coding though. Also, i hate it when people do not realize that in World War II planes were made of metal. Not paper like in World War I

No we can't.

The fly physics are for an atmospheric limited jet. A fighter could do so much more.

Where would they differ? I understand that the fighters would be more maneuverable, would be able to strafe (your definition, not the actual one), would have a better fuel system, be able to fly fully functioning in reverse, would have rotatable weapons (and missiles), and be able to roll; but is that really that important?


Actually, I think I see your point...

In an atmospheric jet, a plane going 400 mph north that turns west is going 400 mph west.

In a starship, it's going 400 mph north, and facing west.

In fact, the math is simpler.

I have a suggestion to reduce the lag for when there are going to be massive battles and hundreds of thousands of lasers are going to be shot (I came up with this idea when I was traveling on the bus home so dont expect it to be great just letting you know now) you could make so the lasers are from different worlds just like the ships but not a world for each missile but a world for each axis (not world axis but the entity specific ones).That means that there are 360x360x360 (46656000) worlds that allways exist and thats too much.Instead there could be like 2 or 3 axi positions for one world (or even more)(if 3 per world then there are 60x60x60(21600).

So basically if you didnt understand that every missile entity has an "x" "y" and "z" and an "x" "y" and "z" in the world. We use those "x" "y" an "z" of the specific entity and every one that has a certain combination (like 1 29 354) is part of the same world the same way the sips are in the real world,the missiles are in a world in the real world.That instead of having thousands of entitys in one world you could have a main world in which there is anothere in which there are a couple of hundred missiles.Hope this makes more sense and if you tell me that this wouldnt work then Id call you a liar because I know some coding (very little java but more Unity) and I know that it is posible and I think it could be done for 15-30 lines of code if used the "if" statement.Just to say another thing, if you decide to do it like this then the missiles could be not only entitys but also player build sence they will be in a world thats like the one the ships are going to be.Thats only some suggestions and I hope I helped you with something or gave you an idea.

PS. All that just to reduce the lag even more.

ipel4 wrote:

That means that there are 360x360x360 (46656000) worlds that allways exist and thats too much.Instead there could be like 2 or 3 axi positions for one world (or even more)(if 3 per world then there are 60x60x60(21600).

21600 Worlds to REDUCE lag? No.

I'm not entirely sure I understand what you are trying to say, but how does simulating every possible orientation simultaneously reduce lag?

No. That would not work. Call me a liar if you want.

Though he does have a point. Lag = entities^2

I said that amount of worlds so I dont have to count a lot.You could change the amount to something like ... I dont know 18x18x18 which is 5832 (wait thats too much) 10x10x10 (1000) or even if that is too much 5x5x5 which is 125.I didnt say you necessarily need "x" number of world but it was just a suggestion which could be tweaked.All this would work only if a lot of ships in the same (or even different) place didnt lag out the game(which I dont know because I dont know how you have coded it ).Oh and 2000 ship fighting with 30000 missiles everywhere,thats 32000 entities that the server cant handle if you dont implement something like this or even better.

fr0stbyte124 wrote:

I'm not entirely sure I understand what you are trying to say, but how does simulating every possible orientation simultaneously reduce lag?

What!?! I ...thats not what I said
when an entity is created it checks its "x" "y" "z" ("x" being the direction the entity is moving in) and transfers that entity from the ships world to a world where youve coded so every entity thats ... lets say tagged missile(I dont even know if you can tag things which java but its just an example) will go into that world but only when certain entity coordinates are met it sends that entity to the specific world.The lesser worlds you have for entities the more entitys in a world and the more worlds the less entitys in a world.For example we have 30000 entities and 125 world thats 75 coordinates the world has to check but luckily it hapens only ones when the entity appears there could be lag depending on how you code it.Ow and thats about 240 entitys in a world which is actually fine.Also the 18x18x18 Im writing, your probably thinking what si that.Because there are 18 different degrees that the world has to check and three because there are "x" "y" and "z".This actually would work just fine but that is if you understand what Im talking(writing) if not then its only a waste of time for me and you.

I think I might get what you are saying. You want to simulate a cluster of entities as being stationary relative to one another, and you are reducing their angular resolution to keep the max possible clusters down.

Is that right?

After reading your answer tree times and I finaly understood it (and used google translator for cluster because I didnt know it meant a group and what is angular resolution?).Yes thats about what Im trying to say(actually I think thats exactly what Im saying).

(Angular resolution example: with 60 bins, the minute hand on a clock has greater angular resolution than the hour hand, which only has 12 bins).

But I think you may have some misconceptions about where the performance bottlenecks come from in the case of entity physics.

On the client it is collisions, or more specifically, entity access. Hitboxes in Minecraft utilize the traditional Java philosophy of compartmentalization. For the sake of readability and reusability, the interactions between objects are reduced to the most general form possible, utilizing many method calls over multiple classes and deliberate ignorance of a priori knowledge of its usage, so as to be a good fit for future implementation. That might be fine in a typical Windows application, where nothing is happening most of the time, but in Minecraft it's a huge flaw.
In a chunk, entity references are stored in an array of lists. Each list covers a 16x16x16 section of the chunk, and contains a linear set of all the entities who's hitboxes are at least partially contained. This is a decent compromise between speed and size for regular situations when there aren't may entities in a single area, but take a situation like tons of XP orbs, or the Zeppelin mod, or missile spam, and you can see what happens. To determine collision, every local entity must iterate through the entire list do see if anything is colliding, which is an O(N²) process, and happens every single tick. If we want this to have a reasonable performance, we can't rely on standard entity collision to get the job done. We can't even store it in the same data structure. But more on that in a moment.

On the server side, while it still has the same access time issues (slightly reduced because it doesn't need to get their hitboxes for rendering purposes), the greater issue is network protocol...
Actually, this is going to get pretty complicated, even by my standards, and I'm way too tired to talk about it right now. I'll finish this tomorrow.

Spoiler for those who can't wait: the solution to missile spam uses precalculated bezier curves, iterative collision refinement (page 4, I think, though I don't get into it very much there) and client-side prediction to free up both the bandwidth consumption and collision checks.

I see where I went wrong.From my experience in minecraft a lot of entities cause lag.I havent checked the code (sence its in java I probably wouldnt have understood much of it) so I thought that minecraft couldnt handle lots of entities.I didnt know that the hitboxes and other stuff was made very bad and it basically worked even worse so the best and only solution is to redo the code(I was thinking of cleaning the code anyway to something even more simplistic that actually works but as always Im too lazy ).Also cant wait for the new modding API maybe Ill finaly make something, dont know You probably cant wait for it so you dont have to redo everything every time minecraft updates.Also frostbyte you should update.

PS.Ow I allmost forgot in the end this would actually work but it will reduce lag only for the entities that are in space and not touching any of the ships or anything like that.So it isnt worth the trouble.

Keon wrote:

No. That would not work. Call me a liar if you want.

Liar. Sorry couldnt resist.It actually will work but like I allready sad its not worth it.

I see what you mean now. Instead of a world, though, I would make an entity. And this would most likely only work for something that fires many missiles at a time, such as a flak cannon. But it would be interesting to see how you could do it. They would have to be fired at the same direction and fairly close to each other. The entity can hold a array of entities, the missiles, and when it collides or gets close to a collision, it can spawn its missiles back in.

tl;dr: Entities not worlds, but otherwise good idea.

I didnt know that it could work with entities.That would be better but if its my way you could even build the entities same way you can ships.Plus The way I was thinking it they could be in diferent ends in the universe and not close to each other but then again yours wont use worlds but entities that allready exist so it has its downsides and upsides.
But thats not waht Im posting this for.I allready said it wont work as good as I amagened it (Keon your way actually gave me hope that this could work).I had better ideas before this one but I forgot to add them (I forget a lot so... ).You could make so that a user can from his singleplayer world go to a server but only with ships.Well your telling me whats the point when noone else cant go there.Exaclty you could use it as a safe zone.Someone mentioned on Futurecraft Empire that there will be on servers a safe planet on which they can regroup and remase after a defeat.Why dont you make it so that it works for singleplayer as well.Yesterday I remembered about the thing about no server needed invite friend in singleplayer after watching the xbox trailer and they actually released that feature for testing on the next day. My point is friend make a massive ship and fighters and lunch into space(some random server) to fight.
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).
I have other ideas because like I said on the minecraft forum I wanted to make(or ask someone to make it for for me because Im lazy)a much bigger mod that did have things like this.Actually I just remmembered that I had a better multiplayer idea but its been a long time soo I dont remmember it.If I remmember something Ill tell you and if its good you can implemet it.

Edit:Never type posts and then go do something else and then finish it other wise this is going to happen.I was too sleepy so in the last 3 sentences theres no sense in them, but I fixed them so ...

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?