Modular Ship development

Great! Thank you, jedidia! :cheers:

Well, there is no priority, I think, but you can start with models of engines and trusses. Can you make models of real engines? I thought about using parts of meshes from existing addons, but I don't know if their authors will agree, or I will have to contact too many people.

We need many types of trusses. The variety of trusses defines how flexible will be the ship's configuration. Don't forget that they must have limited dimensions. I suggest to use the size of XR5 cargo bay as a limit for all modules. Attachment points must be well distinguishable.

I don't know almost anything about texturing. Please, suggest, what size all textures must have.
 
It works! This is awesome. If I might make some suggestions now: There should be a way to integrate docking modules, it should be UMMU compatible, and integrating Hab modules should increase the crew capacity.

If you need code/meshes for anything, let me know.

Also, about the Universal Cargo Deck not being compatible with the XR5 due to the COG issue, fear not! That's why I created this: [ame="http://www.orbithangar.com/searchid.php?ID=3312"]Universal Cargo Deck carrier for the XR5[/ame]
 
Define "real engines". Pretty much everything I do is based on real concepts. If you mean "existing engines" like e.g. The nerva, sure, no problem.

btw, here's a pic of that Vasimir I have lying around. interested?



Note that this is an engine that needs a seperate reactor... that one does not exist yet.

Plus, define trusses. you mean different looking trusses or trusses with different attachement points?
 
Under "real engines" I implied existing engines that are currently in use or will be there in the nearest future. But I didn't say that this is requirement. It will be interesting to use different types of engines, nuclear too.

Your model of VASIMR looks great! I like it very much. :speakcool:

Plus, define trusses. you mean different looking trusses or trusses with different attachement points?
I mean trusses with different positions of attachment points. In general, there are no strict rules. Make them as you think they should be.
 
It should be UMMU compatible, and integrating Hab modules should increase the crew capacity.

I already planned to use UMMU, although I don't know yet how difficult it will be. The idea of increasing the crew capacity with hab modules sounds promising. Good suggestion!
 
In general, I think we need some variables to manage the whole construction. As I said, the Vasimir (others too, e.g. the Ion drive) consume power, while others like the Nerva actually give Power, so some will need a reactor to run while others will not. Also, some engines need radiators (while others blow their heat away with the exhaust flame), and the reactors need radiators. We can either attach the radiators directly to the coresponding modules (like my Vasimir), or we can give them a heat-property and make seperate radiator modules. The first of course would be easier...

Also, some engines (majorly Vasimir and an advanced design of the Nerva) allow switching "gears", i.e. trading Isp for thrust. This will need some rework of the engine code I think.

apart from this, a billion cool things come to mind, but I'll keep it at the bare bones for now.
 
Can we make a reactor as a part of one engine module? If an engine, a reactor and radiators together will have dimensions in defined limit, they must be made as a single module, I think, because they can't be used independently and user will have to add each of them anyway. The other question is a damage simulation in a case of malfunction of radiators, for example. But it could be done with an engine, a reactor and radiators in a single module.

As for trading Isp for thrust and back, it seems that this will require little coding and can be done easily.
 
I agree with vchamp.

Consider that we're allready having to go through the trouble of choosing which engines to use, how many for Thrust vs Weight - how many cargo modules we have - where to attach them - and all sorts of cool things.

So making engine decisions easier would be a big help. Make the Engine modules a self contained module - providing it's own power, heat dissapation and all that.

However, the fuel source should be different modules - just use orbiter's generic fuel. Let us pilots worry about how realistic it is to use the same fuel source for Rocket engines and Vasimr engines.

That gives us maximum flexibility... if we want to make a ship that has a Vasimr for long trips as well as a Liquid Rocket for short bursts of power hooked to the same fuel tank - so be it.
 
if we want to make a ship that has a Vasimr for long trips as well as a Liquid Rocket for short bursts of power hooked to the same fuel tank - so be it.
What fuel does Vasimr use? LH2? If yes, then it can use tank with LOX and LH2, but fuel consumption won't be correct, because LOX won't be consumed. Probably the best decision would be to separate tanks for LOX and LH2, but making propellant resources will be too complex in this case. I intend to leave the things like they are now and use the separate tank with LH2 for Vasimr.

I have made habitation centrifuge, which consists of 5 parts. With this I have worked out how to include different modules in one animation and how to make continuous animations. It was a big fun, I must say. :lol: Developing addons for Orbiter can give the same joy, as playing it.

I would like to upload the new version, but I must find separate place for it, where the latest version always will be stored, instead of attaching files to the thread. It would be the best to have a kind of version control system where uncompressed files would be placed separately. This will eliminate the need of uploading and downloading the whole package, when only some files were changed. Does anybody know what is the best way to do this?

Thanks.
 
I'd say a cvs would be the best way to go, but don't ask me how to set one up, I have no Idea... :lol:

Thrusters and their reactors go together, including their radiators. Allright, that should keep it all clean and managable. Only problem I see is that it gets bigger that way, but I think there will be few cases that don't fit into the XR 5.

great to hear centrifuges work! :)

I had a thought about the trusses... We'd achieve a much higher flexibility if we just made trusses with a front and a rear end, in all possible lenghts, and then throw in different adapter blocks that contain attachement points in various positions, from which the next trusses can be extended. A system like that would have a much higher (virtually unlimited) flexibility, BUT: It would get more tedious, since there is more stuff you got to clamp together. for example, instead of installing a 1to3 truss, we would now have to install a 1to3 block, plus three trusses, plus three blocks on the end of those trusses (1to1-90 degrees or something like that).

So, we'll be trading handling for flexibility. Tell me which one you like better. of course it's possible to have both options, like norm trusses for the most stuff and others the player can stuff together himself for some extravagancias, but it'll be double work for the modeler, which currently seems to be me... :dry: however, trusses are not too much work, so It should not be too much hassle to provide models for both systems. To ask the Molden-question: "What do you want?" :)
 
I think there are some people around who can help you setting up a Subversion (newer version of CVS) repository correctly. The best practice is maybe quickly explained, but I feel even I have not yet understood it well. :sorry:
 
What about SourceForge.net? Does it allow to simply make a files repository without version control for the first time? How convenient their system is? If someone had an experience with SourceForge, help, please.

Jedidia, I like the idea with adapters. We certainly must make a use of them. The only negative side of it is, as you said, the bigger number of modules. In general, it is better to include as many small modules into one big as we can (of course if they have the same type). A big number of modules increases the size of scenario file, where information about each module is stored. But adapters are necessary anyway.
 
Hmmm, I don't quite see the problem with having a bigger scenario file. First, people will not load all modules at once into a scenario. There's only so much that goes into the Cargo Bay of an XR 5. And when they get attached to the ship, they aren't independant modules anymore, if I understood that correctly. So, in a worst case scenario we have a load of 40 trusses and adapters flown up. It's quite a bit, and the scn file will grow a bit, but that should not impact on performance too much, or does it? I don't know, I'm not too familiar with that kind of stuff...

Anyways, doing models for both norm trusses and special trusses/adapters sounds best to me too... And after thinking it all over, it really should not be so much more work, since these are very basic geometries and take only a minute or two to texture (and in most cases even less to model... :lol:).

I'll be a bit preocupied over the weekend with an extreme-metal festival going on, but It won't be too long before I can deliver some thirst truss designs...
 
Wow, are you a fun of extreme metal?! Me too, thrash metal in particular is my passion. But this is a theme for a private conversation or a separate thread. :speakcool:

I don't think that many modules will have an impact on performance. The big vessel's entry in scenario file is not a problem. But I would prefer to keep it in a reasonable size.
 
Power Metal anyone? *seekscover*
 
Thrash is nice, I'm more into melodic death, as well as symphonic AND progressive black (it's an unusual combination, I know). And yes, I do enjoy a bit of powermetal every now and then, but it's got to be a bit complexer than the standard dum-pa-dum-pa-dum-pa. I like Dream Theater, allthough calling DT PowrMetal is a long shot... But yeah... OT :lol:

I had a pretty specific truss-design in mind, and just to go sure I checked some resources, and what do I find? exactly what I had in mind. What do you think about these?

http://www.turbosquid.com/FullPreview/Index.cfm/ID/243155/

They're free for use in anything (even in commercial products if I'm not terribly mistaken...) and they're free for download. If you like them I can take them as a basis for our trusses. would save me 2 hours of work to make a basic truss-stage myself. If you don't like them, tell me what you like, because that's pretty exactly what I would have done... so it saves me 2 hours of work anyways :lol:

don't let the dimensions bother you, scaling is an easy thing.
 
I think this trusses will suit well for a main backbone of a ship. Transversal branches should be thiner, or a vessel will look too heavy otherwise. And I would like to use trusses with solid covering too. I hope, you understand what I have in mind, because unfortunately my limited knowledge of English doesn't help me to express my thoughts clearly.
 
solid, then. hmmm... I can distantly imagine something in those lines. we have two possibilties: you look for a pic on the net that looks like what you want...

Or there's a faint possibility that I know your mother tongue. Very faint though. I know english, german and any south-slavic tongues plus a bit of french... but less french than you know english in any case :lol:

maybe something in these lines?

http://www.konstruieren.de/CAD___VIDEOS/strebe250.jpg

or probably more like a modern ships mast? (without the spants and stuff, of course...)

http://www.momo-sailing.ch/seiten/berichte/bilder/03.04/HP_bootsvergleich/03.04_momo_mast.jpg
 
What about SourceForge.net? Does it allow to simply make a files repository without version control for the first time? How convenient their system is? If someone had an experience with SourceForge, help, please.

SourceForge.net is OK, just a little cumbersome if it comes to user interface, IMHO. I use it for 2 projects (Orbiter.NET and OMP) with SVN version control and TortoiseSVN as windows client.

The code and file repository there is rock-solid. You'll get shell-access there, too, which was the primary reason for me to use it.

As project admin, you can enable/disable the various features (Tracker, Versioning (CVS and/or SVN), Wiki, Forum, Taskmanagment, Documentmanager) and give developer-rights to fellow SourceForge-members.
File releases works by means of FTP uploads and HTTP-communication (simple webforms). Versioning works by means of appropriate client-side software and HTTPS-communication (done by the client). Shell access is possible via SSH - this way you can even create simple web pages (if you're masochistic and use VIM :lol: ). Of course SCP-upload of web pages is possible, too.

One drawback is the registration... You'll have to submit a registration form and have to wait until it is approved. Approval is done by humans, so it can last typically 2-3 days (OMP even took 2 weeks), if you've described your project properly.
Another drawback is the license restriction: you have to use an open-source license in order to host a project there.

One small advise: forget easy ways like file-repository-only distribution, start with version control immediately. I use version control for almost everything these days, mostly SVN and Mercurial. And I never regretted it.

regards,
Face
 
What fuel does Vasimr use? LH2? If yes, then it can use tank with LOX and LH2, but fuel consumption won't be correct, because LOX won't be consumed. Probably the best decision would be to separate tanks for LOX and LH2, but making propellant resources will be too complex in this case. I intend to leave the things like they are now and use the separate tank with LH2 for Vasimr.

I have made habitation centrifuge, which consists of 5 parts. With this I have worked out how to include different modules in one animation and how to make continuous animations. It was a big fun, I must say. :lol: Developing addons for Orbiter can give the same joy, as playing it.

I would like to upload the new version, but I must find separate place for it, where the latest version always will be stored, instead of attaching files to the thread. It would be the best to have a kind of version control system where uncompressed files would be placed separately. This will eliminate the need of uploading and downloading the whole package, when only some files were changed. Does anybody know what is the best way to do this?

Thanks.

The Vasimr and Liquid fuel rockets use vastly different fuel (I think the Vasimr uses Xenon?). But what I'm suggesting is that you don't worry about that.

Give us fuel tanks that just has "fuel" (magic fuel) and let all engines use the magic fuel. Your ion style engines will be very high efficiency - low thrust - kind of things, and the rockets will be low efficicency - high thrust kind of things - both attached to the same fuel tank(s).

Realism in this area is nice, but too much required micromanaging of building the ship, assigning the right tanks and power sources and radiators and all that to the right engines... just to have the thing not be able to leave earth orbit (because it turns out our ship design sucked) would be too frustrating to reach the audience that I feel is interested in this project.

I envision this work process for your typical user:
Planning a ship (I want a ship that can get to Jupiter with 5 crew, and have a DeltaGlider 4 in tow for moon exploration)

Building a prototype through the scenario editor (I place these modules here, and this tank here, and these engines here)

Trying the ship out (I use MFD to plot a course to Jupiter... hmm not quite)

Adjusting the prototype (I change this and this in the scenario)

Final Flight test (To Jupiter with IMFD, Yay!)

Then the more die hard would use their favorite realistic earth to orbit delivery system to hand build the ship from the modules needed. (I use Energy and fly up a load of trusses, then Engines, then the Command module, then the Fuel tanks, then the Crew all go up in a DeltaGlider4)

...

I hope the above user story helps your disign of this project! :)
 
Back
Top