m4ti140

Wow... this is why I shouldn't post after 2 days without sleep... Sorry, disregard that post... yeah, of course there is no AIM-7, there never was. Now that I look at the config files though, it seems that the SARH missiles are actually modeled in BDA, it's just that Paolo never added any missile that used this - there is a separate setting for active guidance range, so you could set that to something like 1 et voila, you have a SARH missile. In the source code on Paolo's git I also found a proper switch for Active/Semi-Active, I'm gonna test that one and see if it works. Anyway, now that I had a close look on the R-27 models in PEW, those are both R-27R with different skins, although the red nose on the ERT is reminiscent of the seeker cover on the R-27T missile, so I suppose that's what the skin author had in mind... anyway, if we look the AIM-120 we have in game now (7500m range, goes pitbull at 6000) we can assume it is a kerbalized (i.e. 1/10 scale) version of AIM-120A/B. So with that in mind an R-27T would have a range of 7000m in game (and IR guidance) and R-27R a range of 8000m (and semi active radar guidance). Anyway, I'm gonna make a MM patch and send it to you to show what I mean. I'm also gonna add the Saphir radar to the Stryker A&A Fishbed intakes now that I'm at it.

One thing on The R-27 because omg my OCD: There are two basic variants of this missile: R-27ER, which is semi-active radar homing (equivalent to BDA stock AIM-7 sparrow but with a longer range and higher airspeed) and R-27ET which is essentially the same missile but with a heat seeker - it is one of the longest range heat seeking missiles (if not THE longest range heat seeking missile) in use today.

Do the Fishbed intakes have BDA radar modules included?

So... I hyperedited myself into the orbit of The Creator... and I explode no matter how far from the surface I put my ship... Is The Creator's orbit below The All's surface?

Just one remark in regards to area rule: what you should try to minimize is not only the rate at which the cross sectional area changes but the total change as well. This is why real life designs have their fuselages "waisted" to maintain roughly constant cross sectional area (such as the F-106 shown in this thread - notice how the fuselage gets narrower as the wings get wider - this way they could make a regular delta wing without additional wave drag). This can be achieved to an extent in KSP as well by careful placement of air intakes and other radially attached parts.

I have the exact same specs and it runs smoothly, go to nVidia control panel, manage 3D settings, select KSP.exe (add it if it's not there) and set the "Preferred graphics processor" option to "High performance nVidia GPU".

Can't you just make two versions of each one? A cheap one without crossfeed and a more expensive one with crossfeed. It wouldn't increase memory footprint of the mod since both parts use the same mesh (unless you wanted to add additional textures for the crossfeed capable one) and would add even more control over fuel flow. In fact that's what I'm about to do myself now.

I think I found a little oversight: The viewing cupola has no exit hatch, but it can still be used by the contract generator in "rescue kerbal" missions. As a result my first crew recovery mission in 1.2 was impossible to finish, as the crew to be rescued was stuck inside their ship.

@blackrack I noticed that in the 1.2 versions of scatterer (including the current one) the "disable scaled space ambient light" option doesn't seem to fix planet rendering through the atmosphere. Below is a screenshot of the Mun in early waxing crescent phase right after sunset: It should be barely visible but it is illuminated on the night side as if there was another star there. Either my install is totally borked, or whatever you did to fix this in earlier versions just unfixed itself

@Pak Ok I've made a FAR config. I didn't manage to make the Rudder work correctly, adding two FAR Control Surface modules causes the part to break and be ignored by FAR. If you made a version split into 2 separate parts (left and right half, could make use of FS mesh switch, to allow placing them by symetry) or just make the fin and each of the control surfaces separate parts, I can make it work though. If someone decides to use this config, they should just place two stock rudders inside each other for split rudder (or just forget about this feature for now). Here is the MM config I made. I didn't remove the rudder entry, as it's essentially a brick anyway with FAR installed. https://www.dropbox.com/s/z3jf4ec1vgzonuj/CormorantFAR.cfg?dl=0

@Pak OK, I'm making a FAR patch right now and I have a few questions: 1. Are all the wing and control surface models positioned correctly in the 3D editor (i.e. with the x axis facing towards the leading edge, y towards the wingtip and z perpendicular to the wing surface)? 2. Do the wing parts use the same model as the stock ones? 3. Does the tail fin have the same dimensions as the stock one? Is the point of origin the same? Question 1 again. If all of these are yes, then I'm gonna upload the patch today.

@gagarinekerman IMO you should incorporate BDArmory for combat if you're planning to add it, and work on orbital AI that BDA doesn't have (or talk to Paolo about adding it to BDA). Having a 4th weapon plugin in KSP is IMO a bit underproductive. Also the starting station doesn't have any resources for some reason - that includes life support when using Kerbalism

@blackrack Does the "draw on top of eve clouds" option apply to 2D clouds or only to volumetric clouds? Because it doesn't make any difference on my install, for some reason. Also he probably means clouds getting red during sunset due to scattered sunlight.

Same here, but Win 10 x64. The default launchsite function is completely broken. I tried setting Runway and Launchpad as favourite in KK.cfg in my save but it didn't help. The filters at the top of the launchsite selection window don't work either. What is the name of your save? I have written mine in Japanese for lulz, it might be related.

Wow, those rotor blades, the twist on them... I gotta test it under FAR

This needs BDArmory based combat. Then I can die in peace

Gonna try it out, though I'm not sure if the FAR configs are working (they were commented out in my download). I might try setting up my own configs, but AFAIK the wing models have to be positioned in a certain way relatively to the origin in the 3D editor (i.e. in the same way the stock ones were), otherwise they won't work no matter how you config them (usually it results in the wing, as calculated by FAR, being completely outside the model, in the opposite direction from the leading edge).

Does the Super 25 work with FAR?

I have a suggestion: add an air conditioning system part that scoops air from the atmosphere to get oxygen, allowing flight in higher atmosphere without oxygen tanks. The 7000m limit makes sense with WWII planes but not with modern airliners, which have systems in place to allow sustained high altitude flight Also did you remove the basic resources from the pods? Or did I install something wrong?

Nexter and Danny won't be happy about this...

@Starwaster Is it possible to activate the RSS config when RSS is not installed (without manually editing everything)? I'm playing with Sigma Dimensions and a more reasonably sized Kerbin, and would like to be able to use realistic heating settings.

Thanks for info. The fix worked. It is also nice to hear about the planned improvement of the syntax. I might wait for the next release then. Regarding the parameter choices: I played around with gravity equations and came up with these two: r = v1/2 * sqrt(3/(G*π*ρ)) - planet radius as a function of its density and orbital velocity. Since with 6h rotation period the boost from rotation is quite significant, I used stock escape velocity as the new orbital velocity (3431 m/s) gASL= v12/r - gravity at see level for that radius Having those I could easily obtain the resize and geeASLmultiplier parameters. As for the atmosphere, I assumed a reasonable (as in: one that will not result in ridiculous aircraft and atmosphere of Evian anoyance level but also reasonable from physical point of view, as a smaller planet would still lose more of its atmosphere by the time it developed intelligent lifeforms) atmoasl parameter and than got the atmosphere height: atmosphere height = pASL*105km/geeASLmultiplier - where pASL is see level pressure, 105 km is the atmosphere cutoff in RSS (which gives reasonable pressure curve for 1 bar see level pressure with 9.807 m/s2 gravitational acceleration) and that divided by geeASLmultiplier which is the ratio between our planet's gravity and 1g. This gives a physically possible pressure curve accounting for the reduced weight of the air. The landscape parameter is also obtained this way - I assumed that the mountains would grow higher by the ratio of gravitational accelerations, which seems to be the case for Earth and Mars.

I purposefully kept it this low, because I'm not planning on moving the Mun (the Earth also used to spin stupidly fast like this). I'm trying to make the Kerbol system physically accurate while keeping it "kerbal". In the end I plan to give every planet unique, new parameters that would make it physically possible while keeping the stock feel and, to an extend, payload fractions. This is why I reduced surface gravity on Kerbin and increased the height of the atmosphere to justify the surface pressure (which I had to reduce anyway, because for 1 bar surface pressure I would have to make it something like 250-300 km high to make it physically accurate). The current density of Kerbin is 4500 kg/m^3, roughly 2/3 between Earth and Mars (I might raise it eventually). I'm aiming at making Kerbin an expy of Noahian Mars, or rather what would Mars look like today if it didn't loose atmosphere and produced inteligent life forms. I want the Kerbin to be an alien planet, not a scaled down Earth. If someone is interested in math behind those parameters I may post them here. I'm gonna try the fix and report back. EDIT: I also have a question: Does your mod change the orbital periods of planets when the mass of the parent object changes due to rescale, according to Kepler's Third Law? I want to make Kerbol physically accurate but at the same time keep the orbital period of the Kerbin AND keep it in the Goldilocks zone.

@Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[0] = 1 } } @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[1] = 1 } } @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[2] = 1 } } @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[3] = 1 } } @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[4] = 1 } } @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[5] = 1 } } @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[6] = 1 } } @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[7] = 1 } } @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[8] = 0 } } @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[9] = 0 } } @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[10] = 1 } } @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[11] = 1 } }