allista

I'm focusing on functionality and bug-hunting. Part packs we'll leave for the crafty 3D-modellers in the community, if there are some who feel the same way as you do =)

Oh hell! =) They actually did it! Maps and tape! Humanity is unstoppable >_<'

Good point about S-IVB! Wiki page says it was 10t dry, so even lighter. And I really can't understand how they managed to build it so light! My radial adapters have comparable mass distribution, but not the hub.

1. But as you can see in the screenshot, the cost is positive and equal to that in the config I mean, I can't reproduce what you're describing... And in my experience the cost in config is always what the part costs in its default state, whatever you put in it. So something weird is happening both here and in the fork of ExLP you've mentioned. 2. The radial parts are hollow (you may look at configs: 10kg per m3 meaning some struts and coating and 1.2kg of air), 91.4% of their mass is in their hull, meaning ~scale^2 increment. But the hub should have much more inside, like internal airlocks and pipes and wiring, yet it is still only 100kg per m3 and mass is split ~50/50 between the surface and the volume. Also, Al-Li alloys that are used in aerospace are not so drastically lighter than aluminum itself (~2.6 vs 2.7, see http://alcoa.com/global/en/innovation/papers_patents/pdf/lmt2007_110.pdf for example). And if you increase the mass as the square of the scale it means that the walls of the scaled hollow part will remain to be of the same thickness. Imagine 5m wide hull (size4) still made form the same 3mm aluminum sheet, and what mechanical properties would it have. That's just a thought about the complexity of physical models, even as simple as the one I use to compute parts' masses. I want you to understand me correctly: I do want to make things lighter, because propulsion systems in KSP, as futuristic as they are, are still too inefficient and weak for such huge parts. But I can't just get the numbers out of thin air. All these computations allow me to balance the mod, to keep the challenge in game. So if you feel a part's weight is unreasonably high (or low), please, look at configs -- there are always complete descriptions of weight distribution -- and propose some changes. I will be glad to have some help in that. You're welcome =) And there's still so much to do!

Yea, I saw them, thanks! I'll get to it tomorrow, when my head gets back the ability to think =)

Oh boy, I knew I never could do anything right the first time! So new update => new functionality => new bugs >_< 1. What do you mean by "devoid of metals"? It does not have any metal by default and costs 2980.1: http://i.imgur.com/pSQmkLb.png 2. I honestly don't know what to do with this. I calculate the weight assuming the part is made from real-world materials like aluminum and steel and composites and has reasonable wall thickness and all. And these parts do weight much. It looked strange for me at first too, but than I took the effort and compared their dimensions (hub, scale 2, 6.8x4x6.8m, diameter of a tunnel 2.5m) with some real world examples, like cars and flats and houses... and saw that KSP parts are not as small as they seem, they are actually not small at all! Station Hub of size 2 may easily shelter this baby in each of its radial tunnels! *btw: UNscaled Hub weights 1.5t, just like the stock hub; and if you scale the stock one with TweakScale up to size2 (2.5m) you'll get 12t! 3. Yep, still supposed to. Otherwise it will have attach nodes of size4 right from the start. And it creates some diversity =)

AccidentalDisassembly, I've made a demonstration video of how it should work and is working with friction on my end:

Thank you so much for such thorough testing! It's a great job! I still can't understand what exactly is happening, because there are no errors in logs that I can link to the problem. Even the seemingly related "WheelCollider requires an attached Rigidbody to function." is the message I see all the time; have seen it even before I started to develop the mode, while playing. I'll reproduce your designs, test it all again and report back. If the problem here is still not present, I'll publish a development version with customized log messages and debugging enabled to see what's going on on your system compared to mine. *BTW: do note, that ground hangars have integrated command module and battery (and the big one also has generator), so there's no need to attach them.

Thanks for the rovers, I'll fiddle with them and think more about the designs of landers. And I will test the idea of a more pyramid shape of the dome. If it will change the way symmetrical parts are attached, I'll implement it. But I at last see the core problem. The hangars, all of them, do not have and never will have customizable geometry. They are what they are, as all the other parts in the game. I may remodel them in one way or another, but that wont change their static nature and the fact that they are not fit for every and all imaginable applications. So if you want to get optimal filling and have less mass, you should tailor your payload to them, not vice versa. I wont remove vessels packing, it is conceptually wrong. I can't make the lander any lighter, otherwise it will have to be made of silk and paper, not aluminum and steel. I will make other lander models, if I see some common use cases.

1. Well, I've shown you the calculations (they're for the new version from the pictures, that's why the figures differ a little). If you have any idea of where to cut some more fat from the lander, you're welcome to share it. As for your custom lander design -- it's no wonder. If you make something tailored for your particular payload it should be more efficient. What I do is trying to make something more universal, trading efficiency for lower parts count and simpler design. Hence cubic geometry and built-in fuel tanks and other stuff. And yes, the Rover Lander is certainly designed to be a lifter too. But not for heavy worlds -- there's no propulsion system in the stock game for such things. 2. I always use Editor Extensions to overcome this so I sometimes forget that not everyone use them too. I apologize for that. Still I don't know if adding stack nodes to the top of the lander is a good idea: it may be too confusing to have a part with 10 nodes. 5. The whole point of the mod is to spawn vehicles instead of just attaching them. And while this breaks the realism to the point it is well worth it. Also, it is an ill argument to say that if the realism is broken at one point it's not worth trying to keep it wherever possible. So no, this simulated packing of vessels is, in my opinion, what keeps this mod from being a cheat. A thing to mention: I'm working on the alternative lander part for long rovers to be used in some horizontal VTOL designs. It will hardly be any lighter, but maybe it will fit your needs better and thus wont need to be enlarged to such extents. Then again, VTOL is not something you can do with stock parts and modules.

1. The RoverLander is actually very light. It's mass is calculated like this: //Volumes: [ (ramp side walls: 0.0552m^3, 2.7t/m^3, 0.14904t, 0.4416Cr) (base: 7m^3, 0.15t/m^3, 1.05t, 280Cr) (machinery: 5.76m^3, 0.11t/m^3, 0.6336t, 460.8Cr) (clamp: 0.045m^3, 0.98t/m^3, 0.0441t, 27.0Cr) (doors: 2.18m^3, 0.02t/m^3, 0.0436t, 2.18Cr) (batteries: 0.888m^3, 0.112612612613t/m^3, 0.1t, 1760.0Cr) (reaction wheel: 0.17m^3, 0.952380952381t/m^3, 0.161904761905t, 1700.0Cr) (hinges: 0.016m^3, 2.7t/m^3, 0.0432t, 0.128Cr) ] //Total volume: 16.1142 m^3 //V mass: 2.2254447619 t //Shell: [ (hull: 92.1m^2, 0.004m, 2.7t/m^3, 0.99468t, 589.44Cr) (doors: 55.28m^2, 0.003m, 2.7t/m^3, 0.447768t, 265.344Cr) (fuel tanks: 14.34m^2, 0.006m, 2.7t/m^3, 0.232308t, 137.664Cr) (inner hydraulic cylinders: 2.172m^2, 0.002m, 8.05t/m^3, 0.0349692t, 13.032Cr) (outer hydraulic cylinders: 2.884m^2, 0.002m, 8.05t/m^3, 0.0464324t, 17.304Cr) ] //Total surface: 166.776 m^2 //S mass: 1.7561576 t //Additional mass: 0.04 t //Additional cost: 680 Cr //Resources cost: 653.1 Cr entryCost = 23547.8369899 cost = 6586.4336 mass = 4.0216023619 Still, I've thought of what you've said and managed to cut ~0.15t from the default-sized lander. It is not much, but it adds a couple of tons of payload it's able to lift using Puddles when resized to size4. But just think about it: the dimensions of the size4 lander are 7.4x7.4x5.8m; it's a room almost 55m2 with nearly 6m high ceiling, compare it with the living area of your home! It is made of thin (4mm) aluminum sheets, contains steel hydraulic cylinders, accumulators and machinery, heavy reaction wheel, fuel tanks and so on. Yet it weights only 24.8t without fuels. It is ~78kg per cubic meter. Less dense then most of plastic foams! So it's a shame we don't have a decent propulsion that would allow us to easily lift a house made from plastic foam =) *BTW: I haven't have problems with lifting off using 4 Puddles with 5t cargo on board (see the pictures below). 2. I've successfully managed to attach 4 parachutes using radial symmetry right above the doors without any problems. You can't do it in diagonals, but that's a limitation of KSP Editor and the way it computes orientation of symmetrical parts. Even some stock parts have such problems. http://i.imgur.com/nEEaGU4.png 3. Yes, stock parts are not big enough, they are limited to size3, and you're talking about size4 part. But, as we may guess, it's temporary -- KSP is developing rapidly and the Squad adds new parts. There are also many mods that provide such parts already. And in the next update of the Hangar there will be an adapter that allows to connect S4 to whatever you need. 4 The lander is not meant to be used with landing legs. It is strong enough to land on its own doors at 10m/s without damaging the cargo. I've changed the animation a little, so that the doors lift it enough to fit Puddles underneath. It will be in the next update too. http://i.imgur.com/yaHR8NY.png 5. About storage space: if you park your car into a garage which will still have some space to the right of the car, to the left, a little above and a little behind... and the summed volume of these spaces will, in theory, be enough to park another car there, will you actually be able to park another one? You see, the hangar volume (and the used percentage) is calculated only for reference. The actual storage algorithm considers geometries of a hangar and stored vessels. I do understand that sometimes it may be confusing, but right now I can't thing of a way to provide a user with a more intuitive way to tell if a vessel should fit into a hangar, except trying to actually fit it and report the result. There are still some issues with storing something from the Editor, though. 6. Just wanted to ask: what on Kerbin do you need to launch the lander from Kerbin without booster stages for?! =)

Unfortunately, I still can't reproduce it on my clean install (KSP 0.24.2, Ubuntu 12.04, 32bit). Tried only yesterday for couple of hours with different combinations of rovers and hangars and places. The only thing I've noticed (a long time ago) is that sometimes when you switch to the rover (not necessarily from the hangar) the forward-backward controls do not work. But switching back and forth fixes that in my experience. Could you publish your KSP.log and/or Player.log? Or maybe make a small screencast?

Yea, any kind of procedural meshes are pain in the ass in Unity. I've just implemented simple procedural truncated cone for adapter and it took me several days to clean out all the tiny bugs with normals and tangent space calculations >_<' And if you look inside the ProceduralParts' code, it's tenths of times more complex. Indeed, hangar requires stable orbit just to prevent collision of the launched vessel with the walls of the hangar. Yet fairings may be decoupled with ejection force applied, so these limitations are not a problem. But unfortunately, PF is not a part, but always several parts (base+fairings), so right now I can't even think of a way to inject hangar functionality there. Thus, it seems, the only way is to reimplement it. Another thing about hangars: they store only complete vessels, the root part is required; you can't hide just some section of a vessel there.

Thanks for the clarification! So, essentially a self-disabling hangar that spawns a ship and becomes just a structural frame afterwards. Nice idea, but not so easy to implement starting from the framework I have now. And I can't see the big difference with the present time hangars. Such hangars should be lighter and less expensive, but what other advantages this may give?

My apologies, but I believe I should decide for myself what I should and shouldn't do =) Still, the small inline hangar may be easily used in a spaceplane design if scaled down. But I'll consider making dedicated spaceplane-fuselage-type hangars. Nori is correct, it's possible to transfer resources to and from stored vessels. I can't catch the concept. Any part, hangars included, may be used as a "single-use" device. Just leave it in orbit, on a surface, or destroy it.

Glad to hear! == I hope to release the next version this week. Nothing special, but I'm trying to make it more convenient and flexible with respect to ship designing.

ModuleManager is essential and its .dll should be installed into the GameData folder, and not in a subfolder. It works automatically and does not need any user interaction. The Hangar folder should be in the GameData folder too. If you will still have this problem, please post the file tree of your GameData folder. Also please post KSP.log file.

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, I want to invite you to the discussion of the gateway hangar's problem. See the "Gateway Hangars" milestone on the GitHub.

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

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 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. Very strange. I can't imagine how's it possible. Will investigate. 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. 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.

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.

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

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)