Navigation within multi-compartment spacecraft: Analysis and Potential Implementation

[Wahgineer]

@sumgahi

What I meant by adaptable textures was that if you attached a port radially, a collision less, 3d texture would appear on the inside corresponding to the location of the port on the outside. By right clicking it, you could either insta-transit to an attached port (granted there is one), or actually go into the port and crawl through it to the other side. Considering the IVA is loaded even while in EVA/free cam/chase cam/orbit cam/flight scene, this shouldn't have an adverse affect on performance, as well as aid in navigation within a spacecraft (allows you to find a specific port more easily).

[sumghai]

@sumgahi

What I meant by adaptable textures was that if you attached a port radially, a collision less, 3d texture would appear on the inside corresponding to the location of the port on the outside. By right clicking it, you could either insta-transit to an attached port (granted there is one), or actually go into the port and crawl through it to the other side. Considering the IVA is loaded even while in EVA/free cam/chase cam/orbit cam/flight scene, this shouldn't have an adverse affect on performance, as well as aid in navigation within a spacecraft (allows you to find a specific port more easily).

The main problem here is that because your proposed port can be radially attached to any surface of a crew compartment, there is the potential for the internal hatch mesh to clip into and visually interfere with whatever detail that was on the original interior.

Consider the stock Hitchhiker - if you surface attach a port to the sides, the internal dynamic hatch mesh is likely to clip into one of the seated Kerbals or a cabinet.

[Aghanim]

Option 3 for the near future, option 1 for the far future

[Mecha Pants]

Not being a modder, and lacking any knowledge of the difficulties involved, if I were building a full first person IVA movement mode, I wouldn't allow crew transfer through surface attached docking ports, only those on nodes. Each node would need an ID of some sort, to tie to an IVA entry/exit point.

In addition, I'd put internal IVA hatches between rooms (with or without windows), and only simulate "active" rooms. As part of this, I would only show the active control module's (or the last module with crew that was active if the craft is being controlled from a docking port or similar) kerbal portraits while using external views (to limit the number or rendered areas).

As far as IVA physics in time warp, I wouldn't put individual interior objects on rails during warp, I would simply pause all the interior spaces until warp ends. kerbals or objects don't float away, don't move at all actually, until you stop time warp.

For example: if I were in IVA view in a lander can on the top node of a hitchhiker only the hitchhiker and the lander can would be active. if I were to move into the hitchhiker then it, the lander can, and whatever the "next" compartment happened to be would be rendered. As I continued to move through rooms only my current room and adjacent rooms would be active.

If at any point I decided to use time warp while IVA, the only thing that would move would be the view through the window.

I could see some issues forming with crew tunnel segments having a hatch at both ends, repetitive opening and closing of doors as you pass down the corridor would get annoying. Maybe something along the lines of a stretchytanks style procedural crew tunnel with a dynamically repeating texture and IVA internal would offer a solution.

edit: Also, there could be a configuration flag to skip a module in IVA mode rendering, to account for slim adapters or endcaps.

Edited November 20, 2013 by Mecha Pants

[Wahgineer]

The main problem here is that because your proposed port can be radially attached to any surface of a crew compartment, there is the potential for the internal hatch mesh to clip into and visually interfere with whatever detail that was on the original interior.

Consider the stock Hitchhiker - if you surface attach a port to the sides, the internal dynamic hatch mesh is likely to clip into one of the seated Kerbals or a cabinet.

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.

And you were saying?

[sumghai]

And you were saying?

I'm saying that your idea only works for your very specific "adapter" part and not stock parts like the Hitchhiker. Just because it's a "rare" case doesn't mean it doesn't warrant concern.

All in all, full 3D internal navigation is far too much work for very little gain, and is not scaleable/efficient for larger numbers of crew / travelling between two compartments very far apart.

[Wahgineer]

the reason I made the text bold was because I realized that problem, too.

Also, think about it: how many times do you put docking ports radially on the Hitchhiker?

In Fact, why would you, with the dangers of a craft or new module hitting too hard and destroying the hitchhiker? That is what the 6-way hub node is for: for connecting modules to a central point.

[sumghai]

the reason I made the text bold was because I realized that problem, too.

Also, think about it: how many times do you put docking ports radially on the Hitchhiker?

In Fact, why would you, with the dangers of a craft or new module hitting too hard and destroying the hitchhiker? That is what the 6-way hub node is for: for connecting modules to a central point.

I personally would not build in the way I just described; however, some people may do, and as such my proposal of a GUI-only crew transfer better accommodates this peculiar case than full 3D navigation.

[S4qFBxkFFg]

I honestly thought that this was something Squad had already planned - looking at various parts, it's difficult not to assume that there are already hatches in the art, even if they don't do anything.

Consider:

http://wiki.kerbalspaceprogram.com/w/images/f/fb/Z-4K.png

http://wiki.kerbalspaceprogram.com/w/images/8/86/Rockomax_Hubmax_Multi-Point_Connector_big.png

http://wiki.kerbalspaceprogram.com/w/images/5/5e/Hitchhiker_interior_dev.png

Taking the last image (Hitchhiker) as an example, I always thought the circles you can see at the top and bottom of the compartment were hatches that would allow kerbals to pass through into the next compartment. The small triangle is what I took to be a window, probably so the kerbal who's about to open the hatch can check that there's actually more spacecraft on the other side.

As for considering a part to be passable or not, some of them are (to my view, at least) already implied to be:

http://wiki.kerbalspaceprogram.com/w/images/9/9a/Probehuge.png

...I've always thought the black circle in the middle is just a hole. Some are explicitly empty "inside", like the decouplers.

The docking ports are interesting because they appear to have both internal/external hatches drawn:

http://wiki.kerbalspaceprogram.com/w/images/4/4e/Clamp-o-tron-sr-correct-usage.png

Anyway, it would be great if sumghai's "simple" option could be implemented into the game quickly, although we'd probably all like the option of going 1st-person IVA through our space stations.

edit:

Not being a modder, and lacking any knowledge of the difficulties involved, if I were building a full first person IVA movement mode, I wouldn't allow crew transfer through surface attached docking ports, only those on nodes. Each node would need an ID of some sort, to tie to an IVA entry/exit point.

this Edited November 26, 2013 by S4qFBxkFFg

[John Nowak]

This sounds like an excellent and well-thought out proposal. I'd suggest that crews could also transfer through adapters, though.

Also note that it's quite possible to put a hatch in an ablative heat shield. This was tested successfully in an unmanned Gemini flight; a test example is on display at the National Museum of the United States Air Force.

[tntristan12]

Brilliant!

[Capt Snuggler]

I honestly thought that this was something Squad had already planned - looking at various parts, it's difficult not to assume that there are already hatches in the art, even if they don't do anything.

Consider:

http://wiki.kerbalspaceprogram.com/w/images/f/fb/Z-4K.png

http://wiki.kerbalspaceprogram.com/w/images/8/86/Rockomax_Hubmax_Multi-Point_Connector_big.png

http://wiki.kerbalspaceprogram.com/w/images/5/5e/Hitchhiker_interior_dev.png

Taking the last image (Hitchhiker) as an example, I always thought the circles you can see at the top and bottom of the compartment were hatches that would allow kerbals to pass through into the next compartment. The small triangle is what I took to be a window, probably so the kerbal who's about to open the hatch can check that there's actually more spacecraft on the other side.

As for considering a part to be passable or not, some of them are (to my view, at least) already implied to be:

http://wiki.kerbalspaceprogram.com/w/images/9/9a/Probehuge.png

...I've always thought the black circle in the middle is just a hole. Some are explicitly empty "inside", like the decouplers.

The docking ports are interesting because they appear to have both internal/external hatches drawn:

http://wiki.kerbalspaceprogram.com/w/images/4/4e/Clamp-o-tron-sr-correct-usage.png

Anyway, it would be great if sumghai's "simple" option could be implemented into the game quickly, although we'd probably all like the option of going 1st-person IVA through our space stations.

edit:

this

really well considered and researched point(s).

so we could say that for enhanced IVA to work (at all) you could only enter/exit modules through specific places (the attaching ends) on specific parts that have this capability? this way the parts will always be lined up correctly (via attaching points). this means radially mounted docking points would loose (never gain) crew transfer capability?

that's a fair trade off i think.

but maybe attaching radially mounted docking ports on top of external crew hatches could allow them to work? would that not require less work, this be a possibility?

I think we should all remember these are some smart devs and a smart modding community. I really think this can be done.

Edited December 16, 2013 by Capt Snuggler

[One-Way Films]

This is a relitivly small suggestion. While kerbals are inside your station/ship they have their helmets off and could have T-shirts that varie in colour depending on who they are. Jeb, Bill and Bob have Blue shirts with white collars and the recruits have blue shirts full stop.

Edited December 17, 2013 by One-Way Films

[ImJake]

Since there are already hatches on the inside/outside of several parts, it seems like it wouldn't be too hard to integrate IVA crew transfer. But, since controlled 3D movement (1st or 3rd) between modules seems kinda complicated, an easy method of navigating complex interior structures would be like google maps street view, or the game Myst. In IVA, you click the existing hatch to transfer to the next room. Parts like this battery http://wiki.kerbalspaceprogram.com/w/images/f/fb/Z-4K.png wouldn't need to have artwork or complex coding or meshes (I cant do any of that stuff) for its internals to be made since there's nothing to do in it and it would be unreasonable to make a stop in a compartment that size, so it would be skipped. For parts like the multi port connector http://wiki.kerbalspaceprogram.com/w/images/8/86/Rockomax_Hubmax_Multi-Point_Connector_big.png where there are multiple ways you can go, a small menu would pop up with your options; you click which room you want to go in, and skip the multi connector. Rooms can be renamed the same way the overall ship can for easier navigation. If you click on a hatch and the part on the other side can't be passed through, an error message would pop up explaining why you're being dumb. If you click on a hatch and it leads to outside the ship/station/ect. you are put in EVA mode. Crew capacity wouldn't matter (to a reasonable extent), but everyone would need to be seated before the ship can move or make adjustments to its position. With this system of navigation, only one room would ever needed to rendered at once, because it would be assumed that you closed the hatch behind you.

Also, I'm a big fan of the OP's third method, and I'm hoping it gets implemented within the next few updates.

[MercenaryX]

I for one am for option three, and I can see where you are going with this, as for 3D rendering, that would be nice with IVA, but let's be realistic here. That's alot of work that will hinder the game more then needed, I can see as some kind of expantion pack down the line, but not for something right now.

I also would like to add in that the idea of crew transfer though the station could also be helped by travel time for the Kerbal to go from point a to point b, in that he would start off in one area and then a progress bar could show with him going to the next in place of a view of him traveling though said compartments, And to take this a step further, you can take into account the Kerbal's Bravery and stupdity.

Think about it like this, the more Brave the Kerbal is, the faster he will go though the station to his destnation, but this can also hurt him if he's got a high stupdity, which could have him go to take a wrong turn and end up going out an airlock or damaging a part of the interal structure which could be fixed with supplies, time, and a Kerbal to fix the issue. To get back to this point, the higher the Kerbal's Bravery is, the faster he goes, but has a chance for damaing things or taking a wrong turn, oposit could have the Kerbal being slower and taking more time, but this could also lead to being helpful if an area might have damage which can be reported after a crew transfer and only IF it happens to be there. Stupdity could have the Kerbal get lost easier, damage things on the way, or just end up causing something of a risk, mind you this idea is bearly thought out and figure that it would be an intersting idea on top of crew systems to get people to have a risk reward system in place. Either way, a Kerbal's stats could effect how effecently he takes his time to get from point a to point b.

This again is only just something that could enhance the experince if done right, and again, this can be done without haveing to render anything. What do you think? I for one like this idea because it has also the potnetional for responce time for dealing with damage to stations or crafts, and if your kerbal can get to a section in time, he could save a crew in trouble or fix a compartment so it wouln't have to be jettusoned because it endangers the rest of the station.

Again this is mostly for things down the line, but the potential this system can add a ton of dynamic features while would be cool to look at, is better if only seen in text messages like when you are transmitting data or using the mobile lab.

[nholzric]

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:

http://fc06.deviantart.net/fs71/f/2013/304/b/0/ksp_crew_transfer_gui_mockup_01_by_sumghai-d6sjcxv.png

Fig 1 - Crew transfer dialog GUI mockup

Awesome thoughts! I would love to be able to float a Kerbal through compartments either in first person or third person but it feels like overkill for an such a tangential feature. In other words, probably not worth the development time.

Your idea with the crew transfer dialog makes a ton of sense. It would cut down on tedious EVA's when transferring crew, it's clean, it's intuitive, and sounds simple enough to code. It would also force a new set of considerations when making ships and stations if you wanted your livable places to be connected. BUT people can get around it with mods if so desired ("The Everything's A Tunnel Mod") because sometimes a ship with a fuel tank connecting two habitats just looks good.

I think the airlock bit is a little overkill. It makes sense and is good for role-playing but a little tedious for the stock game. Maybe if life support becomes a stock thing then beginning an EVA from different pods would cost different amounts of air - so you could step outside from the Hitchhiker but the airlock is so huge that it wastes a lot of gas, better to first transfer to a Mk1 Lander Can and open the hatch there.

Edited January 13, 2014 by nholzric

[KASASpace]

This is good.......

[MercenaryX]

Awesome thoughts! I would love to be able to float a Kerbal through compartments either in first person or third person but it feels like overkill for an such a tangential feature. In other words, probably not worth the development time.

Your idea with the crew transfer dialog makes a ton of sense. It would cut down on tedious EVA's when transferring crew, it's clean, it's intuitive, and sounds simple enough to code. It would also force a new set of considerations when making ships and stations if you wanted your livable places to be connected. BUT people can get around it with mods if so desired ("The Everything's A Tunnel Mod") because sometimes a ship with a fuel tank connecting two habitats just looks good.

I think the airlock bit is a little overkill. It makes sense and is good for role-playing but a little tedious for the stock game. Maybe if life support becomes a stock thing then beginning an EVA from different pods would cost different amounts of air - so you could step outside from the Hitchhiker but the airlock is so huge that it wastes a lot of gas, better to first transfer to a Mk1 Lander Can and open the hatch there.

I love the idea you just put in about the cost to go out, if you look at the start of Call of Duty Ghost you see how your guy goes into the air lock and it has to fill with air? Well, when you start off building a station you need to keep sending up air and the like to refill the station because of using said air locks, like you put down with the Mk1 Lander Can, but later on, you can add in a part that gives the air locks a chamber before you can EVA to evacuate the air, it doesn't get all the air out of the chamber, but at least a vast majority of air could be pulled and you only get a small loss, but an early work around to this late game item could be the Lander Can or some other component that is compatible. As for the idea of Looks when it came to a fuel tank, maybe there can be an option to use a part other then what it was intended but at a cost or reduced function? Also there is the part where you could have it either cosmetically look like another part, or my personal favorite, be able to send empty fuel tanks into space when building a space station. With empty tanks you could use those until you fill them as possible passages or have some kind of control room that is part of the tank. At least control in the same terms as a like the Space Lab.

[Deathsoul097]

I can see this being implemented in many ways. I would personally wish that 1 would be implemented in the long term. I think that if you do this to transfer crew between modules, you should be able to right click on other kerbals and click on an option that made them follow you, along with the ability to actually use IVA, such as turning the science lab into an actual useable science lab for the player, with experiments etc depending on the situation, and whether or not you had certain modules or experiments on board, such as surface samples. EG: If you had a lab on the surface of duna, and you had taken some surface samples, then you could find said samples in the lab module if you had one, right click on them, and then over about a minute the kerbal would start doing his own thing, working on the sample, and analysing it on his own, while you moved over to control another kerbal, to start checking up on your bases subsystems, and monitoring a kethane refinery, etc. Taking control of another kerbal in IVA would be just as simple as using [ or ], or right clicking and getting a drop down menu with options like: "Follow me", or "Control Kerbal". Then, as you fly, or do your own thing, you would see the little portraits of kerbals doing their own thing, socializing or moving around and monitoring stuff.

[MercenaryX]

I can see this being implemented in many ways. I would personally wish that 1 would be implemented in the long term. I think that if you do this to transfer crew between modules, you should be able to right click on other kerbals and click on an option that made them follow you, along with the ability to actually use IVA, such as turning the science lab into an actual useable science lab for the player, with experiments etc depending on the situation, and whether or not you had certain modules or experiments on board, such as surface samples. EG: If you had a lab on the surface of duna, and you had taken some surface samples, then you could find said samples in the lab module if you had one, right click on them, and then over about a minute the kerbal would start doing his own thing, working on the sample, and analysing it on his own, while you moved over to control another kerbal, to start checking up on your bases subsystems, and monitoring a kethane refinery, etc. Taking control of another kerbal in IVA would be just as simple as using [ or ], or right clicking and getting a drop down menu with options like: "Follow me", or "Control Kerbal". Then, as you fly, or do your own thing, you would see the little portraits of kerbals doing their own thing, socializing or moving around and monitoring stuff.

There is an issue with this we are trying to get a set up where it doesn't need to have mass amounts of animation, that's just at best something for later down the line near full release, as for that in Iva, yeah I can sort of see what you are going for, but again, it's best if you do it like with the living modual, the one that takes 4 kerbans, however if you just have say only two kerbans in the lab and it's been rendered like the habitat modual, then the idea of samples in the lab isn't a bad idea, but more of a cosmetic thing with maybe, MAYBE, a small animation of a device that is over and over doing something to the sample like a drill or lazer or something of the like, something cute like that. You can't move around or anything, but at least something like that could add flavor.

However this discussion is going off on a tangent, and this is about a feature in the game in the future that would act like Crew manifest.