Lack

Do you mean have the engine double up as the de-coupler? If so, try this: PART { // --- general parameters --- name = 2x1ENG module = Part author = Lack // --- asset parameters --- mesh = model.mu scale = 1 rescaleFactor = 1.2499 rimFalloff = 5 // --- node definitions --- node_stack_top = 0.0, 1.08, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -1.064, 0.0, 0.0, 1.0, 0.0 // --- FX definitions --- fx_exhaustLight_yellow = 0.0, -0.3, 0.0, 0.0, 0.0, 1.0, running fx_smokeTrail_light = 0.0, -0.2563577, 0.0, 0.0, 1.0, 0.0, running fx_exhaustSparks_flameout = 0.0, -0.2563577, 0.0, 0.0, 1.0, 0.0, flameout fx_exhaustSparks_yellow = 0.0, -0.2563577, 0.0, 0.0, 1.0, 0.0, running // --- Sound FX definition --- sound_vent_medium = engage sound_rocket_hard = running sound_vent_soft = disengage sound_explosion_low = flameout // --- editor parameters --- cost = 1800 category = Propulsion subcategory = 0 title = NE-800 Open-Cycle Nuclear Engine manufacturer = Lack Luster Labs description = This engine achieves it's raw power via lax nuclear reactor shielding laws and an open-cycle engine, meaning that it's legal to pump propellant through the middle of a nuclear reactor. This has a minor and harmless side-effect, the blasting of chunks of the reactor and fuel rods out of the back. It may also be worth noting that opening up the throttle too much can over-load the cooling system, this may lead to a slight 'nuclear meltdown' effect. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,1,1 // --- standard part parameters --- mass = 6 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 10 breakingForce = 200 breakingTorque = 200 maxTemp = 3400 fuelCrossFeed = False MODULE { name = ModuleEngines thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 400 heatProduction = 850 fxOffset = 0, 0, 1.0 PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 700 key = 1 260 } } MODULE { name = ModuleGimbal gimbalTransformName = thrustTransform gimbalRange = 2 } MODULE { name = FXModuleAnimateThrottle animationName = 2x1ENGanim dependOnEngineState = True responseSpeed = 0.005 } MODULE { name = ModuleJettison jettisonName = fairing bottomNodeName = bottom isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 10 jettisonDirection = 0 0 1 } MODULE { name = ModuleGenerator isAlwaysActive = true OUTPUT_RESOURCE { name = ElectricCharge rate = 1.5 } } MODULE { name = ModuleDecouple ejectionForce = 400 explosiveNodeID = bottom } } The problem is that the 2x1 to 2.5m is exactly 2.5m across, many of the in-game parts are less than 2.5m across. I have an idea to fix it, can't find the model files for it at the moment though. Yeah sure, if I'm honest, I was just going to leave them as is. http://i.imgur.com/2Ap7N2A.png http://i.imgur.com/gVLs9JB.png Can't find any files relating to the 2x1 to 2.5m at the moment, not sure where I put them.

Yep, it's in the interim release. From the first post: I don't think I've updated 0.09.9 with it though.

Yes, they're done via animations. You change the Emissive.alpha and then use MODULE { name = ModuleLight lightName = lightname useAnimationDim = true lightBrightenSpeed = 1 lightDimSpeed = 1 resourceAmount = 0.01 animationName = animationname useResources = true } to reference it in the .cfg You may also want to add a light entity in Unity, that'll cost more processing power to run though. You do that by having the animation also change the intensity and range of the light. Here's a quick picture I did for someone else: It's missing quite a few points, such as selecting the parent object (where you put the part-tools) when making the new animation, but you get the idea. I was meant to write a proper tutorial about this, but kind of forgot. I should get round to that really.

They should still be there, under the Utility tab, although they don't really have an icon in the menu (since the part extends to be quite large). I've checked and they are in 0.09.9, are you sure you didn't just miss them? @Tw1 and Cuel, Wow, those are pretty darn cool.

Well, 1.5/180 isn't such a bad error rate. I'll have a bit more of a play with it though.

Not yet, just proof of concept work with the regular CBM. Edit: Track Housing upload updated. Fixes issue with the [4x2] wheel-housing. Here's the link again: 2013-06-10_2TrackHousing.zip

I've scrapped them at the moment, try and prevent myself from making too many parts and they're a little large at 2/3 the height of your average Kerbal. The smaller one is roughly 1/2 the height which is closer to human:railing. 0.10.0 will see a few other old parts disappear from it, they'll be replaced by other parts. In the mean time, you'd best go on space-port and grab the Railings download there then open up the .cfg and then do the whole PART { [cfg goes here] } thing. Spaceport's been acting up for me recently, it wouldn't let me update the railings download or upload new ones. _______________ Updated CBM, with invisible teeth. Works pretty well during my brief testing, how's it work for the rest of you? Here's the teeth's [invisible] mesh in Unity: 2013-06-11CBM.zip _______________ @ickli, Those are some really nice rovers, I should have a look at making some track mounts for the 4x2 sized hulls. May require a new model that.

Ah, that's a pity. Also, I don't suppose it would be possible to post a couple of screenshots of one or two stock part's textures? Don't need the whole texture, I'd just like to be able to nick a few hex codes for the shades of the colours (even if they're ball park figures), so I (and presumably others) could get parts to match the stock ones a bit better (as I really like your part's style, your work with that Orion model especially).

I think I'll have to switch to TGAs, it'll take a fair bit more work though, my fault perhaps for having so many parts. NovaS, Is there any word from the Unity developers regarding if/when the bug may be fixed?

What version of KSP are you using? It uses the new part tools and MODEL{} which doesn't really work with any version other than 0.20.2, that should explain the issues you're having. Edit: Seen it's a problem with the 4x2. I'll have a go at fixing it. Edit: As for CBMs, the lock and teeth looks like it'll work, not sure why I thought it may not. Yep, that seems to work, you'll need to be fairly exact already when you line them up mind.

I've been awaiting the release of electronicfox's tracks for some time now, but I'm having a few problems with it at the moment (Runtime error on launch, could be a conflicting plugin). They do load in the VAB however, so I've re-worked the wheel housing to make some track housing for the MkIII and MkIV. Don't suppose you guys could give them a go, see how much room there is for the suspension, etc? 2013-06-10_2TrackHousing.zip

2013-06-10-LLL-InterimRelease.zip Contains a few of the new things: Update to 2x1 Engine - Fairings and I got the grill vectoring to work as intended 2x1 Decoupler Wheelhousing - [2x1 and a 4x2 resize] An extendable CBM - Interim at the moment, just to see what people think of it Updates to all the Cuploa parts - Fixed window specularity and updated the emissive map. Re-balanced closer to proper weights, mainly BoN calcs from stock and ISS cupola As for CBMs; I could possible work the CBM alignment by having a pair of clamp-like objects on the side, best have them visible if I do that. The problem comes from when the opposing parts come together, having the meshes lock together is orientation dependent, which is a bit difficult to comprehend without a visual guide. If anyone has any ideas for a 'lock and key' that won't depend on the initial orientation you approach from then say (preferably with sketches).

Those are the right parts, I'll just need to think of an easy way to get them to line up properly. @Frederik, Ember's right, the wheel arches haven't been released yet. I may do an interim release with a few new parts as the optimising has been taking longer than expected.

I've been working on [figuring out how on Earth to get] the optimising [to actually work]. It's prooving really annoying to do (as in smashing your face into a brick wall annoying). Sharing the .mu f's up rescaleFactor really badly for some reason, so I've been needing to go back and re-scale them in Unity, then type in the URL for the export for the sharing to work and export with the new 0.20 Part tools (and for some reason I can't change where it will export to). Slow going, but it is getting done. Yeah, I was wondering who many would notice the grill. I was going make a version using the new particle emitter that came with 0.20 Part Tools to make it pump out cooling gas when it got really hot, but I can't get it to work. Edit: Anyway, a helping hand for anyone who wants to make parts that fit to the 1x1 and 2x1 hulls. 1x1+2x1sizes.skp That's a sketchup with the sizes for the 1x1 and 2x1 parts. That's then scaled up by 1.25 when it's put in game.

No problem, now I'm aware of the issue (big thanks to rditto48801 and a.g. for the figures and the likes) I'll see what I can do to work on optimising the textures. Reducing the overly large ones and, texture and model sharing primarily. I should be able to knock some general 1x1 parts to handle that sort of thing reasonably quickly, especially now you can scale parts within the .cfg.

That's to do with the game running out of Memory. There still seems to be something up with loading .png files, LLL especially since there's a lot of texture files, and it ends up taking up far more memory than you might expect (the game seems to prefer raw data, so a .png that's well compressed would lose that compression and take up a lot more memory than you'd think). My recommendation would be to cut down the amount of parts by picking those you want to keep and scrapping those you don't. Other than that, get a image editor and change some of the texture sizes down to 256x256 or so. More about it here: http://forum.kerbalspaceprogram.com/showthread.php/33694-Updated-to-0-20-2-from-0-20-0-noticed-mods-w-png-has-KSP-RAM-usage-get-excessive

I have to say, I'm having similar issues with the 0.20 tools. However, they write the textures and the model.mu, but these are not then loaded by the game. I'm writing my .cfgs in the same way I did prior to installing 0.20 so there may be something new I need to put in. Might have to go back to the 0.18 tools if I can find them.

It can be done, I was working on a version back when I was still using the old Bailey module but I got annoyed with the camera controls in Blender and stopped working on it (too fiddly to work on the inner part of the structure). It shouldn't be too hard to do really, main issue is getting the plants to look nice with their transparency.

@Kreuzung, I could have sworn there was more to it than that. Never mind, it would seem the only excuse for me having not already done it, then, is being both forgetful and lazy @Mechrior, Thanks. Post some screenshots if you do re-build, I'd like to see it. @K3|Chris, Nice ship, I like it. The windows only being on one side was be due to the fact that the habitats tended to stick out behind debris shields, so it was extra-shielding on one side to prevent un-warranted decompression. Although in true LLL style, I got the model upside down so it faces towards direction of travel. Oh well. I had considered hollow walk-ways before, but had dismissed since I didn't know quite how to handle transparency (having close to zero modelling experience prior to LLL) and I'd wanted to try and keep the parts geometry simple to save on system resources and my own time. (Although, as it's been pointed out in another thread there do still seem to be some issues with .png files hogging more memory than they should). Actually, on that subject. Are most people updated to 0.20.2 now? I've been meaning to try with the news optimisations, they've worked wonders for Bac and B9. Edit: Right. That's the air-locks all set up, works great thanks to Vanguard, the parts work function as they normally would without the plugin as well, which is useful as up-dates tend to break plugin. Just doing re-balances (working out better weights for the parts. They're mostly too light at the moment. Conviently the 2x1 hull works out as about 1 tonne), some bug squishing and tweaking then on-wards to version 0.10.0

I keep putting that one off. Kreuzung's updated Vanguard now so I should be able to start making it but I'll need to find the old work which had the .cfgs set up, it'll be somewhere on my HDD but I've hardly kept it well organised so far. Lost the PMs with Kreuzung about it in the forum crash as well, which certainly doesn't help. In the mean time just use Crew Manifest.

Well, then, it's not the fairings but, have a new part. It should fit in well with the stock parts and be useful in walkways, air-locks and the likes. Anyways, I'm rather pleased with how it's worked out. LLL-CircularWalkway.zip Screenshots:

I've got a .cfg for decouplers now. Go to \Structural\LLL2x1BiCoupler\ Create a new text document and copy in: and name the file 'Decoupler.cfg' So that can act as a 'quick-fix' till I get proper textures done.

From earlier in the thread: So H-50 legs: rescaleFactor = 0.45 H-50P legs: rescaleFactor = 0.7 Those variables are both found in the .cfgs for the legs (just use note-pad to open them). Which is in Gamedata\B9_Aerospace\Parts\Utility_Leg_H50\H50.cfg, H50P.cfg for the new one update.

Yeah, I made sure to make it surface attachable as well. It's a bit of a hack-job, I knicked the back-part I added to the airlock to make most of it but it works well enough.

That's a great base, ickli. I really like the double-decker modules. DaDodsworth, if you get that landed on Duna, post some shots. Just made one and got it in game. Not the prettiest thing ever but it works beautifully.Great idea that, Ember. That's what that funny shaped adaptor is for, the 1-1 one, it acts as a cowl for the jet engines and air-intakes. (And it saves me the effort of actually making those). Regarding room for the rover wheels. I've been testing them at high speeds and on different planets. Findings: You'll probably need fine-control due to the placement of the wheels compared to the CoM. Otherwise tipping over while turning is very easy. There's enough room for the wheel so that I haven't run into any difficulties with different loads and speeds. The inner-wheel house is big enough that you can place the rover-wheels either very snuggly, or with plenty of room for the suspension. You can also fake a differential like thing quite nicely by attaching the stock structural parts to the inner wheelhouse, and then the wheel on to them. Snug: No problems with it even at speed. Stable when turning (except violently at high speed). Wheels placed farther down: More room for the suspension, but higher CoM. Leads to things like this. My attempt at the whole extra-planetary buggy shebang using stock structural elements. Oh dear: