sumghai

I'm finding it difficult to decipher what you are trying to say. Please provide a screenshot. I know exactly what you are refering to, but it's not a bug. The reason you can't grab surface-attached parts to the left of the red line for that specific view is because your mouse just so happens to hover over the invisible ladder collider boxes. Now, if I remove the collider boxes or make them smaller, the EVA ladders won't work. Your best bet is to change your camera angle in the VAB/SPH (click and drag).

In high school I broke both my wrists at the same time, whilst climbing a one metre tall fence. Thing was, I had no trouble getting up onto the fence - it was coming down that posed some problems. In university, I was doing a research project involving high voltages. My project partner and I forgot to discharge a DC-to-DC converter properly, and I got a bit of a jiggle when my hand accidentally brushed against an exposed alligator clip terminal. Fun times indeed.

The current RCS thrusters are sufficient for manoeuvring even medium-sized craft for docking. If you have larger crafts, just put more RCS thrusters at appropriate locations - the small size RCS thrusters allows for precision control.

In theory, yes, I could have made the Kirs have its own docking port(s). In practice, I preferred that people were able to choose which docking ports to use on each of the two ends. Some may prefer the stock Clamp-o-trons, others Fusty's CBMs, and a few are curious about my proposed IACBMs. Essentially, think of the Kirs as a nicer-looking stock Structural Fuselage with a dedicated purpose and (soon to come) IVA.

Let' see... Describing my FusTek Station Parts Expansion pack: I made a set of things you can add to the Little Green Man Space Game - this set has different types of big people boxes for making big houses that fly and stay in space. One of these people boxes allow people to go to six other people boxes. One is for people to live in. One is for people to store things in. One is for people to do good brain people stuff in. One is from which people control the big flying space houses. Two are for people to go in and out of the big flying space houses without losing air (If air is lost, the people inside can not breathe and will die). One has lots of windows to look out into space from. One stores parts to build more space cars and people boxes from. I also made other things to make these people boxes even better.

In addition to TG_bigboss's response, I should note that suggestions/requests/demands/orders for KSP to be optimized to 64-bit OSes have been listed on the Official Already Suggested and What not to suggest lists.

Lelelelelelelel. Semni's JARFR trusses. I do have my own truss system in mind, but that's for the distant future.

In that configuration and accounting for the 80 mm hull thickness and 75 mm corridor chamfers, the sleep stations would protrude an extra 405 mm into the aisle. This leaves an effective corridor width of 340 mm, not nearly enough for a Kerbal to fit through (Kerbals are roughly 500~600 in diameter-ish). Had the modules been 3.75m in diameter with the same hull thickness, your suggestion might have worked. Correct - the top bins will most likely be oxygen / food / clean water storage, whilst the bottom would be temporary septic tanks / garbage bins, which would somehow get fed into any nearby Utilities module for waste processing. Indeed. No doubt I'll be using NavyFish's Docking Port Alignment Indicator for future station assembly, but I feel that installing lights (white static illumination and possibly independently toggleable red flashing lights) would help folks select the right port to target from a distance. That's an interesting suggestion. The problem with having three (3) attachment nodes very close together in one part is that when the docking port is dragged over and onto a module's attachment point, the part position will flicker between the three positions, making VAB/SPH assembly quite frustrating. So, I'll probably limit it to two (2) attachment nodes (top and bottom). That being said: - I've been thinking about a possible FusTek alternative to the Rockomax Multinode even more compact than the current Mk III Node, dubbed the microNode. Essentially this is a Kuest-sized module with six docking recesses. - While waiting for more results from the Hab IVA poll, I've been prototyping some parts for a whole new pack, a stockalike system of Orion MPCV-like accessories for the Mk1-2 Pod (service module, fairings and command pod aero shroud). As part of this hypothetical pack, I'm planning on making docking ports with built-in parachutes - one will be the standard Clamp-o-tron with an appropriate stock parachute, while the other will be a slightly-dirtied IACBM with its own (customizable) parachute. Visually speaking, most likely not. A suggestion would be to install on your space station a Kirs Docking module, with the station-pointing end fitted with one of my IACBMs and the berthing end fitted with a Clamp-o-tron.

I've personally always felt that dedicated propulsion modules should be left up to each individual player, especially with regards to engine type, quantity and arrangement, so I'll most likely pass on this one. Besides, the FusTek aesthetic is less suitable for rocket fuselages than the rough-and-ready stock Rockomax designs. That being said, I've prototyped a (extremely crude) trunk intended as a stockalike Service Module for the Mk1-2 Pod - you may be interested in that. Planned. I've been testing some modules with RCS thrusters built into them - they handle pitch and translation well, but for certain reasons do allow rotation about the main axis. More work is needed to refine the design and functionality. Also planned. I'm aiming for a flattened trapezoidal profile like the real ISS trusses, with the customary FusTek whitening, but will use the same lengths as the THSS trusses. Speaking of trusses, while I'm waiting for more folks to vote in the Hab IVA layout poll, I've started thinking about making some docking ports to go with this pack. At present, most people use either the stock Clamp-o-trons or Fusty's CBMs, both of which are technically compatible with the station parts pack, but I felt that certain improvements could be made: - The stock Clamp-o-trons is most commonly used due to ease and their androgynity (i.e. no confusing drogue & chute or male & female distinctions), but does not match the FusTek aesthetic - Fusty's CBMs are (mostly) visually compatible with the modules, but strangely uses red trim (rather than the yellow found on the modules themselves). Another issue is androgynity - his CBMs come in both Active and Passive formats, as inspired by the real ISS's CBMs, but contrary to the actual usage of pairing one Active port to one Passive port, the in-game parts are actually androgynous as well, making any visual distinction redundant. - Both docking systems physically and visually obstruct the hatches on the modules. Whilst usually a non-issue, I figured it would be neat if Kerbals could still EVA out of hatches and right through docking ports in emergencies. - Another popular request was for the docking ports to have lights built into them, to help with illumination and docking alignment. This otherwise would require attaching additional standalone lights around docking nodes, thereby increasing station part count and lag. So here's what I have in mind for my tentatively-dubbed Improved Androgynous Common Berthing Mechanisms (IACBMs): - Essentially a ring with a square hole to allow the module's existing hatches to be used - 1.25 and 2.5m sizes - Androgynous - Matches the FusTek aesthetic - Built-in toggleable lights - Usable with a hypothetical FusTek truss system

And here's my take on how resources could be tied into science, using faux statistical methods of analysing collected samples.

Kudos for the excellent work - I use the Raw Alarm functions to space out my launches so that I have believeable gaps between missions (i.e. to take into account development and testing periods).

R0.03.3a released - see announcements thread for download link R0.03.3a 8 August 2013 --------------------------- Fixes - Corrected typo in CFGs from breakintTorque to breakingTorque - All parts have been reviewed by our Quality Assurance (QA) department at great expense and at the last minute

Yes, good catch! Serves me right for using an old version of fusty's CFG files >.< I've uploaded a patch that should fix this typo. Thanks for the heads-up! To clarify: - fusty is the original modder who made the basic Karmony module and the CBM docking ports, but he put them in separate packs - I (sumghai) am simply extending his work by making my own module variants, so no, this pack does not contain his current CBMs. However (as Kimberly noted) his CBMs are also compatible with my modules. By the way, I currently use the standard Clamp-o-tron docking ports in my own space station. R0.03.3a released - see first post for download link R0.03.3a 8 August 2013 --------------------------- Fixes - Corrected typo in CFGs from breakintTorque to breakingTorque - All parts have been reviewed by our Quality Assurance (QA) department at great expense and at the last minute

Much appreciated, TT. I'd better get cracking.

Which version are you specifically using? 0.21 or 0.21.1? Where / how did you install your mod? Which key did you bind it to?

You are going to need to be more specific when asking for help - forum users cannot read minds, and certainly not across the internet. What version of KSP are you using? How did you install the mod? Which key did you assign the fire button to?

Yeah, this has been an issue of contention. A cursory glance and some quick arithmetic suggests it is indeed possible for the bunks in the Hab module to be horizontal without adversely affecting shower/toilet/galley/exercise area placement. The main problem is determining viewport positions - I suppose I've had this fanciful notion that each sleep station has a viewport to allow its Kerbal occupant to look out into space / planetary surface, and I had a feeling that having horizontal bunks would result in strange viewport placement. Looks like I'd better start a poll... Now that you mention it... R0.03.2a Blender model files and textures

He lives! I look forward to seeing more progress

That's correct. However, in-game reload does at least cut back significantly on the number of complete restarts. Another option would be to have a separate KSP install stripped of nearly all its parts except the ones you need for testing (plus Hyperedit to get your mod parts to distant locations).

Progress Report, 6 August 2013 Another IVA mockup, this time for the Hab module: Fig 30 - (WIP) FusTek Karmony Habitation Module IVA mockup In order to increase the living area available, I had to expand the galley and exercise area out sideways by extruding out the sides of the standard corridor and directly to the pressure hulls; floor and ceiling heights remain constant, so that these modules would still be usable on planetary surfaces. consequently, I have determined that there is enough room for a stationary bicycle after all (yay!). Some of you may notice the dinky little fridge under the food heater and beverage dispenser, as well as a distinct lack of a pantry - the vast majority of crew provisions will actually be stored in the Logistics module, only taken out of their storage lockers on an as-needed basis. Rest assured that unlike the real ISS, cold brewskis are just as easily obtainable from the beverage dispensers as warm or hot drinks. One other aspect not shown in this mockup is that one of the crew portraits will (by popular request) be inside one of the sleep stations. A bit of a shame that Kerbal postures in IVA are currently limited to "sitting at a command seat", but I'm sure I can bundle the Kerbal up in a sleeping bag with no mesh colliders. These three mockups I've made to date should help me get started with standardizing some key dimensions, as well as possible prop placement. Time to hit Blender!

We'll see At the time of writing, nothke hasn't been logged in since June 25th. He last visited the KASPAR thread on June 13, and up until the 25th he has been working on the DROMOMAN robot arms pack. Let hope that he hasn't lost interest, or at least he has plans to pass on his WIP to someone capable of finishing it off for him. I uploaded a stealth patch a few days ago renaming SpareParts to RocketParts. Have you tried downloading that first before asking?

Strange - it worked for me in 0.21+.

tek, try this: - Launch the game - Go to space center scene - Go to VAB/SPH/flight and do whatever tests you want - Go back to space center - Open up the debug menu (Alt-F12 in Windows) - Go to Database tab - Click the reload button - the game will stay running but reload any changes to plugins and parts - Repeat steps 3 to 7 until you're satisfied with your plugin edits This should be able to speed up development time by cutting back on unneccessary restarts of KSP

Odd - changing the "met" values for each of the missions has no effect, even when using very large number of seconds equivalent to several months. Perhaps there is a another field that stores the flight time / launch date for each flight?

Progress Report, 5 August 2013 Time to start thinking about IVAs! I did some mockups for the Karmony Logistics and Mk III Node modules in SolidWorks first, as parametric modelling is good for determining key dimensions: Fig 28 - (WIP) FusTek Karmony Logistics IVA mockup Fig 29 - (WIP) FusTek Karmony Node Mk III IVA mockup The general design inspiration for these interiors comes (naturally) from those in the real ISS's USOS segments, especially the Unity/Harmony/Tranquility nodes, therefore for the most part only a narrow cuboid of corridor space (with the obligatory beveled edges and the stepped recesses for the hatches) will actually be accessible to Kerbals. The remaining space will be for monopropellant and batteries as well as faux storage lockers for crew provisions and equipment. A fair amount of time was devoted to determining the optimal bulkhead thicknesses and devising structurally sound joints, as these would indirectly affect the dimensions of the interior layout. Special care was taken near the hatches, as I envision some sort of clever pull-in-and-slide-away design preferable to swinging panels blocking access to drawers. For clarity, details such as the actual hatch mechanisms, light fixtures, standard environmental controls and microgravity handgrips were omitted in this mockup. Obviously, to keep poly counts and draw calls low, only the innermost faces will actually be modelled in Blender. These are temporarily highlighted in a rather loud shade of mauve*, which will eventually be replaced with a FusTek'd version of the USOS interior aesthetics (white panels with blue trimmings). *Not exactly the panty-twisting, dinky di aussie way of doing things, but still, a sensible approach nonetheless.