kujuman

WRT interstage fairings, I am all in favor of seeing if they can be implemented. These are just a few ideas which might be helpful (I figure you've considered most of them though) 1. They need to work if building up the rocket as well as building down the rocket 2. They would ideally auto strut the non-parented side, such that the fairing itself will contribute to a stable ship 3. They might ideally come in variable symmetry, or at least a 4x and 2x

Even if a Mars project is "affordable", that doesn't mean it is prudent. Budgeting is about picking which "affordable" projects you fund and which you don't. (Giving a single person in the US $100billion one time is affordable, but it isn't prudent). There are 3 main issues I see with the American people being ready to accept a trip to Mars 1. No call to action. The public does not believe we're in any sort of space race, so why go to Mars now when we'll be able to do it better in 10 years? 2. The development time frames are waaayyyy too long. You might have public support for a project for the first several years, but then people will grow tired of it, especially if there are no visible products. I suspect this is one of the reasons proposals are to go visit the moon first, to give the public a "we're doing something" milestone. But why waste time going to the moon first? Mission creep will kill a Mars mission. 3. The US has been in a really bad slump for the last 6 years with no end in sight (there've been some really poor policy choices against growth). The public probably isn't willing to support such a project if everyday living is difficult (a national cause might of course be very different, and could bring people together, but you must get over the initial reaction people have). Lastly, I know a lot of us here would really like to send people to Mars, and even just flags and footsteps would be awesome. But the next question is "Now what?" I bet most of us have had that feeling in stock KSP as well. We like going places, but unless you use mods like kethane or mapping, it's kinda pointless to keep sending missions places. So unless we find out something to do on Mars, there's no real point going more than once, is there? (good, real, science counts as doing something)

It doesn't increase the Isp directly, that would be a result of a higher pressure. Even so, I figure Kerbal engineers are smart enough to make modifications to a nozzle design to prevent such accidents from occurring. (Otherwise, there would have to be several nozzle types and would make building rockets just that much harder.) I guess it would be pretty simple programically to implement, but the gameplay would be pretty unchanged (aside from chance of explosion or under performing nozzle...neither of which I'd like in a game) and building rockets would be more complex. Ok, I'll remove MJ in the next major release (this is why I should not post hotfixes after enjoying adult beverages...I forget things) Well, at this point, I don't even know if the separation gimbal works correctly yet. It sometimes did in testing, but yeahhhhhhh... I'm going to be rewriting it for the next release for sure, maybe make it a standalone PartModule. And I am aware the booster tend to go super fast...rebalancing this is as easy as reducing the massFlow keys in the .cfg of the nose, but it's a lowish priority balance. I'll check out Mission Controller to see what's up with fuel pricing...I do want to change the way fuel is handled, and so maybe next major version I will.

get it noooowoowoooowwww http://kerbalspaceprogram.com/ksf-advsrb-hotfix/

Like these? At this point the effects become very taxing on system resources, so I put a max cap on the effects.

Hm, Ok thanks for the report Update: Ok, I have recreated the no thrust issue (which is also the cause as the no booster above it fuel use and the low mass flow reading), I think I know which line is causing it, but I don't know why it is. Update 2: I've found a workaround. It actually is a tighter piece of coding now, something I had planned to do when cleaning up the code near the finish. So i'm just going to go ahead and tidy up the code a bit more before publishing a hotfix That's planned for later in the release. I want to make sure I have the code in place before making too many models (in case I need to make changes) Could you please provide a .craft or a picture of the craft? Also, do you have any other mods installed? FAR is currently not working with this.

After getting to a good point with my Advanced Solid Rocket Boosters, I figured I should try out a shuttle. First flight was very balanced until SRB seperation For the shuttle to have enough TWR after SRB sep, I needed to burn until off about 3200 units of fuel from the ET before I launched. Awesome! Don't believe the fuel gauge, it includes the fuel in the shuttle (without oxidizer). Main tank had ~200 units of fuel total left. So in only about 40 minutes I designed a successful orbiter + stack, and never had any problems in balance until the SRBs burned out 100 seconds into the flight.

Added fx which scale with the mass flow. Added some action group items. One action group item is "Abort", which basically lowers your Isp a lot to simulate the nozzle blowing out. I've capped the fx though so that this doesn't happen. Don't worry, this probably can't happen

Update v.2 Features a new booster segment, textures, and the beginnings of analytical tools. Get it now on Spaceport!

Has that ever been stated anywhere or is it just taking the external dimensions of a fuel tank and the tank capacity and working backwards? Because fuel tank walls The way I'm calculating thrust right now is F = massflow * 9.81 * currentIsp I was thinking that nozzles would have a "native" Isp for some baseline pressure fuel and different fuels would have pressures at some ratio above or below the baseline. But upon consideration, that seems too involved and unless too much pressure would blow the rocket (or some other balancing mechanic, like funding in career mode), I don't see a case where I would pick a lower Isp fuel. Long story short, setting Isp in the nozzle config will be a level removed from figuring out nozzle geometry and pressure. Thanks for the tip on game database, I haven't thought to venture into exploring what I can see using it. Heh, I know the feeling. I'm working to try to get v.2 out today (hopefully before .21 comes out, because I'm not going to work on the mod for about a day after release) but for some reason my plugins aren't loading right now, so I can't test my fuel mass flow analyzer. Anyway, game d/l'd, so time to get back to work.

Just use buoyancy. So apparent mass = weight - weight of displaced fluid. Setting apparent mass = 0 (neutral buoyancy) means weight of displaced fluid will equal the weight of the total airship. If the density of air at 40km = 1g/L a 10L balloon will lift 10g to 40km. (total mass of the balloon is 10g, not the payload) If the density of your lifting gas at 40km is .7g/L then you displace 10g of air with a 10L balloon but you also are lifting 7g of lifting gas, leaving you with a payload volume of 3g

hm, I thought I had updated the post... Anyway I have solved the issue. It was due to a do loop getting stuck because part.attachnode.attachedPartId.ToString() returns the attached part and id number just fine when loading a new vessel. (It will return something like "CommandPod1-2_49295810560054") However, this returns "" when the game creates a vessel from a save file. Which is...weird. Anyway, I instead used part.attachnode.attachedPart != null (which returns the attached part as a Part class) which does work after loading from a save. So all in all, always remember to put some failsafe way out of loops and part.attachnode.attachPartId.ToString() should not be used on flight vessels, but would probably work ok for editor type stuff

Just for clarity, in this post by "volume" units I mean the fuel units. I understand and appreciate where you're coming from. To be honest, when I had started the coding of the part modules, I made the density of the rocket fuel to be similar to the regular solid rocket fuel. But the thrust calculations are based on mass flow rate and the way resources are requested is based on volume units. So I was having a hard time developing the modules while also not screwing up the math (mostly decimal places). Further, I had not been able to find a way to get the density of a type of fuel programmatically, so I was making a mess of things with incorrect unit conversions. I think at this point for most users "units of fuel" is arbitrary in any case. Like when they changed the RCS a few updates ago there was a bit of an issue, but people have adapted to understanding intuitively what one RCS tanks of each size will do in space. For this mod, as there is yet no mechjeb integration; if people want to determine delta-V by hand, knowing that this segment contains 3.75t of fuel is simpler (by a bit at least) than having to subtract loaded mass from dry mass to get the fuel level (though I admit that this is not a huge burden). So the only real reason to use a volume convention is to make parts scaled similarly to each other. But I feel that people who are making mod parts will be okay if I include some "suggested volume per mass" in that documentation. At some point between v.2 and v.3 I will probably consider the issue more thoroughly, but at least until I get the burn time calculators running, I will leave things as they are so that they are more intuitive to develop. Thanks for the density of APCP btw, as that's basically what I got my Isp range from, so if I do decide to convert the densities I'm likely to use it. At this point, I'm even debating having different fuels with different Isp, but that might just add too much complication as compared with different nozzles. All things equal, no. When rocket fuel burns you can think of the mass of the fuel burned as creating a certain level of thrust in a certain time. So for a certain amount of propellant, the faster you burn fuel, the higher the thrust generated at the expense of burn time. A simple way to think of how fast something burns is based on its surface area being burned. Liquid engines you can think of as having a fixed surface area for combustion, so no matter how much fuel you have, the rate of burning is the same, and therefore thrust doesn't change. Solid rockets burn fuel all the way to the top of the stage through a hollow channel in the segments. This means that adding another segment and making a booster taller increases the surface area being burned, creating a higher thrust level, but because the segment you've added also contains more fuel, the burn time is unaffected.

The "liter" convention isn't set in stone or anything, so I just made the density easy to use. Fo' instance... The included SRB segments have 3.75 units of propellant and weigh .25 tons empty for a total mass of 4 tons. The stock small SRB has 433 units of propellant and weigh .5 tons empty, for a total mass of 3.7475 tons. Hopefully this will make figuring out the mass of the boosters simpler as they almost certainly don't work with MechJeb or anything.

0.7 Alpha is released. These advanced solid rocket boosters (AdvSRB) are the pinnacle of modern engineering. Developed after accusations that current SRB designs were nothing more than “trash cans full ‘o boomâ€Â, the AdvSRB boasts many exciting features: -Stackable: Each AdvSRB Segment added to a booster stack increases the thrust of the entire stack. -Varying Thrust: By carefully shaping the propellant (or modifying the MassFlow floatcurve in the .cfg) you can change how quickly the propellant burns, exchanging burn time for thrust. Have thrust constant, reduce over time, or even decrease before increasing again! -Gimbaled Nozzles: Nozzles are gimbaled to help steer vessels. While they have no thrust of their own, their Isp helps determine the thrust for the entire stack. -Fixed Burn Times: If mass flow is fixed at a set time, then how does Isp work? Thrust! Low Isp results in lower thrust than a higher Isp, just like on the fictional world of Earth! (May be out of date) How to use: Attach as many AdvSRB segments as you would like one on top of the other. The height of the stack determines its thrust. At the bottom of the stack add an AdvSRB Nozzle. Without a nozzle, the segments are useless. The nozzle will only activate through the regular staging process, and its icon is the standard SRB icon. Note that there is no fuel gauge drawn in the staging stack, so you should use the right click “T+†indicator on the nozzles to determine how long they have been burning. When in the editor, hover your mouse over a nozzle and press the "Home" key to bring up the editor GUI (hover and "End" closes it). This advanced GUI will enable you to customize burn profiles in game, without having to have different parts each with a specific burn profile! Symmetry is not yet supported though, so it's best to make one booster stack to your liking and then engage symmetry. Copy and Paste functionality are per nozzle. While the nozzles provide the GUI, the burn profiles are saved per segment. Version v.1 July 1, 2013 Initial Release Version v.2 July 3, 2013 Update Version v.3 July 4, 2013 Update Version v.4 July 20, 2013 Update Version v.5 September 13, 2013 Update Version v.6 October 26, 2013 Update Version v0.7 Alpha December 4, 2014 Initial Limited Release Features to be implemented before final release: -Full effects: heat -Engine damage -How-To guide, on how to develop your own models and parts (specific requirements) Features to be implemented if possible: -Enabling thrust/delta-V to be read by MechJeb and other popular addons Current known/suspected issues: -The game may allow you to save while the AdvSRBs are thrusting; I have not tested resuming this. -May not work correctly with mods installed (I think MechJeb and Kerbal Engineer will not evaluate the AdvSRBs correctly) -Segments MUST be placed the correct side up- a possible loop failure may cause the engine to not thrust, MassFlow to be excessive, or both. -B size boosters are very wobbly and prone to breaking apart. Please stru As the pack is still in development, do not rely upon parts to remain available or function the same way after an update. I suspect that you will only use them for launch vehicles, so hopefully this will not be too much of an issue. 0.7 Alpha is c 2014, All Rights Reserved. 0.6.1 and earlier versions of this work are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. It was previously released under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License, which was reverted as per the following: "If after 45 days there are no updates to this mod, then the license shall revert to a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. The 45 day period will reset with each update. For these purposes, updates will be noted by version number increases, i.e., v.1 to v.2 This is to give me exclusive right to updating the software while still allowing the community to take over if I let it languish." Video tutorial for v.6 Download <s>Now</s> in the near Future! Development Thread http://forum.kerbalspaceprogram.com/threads/77563-Advanced-SRB-dev-Major-rework-from-v-6?p=1112630#post1112630 .23 HOTFIX information http://forum.kerbalspaceprogram.com/threads/38597-Part-Advanced-SRB-WIP-v-6-by-Kerbal-Science-Foundation-22?p=900643&viewfull=1#post900643

Hello, I'm writing a new part module which is an advanced SRB. For new ships (straight from the VAB or using the select ship box on the Launchpad) the plugin works as expected. However, after restarting a flight or loading a flight already on the Launchpad, activating the part causes the game to freeze. 1. I suspect the problem is with the plugin working after loading from the persistence file. 2. Output log shows that the program is running through the end of the OnActivate() sub, but stops somewhere before getting into OnFixedUpdate() (it may actually enter the code block, but a print() message as the first line of the OnFixedUpdate() sub does not show up in the log 3. As long as I don't activate the custom part module, the game runs fine. I don't have internet at my development computer until tomorrow, but I may be able to post the code up sometime tonight. Thanks for your help.

"No mod makers have taken advantage of it yet that I have seen but nothing is stopping them" Do a search for KSF on spaceport. There are actually pretty bice looking plaques in there which are not pictured. id post a link but im on my phone.

ok, I just loaded up the save file. The ASAS on the station was enabled, which was causing the small shakes and random rotation after a while. the docking port wouldn't work for me (haven't explored why) but if you turn the hab around, it will dock with the other docking port. The second time I loaded up the save (to try again) I bumped the station which then caused it to go very shaky. And I really don't think it's a strutting issue, the solar panel sections were rotating violently along the long axis. but try turning off the asas on the station, turning the hab around and then docking gently. HOW TO FIX THE DOCKING PORT 1. Go into the persistent.sfs file 2. Search for a line which says "state = Acquire" 3. Change to "state = Ready" 4. Load up the game and dock with the port nearby.

Depends on the size and number of tanks. With the tall and narrow tanks, I usually do not strut them vertically, even if they are 6 tanks high. Orange tanks: I always strut between them. The non orange rockomax tanks I might strut if they are 4 tanks tall, otherwise I only strut them if testing reveals they need it. An effective solution is to skip over tanks when placing struts. Using the small cubic struts to extend outwards from and tank and then strutting the cubic struts works very well, so tank #1 is strutted directly to tank #4, with #2 and #3 in the middle unstrutted. Building a taller rocket usually is better in terms of manuverability (the distance by which the thrust vector passes by the center of mass determines tourque) if you're using gimbaled engines, but can lead to wobbling. So tall but not too tall works. This is the correct behavior. For now there can only be one "parent" for a part, so the tanks are being joined to the tank below or above, not the decoupler. You can attach a side tank with only one decoupler, and then use the struts to connect the tanks further up the stack. Otherwise you can make each lateral tank parented to different decouplers, leaving a gap between tanks which would need fuel lines to connect. Yes, struts only work within one vessel; when you decouple, the spent stage becomes another vessel so the struts automatically disengage. Strutting between stages is very common and very effective, and there will be no harm doing so. Other tip. When strutting multiple stages, I typically start at the bottom stage and strut up, so that when the stage disconnects the mass of the strut falls away with the stage (because it is parented to the bottom stage). This might not actually do anything in game because struts may have some special physical properties, but it is something I do anyway.

Quick update, I've done some testing and it is indeed possible to put markings on the object that shows up in the VAB. I'm currently working on making the parts nicer looking, such as adding a bit of depth and removing the shadow as was suggested in a Space Port comment.

To answer the question, yes it is quite possible to land back at the runway fairly reliably. Key things to keep in mind: Test your plane in the atmosphere with no fuel on board to ensure that it is stable even with less fuel (as fuel drains, the center of mass will shift, if it goes too far back your plane will tumble and if it is too far forward you will be a dart) Ensure that your orbit will take you over the KSC. I think most players have stations in an equitorial orbit, so this is not a problem for them. The next step is to save once you're ready to leave your station. For a roughly circular orbit, if you lower your periapsis to the same level each time and set it the same distance from the KSC, you will land in a consistant way. So try it a few times. If you land short either raise the periapsis or do the deorbit burn later. As a starting point, if you have your periapsis around 24km and about over the middle of the ocean to the east, you should have a close landing. Then just tweak until it's right by using the quicksave and you'll have similar results with each subsequant flight.

Kerbal Sciene Foundation releases Flag Decals! You can use these to decorate your ship, plane, rocket, rover, etc! UPDATE 29MAY2013 Now includes two new flag plaques, one flag (the Apollo plaque image) and one mounting base! Old flags have been unchanged so as not to disrupt saves, but if they have not been used yet I suggest you remove them. Though they appear white in the VAB/SPH, through the magic of television they become real factual flags on the launchpad. Download on Space Port! http://kerbalspaceprogram.com/ksf-flag-decals/