TaxiService

@neitsa I have successfully compiled the source codes of RT against KSP 1.2.0.1586 (both x32 and x64) on VS Community 2015 but only after I changed this incompatibility error at the line 216 of the FlightComputer/FlightCore.cs from Vector3d tgtLocalUp = vesselReference.rotation.Inverse() * target * Vector3d.forward; to Vector3d tgtLocalUp = Quaternion.Inverse(vesselReference.rotation) * target * Vector3d.forward; according to the Unity doc. It seems odd since this error is not found in the issue log of GitHub up to this point and you have no problem with complication (on VS2010) on the former line. Do you know why?

Ok, it seems like my IT interviewers said, it is best and quickest way to get familiar with the source codes is to do the IT helpdesk on the bug reports and patches. Many thanks for the direction. I will start with pull requests on the existing issues of the RT GitHub.

Do you have any brief information you could give me so that I can get started quick? Such as which editor to program in C# or the current phase of the RT development.

It would be terrible if this RT project, one of my favourite mods, goes dead without taking advantage of KSP 1.2's new communication network. neitsa, I will assist you on coding. However, I need to start learn on GitHub, Unity editor and KSP modding because I am relatively a new computer graduate, entering the industrial workforce only few months ago. I will let you know when I am sufficiently familiar with the RT codes and GitHub interfaces.

Yes, one nose cone has fixed drag units, when compared to the multiple intakes AND Quad-Adapter of fixed drag units. It is possibly why you fought against so much drag during your original ascent to 12km. 1) My ascent profile is directly derived from Val's profile for his Skylon SSTO below (with 350m/s instead of 450m/s). The reasoning of my ascent profile is to channel most of the thrust energy into the horizontal speed and drag overcome while let the wing lift fight the gravity in the lower atmosphere of dense air. At the higher altitude of <22km, where the air is too thin for the drag to be effective, I pitch up to "throw myself as high as possible into the air" like a baseball off the bat before I activate the rocket mode when I no longer can gain any more speed. Your ascent profile seems to be based on a different idea - get out of the lower atmosphere asap and do the majority of the work above 12km. I don't know if it is the efficient one but it should be good enough for an over-engineered SSTO plane. 2) You are right after I gave it some more thought. It should not matter how many RAPIERS to use as long as ISP remains unchanged. Please discard my statement about the two RAPIERS in my previous post. 3) One major feature to consider when designing a SSTO plane like this is to check how much drag is produced like this pic below during an ascent. Try to streamline the fuselage as much as possible. This includes the wings that have drags too. Another thing to consider is if you find yourself gain speed too fast during an ascent, it is possible to have overkill acceleration. You could try lose one pair of engines without sacrificing the acceleration much. I don't really have other tuning thoughts as they are much dependent on the SSTO design like CoL at CoM/CoL behind CoM or one more engine but more "deadweight" fuel to carry?

I got good news for you. Your stock plane does not need any modification as I managed to fly yours to 300x300km orbit, lose the payload, deorbit and land it on KCS. Once I got out of the atmosphere, I turned off all the RAPIERS except for two RAPIERS to conserve the fuels. Though, I notice the four RAPIERS at the bottom of your plane are not linked to any set actions and I didn't use them throughout the flight. I have to go now. I will come back in 8 hours to add more details if you request. P.S. Your plane has overkill of thrust and I had to adjust my ascent profile to prevent wing tearoff at absurd speed (cutting back the throttle).

Here's my submission to this challenge. Thanks to Nefrums's design, I revised my plane design to successfully fly, dump payload and land on KSC runway. It gots RCS and docking port. Fuels before the flight rollout (excluded the payload): LF: 13835 OX: 8277 MP: 250 Fuels at 300x300km orbit (excluded the payload): LF: 725 OX: 0 MP: 161 Fuels at KSC runway after the trip: LF: 444 OX: 0 MP: 88.15 Ascent profile: It is little complex profile (almost copied from Val's Chibi SSTO 1.0.5 plane) 1) Throttle at 20% until >10 m/s on runway to prevent air starving of two intakes. Throttle to 100% after. 2) Set AoA to 0 at sealevel to accelerate until 7km altitude is reached with over 500m/s 3) Set AoA to 0 again at 7km altitude to accelerate to 1000m/s 4) Set AoA to 10 upon 1000m/s 5) Set AoA to 15 upon 1200m/s before 19km altitude 6) At 22km altitude, go rocket mode and pitch up until no more ox 7) Outside 70km atomsphere, turn on the nuke and climb to 300x300km Mods used: KER, Alarm clock and MM. Plane name: Fire Spirit Points = (13835-444)*0.8 + (8277*0.18) + (250-88.15)*1.2 = 12397 P.S. It is possible to fly with 8 rapiers and 2 nukes with the ascent profile above. Even better, I could drop by 200 points by replacing the MP tank and RCS with LF+OX RCS. But I don't feel like I would try any soon. (deleted the "you tried" badge after reading the previous pages and discovering I actually got fewer points than other initial designs of other players) Post-challenge: Downsize this plane for my own SSTO launch to 75x75 km orbit while maintaining the same payload.

It is my bedtime soon but I made few quick changes to my plane. Besides the too much distance between wet CoM and CoL, is it good enough for the reentry?

I got the second iteration of my SSTO plane that can make to the 300x300km orbit and deorbit into the atmosphere. I changed the tail parts, replaced RSC parts, added two airbrakes and decreased the fuel volumes. But I am still rubbish at the safe and controlled reentry to KSC. I attached the last picture of showing dry CoM and CoL of the plane. Anyone can give me tips on the controlled reentry? I tried a few AoA strategies (AoA=10, AoA=15, S-shaped paths, full RCS pitch) but it always ends up in rolling over and falling towards ground. Also, not only this plane has this reentry control problem but all of my other smaller skylon-style SSTO planes (payloads - 5 ton, 14 ton and 36 tons to 75x75km orbits) always flip during reentry. However, those three planes recover and land on the KSC runaway successfully when the atmosphere is dense enough to use flaps.

>> WORK IN PROGRESS << Here's my first iteration of the heavy SSTO plane, Fire Spirit. I managed to get this baby into the 300x300km orbit with two orange tanks on the first flight attempt. (though I had to move some fuels around during the ascent) I need to refine this SSTO design as there are 1420 LF and 444 OX left. Mod: KER, Alarm clock, MM. Score: NOPE. Need to (1) cut down the fuel amounts; (2) land this plane on KSC; (3) find out if the design survives the reentry; and (4) figure out how to use RCS nodes for docking

The dish? There is only the short-range antenna on the transfer stage and I have almost zero oxidizers left. But see below for the feasible solution. Brilliant! I totally forgot about the RT queue of timed tasks. I think my delta-v problem will be solved, with dumping the lander and letting RT running the whole burning business. Good find!

Hey there, Thanks for the ideas. I am at work so I will take a look at yours later but I can comment on some ideas right now. I forgot to rotate my entry flyby of Duna to prograde after aligning the flyby plane against with Duna's plane, until too late after I burnt it into current orbit (with extra mass of second nuke). ...I like the crazy idea of getting off the wild ride with science stuff and rescuing them later. I will have to try it later. Hmmm, I need to do some maths first on this option that may be difficult for my amateur skills. Good catch on my mistake! This could be the easiest idea with having to getting into too much maths. That's interesting idea. I was worrying about saving as much remaining fuel as possible but the refuel probe should not be big in mass. Yup, at least the guys in my Eve craft have more than plenty of delta v to go home or even visit/flyby its moon. 1) It will be 818 m/s delta v if getting rid of the lander but zero correction-control in Sun SOI (I use Remote Tech mod). 2) Almost zero delta v of the lander because I drained entire oxidizers in the stock transfer tank with nuke. I used up almost whole fuel of lander in the trip of landing and launching. Very few options, indeed. Good idea. I am going to take a look at it later. - - - Updated - - - Um, I just thought of another option, based on your comments. How about this: escape-burn with whole craft directly and dump the transfer stage in mid-course. Then use the monoprop to do corrections into Kerbin's SOI. Once my guys enter the SOI as if they are an asteroid, I launch a rescue vehicle and get them before they escape the Kerbin SOI. Or I just get the guys off (with science of course) the asteroid and brake them with their eva monoprop into orbit of Kerbin. Then I rescue them later like those free-person contract.

Hi people, I have made a poor 1.0 decision. I shouldn't put two nuke rockets on the Duna visit craft. Now I have only 478 m/s delta v after landing on Duna and returning back to the orbiting rocket. I need about 650 m/s delta v to get the orange dudes home safely. Now I have three options of accomplishing it. 1) Use gravity assist of Ike of 300 m/s orbital velocity to accelerate for free, with current craft setup (both vehicles) 2) Undock and park the heavy lander in orbit to gain the total 818 m/s delta v to send the nuke+hitchhiker rocket home directly. But I am using Remote Tech mod (no remote-control in middle of home path), and would have no correction-control between Duna and Kerbin. 3) Send a refuel vehicle to Duna on next window. The wait will be like 1.0-1.5 years. The question is I am trying to figure out how to use the Ike gravity assist correctly. See the second photo in the second spoiler. Is A path the correct way? On a happy note, I applied my lesson on designing a EvE craft (just visiting not landing) with a single nuke and mod liquid-only tank.

Once upon a time... Last year, a large communication satellite was launched and headed for Dres, which was well-known in the folklore as "Lonely space potato". This satellite was part of our communication project, "Deep Space Network", whose aim was to set up a telecommunication network over the solar system and to support interplanetary spacecraft missions. On the halfway to Dres, the Mission Control of the Kerbal Space Center suddenly lost contact with the satellite, and could not re-establish the contact. Last few lines of its recorded telemetry indicated that an unexplained hull breach had been occurred, resulting in the total destruction of this spacecraft. In our entire history of the space center, this was the first craft loss outside Kerbin. Despite the setback, we decided to build and send another satellite of the same type to Dres in the next transfer window. Contracts Meanwhile, the Kerbal Space Center received three contracts from "Explosive Space Tourism" agency and "Marshall Lee Industry" corporation. The tourism agency wanted one hotel orbiting around Duna, and another one on the surface of the planet. The corporation requested a sample of the Karbonite resource to be mined on the Duna surface and to be delivered to Ike, the single moon of Duna. The sample would be parked in an orbit there. No reason was given for this odd contract, though few speculated that it might be just a rumoured ritual for a white-hooded boy and a talking dog. Nonetheless, the timing of this Ike contract was convenient. One of our space projects was to build a refinery and refuel station above one moon of a planet, along with a delivery vehicle. This vehicle which would land on the surface, mine some Karbonite, launch back into an orbit and deliver the payload to the orbital station. The station in turn would process and convert to rocket fuels for a wide range of uses, including home-return trips. Eve and Duna were the current targets of the near-future manned exploratory missions so two such stations were scheduled to operate above their moons, Gilly and Ike. Payloads Over several months, huge amounts of funds and resources were poured into the designs and constructions of five launches and their payloads. The payloads were described as follows: (a) Dres communication satellite This was a replacement satellite for the mysteriously destroyed one. This automated satellite at Dres would serve as a gateway between the inner and outer layers of our solar system. Also, Dres desperately needed a companion. ( Gilly Karbonite station A mining vehicle would piggyback on the fuel factory on way to Eve's Gilly. There, it would mine the moon and resupply any thirsty spacecraft with fuels. Two crew members were training to fly and operate the factory. © Ike Karbonite station Like the Gilly cousin, the factory station would arrive with its crew of two kerbals in an orbit around Duna's moon. It would refill the empty tanks of a spacecraft to go to somewhere else, included home-return trips. (d) Duna surface landers Two separate crafts for the surface hotel and sample contracts were glued together on a disposable transfer rocket to Duna. Once a successful orbit insertion was made, both crafts would separate and land on Duna independently. Each vehicle was to be manned by one crew person. The sample craft would launch and rejoin the Ike fuel station later. (e) Duna orbital hotel It was just for completing the orbit contract of the tourism agency. This unmanned mission would be remotely piloted from the Mission Control. Missions Spanning the next months, the spacecrafts were launched from the launch pad and made successful transfers out of the Kerbin's SOL. Each of the five spacecrafts was merrily floating through vast void towards their destinations. The Mission Control were satisfied with the lacking of any problem or anomaly report from the trips. A few months later, the crew of the Gilly mission reported the successful burn within the Eve's SOL and inserted themselves around the planet. The crews of the two Duna spacecrafts also reported that the pale orange dot was spotted at a great distance away. Everything was going well according to the plans- One of the rockets suddenly transmitted the Mission Center with a confusing report, and then went silent. The unmanned hotel station to Duna also ceased broadcasting its telemetry and was no longer responding to any commands. The report was baffling. It said something about the distant stars and Sun disappeared instantly, and that two green long tube-like objects were seen approaching the spacecraft rapidly out of nowhere. No further contacts from the three Duna-headed crafts were received. The large observatory of the Research and Development Facility was immediately ordered to pinpoint its giant telescope to the last reported position of the silent rocket. The observation of a wide field of debris was reported. Stunned, the Mission Control hastily attempted to contact the Gilly crew only to find they were alive but unaware of the disaster unfolding. In the next two days, the contact with the communication satellite would soon be lost forever. Its transmitted telemetry matched to the one of the first satellite. Frighteningly, it was similar to the telemetry of the lost unmanned Duna station vehicle. Aftermath Out of the five space missions from Kerbin, the Gilly one was the only one arrived at its destination unharmed. The rest were presumed lost to the eternity space, with the total loss of four lives. The ten thousands, if not millions funds, were down the drain. The flags over the Kerbin were lowered to half in our remembrance of the four brave astronauts. No one dared to wonder what was lurking in the black void. (Yup, I encountered this Kraken bug for the first time, and it is persistent in the multiple saves. It was so bad and the 0.90 update looks so awesome that I lost interest in playing the 0.25 update.)

Hi, I deleted all of the four Karbonite folders and added the three folders of version 0.1.2 except for the Texture Replacer. The index and null errors are still showing up BUT the errors only show up in the same landing area. I attempted more landings in other areas around the first test landing. I landed (too hard though) three times on grasslands, mountain and highlands some distance from the first landing without any error. Sorry, I don't think I can give you some good leads on the error origins. I will come back if I encounter the same errors on other planets or more areas of Kerbin. The single area of these errors doesn't sound like serious to chase after, does it? https://dl.dropboxusercontent.com/u/23644462/output_log.txt 10MB, direct txt, may freeze your browser!

Hi, I think you have seen the lag-related bug report before but I figure it won't hurt to have another bug data for you to dig out. Here's screenshot with long list of index and null errors, making my computer cry: And a output log (22MB) too: https://www.dropbox.com/s/qcm89ie3ig14ht8/output_log.txt 1) What I was doing when the null and index errors appear: I was landing a test Karbonite craft on a nearby west mountain, launched from KSC, and the framerate falls as the radar altitude decreased from 3km or so. The framerate becames 1-2 when the altitude is below 500m. 2) Mods: [ModuleManager] compiling list of loaded mods... Mod DLLs found: Assembly-CSharp v1.0.0.0 ModuleManager.2.2.1 v2.2.1.0 DeadlyReentry v5.1.5319.31493 EnhancedNavBall v1.3.2.0 Firespitter v7.0.5320.35444 KerbalEngineer v1.0.3.0 LitJson v0.7.0.0 OpenResourceSystem_1_1_0 v1.1.0.0 KSPAPIExtensions v1.7.0.0 ProceduralFairings v0.0.0.0 RealRoster v1.0.0.0 RemoteTech2 v1.0.0.0 Romfarer v1.0.0.0 SCANsat v1.0.6.0 KerbalAlarmClock v2.7.8.2 KSPAlternateResourcePanel v2.5.1.0 Karbonite v1.0.0.0 USITools v1.0.0.0 Non-DLL mods added: Mods by directory (subdirs of GameData): BahaConstellation NASAmission OpenResourceSystem Squad TextureReplacer TriggerTech UmbraSpaceIndustries 3) KSP 0.24.2 32-bit on 64-bit Windows 7 with 8GB RAM If requested, I am willing to reproduce this with a stock separate KSP. Let me know if you have some questions (but unavailable as it's bedtime for next day work :-p)

Did you command your craft to react to a maneuver node? I tested a simple 0.6-ton craft with a reaction wheel and set up a maneuver node ahead of its path. When I command it to hold maneuver prograde (node button). It indeed wobbles around the blue point on the nav-ball with and without torque, but I am able to time-wrap, cancelling the wobbling. I think the problem is the torque is possible too overwhelming for your little-mass craft to handle. Larger-mass crafts would be able to overcome the torque sweep. Can you check this?

Based on what I played, yes, a vessel with directional dish will connect to all vessels included active one within its cone. The dish can connect to omni antenna within too. I point one dish with widest cone at Kerbin, and the omni-only satellites orbiting the planet will connect to the dish (if they have the disk within their ranges). Correct me if I am wrong.

Windows 7 also can't open it but I can open it using 7zip. I recommend a different file extension or another program to zip the mod.