Porkjet

I'll just pretend nothing happened ¯\_(ツ)_/¯

Apologies! This version should work now, fingers crossed. It's amazing what one wrong file can cause...

Starwaster is absolutely right, I simply didnt use the correct parameters. This fixed Radiators sometimes not working. I just uploaded the fix, plus additional "waste heat" and "power" ratings for engines and radiators as an approximate indicator how many radiators you need for which engines. Also hid those empty community tech tree nodes, may cause some glitchy lines in the tech tree but whatever.

Ok this is strange indeed, the four radiators should cool it for a at least a few minutes, not just 7 seconds, and they should visibly turn red rather quickly. I just tested your setup (with stock fueltank) and replicated the result. I think this might be a bug with the radiator module. These are my observations: when mounted on the fuel tank, the radiators barely work, but when mounted on a battery or probe core they work as intended. It seems to happen to the stock panels too, but to a much lesser degree. I suspect that high thermal mass might have to do with it. I'll have to ask Roverdude about this. As to your question about the Overheat bar, I've noticed this too, it seems that the gauges represent the Skin temperature, and that heats up much slower than the internal temperature of the engine. You're right that there needs to be more explanation about usage. I'm also thinking maybe some sort of rating system to make it easier to find out how much radiator you need, E.G. engine has a heat production of "5" so you need radiators with a total cooling power of "5". Thanks for your feedback

Which size? How many did you attach? How long was your burn time before it overheated? The large size 3 ones are about half as effective as the largest stock folding panel, and the size 2 ones 1/5th as effective, so you need quite a lot of them if you want to run the engine indefinitely, about 4x size 3 ones or 10x size 2 ones should do it.

Yupp! exact same way, all explained here in detail: http://forum.kerbalspaceprogram.com/threads/83690-Prop-config-files?highlight=prop

Hard to judge without a wireframe picture. What I can see is that the cylinder its based on has an unnecessary amount of segments, in KSP cylinders are usually 24-sided. Depending on size, if this is going to be smaller than 0.625m, which I assume, you should even go lower, 16 or even 12 sided are enough if its small. You don't really need any sort of subdivisiion modelling for this, just plain old box-modelling. Those little vertical frame pieces at the top look like they might contribute a lot of unnecessary polies. If you have to have em at all, just make them simple wedge shaped pieces that you place on the mesh. I dont think you need to model all those distinctive lips on the lid there either, just make it a flat cylinder top on which you place the wegdes and the little center ring. Generally speaking, think of how you can simplify and approximate the shapes. Only model out the rough and most defining bits, leave out tiny details or paint them in the texture. Work with intersecting pieces, it saves a lot of polies if you can just stick a detail onto a surface without having to carve out a hole and connect everything to make it manifold. Hope this helps a bit, please keep us up about your progress. If you've got more mesh related questions, a pic of the actual wireframe would be very helpful.

Using atlas textures over mutliple models is more efficient since it reduces the amount of individual render calls for the textures. You can reuse parts of the texture across multiple meshes, potentially saving time and performance. To do this in KSP, use "MODEL{}" instead of "mesh = " in your CFG example: MODEL { model = Squad/Parts/FuelTank/mk3Fuselage/LFO_100 } It will automatically look for textures in the same folder that match the internal reference name of the texture assigned to the material you exported with the mesh.

Just a guess, seems to me like this distortion was already present in the original, caused by original spherical distortion at the poles which is kinda difficult to compensate for when working in 2D, and your method itself is probably flawless and just copies over the original faulty poles to the equator. If this is the case I can't think of any other solution than manual photoshop retouch magic (might be a problem to sync this across the different map types) Just for curiosity, what's your method of tilting the textures?

Ah right, I forgot to mention, this is a bit obscure but it seems like the parent object's X axis also needs to be aligned with the rotation axis. So it might be enough to create an empty gameobject, align its axis to your CtrlSurface and use it as parent transform.

It's actual simulated aerodynamics, just as if you'd place a wing flat against the air stream. deflectionLiftCoeff is basically the effective area of the aero surface.

Looks awesome, nice work!

transformName = name of the rotating object, the actual flap. Like control surfaces It's rotated around X axis. I think dragCoeff is an obsolete leftover from the old drag system.

The final two values are the in- and out-tangets of the curve, at 0 0 the tangent goes in and out flat horizontally for each key so not exactly a smooth transition. I recommend to check out r4m0n's float curve editor for unity, it shows you a graph for your curve, lets you tweak and copy paste it. (remove empty spaces before keys when you use it) Also, here's a handy guide on configuring air breathing engines including scramjets

It's not just the fov, the point of view is also much higher than in kerbal cockpits. That's mostly because of the eye position of kerbals in contrast to humans, kerbal heads take up like half of their body height, there's at least 5 times more foreahead sitting above their eyes making it impossible to position them high enough under the ceiling without tricks. As a result, you can get the kerbal to barely peek over the ledge of a canopy, let alone see the ground below properly. I think everyone who's made an IVA has bitten their nails on that one at some point.

Oh, nope, not at all, looks like you've not installed the community tech tree, it's supposed to be in a custom node that comes after aerospacetech. I do need to put the default node somewhere else to account for this.

From Community Tech Tree FAQ: Q: Why do I see so many empty nodes! A: Because of the current state of KSP tech tree modding. There are compromises to having empty nodes hidden (little lines leading to nowhere). The decision was made to unhide all the nodes for clarity's sake. I agree its not optimal, I'll see if I can hide them without breaking compatibility to CTT

I've already experimented with ramjet settings, again had to cheat up the thrust compared to information i got on Project Pluto quite a bit to make it work, probably due to higher drag in KSP. It's really challenging to fly, or even boost it up to sufficient speed to get self sustaining thrust, but also much fun smashing through the landscapes a few meters above the ground at mach 3. Gotta be real careful to keep up enough speed at all times, too slow and it couldnt keep up the thrust. Also it overheated quickly, had to turn on cheats etc. Anyway, this is much fun and would fit nicely so I'll definetly make a proper nuke ramjet at some point. Yes thats exactly what I did, added intakeAtmo to the intakes. Didnt use the CRP "IntakeAtm" because according to the google doc it has 0 density, just checked interstellar tho, which is where this comes from and there it has standard intakeAir density, so i guess that's a mistake in the CRP doc. For air turbo rockets, since they should still work in vacuum I think you don't wanna use any additional intake resource at all, might be enough to give it better ISP in atmo, but not sure on exact performance of those in relation to atm density, check if you can find any precise info, if it's more complex than that you could try making it an airbreather without the need for intake resource, but have it use the jet parameters like atmcurve to precisely tune the performance. For mk2 texture, you could always edit one of the stock textures.

Thought about that. I'm concerned that it might overcomplicate things. Might make it as an optional component maybe. You're probably refering to the machLimit = 1.5 parameter in the CFG, it has nothing to do with a speed limit tho, instead it's a limit after which the engine starts to produce extra heat. What does limit the speed are the curves, and the engine actually still produces thrust well within mach 3.5, it's mainly the low TWR that effectively limits it to subsonic. Also note that thrust scales almost linearly with atm density, meaning it'll also give much more thrust on eve. (tho due to high drag there you still won't go supersonic easily) It's based on performance of real experimental machines from the 60's. I found some vague info on performance values which i generously increased till it was just enough to be fun in game. Real stats are quite underwhelming, might be part of the reason they never put these things into actual production. Fits with gameplay balancing tho, an infinite fuel cruise drive is already good enough, especially since you can use it for cruising in places like EVE. Yes. You can also attach things to the base mount of the lightbulb. Helpfull if you decide to use passive radiators. Yay almost supersonic!

What do you expect to happen? As soon as part of your vessel becomes hot, they will draw away the heat cooling them.

New version, new parts!

Firstly, noise and blur is a good idea, and can be especially helpful with lossy formats like .dds in 'dithering' the compression artifacts to make em less apparent. For Mk3 cockpit I basically handpainted it all. I'm still experimenting to find the quickest workflow and have recently used more and more filter combinations instead of handpainting, but basicly I use these steps to create spaceplane textures: 1. First, with a fairly hard low opacity brush draw black along the panel lines to 'soften' them, dont paint too cleanly here, we want it too look dirty. Then lower opacity of the layer till its just a subtle effect. Another easier way to do this would be to copy the panel lines into one layer and apply a blur filter, but that gives IMO too uniform results, I prefer the slight dirtiness of a hard brush and sloppy hand-painting. 2. Then on a new layer paint in white, similar brush, slightly higher opacity (cos of bright grey background). With this paint more in the center of the panels, still somewhat following along the outlines tho, fairly sloppy and randomly because uniformity is the enemy . Adjust this layers opacity till its just a subtle effect. The combination of this white and the black layer is supposed to give a cheap and simplified impression of manufacturing marks and some material wear. Dirt and erosion usually manipulate the look of a material based on convexity of surface features like small grooves between panels, protruding bits and so on. By painting fairly randomly along the panels like I described it, a very basic impression of that can be 'faked' quick and easy without going into any detail about material properties and different kinds of wear. 3. Now its time to add some detail on another layer. With a small bruish, fairly low opacity paint the intersections of the panel lines, imagine the panels arent sharp rectangles, but have very subtle radius on their corners, when joining them together it leaves a tiny dark gap on the corners of the panels. Try to very subtly 'round' the corners of the panels with the brush. It adds some depths to the panels and we're used to seeing this from seams between panel sheets on cars and other machines. 4. Take a fine brush, 1-3px medium or high opacity, white, new layer. This will be the scratch layer. Paint bright scratches on panel edges, fairly randomly. You can experiment with how uniformly you paint those, it can be non-uniform lines along the entire edges or seperate bright specs randomly distributed along the seams. Paint them especially obviously at the corners of each panel, corners usually wear out quickly. Optionally: - paint thin scratches randomly over entire panels, concentrate them especially in areas that are convex on your model. - give underlaying color, underneeth the outline layer randomly different brightness for different panels. E.G. make some panels darker or brighter than others, to imply some have been on the vehicle longer than others, that some have been recently replaced and are less dirty. If you look closely at the spaceshuttles white panels and tiles, its actually a really messy patchwork. Note that its not a very realistic approach tho, it's only supposed to add a basic and toyish material authenticity to the textures. If you want more realism I recommend look closely at some photos of the space shuttle, what color and texture the different materials have, how they wear out, and how worn dirty pieces differ from newly replaced panels and ceramic tiles, what kind of material is exposed if upper layers are damaged and so on, and try to replicate that. Loving that Spaceplane by the way, awesome job so far! If I may nitpick one thing tho, never use true black on large areas of game textures. Leave some room for shadows. So, use a dark grey for the black tiles instead of actual black, something around 10% - 20% brightness. Hope this was of any help, have a good time texturing! edit: landeTLS mentioned it already; your model may benefit from some shadowing along concave areas, e.g. where the fins join the main body, can be a baked ambient occlusion multiplied on top or you can try to hand paint it.

Hah! I'm indeed planning to do a NSWR. Orion not so much.

Indeed, the actives are so effective even that I've ramped up the lightbulb heat production to 2000 for the next version. This requires two large stock active panels for unlimited burn time, seems right to me as a means to give some 'debuff' to an inherently 'overpowered' engine, aswell as an excuse to cover your spaceship in radiators and make it look awesome.

I didnt do it ¯\_(ツ)_/¯