[1.9-1.10] Hangar

passinglurker · December 3, 2014

OK, lets differentiate the proposed ideas:
light hangars with reduced functionality; what could be limited:
one ship at a time
add ships only in editor
no crew/resources transfer
By combining all three we may get almost what you want. I'll consider it.
But to automatically fix a ship inside a cargo bay with struts, instantly, without any Kerbals involved? No, not without machinery.
And do remember: it will remove only ~30% of the weight of the Inline Hangar.

Not so hot about "only add ships in editor", and "no crew/resource transfer" I understand that it doesn't seem realistic, but the fact of the matter of is many people are not going to look at this mod as some new gameplay aspect to balance they are going to be looking at it as a game performance and quality of life improvement. They want a way to cut wobble and part count while still being able to bring probes and landers with minimal harm to the space traveling performance of the their craft. As such what they'd want is a hangar that weighs no more than a stock cargo bay+docking port of equivalent volume. That being said I'm not saying the hangars should be rebalanced to be magic you are right in saying an orbital carrier or dry dock would have a lot of heavy infrastructure I just think that "one ship at a time" and "no transferring ships between storage spaces" are adequate limitations given what you can already do with stock docking ports(i.e. attach and detach repeatedly and transfer crew and resources) while still keeping full blown hangars relevant not to mention with storage expansion parts full blown hangars would be even more economical that lightweight limited hangars when deployed on a larger scale.

fairing hangar, meaning a container that is attached to the head of a rocket and that spits out another ship forward on stage separation. There are two main problems here: vessel switching during acceleration and gravity turn; and inability to store crewed ships in-editor. So as appealing as the idea may seem, I still consider it impractical, if at all doable.

Probably best not to have it stageable then. Is it possible to have a hangar refuse to spawn a ship while throttled up or spinning? the spawning and decoupling could still be done safely either before the circularization burn or in orbit(assuming spawning and decoupling were separate steps and not done at the same time). Parts with the classification of "fairing hangar" could be slightly lighter, much cheaper, and available in the tech tree earlier than their "lightweight limited" hangar counterparts at the expense of being limited to a one time use and having resources be non transferable. these would be useful for delivering exploration probes and rovers that are not meant to be part of a base infrastructure or otherwise have a home to operate out of at the very least, but you are right not being able to store the crew is a problem that would limit this to a bit of a niche. Is it possible to give the fairing a dynamic number of crew spots based on the number of crew slots the ship its holding has and have them be automatically transferred into their places on vehicle spawn?

convert existing parts to hangars -- in the v2.0-BETA I added Hangar Extensions. They are more-lightweight containers without doors that can have ships inside and pass them to each other, but not store/launch them. This allows to expand storage space while having the same small docking space with doors (inline hangar). The module HangarStorage that turns a part into a Hangar Extension does not require anything particular from the model, so it can be added to any part that seems appropriate. But you still need a hangar attached to that part to store/launch ships. As for the real conversion of a third-party part into a hangar, it's not possible because the Hangar module needs specific model design with several emty transforms and invisible meshes (like ModuleLandingLeg or ModuleWheel).

Would it be possible to use config file MODEL nodes to weld these required invisible meshes and empty transforms to the 3rd party part one would like to use as a hangar? if its possible then all we'd need it a set of these invisible meshes in standard sizes that aren't tied to a visible models and any user with a text editor and a welding tutorial can turn their favorite part into a hangar.

SSTO hangar -- I've already made (but not published yet) the non-resizable Mk3 compatible hangar. It is very light for its volume of almost 90m3, has enough fuel to get to orbit and return, has a door at the back that works as a ramp (like in cargo planes). It is made in the same paradigm and is still big and heavy, but is tuned for space-planes; and I already flew it several times to orbit and back.

aren't they phasing out the old mk3 parts in 0.90? well if what I said above about welding holds true I suppose it could be considered a moot point as you could easily make a hangar using whatever cargo bay models squad puts out.

Edited December 3, 2014 by passinglurker

allista · December 3, 2014

aren't they phasing out the old mk3 parts in 0.90?

Could you be more verbose about it? I heard nothing :confused:

*I'll answer the rest a little later

passinglurker · December 3, 2014

Could you be more verbose about it? I heard nothing
*I'll answer the rest a little later

heh sorry here are my references

https://twitter.com/maxmaps/status/537379378486083585

http://forum.kerbalspaceprogram.com/threads/101200-New-Mk3-Parts-Partially-Unveiled

allista · December 4, 2014

Not so hot about "only add ships in editor", and "no crew/resource transfer" I understand that it doesn't seem realistic, but the fact of the matter of is many people are not going to look at this mod as some new gameplay aspect to balance they are going to be looking at it as a game performance and quality of life improvement. They want a way to cut wobble and part count while still being able to bring probes and landers with minimal harm to the space traveling performance of the their craft. As such what they'd want is a hangar that weighs no more than a stock cargo bay+docking port of equivalent volume. That being said I'm not saying the hangars should be rebalanced to be magic you are right in saying an orbital carrier or dry dock would have a lot of heavy infrastructure I just think that "one ship at a time" and "no transferring ships between storage spaces" are adequate limitations given what you can already do with stock docking ports(i.e. attach and detach repeatedly and transfer crew and resources) while still keeping full blown hangars relevant not to mention with storage expansion parts full blown hangars would be even more economical that lightweight limited hangars when deployed on a larger scale.
Probably best not to have it stageable then. Is it possible to have a hangar refuse to spawn a ship while throttled up or spinning? the spawning and decoupling could still be done safely either before the circularization burn or in orbit(assuming spawning and decoupling were separate steps and not done at the same time). Parts with the classification of "fairing hangar" could be slightly lighter, much cheaper, and available in the tech tree earlier than their "lightweight limited" hangar counterparts at the expense of being limited to a one time use and having resources be non transferable. these would be useful for delivering exploration probes and rovers that are not meant to be part of a base infrastructure or otherwise have a home to operate out of at the very least, but you are right not being able to store the crew is a problem that would limit this to a bit of a niche. Is it possible to give the fairing a dynamic number of crew spots based on the number of crew slots the ship its holding has and have them be automatically transferred into their places on vehicle spawn?
Would it be possible to use config file MODEL nodes to weld these required invisible meshes and empty transforms to the 3rd party part one would like to use as a hangar? if its possible then all we'd need it a set of these invisible meshes in standard sizes that aren't tied to a visible models and any user with a text editor and a welding tutorial can turn their favorite part into a hangar.
aren't they phasing out the old mk3 parts in 0.90? well if what I said above about welding holds true I suppose it could be considered a moot point as you could easily make a hangar using whatever cargo bay models squad puts out.

1. I believe that people who are "looking at it [Hangar] as a game performance and quality of life improvement" are just not my target group. Simply because I can't do both things (realistic challenging mode and performance and quality of life mod) at the same time, as at some point the two become mutually exclusive.

I agree, though, that one-at-a-time hangar may have transfer capabilities and store/launch in flight. As I said, I need to think it through carefully.

2. The problem is not in staging, but in spawning a vessel during throttling and acceleration. I will see what particular problems arise in this situation when I have some free time. Right now hangars do prevent launching when throttled, accelerated, spinning and such. And I thought this behavior to be incompatible with the fairings use-case. As for automatic crew transfer and dynamic crew compartment, technically this is possible. But it would be hard to imitate the right behavior: so that to the users it looked like they actually store a vessel with crew. This whole thing needs thorough investigation before I'm ready to discuss it more.

3. Hm... welding is certainly possible! I confess, I never thought about this :rolleyes: But I'm not sure about premade models for standard parts. I mean, I can convert the two stock cargo bays into hangars, but the models made for this could hardly be used anywhere else. So it is still requires a modder to have basic modeling skills and to know Unity-KSP workflow.

allista · December 4, 2014

heh sorry here are my references
https://twitter.com/maxmaps/status/537379378486083585
http://forum.kerbalspaceprogram.com/threads/101200-New-Mk3-Parts-Partially-Unveiled

Ah, that's not a problem if they're just remaking the models. It's fairly easy to adapt my model to the new form factor.

passinglurker · December 4, 2014

1. I believe that people who are "looking at it [Hangar] as a game performance and quality of life improvement" are just not my target group. Simply because I can't do both things (realistic challenging mode and performance and quality of life mod) at the same time, as at some point the two become mutually exclusive.
I agree, though, that one-at-a-time hangar may have transfer capabilities and store/launch in flight. As I said, I need to think it through carefully.

I'd agree if someone came in wanting the hangars to not add their own weight at all. The example of basing the balance off the weight of the stock cargo bays and docking ports was to leverage stock as a defence for certain balance choices and there for try to appease the broadest number of people on both sides of the issue (not everyone though to attempt such a feat is foolishness). so while you're point that there does come a point where the two are exclusive is correct there is also a happy medium to be found that would result in catching the widest possible target group.

but I haven't really run the numbers on "stock cargo bays vs. hangars" so I could be talking nonsense, but another way to keep the full feature hangars relevant should people simply not care what they can do and always choose the lightest option is to give the full featured hangars a killer app feature that the lesser hangars simply are not capable of. The idea that was kicked around before of being able to break a ship down into its individual parts and reassemble them in a different configuration inside full featured hangars without having to go through ExPLp's "grind into scrap metal"->"smelt into metal"->"forge into rocketparts"->"build into rocket" tool chain would be perfect for this, and make full featured hangars an excellent choice for repair missions(like those times you accidentally hit stage and break your ship in half (KAS can't fix this blunder I've tried)), and deep space tour missions(imagine cannibalizing you lander and assembling it into the efficiency optimal configuration for each planet(use ExPLp's for this and you'd need to haul an overkill factory that can make you ships from dirt around with you))

2. The problem is not in staging, but in spawning a vessel during throttling and acceleration. I will see what particular problems arise in this situation when I have some free time. Right now hangars do prevent launching when throttled, accelerated, spinning and such. And I thought this behavior to be incompatible with the fairings use-case. As for automatic crew transfer and dynamic crew compartment, technically this is possible. But it would be hard to imitate the right behavior: so that to the users it looked like they actually store a vessel with crew. This whole thing needs thorough investigation before I'm ready to discuss it more.

fair enough though I do think even with the hangars locked under acceleration and rotation these parts would be useful for one time deliveries to orbit and beyond as they can turn wobbly and off center abominations into single solid stable parts without the weight of unnecessary features like hangar resuabulity.

3. Hm... welding is certainly possible! I confess, I never thought about this But I'm not sure about premade models for standard parts. I mean, I can convert the two stock cargo bays into hangars, but the models made for this could hardly be used anywhere else. So it is still requires a modder to have basic modeling skills and to know Unity-KSP workflow.

most parts(but admittedly not all) are typically made to be multiples of 1.25 meters in length and diameter and cargo bay mods are no exception. Making a few premade meshes for the various common configurations of .625, 1.25, 2.5, 3.75 length and diameter won't catch all the parts and may result in some wasted space for some parts, but it'd be casting out the biggest net to the widest audience (more people know how to edit config files than use unity). case and point for multiples of 1.25 is this set of tweakscale compatible public domain cargo bays

allista · December 5, 2014

I'd agree if someone came in wanting the hangars to not add their own weight at all. The example of basing the balance off the weight of the stock cargo bays and docking ports was to leverage stock as a defence for certain balance choices and there for try to appease the broadest number of people on both sides of the issue (not everyone though to attempt such a feat is foolishness). so while you're point that there does come a point where the two are exclusive is correct there is also a happy medium to be found that would result in catching the widest possible target group.

I do agree with your reasoning. But do so very reluctantly. Because the Squad do not balance their parts at all. It almost seems they just invent all the figures. It's normal for them to make one part in a series twice as big as the other and to make it twice as heavy, as if it was an infinitely thin string. But in the course of the development I already had to sacrifice many real-world-like calculated values for the sake of uniformity with the rest of the game content.

but I haven't really run the numbers on "stock cargo bays vs. hangars" so I could be talking nonsense, but another way to keep the full feature hangars relevant should people simply not care what they can do and always choose the lightest option is to give the full featured hangars a killer app feature that the lesser hangars simply are not capable of. The idea that was kicked around before of being able to break a ship down into its individual parts and reassemble them in a different configuration inside full featured hangars without having to go through ExPLp's "grind into scrap metal"->"smelt into metal"->"forge into rocketparts"->"build into rocket" tool chain would be perfect for this, and make full featured hangars an excellent choice for repair missions(like those times you accidentally hit stage and break your ship in half (KAS can't fix this blunder I've tried)), and deep space tour missions(imagine cannibalizing you lander and assembling it into the efficiency optimal configuration for each planet(use ExPLp's for this and you'd need to haul an overkill factory that can make you ships from dirt around with you))

Oh, I can't even start to imagine how that could be implemented! :confused: To my knowledge, the only way to create a new craft configuration is to use the VAB/SPH. So such reassembly will require the visit to KSC. And you need to limit parts that could be used in construction and their number and all. Then comes "sending" the new blueprints back to the ship... and there you need some kerbals and expendables and resources (apart from the parts) and time managment. It's a whole new mod you're talking about! ;.;

So I'm still inclined to single-use no-transfer shell-only hangars and, maybe, heavier single-ship shell+docking-port hangars with transfers. But until I implement it in the code and make some models and calculate their masses, I can't tell if it'll work out.

fair enough though I do think even with the hangars locked under acceleration and rotation these parts would be useful for one time deliveries to orbit and beyond as they can turn wobbly and off center abominations into single solid stable parts without the weight of unnecessary features like hangar resuabulity.

I've made some tests. The biggest problem is the acceleration (both linear and rotational):

Ship A accelerates.
Ship B is spawned inside Ship A. During the process (while FlightManager switches active vessels) Ship A goes on rails for several frames.
In that time Ship A catches up with Ship B. But the physics haven't kicked in yet, so the ships start to intersect with each other...
"The party and the Krikkit warship looked, in their writhings, a little like two ducks, one of which is trying to make a third duck inside the second duck, whilst the second duck is trying very hard to explain that it doesn't feel ready for a third duck right now, is uncertain that it would want any putative third duck anyway, and certainly not whilst it, the second duck, was busy flying." Douglas Adams.
Then the physics starts and both ships are blown to pieces.

But If you exclude the acceleration (at least larger than ~1m/s2) and spawn the ship only after the previous stage's engines flamed out, it's not a problem. Add the initial relative speed of about 10m/s (using the Push Vessel Out option) and it starts looking pretty promising. I will definitely work further on it.

most parts(but admittedly not all) are typically made to be multiples of 1.25 meters in length and diameter and cargo bay mods are no exception. Making a few premade meshes for the various common configurations of .625, 1.25, 2.5, 3.75 length and diameter won't catch all the parts and may result in some wasted space for some parts, but it'd be casting out the biggest net to the widest audience (more people know how to edit config files than use unity). case and point for multiples of 1.25 is this set of tweakscale compatible public domain cargo bays

Well, as it's pretty simple, I'll make a single barrel-shaped hangar-conversion model of 1.25m and, say the length of the mk1 fuselage. For starters. And using a MODEL node one can rescale it to any other size and length anyway.

So, the bottom line is:

First of all, I will be developing FairingHangars, as they seem to be one of the most popular use cases.
I'll make a simple conversion model for barrel-shaped parts.
I'll consider another mass rebalancing of the existing hangars and adding lighter limited hangars. But the limitations of the latter will be severe as an implication of their simplicity.
And I will convert stock Mk2 cargo bays to hangars, but as they are just shells, I'm inclined to make them single-use.

passinglurker · December 5, 2014

I do agree with your reasoning. But do so very reluctantly. Because the Squad do not balance their parts at all. It almost seems they just invent all the figures. It's normal for them to make one part in a series twice as big as the other and to make it twice as heavy, as if it was an infinitely thin string. But in the course of the development I already had to sacrifice many real-world-like calculated values for the sake of uniformity with the rest of the game content.

the realism overhaul guys might be interested in you real world like calculated values for hangars and garages.

Oh, I can't even start to imagine how that could be implemented! To my knowledge, the only way to create a new craft configuration is to use the VAB/SPH. So such reassembly will require the visit to KSC. And you need to limit parts that could be used in construction and their number and all. Then comes "sending" the new blueprints back to the ship... and there you need some kerbals and expendables and resources (apart from the parts) and time managment. It's a whole new mod you're talking about!

I'm unfortunately not a coder, but I don't think you'd need to go as far as to make a custom VAB like editor with a limited parts catalog(though some of that idea may not be entirely impossible

)

What I imagine you'd need to start is a way to spawn in the ship from any old craft file you have saved that fits in the hangar collision mesh. Then you can simply make your reconfigured craft in the stock KSC VAB, save it, then focus on your hangar craft, open a simple GUI menu, and spawn it.

The next thing you'd need is a way to read what parts make up your stored craft and an option to disassemble your stored craft and break them down into their individual parts.

Finally you'd need a way to put the two together where when a craft is going to be spawned the mod reads what parts it would need from the craft file and cross references that with the individual parts available in the hangar if all the needed parts are available the ship spawns and the parts used are deleted from storage. If they are not all available then the ship simply doesn't spawn. stuff like needing kerbals or their stats, build times, and construction consumables I would personally view as unnecessary as this idea was pitched as a simpler alternative to ExpLp. You are not building a ship from dirt here you are rearranging some space lego's you already had in orbit so its already much less powerful than ExpLp to balance out its greater convenience. Kerbals wouldn't be essential cause the full featured hangar as you explained is already packed with autonomous hardware for moving ships and their parts around all you need to do is add socket wrenches and tape dispensers, build times would be pointless because you can time warp through them, and consumables IMO should be omitted just for the sake of not cluttering the resource menu. The proposed counter balance to the power to reconfigure ships would simply be you need to carry a part that is heavy and much larger and bulkier than the parts you are taking apart and putting back together.

That being said needing kerbals, dealing with build times, and managing your duct tape supply would all make nice hard mode options but as you said this idea is borderline a whole mod in and of itself, and as such the initial implementation should be kept as simple as possible. and speaking of this being borderline a whole new mod while again I admit I know little of the arcane ways of the code I would imagine as this mod is one of the few that can spawn a ship some where other than the KSC launchpad or runway that much of the needed ground work has already been laid.

FreeThinker · December 7, 2014

Technically, you could implement the VAB editing method using the same tricks used by Kerbal Construction Time. Basicly you first make a back save, load a previous save in the VAB. After lauch copy and replace the old ship data in the backup file by the new ship data, then reload the backup file. I have done it several times myself using a simple text editor, but a simple regular expression should be able to do the same.

allista · December 9, 2014

Hangar v2.0.0-BETA.1 is now available for download

This is not a stable release and is intended to be used for testing

Please, report any bugs you encounter

This should be more stable than beta.0 but I would still recommend to backup your saves

allista · December 14, 2014

Hangar v2.0.0 is released

Please, see the main post of the thread for details

AccidentalDisassembly · December 15, 2014

A few notes of stuff I've encountered so far:

- Asteroid hangars: flipping awesome.

- On a mostly clean install of KSP 0.25 32-bit, many hangar parts (like hangar extenders) can't be "set down" in the VAB/SPH unless it's to attach them to another part - don't know why.

- There's no evidence in the VAB/SPH that the hangar extenders extend the space available in the hanger - I'm not saying it doesn't happen, just that there is no representation of this in the shipbuilding process. Is it possible to update the space value (Volume: x m3) in the right click menu in the VAB when an extender is added?

- I *think* I understand the visual indicators used to tell me how to align the various docking port stuff, but it would be clearer if the mark you use on the corner of each part, the green patches already there, were also arrows that all ought to point in the same direction.

---- Depending on the angle at which you view the part, EVERY side of the asteroid hatch can be bathed in both red and green light, or one color primarily, so if orientation in relation to this part is important, it's not going to be clear. It would be really clear with a green square like the other parts have. I think it looks pretty clear in space, but in the VAB it's not terribly.

---- The Roll-Sensitive Docking Port - pretty clear, but: there are two green markers on this part, and it's easy to see that the one on the side of one corner is meant to be aligned with the very similar one on the corner of the Roll-Sensitive Docking Port Adapter. But there's a second green mark on the FACE of the docking port too, which looks like it ought to align with a similar one on the Adapter, but can't. Slightly confusing, or perhaps I am just slow in the spatial perception department, hah! Very possible.

- Any plans for rectangular extenders for the ground hangars?

Additionally... any plans for a radially-attachable hangar entrance like we discussed long ago (kind of like the asteroid hangar entrance, but adjustable in size and aspect ratio, and perhaps a little deeper)? This could be stuck on the side of any hangar extension part, thereby allowing greater control over where the entrance to the hangar points - would be pretty cool if it's possible.

If there's some sort of simple MODULE{} that you can add to parts that allows them to be hangar extenders, one could quite easily create dedicated hangar-space parts for different mods - take a non-hollow HX part from B9, for example, empty out the fuel and put in the MODULE{} that gives hangar space, then radially attach a hangar entrance and boom: hangar time.

EDIT: Also, if I may make a request, I understand putting all the models and textures in the same folder - however, many of us delete parts that we don't want (to save RAM). It's much harder to do this when everything is thrown in one folder. Since many textures don't seem to be shared between very many parts, putting all of the adapters' configs in the same folder with their .mu and .png files - in short, organizing things more clearly when textures aren't shared - would be very helpful.

I ask this because Hangar uses some absurd number of texture files (100+), 32 of which are 1024x1024 or so, another 49 of which are 512x512, and the rest are 256x256 or smaller. That means that Hangar probably takes up ~ 80-100MB of RAM (unless I'm calculating wrong - I don't know, actually the 1024x1024 textures alone might take up 120MB) - for a small number of parts. RAM is at a premium even if using OpenGL [no shadows! ] considering how many good mods like yours are out there that people want to use.

In theory, considering how many parts look somewhat similar in this mod (which is a good thing), you could probably get away with using one 1024x1024 or 1024x2048 texture file if you're going to go down the texture sharing path. If not, please make it very easy for the rest of us to delete stuff.

Edited December 15, 2014 by AccidentalDisassembly

allista · December 15, 2014

- On a mostly clean install of KSP 0.25 32-bit, many hangar parts (like hangar extenders) can't be "set down" in the VAB/SPH unless it's to attach them to another part - don't know why.

What do you mean by "set down"? Can't be the root part? If so, it's strange as they should and in my tests only a few are set not to. (This is controlled by allowing/disallowing serface attachment to the part).

- There's no evidence in the VAB/SPH that the hangar extenders extend the space available in the hanger - I'm not saying it doesn't happen, just that there is no representation of this in the shipbuilding process. Is it possible to update the space value (Volume: x m3) in the right click menu in the VAB when an extender is added?

The is evidence: open the Edit Contents window of the hangr; if the extension is attached to the right node, you'll see two volume indicators (total and hangar's):

- I *think* I understand the visual indicators used to tell me how to align the various docking port stuff, but it would be clearer if the mark you use on the corner of each part, the green patches already there, were also arrows that all ought to point in the same direction.
---- The Roll-Sensitive Docking Port - pretty clear, but: there are two green markers on this part, and it's easy to see that the one on the side of one corner is meant to be aligned with the very similar one on the corner of the Roll-Sensitive Docking Port Adapter. But there's a second green mark on the FACE of the docking port too, which looks like it ought to align with a similar one on the Adapter, but can't. Slightly confusing, or perhaps I am just slow in the spatial perception department, hah! Very possible.

I'll try to make them arrows and see how it looks. Meanwhile, look at the documentation, there's a picture showing the right orientation. The key is to look in the direction from the docking ship to the port you're docking to. Then you'll see only one green light on your port (on one of the four lugs) and should align it with the only visible green light on the other port (on it's face). I'll try to invent some clearer indication, but it's not so easy really.

---- Depending on the angle at which you view the part, EVERY side of the asteroid hatch can be bathed in both red and green light, or one color primarily, so if orientation in relation to this part is important, it's not going to be clear. It would be really clear with a green square like the other parts have. I think it looks pretty clear in space, but in the VAB it's not terribly.

Orientation of the Hatch itself is not important. The standard port-starboard lights are there for the entourage mostly, but you can use them to your benefit if you attach the docking port in the same orientation (which is the default orientation when you just take the part from the library). Then, when you're attached to an asteroid, you can distinguish the left and the right sides of the hatch from the grater distance (when you're looking straight at it, of course).

- Any plans for rectangular extenders for the ground hangars?

Not yet, as it at least would require some new type of ground hangar. Present ones have all the machinery (and even kerbal-quarters) at the back; there's just nowhere to attach the extension to.

Additionally... any plans for a radially-attachable hangar entrance like we discussed long ago (kind of like the asteroid hangar entrance, but adjustable in size and aspect ratio, and perhaps a little deeper)? This could be stuck on the side of any hangar extension part, thereby allowing greater control over where the entrance to the hangar points - would be pretty cool if it's possible.

I'll think about it, but at the moment the whole system of Hangar Passages that allows extending hangar space is based on the stack nodes and their IDs. To transfer a ship I need two nodes attached to each other to check if it can pass through both, but surface-attached part has only one node without ID.

If there's some sort of simple MODULE{} that you can add to parts that allows them to be hangar extenders, one could quite easily create dedicated hangar-space parts for different mods - take a non-hollow HX part from B9, for example, empty out the fuel and put in the MODULE{} that gives hangar space, then radially attach a hangar entrance and boom: hangar time.

That was the point of the whole Hangar Extensions thing (well, that, and the asteroid hangars; they obviously use the same Hangar Passage system to transfer ships from the Gateway to an asteroid).

Look at the config of the small (the barrel one) Hangar Extension, at the HangarStorage module.

EDIT: Also, if I may make a request, I understand putting all the models and textures in the same folder - however, many of us delete parts that we don't want (to save RAM). It's much harder to do this when everything is thrown in one folder. Since many textures don't seem to be shared between very many parts, putting all of the adapters' configs in the same folder with their .mu and .png files - in short, organizing things more clearly when textures aren't shared - would be very helpful.
I ask this because Hangar uses some absurd number of texture files (100+), 32 of which are 1024x1024 or so, another 49 of which are 512x512, and the rest are 256x256 or smaller. That means that Hangar probably takes up ~ 80-100MB of RAM (unless I'm calculating wrong - I don't know, actually the 1024x1024 textures alone might take up 120MB) - for a small number of parts. RAM is at a premium even if using OpenGL [no shadows! ] considering how many good mods like yours are out there that people want to use.
In theory, considering how many parts look somewhat similar in this mod (which is a good thing), you could probably get away with using one 1024x1024 or 1024x2048 texture file if you're going to go down the texture sharing path. If not, please make it very easy for the rest of us to delete stuff.

I need to investigate the matter. All textures and models are in the same folder for the reason of sharing: I often use the same meshes and materials (e.g. windows and doors) in different models. Sorting this all into the appropriate subfolders will be hard, but maintaining it while developing more models will be harder still (at least it seems to me so). It may be more logical to divide the mod into several part packs instead.

As for the texture sharing: I always try to share textures, but despite the models looking alike, making a seamless texture with patterns and dirt and all prevents sharing in many cases. The real amount of the memory used is hard to determine, as obviously not all of the textures are loaded at the same time. Also, textures, normal maps and emissives need different amount of memory for the same dimensions as they use different bit depth. I'll try to reduce dimensions of some of the lesser textures (again, windows, lamps, doors etc.), but I can't use less than 1024 for big models -- it will look awful. Anyway, I recommend to use ActiveTextureManager as it applies internal video-card compression to textures and keeps them inside video-memory, freeing valuable RAM which is capped at 4gb in 32bit systems.

BTW, have you compared it with some other part mods: I'm sure mine is not the greatest memory hog = ^_^ =

allista · December 15, 2014

I ask this because Hangar uses some absurd number of texture files (100+)...

You should check your installation (have you removed the old version?): currently there should be 98 png files in Hangar/Parts/Models, only 52 of which are textures, the rest being normal maps and emissives.

I'll still be thinking of a way to reduce the memory footprint, though.

AccidentalDisassembly · December 15, 2014

You should check your installation (have you removed the old version?): currently there should be 98 png files in Hangar/Parts/Models, only 52 of which are textures, the rest being normal maps and emissives.
I'll still be thinking of a way to reduce the memory footprint, though.

All image files have to be loaded into memory, so every one of those counts in RAM - doesn't matter if it's a normal map or emissive, it still has pixels to read. That's why the load on demand mod exists, because that's what KSP DOESN'T do, unfortunately. I use the equivalent of ATM, 1/4 size textures, and still max out RAM - like I said, yours is one of a large number of good & really useful mods out there . I count 125 .png files in the Hangar folder I just unzipped... The ones in Spaces count too. Yes, I removed the old installation.

Also, I am comparing the number and size of png files per part - sure, other parts packs like B9 have a crazy number of textures too, but they also have a crazy number of parts.

Do you think it's possible to make the hangar extender work with radially attached parts at all? Maybe PASSAGE_NODE = node_attach, or something? Or somehow looking at parent part rather than node? The reason I wonder about that is just because then you as the modder could allow the user to create basically any shape & flavor of hangar, and put a hangar door facing any direction, too - including on a stack node like it is now, of course. If you had a variable size & aspect ratio entrance that looked like a somewhat deeper combination of the asteroid hatch + docking port doors, that would make it totally customizable.

Actually, if I put that module from the small extender (just looked at it) in the config for a B9 HX part, let's say, would it work if it was stack attached to the rectangular hangars? Do the rectangular hangars then just need to have a PASSAGE_NODE added that corresponds to their bottom stack node to make that work?

Edited December 15, 2014 by AccidentalDisassembly

allista · December 15, 2014

All image files have to be loaded into memory, so every one of those counts in RAM - doesn't matter if it's a normal map or emissive, it still has pixels to read. That's why the load on demand mod exists, because that's what KSP DOESN'T do, unfortunately. I use the equivalent of ATM, 1/4 size textures, and still max out RAM - like I said, yours is one of a large number of good & really useful mods out there . I count 125 .png files in the Hangar folder I just unzipped... The ones in Spaces count too. Yes, I removed the old installation.
Also, I am comparing the number and size of png files per part - sure, other parts packs like B9 have a crazy number of textures too, but they also have a crazy number of parts.

I see. Will try to work something out. Unfortunately, efficient modeling is not my strongest side =\

The main advantage of ATM is not in texture resizing, but, as its author claims, in that it compresses textures in memory using native GPU format and lock them in video-memory, offloading from RAM.

Do you think it's possible to make the hangar extender work with radially attached parts at all? Maybe PASSAGE_NODE = node_attach, or something? Or somehow looking at parent part rather than node? The reason I wonder about that is just because then you as the modder could allow the user to create basically any shape & flavor of hangar, and put a hangar door facing any direction, too - including on a stack node like it is now, of course. If you had a variable size & aspect ratio entrance that looked like a somewhat deeper combination of the asteroid hatch + docking port doors, that would make it totally customizable.

As I said, within the current implementation it is not possible. As for reimplementation, I'll think it through; but at the moment I see many caveats in the framework you propose.

Anyway, right now I would rather concentrate on the texture problem and other existing issues, than on another massive reimplementation effort. All in due time

Actually, if I put that module from the small extender (just looked at it) in the config for a B9 HX part, let's say, would it work if it was stack attached to the rectangular hangars? Do the rectangular hangars then just need to have a PASSAGE_NODE added that corresponds to their bottom stack node to make that work?

That is perfectly possible. But I wouldn't want to see the result :confused:

Kerbas_ad_astra · December 15, 2014

One thing to bear in mind is that ATM will not compress "normal" (that's "normal" as in geometry, not "normal" as in "typical" -- this mod includes some of those) textures by default (in fact, because it adds mipmaps, it will increase their memory footprint by 30%) unless it has a config like this:


ACTIVE_TEXTURE_MANAGER_CONFIG
{
    folder = Hangar
    enabled  = true
}

I've been defining configs like these for a bunch of the mods I have installed that didn't have one in ATM already (e.g. USI, Near Future Technologies), and seen some pretty hefty memory savings -- several hundred MB for sure.

Edited December 15, 2014 by Kerbas_ad_astra
Some stuff got lost in the shuffle.

passinglurker · December 16, 2014

I see. Will try to work something out. Unfortunately, efficient modeling is not my strongest side =\

One possible solution could be to take a page out of SXT's play book and only use the stock textures people usually load any way.

AccidentalDisassembly · December 16, 2014

I see. Will try to work something out. Unfortunately, efficient modeling is not my strongest side =\
The main advantage of ATM is not in texture resizing, but, as its author claims, in that it compresses textures in memory using native GPU format and lock them in video-memory, offloading from RAM.
As I said, within the current implementation it is not possible. As for reimplementation, I'll think it through; but at the moment I see many caveats in the framework you propose.
Anyway, right now I would rather concentrate on the texture problem and other existing issues, than on another massive reimplementation effort. All in due time
That is perfectly possible. But I wouldn't want to see the result

Makes sense to look at the textures first. I'll see what happens when I try to make a hangar extender out of some B9 stuff, haha... explosions, most likely!

Actually, just thought of something - with your code as it is currently, can ANY stack nodes on a part be defined as the passage nodes, and can multiple ones fill that role? If that's the case, in theory, you could do what I'm thinking about by simply adding a stack node to the side of a part, and radial attachment stuff wouldn't be necessary. In that case, simply having a somewhat shallower normal hangar part would do the same thing I'm thinking of, I think.

EDIT: Or, in short, you could create simple parts that are just big, textured boxes or what have you, put a bunch of stack nodes on them, and then you could attach the hangar mouth (the hangar part, in other words, that's just a bit smaller so it doesn't stick out of the side of the ship so far) to whichever node you want.

Edited December 16, 2014 by AccidentalDisassembly

allista · December 16, 2014

One thing to bear in mind is that ATM will not compress "normal" (that's "normal" as in geometry, not "normal" as in "typical" -- this mod includes some of those) textures by default (in fact, because it adds mipmaps, it will increase their memory footprint by 30%) unless it has a config like this:
ACTIVE_TEXTURE_MANAGER_CONFIG
{
    folder = Hangar
    enabled  = true
}
I've been defining configs like these for a bunch of the mods I have installed that didn't have one in ATM already (e.g. USI, Near Future Technologies), and seen some pretty hefty memory savings -- several hundred MB for sure.

If you're using the Basic release, true. Still, it's 30% more in video RAM, not in system RAM. In any case it's much simpler to disable mipmapping of normal maps in the main ATM config, or install the Agressive release, than to write configs for every mod.

*Enough, I've stopped to advertise the ATM :cool:

One possible solution could be to take a page out of SXT's play book and only use the stock textures people usually load any way.

Only if someone would do it for me :rolleyes: It's hard enough to unwrap UV maps to make my own textures, let alone to tailor them to preexisting textures which I previously need to convert from MBM to some readable format. And I will still be needing custom normal-maps in some cases, as they're belong more to the mesh part than to the texture part of a model.

Makes sense to look at the textures first. I'll see what happens when I try to make a hangar extender out of some B9 stuff, haha... explosions, most likely!
Actually, just thought of something - with your code as it is currently, can ANY stack nodes on a part be defined as the passage nodes, and can multiple ones fill that role? If that's the case, in theory, you could do what I'm thinking about by simply adding a stack node to the side of a part, and radial attachment stuff wouldn't be necessary. In that case, simply having a somewhat shallower normal hangar part would do the same thing I'm thinking of, I think.
EDIT: Or, in short, you could create simple parts that are just big, textured boxes or what have you, put a bunch of stack nodes on them, and then you could attach the hangar mouth (the hangar part, in other words, that's just a bit smaller so it doesn't stick out of the side of the ship so far) to whichever node you want.

You could do that, right. But in that case I somehow should calculate and prevent situations when a ship that is transferred from the mouth-hangar to the extension has to be bend in order to pass inside through the side node. Axial stack nodes do not have this problem.

allista · December 16, 2014

Oh boy... they've published the 0.90 ;.;

Just when I was about to get some rest.

Kerbas_ad_astra · December 16, 2014

If you're using the Basic release, true. Still, it's 30% more in video RAM, not in system RAM. In any case it's much simpler to disable mipmapping of normal maps in the main ATM config, or install the Agressive release, than to write configs for every mod.

Even aggressive ATM will leave normalmaps alone without a config -- it compressed everything else in the mods just fine, but mods with lots of finely-detailed parts (I'm looking at you USI, NFT...) were not getting maximal memory savings because ATM mipmapped but did not compress the normals. Adding a bunch of configs fixed that and knocked several hundred MB off of my memory usage. (I'll be adding a pull request to put them in the main ATM repo before too long.)

Edited December 16, 2014 by Kerbas_ad_astra
Clarified who I'm talking to.

allista · December 17, 2014

Even aggressive ATM will leave normalmaps alone without a config -- it compressed everything else in the mods just fine, but mods with lots of finely-detailed parts (I'm looking at you USI, NFT...) were not getting maximal memory savings because ATM mipmapped but did not compress the normals. Adding a bunch of configs fixed that and knocked several hundred MB off of my memory usage. (I'll be adding a pull request to put them in the main ATM repo before too long.)

Thanks for the info. If so, I'll include the ATM config for the Hangar in the next release.

BTW, how do the compressed normal maps affect visual quality? In ATM config it is said that compressing normal maps is not recommended.

Edited December 17, 2014 by allista

allista · December 17, 2014

Hangar v2.0.1 for KSP 0.90 is released

NOTE: it is incompatible with KSP 0.25. Use this update ONLY if you've already upgraded to KSP 0.90

All download links are in the main post of the thread.

AccidentalDisassembly · December 17, 2014

There's a new version of KSPAPIExtensions - one in your download is the previous version, just FYI.

[1.9-1.10] Hangar

[b]Do you use the [u]Desaturated Texture Pack?[/u][/b] 327 members have voted

1. [b]Do you use the [u]Desaturated Texture Pack?[/u][/b]

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

[b]Do you use the [u]Desaturated Texture Pack?[/u][/b]
327 members have voted