Bluegobln

IIRC the sizes for KSP are normally 0.5m, 1.25m, 2.5m, and other packs have introduced 2.18m, 3m, 3.75m and 5m as well (just from some packs I have seen). Technically, parts models can be any size you want though, it's just a matter of whether it matches or looks good and such.As far as different sized parts, you can adjust the parts sizes by modifying the CFG files if you like. Right now THSS uses 2.57 part scaling which is because they're modeled in inches I think, if you double that to 5.14 all your tri-hex parts will go from 1.25m to 2.5m. I'll do the math for scaling numbers in the CFG for y'all. (Untested) For larger Tri-Hex pieces: - To make the 2.5m adapter into 3m you change your rescale factor to 3.084, which will make the Tri-Hex inscribed circle about 1.5m - To make the 2.5m adapter into 5m you change your rescale factor to 5.14, which will make the Tri-Hex inscribed circle about 2.5m (side effect, the 1.25m adapter becomes a 2.5m adapter, this is probably the most ideal) For smaller Tri-Hex pieces: - To make the 3.75m adapter into 2.5m you change your rescale factor to 1.71333~, which will make the Tri-Hex inscribed circle about 83cm - To make the 2.5m adapter into 1.25m you change your rescale factor to 1.285, which makes the Tri-Hex inscribed circle (and the 1.25m adapter) about 62.5cm So those three will give you Tri-Hex pieces of inscribed circle sizes 1.5m, 2.5m, 0.83m, and 0.625m (standard is ~1.25m). Since you're only really doing this to resize the Tri-Hex shape, its better to make the adapters line up with other sizes rather than the Tri-Hexs line up to other sizes. It's not too hard to do the math for other sizes if you want to. Personally, I like the size they already are, though I might like some smaller stuff for making more fine details. Also note: If you decide to do a rescale on the parts, you can create duplicate copies of the parts folders and rename them so you have the original sized parts still, but I am pretty sure you also have to rename the part inside the CFG file as well (which you'll be editing anyway so no problem). The one that matters is at the top of the CFG, but you can also edit the one further down which identifies the part to the player in-game (and change description, fuel amount, etc).

What if your payload is non-circular, something odd shaped, or can't be made to fit in a faring? Are you boned? Try to put farings around it? Must everything I build fit in a faring or be made aerodynamic? Asparagus could be one of my problems, I usually use some form of additional liquid tanks and engines with decouplers around the main, but I don't see how that might cause the tumbling by itself. Doesn't an array of engines with good vectoring typically INCREASE your control and stability? *confused as hell by that* I can see how it could be a problem of drag though. Will extra engines mounted with aerodynamic surfaces flush against the main stack work though? I thought it was clear from the first sentence? All of my rockets tumble no matter what I do about it. The only successful launches I have are some kind of insane combination of skill and luck while threading a fine needle. :|Thanks for the tips.

How does one prevent one's rockets from tumbling end over end. This mod is ruining the game for me, and I am about to remove it, which is sad. I've tried redistributing fuel. I've tried making craft more aerodynamic. I've tried balancing, massive clusters of RCS, winglets in all kinds of different positions. I've tried slow ascents, fast ascents, staging, non-staging, small craft, large craft, more thrust vectoring, less thrust vectoring. I've done everything I can think of to discern the source of this issue, and it seems to me the issue is the mod does not work properly. Real rockets do not tumble end over end like this in EVERY SINGLE CIRCUMSTANCE AND SCENARIO. The only thing I have not tried is putting my rocket engines up top and on the sides and TOWING my payloads into orbit. This is just plain ridiculous. If you can explain it, I'm happy to learn it, but as I see it there are things severely wrong here.

Judging by the image, your poly count isn't even remotely pushing the limits of what's acceptable by the game. For example, some parts I've worked on that are admittedly a bit on the high side, but still work alright (and at least on my fairly high end system run smooth as butter besides the FPS drop from physics processing). Most of mine are 1200-4000 polys. I'd guess that one is like... 120? You have a lot to work with, in any case. Trust me. Just don't get addicted to the freedom of it. Edit: As an example, the Tri-Hex struts you are using to mount those on in one of your images are probably 10x the poly count of your piece lol...

I've been working on making a few parts to expand the THSS list a bit. Here is what I have so far! DL link: Goblin Industries parts for THSS

This is because of collision meshes being different than the model. If you use a really complex collision mesh it can add a lot of load on an already heavily taxed CPU. However, adding polygons (which is what this mod does instead of using heavy textures) is mostly landing on the GPU I believe. So basically you have a situation where the models are higher detailed, but it is not a good idea to use nearly that complex a model for the collision, so you end up with a basic bounding box instead.For the extremes of quality, every one of these models could be made with a customized collision mesh to make the collisions work flawlessly like you'd expect. That would be a lot of extra work though, quite a lot. :| If there are specific pieces that are busted, rather than all pieces of a certain type behaving the same way, that's probably a bug worth looking at though!

I assume this is still the case. I have hopes for your ideas about keeping compressed versions of the textures to hugely improve the game's load times. Basically I see a few simple needs here:1. Need to be able to keep pre-compressed textures and load them automatically. 2. Need a way to manually tell KSP to re-compress the textures again, such as when you install new parts, or update old parts. 3. As an improvement on #2, a way to automatically detect changes to the parts folder, and thus automatically know to compress files again. (Check to see if new parts installed? Check to see if files' date modified has changed?) How much of this can be done outside KSP itself is well beyond my understanding of software. I'd guess a lot of it would have to be implemented by the devs themselves, though they sure would have an interest in improving their game in this way I think. Maybe if we rattle some pots and pans they'll hear us over the sound of the rocket engines.

To have a balanced "realistic" warp, even though they're only theoretical right now for us of course, you need a fuel source that would generate immense power to generate the field. To the point of inefficiency. I imagine that the early forms of it (the ones we can envision) would actually be so backwards compared to our current methods of travel it wouldn't be helpful. However, the key lies in the improvement of that technology over time. As it gets refined and made more efficient it would become competitive with other propulsion, then surpass, then eventually far surpass as speeds began to increase and/or efficiency increased (through better fields, better parts, more effective fuel sources, etc..) Personally, I wouldn't touch warp unless it was a novelty propulsion, literally a worse method of traveling than others (by that I mean more difficult, such as having to launch MORE fuel into orbit than other methods, or it burns 100x the fuel mass per distance traveled or something). Then it not only has the futuristic appeal, it also has the hardcore appeal rather than the cheat appeal. If you make it "hardcore" then you can pretty much fudge the numbers all to hell on the realism front and nobody will complain (except the people who want it easy). Heck, if you get people wanting it easier, release a more easy version too. Just change a few values and presto, less hardcore.

I believe the intent is to move to using user editable PNG textures for every part in the future. When this happens the compression makes more sense, I think. It begs the question: can't we use PNG's now? Then why the HELL don't people use them? However somehow having the option to enable pre-compressed textures for parts that wish to use them in the CFG file would be INCREDIBLE. My guess is it would take only a few simple changes to the code in the game, and an addition to the code for part CFG's, and bam, no problem! Course then we'd have to compress things ourselves when making parts, but that's not really difficult to set up.

This is cool. Many types of ships can be built and launched from the Mun that cannot be launched from Kerbin.

For the sake of sanity, I recommend writing a plugin or method for changing the fuel type between different fuel tanks. This would already be a benefit to the game as is, with just what I have (Liquid, Ox, Xenon, Kethane) but with even more fuel types it would become exponentially more useful to have. So for example: you have a basic fuel tanks. It holds X fuel units. These units are translated into their specific fuel equivalents, 1 "FU" (Fuel Unit) is exactly 1 LiquidFuel, but it would be something more like 10 Xenon, 50 Kethane, etc. Then allow us to pick which fuel to load into the tank on a per-tank basis while in the hangars. Suddenly our parts lists become half the size they were. Well, more like they'd shed a few pounds, but still a major improvement. You only need one fuel tank of any particular model (barring size differences) rather than one copy for each type of fuel.

Ok I got the model into the game and it seems to be working ok but I can't get the animation to work. Its likely that the problem is on the Unity side of things or somewhere between 3ds and Unity. It could just be the CFG file though, so here's as far as I got. I shamefully borrowed your sails CFG stuff. The animation is named "sailExtend" if that helps. Goblin Enterprises Solar Sail (not working presently)

It is probably a specific part that is going haywire. I don't have this issue with the parts, which parts specifically are you using?

I want solar sails. Your version is very cool. Obviously I want a version that can provide thrust while time accelerating at a much higher than 4x rate (who doesn't), BUT, I want them all the same. I am willing to accept painful tedious versions temporarily, though. Since you've essentially made them, I think I will contribute to this goal with my model. This is a pretty darn early version so be gentle. No textures obviously, but it is animated (relatively well IMO). Due to my lack of interest in FOLDING a massively large amount of "cloth" in animation, I decided these guys have access to some kind of extremely stretchy material that automatically bunches itself beautifully when you retract the sail. If this works well once I get it into an actual part format, I will probably go to the trouble to add an outer casing and animated doors, etc.. (Would probably make it a 2.5m part, right now the core is 1.25m). Edit: Forgot to add, the arms are just about 165 meters long, so the total span is about 330 meters. By solar sail standards that's REALLY small, I think.

Wasnt sure where you check most often, so I am cross-posting. I have some ideas but of course I won’t be upset if you don’t make any: - Round versions of all these (same style though) - Square versions of all these (this has kinda been done, but I like your look best) - More conversion pieces (tri to square, tri to half meter, tri to offset half meter, tri to offset 2.5 meter, pieces that match with the stock square/rectangle stuff, etc) - 90 degree angle tri piece (like the big 6 way piece but just a 90 only) - More 100% enclosed pieces of things (no visible internals, but still tri struts!) - More of the small size stuff (0.5 meter tri struts) though it might not be necessary to do a half meter version of EVERY piece, that seems like a lot of work lol I am trying to get into modeling and building parts myself. When I do, the first thing I am releasing will be parts that look good alongside this pack. Maybe if you don’t tackle some of the above, I will try. *salute* best pack to be found IMO.

Thanks mate. Appreciate it.

Link? I'm looking and I don't see what you're referring to, bud. It is chin deep in the complex stuff, I'm guessing, and I just can't be bothered with reading all that when I have no intention of doing more than modifying CFG files. :(As far as the distance thing, that makes sense. I'd like to know what the other values are for or if they even do anything, but that alone is good enough. Thanks! Also, 10x multiplier when you're on the surface of the sun eh? lol I am actually flying a Sun mission soon, so I will share data on whether the solar panels perform... above expected. (Or perhaps they will melt).

So I realize there is a very handy and thorough guide on the wiki page here: http://wiki.kerbalspaceprogram.com/wiki/CFG_File_Documentation However, the one thing that is missing that is driving me bonkers is this little bit that is part of every single solar panel array of any type. MODULE { name = ModuleDeployableSolarPanel animationName = bigsolarpanel raycastTransformName = suncatcher resourceName = ElectricCharge chargeRate = 14 powerCurve { key = 206000000000 0 0 0 key = 13599840256 1 0 0 key = 68773560320 0.5 0 0 key = 0 10 0 0 } } Specifically, I want to know what the non-obvious stuff does. I assume it has to do with which angles the sun is caught by the array, and to what degree that affects the power output of the array, but nobody seems to have or be willing to share if they do on what specifically these numbers represent. The big number eludes me completely: key = 13599840256 1 0 0 key = 68773560320 0.5 0 0 key = [what does this mean?] [I think the amount of power the array receives for this given sun angle] [?] [?] Now.... assuming someone does have this information, I'd love if they pointed out where I can get it, or just tell me here (which would be fine of course but then we'd have to be sure to go about getting it on the wiki as well). If nobody has this information, then I'd like to propose we experiment and figure it out if possible. Seems like a useful thing to know how to do. Ty for your time.