boolybooly

The Kraken takes the blame!

It liiives! @toshathanks for resurrecting the K-Prize. Congratulations on completing the K-Prize challenge successfully four times with four craft designs and earning three highly regarded APPAs with SRSTO, Jack of No Trades & Mk2 SSTO for Passengers and a sincerely respectable PPM for the Silver Bullet mission which I hope you agree did not touch the grey runway texture due to collision with the floodlight and came to rest, with zero dV or any other motive means, on the sloping green bank around the runway which counts as KSC field ... so close. Thanks for your video mission reports and welcome back to the K-Prize party guest list aka the roll of honour. (I have added the mission kudos beneath your previous successful mission listings.)

Can anyone explain what is going on with these files failing to validate? I have had a few gremlins with my instal so I uninstalled and deleted it and redownloaded a fresh instal and manually rejigged .cfg so as not to reintroduce any glitches. I have no mods ever and three career saves synced with steam but I didnt run any of them. I ran a test sandpit game and the game behaved normally and I checked vehicles and kerbals to make sure I had the .cfg set up right. But after quitting I ran the validating tool and it picked up 20 files. Previously it was picking up 32 in the previous installation. The .cfg might account for one, why twenty? Anyone know what is going on?

@jimmymcgoochie thanks for the suggestions and valid concerns I used the ratchet method, had four micro legs and two medium legs to use as jacks on the rover and found I could use the displacement tool in engineer mode to move them out further and further in pairs, retracting and deploying, as long as the point of contact with the Mun was the other side of the center of mass from the engine landing gears it was stable-ish on four points, so moved all fuel into the bottom tank, maxed springs and ended up I was able to right it using the extra gyro tacked on the side for a bit of welly on the last bit. You can see in the screeny from after righting the lander and prepping it for orbit, this process somehow mangled the weight distribution in the lander and it showed up in burns even after I removed the spare gyro but not so bad it could not fly. Dont ask why I brought a magnetometer to the Mun surface, basically I forgot it had it on there! Also for return the Kerbals had a Mun insertion stage in orbit which doubles as a fuel depot and junkyard and had the chutes tucked away in an inventory cargo section to reduce the Mun lander weight. After rendezvous the lander was re-engineered to add those and remove the science pod for possible recycling, which seemed like a good idea as you are right it is a weak link for thermals. Though if you keep it in the thermal shadow of the tanks and engine or ablative shield (which it does have below the Mk1 pod for emergency use btw), by reentering retrograde you can in fact keep everything behind the engine or shield cool e.g. chutes, though you do have to watch the engine thermals on a direct reentry from the Mun return orbit as it is a pretty high speed and anything from outside Kerbin SOI would blow up unless you decelerate first and or keep it above 50km but from the Mun you can go to about 37km and if it overheats enough to fill the bar a few m/s of retro thrust will take the edge off it. If that fails you can just jettison the fuel tanks and engine and go with the ablator which has higher drag and a better thermal shadow for its size and does the job. So the reengineered lander returned with engine intact and besides repairing the rover they collected over 1000 science as well as completing munstone collection and flag planting missions and testing the small rover wheel on the Mun.

My space ship fell over. I was trying a rover repair mission. I had set up a lander with longer legs on one side than the other because the target rover was on a slope and it had to be parked nearby to transfer parts to the rover with an engineer. I was having trouble because of shifting frames of reference in engineering mode, even when the kerbal engineer was on a ladder on a rover parked on the Mun surface there was a kind of creep possibly due to the rotation of the Mun which kept misaligning parts. Also velocity was added to the craft every time a part was added. I bodged it and it worked well enough but dont get me started on rover wheels. I finally completed the objectives, brought the rover to a new location and back to the lander and then thought about salvage. As I sat there in inventory mode something about that broke the lander leg physics and to my horror it slowly toppled over stranding Val, Bill and Bob on the Mun. The kicker is, this is a "no second chances" career game. So no save and reload, I have to engineer my way out of this situation with a few spare lander legs etc, could be tricky but at least the Kerbals are safe! https://steamcommunity.com/sharedfiles/filedetails/?id=2635971208

Back in the days when we had no Mun and no time warp, real time was the only way to orbit Kerbin. It was fun patiently waiting the half hour it took to get a chance to land back at KSC and watching Kerbin pass beneath but it was a big relief when timewarp arrived. But hey if it makes you happy, you can play it any way you want to. Maybe dress up in an astronaut costume at the same time just dont crash at the landing site or you will not be able to take it off until you get rescued!!

FYI still gtting CTD on revert to assembly soon after revert to launch. This is after validating and repair as above. This instal has never been modded. After the last CTD, 31 files failed to validate despite previously being validated and passed after repair. So something is causing the files to fail validation and its not me! i.e. have not made any edits etc.

I always play career in KSP, unmodded, usually >hard, currently trying a 40%/40%/100% (sci funds rep) playthrough, with revert and save/reload. Previous playthrough "Hard Science" was 10% sci, with funds and rep at 100% which I found fun but didnt get to finish it before the Final Approach update. I like finding ways around the challenges restrictions create and min-maxing mission craft. I also find progression in a career creates a sense of a narrative/history and rescuing crew helps to give them characterful significance. I agree the KSP1 mission system leaves a little to be desired but I pick the best and leave the rest. There are a lot of pitfall missions generated which are basically unworkable but by now I know what to avoid. Am looking forward to trying out whatever Nate & Co have cooked up for progression play, probably default settings for the first playthrough though.

FYI as a preliminary to bug reporting I verified the Steam installation and it flagged 60 files for redownload so hopefully that will fix it. This suggests something did not update completely first time around. This installation has been kept up to date but is a year and a half old (Apr 8 '20).

I have been getting more CTDs than usual with the latest update. Two when reverting to hangar and one when exiting research after researching a new node. Each time they gave me a kind of loading screen. See screeny below, I was wondering, does this mean they are being reported and I dont have to make a bug report?

Before all the SAS bells and whistles were added landing was quite a learning curve, took me hours and hours to understand how to coordinate navball and eye. Its actually much easier to land now, if you have a pilot or probe core which can track retrograde. You just set SAS on retrograde, altimeter to mountain i.e. distance to surface and set relative velocity to surface, execute an approach burn then set up a braking burn node which brings the orbit velocity to zero, as a guide at the point just above where the approach meets the surface in the map, which will help keep a tab on how much dv you need to use to get to a landing velocity and the time it will take to make the burn. Then you approximately execute the braking burn as necessary by the seat of pants method and allow the craft to fall when it will continue to orient to retrograde at the correct angle for braking and you can bring it down gently and the altimeter will tell you how far you are above the terrain. The trickiest bit is right at the end, switching SAS to hold course when you get below 5m/s, by which time you need to be on a vertical descent, also if you want to gain altitude, as otherwise you will find your lander veering erratically or even upsidedown! Once you have that working you can do the whole thing with a target selected and land accurately by switching between target and surface relative velocity and navball display.

I like the waves, what I really want to know now is ... can Kerbals surf ?!

Thinking out loud, I did try this in KSP1 and encountered that problem that you cannot control two craft at the same time. I got as far as needing to make the first stage a high enough lob and second stage a high enough thrust to mass ratio so it could quickly make a burn and give me enough time to land the first stage before I had to circularise the second stage orbit. It worked and was doable for fun but was time consuming micro so I reverted to disposable stages, so I could focus on other aspects of the missions and optimise the second stage for flight instead of reusability of the first stage. In terms of how this could work in game play, splashdown with chutes or touchdown with chutes assisted by landing legs and last second burn were the ways I did it. Either way you had to engage the full physics sim to get a recoverable landing, since otherwise KSP1 just approximates a collision and you lose the stage. It strikes me that it would be nice to see a recovery option. You could just set it to recover anything with a chute on it in place of collision which would be OK though thinking like a criminal I mean gamer this is easily cheesed since you could just slap a smallest chute on and would also miss out on the challenge to actually do it for real. This implies there ought to be some kind of test for reusability. One way would be a simple one off physics calculation for landing velocity, involving the mass of the craft and its total drag with chutes deployed, atmosphere and altitude of impact/touchdown. Powered landers could factor in a dv deduction at the point of "landing" related to the amount of fuel remaining and engine properties. Another approach would be certification of a specific craft design by an actual mission flight, meaning you could certify a stage as reusable by actually flying it and landing it, Thereafter it could be treated as recoverable so you could just allow it to reenter and it would be recovered instead of collided. The reason this might be worth doing is it raises the prospect of a social aspect, using steam workshop to share certified designs, so others can use the design in their own game, meaning the design would carry its certification with it and be useful to others. Certification is also open to cheesing because e.g. you could expend fuel in later flights you held in reserve for landing in the certification flight. So there would still need to be a test for viable undamaged chutes and landing legs and remaining dv for a certified reusable stage to be treated as recovered. It could also be cheesed by reducing payload mass or reducing separation altitude for certification so this would also need to be tested and both recorded at certification and then applied at relaunch and recovery failed if either parameter exceeded. 2c

Delighted by the lights. Attention to the player experience is welcome, in the little stories about how a part gets used. I beta test a fair bit and construe its too easy for engineering to go ahead with tunnel vision on the task at hand and the player experience being created treated as an afterthought, which is the other pole, as it were, of game development and too important to be an afterthought. So its encouraging that the player experience is front and center of defining engineering objectives in KSP2.

Good to know objects will collide effectively at high velocities in KSP2 ! The √64k question, can we use impactors to shift asteroid trajectories ?

Just want to say thanks to the people responsible for bringing us this update, I am grateful for the real long term effort that has been made to support and add to KSP #1 and give value to all owners of this game. As a player it creates a good experience and I believe makes excellent marketing sense as well as not only will KSP1 continue to be popular itself, it will also act as a great advert for KSP2. This is the right way to do it, a virtuous spiral of a good game and happy players, well done and thanks!

Not sure if this has been mentioned, scanned the thread but not all details, nodes as bookmarks. In KSP1 you can overshoot a maneuver node. What KSP2 needs for SP and MP is for maneuver nodes to act as universal bookmarks and stop timewarp a few mins before a craft reaches it even if the player is piloting another craft. In SP it means you never miss another maneuver, hooray! In MP it means you set up your flight in real time with a maneuver node, press go for timewarp which is your vote. When everyone has pressed go the game warps to the nearest bookmark for all players at a speed matching the interval to the next node. Player communication would be important to help things go smoothly.

I dont see this as a problem at all, you could just import the engine data with the craft file to use in sandpit mode and filter engine data in career mode and allow substitution of an imported engine model/specs with a player owned engine model, maybe add a warning or comparison like with prototype part testing mission designs in KSP1, where you can build a craft with a part you have not unlocked if you have a mission to test it and retain the craft design if you completed the mission but cannot build it until you unlock the part. The programming for that has probably already been done. Then with an imported design in career you can try to use your own engines or develope engines to meet requirements and match the imported craft spec. If anything it becomes an incentive/challenge to R&D better engines. Any designs included in the game would have to work at min spec for engine performance obviously. Personally I would like it if the product of engine R&D started below stock capability i.e. prototypes and then matched it to become a production model and went on to exceed it to a limited extent with trade offs allowing excellence in one capability. There might need to be different models of the same engine type for that reason, player named and player developed. Obviously you would not want it to get too silly but on the other hand it might be something to do with end game resources.

I would like to play with test flights and static test firings as a part of component research and for components to actually improve as a result. Would like research to be far more granular, individual parts for some branches of the tech tree like SRBs and a separate branch which is similarly one at a time research progression for very large engines like Mammoth and Mainsail. Then test firings etc could add gimble cabability to prototype engines and improve it for production models as well as improve ISP and tweak atmo/vac ISP performance to your requirement, but consume resource of some kind, like research and funds with exponential scaling of cost per improvement. Many types of parts could be improved, like landing legs could have better load bearing / heat tolerance / lower weight but if you raise heat tolerance or load the weight goes up. Point being to feel like you are flying something potentially unique which you had a hand in creating. I also think you should need to achieve milestone goals to unlock the option to research some tech, as if under the control of a directorate, who only approve the need for a particular part if you demonstrate it, eg LV-N NERV is only unlocked if you complete an interplanetary flight of a large distance like to Duna, without it. 2c

Congratulations @camacju on completing the K-Prize mission eight times over in one launch with a prodigious feat of endurance demonstrating true dedication to the cause of reusability! APPA x8 it is, well flown, thanks for your mission report and welcome back to the K-Prize roll of honour aka the K-Prize party guest list.

Looks good, I like the way you have the craters on the rocky highlands and glacial material filling the valleys.

@tosha please consider your reputation on the K-Prize party guest list redeemed. Congratulations on completing the K-Prize mission successfully with Comet-Nickel and bringing a payload of ore back to Kerbin runway from Minmus to earn the kudos of the much sought after (often missed) Advanced Pilot Precision Award as well as the highly regarded Utilitarial Distinction. Welcome back to the K-Prize party guest list, aka the roll of honour.

Probably! Hehe, very well, here is your bespoke quip ! tosha told reporters that hacking the KASA mainframe was only to assist a refuelling maneuver, was very sorry it broke a rule but felt its easier to ask forgiveness than to get permission.

So... @tosha do you want a gatecrasher? . . . Save file edit counts as modding IMHO and refining rules you know about, though its perfectly legit to pick up ore and transport it as payload, even refine it, as long as you dont use the fuel created which I am gathering was the case with this mission.

With a game engine, as with the imagination, anything is possible. As I understand it, in the real world this is possible but very unlikely with a random convergence. Large planets like Jool which is analagous to Jupiter, are believed to be responsible for flinging other planets about in the early era of star system formation. A small moon sized planet like Eloo/Pluto cannot get close to a gas giant like Jool/Jupiter at orbital speeds without having its orbit around the sun bent out of shape by the huge gravity well of the larger planet. The small planet will deviate massively from its previous orbit but the larger planet will deviate hardly at all because the mass of the small planet only creates a tiny gravity well. The small planet will in most cases either be accelerated by a slingshot effect or be dropped into a lower orbit by a negative slingshot deceleration. It is possible for a very restricted set of cases for the acceleration and deceleration to cancel out and balance each other. This is why Jupiter's moons for example have settled into a pattern of resonant frequencies 4:2:1. Is that the kind of thing you were thinking of?