Greys

Thanks for the encouragement! I can definitely understand that, they are a little more sharp than I had intended but I decided to simplify it to keep polys down, originally they were going to be semicircle cutouts. They're supposed to be something along the lines of the the impact absorbers on nuclear waste transport containers, so I'm still considering having a variant without the bumpers, it'd have even lower polys and be able to fit into smaller spaces; but doubling the part count leaves a pretty big number so I might only provide them in the Small and maybe Normal sizes and certain contents.

If you can figure out how it should be perfectly allowable to make a binary patch(er), that itself only contains the changes to the code and where to overwrite it on the plugin file. But yea, have fun with that

I've been working on this since about 26 hours ago, with probably 6 hours total low density work spent, and I finally got to a point where it is something and it doesn't look horrible. So it's a system of little radially mountable but also stackable hexagonal cylinder things for unspecified purposes. This may sound to you a lot like a certain other radially mountable cylinder things for unspecified purposes pack, Orbital Industries. Because it is. OI is wholly the inspiration for these parts (few that I have right now). But unfortunately due to the forum crash, OI's license is nowhere that I can find, making it essentially off limits for any new developments. Seeing that and resigning to it I thought, how hard could it be to make a fricken cylinder and paint it kinda nice and fill it with ****? not that hard actually. Get It Here's the download, pictures to follow http://forum.kerbalspaceprogram.com/threads/33754-0-21-x-HexCans-Standardized-Resource-Canisters-0-5-0-Now-with-aircraft-stuff! Dev Log So far I have three sizes of canister, 3m, 1.5m, and 0.75m based on this model via rescaleFactoring http://i.imgur.com/jRNC7A1.png http://i.imgur.com/LSNv5nk.png There were some snafus with unity http://i.imgur.com/aRdZJfi.jpg But after figuring out who was at fault between the three programs, it all came together http://i.imgur.com/QI7YUTw.jpg http://i.imgur.com/VvQQqWj.jpg (Everything is subject to change, nothing has been balanced yet) Then it just needed a better coat of paint http://i.imgur.com/f8jf8fg.png #==== 5/17/13 I've just finished the cfgs and textures for all of the stock resources except Xenon; can't figure out an icon for it... The resource amounts have also been balanced to match stock volumes, we'll see if that sticks... http://i.imgur.com/xbTd6NA.jpg #==== 5/22/13 Haven't achieved much over the last week, but I have gotten nearly all of the stock stuff done, the only things not finished are the ASAS and SAS bits. Also, updated to the .20 format, just copy the HexCans folder into your GameData folder to install. If you have any, I highly suggest deleting the old HexCan parts because names have changed; please remember to remove them from your ships and .crafts to prevent weirdness. Textures have also changed, and will probably change more as I finalize colors and eventually move over to the new UV map... which will just be a lot of work... New stuff!: Xenon textured and added RTGs in all three sizes; note that the Large RTG is not on by default; I may make it more complex. Normal and Small Probes! in the picture below the unmarked cans with Blue caution tape are probes, the Large size will be a manned pod but I still have to make it's texture from scratch due to the differing model. Battery color changed from Green to Red; this is to free up Green for Kethane later on. I don't have any other mods loaded on .20 yet, so the rack is less beautiful, but oh well. http://i.imgur.com/gTSexcN.jpg I will probably be making Monopropellant a darker, more pastel shade of yellow, maybe tint it orange a bit. PS, I entirely renovated the organization in the archive (also now provided in both .zip and .7z) to be cleaner ##### 5/24 Finished everything. Stock anyways... http://i.imgur.com/IEmNaSO.jpg Downloads updated, Colliders updated, no changes to previous textures Rebalanced part weights, fixed some resources that were labeled wrong Sorted the cans into their correct categories Submitted to SpacePort. ##=== 5/26 Fixed a bunch of stuff, took more advantage of .20 to reduce the model count by a third; when they fix the referencing things in different folders bug I'll be able to reduce it to a total of 3 models where currently there are 14 (and previously there were three times that) More importantly though, I made the surface attach rack, cuz it's snazzy, and the Decoupler Rack In blue is the rack itself, in green is the pistons that make it a decoupler http://i.imgur.com/LS5KnsH.png In Game In Action http://imgur.com/a/Inx2F License This set of parts are released under CC-BY 3.0, you are free to use, alter, or add to as you desire, you may release your works using HexCans under whatever license you desire though I suggest open source as it's good for the community. You may distribute your works however you like. Rules of Attribution To make it simple and concrete I require only one thing to consider your released works sufficiently attributing me. In the .cfg files for all HexCans parts there is the line author = Greys "Greys" must remain in that field, you of course can add your own name/names and I do not care about the order. example: author = BobDole & Greys Nothing else is required for the license to be satisfied. If you can I would like to have a link to either of the HexCans forum threads in your release thread, it does not need to be prominent, but that is not required. ````````` Happy to hear any critique you might have, or advice you'd like to offer

I just gotta say, a sabre engine is bent like that so the air intake will point downward from the nosecone and therefore be pointing more into the air stream; not to either side; but that's about the thing you made out of it; they look awesome. I appreciate your openness, but given the recent forum crash we're starting to run into situations where mods and addon packs exist but their original listing does not and the authors are MIA; And because it did not seem to be important they did not include any form of licensing with the mod/addon. In a situation where we don't have the license anymore, it defaults to All Rights Reserved, and nobody can do anything with them regardless of what it was. so I would encourage you to include a copy of some license you like in the .7z folder to permanently clarify the issue. I would suggest you look at the CC-BY license or the Do What the **** You Want to Public License. The GNU licenses are also pretty good, but they're not very friendly unless you love legal language. As far as making it properly a multimode engine, I've never tried to include two ModuleEngines definitions on a single part but I know you can have multiples of most other things; though they would both be activated by staging so that might not work to well, you should be able to control them separately from the rightclick or from actiongroups. Anything more than that you will need a mod to manage.

Minor bug note; the actiongroup tank config interface will list things the tank can contain, even if they're not defined in the /Resources/ folder. I haven't specifically tried but this would mean that a part made to be able to store Kethane, would show Kethane as an option even if the specific player doesn't have Kethane mod. On that note you should add a cfg flag to specify that a resource cannot be filled from launch like Kethane or IntakeAir, or assuming vanilla doesn't impliment a featureset like this, the resources they intend to add.

I've never seen a mod that adds better gimbaling, but if you watch WinterOwl's youtube series, for his shuttle he puts the engines on Damned Robotics hinges, so he can manually adjust their rest vector, this is pretty hit or miss because DR doesn't give you any feedback about angle so you have to do it all by eye, but it works pretty damn well for him.

you have to do a bunch of extra stuff to make it palatable to unity/KSP, which typically Rhino doesn't give you access to, but if you can make a .DAE you can load it in blender, and blender will let you do all those finishing steps. Maybe also the Unity modeller thing, but I don't know anything about it.

the images look great, though they will look entirely different once textured; I'd suggest sticking to a very simple theme, basic colors, simple shapes, outlines; and a very light texture overlay to make it less cartoony. Pointing the thing is definitely going to be your biggest functional trouble, if you rely on the specific orientation of the barrel to determine where it fires it's going to be nearly impossible to hit anything at a decent range, things wobble too much no matter what you do. If you want to mess around with it now, to a limited extent, it's very easy to add resources to the game, you would want to add ion charge and heat, then make your barrel a Generator type part (look at some mod power sources) that consumes ion charge rapidly to produce heat, with some particle effect shooting out the end if you can, may have to make it an engine to do that. Then make your cooling fin into a generator that consumes heat to do something. It won't actually shoot but you can put the thing together in game and see how that feels.

I encountered the same thing Note the mission time and speed

I'm a hobbiest at modelling with CATIA, the sister program to SolidWorks, and I just wanted to let you know that it's not actually that hard to import a .CATPart model into Blender, and from there you can do anything. From CATIA I can file>save as, and specify the format .STL, which can be directly imported into blender; the only trick there is to make sure that you've set it to use Meters as the unit, the STL does not specify units and Blender will assume meters; so if you export in millimeters, a 1000mm model will be 1000m in Blender. From there you can explort the model in Blender as a .DAE Collada file, which is natively accepted by Unity. I don't know that Solidworks supports saving as .STL but I can't imagine why it wouldn't. Also don't export it as .STP, it doesn't work. Once you have the model imported to Blender you shouldn't need to edit the mesh at all, if you've done things right. You will only need to set up the tree (I haven't gotten that far yet), textures, and the collision box. Best of luck!

Romfarer, the person you're thinking of, has since been hired by Squad, makers of this game. As such you can understand that he's got more important things on his plate. Please seriously take no offense to that. As long as you're not going to simulate ships breaking up; which you can't under the current physics model, you also don't particularly need much of what he has already, the benefit of the Sunbeam destructive lazor is that it effects specific parts, makes them overheat and explode themselves as an exploitation of the physics. This allows you to pinpoint blow up random debris or if you're really good pick parts off of a ship with minimum collateral damage. You want a swath of destruction, given this kind of cannon nothing short of an active sufficiently powerful EM shield would prevent the utter destruction of the target. Now, you're aware of the 2.5Km physics range, which can through Lazor mod be extended to 97.5Km, past this distance the object is referred to as "on rails"; the big problem that you're going to run into with anything more than an effective pinpoint beam is that beyond another specific distance that I don't have on hand at the moment the vehicle is on rails And "Packed", when a vessel is packed, it exists as a single point of information linked to a stored format of the ship's composition and structure. if you're projecting a ray from point A, the barrel of your cannon, to point B, the packed target, no problem. In that situation the beam is purely visual, you've selected a single target and you're dealing with it outside physics. Once you give the beam width and the ability to hit multiple things, now you're going to have to make mechanical concessions. Will the beam only destroy ships who's packed points exist within the beam? That shouldn't be too hard to calculate but it's possible to have some pretty damn massive ships that would seem to dodge the beam simply because their point was outside the beam, even if a large portion of the ship wasn't. Are you going to try and force unpack ships near the beam to figure this out? that's going to be hard, maybe even impractical. And like I said, these things that are well outside the physics sphere and even outside the unpack distance, there is zero possibility that you will be able to modify the object, if you try to shot a rather large space station 400km away, and hit; you have two choices. It's all gone, or it's all still there, even if the ship you're shooting is substantially larger than the beam. It shouldn't be particularly hard to delete an object in space once you've identified your target. Optimistically, this sounds like great fun and I'd love to play around with it, pessimistically I don't think you'll be able to get around these limitations without compromising the feel you want. Unfortunately this is the extend of what I can offer, I'm not a coder myself but these are fairly basic elements to the engine that you'll have to work against. One thing you might be able to work with is using a hidden projectile object; but that object would have to be made the focused object so that physics travel along with it, but this would make it behave as a moment-damage system instead of a continuous beam damage system and you would have to override it's physics (put it on rails) to make it not deflected by the objects it hits.

Information I'd like to have on hand, generically things to do with electricity, less generically: Current Elec. Max Elec. Current Generation Max Generation Max Generation in Shadow (ignoring solar panels) Current Drain Max Drain Max Drain - Ion Engines Time Till Blackout Time Till Full Charge Max Ion Burn Time (at full throttle) Sustainable Ion Burn Throttle % Some of these would be helpful in flying ion-driven ships, running space stations, and mining operations; others would be useful in the VAB/SPH.