Blaarkies

It works with FAR, no ill effects...however, I do use the Stock Bug Fix Modules (by Claw). With both these mods, I frequently send up SSTO rockets with absolutely no fins or wings or airbrakes (inspired by SpaceX's Falcon9), and everyone survived. In KSP we cannot simultaneously control both ships, thus I build a massive 2orange-tanks+twin-boar SSTO that can lift about 10t payload into LKO. This SSTO uses some left over fuel to de-orbit, and weigh down the back end. I cannot even risk fins on the bottom of the engine because they will flip me over on re-entry...but you have to stay true to prograde on launch. So before you reach 100ms, you already need a slight east tilt. Then lock to prograde and keep it centered until about 40km altitude, from then on you can easily control the craft as you see fit. Engine gimbal does most of the work, so you are not really allowed to drop the thrust to below 30%. This thing costs way more than it should to put 10t into orbit, but when i land this near ksc the whole missions ends up costing 15k-17k.

DeepFreeze Continued -(By JPLRepo) You might be looking for that, it seems to be compatible

Speaking of adapters, are there any plans for the S2 plane parts? The octagonal shape looks really cool, but it's hard to use with other parts because of that shape. Don't get me wrong, the S2->2.5m adapter looks fine on space stations, but it's awkward on spaceplanes(increase in cros-section right before the engine) I have always wondered about a S2->1.25m adapter.

There you go! Bigger landing legs homegrown from stock parts! It's a Module Manager script that creates a copy of the LT-2 Landing Legs, and then rescales them to double size(and increase their cost, mass, etc.) +PART[landingLeg1-2] { @name = landingLeg3 @rescaleFactor *= 2 @node_attach = 0.0, -0.05577543, -0.1288447, 0.0, 0.0, 1.0, 2 @entryCost *= 2 @cost *= 2 @title = LT-3 Landing Strut @description = The LT-3 Landing Strut was designed after a mishap when a towering rocket landed(for a moment) at sea. Blame was thrown left and right, but in the end a brave engineer decided to simply double the size of the landing legs and hope they still fit inside the landing zone. @mass *= 2 @MODULE[ModuleLandingLeg] { @impactTolerance *= 2 @suspensionSpring *= 1 @suspensionDamper *= 1 } } So if you don't know what Module Manager is, then i suggest having a look at this(Module Manager). TL;DR :Get yourself "ModuleManager.2.6.17.dll" (or a newer version), copy that into your "GameData" folder Also, Open up notepad, copy this script into notepad. "Save As" SaturnVLlegs.cfg into your GameData folder.(make sure the extension is ".cfg" ,the icon should change) TADA! New legs in the same techgroup as the old big legs. All credit goes to Squad for the pre-existing parts, and also sarbian for making the awesome MM mod (and some credit to Red Iron Crown for advice). This script was quickly put together, so please criticize the kerbal hell out of it...I want to know whether or not the doubling of mass, cost, etc. is balanced for it's size and capabilities. P.S. I have a MM script that creates lots of cool parts out of stock ones like this...it also modifies existing parts slightly to make them useful(I'm looking at you, Mk2 Lander Can ...weighing more than 4 times that of the Mk1 Lander Can). Anyway, if anyone is interested in taking a look at that script, just PM me

SpaceX barge landing Do you see now how important bigger landing legs are?! If Elon had some big sturdy stock landing legs to build his rockets, that would have landed...and stayed landed . But no he had to rely on modded landing legs. All jokes aside, it was amazing that it stopped so gently but sad that it was for but a moment. Back on topic: Does anyone know how the stock landing legs react(their animations specifically), when their part.cfg file is edited to have a bigger scale?(I plan on making a simple ModuleManager config file, which would make a copy of a part, and modify the copy's scale,price,mass,etc.) ... (I want to tell a "forgot to click on the Lock Suspension button" joke, but it's too soon)

(git) Crzyrndm - VariableThrustLimiter A really simple mod. It adds a second thrust limiter on every SRB in the VAB/SPH. The stock thrust limiter controls the initial thrust, while the second limiter controls the final thrust. The SRB's thrust follows a linear function of these two values. I wish i found this mod sooner!

^This is what we need But I see a small problem with this solution when looking at the contracts window "in-flight". ...at least after you choose the contract in the Mission Control building, you will know exactly what is expected of you.

Me too. Back in v0.24 when i did my very first mun landing, i was pleasantly surprised to find that each binome had experiments independent of each other, with that could rush through the tech tree(I uncontrollably exploit any farm-able features i find ). So after doing that way too much i absolutely hate binome hoping now...binomes are a cool idea, but sometimes i wish i could just land on 3 different spots and be done with all the Mun's science. Regarding the science on contracts thing...have you tried "Zero Science Contracts"? It's a tiny mod that removes any science rewards from contracts. It gives me a bit more gameplay, since with this mod installed i can't get through the tech tree with just low orbital flights anymore. ISPR missions sound awesome, it could give MK3 size spaceplanes a real use. A simple version could be "Expand space station ISS with part X" + "Be in LKO for 16days" + "Recover part X" Contract configurator type mods does this and more, but i'm not sure how well the part ID sticks to parts after docking and undocking. Is it possible?

I want to propose a new mechanic in Stock to encourage the use of the part called "Mobile Processing Lab MPL-LG-2". Instead of supplying a slow but infinite source of science points, I suggest one based on the current science gathering mechanic. Simplified version: Every SOI has a set amount of science points attainable by the MPL(doesn't matter whether you gathered every experiment or not). For arguments sake, let's say 500sci. Send a MPL into Kerbin orbit, put a scientist and lots of solar panels on it. Click the "start research" button, then after some time and lots of EC the current attained science points in the MPL will increase. At any time the player can transmit the current attained science points(to recover some science earlier if need be). The processing can only continue until the sum of all transmissions and current attained science points reaches the 500sci point limit...at least for this SOI. Sending another new MPL to the same SOI does not get any new science at all: once the 500sci has been reached, then no more MPL science can be done in that SOI...the MPL is essentially useless as far as science is concerned(unless of course you move it to a different SOI). This science is essentially like a thermometer experiment, except that it is worth a lot more, but it trickles in slowly and takes much more electricity(and the scientist and fuel to get the MPL there) Advanced version: Every SOI has a set amount of science points(dependent on the total amount of gathered science in that SOI) attainable by the MPL. For arguments sake, let's say 10% -> Let's say there is 5000sci gather-able science(thermometer,gravimeter,crew report,etc.) in the Kerbin SOI, but at the moment the player has only collected(recovered/transmitted) 1200sci. Then the MPL can only processes until it has attained 120sci. -> As soon as the player recovers/transmits more science points(let's say 2000sci more), then the MPL can continue a little bit further(until it reaches 320sci). Simplified version points 2,3,4,5,6 are all applicable here Unmentioned ideas: Scientist skill level: Should it influence the speed of processing? (time warp nullifies this anyway). OR should the skill level enable "over-processing"(instead of stopping at 500sci, a good scientist can up the limit to 550sci)? Right click menu on MPL: Show the maximum amount of gather-able science point in it's current SOI? (it's a nice way to track progress...although the R&D has a version of this) SOI: Is Kerbin SOI all the science(landed,splashed down, all binomes on kerbin, atmosphere, LKO, high orbit,etc.) except those that are within Mun and Minimus SOI? (In other words, are Kerbin, Mun, Minimus SOIs counted as 3 different unique MPL experiments?) Landed vs Orbit: Should a Kerbin SOI MPL experiment rather be divided into a Kerbin-landed and Kerbin-orbit experiment? But...why?: Both the previous and current version of MPL stock mechanics did not address the issue of encouraging players to use a 3.5ton fragile structure in space. -> "old" MPL made it sensible to use 1 of each "SC-9001 Science Jr" and "Mystery Goo" when doing a mission that required re-using these multiple times. The boosted transmission value was silly: it had such a slight effect for unmanned crafts(one-way trips usually), but adding 300 LFO to a science probe craft could very well let you even return that science back to kerbin. For manned craft, why would i want to leak out ANY science points by transmitting, when i am planning to bring back that crew? The only sensible argument is that the little bit of transmitted science could help support missions, to refuel those far away kerbals who need it. -> "new" MPL is just ridiculous: Start the game, rush the techtree up to the MPL(get solar panels, and basic rocket parts). A few contracts should get enough money for like 10 MPLs. Build a centipede of 10 MPLs, separated by decouplers, each with lots of solar panels. Put them on the runway. Use the VAB to launch your scientists, and a single kerbal to run around the KSC collecting every piece of science he can. Put this heap of science into MPL nr.1 and process it...retrieve that science, store it in the next MPL. So you fill up all these MPLs by copying the same heap of science. Start research and timewarp to the max. -> Your first Mun landing will be a Saturn V sized craft and science will become meaningless However, i understand why it works this why. Whiny players convinced devs that "career/techtree is such a grind!"...career is a mechanic that encourages players to build smart and cheap, on a shoe string budget with outdated technology. If you want to build your dreams, then use sandbox to skip the grind or slide the wonderful difficulty sliders at the start of a new game. I feel the current MPL is overpowered, i vowed to never use it until the techtree is fully researched. The admin building's funds->sci mechanic breaks the techtree as well, but that's for another thread. I was aiming for an abstract mechanic, where the player doesn't have to micro-manage everything. Where a science lab in space just "does science", sort of encompassing what happens on the ISS(NASA wouldn't make a half-way stop back from a moon landing to fill up the ISS with moon rocks, do they? ) This isn't a perfect solution at all, so please criticize and tell me everything that is good, wrong, right, bad about this suggestion.

The 90 degree angle landing legs is a good idea, not only for b9 mothership landers, but also for the existing contracts asking for bases and such. But @Pulstar has a good point about bigger engines needing longer landing legs. In general it seems that stock KSP parts tries to emulate their real life counter parts(at least visually)...and since yesterday's successful launch and landing, i'd say those massive Falcon9 legs should become stock. It makes just as much sense as the NASA Saturn V fuel tanks, or the fact that theres 4 sizes of rover wheels...but only 3 sizes of landing legs (they should handle the 3.75m tanks at their max limit at least)

On default this mod will NOT kill them, even if they are without snacks on the way to Eelo. You can change this by opening up the "...GameData\Snacks\PluginData\Snacks\snacks.cfg" file and changing "kerbalDeath = False" to a "kerbalDeath = True". This should kill kerbals at meal time if there is no meal(not sure if it has a grace period). However, with or without death, you will take a reputation penalty hit for every meal time, everyday kerbals are hungry...this could "kill" your space program if you dont pay attention to it. There is no stock life support as of KSP 1.0.5, with no mods you may leave kerbal out in the void of space for years on end...nothing will happen to them or to you for doing that(you monster!) Snacks! is simplified relative to the other lifesupport mods out there(where you need oxygen+water+food+equipment to maintain a cozy room temperature inside and all that). Snacks doesnt need micromanaging, the only rules is to know how many "days" away from kerbin(or other planetary base) your kerbals are, otherwise your resupply trips will be too late(my kerbin space station is only "2 duna landings" old, and i have resupplied it 3 times now) If you are familiar with the basics then you are ready for this mod, but it takes a few missions to learn how much snacks to pack(My first few interplanetary missions still had tons of snacks left when i returned...just to be safe )

Nope, doesn't overwrite any files. It uses "Module Manager"(a .dll only mod that is like a programming language for ksp parts, it edits parts without touching their part.cfg files -> it gives you a "temporary" version of a parts with your modifications that is created). So Snacks! just modifies parts that has crew capacity, adding a snacks resource to them. this change only exists in your RAM. If you run the same savegame without this mod, then suddenly all notions of snacks on your vessels will be forgotten, as if the mod was never installed to begin with. This mod is awesome because it is so abstract. If you don't like micromanaging too many stuff, this mod hits the spot. -You have to think about how much extra crew capacity parts you want to add to your interplanetary ship(A Hitchhiker could support 1 kerbal about 800 days...that's about enough for a Duna flyby mission?) -Perfect cheapest Hohmann transfers aren't that good for manned missions anymore(because the longer transit time costs more snacks->mass->cost). It let's you use real-life early intercepts, which cost more dv but less snacks...which might be more efficient.

[quote name='JPLRepo']Is anyone still actively using or working on this mod? Has anyone testing with 1.0.5 yet?[/QUOTE] I am using it. I love it, it's awesome and still works in KSP 1.0.5. Stuff not fixed: - Rescue contract kerbals spawn in a capsule that has 0 snacks. I still get the reputation penalty for them being hungry, even though their not my kerbals yet(never entered the 2.3km physics bubble). So i ignore any "Rescue Derp from orbit of the sun" contracts: I leave a probe controlled lander can with like 400dv on each space station. If a new contract leave one stranded in Minimus orbit, i can quickly get him some snacks at least. - MK3 Passenger module(16 crew capacity) might not have snacks, see you might have to fix "patch.cfg" Everything else works perfectly fine(i just re added snacks weight for myself...seems to be more "can't have it all")

[quote name='FungusForge']This doesn't seem to actually like FAR. For whatever reason Trajectories is causing my craft to get minced because of aerodynamic stress whenever I go to the map. Even on the runway. Removing Trajectories fixed the issue, so I figured I'd bring it here.[/QUOTE] I have the same problem(not on the runway per say). Whenever im in the atmosphere and switch te map view, then my vessel starts spinning around violently, changing it's axis of spin quickly as well, also my orbit (stock and predicted) changes dramatically, by the amount of about 5g in random directions(velocity seems to slow down though by more that 10x atmospheric resistance). -I can see the rotation(10+ revolutions per sec?) in the navball in map view, the longer i stay in map the worse it gets. -It stops as soon as i switch back to flight("real world" view)...except for the spinning inertia left over from this. -This was tested with multiple vessel designs(at first it looked like phantom acceleration by part clipping, so i tested with simple rockets as well), starting from launch, and again after re-entry back into atmosphere(both situations before and after going to "space centre" and back again). -Enabling/disabling "fixed-body trajectory" did not affect results I do however get no glitches out of atmosphere. Anything above 70km is business as usual to adjust orbits and the like. Mun landings work perfectly(i constantly switch between map view to double check my landing site), I landed with pin-point accuracy where your red cross predicted and with very little effort. Using: KSP 1.0.5 build1028 Trajectories-v1.4.4 FAR v0.15.5.3 "von Helmholtz", 11/12/15 RemoteTech v1.6.9 ScienceAlert-1.8.9 P.S. Awesome mod, Squad should really get this into stock. EDIT: Found this. It would explain my results(but i have no clue about the source code) I know this mod is still a pre-release for ksp1.0.5, but i find this mod so useful. I hope all this is useful This issue was fixed by removing RemoteTech. I think the probe autopilot computer/feature interferes. post-number:[URL="http://forum.kerbalspaceprogram.com/threads/20451-1-0-5-Ferram-Aerospace-Research-v0-15-5-3-von-Helmholtz-11-12-15?p=2303362&viewfull=1#post2303362"]#11395[/URL] [URL]http://forum.kerbalspaceprogram.com/threads/20451-1-0-5-Ferram-Aerospace-Research-v0-15-5-3-von-Helmholtz-11-12-15/page1140[/URL]

You might want to check your: [CODE] !fx_exhaustFlame_blue !fx_smokeTrail_light [/CODE] ...these might be syntax errors. I made this same mistake in MM, now i finally found the solution. You need to replace all the delete lines with: [CODE] !fx_exhaustFlame_blue = 123 !fx_smokeTrail_light = 123 [/CODE] If in doubt, go in-game to the "space centre"(where you can choose which building to enter) Press MOD+F11 there(Alt+F11), and MM window should show up to reload the parts database in game. In the Alt+F12 window there is a debug/database tab. Follow that in all the way to parts, try to find your part you are interested in to see the kind of "cfg file" that is loaded into memory at the moment...compare to see what wasn't removed correctly. I found this at: [URL="https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax#delete----or--"]https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax[/URL] [CODE]@PART[nodeDelete] { // Delete the first copy -MODULE[module2] {} // Indexed delete -MODULE,2 { } // Indexed delete from end -MODULE,-2 { } // Indexed delete off end -MODULE,9999 { } @MODULE[module1] { // Unindexed (remove all) -multiVal = dummy // Indexed -multiVal2,0 = dummy // Wildcard -num*ic = dummy } }[/CODE] P.S. My very first post, i have no idea how the formatting is going to turn out.