allista

Hangar v2.0.2 for KSP 0.90 is released All download links are in the main post of the thread.

I cannot reproduce this thus far. I believe more than a several orbiting ships with hangars and content are needed. With a simple setting the only thing that happens is the messages that the ships contain non existent parts and are thus removed from the game.

Thanks for the test! The difference in visual quality as well as in RAM usage is easily seen. I reckon it is up to users of ATM then to enable/disable normals compression. I've added the ATM config to the Hagar installation, so it's easy to do it. And I will continue to try to downscale and merge textures where possible.

Sorry for my absence -- to much work this week. I confirm the problem. The Gravioli experiment does indeed indicate the mothership's name as a planet's biome. And I think I've found the way to fix it in my code. Will try to release the fix this night.

Wow... never thought it may be that bad I will investigate the issue ASAP. Meanwhile I would appreciate if you send me the logs and the corrupted savegame.

Thanks, xEvilReeperx, that was fast!

I'm afraid the EPL/Hangar bug has returned in 0.90. Both v1.8.2 and v1.8.3 have the issue: NullReferenceException: Object reference not set to an instance of an object at ScienceAlert.ScienceAlertProfileManager.OnVesselCreate (.Vessel newVessel) [0x00000] in <filename unknown>:0 at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0 at Vessel.Initialize (Boolean fromShipAssembly) [0x00000] in <filename unknown>:0 at ShipConstruction.AssembleForLaunch (.ShipConstruct ship, System.String landedAt, System.String flagURL, .Game sceneState, .VesselCrewManifest crewManifest) [0x00000] in <filename unknown>:0 at AtHangar.HangarStorage+<convert_constructs_to_vessels>c__Iterator0.MoveNext () [0x00000] in <filename unknown>:0

You have encountered the bug caused by the ScienceAlert that was already discussed here. But according to SA's changelog it was fixed in v1.8.1, so I haven't mentioned it in Known Issues. But, obviously, the bug reemerged in 1.8.2 (maybe because of the 0.90 API changes) and is still there in 1.8.3 as I've just checked. Unfortunately there's nothing I can do about it: on Hangar's side the bug happens upon calling an API method, it's not in my code. I'll inform SA's developer about the issue.

I want to clarify things a bit: 1) The Desaturated Pack is just a set of the same textures you see in the mod with colors removed (with the exception of warning strips, orange door handles and such). 2) I, obviously, prefer the colored textures. Thus I have no intention to advertise the grey set, which is provided solely because some users have said that they don't like the colors. 3) Consequently, the poll tries to divide the users into those who already use the grey set, because they totally don't like the colors, and those who consider colors good enough, not bothering themselves with trying the grey set. I deliberately wish to keep people, who want to try both and decide which is better, a minority. So, if you're using the mod and the colors do not annoy you, you may honestly answer "No, I don't use the pack", because that's exactly what's happening. All in all, the discussion shows that I've designed the poll poorly and need to reformulate it. [uPD] Alas, it seems I don't have the means to edit (or close, or delete) the poll. Is it to hang over there forever?

Thanks a lot! That's what I thought after examining the logs. It's CKAN's problem, as KAE dll (according to KAE docs) should be bundled with the mode that uses it. As you can see from your logs it's a common practice: MagicSmokeIndustries\Plugins\KSPAPIExtensions.dll TweakScale\plugins\KSPAPIExtensions.dll What is strange, is that I don't see the Hangar\Plugins\KSPAPIExtensions.dll; but it should be there, as it is included in every release. So, apparently, CKAN is stripping KAE dll on installation.

I'm not familiar with the CKAN; and while I don't really suspect it to be the culprit, it won't hurt to try to reinstall the mod using the archive from GitHub or KerbalStuff. Meanwhile I need more information about why the HangarProceduralAdapte could not be loaded. Such information is usually contained inside the output_log.txt which is a log that Unity engine itself writes. On Windows it is located inside the KSP installation folder: {KSP}\KSP_x64_Data\output_log.txt Please, upload it as well.

That means the Hangar.dll was not loaded by KSP. It is indeed looks like a mod conflict (btw, you have Hangar-2.0.1, right?), but I need to see the logs to tell more. Please, double check the version of the Hangar and if it is indeed the 2.0.1 send me the Player.log somehow (pastebin, gdrive, dropbox, etc.).

Thanks) Would appreciate the feedback.

Yep, thanks! I know already, but the previous version of KAE works with 0.90 (I've checked) and the new version came out a little later than I updated the Hangar. And assembly election mechanism should disable it anyway (if another one is used by some other mod). So if it causes no trouble (?) I would rather leave it like that until the next release.

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.

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.

To distinguish Editor type (SPH/VAB) the EditorFacility enum may be used. E.g: if(EditorLogic.fetch.ship.shipFacility == EditorFacility.SPH) { ...; }

Oh boy... they've published the 0.90 Just when I was about to get some rest.

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 Only if someone would do it for me 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. 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.

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

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.

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). 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'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. 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). 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. 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. 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. 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 ==

Hangar v2.0.0 is released Please, see the main post of the thread for details

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

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. 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! 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. 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. 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.