[1.9-1.10] Hangar

[colmo]

Was just testing out the Ground Hangar. I recovered it, which recovered the vehicles inside it (or at least the first on the list, I didn't look closely - it was a KSO Fire Engine, it only recovered 98% despite being on the runway, possibly it didn't count as being on the runway, just very close), but left the structure there. On my next launch, my craft spawned clipped through it and the two things writhed about in a display of physics glitchiness.

The green/brown textures look much better in-game than they did in videos or thumbnails, btw. I think the details (it's quite a subtle pattern) were smeared by video and image compression. They suit ground structures, if not space-bound ones.

Edited September 1, 2014 by colmo

[allista]

Was just testing out the Ground Hangar. I recovered it, which recovered the vehicles inside it (or at least the first on the list, I didn't look closely - it was a KSO Fire Engine, it only recovered 98% despite being on the runway, possibly it didn't count as being on the runway, just very close), but left the structure there. On my next launch, my craft spawned clipped through it and the two things writhed about in a display of physics glitchiness.

The green/brown textures look much better in-game than they did in videos or thumbnails, btw. I think the details (it's quite a subtle pattern) were smeared by video and image compression. They suit ground structures, if not space-bound ones.

Sorry, I didn't quite understand the situation you've described. What structure was left on runaway?

Anyway. If you recover a hangar with some stored vessels (i.e. they are invisible and appear in the list in the GUI), their cost is just added to the cost of the hangar, so they themselves are not, technically speaking, recovered, just their costs. On the other hand, if some vessel is just positioned inside the hangar (e.g. you drove your rover into the inactive ground hangar and left it there) and then you recover the hangar, positioned vessel is not recovered; the hangar just disappears from beneath. Maybe the vessel that was left was not stored, just located inside the hangar?

[colmo]

I'll have to rerun the test to be sure, I didn't have time.

The hangar was still on the runway when I launched from the SPH, to be clear. The game did not inform me it was still there, or offer to recovery it first.

[AccidentalDisassembly]

Quick question - I fiddled with the hangar configs to achieve ludicrous scaling & space inside one. Things came up:

1. Ground hangars at least (didn't try others) won't scale beyond 10.0 even if the maximum scale is set higher in the config.

2. Would it be possible to make a configurable "volume multiplier," or something to that effect, so that one could place a hangar on a very large ship and simulate the idea that the hangar part is just the entrance to a larger bay? Something that would increase the available volume in a hangar without increasing scale, optionally.

3. This may be purely an issue with TweakScale, but I found it odd - other parts don't do this: When attaching a hangar to another part (both scaled up), the hangar's point of attachment will change upon reloading the vessel. It *seems* like the hangar's node moves to the very center of the part it's attached to; maybe it's moving to where the attached-to node would be had the part not been scaled, and isn't correctly resetting itself on load, or something.

Awesome, awesome idea & parts.

[colmo]

2. Would it be possible to make a configurable "volume multiplier," or something to that effect, so that one could place a hangar on a very large ship and simulate the idea that the hangar part is just the entrance to a larger bay? Something that would increase the available volume in a hangar without increasing scale, optionally.

I'm simply planning to shove a Habitable Hangar below the deck of an ID aircraft carrier. An extra node on the bottom, at the centre of mass, would be most welcome for this purpose.

[allista]

Quick question - I fiddled with the hangar configs to achieve ludicrous scaling & space inside one. Things came up:

1. Ground hangars at least (didn't try others) won't scale beyond 10.0 even if the maximum scale is set higher in the config.

2. Would it be possible to make a configurable "volume multiplier," or something to that effect, so that one could place a hangar on a very large ship and simulate the idea that the hangar part is just the entrance to a larger bay? Something that would increase the available volume in a hangar without increasing scale, optionally.

3. This may be purely an issue with TweakScale, but I found it odd - other parts don't do this: When attaching a hangar to another part (both scaled up), the hangar's point of attachment will change upon reloading the vessel. It *seems* like the hangar's node moves to the very center of the part it's attached to; maybe it's moving to where the attached-to node would be had the part not been scaled, and isn't correctly resetting itself on load, or something.

Awesome, awesome idea & parts.

1. There's another config in the plugin directory: common.cfg. The limit is defined there.

2. Technically, with some code changes, that's possible, but I don't see why not to just use a huge hangar. Isn't it more realistic that way? And vessels will still be limited with the geometry hangar space.

3. You mean some part is scaled with Tweak Scale, and the scaled hangar is attached to it? I'll check it.

Thanks)

[AccidentalDisassembly]

1. There's another config in the plugin directory: common.cfg. The limit is defined there.

2. Technically, with some code changes, that's possible, but I don't see why not to just use a huge hangar. Isn't it more realistic that way? And vessels will still be limited with the geometry hangar space.

3. You mean some part is scaled with Tweak Scale, and the scaled hangar is attached to it? I'll check it.

Thanks)

Thanks for the reply! A bit of clarification on my poor wording:

1. I know about common.cfg, I defined the maximum to be 12.0 - but the part will not scale to 12.0, it only goes to 10.0 no matter what arbitrarily large number I enter into the config. Not a question of tech limits either. Maybe I've done something wrong with my install.. or could be some other of the 9583985938 mods I'm using that's mysteriously interfering.

2. Naturally that would be more realistic, but disappearing ships isn't realistic either Mostly my idea was that it would be cool-ish to imagine that the hangar part is actually the entrance to the ship's hangar (which would really have to be quite large to actually hold a large number of spaceplanes aircraft-carrier style, since you couldn't disassemble all the parts), put a texture that looks like a set of doors at the back, and pretend that what the hangar actually does is grab a spaceplane and send it somewhere in the belly of the absurdly large ship I'm trying to build. Really not a terribly important feature, but it'd be neat if we could fiddle with what the hangar considers its volume to be (if the code changes wouldn't be hard).

I guess it would be equally realistic though just to make an absurdly long or large hangar. Would it be possible to change the aspect ratio of the ground hangars like the inline hangars can (I think... right?)? That would also be interesting.

3. Right - Tweakscaled hangar meets tweakscaled part, reloading causes hangar to move around relative to... something. I don't know whether it happens or not with non-tweakscaled stuff, sorry for lame info. The other thing I noticed, which may or may not be related: I can't figure out how to replicate it, but in some cases, when you attach the most rearward node of the hangar to the node of another part (specifically in this case a B9 2x1 hangar part), the node on the part it is attached to does not become "occupied" - other things can still attach to it. You can see this when you attach a hangar to something hollow, then pick the hollow part up - node still visible. This may also boil down to something I don't understand about the parts in play, though.

Also - another feature that would be helpful: is there any way to make it so that the hangars could surface attach to something without being sunk halfway into the part they're attaching to? Is it the node_attach or whatever in the cfg that determines how things surface attach? If so, I could try to relocate the attach nodes so it works like this.

Finally, this may be intentional, but the smaller ground hangar's attach nodes are off-center vertically, whereas the larger ground hangar's nodes are centered. Result: hard to place the non-habitable ground hangar inside the aforementioned absurdly large ship I'm building.

Sorry - I realize as I type this that my suggestions are basically all geared to a very nitpicky, specific case. Not sure if they'd be useful for the rest of the people who use your mod! Ack.

[passinglurker]

1. There's another config in the plugin directory: common.cfg. The limit is defined there.

2. Technically, with some code changes, that's possible, but I don't see why not to just use a huge hangar. Isn't it more realistic that way? And vessels will still be limited with the geometry hangar space.

3. You mean some part is scaled with Tweak Scale, and the scaled hangar is attached to it? I'll check it.

Thanks)

2. Asteroid hangars anyone?

[allista]

2. Asteroid hangars anyone?

I never tried it, but since asteroids are technically vessels, a hangar big enough should store an asteroid with problem.

[AccidentalDisassembly]

I never tried it, but since asteroids are technically vessels, a hangar big enough should store an asteroid with problem.

I think it was more that one could attach a hangar to an asteroid, and make the asteroid into a hangar... or my own biases are showing.

[allista]

Thanks for the reply! A bit of clarification on my poor wording:

1. I know about common.cfg, I defined the maximum to be 12.0 - but the part will not scale to 12.0, it only goes to 10.0 no matter what arbitrarily large number I enter into the config. Not a question of tech limits either. Maybe I've done something wrong with my install.. or could be some other of the 9583985938 mods I'm using that's mysteriously interfering.

2. Naturally that would be more realistic, but disappearing ships isn't realistic either Mostly my idea was that it would be cool-ish to imagine that the hangar part is actually the entrance to the ship's hangar (which would really have to be quite large to actually hold a large number of spaceplanes aircraft-carrier style, since you couldn't disassemble all the parts), put a texture that looks like a set of doors at the back, and pretend that what the hangar actually does is grab a spaceplane and send it somewhere in the belly of the absurdly large ship I'm trying to build. Really not a terribly important feature, but it'd be neat if we could fiddle with what the hangar considers its volume to be (if the code changes wouldn't be hard).

I guess it would be equally realistic though just to make an absurdly long or large hangar. Would it be possible to change the aspect ratio of the ground hangars like the inline hangars can (I think... right?)? That would also be interesting.

3. Right - Tweakscaled hangar meets tweakscaled part, reloading causes hangar to move around relative to... something. I don't know whether it happens or not with non-tweakscaled stuff, sorry for lame info. The other thing I noticed, which may or may not be related: I can't figure out how to replicate it, but in some cases, when you attach the most rearward node of the hangar to the node of another part (specifically in this case a B9 2x1 hangar part), the node on the part it is attached to does not become "occupied" - other things can still attach to it. You can see this when you attach a hangar to something hollow, then pick the hollow part up - node still visible. This may also boil down to something I don't understand about the parts in play, though.

Also - another feature that would be helpful: is there any way to make it so that the hangars could surface attach to something without being sunk halfway into the part they're attaching to? Is it the node_attach or whatever in the cfg that determines how things surface attach? If so, I could try to relocate the attach nodes so it works like this.

Finally, this may be intentional, but the smaller ground hangar's attach nodes are off-center vertically, whereas the larger ground hangar's nodes are centered. Result: hard to place the non-habitable ground hangar inside the aforementioned absurdly large ship I'm building.

Sorry - I realize as I type this that my suggestions are basically all geared to a very nitpicky, specific case. Not sure if they'd be useful for the rest of the people who use your mod! Ack.

1. Then it's a bug. Thanks!

2.1 It's not impossible even now: through a proper part model with huge (invisible) hangar-space mesh and a launch-position transform located near one of its ends. But then one could attach such hangar to a small ship and still get this huge hangar. To overcome this (to somehow dynamically define hangar space depending on other ship's parts or like) some reworking of the core hangar implementation is needed. So I need to think about it carefully, especially in the light of the aforementioned "asteroid hangars" in your interpretation. I realy like the latter idea.

2.2 Changes to aspect ratio are controlled by the flag in the part.cfg (sizeOnly, aspectOnly). But if you start to change it for the ground hangar, its door would also be scaled during the animation in the longitude direction; i.e the door will start to stretch when the open animation is playing. That looks terrible! Try it

3.1 About TweakScale problem: understood.

3.2 About B9 part: it seems that the part has two identical or located very closely attach nodes. You use one, and another one is left. Check .cfg of that part.

4. Surface attachmend is controlled by node_attach, that's correct. So you may add such node to a hangar, yea. Meanwhile I work, amongst other things, on radial-to-stack adapters for hangars.

5. This is intentional, because the line of center of mass is shifted to the bottom of the hangar. What is UNintentional is that I forgot to move attachment node of the Inhabitable Ground Hangar =( Still, this may be a matter for discussion. Maybe leave the nodes geometrically centered? But then it'll displace CoM of a ship if attached.

[passinglurker]

I think it was more that one could attach a hangar to an asteroid, and make the asteroid into a hangar... or my own biases are showing.

Thats what I meant

[AccidentalDisassembly]

1. Then it's a bug. Thanks!

2.1 It's not impossible even now: through a proper part model with huge (invisible) hangar-space mesh and a launch-position transform located near one of its ends. But then one could attach such hangar to a small ship and still get this huge hangar. To overcome this (to somehow dynamically define hangar space depending on other ship's parts or like) some reworking of the core hangar implementation is needed. So I need to think about it carefully, especially in the light of the aforementioned "asteroid hangars" in your interpretation. I realy like the latter idea.

I very clearly don't understand much about how the hangar actually works, but I gather there's a way that it calculates the total volume of various ships inside it - could it calculate the total volume of the ship attached to it (minus the hangar) and then add an arbitrary multiple of that volume (say, 1/3 or 1/2) to its own internal storage space?

Another option - just throwing things out there - there could be a "hangar extension" part that, when either attached to the hangar itself or to the ship somewhere, increases the volume of that hangar... That would probably make decent sense realism-wise too. A hangar annex, if you will. For immersion's sake, it would probably rely on the hangar looking more like an antechamber or something. Though the calculation of ship volume might be a little more universally useful.... cf. the asteroids.

Another alternative might just be to give a fixed number for the volume of a given hangar, then an individual user could decide what's realistic or not, but that definitely would be weird in terms of the potential for a very small ship to have a gargantuan hangar and whatnot.

2.2 Changes to aspect ratio are controlled by the flag in the part.cfg (sizeOnly, aspectOnly). But if you start to change it for the ground hangar, its door would also be scaled during the animation in the longitude direction; i.e the door will start to stretch when the open animation is playing. That looks terrible! Try it

Ah yes - didn't think about that. That does sound ugly...

3.2 About B9 part: it seems that the part has two identical or located very closely attach nodes. You use one, and another one is left. Check .cfg of that part.

That's the weird thing - it really only does have one node in the middle on each end of it, and the hangar obviously only has the one node on the very end of it too, so the whole thing seemed very bizarre. Maybe it has to do with them being tweakscaled as well?

4. Surface attachmend is controlled by node_attach, that's correct. So you may add such node to a hangar, yea. Meanwhile I work, amongst other things, on radial-to-stack adapters for hangars.

Here's what I wrote in the configs for the ground hangars - seems to work (small gap appears still when scaled very large, but I don't think it's terrible). Not centered on the part, probably could be improved:

Habitable ground hangar:
node_attach = 0.0, 0.0, 0.888, 0, 0, -1

Other ground hangar:
node_attach = 0.0, 0.0, 0.638, 0, 0, -1

5. This is intentional, because the line of center of mass is shifted to the bottom of the hangar. What is UNintentional is that I forgot to move attachment node of the Inhabitable Ground Hangar =( Still, this may be a matter for discussion. Maybe leave the nodes geometrically centered? But then it'll displace CoM of a ship if attached.

Huh, I didn't know node location determined mass distribution of the part, but I suppose it would make sense to have the mass down low. Having a node in the middle is useful for sticking the hangar inside other hollow parts, at least.

[allista]

I very clearly don't understand much about how the hangar actually works, but I gather there's a way that it calculates the total volume of various ships inside it - could it calculate the total volume of the ship attached to it (minus the hangar) and then add an arbitrary multiple of that volume (say, 1/3 or 1/2) to its own internal storage space?

Another option - just throwing things out there - there could be a "hangar extension" part that, when either attached to the hangar itself or to the ship somewhere, increases the volume of that hangar... That would probably make decent sense realism-wise too. A hangar annex, if you will. For immersion's sake, it would probably rely on the hangar looking more like an antechamber or something. Though the calculation of ship volume might be a little more universally useful.... cf. the asteroids.

Another alternative might just be to give a fixed number for the volume of a given hangar, then an individual user could decide what's realistic or not, but that definitely would be weird in terms of the potential for a very small ship to have a gargantuan hangar and whatnot.

The thing is: a hangar not only calculates the volume of the internal space, but also considers its physical boundaries, so it's not enough to just "add some volume", I need to separate volume calculations form geometry calculations, so that checks that prevent storing ships that are too big to launch (i.e. will intersect with the hangar walls) will still work. So there's no problem in calculating ship's volume (it is done already for the info part of the GUI), but still. I honestly will think about some good way to implement such "gateway hangars", but in due time. For now there are several long asked improvements I'm working on that need to be finished and published.

That's the weird thing - it really only does have one node in the middle on each end of it, and the hangar obviously only has the one node on the very end of it too, so the whole thing seemed very bizarre. Maybe it has to do with them being tweakscaled as well?

Very strange. I can't imagine how's it possible. Will investigate.

Here's what I wrote in the configs for the ground hangars - seems to work (small gap appears still when scaled very large, but I don't think it's terrible). Not centered on the part, probably could be improved:

Habitable ground hangar:
node_attach = 0.0, 0.0, 0.888, 0, 0, -1

Other ground hangar:
node_attach = 0.0, 0.0, 0.638, 0, 0, -1

If you have Blender installed you may just open the corresponding model and pick the needed coordinates from there. Just remember to swap Y and Z coordinates.

Huh, I didn't know node location determined mass distribution of the part, but I suppose it would make sense to have the mass down low. Having a node in the middle is useful for sticking the hangar inside other hollow parts, at least.

No, the center of mass is determent by the position of the zero point of the part's frame of reference. I just thought that it's better to have nodes in the line with the CoM, in case someone would actually try to add the hangar to a ship. Don't know if it's a good idea.

[AccidentalDisassembly]

Not that you need any more questions from me, but... I'm having an issue that makes it difficult to get rovers in and out of hangars. When I manage to get a rover inside one, the wheels almost completely lose traction - as if the surface of the hangar were greased. Momentum can help get the rover in, but getting one out is quite difficult, and impossible if the hangar is at an angle at all. Is this normal?

Also, it is impossible to switch vehicles if the rover doesn't get taken by the hangar, because it slides around the hangar surface - motion = no switchy Have to wait for motion to cease.

EDIT: Thing I said about FAR not applicable.

Edited September 9, 2014 by AccidentalDisassembly

[Nori]

Yo, that's a known FAR bug that has apparently been fixed in dev. Hopefully it'll be released soon since it is a really annoying bug.

[allista]

About friction: that was a known problem, but I thought I've fixed it in the previous releases. Well, not fixed, because I still can't understand why it's happening, but made a workaround and tested it thoroughly, it seemed. You do use the last version (1.1.1.1), right?

And what it was about FAR?

Edited September 9, 2014 by allista

[AccidentalDisassembly]

About friction: that was a known problem, but I thought I've costs it in the previous releases. Well, not fixed, because I still can't understand why it's happening, but made a workaround and tested out thoroughly, it seemed. You do use the last version (1.1.1.1), right?

And what it was about FAR?

I'm using 1.1.1.1, so far as I know - so says the ZIP file, anyway. I tried with both stock wheels and non-stock wheels - really weird stuff. Stock wheels rotate very, very slow and go nowhere, but turning seems possible-ish... or perhaps that's a reaction wheel at work...

The FAR thing was an assumption I made that since a FAR error was happening when a craft was eaten by the hangar, it might be related to the hangar - but it's not after all.

[allista]

I'm using 1.1.1.1, so far as I know - so says the ZIP file, anyway. I tried with both stock wheels and non-stock wheels - really weird stuff. Stock wheels rotate very, very slow and go nowhere, but turning seems possible-ish... or perhaps that's a reaction wheel at work...

That's very strange! I need some details to reproduce it. It works fine on my end, both on Kerbin and Mun.

[allista]

AccidentalDisassembly, I want to invite you to the discussion of the gateway hangar's problem. See the "Gateway Hangars" milestone on the GitHub.

[Nori]

About friction: that was a known problem, but I thought I've fixed it in the previous releases. Well, not fixed, because I still can't understand why it's happening, but made a workaround and tested it thoroughly, it seemed. You do use the last version (1.1.1.1), right?

And what it was about FAR?

The second part he posted (about the flickering GUI etc). It is a known error in FAR that apparently has been fixed in dev.

[AccidentalDisassembly]

Put a comment on GitHub - hope it's helpful. I'm personally in favor of the automatic-calculation method based on mass to volume ratio, but of course I don't know how much of KSP actually works or whether that would be possible.

RE: the hangars being slippery, here's what I did:

1. Put 4 wheels (tracks from lo-fi, in my case) on the hangar part, drive it off the runway after spawning.

2. Make a rover in the SPH, spawn it, drive it over to the (opened, active) hangar.

3. Wheels don't grip inside the hangar, but you can get momentum to send you to the back where the hangar will ingest you.

4. Spawn rover in hangar - it appears in midair, like normal, drops onto hangar floor. Wheels have no traction, can't drive out.

I have a bunch of mods installed, could be interference from something else.

Also, is it possible that I actually don't have the most recent version? The ZIP says 1.1.1.1, but...

Edited September 9, 2014 by AccidentalDisassembly

[allista]

Put a comment on GitHub - hope it's helpful. I'm personally in favor of the automatic-calculation method based on mass to volume ratio, but of course I don't know how much of KSP actually works or whether that would be possible.

RE: the hangars being slippery, here's what I did:

1. Put 4 wheels (tracks from lo-fi, in my case) on the hangar part, drive it off the runway after spawning.

2. Make a rover in the SPH, spawn it, drive it over to the (opened, active) hangar.

3. Wheels don't grip inside the hangar, but you can get momentum to send you to the back where the hangar will ingest you.

4. Spawn rover in hangar - it appears in midair, like normal, drops onto hangar floor. Wheels have no traction, can't drive out.

I have a bunch of mods installed, could be interference from something else.

Also, is it possible that I actually don't have the most recent version? The ZIP says 1.1.1.1, but...

Yea, I saw and thinking over the answer. Thanks.

You may check the version of the Hangar.dll itself. If you use Windows, it should appear somewhere in the file properties or on mouseover. Because what you describe is what was happening before v1.1.1; I've just checked the version of .dll from the v1.1.1.1 zip from GitHub, and it is the new version with the workaround. I will check the behavior myself on Sunday, when I return home. Meanwhile: does anyone else have this issue?

[AccidentalDisassembly]

It's 1.1.1.1 in the DLL version - trying it out right now on a (relatively) cleaner install with just Infernal Robotics and some general tools like FS and EditorExtensions

EDIT: actually tried it on an entirely clean install, still happens.

Edited September 10, 2014 by AccidentalDisassembly

[Kurbal.Fashion=True]

My apologies because this may already have been posted, but I cannot get this thing to work properly. I'm running kspapiextensions as well as Infernal Robotics and Mulitwheels7. I haven't used module manager yet, and I am terribly clueless on how to use it in this scenario. I have unpacked the folder into my GameData folder like everything else, when I start KSP I can see it loading the files from the Hangar folder, and Module Manager comes up on my loading screen. I then continue to my sandbox mode only to not find any new parts either in SPH or VAB. Any suggestions? Thanks!