saabstory88

I messed with this for about an hour. I think that you really have to change the tech tree. With the stock contracts system, you also end up getting lots of impossible tasks, and suddenly your gateway to new contracts via Minmus is gone. Don't get me wrong, I love ironman challenges, but I think RSS 0.24 is a bit much, mostly because contracts have become such a necessary part of the game. Sorry Rockomax, I can't test you part in an 80km "orbit", because, well, it isn't one. I'm sure it will only be a matter of time before someone comes up with a brilliant plugin to make RSS a joy with the new system. Until then, RSS for sandbox, normal system for career, at least for me.

Is the GUI implemented in the latest version? The part loads properly (0.24 win), and I can place it with no ill effects. I do not have a button which allows me to access a GUI. Do I have to to create .cfg files for every size I want, or is something just keeping the GUI button from being shown? Also, when I downloaded the package, there is a Kotysoft folder which contains folder structure, but is empty, maybe it shouldn't be? Here is the full log: https://drive.google.com/file/d/0B51D0goiPm7JUG9RNTNLQlFrNkE/edit?usp=sharing Here are lines that seem relevant: [ERR 19:22:57.321] AssemblyLoader: Exception loading 'NRAP': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'IPartCostModifier' from assembly 'Assembly-CSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type '<>c__DisplayClassf' from assembly 'NRAP, Version=1.5.5324.40306, Culture=neutral, PublicKeyToken=null'. Here is the Mod list: 000_Toolbar AIES_Aerospace DRE FASA GameData JSI KER KWRocketry MagicSmokeIndustries NEAR NearFutureConstruction NearFutureSpacecraft NovaPunchEngines NRAP Procedural Parts+Fairings SCANsatRPM TAC

Thank you very much. Also just remembered Nova Punch. Is there no AEIS 0.24 version? It's fine if there isn't, I just want to make sure of this before I start reconfiguring them.

Hello all, I run with a pretty heavily modded game. I have been trying to find better engines for the purposes of clustering. Specifically, I am looking engines that are realistic in that they have no predefined coupling ring at the bottom of the tank, and just have the structure and turbopumps to attach to the tanks. I already have FASA, KW, and Near Future propulsion. It is ok if these are older packs, I can adjust configs for .24 of my own. I have seen the soviet engine pack, but I am concerned about he RAM footprint. As an extension of this, is there a mod which strips the tank connectors from stock engines (if appropriate)? I could do this myself, but I guess .mu files can not be reverse engineered? TL;DR, looking for realistic form factor engines, I can upgrade them per part for .24 if necessary, and I already have FASA. Thanks!

Seeing Kenobi McCormick's avatar makes me think about having cheap rocket challenges. Those could be fun (and funny) missions.

Thanks so much! It works great now, no active texture management needed. And I have to say, I really enjoy your work. Obviously, my realism overhaul install would be worthless without it. I felt like an Agena based 1.25m orbital parts tester was in order for 0.24 though. My computer is pretty much maxed out for a laptop, but I that old high clock speed machine with 8gb ram and a firepro will really step up the experience.

So about a week before 0.24 was released, I wiped my Windows 7 partition on my computer to be able to install OSX 10.10 beta. So no 64bit for me until I finish restoring my 6 year old dual core 3.2ghz windows box to be a DEDICATED KSP machine. In any case, I tried the previous 0.235 compatible release, and it hit the memory limit really quickly. I never even got a rocket to the launch pad, it always crashed after the third or fourth part in the VAB. The only other mod I have running on my 0.24 install is KER. If I run with the game at half textures, and use the 0.24 version of FASA, might I be ok? Or do I need to enable an additional texture compression mod? I see Texture Replacer is listed in the updated mods list, but is it appropriate for this application?

I wonder why they wouldn't just issue weeklies like Minecraft did during the end of its alpha/beta and beyond. People who can wait for things would be satisfied, they could get feedback about every weeks progress, and hopefully make their development process easier. I always liked that about that process, if you were impatient, they'd let you play with the broken, buggy, build, and the Devs got great bug feedback week by week. It also meant that major versions were far more stable.

I am trying to trust that the ram jet design handbooks I have been reading are correct in their math. You do actually divert a large amount of air in real sub, and supersonic ram jet designs, around the engine, setting up the geometry such that only the right amount of air is allowed into the intake. It's all a matter of forward inlet area, versus rear of inlet frontal area. That ratio determined your flow into the engine. I am working on some data sets to try to determine how much efficiency can actually be gained on top of a standard hybrid rocket. I'm working on the assumption of a 90 second total boost time, with a desired final velocity of 1200 m/s, and an altitude of 40-50km. I picked this number, because it's pretty much the starting point you would need to take a reasonably sized (m < 600kg) hybrid rocket body second stage close to orbital speeds. Speaking to a second stage, the fractional mass ratio would allow you to maybe, MAYBE, put a cube sat on top of this thing.

Your completely right about the aerospike approach, which is why I would not choose to go that direction. A traditional rocket bell would function much better for this application, as altitude increases, the exhaust plume tends to expand a predictable rate. What I think that I am not communicating properly, is that with a properly shaped engine bell, the supersonic boundary between the surface of the exhaust plume, and the incoming air is of a sufficient pressure that the plume is essentially a solid mass in comparison. Air compressed in this manner does not actually mix wit the exhaust plume until it is clear of the shroud, so it's no really an afterburner, which injects fuel directly into an exhaust plume. So the design goal should be geometry that allows us to treat to rocket component and the ramjet component as two SEPARATE systems. Our shroud length should be less than the distance of the coherence of the exhausts supersonic boundary layer. This will ensure that the exhaust does NOT MIX until it is clear of the engine. For the following example, imagine a system where you have a conventional rocket, with several variable geometry ram jets around its axis. Let us take a design that call for a final thrust of T(f). The rocket portion should be designed to produce up to .75 * T(f), the subsonic ramjet configuration shall be designed to reach at minimum .5 T(f), and in supersonic configuration, at minimum, .25 * T(f). The rocket shall be throttled at liftoff to maximum power, and remain there until enough velocity is achieved to ignite the subsonic ram jet configuration. The main engine is throttled such that it is producing equal thrust to the ramjet(s). Thus during this phase, the Isp of the system can be given by using the ratio of thrust that each engine is contributing to the system, to find the weighted average. So for our example, a rocket with several radial ram jets, we can take an average ram jet Isp of 2000s, and average that with a typical rocket Isp of 250s, for a total system Isp of 1125s during subsonic flight. When the rocket achieves supersonic flight, the ram jet geometry is changed such that the engine can operate at those speeds. Because this requires changing the ratio of inlet area, to diffuser area from greater than 1, to less than one, this generally causes the specific impulse of the supersonic mode to be lower in a variable geometry design. However, at this point the Isp of the rocket has usually increased. So when we take, for example, a slice of the Isp average at high altitude and speed, the ram jet would be operating at say, 1500s and the rocket at 300s. However, in our example, the trust ratio has changed in favor of the rocket. So recalculating, weighting the average by proportion of contributed thrust, we still arrive at an Isp of 600s for supersonic operation. But we don't simply have to strap variable geometry ram jets to a rocket to gain this kind of efficiency. What I think you fail to understand, is that air passing near a stream of supersonic exhaust gas on the same vector can not enter the stream. It might as well be a solid. It will eventually lose pressure and velocity and allow air to mix, however this does not occur close to the engine. Thus if we design a shroud that is less than the distance before the air starts mixing with the exhaust, we essentially have a variable size SOLID at our disposal. This is why the ram jet component and the rocket component can be treated just like our previous example of literally having to different kinds of engines on the same vehicle. See the following diagram below, keeping this in mind. Also keep in mind that as altitude increases, the exhaust from any given engine bell geometry tends to increase in diameter. We use this effect to allow for a change in intake area, to combustion area, inside the ram jet shroud.

I'm curious about how you calculate the total effect on ∆V when using this system, especially when using additional fuel. I know I can find literature about how to calculate the various cross sectional geometries of ram jets, both sub- and super-sonic. Do i treat the rocket and the additional jet thrust as two separate systems due to the boundary layer? Assuming the main engine burn time is less than the time the rocket will take to reach peak operating altitude and air speed, it seems pretty easy to calculate the amount of extra fuel required. I'm really talking about something beyond using passing air as extra reaction mass for the system, and actually burning additional fuel, stored and injected separately. If I could determine the Isp and thrust of each system, could I simply factor those proportionately to get a total system Isp assuming uniform burn time between the two? The term, Air-Augmented rocket, appears to only refer to the concept of using thermal energy from the exhaust plume to heat captured air, not actually burning additional fuel. The non mechanical designs I have seem thus far also only increase efficiency of the system at subsonic velocities. I am trying to ascertain whether the exhaust boundary could be controlled to the point where it could allow additional fuel to be burned at supersonic velocities as well, without the use of any actuated mechanical means.

Hello all, Seeing as there are an abundance of intelligent people who are involved with KSP, and in turn, have a fascination or career involving rocket science and aerospace, I was hoping to have some assistance with a theoretical design. I have been researching the topic of Ramrockets, and I had an idea for something resembling a cross between a NASA style RBCC as described here: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19970017381.pdf and a more mundane ducted rocket. From what I have been able to research about ram jet physics, the greatest concern at supersonic velocities is the variable geometries of the diffuser assembly required to achieve a subsonic fuel air mixture. This got me thinking about whether the boundary layer generated by traditional rocket exhaust inside of a ducted nozzle could be varied, by changing thrust, to create ideal conditions for additional combustion. If additional fuel injectors could be added to the duct assembly, could additional fuel be burnt at higher efficiency, being mixed with the incoming air? In the NASA case study, and related designs I have seen, the rocket motor has always been positioned in the aft section of the combustion chamber, where the flame trap is usually located, and variable intake geometry, via active motorized means, has been used. By relieving mechanical actuators and flaps from the responsibility of changing the geometry, could significant weight and complexity be saved? I have been working up to putting some small scale hybrid rocket motors into practice, and understand most of the principles involved, but the fluid dynamics required to actually design a ramjet shroud, are a little beyond me at the moment. I would love to eventually upgrade a motor to incorporate such a system, but then again, I do not have a supersonic wind tunnel to test it. I have not yet delved into the realm of trying to configure any of the CAD software I have available at work for this task, but even if anyone has any direction on the software portion, that would be greatly appreciated. Here is a rough diagram of what I would envision this system to look like. This image is only meant to demonstrate the idea, and is obviously not based on any calculated geometry. Thanks!

Hello All, You may have seen this in the general discussion thread: http://forum.kerbalspaceprogram.com/threads/83679-Custom-Space-Program-Possible-Challenge Take a look, it will explain the concept. As I mentioned, I thought I should let people know that at least I am doing this personally, and will try to share some progress. As of this evening, I have now flown a sounding rocket that I designed from scratch. I have a lot of work to do on texturing, and getting some fiddly bits working with the engine heating animation. That being said, the joy of flying a rocket that I created with only parts that came out of my brain is arguable as satisfying as when I first achieved orbit, many months ago. I imagine that my journey will continue with unmanned Kerbin SOI vessels for a while, until I can build up the skill base to really create the range of parts I will need to explore the Kerbol system. But of course, this was my intention. I don't even need the tech tree anymore to have a satisfying game progression, and it's pretty cool. Here are some pictures of my un-named sounding rocket, on it's was to an Apoapsis of 134km, on it's maiden ballistic flight. https://imgur.com/a/DxXMG

Hey, at least the part count is low!

I have mastered fuel tanks, and am working on engines and aerodynamics. Blender is a little bit of a pain versus what I am used to, since I usually work in Vectorworks, which is for precision actions, and I am very good at (I should hope so, it's my job). I may just find a way to export the physical models from there, and U/V map in blender. Anyway, the point is, a day and a bit in, I am nearly ready to launch a custom built sounding rocket. I will add a forum post to the appropriate forum when I really get going, possibly later tonight. As to that, with something like this that will progress, is it more appropriate to post in Mission Reports, or Spacecraft exchange? Especially since half of the challenge is building the models. I still hope some community members can really take off with the "Full Version" of this. Thanks

Under my current understanding of the game engine, which is no where complete (have to wait to tonight to really start digging in), but resources, the necessity for their consumption/mitigation can be implemented independently of individual parts. This would only make sense being that there are no mandatory parts that must be included in a spacecraft for these effects to occur, in respect to mods like TAC-LS and DREC. I would love to see these effects to be implemented as some sort of modular global framework, which is decided upon at the beginning of the video series, and distributed to all of the participating mod creators, and which is not modified per save file/video series. Depending on the licenses of the particular mods in question, source code could be reused to create a custom master framework which includes these algorithms and properties. Again, discretion is needed. But of course, unless you are trying to implement something like Ferram (which you should just install as is anyway), none of the resource depletion in these aforementioned mods, should be that hard to add. I'm not yet familiar with how to game engine handles it, but linear change in a resource over time should be a cake-walk. Having a standard framework build for the series will be essential anyway, as naming conventions, and features of parts should be comparable.

Firstly, this ^ Secondly, in your first attempt, what was your altitude when you slowed warp to observe the change in your Duna periapsis? It is likely that if you waited to change your periapsis until you were close, you could have wasted fuel. It is also worth noting that there are multiple ways of changing your trajectory when entering a sphere of influence. Burning to the Radial In vector will use far less fuel to change you periapsis than will a retrograde burn. Although it is worth noting, that it seems likely that if you changed your velocity by a simple retrograde burn, and you expended the fuel in your craft, you probably didn't have enough to return in that craft to begin with. EDIT: Previous poster edited before I hit send. This information is now redundant. As far as your space navigation woes are concerned, I am assuming that you are not using any sort of Delta-V budget calculations, whether they be a mod, or manual calculations. I assume this because you have not made mention of any expected fuel expenditure at an earlier point in the mission, and felt until your unexpected trajectory, that everything was going to plan. As far as your landing is concerned, despite my best calculations, I can be pretty terrible at actually piloting landings, so I can not help you there. As I am sure others will suggest, two mods that I have seen recommended, and use myself are Kerbal Alarm Clock, which can aid in SOI changes, among other things, and Kerbal Engineer, which will assist in planning your fuel and velocity requirements with reasonable accuracy. There is always something to be said for having a decent amount of fuel margin, especially if you have never done something before. Cheers

As I stated earlier, due to my work schedule, I will certainly not be the one making these YouTube videos. I will try to publish some pictures as I enjoy my own personal journey with this idea, but I think that having this idea be the model for a community project would be ideal. That being said, it would be fantastic for people reading this who are friendly with both video and mod content creators, to let them know about it, and see if anyone is actually interested in the concept. I can't wait to see what this creative and talented community could do with such a series. In reference to the idea of tech tree integration, a traditional model may actually not be necessary. I have only begun to dig into the specification of the game engine and programming specifications (I have some experience with file structure due to fixing game glitches, and appreciate greatly those who have guided me in the past). I would imagine that the game would be run in sandbox for such an endeavor, without the stock parts even loaded. Whether this can be done is the only thing I am unclear on, and will defer to those with more experience as to its implementation. I feel it is irrelevant to have the traditional progression for the two following reasons: 1. There are no existing parts. They must all be created for a purpose, and the next level of technology will emerge for missions of increasing difficulty. The person who is creating the series, and is requesting the part design parameters will have the want for a series which will keep the viewer engaged through ever more daring missions. A mission straight to the surface of Laythe would only be one piece of content, and not something that will drive their subscriber base. Of course there will be a certain amount of good judgement needed on the part of the space program director. 2. Mod creators strive to make balanced parts already. It is in their best interest to have and interesting and useful mod pack at the end of the series. Having a good directive to create a part to complete specific tasks will ensure that their parts have real, in game applications, and proven testing. Also, creating parts with differing performance parameters from the competing modders could provide differing unique, and creative solutions to problems. It would be and an interesting roleplay adder for the group of companies to "not be able to" create, say, and engine which has outlandish specifications from the program director. If it is desirable for a "Science" system to be implemented, perhaps part parameters could be set to provide science based on successful engine stand test firings, and short flights of the actual components. This could create a more realistic way to proceed to the next tech level, especially if the part output rate of the modders exceeds that of the producer of the videos. As we know from real life, these sort of things actually advance spacecraft design, as opposed to returning experiments from distant worlds. If a funding system is desired for the video series, then that could be a useful purpose for traditional experiments, where a robotic discovery spurs the funding for a manned mission. This could of course be accomplished by roleplay alone, without a necessary programatic game requirement, however I'm sure there are those who would love to play around with a system like that. Those are some of my idea's for now, and I would love to hear the opinions of some content/mod creators on the matter, even just to inform my own trials with this process.

Hello All, This idea has been mulling around in my head, being that for my job, I do a bit of modeling, animation, and programming (I work in entertainment video and lighting design, the same sort of things the squad guys started doing). This would be a challenge sort of the inverse of seeing how far you can push the stock parts. The idea would be to run a space program, and land on as many planets as possible only using parts that are bespoke for the program, much in the way that a lot of real space technology was developed, by the program itself. I'm actually not sure of anyone has done this yet, I haven't seen anything on youtube or google showing something like this. Imagine a space program where all of the parts were actually created custom for the specific game. I'm sure there is some overlap between talented modders, and talented youtube creators which could really make for an interesting video series. The natural progression of this could be a collaborative effort, where the one who runs the program could get a group of various modders, acting as "Aerospace Companies", and could submit specifications for various engines, tanks, and payloads, and have a government style procurement process to select the parts that go on the missions. They could even release the parts at the end of the series as it's own Mod Pack, which of course would be well tested, and documented via the Youtube series. Who knows, this could lead to the development of some really interesting custom solutions and parts that otherwise wouldn't come about just be people working independently on their own endeavors. I am definitely going to try this at least personally, but I certainly do not have the time to create a youtube series (not for lack of technical knowhow), but I would love to see what people could do with this idea. EDIT: Just to be clear. The idea is creating a space program that uses no stock parts, and no existing mod parts. The only parts that would be used would be created completely from scratch for the "Custom Space Program". Cheers EDIT: I will be posting my personal progress with this here: http://forum.kerbalspaceprogram.com/threads/83818-Custom-Space-Program-Small-Steps

Looks awesome! Do you have a complete list of mods? It this a "Linux only" installation due to memory requirements?

The design of the craft was spurred by my desire to build a "Reusable" SSTO/Shuttle type vehicle, but hindered by my lack of ability at landings. Technically, in lift configuration, it needs some additional boosters (included here), but if it is just recovering payload from orbit, it is fine on it's own. First, the list of mods in use: FAR B9 KW Deadly Reentry Mech-Jeb (In this case for orbital info, it can so not fly this thing) I have others installed, but they are not used here, this is the list if you want to use it. Before I go into the design, here is the Verti-Shuttle. You may begin to suspect something odd, and you'd be right. Here's some more info on the craft... Main Engine: Sabre M Booster Engines: Sabre S x 4 Control: 2.5m SAS (B9 version), Stabilator x 4, Large Airbrake x 4 Payload: Designed for 1.25m based payloads, total payload weight very dependent on ascent profile. No estimates yet. Crew Capacity: 2 Recovery payload: Theoretically, whatever you can fit in the bay. It could safely deorbit and land a block of lead. The rationale behind this is that with playing in career mode, that I will eventually need something to go pick up spent boosters from my early career, which, despite my best efforts, are still in orbit. I have used grabber claw vessels in the past, but I thought it might be useful to have something that could recover, say, crewed vehicles. Ready for launch. For anyone who cares to down load this craft, here are the ascent and landing profiles: Ascent Pitch targets: @1000m - 60º Pitch @5000m - 50º Pitch @12000m - 35º Pitch @20000m - 15 º Pitch @21000m - Booster Separation NOTE: The aerodynamics of the craft are designed for the boosters to separate THROTTLED UP. @30000m - 5-10º Pitch @45000m - Nosecone ejection This profile has given me at least 2/3 fuel in the main tank after circularization. Landing is easy as pie. @Orbit - Set periapsis to 20km @45km - Open 2/4 Airbrakes @20-25km, near desired landing site Open 4/4 Airbrakes @10-20km, Adjust airbrake pressure to target landing spot, kill all horizontal speed. @5km - Deploy landing gear, chute ring #1 @2.5km - Deploy chute ring #2 @Landing... well yeah, it's a rocket landed on it's nose... but it lives! I don't yet have good decent photo's, but here is the rest of the album: http://imgur.com/a/Q32Bd As well, for anyone crazy enough to want this in their space program, here is the .craft file: https://drive.google.com/file/d/0B51D0goiPm7JdE0tVGV6YkdlQVE/edit?usp=sharing I hope this amuses someone

Thanks for the hotfix! Works great now

I am having the very same problem. It actually bricked my career, but I was able to restore from a quicksave. Here is the craft file... https://drive.google.com/file/d/0B51D0goiPm7JdHVwRDJQQmdvdDQ/edit?usp=sharing Operating System: OS X 10.9.2 Processor: 2.3 ghz i7 RAM: 16GB KSP Version: 0.235 Mods: KW, MechJeb, Asteroid Cities I checked the craft file and the part appears to be linked to the proper items