Project Interplanetary modular spacecraft

[Lydia]

Actually i dont have time for that forget that

 

[PhantomCruiser]

Which ones have you done already? I have tomorrow off work and can maybe knock them out quickly.

 

[Izack]

The Habitat, and Centrifuge modules, with some done on the SPDM. The problem is though, Piper's docking ports are in funky locations and some need to be corrected.

 

[PeterRoss]

I've got Piper's ExerciseRecreationModule and RadiatorTrusses finished.

 

[xx_mortekai_xx]

Do you still need people for 3d modeling? I use Sketchup, but I have created quite a few things, mostly for cars (I was using it originally for vehicle design visualization). I suck at textures, however, and have never done anything for orbiter.

 

[jedidia]

There's nothing inherently different from modeling for Orbiter or for anything else, except maybe that you have to align everything with the Z-axis. You would have to texture your models, though. Since we're making relatively small parts, texturing shouldn't be too difficult however (you won't have too extensive UV-maps).

 

[Hurricane]

If I join, do I get the 'Addon Dev.' badge?
Anyway, count me in, apart from the part that I'm not totally experienced with texturing, and I don't know how to make UV maps.

Just tell me what to do and I'll work on it

 

[xx_mortekai_xx]

There's nothing inherently different from modeling for Orbiter or for anything else, except maybe that you have to align everything with the Z-axis. You would have to texture your models, though. Since we're making relatively small parts, texturing shouldn't be too difficult however (you won't have too extensive UV-maps).

I pick up pretty much everything quickly, and I can model, so whatever you need. Send me a list and we can go from there.

 

[jedidia]

If I join, do I get the 'Addon Dev.' badge?

I'm not giving them out, but as far as I understand the rules, that should be possible, yes.

and I don't know how to make UV maps.

That's one thing you'd have to learn. To be honest, I have no Idea how it works in Blender, but I know that blender is quite capable in that area, if somewhat unwieldy. But creating UV maps is not that difficult for the rather small single parts you're going to make.

Anyways, to both of you, you'll get an invite to the development group. Everything else will be explained there. Read the welcome thread, have a last thought of wheather or not you want to go through with it, and then come to the modeling thread and make a claim.

 

[jedidia]

The code of IMS reached a point where we're practically at the level I promised initially, except for a few bugs which I'm sure are still hiding here and there. Modelling isn't quite this far yet, but with the additional modelers that joined up we should get there. I'll use the remaining time to put in some additional complexity, but don't expect any thourough hard-physics simulation. I'll probably get an approximation of a power and a wasteheat management in, but nothing too complicated.

 

[Izack]

Is there a 'maximum size' constraint in module development? I'd like to get my vessel to manufacture/store IMS components, but I'm not sure how large the bay should be.

 

[jedidia]

Is there a 'maximum size' constraint in module development? I'd like to get my vessel to manufacture/store IMS components, but I'm not sure how large the bay should be.

Well, the maximum size constraint is the biggest currently available launch vehicle, which would be the XR5. But many modules fit into STS, and the pre-existing ones for which we write configs are mostly designed to fit STS anyways.

I think the longest module we currently have in native is some 20m (a truss), the new command modules are consciously designed to fit STS, and then there's some stuff from earlier on (the parts of the centrifuge) which I designed so retarded that no sane man would transport them that way.
But, there's a centrifuge in SBB4 which will be made compatible, so you don't neccesarily need to carry my bulky stuff around if you don't want to.

manufacture

Manufacture? now there's an idea...

---------- Post added at 06:52 PM ---------- Previous post was at 05:57 PM ----------

Hmmm, I'm currently pulling some values for average powerconsumption out of my but, and I would like to pull them from somewhere else...

Does anybody have an educated estimate of how many watts your average habitation module (like on the ISS) would probably consume for lighting, ventilation, heat re-distribution and stuff? Note that I'm only looking for upkeep, not additional stuff like crewmembers cooking or listening to music, or advanced life support like oxygen regeneration, those are modeled separately.

I'm currently running with 1 kw, but I have absolutely no idea wheather that is too high or too low. Probably rather on the high side.

 

[Maximusfive]

Will the new modules you're making (command, engine, etc.) be compatible with the XR-5 payload system, or will we have to hackjob it with universal cargo deck??
Also, I see you plan UMMU support, but will it also support UCGO cargos?

Also, my first post!

 

[jedidia]

Will the new modules you're making (command, engine, etc.) be compatible with the XR-5 payload system, or will we have to hackjob it with universal cargo deck??

Well Universal CargoDeck is pretty far from a hackjob, IMHO, even with the XR5.

Making the modules XR5 carriable by default wouldn't be a big deal, but most of them are not exactly rectangular, and the size of an XR5 cargo-slot was certainly not a consideration in designing them, so you'd waste a lot of space. Not sure if that's worth the effort.

but will it also support UCGO cargos?

Again, I'm not sure if it's worth the effort. Main consideration is the limited flexibility of UCGO and the upper cargo limit. I can't do more than 40 cargos, and it'll be kind of tricky to prevent people from trying to add more than that (you can build the ship yourself, after all) and then calling it a Bug when their cargo starts disapearing...

What I am thinking about is an own payload system XR5 style, which would mean that you could attach as many UCGO cargo cradles as you'd like... But I'm almost sure this won't make it into the release, unfortunately. I had to set priorities, and those are currently on complexity for the actual building process.

 

[jedidia]

I felt like it might be time to inform the broader public about the project progress, lest people think that it went down the memory hole... again.

The add-on will be released somewhat behind schedule, which has mostly to do with the coder becoming a double father pretty unexpected. It was the original plan to release before my kids scream to life, since I knew that I'll only have limited time afterwards, but my two sons managed to completely annihilate that plan (which I'm sure is only the first of many plans that will fall prey to their willfulness... :lol.

I have to say though that under the circumstances, the project is still advancing pretty well. A lot of features have been added over the last month, and it looks like the add-on is almost bug-free in its current iteration.

Of course it's not quite feature complete yet, so there's still a lot of time for bugs to creep back in, which means that we're by no means finished yet.

I expect to wrap up the heat management this week, which got a bit more involved than initially planed, but it's about the last major feature to go in.

After that it's making the whole thing more accessible (read: making the instrument panel actually do something), implementing failure modes, and writing up a whole lot of docummentation (ugh, I'm so not looking forward to that part!).

All in all, I'd say chances are still very good that we'll get there before summer.

 

[lassombra]

Can possibly help

I'd like to offer any help I can. I'm a reasonably well versed c++ programmer, with a little (read very little) experience with the orbiter API (worked on project Apollo for a bit). Feel free to PM me or reply if you think I could be helpful even at this late stage.

Second, I'd like to offer a feature suggestion/request. I know that adding a feature at this stage of the game is *highly* unlikely, but perhaps I could add it later also for a second version, I don't know, all I have is the idea. A landing bay of sorts would be a nice addition (config controllable perhaps) that would use collision detection with compatible attach points against a "landing" plane and upon collision within reasonable relative speeds would create a new attach point and "grab" the landing craft (think Battlestars and landing vipers. The entire deck can be a grabbing point). This would create the ability to "assemble" battlestars or similar craft and "attach" smaller "local" craft, even perhaps deltagliders and the xr fleet could be detected and "caught" with this mechanism.

This could be used to create larger more interesting interstellar ships, and using actual landing strips for landing craft, maybe even switching to attaching these "landers" to an internal hangar bay slot for travel, then they can be "prepped for launch" which would connect them to a docking bay for eva transfer, and then attached to a launch tube, or to the front end of the landing bay in preparation for launching. A simple MFD interface to the parent ship would allow the pilot to "disengage" the clamping or gravity or whatever which would then allow the ship to launch on it's own power, or if placed in a launch tube type structure, it could be accelerated away from the ship by the ships forces.

This idea is *inspired* by Battlestar Galactica, but is more aimed at the idea of long range vessels having more features and capability than just docking support craft. Why not provide a *short* landing strip and launch tubes? For a larger ship, I think that it would allow for more complex logistics operations as more ships could "arrive" in a short window if they have the flexibility of just landing on board. Obviously this would only support very small ships (up to xr2 perhaps?).

 

[jedidia]

I'd like to offer any help I can. I'm a reasonably well versed c++ programmer, with a little (read very little) experience with the orbiter API (worked on project Apollo for a bit). Feel free to PM me or reply if you think I could be helpful even at this late stage.

Thanks for the offer. The problem is that having several coders in the current stage would most probably create more work for me than it takes away (setting up repository, documenting code etc). Most of the code was written by vchamp back in 2008, and by now I know it well enough, but it would still be tricky to get another coder in at this stage.

A landing bay of sorts would be a nice addition

Well, there's docking ports. Code support that allows to make a closable landing bay with several docking ports is already there, so all that's needed is a mesh and a config. Since modeling time is pretty much at a premium with the two modelers we have left we have to concentrate on realistic current- or near future tech, so a big hangar bay is not on the list, but there's nothing preventing anyone from making one once the add-on is released.

As for a landing strip, that would take quite some coding time and is utterly unrealistic, so it won't happen. SourceCode will be open to public once the add-on is out, though, so you'll be free to try your hands at it. Carrying support craft in and of itself is no problem at all, you'll just have to use docking ports.

 

[francisdrake]

First of all, thanks for undertaking this project! It sounds promising and has the ability to add another kind of playability to orbiter by letting the users build up their own interplanetary vessel.

One questing on the kind of modularity: Will the modules be docked together, or joined using other methods? Reason for asking is, that maneuvering a docked stack is very tedious in Orbiter. The autonav does not properly consider the added masses and moments of inertia. It would be better if there is a way to combine the modules into one 'logical' vessel. 'Logical' here means the programming logic, that is the vessel properties as used in the Orbiter SDK.

 

[PeterRoss]

IMS makes multimodular construction a single vessel consisting of modules' meshes and sharing their properties, to put it simple. If you place your RCS thrusters correctly (and main engine too) and supply them with appropriate fuel and get some electricity power and properly balance thermodynamics through heaters and radiators and won't forget to have enough food for your UMMUs and... oh, I hope it wasn't secret till release date :shifty: Anyway, autopilots are working fine with IMS vessels as much as all kinds of MFDs (except of Aerobrake I guess - don't see how it can work with the current state of the project - though maybe I should try an see it myself).

 

[jedidia]

One questing on the kind of modularity: Will the modules be docked together, or joined using other methods?

The modules will be merged to form a single vessel. That's the whole point of the add-on, really.

oh, I hope it wasn't secret till release date

No idea, go ask in marketing. Oh wait, I didn't put anyone in charge of marketing. The Guys who tried to teach me project leadership skills won't be too happy, I guess... :lol: