Oh wow, that is a lot more detailed than I expected!
Once I have coarsely scaled everything, I could either keep on coding (what I would prefer) or produce a first mesh (which I am really bad at)
By all means, keep on coding. We can make do with the tin can for a while, and if we have something cool, maybe somebody more talented at modelling than either of us gets interested in taking it off our hands...
External modules around the crew section, that can be replaced by refueled modules quickly and without danger of propellant leaks
Interesting concept. I'd say it's probably best to not have them be
actually detachable in a first iteration.
Do we want to follow modern visual conventions? I think for gamification and simplicity, some older science fiction references could be smarter, like 2001 or Moonbase Alpha
Yeah, something more recognisable might be a better choice, I agree.
If the visual design for the interiour is selected, we could need a MFD framework to define a common UI visual language, so all MFDs and other displays in the spacecraft are uniform.
Hmmmyeah, I'm certainly the wrong person to discuss visual language with... somebody might be interested in making some drafts. Codewise I guess we should try to go for something that can visually be easily changed.
Again, if we're going with touchscreen interfaces, my UI-framework might serve well. It's externally themeable and layoutable, and can even switch themes at runtime (not layouts, though). The customisation options aren't
that varied, but some things can be done. I guess I could start ripping it out of IMS2 and putting it into the hauler for a quick proof of concept, though it's a bit iffy without much to control yet. I guess I could start implementing actual orbiter MFD support, because that's still missing.
Oh, and it's easier to work with for prototyping than a raw panel (though not as easy as I'd like), so if we decide to tear it all out later it's not such a great loss either. In any case, even if we want physical switches, it should still serve well for any text displays in the panel (graphs not so much, though a sketchpad element would be easy enough to add...).
Right now I planned without artificial gravity, keeping the time in space of the crew limited to about 3 months, is that OK?
3 Months is plenty. I'd kind of expect such a vessel to be necessary if there's already some serious orbital activity, and probably some places that have artificial gravity to recuperate. Or the crew can just tkae a shuttle down to the moon for shore leave...
Other vehicles, bases, buildings in the world - they would make sense, but I haven't really thought about them yet.
Yeah, let's not think about that just yet....
OMmu support? It is far from ready for production right now, but its open source.
I was thinking about it these days, and it would certainly be somewhere on the horizon, but I wouldn't give it much priority until we have most of the vessel functional and presentable. I've worked with UMMU, if OMMU works in a similar way it shouldn't be a problem to add it later.
Skin support - I think it would be mandatory if we go fishing in the XR waters, but I have no idea yet how to implement it.
I do. Not that much to it, just load in a texture manually and associate it with the mesh behind the scenes. No big deal, can be added whenever we have a mesh and more than one texture.
So, let's see...
Loading and Saving the scenario is still open, payload handling would be a point we really need.
Scenario saving is simple enough with Oparse in there as long as the data that goes into the scenario is neatly encapsulated. I guess I could make some example.
But payload... huh. There's a discussion to be had about how we want to handle payloads first of all. The natural choice are attachment points, they're basically made for that.
But: Scenario editor does
not allow to control attachment points, which means it's quite a pain to actually attach payloads without also implementing some payload manager. Sure, you can grab a dragonfly and dock them all there manually, or do so with an RMS, but most people are not so much into that (especially since the dragonfly doesn't quite work in Orbiter2016). Being able to relatively quickly attach a payload and get going is crucial I think.
So either we use dockports to attach payloads, or we have additional work to make the thing usable. I'd suggest going for dockports first, and then maybe changing that in a later iteration if we don't like it. Dockports and Attachment points have a very similar API, so it wouldn't be too hard to switch.
That would still leave the question open of how payloads are handled simulation-wise. I assume IRL you'd position the payload and then close some latching or grabbing mechanism to secure them, otherwise they fly off when there's more than a certain acceleration...