Matuchkin

Currently having an issue with a CKAN-installed instance of RO for 1.12.3, on the procedural fairings side of things. It appears that fairing diameter cannot be larger than 1.5 meters. Upon attempting to increase their diameters further, nothing happens. I have an incredibly faint memory of something like this appearing in the past, but I can't recall a single detail past that. I may be blind, but I have not been able to find any settings that would allow me to increase fairing diameters further. This may very well be some hidden option that I am too dim to notice. Thank you for the help.

I have installed Procedural Fairings for 1.10.x, from CKAN, with RO. It appears that the fairing bases have now been adjusted to limit themselves to the diameter of what they were attached to, with the user unable to increase their diameter further. This renders it impossible to use the mod. I hope this issue can be fixed soon.

I would like to provide you with the following advice: Step 1: take whatever crew parts you need. Step 2: attach solar panel, attach long range antennae. Step 3: LV-N "Nerv" Atomic Rocket Motor (x1) Step 4: Mk.1 Liquid Fuel Fuselage (xN, N∈Z+) The universe is now your oyster, at a nippy 0.10 TWR.

2353: After eight years of climbing, you finally locate the printer outside conference room 5, only to find that it ran out of ink sometime in late 2017. You use the elevator to get down to floor 10, retrieve the ink, and reload the printer. The round trip takes around 30 minutes.

Ten years and finally the last page is written. I would say it was a great run, almost 10 years being the only game of its type and fully relevant until the end. On the plus side, I guess there will never be any issues with mods again. Except the ones that didn't make it from the good old days. On a completely unrelated and totally unsentimental note, does anyone know if it is possible to get one's hands on KSP 0.90?

I am quite a big Quentin Tarantino fan. Actually I'm completely into this whole class of directors - QT, the Coen brothers, Robert Rodriguez, and the like. One film I find to be severely underrated is The Hateful Eight. The general consensus that I see is that the film is bloated and/or has an excessive runtime. I don't feel this way - in fact one of the aspects of the film that stood out to me the most was that it felt more like a play than a motion picture. No other film has made me snap out of the "I'm watching a movie" sentiment more than this one. The camera and aesthetic choices, along with the sound track, simply make this the most immersive and frankly amazing films I have ever watched. Another film(s) that I find to be special is the Kill Bill series. I don't know many other films that manage to be so overblown and exaggerated, yet do so while being taken seriously and perfectly maintaining their self-awareness.

[A comment deletion function does not exist on the forums, so here is placeholder text.]

Hello. I have been searching for the Promethium Weapons Expansion since it left development in 1.2.2, and up until this month I have not realized that the PEW project is now continued in NSI. I am very happy about this - the greatest mods eventually disappear, and it is through developers like you that this community continues thriving. We never give enough credit to those who continue projects on the verge of obsolescence. That being said, I have several qualms/questions about this mod: 1. It appears that textures are missing for multiple weapon components, such as the R60 missile. The components are covered in a black matte texture with their name written in white font. I have installed NSI via CKAN and ask whether this is an issue or these textures have not been developed yet. As I remember PEW having the same issues, I would assume for now the case is the latter. 2. I understand that combining NSI and BD Armory Weapons Extension is most likely a good solution for a modder such as you, especially with the workload that most likely comes from maintaining multiple projects. However, knowing that, BDAWE and NSI are two completely different mods, each offering different sets of components. I hope it would be understandable if I ask about what folders I must delete to remove the SciFi components in NSI, in order to only leave BDAWE (I assume simply deleting everything other than MilitaryDivision is going to completely break the mod). I also ask if it is somehow possible to segregate the BDAWE components (and others) of NSI into different folders within the mod's main directory, so that a user could simply select what elements of the mod they may wish to have. Such a structure would greatly simplify matters and reduce part bloat. 3. NSI is compatible with KSP 1.10.1. This leaves some confusion, as BDA is compatible with 1.8.1 - the version in which landing aircraft was impossible. Thank you for your work.

At times, I do wonder how much new content is directly descended from mods that have been in KSP for years. We had our Infernal Robotics and Tantares DLCs, now we have our KAS/KIS update. Nevertheless I understand that an idea is different from its implementation, and I must acknowledge that there is a large KSP community that plays stock. This update is certainly well worth it.

Hello. This is an amazing mod and I feel that switching up how propeller engines work in KSP in such a fashion is an idea that cannot be more welcome. However, you may wish to consider that, by switching to horsepower, you are effectively breaking the system used by KSP to determine flight time, thrust-to-weight, and other important factors. This greatly reduces the usability of the mod, as the user does not have any information about the engine they are using. Furthermore, as an engine's sole purpose is to accelerate an object, the most useful measurement for an engine is thrust, and the most important measurement for an object with an applied engine is thrust-to-weight ratio. Providing the power of an engine is meaningless: if I told a KSP user that a rocket engine outputs a certain number of Watts, this would mean absolutely nothing. Yes, a propeller engine rotates, but the end result of this rotation is always thrust in a certain regime. The action required to generate thrust, be it the expulsion of gas, rotation of aerodynamic surfaces, or standing on one leg and barking three times, does not mean anything when asking the question "can I accelerate this object". To add to this, information on fuel consumption, at least at a standstill at sea level and 100% mixture, is enigmatically not included in the engine parameters. One would assume this is an important piece of information, given that many pilots meticulously plan fuel consumption for every flight down to the liter. Again, I do not mean to discredit your work. AJE Extended has always been used and will continue to be used by me in the future. I am simply wondering why, as of now, one has to guess when using piston engines.

Plane-based SSTOs are difficult. I have been playing this game since I found 0.18.3 Demo on Softonic seven years ago, and I have only managed to create my first SSTOs this week. You may also wish to consider creating rocket-based SSTOs. For instance, combine a single Mammoth engine with an appropriate number of Kerbodyne S3 tanks of any length. You will get SSTOs that could lift fairly large payloads into orbit. A challenge that I have set for myself in stock or stock-sized KSP is to get all payloads into orbit with a single stage.

Small confirmation on the modded engine rule: are the small electric ductfans from KAX permissible for this challenge? I am asking this because, while they do not utilize exotic or unrealistically efficient fuels, they simply have infinite fuel as electricity is a fairly simple issue to take care of, whether with solar panel or RTG spam. EDIT: And also: I understand that this thread is old (and that I have frequented it before), but somehow I never thought of asking about the actual definitions of circumnavigation used, and cannot see valid definitions in the opening post. If I were to travel a path that would be considered a circumnavigation by any real life competitive/exploration association or body, would this automatically be considered a circumnavigation within the challenge's ruleset?

You may want to look into physicsless parts in KSP (if such parts still exist in the current version). These are parts without any mass or aerodynamic effects. If I am correct, the small radial monopropellant motor is an example of such a part, which means that you can generate an extremely large thrust while adding no mass to your vehicle. However, though the above will get you to accelerate quickly, you will be doing so within the bounds of the KSP physics engine. The "fling" that you displayed, where an object is ejected at speed away from a celestial body, is a glitch that commonly happens when the physics engine is broken. A common way to reproduce this glitch is to enable infinite fuel and accelerate towards a celestial body, reaching relative velocity before impact. My guess as to how it can happen is that an error in calculation results in a division by 0 and hence an infinite force vector. When this vector is effected onto the object in question, this can only happen within several "frames" of the simulation before a collision is no longer detected and the vector disappears. As a result, the object is propelled at a random but extremely high velocity, which depends on your computer specifications and - I would assume - processor speed. The answer to your question, then, is that you simply need to push the boundaries of the physics engine. You can spin until the craft's joints begin to stretch and parts begin to clip, create a craft that decouples a clipped part, et al. Something that would return a calculation error. The rest is random.

For me, the only thing Origin has done was give me Battlefield 3 and Dead Space when I was in grade school. They had something called "on the house" or such. Other than that, Origin simply serves as a Battlefield 3/4 installer when necessary, which is a shame since these games have now been put on Steam.

Well there's this game called Kerbal Space Program. It's in a pretty early state, they only have this white pod that seats 3 people, two fuel tanks, two engines, and a decoupler, but I think you can get creative enough with it. The graphics are very unity-like and simplistic, but I like the sort of bright red, futuristic colour scheme they have with their buildings. They modelled a whole planet as well, and a moon. Can you imagine? That's insane.

@lucho No need in worrying about reviving this, it's a repository and it probably wouldn't die based on how long it has been active. When you install a mod, I suggest you look at the version listed or the latest available version, but you probably already know this. KSP is not the type of game for which one would risk botching together mods that may or may not work. In the end of the day, chasing mods themselves isn't important. What is important is knowing that the latest version of KSP should not be considered the "default" version by any means. I too have had a period where I simply accepted the latest version and waited for the other mods to catch up, but after I got into RO a few years ago I saw that the latest version is simply a bleeding edge of new game mechanics. In short, I recommend you go to steam and revert back to a version that works with the mods you like. Then all you have to do is download the older versions of said mods.

I have recently decided to make a jump from RemoteTech to RealAntennas, being attracted by the seeming realism of the latter. I have read through the majority of the documentation listed on its Github wiki page. However, though said documentation has indeed increased my understanding of how antennae work within the realms of this mod, I nevertheless find myself in need of a number of gameplay related clarifications and general advice. As such, what follows is a list of inquiries alongside their respective explanations: 1. How can I determine a threshold for when an antenna ceases to communicate with another? As the intent of any antenna is to communicate, the variables given by RealAntennas must ultimately lead the user to a conclusion about a maximum distance within which a given antenna can communicate with another antenna. In RealAntennas, I see that this distance is a result of transmitter power, gain, and frequency used. The antenna planner ultimately produces a number that represents a data transfer rate at a preset distance (why the distance slider only reaches 1Mm is completely beyond me). How can I determine the minimum acceptable data transfer rate between two antennae? What benefit does a high transfer rate have from a sandbox mode perspective? At what point do two antennae lose connection? Note: in questions 2 and 3, I assume that communication satellites primarily perform their purposes with dish antennae. 2. How does one distribute dishes on communication satellites? If I recall correctly, an antenna can connect to only a single radio source. Firstly, I am unable to create communication satellites with hundred-dish arrays for every single object I will launch in my save. Secondly, given that I, as a player, would generally like to do things other than launch an endless number of communication satellites for months, I limit myself to eight communication satellites (four in equatorial orbit at 10000km, four in polar orbit at 10000km) per save unless I expand outside of Earth's SOI. How can I do the same with RealAntennas? 3. Dish angling. Of course, a dish must be pointed in the correct direction. This raises multiple issues. To begin, I am unsure if I will be able to launch enough satellites to blanket the surface of the Earth with good communication. Secondly, I am not sure how I can approach satellite orientation. Given that I have Persistent Rotation, I may be able to simply let my satellites constantly rotate to face the Earth. However, once in a while, these satellites will drift. This means that I will need to constantly check and reorient every single communications satellite I will ever launch. Is this true? All in all, my confusion lies in how one designs a communications satellite and how one maintains a communications network. I am unsure whether omnis or dishes are what a communications satellite usually uses to connect to its surrounding objects, and, if dishes are what I should use, I am unsure how to keep said dishes oriented correctly. Of course, I may simply be misunderstanding everything. My apologies if I come across as ignorant, Matuchkin.

Hello. I am currently using KSP 1.7.3. The mods that concern this issue are as follows: - Realism Overhaul (not likely) - ROTanks - Procedural Fairings - Procedural Fairings, For Everything Though I will be referring specifically to the process of MECO and first stage detachment, this issue occurs in every instance at which an interstage is used in such a fashion. Consider the usual launch vehicle, with an ROTanks first and second stage. Upon the first stage rests a procedural ribbed interstage. To the detachment node of this interstage is attached a procedural parts thrust plate (engines irrelevant), which itself is appended to an ROTanks second stage. The second stage has an SIVB engine mount, which is considered to be part of the tank and is the result of an option that comes with ROTanks. The gap between the ribbed interstage and second stage is covered with a procedural fairing. Now, consider the following scenario: Upon MECO, the inert first stage is detached (as per usual). Both elements of the aforementioned interstage - the ribbed interstage and the procedural fairing - are decoupled simultaneously. Upon this event, the second stage enters into a spin from which it may take minutes to recover with the currently installed attitude control thrusters. The above description occurs on all launch vehicles. Observe the example below, wherein I disable ascent guidance and simply allow the second stage to attempt to kill rotation: Of course, were I to keep guidance engaged, the RL10A4s would have ignited and recentered the stage. Upon inspection, I have come to the conclusion that this issue is a result of part clipping: the interstage fairings clip into the mount and bottom of the second stage wall. Upon decoupling, the fairings and second stage tank become two separate objects, violently snapping out of each other's collision boxes upon the slightest movement. As the volume of overlap between the fairings and tank is relatively small, this effect puts the second stage into a spin rather than ending in the usually destructive collision box glitch. I have reached this conclusion upon launching the second stage with no fairings. Note how my first attempts to alleviate this issue included splitting the fairings into two sections, decoupling them from the first stage, and placing eight retrograde thrusters onto the first stage. As you can see, this did not work. The issue is that, at this point, I am at a loss of what to do. Were this to be another issue, I would be able to alter a setting or game configuration and solve it. However, as collision boxes are a core game mechanic, do not know how to proceed. Of course, I know that this issue can be fixed, as everyone else on these forums seem to be able to create interstages that do not produce torque upon detachment. If anyone replies to this, thank you for your help.

I guess I'm just going to post what I have here. First off: the names that I have given to my vehicles are Russian, even though I use an English keyboard. For this reason, the following is a list of the abbreviations I have created, along with my attempt to spell them phonetically: RN: Raketa Nosityel - Carrier Rocket RB: Razgonniy Blok - I'm going to create a nonexistent word here because an adjective to "acceleration" doesn't exist in English: "Acceleratory Block". A third stage/tug T[number]: Typ - Type T[no number]: Tezhëliy - Heavy FS: Ftoraya Stadia - Second Stage PS: Pervaya Stadia - First Stage UFS: Udlenënnaya Ftoraya Stadia - Lengthened Second Stage UPS: United Parcel Service. That was an attempted joke. It actually stands for Udlenënnaya Pervaya Stadia - Lengthened First Stage UPFS: Udlenënnaya Pervaya i Ftoraya Stadia - Lengthened First and Second Stage ZhRU: Zhidkostniy Raketniy Uskorityel' - Liquid Rocket Accelerator (Liquid Rocket Booster) Secondly: the official dV number I use for deciding whether something can "get to orbit" is 9370m/s, which was decided based on a single launch. I am a lazy human being. Without further delay, the following is a photograph of my first launch vehicle - RN1: First stage: 5m diameter, uses a single RD171M. Second stage: 4m diameter, uses a single RL10B2. I used this vehicle to quickly launch a series of communication satellites into a 10,000km orbit above the equator, then never used it again and developed the RN2. The following image is of the currently employed RN2 series: From right to left: RN2, RN2UFS, RN2UPS, RN2UPFS, RN2T, RN2UFST, RN2UPST, RN2UPFST Core diameter: 4m. The standard first stage is designated PS151, using two RD151 engines. The lengthened first stage (on all UPS and UPFS models) is designated PS181, with two RD181 engines. The LRB versions of each, used on all T models, are designated PS151ZhRU and PS181ZhRU, respectively. The second stage uses two RL10C1-1 engines regardless of configuration. The standard second stage is designated FS1, while the lengthened second stage is designated FS2. A five meter second stage for larger payloads, designated FS3, is in the works. The next image gives you a better perspective on the second stage engines, as well as the RCS attitude adjustment rig I made for each second stage. The next image gives you a better view of the configuration I use for the two RD151/181 engines: If anything weighs 10 tons, I send it up via the basic RN2. The heaviest variant, the RN2UPFST, can put god knows how many tons into LEO - I haven't actually gauged its capacity (in one of the spoiler screenshots below, VOPZ T1 is mentioned. The probe, along with the modified second stage that was used to perform its injection burn, were both lifted into orbit successfully via the PS181 and PS181ZhRU combo without any assistance, so that might give an idea of its capacity). Edit: I just looked at the RN2UPFST, and it can launch approximately 46.296 tons. Not great, not terrible, but I may need to create a heavier lift vehicle. My next launch vehicle - the RN3: Note: the bottom half of the first stage is not gray. The whole LV is stark white, with two bands running through the center and the engine mount. I have no idea what happened with the lighting here. From right to left: RN3, RN3UFS. Both variants use a single RD181 as their first stage engine, with two LR101NA3 engines for roll control, along with one RD50MCCN for their second stages. These rockets were created when I realized that the RN2 was perhaps a bit much for five ton payloads. They are three meters in diameter. The following shows their second stage engines. Note that I keep reusing the same RCS rig: The following shows their first stages. One RD181 and two LR101s: All of the above launch vehicles, with the exception of the RN1, can be fitted with a series of orbital tugs, each of which is designed to deposit a payload at a target orbit, detach, and decelerate into a suicide trajectory: RB1: A heavy tug used to haul large payloads to high orbits. Initially created during the SOLPS T1 (Srednye-Orbitalniy Lunniy Peredatchniy Sputnik, Typ 1 - Medium Orbital Lunar Communication Satellite, Type 1) missions, for which I needed to place objects in medium Lunar orbit, and for the LPZ T1 (Lunniy Pasadotchniy Zond, Typ 1 - Lunar Landing Probe, Type 1) missions. Uses one S5.98M engine. RB2: This one is old, having been designed and redesigned for multiple saves at this point. Initial use was for hauling SOPS T1 (Srednye-Orbitalniy Peredatchniy Sputnik, Typ 1 - Medium Orbital Communications Satellite, Type 1) satellites to a 10,000km Earth orbit. Also employed for the Zemlya 2 ("Earth") mission, which entailed the transport of two terrain mapping satellites (one per launch) to 7,500km orbits. Uses one S5.92 engine. RB3: This one was designed for the Zemlya 1 missions, each of which again entailed the transport of two satellites to a 2500km orbit. Can only be mounted onto an RN3 vehicle, whereas RB1 and RB2 can only be mounted onto an RN2 vehicle. Uses one R40 engine. What follows is a montage of screenshots that shows some of the above elements in use: I tried to present this post as well as I could, or at least in the same style as those who posted before me. My apologies for the obnoxious naming schemes, the constant translations, and the fact that this post is insanely long and filled with photographs. Now that I am back, I will hopefully find myself somewhat more active within this forum.

Credit where it is due for for looking at the two final images and deciding to write "both her arms are broken".

Wow, I... somehow didn't think of that... Not sure how it will work with Earth, but I will certainly try this first and foremost.

Hello, Recently, I have decided to expand on my realism overhaul experience, having installed two mods: Principia and RemoteTech. My main question - and the reason why this thread was placed here - pertains to the methods used in order to set up satellite networks. Currently, I have a single communications satellite orbiting at a distance of roughly ten million meters, with an Ap-Pe difference of approximately fifty thousand meters. I plan to get four (or more) satellites into the same orbit, but said satellites must be positioned at certain angular intervals throughout said orbit. I believe I can safely assume that, were I to set the original probe as a target and set up an insertion trajectory that would place a second probe at a point in the orbit 90 degrees away from the former, I would not be able to rely on an "encounter" distance marker; not only is the encounter marker solely used for intercepting spacecraft, but the distance between the two "encounters" will be far too great and said marker would not appear. How would an experienced player go about this? Secondly, I ask a simple question related to a mod. Currently, mechjeb is incompatible with principia. Since physically controlling a spacecraft is not exactly realistic, I ask whether there is a mod that implements a principia-compatible autopilot. I also ask if mechjeb can somehow be altered into compatibility. That being said, I have considered learning kOS, but for some reason this non-object-oriented amalgamation of Java and some other mysterious language has never caught on to me (though I do admit that it may be the best option). Thank you for your help and understanding, Matuchkin.

Right then. Thank you for clarifying.

I would like to confirm that the 1.6.1 version of this mod functions with Realism Overhaul in its current state. My apologies for asking. I understand that modding can be extremely daunting and that this question is asked on almost every parts mod related thread, multiple times every month. I acknowledge that, as one who is being provided with a free service, I must not expect even an answer to the above question. Thank you for your consideration.

I believe that, by far, the most important addition to KSP 2 would be a dedicated preparatory mod creation team. As it stands, a large portion of the appeal of the original KSP stems from the way in which it manages to integrate a stock game experience with one of the largest mod communities in the world (that I have seen). Though KSP 2 is a heavily altered game with multiple new features, it will still exhibit the same mod syndrome that the original KSP always had, a syndrome that is admittedly crucial for the continued relevance of the game series. My proposition is as follows: assemble a team of mod creators and preemptively redevelop a series of large, expansive KSP 1 mods to support KSP 2, before the release of the latter. This will serve as a gateway into KSP 2 for the KSP 1 playerbase. I state this with the understanding that my proposition is hypocritical, as I have little programming experience and therefore cannot be a mod creator myself.