kujuman

Finally a good reason to use the poodle! I'm also glad people are working on new SRB effects, they look great. Obviously I'm not developing these, but I think that would require a custom plugin. However, I don't think it would be "particle"-ly difficult to write But it would require having different effects for each body, and some other things.

Assuming near circular orbits... 1) Burn to have the tug lower its Pe to 77km, it doesn't really matter where, but I like to have the Pe be on the dayside, as this is where the rendezvous will occur (I like to burn so that my Pe is just inside the orbit of my target, the goal is that if the paths intersect, the closest approach measurements seem more accurate) 2) Wait. Keep an eye on the closest approach markers every orbit. You should notice eventually the "target" marker will move from being behind your vessel at closest approach to moving in front of it. As soon as this happens, burn retrograde until the markers line up; you will have your rendezvous on the next orbit. To know if this is going to work correctly, the closest approaches should be at or near your Pe. I hope this is clear enough. It's not as fast as other methods, but it will work. Good luck If you just want a fast intercept and have plenty of fuel, you can also try burning radial in and radial out with the maneuver node to fine tune closest approaches, but it does waste fuel.

I was just going to switch from having the effects using the old system to using the new system. My graphics development computer is on the fritz, so any new effects like that probably won't happen for a long time, at least from me. The other news is that the use of the old effects system is what was causing the engines to not work correctly , so I've created a hotfix for that. It does remove the visual and audio effects, but at least the engines will run. http://kerbalspaceprogram.com/ksf-advsrb-hotfix/

I just got back from vacation a few hours ago, so I'll have time in the next few days to start work on it again. In addition to getting it to work with .23 (still have to figure out why it isn't working) I'm still planning on converting over to the new FX system, which might solve some graphical problems, and I have a pretty good idea of what I need to do to make it work.

Try moving the docking locations further apart from one another. What may be happening is that because you're in close proximity to both ports when docking, both are magnetizing. When you successfully dock, the game resaves the craft. If a docking port saves in the magnetizing mode (I don't recall what it is actually called) it gets stuck in that mode and will no longer function. Good luck

This should be possible. When you create the .cfg, just add a second docking module and change the "referenceAttachNode" to match your new docking area. The value you enter on the right half of this line is the last part of the attach nodes defined elsewhere in the .cfg Example, for "node_stack_top = 0.0, 0.2828832, 0.0, 0.0, 1.0, 0.0, 1" to become the docking node, make the "referenceAttachNode = top" For "node_stack_thisismydockingport" set "referenceAttachNode = thisismydockingport" You will encounter the problem that the right click menu will be ambiguous as to which docking port you actually are using.

I think it would be easier to use rockets for the "receiver" aircraft so there is no spool up time, it might give you just the extra control you need.

Okay. I'm away from development over the holidays but expect that I can get something out mid January or so. That update I'm also planning to convert to using the next effects system. I'll also consider additional improvements, but not sure on what.

Pretty neat. I'm not sure what "Average Thrust Position" does, but based on skimming the code, it looks like you simulate the engine cylinder by cylinder? (So force is applied only on ticks during which the cylinder actually fires?) Am I correct in thinking that "Average Thrust Position" is meant to apply a steady force, rather than be bumpy? If so: It might be worthwhile to have the draw of resources to be smoothed out the same way, as it's pretty jumpy at the moment. Assuming that I am correctly understanding how the code functions, I think a "better" solution would be to have the power derived from prop RPM and pitch position with RPM being affected by the engine, so that RPM will increase when a cylinder fires and RPM decreases due to "power loss". I think I understand enough of what the code is doing to realize that this is a potentially major overhaul, but having power be based on RPM allows other options, like residual power after engine failure, providing incentive to windmill a failed engine etc. Enough complaining... I really like that this allows me to have propellers which are not wayyy too powerful, so I can make a Tri-Motor

Can I claim 7 parts and then show proof in about 2 hours? Because I know decoupler spam

Neat. I figured this was doable as a plane, but eh, too much work I'd actually consider this the first success, or at least separate the "planes" vs the "parachute replacers" aka heli-pods

Even if we can't use Kerbals to get out and push, I have an improvement by one part. Calculations show I have enough delta-v by replacing the tank+ant with a sepratron that I can still complete the deorbit, assuming that the figures given by the KSP orbit mechanic are accurate (http://forum.kerbalspaceprogram.com/threads/4374-KSP-Orbit-Mechanic-1-2a-Optimize-Your-Orbits) I might bother to build and fly it, but it's pretty much assuredly going to work. Also waiting on final ruling on getting out to push before I fly again. Low altitude testing shows that the craft is just as stable without the fuel tank and engine on it though. For everyone attempting, a circular 81km orbit to 81km x 40km requires about 35.6 m/s. 81x81 -> 81x55 requires only a 22.3 m/s burn. So for the first orbit a single septratron will work if the rest of the ship is about 1.49t or less, the second your ship can be up to 2.51t

Can a Kerbal get out and push to lower Pe for a min theoretical 3 part lander? Edit: Completed challenge with 9 part ship, no kerbal pushing.

hummmm.... I'd suggest maybe trying a helicopter type (or seedpod) landing, but that might require FAR to actually make it work correctly. I'd also advocate allowing FAR as a separate category, as the "lift" physics in stock are awful. comes back after proof of concept... Ok, done, mostly. 7 parts + 2 more for tiny OMS, probably can strip it down a few more parts. completely stable, so no need to test from reentry. slows to ~9m/s at ground level. still a bit too fast for not breaking the winglets off, but another few test runs should solve it. Update 2: currently testing w 3 adv canards to save on parts. might be able to get down to 2 and use a sepretron from deorbit burn, meaning a total part count of 4

Since they run during the same Unity frame? Try this: setup a bool variable like isStepTwoNextFrame, set to false at initialize, set to True after running step one code set the step 2 sub to check for isStepTwoNextFrame = true, execute code in step two then. At end of this code segment, set isStepTwoNextFrame back to false, to prevent execution during the next frame. As long as you check isStepTwoNextFrame before you change its value it should work correctly. bool isStepTwoNextFrame = False; sub AutoAsparagus() if(isStepTwoNextFrame = True) stepTwo(); if(stepOneBtnPress = True) { step one code isStepTwoNextFrame = True; } end sub private stepTwo() { step two code isStepTwoNextFrame = False; } end

They are quite handy. Even if they are just a simple implementation of each plug having a set burn time and thrust based on fuel, a lot of good can come from them. Of course, Mechjeb and Kerbal Engineering (as I understand them) are not set up to really support variable thrust within a stage during launch. Speaking of SRB plugs, allow me to shamelessly plug my SRB mod, which introduces variable thrust curves and segment plugs into SRBs.

I could envision just having ETs that feed the core and then dropping those ETs a la the Space Shuttle. Of course then you might get issues with ever climbing TWRs which could put your payload in jeopardy. And there might be bigger difficulties in keeping the fuel flow from opposite tanks equal enough to not get too off center mass. And then your engines in the first stage core are going to have to be stronger at launch in order to lift the spare fuel + structure of ETs. So it makes sense to have the extra strap-on tanks have engines. WRT to asparagus being a KSP exploit, it's not that it is an exploit so much as an issue which isn't as punishing as it would be IRL. To repeat people above, the added mass and complexity of the plumbing needed to pull this off is not taken into account when you add a simple fuel line. Of course, the developers could eliminate fuel lines, but this would make Space Shuttle like lifters and small landers with fuel tanks arranged in a way other than a stack (both things which are done in real life) impossible to build in KSP.

Olympic flame in space? Here's my thoughts: 1) The flame device must be self-contained (that is, keep the flame in an enclosed space) 2) The flame device must be capable of a long-ish duration burn (3-7 days) 3) Lighting another torch should of course be feasible on the ground, doing it on EVA would be a nice if possible feature To minimize fuel mass, the flame should be at a barely sustainable rate during transportation and be able to be increased during lighting of another torch. Depending upon the total mass of fuel required for the duration of the burn, a regenerative fuel system might reduce total mass. This also solves the problem of containing exhaust and heat. Consider an enclosed volume with an H2 tank, an O2 tank, a flame "nozzle", fuel flow control equipment, and electrolysis plates. There would also likely need to be additional plumbing, but that is abstracted away for these purposes. The set-up is that the nozzle combines and combusts H2 and 02, generating a flame and water vapor as exhaust. The water vapor would be collected in some manner and be broken down into H2 and O2 by electrolysis. The H2 and O2 would then be recycled into the system which feeds the nozzle. During EVA torch transfer, removal of the "lid" for a sufficiently short duration should minimize fuel loss on the target torch. Alternative torch lighting could be through a conductive wire which is attached at the nozzles and just transfers heat produced by the flame without the need to remove a lid. There you go, a "practical" space-proof Olympic torch.

Maybe like the real LM. Although this isn't a great configuration for kerbal I'd imagine

Okay, I've linked a video on the first post.

Both of these rockets would have lost their nozzles within a few seconds of start up before this mod. 180 ton rocket with SRB producing 2.3 kN of thrust (through 5 fuel segments) flies impeccably 280 ton rocket with SRB producing 4.9 kN of thrust (through 8 fuel segments) flies not so great. Same rocket with 4 2x size segments is working great. Thanks Ferram!

I can understand not transmitting data since the electric charge requirement is pretty high. But if your kerbal is in a seat and the seat has an antenna the data will transmit (great for rovers).

A simple (though not optimal) potential solution would be to re-target the docking port every frame instead of once, assuming that KSP will let you make the switch once.

If what you want is an easy way to interpolate between those points, I'd suggest a FloatCurve variable. It is what engines use for Isp and can be specified in part.cfg files. FloatCurves are a list of points, time and value, but they are really just independent variable and dependent variable. Use FloatCurve.Evaluate(time) to get the dependent variable. I would probably set it up so that G level is "time" and the max duration at that G level is "value"; so that maxDurationAtThisGLevel = FloatCurve.Evaluate(gLevel) Extra info you probably don't need: FloatCurves are a kerbal specific class which is based upon the Unity AnimationCurve, which in turn solves for points along the curve as a bezier curve.

First bug. Apparently I only put one part in the Tech Tree. Whoops! I won't push another release right away, it's easy enough to add tech tree info to the configs until a later release fixes this. suggested lines for the B size are TechRequired = heavierRocketry entryCost = 9000