Jump to content

pincushionman

Members
  • Posts

    1,048
  • Joined

  • Last visited

Everything posted by pincushionman

  1. pincushionman

    Girandola

    He was probably Googling for "rocket enthusiasts," which admittedly isn't that far off. Welcome to the forums…? Good luck getting your design worked out. Though this forum is for fans of the KSP game, there's enough shared interest people will want to see pictures.
  2. Yes. Contact Steam support. They're the only people who can help you here.
  3. Well, you're on the right track then. Do note that airplanes, both in KSP and in real life, are far more complicated and sensitive beasites than are rockets. Rockets are hard, yes, but the trouble is getting them to work reliably and safely, and most of complicated bits are in the internal workings of the motors themselves (which is abstracted in KSP); conceptually the whole package is little more than speed stuffed into a tube. On the other hand, airplanes are beholden to a whole bunch of complicated, non-intuitive, and occasionally contradictory aerodynamic effects, and are very sensitive to exactly how the vehicle is made and laid out. Many, many things that go into aircraft designs even today are simply because we know they work and changing them would be an unacceptable risk. With the exception of Northrop Grumman and Burt Rutan. They laugh at convention a little bit. Basically, airplanes are slaves to the aerodynamics of the regimes in which they operate, whereas rockets' answer to aerodynamics is brute force.
  4. How are you trying to do it now? A common mistake is to try to use rudder to do it. What you want to do is roll in the direction you want to turn, and use elevator (and rudder, to a lesser extent) to control your flight path angle (that is, the angle up or down you're trying to go). The combination of angled wings and increased pitch will pull your nose around.
  5. This sounds normal if your control is coming from control surfaces. It's not necessarily about what direction you're pointing, but what your angle of attack or sideslip angle is (fancy way of saying "how far your nose is from the prograde marker"). Depending on the design of your plane, as you increase AoA, one of two things will happen: The self-stabilizing moment will increase and your control surfaces will become less effective, until they cancel out and you can no longer increase AoA. This sounds like what is happening. Your plane will flip out. If you're not sure what I mean by this, then it isn't happening. You will know if it does. In the real world, a third thing happens - stall, and it's bad. Airfoils in real life can't handle more than 15° of AoA. The AoA you can handle will also depend on speed and altitude. Ain't aerodynamics fun? Now that I've said that, though, you specify a joystick - does the same behavior occur when using keys? It should.
  6. I'm sure you mean royalty-free? Google "royalty-free music" and see what you get. Including a style or genre in the search will help - I found plenty of old ragtime recordings that way.
  7. According to the features page, the controllers are motion devices and the screen is a touchscreen. It's one of those fancy webpages you'll have to scroll through a whole lot to find it, though. I doubt it will get much play as a touchscreen, though, as that would lock you out of the connected-to-tv aspect. Would be nice if it could double as a tablet, though. And I'm not sure what to think about the multiplayer, playing up the bringing-8-consoles-together thing. At least you and your friends are in the same place, but in the past Nintendo has been the only company to insist that "multiplayer" means "you and your friends, on the same couch, at the same TV." Although you can obviously do some multiplayer (2 player) by splitting up the controller, how many controllers can pair to the same console at once?
  8. I assume you already know they need to attach to nodes on other parts, and that's what you're trying to do. A quirk with node attachment, though, is if you're looking at the end of a node attachment, it won't attach. You need to rotate the view so you're looking at the attachment from the side. I don't know what the threshhold is where it works. This happens in the VAB too, but you tend to encounter it more in the SPH.
  9. By "intended value" do you mean "a particular exact dV number" or "a particular orbit shape/apoapsis/periapsis value? Because if it's the latter, it isn't your mouse. It's because big dV is worth more than small dV - as the energy of a transfer increases, and the orbit becomes more elliptical, even small changes to the dV applied become more pronounced. Make a test sandbox, put up a small satellite with loads of dV, put it in a circular orbit, throttle prograde, and watch the orbit change. It'll start off slow, but speed up little by little, but you'll convince yourself it's not changed that much. Then it'll be faster but still OK, but then it'll all of a sudden take off to infinity.
  10. Because there is both a "minimum" required KSP version and a "maximum" version supported in the listing. I believe these default to the same value. I've seen some authors future-proof their listings by stating their max version is 1.X.99, but that is a gamble.
  11. You could fake it by only doing it when "flying low" over "water" or "shores" biomes within a certain latitude and speed range. The real killer would be determining exactly which part edges cause this effect.
  12. Binary pairs come in a wide variety of size ratios and distances. There are bound to be some with Lagrange points even within just this galaxy, likely all with capured bodies of one size or another. As for the galaxy at large, it's more of a "gravity soup" than isolated point masses, and orits as we know them don't really happen.
  13. So their space phone station doesn't catch fire. I kid a little, but in all seriousness, these are man-size batteries. And for all of our advances in battery tech, they are still largely vats of chemicals that release stored energy by controlled corrosion of the metallic parts inside. There is literally nothing in there that you wouldn't rather have outside instead of inside, impinging on and potentially contaminating (or worse) your living space.
  14. I haven't been able to find that yet, myself, but I also hanen't looked very hard. But you may want to search settings.cfg for any instances of "dock"; there may be an unused hudden keybind in there somewhere.
  15. It's a conversion factor, and it's to have a measurement of efficiency that's independent of your units system. It's actually not 9.8, it's g (standard acceleration from gravity at the Earth's surface), expressed in whatever units the rest of your measurements are in. So in metric you always use 9.8(0665…), regardless of what the actual local gravity is; in FPS it's 32.174, in IPS it's 386.1.
  16. Part of my comment didn't emphasize enough that China will get better at building jet engines by building more jet engines. Just like the rest of the engine makers.
  17. Because a big part of manufacturing these kinds of things successfully is in the manufacturing techniques, which are harder to steal because they aren't just drawings and documents? There's this prevalent attitude in management that documenting everything about what you do automatically makes you more successful as a company, but the reality is in successful companies there's still a huge ammount of tribal knowledge that can only be passed on by experience.
  18. Right-click the game listing in your Steam library and select Properties. In the window that pops up, select the Local Files tab and click "Browse Local Files." It is recommended that you copy this whole folder to a new location and put mods in that copy instead of the Steam one. To run such a modded install, you can either: Browse to that folder and launch from there Add the new location to the Start Menu apps Pin the new location to Start point CKAN to that directory and use CKAN as your KSP launcher (recommended) in Steam, in the File menu, "Add a non-Steam game" and point it to the new location.
  19. Yes, the maximum fuel and oxidizer flow rates are shown in the engine descriptions, stated in units per second. The unit mass of each propellant can be worked out by comparing tank capacities and masses.
  20. I dunno, man, Keep Talking and Nobody Explodes is in the category, too.
  21. I've re-checked my math using a fresh pull from HyperEdit v 1.5.3 in KSP 1.2.2, and it's pulling different values for Sun surface gravity multiplier (1.746846561) than what I had previously pulled using HyperEdit 1.5.2 in KSP 1.2 (1.7462500333786). Using the newer value I get a sun GM of 1.17233E+18, which in turn gives me a year of 426 d, 0 h, 32 m, 24.6 s, which is what we want. Looks like I'll be doing a fresh pull of all the body data; I haven't re-computed the elliptic orbits yet anyway. However, it brings up another quirk - the GeeASL HyperEdit is pulling for Kerbin (the surface gravity multiplier) is 1.000341605, where you would expect it to be 1.0. If you multiply this by the (new) standard gravity of 9.80665, you get...9.81. Makes you wonder why they even bothered to change the g0 constant in the game, if they were just going to hack the gravity back to its old value. It's obvious they adjusted the M values of the planets to get the old GM values back regardless of the G value. I haven't checked to see if any of the engine performance measures have changed as a result of this (and probably won't), that's the only other place where I remember this showing up.
  22. I've been working on an orrery for the Kerbol system and I've run into a couple of issues with regard to the length of Kerbin's year. Using values from the wiki and extracted from the game (suppposedly) using HyperEdit, I've managed to calculate this year length: Parameter Symbol Value Source Gravitational Constant G 6.67408 ∙ 10-11 m3/(kg ∙ s2) From patch notes Acceleration at Kerbin SL g0 9.80665 m/s2 From patch notes Acceleration at Sun surface (in g’s) gS,g 1.7462500333786 ∙ g0 Extracted with HyperEdit Acceleration at Sun surface (m/s2) gs 17.1248629 m/s2 gs,g ∙ g0 Radius of Sun rs 2.616 ∙ 108 m From wiki / verified in game Sun gravitational constant GMs 1.171932456926 ∙ 1018 m3/s2 gs = GMs/rs2 Kerbin SMA rk 13599840256 m Extracted with HyperEdit Kerbin orbital period Tk 9205116.471 s T = 2π√(rk3/GMs) This works out to a Kerbin year of 426 d, 0 h, 58 m, 36.471 s. And there are two problems with this value. First, I can't replicate this in-game. I placed a satellite into a 13599840256 m orbit around the Sun using the debug menu orbit editor and compared the apoapsis and periapsis of this orbit, and I get a difference of 213 d, 0h, 16 m, for an orbit of 426 d, 0 h, 32 m. You'll notice my math gives a different result by some 27 minutes, give or take a minute (.0173%). This may not seem like much, but given the precision needed for successful small-body encounters in KSP, accuracy to the game's physics is key. So one of two things is happening: either my math is wrong or the values I'm using for my calculations are. Please check my math, and if anyone knows any methods to determine these values correctly, I'm all ears. Second, you'll notice this isn't an integral number of days, no matter which one is used. So, like Earth, there should be leap years. Given my math above, the sequence would be one extra day every six years, except for the 258th year of each cycle (like how on Earth we have one extra day every four years EXCEPT for years divisible by 100 (like 1900) UNLESS it's also divisible by 400 (like 2000)). But given the year length in-game is a little more than 426 d 1/2 h, it would be one extra day every 12 years, except on the 180th year of the cycle. Or something odd like that. But I've timewarped for 15 years and saw no evidence of a leap day in any of those years. Does the game simply do 426-day years and let the "new year" point drift backward by 1/2 hour each year? Now, I do understand that the math as it is now is going to be dang close. However, objects in-game are moving faster than in my model. I'd like to be able to plot user-defined trajectories as well as the planet positions, and if the orbital motions are off by even a small amount, the data the tool gives about encounters is going to be bad information. Plus I'm a little obsessive about accuracy. Either way, I'd like to avoid this kind of error if I can. Thanks in advance for your help!
  23. We'll need a picture of the un-coupled ship to know for sure, but it sounds like the payload-side port has been rotated 180 degrees (as in you rotated it "forward" twice to get it to point the right way) and you're using it as the control point (but the axis is in the correct direction). On the Clamp-O-Tron there is a line on one side of the face which indicates "down" in the docking port's frame of reference. If this line is on the forward side of the port (the line is closer to the cockpit), then when the "control from here" is on the docking port, the cockpit will see the control inputs as: Port pitch up -> cockpit pitch up Port yaw left -> cockpit roll left Port roll left -> cockpit yaw right Port translate up -> cockpit translate aft Port translate left -> cockpit translate left Port translate forward -> cockpit translate up If, however, the line is on the aft side of the port (further from the cockpit), then the cockpit will see: Port pitch up -> cockpit pitch down Port yaw left -> cockpit roll right Port roll left -> cockpit yaw right Port translate up -> cockpit translate forward Port translate left -> cockpit translate right Port translate forward -> cockpit translate up I've emphasized the directions that get "changed" in each case. Now, if the line is on one side or the other instead, it's even more catty-wumpus (I've done this). Does that sound like what's happening? Oh, and there is no "male" or "female" for the stock docking ports - they need to face each other and it appears you've done that correctly, at least.
  24. The simplest thing to do is to use two Junos, one on each side of the fuselage. Just like on a real-world business jet.
  25. Wait wait. I don't know anything much about the code, but is the problem that "all the transformations reference the same axis (and it would be a PITA to find them all and change them to reference an arbitrary cord)", or "in all the transformations, the transformation to cord 0 is implicit in the math?" Because one of those problems is way more approachable than the other. After all, we already jump around between coirdinate systems, what with SOI changes and the whole shifting-origin behavior.
×
×
  • Create New...