Chaos_Klaus

Ok, that all makes sense. Thank you!

Hi, Hey. I am making a few parts in Blender and I wanted to know about scaling. I read somewhere that 1m in Blender would be 1.25m in KSP. That makes no sense to me. Somewhere else I read that you'd make your part 1m and then scale it by 1.25 in the config. The stock parts don't use scaling though. This is information is conflicting. Normaly, I'd just load up a part andsee how it looks in the game, but I can't find the latest part tools. The ones I found don't seem to work. The part doesn't show up in KSP.

OK. So I found out that the oceanic harvester from Karbonite also doesn't show the buttons ... until you deploy it. Do these harvester types need an animation, or do I need to specify some special mesh that tells KSP where the resource is taken in? I guess the same applies to drills.

Check out the community resource pack. It atempts to somewhat standardize at least the resources that various mods use. It's realy not useful to standardize everything. For example, you need very small quatities of certain resources (antimatter) while you need very large quatities of others (fuel). To think of that in volumetric units is just not useful. Also, you'd not only have to change tanks, but engines aswell and every part that converts, harvests, consumes resources in any way.

Were the part tools released somewhere?

The air intakes got an overhaul. Check [URL="http://forum.kerbalspaceprogram.com/threads/139019-1-05-Intakes-Lets-figure-them-out"]this thread[/URL]. Edit: I'd use a part with moduleResourceConverter to convert intakeAir into another resource, maybe "compressedAir". That should work. Intake air is still there, just hidden.

I don't even think the drag cubes have a volume in the typical sense. I thought they were just abstract objects that had faces with numbers ascociated to them. Lift and drag in water is based on the drag cubes though, as mentioned by Nathan Kell on a stream. But that is for dynamic diving, not static diving by controlling boyancy.

Well, the problem is that other (new) players get the wrong idea about the general perception of the update.

Blow them up. It's the only way.

For me, this levels out at some point.

Hey forum. With the new boyancy in 1.0.5 I started modifying the mk1 liquid fuel tank so it would act as a ballast tank. I am using the community resources pack to specify the "water" resource. I use these part modules: ModuleResourceConverter ... to consume water and convert it to "nothing". This removes water from the tank while the converter is running. ModuleResourceHarvester ... this is supposed to harvest the "water" resource from the ocean and place it in the tank. My problem is with the Harvester. If I set HarvesterType = 2 (which means it will act like an atmospheric harvester) I can happily harvest water from the air. If I set HarvesterType = 1, I can see in the part description that it now says "oceanic". However I get no button when I right click the part and try to use it. It doesn't matter if the part is submerged or not. The button for the converter is still there and works. Why is that so? Are those harvester types not really implemented into stock KSP? Then again stock doesn't use any atmospheric harvesters and they seem to work fine. Am I missing a code line? Here is the part's config file so far. PART { name = Ballast Tank module = Part author = Chaos.Klaus rescaleFactor = 1 node_stack_top = 0.0, 0.9375, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -0.9375, 0.0, 0.0, -1.0, 0.0 node_attach = 0.0, 0.0, -0.625, 0.0, 0.0, 1.0, 1 TechRequired = aviation entryCost = 2600 cost = 550 category = FuelTank subcategory = 0 title = Ballast Tank manufacturer = D8 Submersibles description = A modified fuel tank that can be flodded with water to decrease it's boyancy. To increase boyancy again, repressurize the tank with the compressed air that is stored in a different compartment of the tank. attachRules = 1,1,1,1,0 mass = 0.25 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 10 breakingForce = 50 breakingTorque = 50 maxTemp = 2000 // = 3000 thermalMassModifier = 2.0 fuelCrossFeed = True bulkheadProfiles = size1, srf MODEL { model = Squad/Parts/Structural/mk1Parts/Fuselage } RESOURCE { name = Water amount = 1000 maxAmount = 2000 } MODULE { name = ModuleFuelJettison } MODULE { name = ModuleResourceHarvester HarvesterType = 1 // this specifies the harvester to be of the "oceanic" type. 0 is "surface", 2 is "atmospheric", 1 is "oceanic" Efficiency = 1 ResourceName = Water ConverterName = air vents StartActionName = open vents StopActionName = close vents } MODULE { name = ModuleResourceConverter ConverterName = Compressor StartActionName = start repressurizing StopActionName = stop repressurizing INPUT_RESOURCE { ResourceName = Water Ratio = 10 FlowMode = STAGE_PRIORITY_FLOW } } } EDIT: Mixed it up. Corrected: 1 is oceanic and 2 is atmospheric. Problem still stands.

Yeah, well. I think we need to reconsider the ascent profiles because heat is now a thing on ascent too. I actually like that. Heat actually was a large problem with early rocket design. Didn't want to melt your rocket before reaching it's target, did you? In 1.0.4 we had massive visual flame effects on ascent, without any real heat generation. Now they actually mean something. It's something new to consider and the super shallow profiles are dangerous now. Just because the ascent profiles we got used to in 1.0.4 are dangerous now, doesn't mean the heating system is broken. It'll just take a little bit of thinking, adapting, tinkering and engineering to get everything up and running again.

Boyancy was completely overhauled in 1.0.5. You can use empty fuel tanks as flotation devices now. Water will now produce lift, drag as it should. I guess your intaks just make for a lot of drag.

Wow. That is super cool. Nathan Kell also mentioned that water drag scales somehow. At high speed (eg when your craft enters the water) drag is higher then at low speed. This simulates the highly turbulent flow at low speed. It also makes sure that craft come to a complete stop after a water landing.

Wow. Two pages of answers and nobody actually answers the question without throwing around words like "n-body". Patched conics. The typical simplifications that are made to model gravity are that there is only two bodies interacting: The spacecraft and the parent body it is orbiting. It is also assumed that the mass of the spacecraft is insignificant compared to the mass of the parent body. This simplification works well for a lot of situations and KSP always uses it. Under these circumstances your orbit can have various shapes. It can be a circle, an ellipse, a parabola or a hyperbola. (or even a straight line) All of these shapes are so called conic sections. That means you can get them by cutting a cone in half at different angles. The wikipedia article has a picture that illustrates that. So know we know what conics are. What about patched? In KSP we have different celestial bodies. Each of them has a sphere of influence (SoI). Imagine you are orbiting Kerbin, wandering along an elliptical path. Kerbin is the only body that exerts gravity at this time. Now you enter the Mün's sphere of influence. Suddenly the Mün is the parent body and you are nolonger traveling along an ellipse, but rather a hyperbola. However, at the point where you switched the SoI, the hyperbola and ellipse were perfectly tangent. They were "patched" because your trajectory does not have any kink in it. For KSP gameplay that means: If you unlock patched conics, you are able to see your predicted orbit after an SoI change.

... and it's price tag. The whole point of the shuttle was to have a reusable craft that could use more expensive components then an expendable system. That's at least what they set out to do. So if the Vector engine is going to be late tech tree and very expensive, than that's ok with me.

Ahhhhh ... I can't watch these streams ... why do they have people streaming who don't know what they are doing!?! ​ And then this stupid music .... GRRRRR!

It's not local gravity. It is g0. You always have to use 9.81m/s². It's a little confusing, but this value is just there to do a unit conversion. The rocket equation actually goes: delta v = ve * ln (m0/m1) ve is the exhaust velocity given in m/s. Actually this value could be considered specific impulse. One explaination is that when german and american rocket scientists worked together they had to deal with different unit systems. So if everyone just used g0 in his prefered unit system and got the same value for ISP.

Well, I like when things are technically correct. The turbines are a nice thought, but I think it's a bad idea to add them in terms of flexibility. It works for the typical designs, but in some cases you might pretend that nozzle and turbine are built at an angle. Everything else i think is absolutely great! Also, I actually think it is great that you go ahead and try the thing with the turbines and see how it looks, how people react.

I don't know the exact convention. In KSP everything rotates in the same direction. That is prograde. If you view that from the "top" looking at the northpole, that is anti-clockwise or mathematically positive. But: If you look at it from below, looking at the south pole, it actually is clockwise! That's why we use terms like prograde and retrograde to make it clear. :]

Sorry, but that is just wrong. Gravity is not per se positive. Gravitational force is a vector and it's direction can often displayed with a positive or negative sign. Also, "g" is not "gravity" ... g is acceleration due to gravity and depending on your reference frame/coordinate system this acceleration can be negative. In fact most of the time gravitational force will be considered to be negative, because it is pulling you towards the parent body thereby lowering your distance to the ground. KSP is no exeption. Mass however is never negative ... even with anti matter.

It might be because your landing gear is not flat on the ground. Another reason might be that there is more gear on the front wheel then on the rear wheels. That will cause your problem aswell, because the plane is balancing on the front gear, tipping left to right just a little. This will make you go sideways. But that is all guesswork. We can give you more detailed advice if you post pictures.

As you get higher, the air gets thinner. You have to compensate for that by going faster and thereby pushing more air into your intakes. If you never gain enough speed, you won't get enough thrust.

Only that this would make you go fowards ... In this case it is the damn unupgraded bumpy runway. By the way: you can hit C to activate angle snap. That let's you place things at specific angles, like the wheels. Also: Basically everything about your design is not working. Your wings are too far fowards. Even if you get it in the air, it will want to fly backwards. Turn on the markers for center of mass (CoM) and center of lift (CoL). They are located at the bottom of the parts menu. The blue lift marker needs to be behind the yellow mass marker. That way the craft has a chance of not flipping. Look at real planes and the kind of wings they have. Your plane lacks a vertical stabilizer. That would be a vertical fin at the tail. You also need to control pitch, so you need elevators either at the front or at the tail. Roll control comes from controlsurfaces on the main wings. If you have swept wings, you can combine roll and pitch control with one set of control surfaces. With the gear: make sure the rear gear is behind the center of mass so your tail does not immediately fal to the ground. But don't place it too far back. For lift off, you need to lift the nose and the gear is your pivot point. The farther back the gear the worse the lever is going to be.

Also, Hermes uses aerobraking to capture into an orbit. This is referenced in the book, when they blow the inner hatch of the airlock instead of the outer one. The reason is that they want to keep the outer shape of the craft intact for aerobraking.