wasml

I suspect this could be done with a module manager patch - there's a part attribute in the cfg - "maxPressure" - that defaults to 4000 according to the Kerbal Space Program API. You would just need to replace (or add if it wasn't already there) and set to a different value. You might even be able to tie into the part upgrade system. Note: If the "maxPressure =" isn't in the cfg file it defaults to 4000 - that's why you don't see it in some (most?) part cfg's.

I created a number of part projects including the Blender and Unit projects - one is a solar panel - so people could open the project and see how it was put together.

The node_attach = XPos, YPos, Zpos, XDir, YDir, ZDir line in the config controls how surface attach works. Typically the one of XDir, YDir or ZDir is 1.0 and the others 0.0 - depending on which axis you want to attach on.

Just saw the "This thread is quite old...". Just wanted to say that this isn't dead, I have a partial deployable wheel/landing gear in the works (Thanks for the tutorial blackheart612) and want to add a a deployable landing leg then update all to use the current Unity but RL is rather busy and it will be awhile before I get back to this - at least February.

In the config file there's a field "buoyancy" that you can adjust, default is 1.0 It's a pain to adjust - change the cfg, reload, test, change the cfg..... so I created a very simple plugin to help - Add the module to your part's cfg and then in game adjust to the desired buoyancy (then copy that value back into your part's cfg and remove the test module). You're welcome to use it if you'd like (MIT license) code included in the zip. Dropbox link here if you care to use it. Thanks for sharing sharing your creations! Edit: this worked in 1.4.3 and a brief test in 1.4.5 worked.

I had forgotten about this one and was just confronting a similar issue that this should take care of very nicely. - Thanks!

Making some dangerous assumptions here based solely on your screen shots – you've likely though of some or all of these. That said I'll toss out some thoughts in hopes of triggering some ideas on your side. Have a balloonet in both end caps to adjust AOA. Pro – adjustable AOA so you can point up or down and the engines can drive you up and down faster that just the lift (or lack of). Con – more complex UI/ UI uses more screen space. Could have one fill slider and one balance slider – balance would just move air from one balloonet to the other without changing lift volume/balloonet volume ratio. Problem – you know people are going to build crazy contraptions that won't have a clear front/back (think an end cap at front/back/left/right/top/bottom) and the poor balance slider code is going to have a melt down. Rigid airships with multiple internal cells (Wikipedia says the LZ 129 Hindenburg had 16). No balloonets unless I misunderstand. Con – potential nightmare UI unless control could be condensed – maybe a full/empty slider and a gradient slider? Open cell (think hot air balloon) – pressure is always ambient and temperature alone drives lift.

If your looking for modeling info I've started a page with the complete project for various parts Each demo part includes the Blender, Gimp and Unity projects and some notes. While it doesn't cover the basics (like how to use Blender/Gimp/Unity) I've tried to add notes with some of the gotcha's and special requirements. Word of warning - it all made sense to me when I was putting it together but if anything doesn't make sense feedback is welcome. And to repeat what Matrix Aran said - a simple project (like a fuel tank) would be good to get you familiar with the work flow.

Have you seen this site - covers most of North America in one format or another https://viewer.nationalmap.gov/basic/?basemap=b1&category=ned,nedsrc&title=3DEP View

Take a look at Neist Airliner Parts:

I have a Gimp dds plugin that seems to work - I don't remember where I got it but a quick google of the author takes me here

Just got a chance to play with this a bit - Nice! Only thing I've found so far is in the OP - under basic usage "ModuleGenericAnimation" - I think that should be "ModuleAnimateGeneric" Thanks for sharing this - it opens up many possibilities.

I've double checked - did a fresh install of 1.4.4 with only Cartographer added. KSP came up as usual without any delays and didn't see any Cartographer related errors in the log - but no directories were created and no maps. To be clear there were three files in Sigma\Cartographer\ when I installed it - the dll, the version file and the cfg file - directory was unchanged after booting KSP and then quitting from the space center scene. I then made a fresh 1.3.1 install - same same setup as the 1.4.4 test. I booted KSP and there was a long pause before the start screen during which time the PluginData\Kerbin\Sigma\Cartographer\Maps\ColorMap path was created and the map created in the ColorMap folder. This was my cfg file - copied for the most part from a post by blowfish: SigmaCartographer { Maps { body = Kerbin // the name of the body (default = Kerbin) width = 4096 // the total width of the texture (default = 2048) tile = 2048 // the width of one tile (default = 1024) exportFolder = Sigma/Cartographer/Maps // path for the export folder leaflet = false // export in folders divided by columns and rows (default = false) heightMap = false // export height? (default = false) normalMap = false // export normals? (default = false) slopeMap = false // export slopes? (default = false) colorMap = true // export color? (default = true) oceanMap = false // export ocean? (default = false) satelliteMap = false // export satellite? (default = false) biomeMap = false // export biome? (default = false) oceanFloor = true // include the ocean floor ? (default = true) normalStrength = 1 // strength of normals (default = 1) slopeMin = 0.2,0.3,0.4 // color for 0° slope (default = 0.2,0.3,0.4) slopeMax = 0.9,0.6,0.5 // color for 90° slope (default = 0.9,0.6,0.5) LAToffset = 0 // offset latitude (default = 0) LONoffset = 0 // offset longitude (default = 0) // if you want to print only selected tiles // add as many of these as you want // if you don't add any of these // all tiles will be exported //printTile = 0 //printTile = 1 } Info { // List all the bodies for which you want info on // the lowest and highest point on the planet //body = Kerbin //body = Mun } } I have the log files from both tests and can upload if you'd like - or I can see about opening an issue on you github page.

@Curveball Anders I was playing with this a bit and not getting anywhere then realized the inter stage nodes are off by default - turn that on (in the parts right click menu) (Doh!) and the nodes appear. Was able to directly edit a fairing to double its size (I know - not quite what you want but should be able to only scale one axis the same way) so I believe it is possible - just a question of figuring out the MM patch. As far as the node_stack_top/bottom - I think those are the nodes on the base so you shouldn't need to mess with those.

You'll find instruments and seats and other props in the GameData\Squad\Props folder

Ran across this just a few days ago - looks like it's for 1.3.1 - doesn't seem to work in 1.4.4 (a recompile might help) Sigma-Cartographer

There's also this one (much out of date):

Nice! Curious how you place these and are they generated models or procedural? PS - you might want to take the keys away from that Kerbal - he seems to have trouble keeping it between the lines (or off the sidewalk for that matter)

I've played with this a little and the truss sections all had an actual model behind them (each individual section had a separate model). In other words you might be able to move the nodes but the actual truss won't stretch to fit.

I haven't done this so can't give you any advice other than to look at some of the existing re-texture mods that are out there like Dark Textures for examples.

I like to keep the parts list parred down so would personally want this and will probably make one for myself if you don't. I prefer to avoid dependencies if possible and (depending on what you do with the nose cones) would consider the variant route if I did this and it didn't restrict the functionality. For backward compatibility you could always save off the current config files and store in a non-GameData folder - users would need to remove the variant config and replace with the individuals to use in a pre 1.4.X game - could create a bit of a headache support wise though. Side note: Someone (RoverDude?) had a post that said mass changes are now possible with variants in 1.4.4 (but I haven't found any examples in my limited search) and didn't save the post location. Edit: Found an example - look at the structural tubes in Making History - Variants can change both cost and mass.

Does the track always move east? That looks like about 350 meters - suspiciously close to the distance a point on the surface would travel in 2 seconds as Kerbin rotates.

A quick test (RSR v1.8) on 1.4.4 doesn't spam the log file and parts are in game - fairings in the payload section. This looks like a parts only mod and they typically have far fewer problems than plugin's with version changes. If you want to stick with 1.2 you might make a copy of the KSP folder and test the RSR 1.8 parts in the KSP copy - Fairings did change significantly at one point and so might not port back to 1.2.

I believe RemoteTech does signal delay:

I think I understand - your saying a field or event could be waking the module back up and I need to disable them. I'll go poke at that - Thanks!