Matuchkin

Members
  • Content Count

    1,503
  • Joined

  • Last visited

Community Reputation

1,549 Excellent

About Matuchkin

  • Rank
    no.

Profile Information

  • Location Array

Recent Profile Visitors

7,569 profile views
  1. 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.
  2. 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, and less of an immature prick - as I was before I left.
  3. Credit where it is due for for looking at the two final images and deciding to write "both her arms are broken".
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Thank you for the heads up, with the coming KSP-2 I decided to take a look back. Perhaps I will return to this forum and join this fight.
  9. Understood. I initially thought that it would work when I read the [1.4.5] tag in the thread title.
  10. I recently installed Realism Overhaul on my device, using KSP version 1.4.5. Everything seems to work out well, but my problem lies in the material. Not only does this version of KSP no longer support the large stock crew module, but all other goto mods (tantares, SSTU, et al) also completely lack support for crew cabins. This leaves me unable to perform manned missions in Realism Overhaul, and as a result I would like to question whether it is possible at all to obtain a multi-crew capsule fit for RO. Thank you for your help.
  11. As much as we have progressed, we should all remember the version that would forever be in our hearts. 0.90, we shall never forget thee.
  12. Reporting to this long-lost home from CloudyNights. What mounts do you guys use for tracking?
  13. I will be frank, these are very cool designs - almost like a combination between a cheesy space opera and something Gru will fly, but much smoother and sleeker. I think my favorite will be the Geddy.
  14. 4187: You fall into a coma for exactly 30 years (94,670,856 seconds). You then wake up, yawn, restart your heart, and continue to the next floor.