Technologicat

Had some spare time tonight, so I went through my list of installed parts. Overall the quality of CLS configs was very high, but I found a few stragglers that need their configs fixed. Results below. Part mods that supply their own CLS configs This is just for information. Naturally, a list of this nature can never be exhaustive; here are the ones out of those I have installed. Kerbal Planetary Base Systems by Nils277 Mark IV Spaceplane System by Nertea Mk2 Stock-a-like Expansion by SuicidalInsanity Parts that should be passable (axially) but are not Since stock and KIS configs are provided by CLS, I think the most logical option is to fix them here. Stock: Mk3 Cockpit (mk3Cockpit_Shuttle) Mk3 Passenger Module (mk3CrewCabin) Mk1 Crew Cabin (MK1CrewCabin), new in KSP 1.0.5 KIS: ILC-18k Container (KIS_Container2) ISC-6K Container (KIS_Container3) Mark IV Spaceplane System: Mk4 'Thunderhawk' Cockpit (mk4cockpit-1). Visible hatches front and back. The back hatch is located near the top, offset upward from the center, but the other Mk4 crewed parts have matching offsets. The impassability of this cockpit seems to be caused by an incorrect part name in MarkIVSystem/Patches/MkIVCLS.cfg (mk4cockpit instead of mk4cockpit-1), so I suppose I should bring this one to Nertea's attention. Docking port and decoupler inconsistencies stock: Clamp-O-Tron Shielded Docking Port (dockingPort1), passable axially but not as surface-attached, although the regular Clamp-O-Tron Docking Port (dockingPort2) is. Is there a reason or is this just an oversight? Near Future Construction: Grip-O-Tron Large Docking Connector (docking-25), no CLS config, maybe should be passable for consistency with stock Clamp-O-Tron Sr. (dockingPortLarge)? The Grip-O-Tron is a hollow construction with a sealed outer rim, having geometry similar to stock decouplers that are considered passable (e.g. the Rockomax 2.5m). MRS: MRS Decoupler, 2.5m Stack, Slimline (NBdecouplerSlim2m), no CLS config, maybe should be passable for consistency with stock Rockomax decoupler. Cargo bays There are inconsistencies in the handling of cargo bays: some are marked passable, while some are missing a CLS config. (Personally, I'd prefer impassable, since cargo bays open to space and are thus not necessarily pressurized, but either way is fine as long as it's consistent - for preference, there are always local overrides.) Stock: Mk2 Cargo Bay CRG-04 (mk2CargoBayS), passable Mk2 Cargo Bay CRG-08 (mk2CargoBayL), passable Mk3 Cargo Bay CRG-25 (mk3CargoBayS), config missing Mk3 Cargo Bay CRG-50 (mk3CargoBayM), config missing Mk3 Cargo Bay CRG-100 (mk3CargoBayL), config missing Mk3 Cargo Ramp (mk3CargoRamp), config missing Mark IV Spaceplane System (all passable, using Mark IV Spaceplane System's own CLS config): CRG-60 Mk4 Cargo Bay (mk4cargo-3) CRG-120 Mk4 Cargo Bay (mk4cargo-2) CRG-240 Mk4 Cargo Bay (mk4cargo-1) DRP-60 Mk4 Ventral Cargo Bay (mk4cargo-drop-3) DRP-120 Mk4 Ventral Cargo Bay (mk4cargo-drop-2) DRP-240 Mk4 Ventral Cargo Bay (mk4cargo-drop-1) Mk4 Tail Cargo Bay (mk4cargotail-1) Modular Rocket Systems (all config missing): MRS Rocket Payload Bay, 1.25m (NBcargoBay1m1) MRS Rocket Payload Bay, 2.5m Long (NBcargoBay2m1) MRS Rocket Payload Bay, 2.5m Short (NBcargoBay2m0) Axial Aerospace Cargo Bays mini mod (recent mod featured on Modding Monday a while back, not yet configured for CLS): 1.25M Cargo Bay (125cbsimple) 2.5M Cargo Bay (25cbsimple) Buffalo The Buffalo MSEV by Angel-125 does not currently support CLS. This is more complicated to get working correctly than the others above. Passable parts: Buffalo Command Cab (WBI_BuffaloCab). This is a cupola-ish "truck cabin". It should have the door at its back passable, all other nodes impassable. Buffalo Crew Cabin (WBI_CrewCab). Four visible hatches: front, back, left, right. Buffalo Adapter (WBI_BuffaloAdapter). Non-crewable part with hatches, should be passable. Connects between Buffalo and 1.25m form factors. Tundra 200 (WBI_Tundra200). Configurable container, meant to be used either as KIS storage accessible from inside the craft, or as a fuel tank. Uses WBIResource Switcher. Tundra 400 (WBI_Tundra400). Larger version of the above. Wagon (WBI_Wagon2u). Configurable inflatable storage module providing either internally accessible KIS storage or a resource tank. Uses WBIResource Switcher. Similar to the above, but with the additional requirement that the module must be in the inflated state to be used. When not inflated, the internal space is taken up by the inflatable shell. Depending on whether the Tundras and the Wagon are meant to always have a crew tube (or if the full volume is taken up by fuel when used as a fuel tank), one may need to switch CLS configs on the fly depending on the container configuration selected. I suppose this means that WBIResource Switcher may need to call into the CLS API. Fortunately it's by the same author as Buffalo itself. In any case, I think that if we would like CLS support for Buffalo, we need to talk with Angel-125, ask for his opinion, and then determine the best course of action.

+1 for changing the labels "Surface Attachable" and "Attachable Surface" to something more descriptive. In case opinions are welcome, "Is passable" (or simply just "Passable"?) is compact and descriptive. "Also surface passable" leaves open the question whether the "surface" refers to the surface of this part, or that of this part's parent (to which this part is surface-attached). Maybe "Also passable surface-attached?" "Also passable to surface parent?" "Also passable through parent surface?" (This is difficult to express compactly.) How exactly does the third option work? I used to think I understood it but now I'm confused. If it always overrides, when is the second one used? Or are the options "one-sided" so that both must be set (option 3 on the parent and option 2 on the child) to make that particular surface connection passable? If one-sided, then one possible description for option 3 could be "Also passable to surface children". Also, did some testing. It seems that after toggling a CLS tweakable, at least one of the affected parts must be detached and re-attached to make CLS update its connectivity model. (Tested by detaching/re-attaching the part closer to the leaf level of the tree.) If the detach/re-attach is done with the CLS window open, the list of parts in the space refreshes immediately, but the CLS highlighting overlay is lost until the CLS window is closed and re-opened. (Just clicking again on the name of the space does not restore the overlay.) This behavior is now 100% reproducible in my testing. Found two more parts that have axial hatches but are not marked passable by default. List so far: Mk3 Cockpit (mk3Cockpit_Shuttle), stock Mk3 Passenger Module (mk3CrewCabin), stock Mk1 Crew Cabin (MK1CrewCabin), stock, added in KSP 1.0.5 ILC-18k Container (KIS_Container2), KIS ISC-6K Container (KIS_Container3), KIS (If you want help, I think I could go through the list of stock parts plus those from mods I have installed, to see if there are any more omissions. I like this mod!)

Np, parts sometimes get added or changed KSP 1.0.5 introduced some rather large changes (as listed on the wiki) considering it's just a revision update. The updated plane parts are one, but also notable is the thermodynamics system overhaul (much fewer rapid unplanned exothermic oxidation events). The improved time integrator (explicit RK2 / Heun, as was mentioned on Devnote Tuesday a while back) also seems to have stabilized things. In 1.0.5, physics warp is stable enough to be used during launches (even with 200+ part craft, at least if using KJR; example). Makes me suspect 1.0.4 and earlier may have used explicit Euler, which is simple, but notorious for its instability Anyway, concerning CLS, I read through the original dev thread. Impressive work. The Unix-style "do one thing and do it well" approach works well here. For the most part I agree with the discussion in that thread. Generally speaking, punching holes at random locations on meticulously designed spacecraft components does not make much sense (even if it would shorten Jeb's trip to the snack storage). The exception are things such as structural fuselages, where the inside consists of pretty much empty space. For such corner cases, the on-the-fly customizability is nice. As for the bugs, I played around in the VAB last night and this time couldn't reproduce them. No unplanned duplication of toolbar buttons, or failing to register changes to the tweakables without exiting the VAB. (Closing and reopening the CLS window was enough.) So, it seems these either occur randomly, or require a more complex set of conditions to trigger... I can keep an eye out in case they happen again, and grab a log if so, but can't promise a timeframe on testing. Yeah, how to update the mod is indeed up to PapaJoe. Nice that it's configurable - custom MM patches already allowed me fix the incorrectly behaving spacecraft parts locally, so anything PapaJoe does to the mod is a bonus

Thanks for the pointer! For the Mk1 Command Pod, makes sense. The Mk1 Cockpit (at least its remodeled KSP 1.0.5 version) and the Mk1 Crew Cabin (a new part in KSP 1.0.5, which is what I and WildLynx meant), on the other hand, have hatches. Porkjet's original Imgur post can be found here.

Hi, Finally got the time to test this last night. New version of craft, around 170 parts (plus lander), no hex trusses, no serious framerate issues. Seems we can rule out the spindle system and the tweakable fuel tanks as potential causes for the slowdown.

Ok. Oo, new Ship Manifest? Will have to try that when it's out. The current version has simplified my crew and fuel transfers considerably. The intuitive LF/O autobalancing in fuel transfer - as well as the ability to tell SM to "refuel that docked vessel" - helps a lot. The stock crew transfer mostly refuses to work for me, so having an independent implementation of crew transfer in SM is useful. Support for CLS in SM is icing on the cake. (No idea if it's an issue with KSP specifically on Linux, but in the stock game, the second click to select the target module for the crew transfer very rarely registers at all. This occurs at least on KSP 1.0.4 and 1.0.5. The only possibility is to cancel by hitting esc, and EVA the Kerbals over. I've seen people occasionally complain about this on the forum, but I'm under the impression that for most people the stock mechanism works fine. The issue seems to get worse with large craft, where the framerate is low. Using SM instead, I've had no problems transferring crew.) In SM, the only thing I'm missing is a "vessels" switch for the parts control panel (like in the resource transfer window), so that you could switch on/off the lights (or solar panels, or stuff) on just one docked vessel. (Would be useful for switching off the lights on a lander or a shuttle after docking to a mothership - I almost always forget to hit the lights key just before the docking is complete.) But back on topic: noticed two more things in CLS when playing last night: The Mk1 crew cabin (MK1CrewCabin) that was added in stock KSP 1.0.5 is not marked as passable. Tested with the "freedom" CLSStock.cfg. (EDIT: Oops, WildLynx already reported this.) When using the editor tweakables to make optional parts passable, the connectivity of the living space updates only after saving the ship, exiting and re-entering the editor. (Should be reproducible by adding a KAX heavy structural fuselage, radially attaching radial attachment points, and to those, stock structural fuselages (axially, making them stick outward from the larger fuselage, like near the front of this craft). Then tweak the KAX fuselage, selecting radial attachments as passable.) About the earlier things I reported, it seems the button spawning issue does not occur 100% of the time. I entered the VAB several times during the session, and got only one extra button. But earlier, in another gaming session, I eventually ended up with the toolbar looking like this after lots of flight reverts and tweaks to the craft I was making. I'm running a fairly heavily modded install, though, so at the moment I'm not sure if CLS on its own does this, or if it's an interaction issue (although for a toolbar button the latter seems unlikely). Maybe I could catch a log just after the issue occurs, if that might help in tracking it down? Also, I confirm that (pretty much as expected) this MM patch: @PART[KIS_Container2]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[KIS_Container3]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } fixes the issue with the large KIS containers.

Hi, Nice work with the optional passability feature. It's nice to have freedom with things such as structural fuselages (and KAX heavy structural fuselages), which could well be designed for a specific craft to include holes for radial passage. Some minor things (in CLS 1.2.0): Some large KIS storage modules are not passable, although they should be according to the textures (suggesting the presence of hatches), in-game descriptions, and KIS itself (the KIS inventories are openable without EVA). Specifically, these are the ILC-18k Container (KIS_Container2) and ISC-6K Container (KIS_Container3). They seem to be missing from CLSKIS.cfg. It seems that each time the VAB (or SPH) is entered, a new CLS button is spawned. Exiting and re-entering the editor several times (as when testing craft and reverting the flight), the toolbar eventually fills up with CLS buttons. (Only the latest one actually opens the CLS window.) This happens at least with the stock toolbar. With Blizzy's toolbar, I'm getting the same purple icon issue as was reported by WildLynx above.

Cool! Also funny how similar problems inspire similar solutions. (That, and maybe The Martian. But a design along these general lines simply makes a lot of sense.) Built this back in November: (This one uses DSEV, NF, MRS, KPBS, SCANsat, Asteroid Day. There's also an ALCOR-based lander docked at the aft, but technically speaking it's not part of the interplanetary craft.) Good idea, I'll try that. The pic above shows the craft in question. Most of the fuel tanks come from NF, but there are some FLM-1800 inside the trusses. I realize it could be also one of the other mods causing the performance drop, but based on other craft with NF, MRS, SCANsat or Asteroid Day parts, this seems unlikely. KPBS is somewhat of a question mark, as I haven't yet built any large bases that would stress the part count, but here it's just three habitats and three greenhouses (for show; no life-support mods installed yet), and at least toggling the transparent pod option has no effect on the performance. Then I remembered your post mentioning a performance issue in DSEV, and seeing this is so far my only large craft that has DSEV parts... I'll test when I have the time and report back what I find. This wasn't addressed to me, but... the compact ISRU and the reactor fit there, too?! Need to try this in a future design. Thanks for the tip! Sounds sensible. Why remove the triple-length? I think there may be a slight issue with the positioning of the nodes, if one wishes to space things equally in it (if no one else has reported this, I can test again and check it's not a PEBKAC issue), but it's useful for saving on part count.

I think I've now seen the performance issue... I've built a couple of 200-part craft, and the others work fine, but the one that includes DSEV parts is getting something like 3-4 fps in orbit. (This is with physics time delta at 0.04.) Is it known which of the parts cause the largest performance hit? I think there was something earlier in the thread about the girders having overly detailed collision meshes? Also, I've noticed that the hexagonal girders are not recognized by Filter Extensions as girders, although NF's octo-girders are. Should this be reported here or in the Filter Extensions thread? (Looking at the FilterExtensions configs, if I'm interpreting it correctly, SubCategories_Structural.cfg matches anything with "Girder" in the title, but "Truss" is not included in the list.)

Ah, ok! Glad to hear that.

Sound advice at least for Linux/OpenGL users. Thanks. The .021 version is good also in that it seems to load faster than .0191 (which was the previous one that worked correctly for me), or is at least much better at hiding the loading delay. It seems that with .021, pop-in of the scattering effects at scene changes occurs much less if at all, which makes me happy On a side note, on .0215, I'm getting the glitchy "half planet clouds" in orbit with the new EVE (the issue mentioned and screenshotted by visivante some pages back), but on .021 this glitch does not occur. Posting this in hopes it may help in narrowing down the cause. The same version observation applies to the sunflare being rendered in orbit even though it is well behind the lithosphere, but I think this issue being new in .0215 has already been confirmed by others. Finally, as another data point for an already reported bug, for me the ocean fails to render if the craft (actually camera?) is higher than ~20m from the sea level (as per the stock altimeter), and even then most of the screen area covered by the ocean renders as black. Playing around with the settings (including m_resolution) had no effect. KSP 1.0.5 Linux 64-bit, OpenGL, NVidia. Just throwing this out there, because the maximum altitude seems unusually low (I've been following this thread for a while and I think I've only seen one report with such low altitude), as does having most of the screen area of the ocean covered by one large artifact (instead of the more common "seaweed" type which consists of separate black strips). So, going with .021 for now, although I have to say the atmo scale feature of .0215 is very nice. The new rescaled atmosphere looks excellent, especially with clouds from EVE. The darker blue region above the cloud layer (as per new EVE defaults) in the new version of Scatterer is just wonderful.

[quote name='Z-Key Aerospace']I didn't realise that sounding rockets came with experiments! Thank you for telling me.[/QUOTE] By the way, regarding mods adding experiments, beside DMagic, Solar Science, SCANsat, and Sounding Rockets, there are (at least) also Asteroid Day and [URL="http://forum.kerbalspaceprogram.com/threads/136040-1-0-5-BETA-CactEye-Telescopes-Continued-0-6-10"]CactEye Telescopes Continued[/URL].

[quote name='Z-Key Aerospace']OK. I'm guessing that you could technically take the sounding stuff to Eeloo? I guess it would do something?[/QUOTE] I was under the impression that Sounding Rockets operated on StoredCharge instead of ElectricCharge, but looking at the part cfgs, it seems the latest version uses only ElectricCharge. So yes, technically you could take the sounding experiments to Eeloo, and they should work. Maybe better to leave them enabled, then :) Hmm, although... to think of it, looking at ScienceDefs.cfg in Sounding Rockets, SRExperiment01 and SRExperiment02 are meteorological and aeronomical experiments, respectively, so perhaps they should NeedsAtmosphere. On the other hand, they don't requireAtmosphere in the .cfg - maybe that should be reported as a bug to RoverDude. (According to the default results, "aeronomical" includes experiments on gravitational effects, so conceivably it could partly work in a vacuum, but the meteorological experiments "on local weather patterns" clearly should require an atmosphere.) SRExperiment03 and SRExperiment04 are materials and engineering experiments (respectively), so logically they should work anywhere (and indeed the .cfg does not restrict this). [quote name='Z-Key Aerospace']If you want to restrict it to Kerbin or Earth then this will do the trick. So you find "\GameData\[x] Science!\science.cfg" Change it to look like this ScienceChecklist { CelestialBodyFilters { dmbiodrillscan = NeedsAtmosphere HMI = NeedsStar, NeedsInSpaceLow STEREO = NeedsStar, NeedsInSpaceLow SRExperiment01 = NeedsHomeWorld SRExperiment02 = NeedsHomeWorld SRExperiment03 = NeedsHomeWorld SRExperiment04 = NeedsHomeWorld } } That will restrict the Sounding Rockets stuff to just Kerbin. The other lines are the default filters it ships with they are for DMagic and SolarScience.[/QUOTE] Thank you! May I suggest shipping this modification as an optional MM config with [X] Science!, similar to how some mods do? Would make it easy on the player's part to enable/disable it by just renaming a file. Something like SoundingRocketsRestrictToHomeworld.txt with [CODE]@ScienceChecklist[]:FOR[?x??Science?] { @CelestialBodyFilters[] { SRExperiment01 = NeedsHomeWorld SRExperiment02 = NeedsHomeWorld SRExperiment03 = NeedsHomeWorld SRExperiment04 = NeedsHomeWorld } }[/CODE] [quote name='Z-Key Aerospace']OK, this one is a bit of an old chestnut. All the experiments are possible. For example "Landed at Kerbin's Water" You can get that at Ice Caps. Some of the ice is white (in map view) - that's ice cap. Some is blue - that is water. Splashed at mountains and highlands is available NE of the launchpad. Find the big river delta and follow the river to its source in the mountains. Bring parachutes. Remember they don't slow you down as much at that altitude. Splashed at deserts and grasslands is W or the lauchpad. Real easy. Splashed at tundra and Ice caps - There is a lake N of the launch pad. The N shore is Ice Cap the S is Tundra. Badlands is a pain but I always find the right teeny-tiny lake in the end.[/QUOTE] Aaaaaah! I've never noticed this! Thank you for the correction! And again, thanks for the nice mod!

[quote name='Angel-125']Glad you like the mod. :) I strive to make my artwork look stock, and aim for quality similar work by PorkJet or Neartea- I admire their art. My aim for DSEV, MOLE, and Buffalo is to provide parts that give a similar look and feel to NASA's exploration craft but adopt the kerbal look and approach, so parts are asmodular as I can make them.[/QUOTE] Buffalo is also very nice. Allows building space trucks for refueling :) The cockpit with the ASET props is excellent. [quote name='Angel-125'] DSEV is due for an overhaul to improve performance but will need to wait until I can get Pathfinder stabilized. Still having issues with bases exploding upon loading and such..[/QUOTE] There have been performance issues? Rapid unplanned disassembly tends to be a problem with bases for some reason. [URL="http://forum.kerbalspaceprogram.com/threads/127413-WIP-1-0-5-Kerbal-Planetary-Base-Systems-v0-2-10-Update-17-11-2015"]Kerbal Planetary Base Systems[/URL] was struggling with that earlier, too. (By the way, DSEV and KPBS combine nicely to make a rotating habitat for a cruiser.) [quote name='Angel-125'] as for the centrifugal force, I would assume that KSP is using real-world physics but I don't honestly know. I tend to put Masscon parts on the counterspin ring that match the mass on the hub, then spin it in the opposite direction and let the Spindle's torque module deal with the rest. That mostly works.[/QUOTE] Ok. I'm trying to minimize ballast and preconfigure the rotation rate before launch, that's why I was wondering :) [quote name='Angel-125']I do have plans for an animated centrifuge similar to the Discovery II and one designed for the Nautilis, but I have to finish some other parts first. Sadly I can't create mods for a living so it will take some time to finish the parts..[/QUOTE] Mm, hobbies tend to be like that. :)

[quote name='davidy12']Erm... He didn't make the centrifuge [COLOR=silver][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] Wild blue did. Plus, why would he make a centrifuge for the surface?[/QUOTE] True. Now that I look at it, my wording may have been confusing. My intention was only to point out that the KPBS modules may be useful also in space, because there is a centrifuge available. The thanks at the end was intended to Nils277 for KPBS. I think the parts look good, cover everything necessary and are highly modular, offering interesting possibilities for base building. Also, I find it impressive that all the crewed parts have an IVA. This final touch has undoubtedly taken a lot of work. While adding immersion, it also makes KPBS pleasant to use - no misplaced Kerbals because one didn't show up in the portraits. :) Also, rigid structures. Variety for the win (inflatable ones being covered by Pathfinder and MKS). [COLOR=silver][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] [quote name='theJesuit']This is the setup that I use, but rather than attaching at the top node I round the corridor to attach the habitat module as intended.[/QUOTE] Ah, nice. I take it that's with the old modular corridors? It seems the new procedural ones work differently - place endpoints, link them in the field via KAS. Makes base building much easier, but doesn't work for this application. [quote name='theJesuit']I think IR or at least DSEV has the issue that if you 'control' the ship from one of the rotating habitats by going into IVA then IR keeps the new control stable and rotates the rest of this ship. Hilarity can ensue.[/QUOTE] Heh, haven't tried this. Maybe when it's time to retire a cruiser :P

[quote name='D3M3T4N']I have a problem with this mod. If I go in the settings on the main menu and I go back to "Start Game". When I click the "Resumed Saved" button, nothing happens. Same things for Training and Scenarios. If I don't go in the settings, everything is fine. KSP Ver.: 1.0.5.1028 X Science Ver,: 4.11[/QUOTE] I see this too, and can confirm that it started happening after installing X Science!. The mentioned three options change color upon clicking but otherwise there is no response. "Start new" brings up the window normally. It's not a major issue, but does require some extra restarting of KSP when trying to tune the performance (since some of the settings can be changed only in the settings screen accessed from the main menu). Versions: KSP 1.0.5.1028, Linux 64-bit under Linux Mint 17.2 X Science! 4.11 Otherwise, this is a very nice mod. Exactly what is needed for extracting some extra science when you're no longer quite sure which experiments you have already run in which biomes. Two small suggestions: Defining and saving custom filters? [URL="http://forum.kerbalspaceprogram.com/threads/102502-1-0-5-Sounding-Rockets%21-Start-small-Dream-big%21-0-3-1-2015-11-09"]USI Sounding Rockets[/URL] defines four experiments that are meant for early game (so Kerbin) only, and it would be nice to be able to somehow hide them for space and other planets/moons to clean up the list. (Preferably as an option. While I don't personally plan to equip my interplanetary cruisers with launchable sounding rockets, someone else might.) Currently, 4.11 lists some biome and situation combinations that cannot actually occur (e.g. splashed down at mountains). It would be nice to filter these out, but I don't know if there's a programmatic way to determine which combinations are actually possible.

[quote name='Thegamer211']Does the mod work in 1.0.5?[/QUOTE] Not at the moment. Stock aero has changed and requires corresponding changes to this mod. Youen has already updated the code (see the previous page in this thread), but there are still some issues that need to be ironed out before it's ready for release. If you play with FAR it might work, but there may be problems (see FungusForge's post above).

[quote name='Nils277']Also all the IVA are made to look good with gravity. There would have to be a way to prevent them from being habitable in space. Else it might break immersion :wink:[/QUOTE] Just a note to this, in space, there may be artificial gravity :wink: There's a modular centrifuge system in [URL="http://forum.kerbalspaceprogram.com/threads/135717-1-0-5-Deep-Space-Exploration-Vessels-1-0-5-Build-NASA-Inspired-Ships-In-KSP"]Deep Space Exploration Vessels[/URL] which lends itself to attaching KPBS modules for long interplanetary trips. Configuration: rotating hub, radial attachment point, some structural fuselages for distance, desired KPBS part (attached by its top node to have the floor pointing outward). Apply symmetry as desired. Beside planetary bases, for this use it is very nice to have crew parts that are designed to work in an environment with gravity (even though the artificial gravity has no actual gameplay effect). A minor issue with this setup is that while the centrifuge is spinning, the IVA meshes seem to ignore the motion of the parts they belong to. But I suspect this is a stock bug - I've seen the same happen with stock IVAs when a long craft wobbles significantly. (The IVA stays put at its original position, while the exterior of the craft (visible through the window) wobbles around.) Thanks for the great mod!

[quote name='Angel-125']That leads me to my question: For the trusses, how many people use more than two sides to attach stuff?[/QUOTE] I do, too! (Been playing KSP for 200+ hours, but only bothered registering on the forums just now.) The hexagonal truss system is ideal for craft with three- or sixfold symmetry, offering a unique cross-section profile and thus expanding options for craft design. Both the stock modular girders and the octagonal trusses from Near Future Construction are geared for two- or fourfold symmetry. I think each of the three truss systems has its niche. Love the centrifuge parts, too. An artificial gravity system feels very appropriate for any interplanetary cruiser, given the typical flight times. Which brings me to one question: how is torque determined in KSP? What I'm trying to do is to determine the optimal rotation speed for the counter-torque ring for a given configuration. If there is to be no net rotation, the total angular momentum must cancel out: L = sum I[SUB]j[/SUB] omega[SUB]j[/SUB] = 0, where I is the moment of inertia, omega is the speed of rotation, and j indexes the parts of the craft. (All parts that are not rotating in the centrifuge can be ignored.) The moment of inertia I is the integral of r[SUP]2[/SUP] dm, but how is the mass distributed in the rings? The radii for the two ring types are the same. Can the mass distributions be considered to have identical shapes, which would make the moment of inertia simply linearly proportional to the total mass of each ring? If so, then in the case of no payload, the rotation speed that exactly cancels the torque should be omega[SUB]2[/SUB] = -(m[SUB]1[/SUB]/m[SUB]2[/SUB])*omega[SUB]1[/SUB], where m is mass, omega is rotation speed, subscript 1 refers to the spin hub and 2 to the counter-torque ring, and the minus sign indicates the opposite direction of rotation. Then, if there is payload attached to the spin hub, we assume that each attached part is a point mass located at its center. The distances from the axis of rotation should be rather easy to approximate visually. This would give a ballpark estimate for the needed rotation speed for the counter-torque ring, which can then be fine-tuned once the craft is in orbit (without causing the craft to spin wildly when the centrifuge is first activated). This also allows skimping out on ballast unless the estimated speed is ridiculously high, saving payload mass. What really won me over to installing DSEV - aside from the stockalike look - is its modular nature. As a craft builder, I prefer flexibility over replication of minute details of actual real (or concept) spacecraft. Right now I'm building a ship for a manned (kerbaled?) trip to Duna, for which the DSEV parts (along with Near Future and MRS) come in very handy. Thanks for the great mod!