Baythan

As a temporary workaround... yes, I agree. Or when magico gets a chance he could add that info to the OP. We'll still get people who don't check the last 2 pages or the OP before asking the same questions, but thats life.

With the current contract system as it is, some polish is already required, we know this and I'm sure Squad knows this. I'm not very well educated when it comes to programming, but it seems to me that making contract trees wouldn't be too hard. I think it could even be procedural in the same way current contracts are. Just have a basic empty tree, select a part, then output the first contract with that part. Once that first contract is done, output another contract with the same part. Taking this a step further, the altitude record contracts could all be combined into one long tree that takes you higher and higher, then into orbit, then the Mun, etc. Tying them together turns them from a discrete list of contracts into a full mission. Taking it another step and having the contracts auto-update with new objectives after a previous condition is met makes it even better. One could potentially make an orbit-capable ship and successfully complete ALL altitude records up to full orbit in one mission and NOT miss out on each discrete stage of records. As it is, I have to limit my altitude attempts so I DON'T break records I don't have contracts for and miss out on that little bit of extra funding early on.

Procedural part cost will probably not be able to be listed in part config or in that little tooltip. We'll live without it. Yay! being able to use that nosecone on a Mk1 pod without it looking ridiculous is a great thing. I'm pretty sure that's exactly what Prismatech was asking for through his Google(or Bing) Translator.

That doesn't fix the issue where inactive vessels with Kerbals in them get recovered by this mod, but the Kerbals lose their experience. Having to edit a save file every single time you recover a vessel in this way would get tedious. For the time being, I guess it's best to just not auto-recover any Kerbals.

This is pretty much what we are making the argument for. There are basically three(most likely more, but these three are the general idea) philosophies oh how people want to start their career games: The Wright Way: Start with plane parts like wings, landing gear, air intakes and air breathing engines. Fly around gathering science and funds to unlock more parts. The Sputnik Method: Unmanned Probes! Rocket engines, probe cores, fuel, and maybe some batteries/solar arrays. The Full Kerbal: Why test stuff first? Put Jebediah on a firecracker and send him up! Rocket engines, fuel, and command pods. While the unmanned and manned rocket starts can be very similar, the unmanned probes can be much lighter and therefore you start with smaller engines. So in the end we've all pretty much determined that we need brand-new career games to start with either nothing at all and we buy/research whatever parts we want with a starting allotment of research/funds that will allow us to get just enough parts to fulfill one of those three ideas or we get to pick a starting node that has one of those three sets in it. Mostly what we all want is the CHOICE to pick what parts we begin with so we can customize our career path as we choose. The Tech-Star/Wheel is just a visual representation of being able to go in whatever direction we want. The layout of the tech tree doesn't HAVE to be a circle as long as we get to pick our path and actually get all the parts needed to do simple versions of whatever mission type we decide to start with. The trickiest part of making a fully player-choice driven tech tree is making sure you cant lock yourself into a position where you picked parts that can't actually DO anything together, like getting engines, lights, batteries, science equipment, and probe cores.. but no fuel. The tree has to start relatively limited, but should not force us into doing manned rockets first if we don't want to. My biggest complaint with the techtree as it stands in how HARD it is to get all the parts needed for a simple(not rocket-powered) plane.

I noticed the listed price was 0 as well, but the parts do increase the cost of the vessel and do return funds while using StageRecovery. Could be considered a minor bug, not much of an issue though. Of course, it's hard to list a set price when different options that can be adjusted also affect the price pf the part... soo... lack of a price listed on the tooltip is no biggie.

I've noticed a small issue with precise Node, the Focus Vessel button doesn't always work. I haven't been able to figure out why, or how to replicate it working/not working consistently. It seems to mostly NOT work if I ever change focus to another object/node. Would an output log help? Edit: Still having issues consistently reproducing the issue. Seems to work fine sometimes and not others. Could well be a problem from something else, because when I can't use the focus vessel button, I also can't tab past Eeloo in map mode (should go back around to the Sun but won't).

I've noticed that AVC says version 7 of this mod is available, but it does not have the download link to it. I really only have the .dll for this is order to use MKS/OKS. Any idea why AVC thinks the update is already available?

Just thought I'd mention that KAS is currently using ModuleManager.2.5.1.dll instead of 2.5.4, not that it appears to be causing any issues in my Career game atm. Just thought it odd that I had 2 MM dll's and decided to see which mods were using an older version.

I'd noticed this as well, my GameData folder has both MM 2.5.1 and 2.5.4 because one or two mods (this being one) comes with the 2.5.1 instead of the 2.5.4 version.

The SpaceX designs are set up so that the first and second stages can be re-used within hours of return, rather than requiring a naval vessel to recover parts dropped into oceans halfway around the world. Stage one returns to the launchpad within minutes, stage two re-aligns after a full orbit and returns. Check out the info here. I would also guess that the tanks dropped by NASA Space Shuttles required repairs and refits due to impact forces with the water. As of yet, I do not believe there is a working prototype of a real-life SSTO. I could be wrong.

True. (apparently all responses have to be at least 10 characters, so I threw in a few more)

As far as fuel boil off, I very much doubt this will ever be added to the game, as that is needless realism that would make the game less fun. One can assume that the fuel listed in the tanks is what is available after such things are taken into account. I see no reason to force the players to have to worry about that extra percentage of fuel.

Not much control, no, but as stock chutes come with tweakable pressure and altitude settings, I think those settings should still be available in the VAB/SPH no matter the career level. The rest of the editables can remain in the action groups. Just my opinion, of course.

Agh! But I LIKE being able to edit when chutes deploy even without access to action groups! When I installed this mod today for the first time, it confused me that there was no tweakable to do so on any chutes, even the stock ones. After scrolling through the forum for a bit I discovered that the editable stuff is tied to action groups (and still haven't progressed far enough into Career to unlock that). With stock chutes I have a bad habit of dropping all chutes deployment altitudes to 50m so I spend less time watching pods drift slowly to the ground. I quickly discovered doing so with RealChutes is a BAD idea (~350-400m is working for the small stuff I'm launching right now). Given the complexity of the overhaul you've given to chutes, and the awesomeness of the mod in general, if you take away my ability to edit these things before action groups are available... I'll just suck it up and learn to live with it. Love the mod already, and I've only used 2 of your chutes and 2 of the stock chutes. Can't wait to start dropping station modules on Duna.

Something I'm seeing consistently in the output log is this: all systems started (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [RealChute]: RealChute Cone Chute Main chute Scale: 2.917974 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [RealChute]: RealChute Cone Chute Main chute Scale: 5.054079 I'm sorry to say I'm not familiar with what parts of the log would be most useful to you, or if you'd like the whole thing(over 23k lines as of right now). I'll do a search of this thread to see what you've stated about it in the past. Edit: Here's the full output-log.

Awesome. And we are being civil, for the most part. Some tempers flared, responses were made in a level-headed fashion, tempers cooled, hands were shaken. Consensus has been reached inasmuch as is possible: We want the Barn, and we're sure that Squad will do their best to make it up to the standards of the rest of their (very awesome) work.

If you right-click a chute while on the launchpad or while in flight, you can show the info tab and adjust predeployment altitude/pressure as well as switch between the two modes, and adjust the deployment altitude. Edit: added screenshot Edit 2: Also, removing the two cones and putting new ones on did not solve the issue of having two different types of chutes deploy from otherwise identical parts.

I just ran across something interesting... I put two RealChute Cone Chutes on a rocket using symmetry (each is mounted atop radially-attached solid boosters), and modified their deployment altitude from the part meus at launch, as I do not yet have actiongroup access in my career game. upon deployment of the chutes, one of them had 3 chutes deploy on shortish lines, and the other had a single large chute deploy on long lines. Will test again to see if this happens again. Not sure if its a bug or intended. All chutes deployed at the same speed and the craft drifted down without tilting, so no noticeable drag change.

For all parts? .... I did not know this... I must go test things now. I have seen some contracts in which the parts I had not activated allowed me to do a 'run test' and had the option in the menu even when in the wrong situation (it wouldn't fulfill the contract until parameters were met though), but I never noticed the ability to run a test on an already activated part or a part where the contract says it must be activated through staging.

I like the idea of better CoM control by having the fuels placed in more controlled locations, and using a better ratio of LF/O would help greatly with this. As Liquid Fuel and Oxidizer are generalized terms, we don't know WHAT kind of liquid fuel is being used and what sort of oxidizer either, but a more realistic ratio is a good idea. I'd like airplanes to have their fuel flow from the top of the plane to the bottom rather than the front to the back, but that should be another discussion. As it stands, I've started using the RCS Build Aid mod to see my Full CoM, Dry CoM, and Average CoM so I can better determine where to place wings and how to angle engines to create shuttles and spaceplanes. Having more control over these points by moving the heavier fuels forward or backward inside their tanks (or with two tanks attached, splitting the ratios up so one tank ends up heavier) would help with flight balance over the entire mission. I would guess that the ability to move two separate fuels around inside the entire vessel would be difficult, as would splitting the fuels unevenly across multiple tanks, so the best option then is your separate fuel tanks idea. The difficulty with separate fuel tanks that I see is in teaching players how to place the two types of tanks in the proper ratios, because you DO need to make sure you have the right amount of both so that you don't run out of one while still having some of the other. A stock version of something like Kerbal Engineer windows in the VAB and SPH would help by highlighting which fuel you are short on. The tanks would, or should, be designed in pairs so that if you use one of the LF tanks, you place one of the corresponding O tanks. If the tanks larger versions are also designed to hold exactly double (or some other simple ratio) the amount, you could place one larger tank(LF or O) and two of the smaller tanks(O or LF) in other locations to keep balance and fuel ratios. All in all, I like your ideas... provided the implementation remains as simple as possible in order to be fun while still being close to rocket science. If it become tedious rather than fun, Squad won't implement it.

I agree with this thread! I'm not a big fan of the "Test __ in flight" contracts because they don't pay enough, the speeds and altitudes are arbitrary and hard to meet in a single attempt, and take up space from contracts I'd LIKE to do, such as "Do Science ___," "Explore ___," "Rescue ___ from ___," "Place ___ in orbit around ___." I'd LOVE it if those pesky testing parts contracts were part of larger missions... and also didn't require activating the parts through staging. It is VERY difficult to test an LFB KR-1x2 in sub-orbital or orbital flight (even if it's empty), especially with the new building levels and with how early I seem to get that contract. A contract that had you test a single part in multiple situations, in order, would be very interesting. For example: "Test LFB KR-1x2 landed at Kerbin" This step would be on the launchpad, of course, and activated through staging. After completion, a new step would activate after having been greyed out from the beginning but still visible so you know it's coming. "Test LFB KR-1x2 in flight" This step should probably happen at a specific speed and altitude calculated based on a relatively light craft using only this engine, and it would involve the right-click activated 'run test' option. After completion, the next mission should become available from Mission Control. "Test LFB KR-1x2 in sub-orbital flight" This would be a new mission instead of part of the previous one because you'd want to do 'safe' (Kerbal-defined safe, not human-defined safe) atmospheric tests before adding more tanks and sending this sucker sub-orbital. There's little point in testing this particular engine in orbit, but other parts it would make sense to continue on this line of testing. This kind of thing would involve less procedurally generated contracts and more custom-designing for each part, but would make a bit more sense from a gameplay perspective. The current randomness of the contracts goes a bit beyond the lovable goofballness of Kerbals right now (in my not-so-humble opinion).

I believe you missed the OP's point. We aren't talking about the tracking station or the map view. We are talking about the load game menu where each savegame has a number of flights in progress listed. Flags increase this count. If you look at a save where you've visited the Mun a handful of times, Minmus a few, Duna several times, and planted a flag for each mission as I do to commemorate the survival of the Kerbals (and to a lesser extent the success of the mission) along with a nice amusing note of about who did the mission/what happened during the mission, then you end up with a savegame saying you have 20+ flights in progress. Toss in every satellite in orbit (especially if you use Remote Tech) and space station and the flights in progress gets astronomical as well as useless. I'd rather have a count of MISSIONS in progress where I get to designate what is an active mission and what is not, but that goes beyond the scope of this thread. Simply put: flags, which are landed objects and markers of past missions are currently counted as flights in progress on every save game and we believe this is erroneous/misleading/a bug/just an issue that should be addressed.

Sadly, I did not see the barn as it was presented wherever it was presented. I do like the idea of starting out as a backyard rocket lab built on a farm though, it feels very Kerbal. Many of us here have been playing for so long we might think the barn idea is silly and we are past that, we've all learned a lot about rockets and how to make them work in this game, or are rocket scientists already. But this is KERBAL Space Program, it's SUPPOSED to be silly. Way back when I started playing KSP I had the feeling of an amateur rocket enthusiast/crazy bomber because stuff just exploded all over the place. It spoke to the idea of who and what these little green dudes are: Crazy, Gung-Ho, not exceptionally bright, but still launching rockets! I say #Bringbackthebarn or #improvethebarnandthenbringitback. As it has been stated, and apparently overlooked, whatever was shown was only 20% complete. So, yes, the graphics were probably bad (again, I didn't see it), but they were INCOMPLETE! Whatever was seen would NOT have made it into 0.90.0. The models would have been finished, polished, adjusted, levelled, painted, etc. Now we don't know WHAT it would have looked like because people complained about the cake while it was still being baked. I love the barn idea, I think it fits the flavor of what KSP should be in the early game. I definitely want it to look nice too, as nice as a barn can look anyway. I think we should have that runway, even if it's just a dirt road that we take off and land on. A nice silo with a ladder/platform on it for air control it a good fit. Some trailers for the admin buildings, a Barn or two for the VAB and SPH. Tracking station could be a telescope, a laptop and some other instruments spread out on a card table. Think October Sky, but more haphazard and Kerballized. Of course, a re-worked Tech Tree to go along with it would be nice too. I want to build a crop-duster first... because I want to build planes first. Other people want probes first, and still more want to go full Kerbal and strap Jeb on top of a rocket for the maiden engine test. So, I guess what I'm saying is I agree with everyone to some extent. I love the barn idea, but the models should be up to (game-current) standards. Maybe Squad messed up in showing it to the public unfinished, but it sounds like a lot of really vocal people went a bit overboard in calling them out on it. It happened, oh well, let it go and look forward. Finish the barn, bring it back and lets see what doesn't explode when the engines light.

I too have wanted some way to move the flags off the 'flights in progress' count without removing them from the tracking station. I don't know what kind of change would need to be done to do that. Theres a possibility that some piece of code required to stop the game from deleting the flags as debris requires that they be counted as a flight in progress, and the change might not be as simple as we think. But it'd be a nice piece of polish in any case.