• Content Count

  • Joined

  • Last visited

Community Reputation

488 Excellent

1 Follower

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hmmm... looks fine. Are you coming in at an angle? If you select "control from here" on the docking port on the controlled vessel and "set as target" on the port of the other vessel, then the target marker on the navball with be in the center when the target port is straight ahead of the local port. If you do that on both vessels (switch between them with "[" or "]") then you can see if they are aligned correctly. There is also an IMHO useful guide here: (This guide uses a mod to check display the alignment on the target vessel, I flip between the vessels to do the same thing.) P.S. One thing about the vessel(s): you don't need to attach the RCS thrusters to the monopro tanks, you can attach them anywhere on the vessel. And if you space them out more evenly around the center of mass of the vessel then your vessel will not rotate (as much) when you want to translate or translate when you want to rotate.
  2. Hi @The7O2Guy, welcome to the Forums. As @5thHorseman said, many things could be wrong. One thing I did often wrong in the beginning was that I was trying to dock two docking ports of different sizes to each other, i.e. I was trying to dock a "normal" clamp-o-tron and a junior-sized clamp-o-tron. When I did this then the magnetic forces pushed the two docking ports apart instead of pulling them together. (A bit like real life magnets: get the north pole of one close to the south pole of another and they will pull each other together. Get the north pole of one to the north pole of another and they'll push each other apart.) Switching off RCS and SAS just before docking is IMHO a good idea (aka: I also do that), but that doesn't usually cause or prevent being "kicked away" from the docking port. Having SAS on can keep your craft from being properly aligned by the magnetic forces and thus keep you from actually docking, but then you typically still "stick" to the port without actually being docked. Docking at too fast a speed will result in the two craft bouncing off from each other, but 0.1 m/s is definitely not too fast.
  3. Well, that was the message that the tone of what you wrote conveyed to me. I believe that reporting bugs and reminding the developers of unfixed bugs after a new release in unconfrontational tones is more effective than b*tching about things. Probably not effective enough to get everything fixed though, but considering the number of longstanding bugs that also affect the Windows platform I don't believe that this will change. So my summary is: "because the middleware support for Linux is buggy". Kind of what I was afraid of. Thanks!
  4. About the KSP on Linux issue: KSP works fine on my Linux computer. Granted, I don't have a joystick so the missing support for one doesn't affect me. But the graphical issues - that I know of - don't make the game unplayable. And some Linux specific bugs do get fixed, although with the alacrity that SQUAD applies to all bugfixes. So claiming that Linux isn't supported at all is unfair. I also think that just complaining about how bad it all is and that nothing works is not going to motivate SQUAD to do a better job at supporting Linux.
  5. Coming back to that: I just did a test with using the BG robotics parts to cover the senior-sized docking ports. My test vehicle looks like that (with the ports closed): As you can see it has groups of five rings of docking ports, each ring has four pairs of docking ports where one is the actual port and the other is the movable "cover" of the port. The craft in the image has three such groups, so 3*5*4*2 = 120 open ports when all of the pairs are in the "open" position. And this is the lowest number of groups where I start to see yellow times, although sometimes they flicker green and there is no significant lag. With four groups (i.e. 4*5*4*2 = 160 ports in total) I see measurable lag when they are open (10 s game time in 15 s real time). If I move all of the "covers" to the closed position the lag (and the yellow times) go away. So for my machine about 100 open docking ports seems to be the boundary for "absurd" (Btw.: Ryzen 5 1500X, 16 GB RAM, Ubuntu 18.04) P.S. Due to bug #24435 action groups to open all these doors don't work. (But I guess you - @XLjedi - know that.)
  6. Well, my guess is that with 19 open ports (and a few hundred parts in total) you can measure a difference between having the ports open or not. If you actually notice the difference in normal gameplay is another question. Although now that I re-read your message, 19 senior-sized ports plus a comparable number of normal and junior-sized ports is at least at the edge of what I consider "reasonable". The biggest station that I built has 8 normal docking ports, 4 junior-sized ports, and 5 senior-sized ports open and 13 more senior-sized ports that are attached to something. (And it is already pretty laggy, but it is also the biggest - in size, weight, and part count - object I built.) As you can see from my test, 288 open docking ports is clearly on the absurd side of the scale.
  7. That's also the impression that I have from my tests. Yes, there is an effect. But if you only have a reasonable number of docking ports then this effect isn't so serious. And from a programmers point of view: I can well imagine that in an older version of the game each docking port tested every part within physics range, but that at some point a dedicated list of docking ports was introduced so that now only that list needs to be searched.
  8. O.K. I just did a quick test with a dummy craft with 288 shielded docking ports (out of 295 parts in total). There is indeed serious lag when all those shields are open, compared to when they are closed. Another test: similar craft but with 288 normal clamp-o-trons covered with a nose cone each (583 parts in total) -> the time display flickers green and yellow, and 10 in-game seconds took 10.32 seconds real time (timed manually on a stopwatch(-app on my phone)) Same craft but without the nose cones (so 295 parts in total) -> the time display is a steady yellow, and 10 in-game seconds took 28.92 seconds real time (Well, a bit less. I got bored. ) So, yes. There definitely is an effect! Edit: Another test with a craft with 8 docking ports (uncovered or covered with a nose cone) and enough fuel tanks to bring the total number of parts up to 885 resp. 877 parts showed no significant difference in the lag between the two craft...
  9. AHHans

    RP-1 as a DLC

    Highly refined kerosene, a kind or rocket fuel: RP-1 on Wikipedia. Among other uses it was used in the first stage of the Saturn V and is used on the Falcon 9. Why SQUAD should buy that is beyond me. Maybe the OP wants them to build actual rockets?
  10. I don't know. Why don't you give it a try and let us know about the results? (Then I don't have to do it myself.)
  11. I don't have much to add, but here are my 0.05€ to this topic: Normal connections between two parts are a bit "bendy", i.e. they can move against each other when the forces become large before breaking off. If you set this to true, then the connection to its parent part will not move but will just break when the force becomes too large. As in real life, this movement acts like a spring during an impact (e.g. a plane landing) and usually reduces the maximum force between two parts by spreading out the acceleration over a longer time. So rigidly attached parts tend to break apart on even lesser impacts. But they don't shift around during lower accelerations. (I never use that option in my craft.) Two things about the sides of a fairing: one is that the number of sides only actually gets changed if you edit (or create) the fairing after changing the number of sides in the PAW. (So, yes, if you just change it in the PAW nothing will happen immediately.) The other is that the fairing pieces can collide with your payload after deploying the fairing. (This is even more of a problem when you use "clamshell deploy".) If your payload is not cylindrical but e.g. has a 4-way symmetry then setting the fairing up so that the pieces are on the sides and not the corners - and thus are ejected away from the corners - can keep your payload safe from collision. (I figured that out the hard way when a fairing kept damaging two tires on one of my rovers when it had three sides.)
  12. I don't know how FAR does things, but the way the stock engine works flaps or spoilers just don't make any sense. Any aero-surface will always cause lift, even if you completely hide (clip) it into another part. So you cannot change you wing area by moving parts into or out-of each other. Similar for spoilers: you cannot disrupt the lift of an aero-surface by putting another part into the airstream around that surface. (Because there is no airstream...) You can make airbrakes, as you already found out. You can also increase the pitch of some aero-surfaces to generate more lift without pitching the whole craft up, but as you say that's not the same as actual flaps. And, well, elevons are just control surfaces with both pitch and roll control active. (But in my experience it is better to have some control surfaces dedicated to only pitch, because otherwise you'll loose pitch trim as soon as you enter roll commands...)
  13. IMHO it is best for all kinds of rotors (in KSP) to keep the RPMs constant and control (whatever you want to control) by changing the blade pitch. But if I understand you correctly you also arrived at that conclusion. If you only ever need 10% rotor torque, then I'd suggest to lower the motor size in the VAB/SPH. That way you don't need to carry unnecessary weight around with you. And finally to your actual question (yes, yes, I do get to that): with the new changes in 1.9.0 you can indeed get classic main-rotor / tail-rotor helicopter to work. If you set the blades on the main rotor to do pitch and roll control and the blades on the tail rotor to do yaw control (with the control direction to the front), then SAS can use the tail rotor to keep the craft from spinning. Even without a counter-rotating rotor setup. I put a small test helicopter that does this on KerbalX: Basic Helicopter In a heavier craft (with a more powerful and thus torque generating main rotor) you may have to "trim" the tail rotor to keep it from slowly rotating. You can either do this with the manual trim as @OHara explained, or by setting the deploy angle of the tail-rotor blades to an appropriate value.
  14. Hi, welcome to the forums. KSP should run fine on that machine. KSP is in general more CPU intensive and less GPU intensive than other games. And it really likes to have RAM, so the 16 GB RAM help a lot. You'll see some slow-down when you fly large craft with many parts, but a faster CPU will "only" push that limit up to somewhat higher part numbers. So it's IMHO really only a gradual difference. I can't say much about the GPU, but I think it should also be fine. You may not want to turn up the "Terrain Shader Quality" to ultra in the settings, though.
  15. Ah, welcome to the club! The battery extension for my Jool 3 (Vall, Pol, and Bob) rover/lander is currently on its way to Jool. (It has an RTG, so it surely doesn't need big batteries, does it?)