Navigation within multi-compartment spacecraft: Analysis and Potential Implementation

[sumghai]

Since the introduction of internal cockpit / crew cabin views and docking in 0.17 and 0.18 respectively, there have been numerous requests for the game to allow the movement of crew between compartments within a collection of docked vessels or space stations. As such, the purpose of this thread is to:

- Examine the current nature of crew movement between compartments in a vessel / station

- Evaluate various proposals for improving the current system

- Discuss specifics regarding implementation, including vessel tree heirarchy, pathfinding and airlocks

Current Known Implementation (0.19 ~ 0.22)

- The stock Clamp-O-Tron series Docking Ports (Jr./Regular/Sr.) allows two or more vessels to be joined into a single controllable entity

- Resources can be transferred between connected modules by Alt + Right-clicking two tanks/resource containers and using the context menu options

- Crew movement between compartments is via Extra-Vehicular Activity (EVA); specifically, a Kerbal needs to get out in a spacesuit and enter another compartment through the latter's own airlock, even if the two compartments are directly adjacent to one another

- Alternatively, the Kerbal Crew Manifest add-on provides an in-game GUI to allow crew transfer between compartments without involving EVA

Issues

- The primary issue is one of inconvenience and lack of realism; real astronauts aboard the Mir and International Space Station (ISS) generally move between internally crew compartments via pressurized tunnels, connecting nodes and docking ports

- Kerbal Crew Manifest is by no means a perfect solution, either:

- Crew transfer between compartments in the same vessel is allowed even if they are separated by parts/assemblies that are technically impossible for a Kerbal to realistically fit through (e.g. hollow and exposed trusses, multiple docking ports attached to a flat bi/tricoupler)

- The GUI lists *all* available crew compartments in the vessel, which occupies a large amount of screen real estate quickly for complex space stations / outposts

Assessment of possible options

First-person navigation

+ User intuitively controls individual Kerbals with standard WASDQE controls as they walk/float between compartments

+ Immersive

+ Allows Kerbals to interact directly with internal props without having to be seated first

+ Allows Kerbals to pass through an otherwise "full" (i.e. all seats occupied) compartment, by simply walking down corridors

+ Allows Kerbals to loiter in compartments that don't necessary have seats (e.g. crew tunnels, six-way docking nodes)

+ Could potentially allow Kerbals to carry objects between compartments

- Users must enter into IVA view and manually control each Kerbal as they move between compartments, which can be tedious if several Kerbals and/or many compartments are involved

- Requires significant rework of both stock and add-on IVAs with appropriate collision meshes

- Requires visual cues as to which internal hatches lead to which compartment; can be problematic if docking ports were placed radially on a fuselage with no corresponding internal hatch

- Rendering the interiors of other compartments through hatch openings may provide this visual cue, but draw distances for very long and linear chains of compartments may be an issue (case in point: the

Star Trek Online

MMO uses snaking corridors in order to keep down the draw distance viewable by players at any one time)

Third-person navigation with cutaway

(Same benefits and problems as above)

+ Can see compartment occupancy / Kerbal locations in relation to the overall layout of the vessel

- Requires complicated culling of exterior models that account for user camera orientation and to fill in gaps between the exterior and interior geometry, which may inaverdently lead to Kerbals having the appearance of walking on thin air / interacting with invisible control panels

Integration of (modified) Kerbal Crew Manifest feature into part context menu

+ Comparatively simple to develop

+ Efficient for managing large numbers of crew over many compartments

+ No change to current IVAs

- Not as "fun" as the prior two options, as the Kerbals are simply "teleported" between available seats

In the interests of efficiency and to save development time, the third option is the best bet.

Implementation

Crew Transfer with Path Validation

For the most part, this would be functionally identical to the Crew Manifest add-on, in that the user selects two compartments and chooses which Kerbals to move where. Instead of a large GUI window listing all available compartments, however, the user Alt + Right-clicks the origin and destination compartments, selects the "Crew Transfer" option to initiate the process.

To address the shortcoming of the Crew Manifest add-on that allows crew transfer through seemingly impassible fuselages/structures, an additional function could be used to determine if the path between the two compartments is actually traversable:

- The function considers the relative locations of the two compartments, and by "tracing" along the tree hierarchy used to build vessels in KSP, attempt to find (the shortest) path between them

- By default, only parts with an INTERNAL{} node defined (i.e. Command Pods and Crew Cabins) or ModuleDockingPort{} are automatically considered traversable; everything else, including fuel tanks and fuselages, should be considered impassable

- Exceptions to the rule can be defined in the part's CFG definition using an optional "crewTraversable = " variable, much like "fuelCrossFeed =":

Example 1: A 2.5m stack battery with crewTraversable = true would override the default behaviour, such that if the battery is along the path that a Kerbal would take while traversing between two compartments, it would allow the crew transfer

Example 2: The stock Clamp-O-Tron Jr. docking port was intended by KSP developers to only allow resource (and not crew) transfer, due to its physical size. As a part with a ModuleDockingPort{} definition, it would normally (and unrealistically) allow crew transfers anyway, so the developers could explicitly enforce crewTraversable = false to prevent this from happening.

If a valid path between the two desired compartments is found, the game opens up a small GUI window listing the Kerbals present in both compartments and controls to perform the transfer:

Fig 1 - Crew transfer dialog GUI mockup

Otherwise, an appropriate error message is displayed - i.e. "Cannot initiate crew transfer! Compartments not connected by crew-accessible segments.")

Crew Transfer and Airlocks

As most are aware, real astronauts don't depressurize their living compartments (and certainly not the entire space station) simply to let one or two crew members out on EVA. This improved crew transfer implementation with pathfinding would allow Kerbals to EVA out of any usable airlock in the vessel, even if the airlock is in a different compartment from the one the Kerbal is currently in.

Airlocks can either be normally accessible, manually locked by the user or obstructed due to debris / bad design. From this, a number of possible use cases emerge:

- Directly clicking on an airlock hatch will open up the EVA dialog to allow users to select a Kerbal, just like in the current version of the game; however, rather than just the Kerbals in the immediate compartment, the list would be populated by all Kerbals aboard the entire vessel, with the names of those who cannot find a path to the selected airlock greyed out

Fig 2 - Revised EVA Airlock Hatch GUI mockup; suggested changes include allowing multiple airlocks per crewed compartment, listing all Kerbals in entire vessel, and greying out the names of Kerbals who cannot find a path through the compartments to the airlock.

- Clicking on the "EVA" button above the crew portraits would automatically make the Kerbal emerge from the nearest available airlock, using the pathfinding system for internal crew transfer if the current compartment said Kerbal is in does not have a valid airlock

- If all potential airlocks otherwise accessible along the path are either obstructed or manually locked, again an appropriate error message is displayed - i.e. "Hatch(es) obstructed / locked, cannot exit"

Relevancy to Overall Gameplay Experience

By itself, a revamped internal crew transfer system is of little use other than roleplaying of relief crew rotation; however, it could potentially serve as the groundwork other improvements to gameplay - for instance, perhaps a science experiment module needs to be crewed by Kerbals with certain skills / attributes, and so an orbital ferry could be used to bring these mission specialists up to the station and assigned to said compartment quickly.

Thoughts, suggestions and critiques welcome.

Coming soon - Flow charts describing the various functions/systems

[15nelsoc]

I just wanted to throw my support behind this.

[samhuk]

Editing my previous post...

I like this!

What I like about it is that it suits the KSP Developer mind-set: try and do the absolute least as possible in implementing a feature, then dribble out some random bits related to it for a few months afterwards. What's good about this is that it doesn't require too much work.

It would seem like they wouldn't have to actually add anything graphical to the game. What I think your are proposing is all code based.

It does indeed feel a bit stupid transferring crew between two connected command pods by EVA. In real life you would travel through the docking port or the instant connection, obviously.

Sam

Edited November 14, 2013 by samhuk

[boomerdog2000]

This would take a bit of graphical remodeling since neither of the command pods have exit hatches on the bottom. I suppose it makes sense for the mk.1 to not have one since it's so small but not really for the mk.2.

[sumghai]

What I like about it is that it suits the KSP Developer mind-set: try and do the absolute least as possible in implementing a feature, then dribble out some random bits related to it for a few months afterwards. What's good about this is that it doesn't require too much work.

I'd like to think that the simplicity of the implementation lends itself more to iterative or Agile software development in general than to SQUAD specifically.

This would take a bit of graphical remodeling since neither of the command pods have exit hatches on the bottom. I suppose it makes sense for the mk.1 to not have one since it's so small but not really for the mk.2.

I don't think those command pods need to be modified at all.

As you've correctly deduced for the one-Kerbal Mk1 Pod, its size and resemblance to the Mercury capsule means that internal crew transfer should not be applicable; in which case, the Mk1 would get the crewTraversable = false argument.

In the case of the three-Kerbal Mk1-2 Pod, note that the top and bottom of the in-game model includes mounting points for docking ports; I've also imported the Mk1-2 Pod interior model into Blender, and it is suggested that there is supposed to be a hatch behind (as well as in front of) the seats anyway.

[UnthinkableThinker]

I've some time ago made a thread similar to yours, and apparently it is listed under the "do not suggest" list, under the parts with interiors section. Nevertheless, you have my support on this.

[sumghai]

I've some time ago made a thread similar to yours, and apparently it is listed under the "do not suggest" list, under the parts with interiors section.

Prior to posting this tome, I had asked a moderator regarding this - his response was that while posts that simply ask for items on said lists are discouraged, specific discussions on implementation are kosher.

[UnthinkableThinker]

Prior to posting this tome, I had asked a moderator regarding this - his response was that while posts that simply ask for items on said lists are discouraged, specific discussions on implementation are kosher.

Ok, thank you for clarifying.

[Unikraken]

Support. We need this badly.

[kurja]

1st person IVA transferring between modules would be cool but what about docking ports, those things can be placed almost anywhere, I suspect implementation would not be simple and easy?

edit - hm op already mentioned this, it seems

[Kasuha]

Since we can transfer fuel and electricity through structures without any visible tubing or wires such as modular girders or struts, I don't see a problem moving Kebrals through such structures as well. Simple Alt+right-click on the two modules you want to use in the transfer and it'd allow you to transfer the crew. We can always imagine they went on EVA and did it while we were not looking.

For more immersive experience it might be nice if non-accelerating flying ships out of atmosphere changed their whole surface to a ladder, allowing Kerbals to move around the surface freely without flying off to the space. Real astronauts don't go flying around their space station unless necessary, too. Most often they stay within arm's reach and use various anchor points to keep themselves near. It'd be much easier for many people to navigate them where they need them to go.

[peadar1987]

Since we can transfer fuel and electricity through structures without any visible tubing or wires such as modular girders or struts, I don't see a problem moving Kebrals through such structures as well. Simple Alt+right-click on the two modules you want to use in the transfer and it'd allow you to transfer the crew. We can always imagine they went on EVA and did it while we were not looking.

For more immersive experience it might be nice if non-accelerating flying ships out of atmosphere changed their whole surface to a ladder, allowing Kerbals to move around the surface freely without flying off to the space. Real astronauts don't go flying around their space station unless necessary, too. Most often they stay within arm's reach and use various anchor points to keep themselves near. It'd be much easier for many people to navigate them where they need them to go.

Not sure how hard it would be to implement (and especially to animate), but I'd like to see a tether in the game, so your Kerbals can do EVA science or manoeuvres without having to worry about drifting away into space

[Smidge204]

Since we can transfer fuel and electricity through structures without any visible tubing or wires such as modular girders or struts, I don't see a problem moving Kebrals through such structures as well. Simple Alt+right-click on the two modules you want to use in the transfer and it'd allow you to transfer the crew. We can always imagine they went on EVA and did it while we were not looking.

Well, the implication is the wires/pipes exist even if they are not visible. Apparent size of the fuel line components not withstanding, it's not totally unrealistic that pipes and wires would be small enough to "hide" in structural members. Kerbals are a bit larger and generally do not do well when forces through small diameter pipes.

On the other hand, a simple transfer like this would just imply an EVA without actually having to perform it, and I'm okay with that. The ability to sift Kerbals around between at least some parts without EVA would be nice.

I'd personally LOVE to have a more expansive IVA mode. Collision meshes need not be that complex; the interior of many "walkable" parts would be basically cylinders or collections thereof (you do not need collision meshes that match interior details, like handles and such). Multi-adapters may pose interesting problems, but I think they're large enough to permit passage.

Basically you'd need to model the interior of every passable part, and poke holes where they join. Something similar to how the window on the command capsules work would suffice; You can't see in from outside, but you can see out. Perhaps a simple texture trick (from a solid visible texture to a totally transparent one) would suffice. If the attached component has no walkable volume, show a closed hatch instead.

It would be interesting to be inside a docking port junction when it's under stress! The Clamp-O-Tron halves slipping and pulling apart but not breaking... imagine the terror of being able to see out through the gap!

On a side note: None of the crewable compartments seem to have proper airlocks... just hatches. Perhaps a proper airlock component is warranted. I don't want to derail too much about extra components but having crewable/walkable parts equivalent to the various fuel tanks (eg hollow tubes) would be fantastic too! Kerbal habitrails!

=Smidge=

Edited November 15, 2013 by Smidge204

[boomerdog2000]

Actually is it too unreasonable to assume that kerbals can't maneuver through a radially attached docking port? It might limit some IVA components of space station design but I think it makes more sense that slapping a docking port on some random section of a hitchhiker doesn't just add the ability for kerbals to head out through it.

[Smidge204]

Actually is it too unreasonable to assume that kerbals can't maneuver through a radially attached docking port? It might limit some IVA components of space station design but I think it makes more sense that slapping a docking port on some random section of a hitchhiker doesn't just add the ability for kerbals to head out through it.

Agreed. There is a purpose-build radial docking port for that. If the docking ports aren't "where they should be" (designated "dockable" surfaces) they should still attach but not be valid paths of travel.

=Smidge=

[Wahgineer]

to solve radial docking port problem:

why not make 'adaptable' textures ?

For E.X.:

I have a 2.5 meter cone adapter modified to be crew transferable (which makes sense that it be crew transferable). The basic texture is a gray wall with some hoses or cables to break up the monotony. Radially attached are two clamp-o-tron docking ports. In Iva, a special texture is added that shows the interior 'entrance' to the docking port relative to the docking port on the outside. The number of the textures and where they are located corresponds with the docking ports.

This approach has the advantage of being able to universally fit with every part. While in some cases it may be odd (ex: docking port placed behind a seat in the hitchhiker), these cases are rare enough not to warrant concern.

[sumghai]

Not sure how hard it would be to implement (and especially to animate), but I'd like to see a tether in the game, so your Kerbals can do EVA science or manoeuvres without having to worry about drifting away into space

The point of this thread is to discuss internal navigation. There are plenty of other threads describing the use of tethers in EVA, and the Kerbal Attachment System add-on already fills this niche quite well.

the implication is the wires/pipes exist even if they are not visible. Apparent size of the fuel line components not withstanding, it's not totally unrealistic that pipes and wires would be small enough to "hide" in structural members. Kerbals are a bit larger and generally do not do well when forces through small diameter pipes.

On the other hand, a simple transfer like this would just imply an EVA without actually having to perform it, and I'm okay with that. The ability to sift Kerbals around between at least some parts without EVA would be nice.

The first part is precisely my point.

As for the second part, I dislike the idea of "implied" EVA between crew cabins not connected by crew tunnels, as it encourages sloppy, unrealistic station design.

I'd personally LOVE to have a more expansive IVA mode. Collision meshes need not be that complex; the interior of many "walkable" parts would be basically cylinders or collections thereof (you do not need collision meshes that match interior details, like handles and such).

Multi-adapters may pose interesting problems, but I think they're large enough to permit passage.

Basically you'd need to model the interior of every passable part, and poke holes where they join. Something similar to how the window on the command capsules work would suffice; You can't see in from outside, but you can see out. Perhaps a simple texture trick (from a solid visible texture to a totally transparent one) would suffice. If the attached component has no walkable volume, show a closed hatch instead.

This is precisely what I'm trying to avoid - extensive rework of existing interiors and adding crew tunnels to every possible part (that will seldom be used anyway).

Besides, during timewarp, physics (and colliders) is generally disabled, so you'd have Kerbals floating through walls and out into space.

It would be interesting to be inside a docking port junction when it's under stress! The Clamp-O-Tron halves slipping and pulling apart but not breaking... imagine the terror of being able to see out through the gap!

You'd have to deal with draw distances and culling when rendering compartments that can see through to other compartments.

On a side note: None of the crewable compartments seem to have proper airlocks... just hatches. Perhaps a proper airlock component is warranted.

I've made a dedicated airlock compartment for my FusTek station parts add-on.

Actually is it too unreasonable to assume that kerbals can't maneuver through a radially attached docking port? It might limit some IVA components of space station design but I think it makes more sense that slapping a docking port on some random section of a hitchhiker doesn't just add the ability for kerbals to head out through it.

Agreed. There is a purpose-build radial docking port for that. If the docking ports aren't "where they should be" (designated "dockable" surfaces) they should still attach but not be valid paths of travel.

=Smidge=

to solve radial docking port problem:

why not make 'adaptable' textures ?

For E.X.:

I have a 2.5 meter cone adapter modified to be crew transferable (which makes sense that it be crew transferable). The basic texture is a gray wall with some hoses or cables to break up the monotony. Radially attached are two clamp-o-tron docking ports. In Iva, a special texture is added that shows the interior 'entrance' to the docking port relative to the docking port on the outside. The number of the textures and where they are located corresponds with the docking ports.

This approach has the advantage of being able to universally fit with every part. While in some cases it may be odd (ex: docking port placed behind a seat in the hitchhiker), these cases are rare enough not to warrant concern.

Again, another needless complication of having dynamically-changing internal textures / meshes for many internals.

[Smidge204]

This is precisely what I'm trying to avoid - extensive rework of existing interiors and adding crew tunnels to every possible part (that will seldom be used anyway).

There are only a handful of parts that have internals, and none of them except for the hitchhiker container and Mk2 Lander Can would need any modification at all... and they both already have hatches on the floor and/or ceiling. All the other parts with internal views are only cockpits of some sort, with no room to fly around inside them anyway, so when you get to a hatch with a cockpit on the other side you can just use a "Board" action like with EVAs.

Besides, during timewarp, physics (and colliders) is generally disabled, so you'd have Kerbals floating through walls and out into space.

Only allow physical time warp unless the active Kerbal is seated somewhere. All the others can get frozen in place relative to the capsule during non-physical time acceleration if they aren't seated.

You'd have to deal with draw distances and culling when rendering compartments that can see through to other compartments.

It's my understanding that the interior spaces are already present and loaded in the game at all times, but not rendered fro outside because the windows are not actually windows. That is, the internal spaces already exist and the IVA is simply another camera in the same scene as the exterior view.

That said, I see no reason why you'd need any special rendering tricks... draw distances are already not a problem. It's unreasonable to think anyone would a station larger than the game's render distance. Take a look at the science center from the end of the runway and that's the kind of rendering distance you have to work with. You'll be up against part count issues long before you have framerate problems due to rendering. Rendering down the length of a series of tubes does not seem much more taxing than rendering something with hundreds of girder segments like people already do.

To me it sounds like you're saying this is difficult if not impossible for the renderer to handle:

Again, another needless complication of having dynamically-changing internal textures / meshes for many internals.

So how do windows currently work? They are transparent from the inside but opaque from the outside. Honest question.

As for dynamic meshes, I don't see how this is fundamentally different that most other things in the game. Presumably each part has its own collision mesh. Can a single part have more than one? Using the hitchhiker compartment as an example, you have four "states" - both hatches closed, hatch A open/B closed, B open/A closed, and both open. If you can model the collision mesh as "both open" by default (a hollow tube with open ends), then add/remove "cap" meshes on either end as necessary along with appropriate textures, that should be fine.

=Smidge=

[sumghai]

There are only a handful of parts that have internals, and none of them except for the hitchhiker container and Mk2 Lander Can would need any modification at all... and they both already have hatches on the floor and/or ceiling. All the other parts with internal views are only cockpits of some sort, with no room to fly around inside them anyway, so when you get to a hatch with a cockpit on the other side you can just use a "Board" action like with EVAs.

What about add-on command pods large enough to warrant this (hypothetical) walk-through feature (e.g. Karmony Utilities, Starvision's USS Enterprise NCC-1701 bridge)? How do you decide whether a cockpit gets a "Board"-only function or not?

Only allow physical time warp unless the active Kerbal is seated somewhere. All the others can get frozen in place relative to the capsule during non-physical time acceleration if they aren't seated.

You're looking at significant modifications to the core time-warp code, whereas my original proposal doesn't need to even touch on the issue.

That said, I see no reason why you'd need any special rendering tricks... draw distances are already not a problem. It's unreasonable to think anyone would a station larger than the game's render distance. Take a look at the science center from the end of the runway and that's the kind of rendering distance you have to work with. You'll be up against part count issues long before you have framerate problems due to rendering. Rendering down the length of a series of tubes does not seem much more taxing than rendering something with hundreds of girder segments like people already do.

What you're describing is nice and all, but only for stock parts.

Add-on authors such as myself may make very large or very long crew cabins, and relatively few of these stacked end-to-end with the hatches open along the longitudinal axis would result in draw distance issues.

So how do windows currently work? They are transparent from the inside but opaque from the outside. Honest question.

As someone who's actually experimented with making my own IVAs, the windows are simply cutouts in the internal mesh. Nothing really "dynamic" is involved.

As for dynamic meshes, I don't see how this is fundamentally different that most other things in the game. Presumably each part has its own collision mesh. Can a single part have more than one? Using the hitchhiker compartment as an example, you have four "states" - both hatches closed, hatch A open/B closed, B open/A closed, and both open. If you can model the collision mesh as "both open" by default (a hollow tube with open ends), then add/remove "cap" meshes on either end as necessary along with appropriate textures, that should be fine.

What you're suggesting is okay for stock game, but not scaleable for crew compartments from add-ons, with the potential to have far more hatches than *just* the couple used in the Hitchhiker. Surface-attached docking ports are even worse because then you'd have internal hatches clipping through what add-on authors would, for instance, have intended to be uninterrupted rows of computer banks or other internal doodads.

The point is, IVA navigation that involves Kerbals actually walking around inside might be fun the first couple of times, but it becomes tedious when managing larger numbers of crew. As tempting as it is to retort with "just make all the options available for all playtypes!", bear in mind that we're talking about lots of development time being put into a relatively minor convenience feature - given SQUAD's current direction, I don't think they want to spend too much time on comprehensive IVA overhauls. As such, I believe my proposal as originally presented is more efficient to use and quicker to implement as a small part of a major update (whereas your idea will take up an entire update in itself).

[Smidge204]

What about add-on command pods large enough to warrant this (hypothetical) walk-through feature (e.g. Karmony Utilities, Starvision's USS Enterprise NCC-1701 bridge)? How do you decide whether a cockpit gets a "Board"-only function or not?

What about them? It's their responsibility to maintain their own mods. This argument applies to any update to the game that might ever come out... don't update anything, you might break some mods!

Deciding what cockpits get the board option is easy - just decide. Neither of the capsules have any significant interior space so those make sense as candidates. The cupola module is also pretty cramped. The Mk3 cockpit might have enough room to warrant free IVA but it depends on how it's detailed out internally. etc etc...

You're looking at significant modifications to the core time-warp code, whereas my original proposal doesn't need to even touch on the issue.

You're going to have to quantify "significant modifications" because simply saying the changes are significant doesn't actually make them so. There should be no need for hyperbole here.

Add-on authors such as myself may make very large or very long crew cabins, and relatively few of these stacked end-to-end with the hatches open along the longitudinal axis would result in draw distance issues.

So the render distance, based on how far from KSC I can drive and still make out details, appears to be on the order of kilometers.

How large are these crew cabins you make? The VAB is only ~150m tall. Assuming they're that big, which leaves no room for a lifting stage (maybe you're cheating to get them in orbit?) you'd need at least 80 of them to start making draw distance a concern. And at 10+km in length aren't you more likely to run into problems with the physics engine long before draw distance becomes a problem? And a single ship made of nothing but these 150m long capsules and docking ports to stick them together would be 238 parts. That's with absolutely nothing else. How quickly will you run into a part count problem?

No, I don't think draw distance is a limiting factor here. And really, what difference does non-stock parts make?

As someone who's actually experimented with making my own IVAs, the windows are simply cutouts in the internal mesh. Nothing really "dynamic" is involved.

Okay, maybe my trouble is with the word "dynamic" then. Is it really that hard to enable/disable a mesh? Remember I was thinking a single mesh for the body of the part and a separate mesh for each portal, so it would just be an on/off thing and not having to swap a mesh with another one. Or maybe you could animate the hatches and then "air tightness" is just a matter of a boolean value indicating each hatch is open or closed.

And don't tell me how hard it would be to make animated hatches, because there are plenty of other parts (mostly landing gear) that move dynamically with proper collision meshes, and several mods that add that kind of feature. Can't be THAT hard.

What you're suggesting is okay for stock game, but not scaleable for crew compartments from add-ons, with the potential to have far more hatches than *just* the couple used in the Hitchhiker. Surface-attached docking ports are even worse because then you'd have internal hatches clipping through what add-on authors would, for instance, have intended to be uninterrupted rows of computer banks or other internal doodads.

Again, I'm not sure I can sympathize. It would be the responsibility of the modders to make their mods compatible with the game mechanics, just like it is now. In my eyes your complaint is just as valid for any new feature or change that could break existing mods. I believe the official policy on this is "caveat mutavi" (trans: "Deal with it") Imagine the lamentations of modders everywhere if/when better aerodynamics are rolled into the official game!

The point is, IVA navigation that involves Kerbals actually walking around inside might be fun the first couple of times, but it becomes tedious when managing larger numbers of crew.

As for the second part, I dislike the idea of "implied" EVA between crew cabins not connected by crew tunnels, as it encourages sloppy, unrealistic station design.

I realize these two statements are not opposing each other, but the underlying sentiment is... Do you want realistic or non-tedious? You really can't have both in this sort of game.

=Smidge=

[Kegereneku]

I think discussing IVA navigation in 3D is going way overboard for little benefit.

On the other hand I really like the pathway "code only" idea which sound easy to accommodate into the game.

Working on a structured IVA navigation might lead up to limited-EVA fuel and other IVA gameplay idea. (ex : manned science module, infinite life-support module)

[JerryIRacer]

+1 for the OP option 3. I especially like "fuel flow logic" to establish if transfer is possible. Hope to see it implemented at some point.

[betaking]

I think this is an excellent Idea, or at the very least, a very solid concept that, squad should persue for .23

Even if it's just like a placeholder, I wouldn't mind. It would mean 1 less "Essential" mod (in this case Crew Manifest) I would have to install,

Edited November 16, 2013 by betaking

[sumghai]

I think discussing IVA navigation in 3D is going way overboard for little benefit.

On the other hand I really like the pathway "code only" idea which sound easy to accommodate into the game.

Working on a structured IVA navigation might lead up to limited-EVA fuel and other IVA gameplay idea. (ex : manned science module, infinite life-support module)

+1 for the OP option 3. I especially like "fuel flow logic" to establish if transfer is possible. Hope to see it implemented at some point.

I think this is an excellent Idea, or at the very least, a very solid concept that, squad should persue for .23

Even if it's just like a placeholder, I wouldn't mind. It would mean 1 less "Essential" mod (in this case Crew Manifest) I would have to install,

Precisely my point - although I wouldn't consider my proposal to be merely a placeholder, but a most-final implementation.

[Dun Kirk]

I just wiped what I said...

I don't care about IVAs that much. Crew transfer functions yes.