Greys

they're the limp joints from Damned Robotics, which isn't officially updated and doesn't work in legacy mode.

There are a lot of ways to have empty containers, from mods like Empty Tanks (sorry no link) to ModularFuelTanks, but in this case since you're making something custom, you just make it empty to begin with. For those that don't know, you define a part's capacity to hold resource with this: RESOURCE { name = ResourceName amount = AmountItStartsWith maxAmount = AmountItCanHold } So if you want it empty, you just set amount = 0, and it'll be empty on the pad. Again, if you want it to vary, ModularFuelTanks is best, it lets you manipulate levels in the VAB/SPH to fit your needs, but if the part should always start empty, this is the way to do it.

Likely both of you are installing it into /GameData/. None of the mods available in this thread are updated to .20+, they are only updated to be compatible with .20+'s legacy mode, and as such must be installed in the .19 way.

It took much longer to come up with a pun as great as that than it did to make the model and texture. It Stays.

even if you don't go with PNG given it's loading issues, there's also TSA which is editable and nearly as native as MBM Edit: TGA. http://forum.kerbalspaceprogram.com/showthread.php/35225-Some-lesser-known-bits-of-info-for-addon-developers I don't use TGA myself because it would make hexcans take up 16 times more space, bringing it to 53MB instead of 3.8MB, but this shouldn't be a problem with a set with fewer unique parts.

Doing transparent textures doesn't really work right and there are no other ways to get this done, either you model the actual structure or you have transparent regions to indicate holes; but KSP doesn't render through transparent textures, you just get a hole in your part with no back. Even if you have a double mesh to render the inside; plus KSP won't do any shading on anything seen through the part. It just doesn't work good. For something as large as this, the way it is is the best way. But also the way it is is miniscule. Even a mediocre computer can handle a visible model with thousands of polygons just fine, it's only visual. What needs to be kept low is Collider models which are involved with the physics engine.

as they're both applicably functional for the needs of modding this game, whichever you can use better.

Sometimes when science needs doing you need to measure very very small things. Jeb doesn't do that kind of science. Jeb's Big Stick is available on KerbalStuff.com http://beta.kerbalstuff.com/mod/33 Useful for all sorts of things, from confirming the size of your own custom parts, to getting measurements for compatibility with somebody else's custom parts, to knowing just how big a space you have to fit a thing in your cargo bay, or space between docking stabilizers. Straight from Jeb's back yard the brand spank'n* new "Big Stick" 10 meter scale with 1m, 0.1m, and 0.01m markings to allow for accurate measurements down to the centimeter. *We are not responsible for any injuries sustained by using a 10 meter long steel plate to spank your significant others Simply attach via the convenient attachment node or by simply placing it on a surface where ever and however you like. Warning, the Big Stick is not intended for practical use in flight, it is 100% guaranteed to suffer from strange physics, weighs quite a fricken lot, and will usually win in a fight.

I've decided to abandon the radial scale plates for the moment, the having textures reliant on roughly four thousand semicircular sections that cannot be simply generated via copy/pasting is just too much work for little gain. I've uploaded it to spaceport, you can find it here: I don't expect there will be any further development except as necessary with future updates to KSP. If you'd like to mess around with it, here are my assets. But it's not particularly hard to make yourself. Taking down all MediaFire and SpacePort links Release Thread here with new download: http://forum.kerbalspaceprogram.com/threads/37196-20-x-Jeb-s-Big-Stick-For-all-your-large-measuring-needs-v1-0

These new wheels are the best! Jet Rover~ With the new V-Twin RTG, it looks great and I love the effect, but as appropriate as the circle ridges along the heads are, the way KSP handles fine grain textures makes them not look very good at any range Up Close http://i.imgur.com/ee969Fu.jpg A bit farther away http://i.imgur.com/LHgJvRM.jpg And then you can go back to the first picture for even further. It's KSP's fault but I really do think it detracts from what is otherwise a great part.

I look forward to giving this a shot, honestly getting things into space is my least favorite part of the game so eliminating supply runs is a huge boon to me. Just a word of warning though, the download counter on spaceport appears to have little to do with anything, mine lists some 1700 downloads last I checked and I'be gotten little to no traffic in my threads, and the downloads on all my other hosts combined is less than 100. I figure some web bots or search spiders are triggering the counter or something.

Make sure you change the internal name as well, o whichever loads last will overwrite the former when you launch

Sorry, I updated the mediafire downloads last night and they have it, but I forgot to update the spaceport download. Quick question if anybody cares to answer. I'm a bit torn over having spaceport at all, a week or so ago it was brought to my attention in the unofficial IRC channel that certain parts of the SpacePort addon upload ToS are entirely unreasonable. For instance, This thread is in violation of them because I am advertising my addon and I am providing it from places that are not SpacePort. So the question is, if I removed HexCans from spaceport for those reasons, do yalls think that would prevent you from giving it a shot? PS: Spaceport updated.

All the Vessel events are likely things that occur in the flight space, OnVesselChange being when you [ ] between ships

That's factually inacurate, the models for the stock parts are built on a meter scale because they used to be meter scale, but then physical Kerbals were added and they don't conveniently fit inside a meter tube so they made the stock parts 25% larger, thus creating the 1.25 standard, which is 1.25m within the game, they are not nor do they purport to be 1m, 1m in KSP is still 1m. Edit: It's difficult to get truely accurate measurements of cylinders, especially the stock cylinders because what you see and the collision mesh are only vaguely related, in this case that mating lip is non-collidable, and the orange tank wall is inset from the actual 2.5m standard for aesthetic reasons. As such the tank wall is slightly less than 2.5m, and the lip is slightly more. Not so much of a problem with LLL.

when a description or name refers to something as being 2x4, is this an arbitrary designation within the LLL set, or is it supposed to be a measurement? I ask because I made this yesterday and later on noticed that by the numbers for the fuselage sections (2x4 2x1 ), my hexcans appeared to be hugely out of scale, and I did just do a big change so I was worried Once I had the chance I grabbed my 10 meter stick and measured it to be sure turns out the 2x4 2x1 is 2.6m wide

Bwhaaa? As far as Kethane goes, how's this look? I know there's volume data for Kethane in the Spherical Tanks thread, I'll go find that and see how fast I can get this done Edit: I don't have time to make a full repack but here's just the new stuff, only compatible with 0.3.0+ link gone Re-edit Found some time after driving all over town to get food for my stupid cats (I love you cats but you're dumb as balls), main links updated with Kethane hexcans, I'll leave the patch link active till morning

he was just generally jammed in the rollkage in such a way that he couldn't move out of the seat even though he had fallen out. But scratch that, a rather more astounding thing has occured, a bit over half an hour ago in real time I pulled a stunt and destroyed both the backup probe (may be involved in what I was describing) and Jeb. The rover is still rolling around, and I've had it at 4x physical acceleration. It got so silly that I've started streaming it http://www.twitch.tv/greys0 No commentary, no content, not even really related to this thread, but I can't quite look away

haven't gotten a chance to play with the new one, but I just remembered that I had a mission planned with the old one (a week late) to the mun Clearly I'm not playing legit at the moment So much fun but quite unstable. Odd discovery, Jeb has been outside his seat for quite a while now, and it causes a lot of collision glitchyiness, but he is still controlling the rover, probably because he's locked in contact with it

Cockpit looks a lot less like nothing now And the other parts with mostly just the bumper material look decent as a beginning Only basic colors applied so far, and time to sleep, it's nearly sunrise

New version! No functional changes! v0.3.0! Moved to the MODEL{} system, split the Decoupler model into a Rack and Pistons model, the rack and decoupler both use the Rack model, the Decoupler overlays the Pistons model onto it. I'm trying to figure out a way to have a similar system for textures, which should allow me to have one full hexcan texture and a bunch of much smaller label plate texture sheets If you mess around with the unfinished parts the HexPod is now available untextured, and largely not set up Also the RamHex or whatever hexy BS I named that thing has a terrible texture, but I've got a plan~ Also the TurboHex engine has been made less powerful, and I messed with it's velocity curve. I should be able to figure out some base textures for most of the Unfinished parts this week, then all that's left is to get them to resemble balanced and I'll probably call that 1.0.0 After that things might get a bit more interesting

Visual example of what I'm experiencing All of the hexcans are defined with MODEL { model = HexCans/Models/HexCan position = 0.0, 0.0, 0.0 scale = 2.0, 2.0, 2.0 rotation = 0.0, 0.0, 0.0 texture = HexCan000, HexCans/Parts/HexCanLiquidFuel/LF } and rescaleFactor = 0.5 rescaleFactor = 1.0 rescaleFactor = 2.0 to vary the size. Here's the catch The racks are exactly the same. Here's another catch. If you were to say that MODEL{scale = x, x, x} and rescaleFactor = y Y=0.5 & x = 2.0 results in the part being 0.5:1.0 scale y=2.0 & x = 0.5 results in the part being 2.0:1.0 scale Y=1.0 & x = 1.0 ALSO RESULTS IN 2.0:1.0 SCALE

I just took my first whack at this and two things stuck out My part with scale = 1.0, 1.0, 1.0 and rescaleFactor = 0.5 appeared in game as one quarter of it's normal size, instead of half. Setting scale = 2.0, 2.0, 2.0 resulted in it being one half as intended. Relying on rescaleFactor means I get to use regular attachment node definitions which do respect rescaleFactor. texture = etc, only works if the model you're referencing had a normally loaded texture file applied to it already, you cannot simply have a model file shared between similar parts and have each part apply it's texture, there must be a model000 texture file present in the directory with the model or it'll just be white no matter what you say.

Progress kinda~ Fiddled with the RamHex intake texture, it sucks but there's potential. I keep forgetting how I made the texture of the black elements and they look very different at the moment. Finally got around to making the HexPod exist in game, though it's not yet cfged properly (still thinks it's a probe) The TurboHex engine is now in a state of resembling balanced, currently they produce 40 thrust and are most powerful between 400 and 1500m/s and completely worthless at 2600. plus one large hexcan of fuel will run one turbohex engine for about two hours, the curves make it difficult to say exactly how long. Changed things in the unity set up a bunch and set up the models for the unified model change Moved everything onto a Github https://github.com/Greys0/HexCans I'm not going to put up a new update till I complete the model changeover, and very little has functionally changed

It's a bit difficult to locate nodes along the angled faces given that they have to face the correct direction and be lined up just right, but it's something I definitely plan on, I was intending to do it with the change to gameObject based node definitions at the same time as I moved to unified models, but currently gameObject nodes are bugged in a lot of key ways, namely for this part set they ignore rescale factor so only the Normal size cans would function. Hopefully a 20.x patch comes out soon that addresses the problem. The nodes need to be addressed anyways as the small can is scarcely visible under it's nodes, and I'm not one to wait for updates to fix problems I can fix myself, so I'll see what I can do. I do worry though, at any node the small can is just too small for 6 radial nodes to be easily used. If only bilateral nodes and triradial nodes weren't exclusive.