Programmer

Here is the link to the person's devlog who went away, Ectrimble. You will have to go to some later pages for server stuff, at the start he just does alloys, weapons and things like that.Click!

As for the ships, you will have to ask Fr0st.

Another thing I was thinking, regarding "planets", is the concept of world wrapping.

I've done some searching and found a few people discussing it, but noone implementing it.

The idea would be similar to "Asteroids", you go off one side, you come on the other.
No attempts at making the surface actually connect, just some modifications with the chunkloader to skip from 64 back to modulus any coordinate by 64 (for example, to make a 64x64 chunk planet).

Not something I've tried yet, but would seem to be an interesting way to make the planets feel "small" and limit their resources.

We are planning on doing something like that. A map is a square on the ground, but when we are high above, we take that map, wrap it around into a cylinder, deform it into a sphere, and then add some ice overlay image at the top and bottom to hide the seams. The ice is just my idea, but who knows. The real problem will be the seam.

I'm not really sure about anything with the ships, I'm just making an educated guess from what frostbyte said

he's the one to talk to about it

EDIT: although, yeah, I'm pretty sure they mean the jetpack thing you said

I understand most of what he says, just I can't find it when I really need it, such as now.

also that video was of a ship that was hard coded in, you couldn't really use it, as I understand, it was proof you could have massively huge spaceships without melting PCs

I assume the zeppelin logic could be used to create a dynamic version?

To what extent do you guys understand how zeppelin works?

I'm not a coder, but I know frostbyte wanted to do something different than the zeppelin mod, I think

I think the main difference is that the ships need to be interactable, you can still open doors, still place blocks, flick redstone, etc.

The way zeppelin works is to build a model based on the blocks available, but the algorithm used by zeppelin to work out which blocks are part of the zeppelin, and which aren't, is the part that would be useful to us. Whether we are using it to work out which bricks to build our new floating chunk/world with, or what to build our complex entity out of (which as I understand, is what zeppelin mod does with it)

alright, well, that seems like it would be useful

Holy crap I was away for a couple hours and you guys have already got poor Cascaid turned completely around.

Let's see...

First of all, concurrent worlds is not a separate dimension, but rather a new framework which does away with the concept of separate world dimensions. In its place, concurrent worlds allows multiple worlds to interact within the same virtual space. Ship worlds are an implementation of a movable finite world. The way it works from a global perspective is that worlds are nested within one another. The top layer is space, encapsulating planets and satellites, and ships can be encapsulated within any layer. Then you could have something like doors or lifts (which are also ship worlds) mounted within a ship. The global virtual position of each entity is calculated by nesting the transformation functions for each nested world, but when dealing with local interactions, you don't need to do the global calculations.

You are right to think that this is overly complicated simply for representing ships. My reasoning behind it, though, is to easily facilitate various additional functionality for things like transitioning from one world space to another, for instance entering atmosphere or traveling through a warp gate. Each of those could be done on their own, but concurrent worlds will allow it to be done natively, which I think is beneficial in the long run.

The zeppelin mod does use a fake world for storing blocks and executing ticks, but the physical representation is done with entities, which is the source of most of its performance issues. We would be doing the world part, but would have at most one entity per ship. If you are interested, Blakmajik gave me access to his svn, so I can send you a copy of the current source if you are curious as to how it works (though I will say our respective strategies are mostly incompatible).

My youtube ship demo is a working ship entity, but does not have block interaction and is a reflection of a space in the current world, rather than being its own world. A concurrent world strategy will be much more robust and efficiently handled, able to be rendered and interacted with as literal terrain.

----------------------------------
World wrapping shouldn't be too hard. In the region surrounding the seams you just have to average out the noise functions and it should look natural. The tricky part will be making the deformation look plausible at varying distances.


---------------------------------
As far as what Ectrimble got done, once you get access to the dev area, you can see for yourself. I'm not sure we have any of the source, but his writings are there. At this point it was mostly just experiments with communication rather than actually building a proper database architecture.

Sorry! D:

I was just guessing

Hey Frost,

Having a look at the Zeppelin code would be great, especially to take a look at the algorithm for detecting the bounds of a ship.

The part that worries me about the concurrent worlds is quite the extent that the core engine would need to be modified, and the problems that would then arise with each Minecraft Update that comes out. I am not saying it is impossible, but I am just wondering if it is actually feasible in a reasonable time frame.
You mention that the Zeppelin mod's use of Entities is it's bottleneck, what is preventing them from using fewer entity, as you plan to do? Or is the intention that the outside of a ship consists of only standard cuboid blocks, and therefore is much simpler to render? With this implementation, is there any such ability to provide dynamic doors, such as shuttle bays, which seamlessly link into the corridors and then bridge of the ship?
What is the benefit of multiple worlds, to expanding the current world, raising the height limit, and adding floating, rotateable chunks?

I'm not intending to criticise anything here at all, just trying to play catch up and work out where we're at, and under what constraints/goals =0)
You mentioned that you have been focusing on the culling algorithms so far, have you managed any lee-way with the worlds yet?

I'm getting a few of my own questions answered from just exploring the forum, so sorry for asking anything that is already explained, I'm getting there! =0)

Glad to hear it. Somebody make him at least coder so he can see 51.

I thought you could do that?

CoalMiningAlchemist wrote:

I thought you could do that?

Nope. I think only Shiva can, though our Super Moderators might be able to.

Alright. I'm sufficiently impressed by the good scientist that... I do believe coder is in order.

Welcome to the team, Cascaid, and may your efforts compliment our own, blend, and create an amazing mod. (More of a total conversion, really...)

cascaid wrote:

The part that worries me about the concurrent worlds is quite the extent that the core engine would need to be modified, and the problems that would then arise with each Minecraft Update that comes out. I am not saying it is impossible, but I am just wondering if it is actually feasible in a reasonable time frame.

Honestly, I'm not sure this is the right way to go. I was pretty set on it because the whole native interface for multi-world interaction is really attractive, but on the other hand it is stalling the project. Maybe going back to the proxy theory isn't such a bad deal, though I would certainly prefer concurrent worlds.

Quote :

You mention that the Zeppelin mod's use of Entities is it's bottleneck, what is preventing them from using fewer entity, as you plan to do? Or is the intention that the outside of a ship consists of only standard cuboid blocks, and therefore is much simpler to render? With this implementation, is there any such ability to provide dynamic doors, such as shuttle bays, which seamlessly link into the corridors and then bridge of the ship?
What is the benefit of multiple worlds, to expanding the current world, raising the height limit, and adding floating, rotatable chunks?

I'm not entirely sure what all you just said, but I think I get the gist of it. The reason Zeppelin uses so many entities is that the implementation has no sense of the whole. All actions, from rendering to rotation and movement to collision, are done on a per-block basis. This is hugely inefficient for a number of reasons, most of which can be traced back to Minecraft not being built to handle large amounts of entity and block interactions at the same time. Futurecraft's strategy is to make Minecraft handle ships identically to terrain, which they are.

Quote :

I'm not intending to criticize anything here at all, just trying to play catch up and work out where we're at, and under what constraints/goals =0)
You mentioned that you have been focusing on the culling algorithms so far, have you managed any lee-way with the worlds yet?

Don't worry about it. Most of the time people just smile and nod or compliment my use of big words, so it's pretty rare I get any sort of constructive feedback.
The culling algorithm was a lukewarm success. It succeeded in its goal of having very low overhead, but wasn't as exclusive at culling as the OpenGL implementation. It seems to win out on weaker computers and lose on more powerful computers, but what it convinced me of is culling alone is not enough to increase the draw distance. That's why I've begun development on a radical new technique for rendering terrain which separates the surface information from the geometry information and will result in a dramatically reduced poly count and storage requirements. I'm several weeks in to that already.

So yeah, I get distracted from the ship world stuff pretty easily, it being simultaneously incredibly intimidating and also unrewarding (for me anyway. I'm sure there are plenty of people who's day I am ruining every time I delay it). What I do have so far is mostly theory and most of that you know already, either from earlier posts or from that big PM I sent you.

Wait...

So, Cascaid is now an official member. However, he/we has/have yet to decide what he is working on?

This post is partially because I want to know, partially because I want to be the last poster on every sub-forum.

At the moment I am just working my way through the Zeppelin source code and the code from Frost's ship demo (found in one of the other threads, is there a more up to date version that would be more suitable?)

I'm happy for you to assign me some stuff to try and work on, or for now I can just bumble along trying to get the code running for myself in 1.2.

A couple of questions regarding the ship demo (I realise this code is not using concurrent worlds, therefore not strictly relevant....) Have you looked at all into integrating with a server, (SMP, not just SSP) and also, in the ship demo, is the ship hard coded (as I read somewhere) or does it build it from terrain as the zeppelin does? (I'm sure I'll work this one out on my own eventually)

Finally, ha, ruined your "last poster" status in this sub-forum!

this I do know, the entire mod is geared towards servers, you will be able to travel between different servers in ships, or so mackeroth has said.

I understand the intent of the mod, I'm just wondering if any work has done with it yet, as obviously this has not yet been done in the Zeppelin mod of the Ship Demo, and is quite essential to getting an initial version running.

What I am wondering, is if it is possible to continue any of the development aside from concurrent worlds, and then add them in at a later point.
If we were to get the mod to a point that: you can build a ship, fly it around, interact with it (in the way that zeppelin mod can not)
Then it would mean other parts of development could start to be integrated.
The power system could be combined, tested, reviewed by alpha testers.
New dimensions could be developed (the moon, mars, etc) implemented as the nether is now, and easily ported to a concurrent world system in the future.
We'd get an idea of how much strain the ships would put on network traffic (assuming a single world version is the baseline, with concurrent worlds possibly increasing this)
Also, work could be started on transferring ships between servers.

My reason for thinking this, is at it's current point, it feels like there's not much that I can do to help.
It feels like the mod is in a waiting state, and I am just wondering if there is any way to get things rolling.
At a risk of using phrases people won't understand, it feels a more agile development method would be suitable here.

As with all my other posts, if I am misunderstanding things or you don't like my suggestions, just ignore me.
I am happy to just be given something to go away and build if you want to keep me quiet

Actually, that's kind of how I feel about it.


the guy who left was working on a mySQL database to handle all of the interserver communication, he might be back at some point, but no one knows (as far as I know)

also, from what I've seen, anyone can work on anything, and it will probably be used, unless frostbyte objects to something in the code, or mackeroth objects to the UI/content stuff



again, that's only from what I've seen, take all of this with a grain pound of salt