kujuman

added a link to the first test version .6.1 on the first post. There's still a lot more work before general release. Be advised that unlike (pretty much all) other mods, these parts are somewhat designed to break apart and explode if you push them too hard. All of the boosters have in the pack currently have gimballing, including the stock SRBs if you have ModuleManager. I'm not intending to create a bunch of parts for this plugin, partly because I'm pretty slow and partly because I'm not nearly as good as others on here. I'm not sure I want to get upper stages worked on until I get some way to spit out delta-V for the user, but it shouldn't stop anyone else from doing it.

I'm not sure exactly what you mean by thrust curves (if it's any different than what I'm using currently. I have thrust curves based on time, not % of propellant expended), but I'll explain what currently happens: 1. Two PartModules, Nozzle and Segment. Nozzle is used similarly to a LFE, Segment to a LF tank. 2. Nozzle contains atmo curve for Isp, propellant type, and an ignition T+ counter. Pretty basic really. Segment basically stores an animation curve with keys containing Time, MassFlow (in tonnes per second), and in and out tangents. Each segment's burn profile can be edited in the VAB or SPH. 3. The nozzle part creates a list of connected parts containing a Segment (using the topNode name). This can include itself (for one part boosters) 4. On ignition, and thereafter, the Nozzle queries each Segment in the connected parts list to get MassFlow(t). It then subtracts that resource mass from the Segment and sums the MassFlows from all connected Segments. 5. Nozzle then calculates thrust (constant flow, varying Isp makes thrust vary) and applies it. There is no set limit on the thrust a single nozzle can accommodate, and one can stack booster segments as high as one would like (well, limited to 250 times to help check against an infinite loop). There is tons more info at the release thread, linked in my sig.

I'm planning on creating/releasing Module Manager files for some of the more popular packs, as well as the stock SRBs (except the seprtron and other similar motors. No need to complicate things ). I intend to have a MM file for at least stock and KW (as it's the only pack with SRBs I currently use) done when I release .7 (the first major redo) of the mod. All that needs to be done is take out the ModuleEnginesFX and replace as such. MODULE { name = KSF_SolidBoosterSegment topNode = top endOfStack = true GUIshortName = LargeBooster thrustVariation = .05 } MODULE { name = KSF_SBNozzle atmosphereCurve { key = 0 250 key = 1 230 } thrustTransform = thrustTransform effectGroupName = running_closed resourceName = SolidFuel topNode = top }

Got the graph generator code working again (wasn't too much of a hassle). The scattered blips are a result of the thrust variation feature. The first image has a variation factor of .3, the second is with a variation factor of .05. The blue is the mass of the segment + fuel (scale at left) The cyan is thrust (scale at right) The yellow is extra thrust (thrust - mass * 9.81m/s) I expect a test release this weekend.

Ok. I'd be interested in feedback about the GUI initially, so when I get a little more progress on it I'll get a test copy ready for release.

I wouldn't say that we have "under-powered" SRBs in the game, but rather that we don't have stock SRBs large enough for the kind of heavy lifts people are doing these days. No, it's not a contradiction. Most real world uses of SRBs are as small supplemental rockets to enable a slightly heavier payload or to eek out a bit more performance. For these uses, the stock SRBs are great. And who hasn't stuck LFTs on top of SRBs with crossfeed to the core to get a simple way to increase performance? It's the Space Shuttle SRBs that I think people really think are "proper" SRBs. For these types of launchers, we do need larger SRBs. To put things into perspective, an Orbiter weighs about the same (with a medium payload) as an empty shuttle SRB. In sum, for a simple LKO crew vehicle, existing SRBs can be a significant fraction of the lift vehicle, but are limited to being supplemental boosters on heavy-lift vehicles.

Latest News I've published v0.7 Alpha. There is still a lot more to be done before a general release, but I figured I need some feedback, in particular about the UI. I don't think it's particularly buggy (except the launch clamps), but who knows what mods may make it misbehave. By downloading and using v0.7 Alpha you should understand that it is still a work in progress so you should create backups of your existing save files or start new ones. For general information on how to use the pack visit the general release thread, which I have linked in my signature. The link should be at Advanced Solid Rocket Boosters This version requires blizzy78's Toolbar mod http://forum.kerbalspaceprogram.com/threads/55219 (included) and makes use of ModuleManager by ialdabaoth and sarbian http://forum.kerbalspaceprogram.com/threads/55219 Source linked below Please list any bugs you find, including steps you did to create them. I am still in the process of creating a burn profile for an entire stack at once, but that'll be for later, I wanted to get a release out tonight; you have to set the burn profile for each segment right now. 0.7 Alpha c 2014 All Rights Reserved. ============ This thread will serve to inform/ask the community about the overhaul of the Advanced SRB mod from v.6. The original goals of the AdvSRB mod were: to create stackable SRBs to allow custom burn profiles to give SRBs some respect Since the initial release of AdvSRB, there have been two significant improvements to SRBs: procedural SRBs and tweakables. Even with these, I still feel that there is a gap for improved SRB functionality, which is why I'm continuing development. Major changes from AdvSRB v.6 Burn times are now linked to nozzles, not segments. Added primitive delta-v page to help while building rockets. Primitive heat generation (based on burn rate). Added rocket shake: thrust from AdvSRBs will cause a bit of wobble, but not too much. Added thrust surging: thrust (Isp actually) will cycle from higher to lower to higher fairly rapidly. Make sure you've strutted everything. Github https://github.com/kujuman/ksp-ksf-advSRB

http://www.nasa.gov/multimedia/nasatv/ Was it ever stated why the Chinese station was deorbiting?

If this means something stupidly "impossible" in game... Land an asteroid and get to orbit again. From Eve.

This mission marked the delivery of the second hab module to the station. Landing was notable as being the first landing at the KSC alternate landing site. I need to do some forensic investigations into the time frames and such, as I lost the KSP install I was using for this (I need to reconstruct things I think). This mission was completed before that happened.

Re: the soot from RP-1, is this soot deposited through the burning, or does it only really present itself at engine start/cutoff as unburned propellant is floating around? Secondly, is soot build-up a substantial problem in the "working parts" of the engine or just in the nozzle/outside? With regard to the "too much thrust to land" discussion, the only time I can imagine one would want ~1g of acceleration for a lander is during the last few meters of descent (to allow some margin in your burn) as you need the vehicle to slow down before that, so more than 1g of acceleration, and at least as fuel is concerned, the higher the acceleration the better. In an ideal world, I'd agree, but at least experience with NASA doesn't seem to support this. Many of the "poor" decisions made by NASA are a result of having to deal with many varied stakeholders. With the Space Shuttle, it's widely believed that the military's requirements were at odds with the "civilian" requirements, leading to a less than optimal vehicle. In designing the SLS, NASA was constrained from day 1 by the political decision to use Shuttle derived hardware (presumably to help keep politically connected companies in business). I don't know how other space agencies operate, but I imagine there is still sacrifice of optimal vehicle design to answer political questions. So at least in this regard, SpaceX having better control over their own processes and decisions will give them an edge.

G-VSKY begs to differ about what warrants a scrapping. The point being that with a new airframe, the vehicle is still valuable enough to warrant more costly repairs than an older aircraft.

The new components as in the station modules? I'm making them myself. The idea was to use building this station to identify what parts don't exist and therefore have me develop them. I am using a bunch of mods though, I'll try to post a list with the next mission report.

The problem is in the way the game only has a binary approach to damage. What had happened is I accidentally retracted the gear at about 30 m/s which caused a the port wing to explode, followed by the roll. What would have actually happened is for there to be damage along the bottom of the fuselage, probably extending to mangling the gear and the heat tiles, but little structural damage.

The first steps into the heavens Missions 001, 002, and 003 delivered the bare essentials to create the Kerbal Station 1. Mission 001 delivered the station core into an equatorial 123km x 122km orbit. The core module is equipped with redundant flight computers, batteries, reaction wheels, air and water re-processors (enough for 10 kerbals), tool and spare part storage apparatus, and docking points for additional modules. Mission 002 delivered the station's first solar array. Unfortunately, two of the panel sections were destroyed in the process of attaching the array arm to the core module. The array arm is able to rotate in two dimensions to better collect solar energy. The arm is designed to accommodate additional arm extensions. It also holds additional batteries. Mission 003 delivered the station's first habitable module. It can hold 3 kerbals and was custom designed for this station. A second habitable module of the same design is being delivered on mission 004. Mission status: Day 2 0 kerbals on orbit 3 kerbal days (kD) of provisions at station Orbiter status: Adamant-Slated for mission 004 Dauntless-Landed at KSC on day 2. Will be available on day 9. Resolute-Landed at KSC on day 0. Suffered minor damage. Will be available on day 27. Tenacious-Landed at KSC on day 1. Will be available on day 8.

After years of working on developing a standard orbital shuttle, the Kerbal Space Administration's Specialty Procurement, Analysis, & Management division (SPAM) finally reached a viable technological breakthrough: hire an outside contractor. Although this contractor had some unforeseen delays, the [thread=68429]delivered product[/thread] far exceeded the expectations of SPAM. After a few proving flights of the KSO, it was accepted into the KSA fleet of launch vehicles. There only existed one hurdle to using the KSO to its full potential: no missions had been developed for it. It was to fill this need that SPAM hastily put together a program to make use of the KSO. SPAM's plan was to use the (somewhat cramped) cargo bay of the KSO to deliver modules to construct a space station in LKO... KSASPAM had set these timelines and objectives for their project: ***HARDWARE*** 1. Four KSO vehicles were available a) Adamant Dauntless c) Resolute d) Tenacious 2. Payload should be developed using existing inventory of KSA if possible a) new parts may be developed so long as they fill a niche SPAM testing revealed that existing parts did not like being crushed, so merely "rescaling" a part was out of the question* 3. The station should be able to be modified according to new mission requirements ***OPERATIONS*** 1. Station a) The station should maintain a minimum of 30 standard days** of provisions once crewed The station should eventually maintain On-Orbit Contingency Vehicles (OOCV) for crew aboard c) The station should be designed to accommodate interplanetary travel 2. KSO a) Refurbishment i. Flights which land at KSC can be refurbished and flight ready in 7 days ii. Flights which land intact can be refurbished and flight ready in 20 days iii. Flights which suffer small amounts of damage require an additional 20 days of repair iv. Flights which suffer significant damage require an additional 60 days of repair Crew i. The shuttle requires 2 crew members aboard to conduct launch and reentry ii. The shuttle may use computers to maneuver it in orbit iii. There is no requirement that a full compliment of crew onboard *Exceptions exist for specialty parts, which would have to be custom ordered anyway (such as robotic arms) **A standard day has a length of 24 hours, and is used to calculate provision requirements (also known as a metabolic day after the metabolic patterns of kerbals). A regular day has a length of 6 hours.

I guess it's time to update progress. I wanted to make sure that the plugin could handle one part (traditional) SRBs, and to provide a module manager file for some of the more popular part packs, but it just hadn't been working until earlier today. So I'm still making progress, but it's slow going. At this rate an update may be released around .24, or within a few weeks.

I'm using them quite effectively on my station (well, the Canadarm anyway). It might be that I'm also using ferram's Kerbal Joint Reinforcement mod. One thing to keep in mind is that if you're trying to move a 5t object and your station only has a mass of 25t, you're going to have a bad time. Another tip is to have a command pod/probe/docking port which is rigidly connected to the arm be your "control from here" pod, otherwise wobble induced by the arm will be intensified by the SAS.

I'm running the TAC life support on my save, and resupplying my station became really easy with this module I made to fit in the cargo bay. Launch to rendezvous is completed from the cockpit (with the exception of timing the launch to be in the same plane as the station and enabling fuel flow on the shuttle after ET sep) with the station in a 91 x 92 km orbit with an inclination of 15 deg. The module holds 640 kerbal-days worth of supplies. This shuttle is awesome.

Meh. I think this is an artifact from the different size connection nodes, which are 0, 1, 2 etc. I'm pretty sure that if you used a plugin to measure from one side of a size1 tank to another, it would return the result of 1.25m. And finally, 1.25m and 2.5m sounds nicer, since then the kerbals have just that much extra room in their capsules

I'm down with leaving flags mostly how they are currently handled. I think the better improvement is to keep the filters one selects in the tracking station persistent. Although the one change I'd make is to optionally set flags to not be cycled to by pressing [ and ] . They just get in the way at a crowded Mun base.

Not at all! I had in mind to use module manager to get the advanced SRBs working with SRBs from KW Rocketry eventually (those models are way better than I could ever do), but I just haven't gotten around to it. Feel free to experiment with new combinations, just be sure that if you release any of them to the public to be aware of the licensing restrictions. I'd like to hear of any progress/success you might have. Also feel free to PM me if there are any questions you have about how the plugin works.

Thanks. This works fine using old style stock effects (the Particle Prefabs); specifically I tested "fx_smokeTrail_aeroSpike", which was referenced in the RAPIER config. I'm testing loading the MODEL_MULTI_PARTICLE by hand.

With regard to having dust kicked up during landing, rover dust trails, and smoke from the Launchpad, etc, testing I've done shows that these should work, but they look like they can't be added to preexisting parts. Parts need to have a free Transform in the model, which needs to be added in Unity (there might be some way to add it in code properly, but I haven't found it yet.)

I'd be willing to hop on, at least to get you started (there are better plugin writers than myself). I think the launch pad side exhausts and the dust would be possible and within my abilities, I don't know about the rest. In any case, I'm working on a proof of concept dust kickup plugin at the moment.