Walking in IVA

[Mihara]

I actually have a halfway clever idea how to do this, or rather, come as close to this as can be expected without actually rewriting large chunks of KSP, but I need some help.

Imagine an InternalModule that does this:

1. Sits on a collider that covers the internal representation of a hatch and waits for clicks.
   
2. When you, being in IVA, click on it, it searches the part tree for the next habitable pod with a defined IVA and a free seat in the direction this hatch would go to.
   
3. Should that be found, it determines which kerbal you are currently controlling.
   
4. It transfers that kerbal to the seat previously found, if such were found.
   
5. It switches your camera to the kerbal's new position.
   

Voila, you're as close to walking in IVA as currently can be expected.

The problem I need help with is this:

Given the transform of an internal collider, it's not an issue to determine where it is in world coordinates and project a direction from pod center, there are functions for that -- or I could make it configurable, that's not an issue. It's likewise trivial to see if there are any free seats in a given list of pods and not a problem to move the kerbal or switch the viewpoint.

The missing piece is, how, knowing a direction and a pod you started from do I determine which pods to check for free seats? For bonus points, how do I determine whether that the pod in question is not connected by smaller clampotrons, which a kerbal can't squeeze through? It'd be easy to produce a Crew Manifest-style GUI instead, but that would break the immersion, and keeping it is the whole point of such an arrangement.

[Faark]

- I barely use IVA, but don't stock capsules have only one exit, that usually points toward space? How do you want to determine a "direction"?

- Are there any colliders set up for IVA doors anyway? Guess you would have to use those of the outside. And if thats possible, you might also use that as a direction

While its not really "walking", any steps toward actual working IVA is nice.

[Mihara]

• Stock capsules have one "exit", but they also commonly have the visual indication of the inside of a hatch, (Marked with the large friendly +) the outside of which corresponds to an attachment node. See in particular Mk1-2 pod, Mk2 lander can, Mk1 lander can, crew tank... Sometimes you can't see backwards while the capsule is facing forwards, like in Mk1-2, and it's obvious exits would also be backwards, which is something of a problem, but not an impossible one to solve one way or another.
  
• They also often do have an airlock door on the inside, and yes, clicking on it could make the kerbal go EVA, which it currently doesn't, but that's much easier.
  
• That they do not have colliders on any of them is not an issue, however, a collider can be created programmatically if one isn't present in the model.
  

The problem I'm seeking help with is not determining direction, though -- that can be solved in a large number of ways, and failing all else, configured when placing the module -- but determining an appropriate pod to end up in given a direction.

For example, suppose I have a Mk1 lander can with a crew tank beneath it, and a crew tank above it. I control the kerbal in the Mk1 lander can and click on the hatch above him. The code should consider the crew tank above the Mk1 can for potential placement, but should reject the crew tank below it, because it's in the wrong 'direction', the kerbal is going up through the hatch, not down.

And I don't think that sort of information can be readily inferred just by going through the list of parts, it needs something more clever than that.

[Faark]

And I don't think that sort of information can be readily inferred just by going through the list of parts, it needs something more clever than that.

Why exactly? Looks pretty much like it for me. It might get a little more complicated when the kerbal has to travel though other parts, but for me it looks like the first thing to do would be finding the matching stack attachment node for the chosen hatch. Its more complicated for surface attached stuff (btw, thats even more a problem in IVA) or when there are different branches to consider. Just imagine a command pod on top of a 6-sided hub that also has 2 crew modules on each sides. There is no way to find out which one the player intends to go to, except with a. an UI (might break the immersion) or b. creating IVA's for those junctions and traveling though them one by one (lots of work for dev, annoying for player, very easy to become lost).

[Mihara]

Why exactly? Looks pretty much like it for me.

Well, for one, just a list won't do, because a list does not directly represent the part tree, as far as I can see, it's a list.

And yes, the only reasonable way to get around the problem of a six-sided hub is to have an IVA for it, however crude. Getting lost will not be much of a problem, though, if the hatches are appropriately marked in it.

[Faark]

Okay, but even with an auto-generated interior for unknown parts do surface attached parts remain a problem. Slapping a door somewhere might look even worse on parts with a custom IVA.

Well, for one, just a list won't do, because a list does not directly represent the part tree, as far as I can see, it's a list.

It is a list of parts that does contain all available information about a vessel, including its part hierarchy. Check out Part.attachNodes / .srfAttachNode.

[ahappydude]

Yes yes yes Please continue on this project, on a more serious note, i tried a while back and they spawned in the iva but mostly flailing around. Great to see someone working on this

[Commissioner Tadpole]

Begin your project with the Hitchhiker Storage Container. It is large, spacious(regarding crew seats), and would be a lot of fun to float around when it is in space.

[Mihara]

Okay, but even with an auto-generated interior for unknown parts do surface attached parts remain a problem. Slapping a door somewhere might look even worse on parts with a custom IVA.

Of course.

Well, maybe that's actually a good thing, don't slap a hatch on the wall and then expect to go through it if the capsule is not designed for it.

It is a list of parts that does contain all available information about a vessel, including its part hierarchy. Check out Part.attachNodes / .srfAttachNode.

I feel a fit of recursion coming on...

Begin your project with the Hitchhiker Storage Container. It is large, spacious(regarding crew seats), and would be a lot of fun to float around when it is in space.

Um. You did read what I wrote about? Unfortunately there will be no floating.

I do wonder what exactly happens if something moves around the InternalSeat transform, but I doubt it's anything good.

[DiEvAl]

What parts should allow kerbals to go through? It'd look very silly if a kerbal can squeeze through an ant engine ;-). And squeezing through mainsail's nozzle, or swimming through a tank full of fuel isn't much better.

I see 3 options here: blacklist, whitelist, or some fancy heuristic.

[Guest]

I think that a whitelist approach is a good one. This could be done via modules. No interior necessary, so you could have, for example, heat shield that can be walked through. Most parts are not designed for crew access, afterall.

In general, I love the idea for this plugin. It'd have great potential for ISS, MIR, FusTek and KOSMOS SSPP.

[Mihara]

I see 3 options here: blacklist, whitelist, or some fancy heuristic.

I think that a whitelist approach is a good one. This could be done via modules. No interior necessary, so you could have, for example, heat shield that can be walked through. Most parts are not designed for crew access, afterall.

There's always a heuristic based on the model's collision box.

Right now I'm having more problems getting a kerbal to change seats, though, no matter what exactly am I doing, reseating them while you're IVA somehow wrecks the internal model data structures and the entire internal vanishes with no comment.

[Mihara]

...Well, to summarise.

1. The problem of not being able to see the hatch from where the kerbal is sitting as well as positioning things to click on has been conclusively solved, I can control the permitted camera rotation range for each seat separately. 0.13 release of RasterPropMonitor will include clickable EVA hatches on the inside for all stock capsules with IVA, and the player will be able to turn to look at them, so that much works.
   
2. The problem of moving around turned out an unexpected stumbling block. Namely, when I try doing something like this:
   

                public static void ReseatKerbalInPart(this Kerbal thatKerbal) {
                        if (thatKerbal.InPart == null || !JUtil.VesselIsInIVA(thatKerbal.InPart.vessel))
                                return;

                        InternalModel thatModel = thatKerbal.InPart.internalModel;
                        Part thatPart = thatKerbal.InPart;
                        int spareSeat = thatModel.GetNextAvailableSeatIndex();
                        if (spareSeat >= 0) {
                                ProtoCrewMember crew = thatKerbal.protoCrewMember;
                                CameraManager.Instance.SetCameraFlight();
                                thatPart.internalModel.UnseatKerbal(crew);
                                thatPart.internalModel.SitKerbalAt(crew,thatPart.internalModel.seats[spareSeat]);
                                thatPart.internalModel.part.vessel.SpawnCrew();
                                CameraManager.Instance.SetCameraIVA(thatPart.internalModel.seats[spareSeat].kerbalRef,true);
                        }
                }

-- if I can reseat a kerbal within the same pod, surely I can sit him anywhere there's a free seat, right? -- pretty much every way I try it, with switching the camera out or without, referring to objects or to indexes, whatever, when it fires, the internal model mysteriously evaporates and the capsule behaves as if it has no internal. My modules start spewing errors because structures they were pointing to go dead, but the stock code remains completely quiet and tight-lipped about what the hell actually happened. Yet CrewManifest, as far as I can see, is doing more or less exactly the same thing... Duplicating what it's doing exactly still gets the same result though.

[sarbian]

Why don't you just part.AddCrewmember & part.RemoveCrewmember ? Each time I looked at how the portrait worked I got nightmare ^^

[Mihara]

Why don't you just part.AddCrewmember & part.RemoveCrewmember ? Each time I looked at how the portrait worked I got nightmare ^^

Because I wanted to be able to sit the kerbal at a specific seat. But AddCrewmember/RemoveCrewmember were the first thing I tried, the result was exactly the same -- the entire IVA mysteriously vanishing.

What puzzles me the most is that switching the camera out to Flight for the duration of the procedure doesn't help either.

[sarbian]

Oh, you mean the IVA portrait is gone ? Crewmanifest has the same bug and I could not fix it (I did not try for long).

In the end I put the button that respawn the EVA back. It calls vessel.SpawnCrew() but mess up things more if the current display is fine ...

Well I wasn't of much help.

[Mihara]

Oh, you mean the IVA portrait is gone ?

I wish it were just the portrait. The IVA itself is gone. My prop modules go crazy trying to operate on nulls.

[CAckad]

Because I wanted to be able to sit the kerbal at a specific seat. But AddCrewmember/RemoveCrewmember were the first thing I tried, the result was exactly the same -- the entire IVA mysteriously vanishing.

Have you tried "InternalModel.SitKerbalAt(ProtoCrewMember kerbal, InternalSeat seat);" ?

I came across that method when playing around with cloning the iva set and making it appear in the command pod outside of the iva mode. This is an alternative approach to what sfr used for the sfr Command Pod mod.

To clone the IVA I did the following.

	imodel = (InternalModel)Instantiate(part.internalModel); //clone internal
	localProtoModuleCrew = new List<ProtoCrewMember>();
	foreach (ProtoCrewMember increw in part.protoModuleCrew)
	{
		ProtoCrewMember crew = new ProtoCrewMember(increw); //copy crew
		crew.seatIdx = increw.seatIdx; //set seat id of clone
		localProtoModuleCrew.Add(crew); 
	}

	foreach (ProtoCrewMember crew in localProtoModuleCrew )
	{
		InternalSeat seat = imodel.seats[crew.seatIdx];
		imodel.SitKerbalAt(crew, seat);
	}

	imodel.SetVisible(true);
	imodel.SpawnCrew(); //draws crew

        foreach (InternalSeat seat in imodel.seats)
        {
            Kerbal kerbal = seat.kerbalRef;

            if (kerbal != null)
            {
                kerbal.IVADisable();
                KerbalGUIManager.RemoveActiveCrew(kerbal);//so that there are no evil twins in the gui
            }

        }

	//helper methods to make the kerbals and IVA visible
	swichLayers(imodel.transform, 20, 0);
	swichLayers(imodel.transform, 16, 0);

	//Move the model into position ect...

Hope this helps. Let me know if you want the source to the unfinished plugin its messy and very buggy, but it does work. It just ignores crew changes and creates evil twins in iva mode .

[Alskari]

Interesting stuff. I've been having issues getting the sfr code to work for me. Spawning the IVA models while not in IVA is really inconsequential for me, the real objective is getting kerbals to spawn while preserving the normal IVA mode option. Currently sfr's code makes the IVA dependent upon the orientation and COM of the root part which was used to begin building. Majorly inconvenient.

Would you mind horribly if I sent you some messages begging for help?

[JPLRepo]

I know this is an old thread. but for days I have been banging my head trying to figure this out as well...

If you do

thatPart.internalModel.part.vessel.SpawnCrew();

then the internal model seems to just disappear.

BUT, If you do a Protocrewmember kerbal.seat.SpawnCrew();

it DOESN'T. no more disappearing internal.

the only down side is the portrait camera spawns on the far right end instead of in seat order.

Edited July 3, 2015 by JPLRepo