Jump to content

tavert

Members
  • Content Count

    1,006
  • Joined

  • Last visited

Community Reputation

107 Excellent

About tavert

  • Rank
    Rocket Scientist

Recent Profile Visitors

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

  1. I'm glad you took up the mantle of keeping this maintained, even if the calculations here so far are simplified. Porting it to JavaScript so it can be a web app is another thing I never felt like doing, but obviously makes it easier to use interactively for everyone. JavaScript JIT compilers are pretty impressively fast and clever these days thanks to constant Chrome-vs-everyone-else competition in web browsers. I don't think you need to worry too much about speed. If you want to implement the more accurate discrete-tanks version then you can always put the new code behind a checkbox to switch
  2. If you've seen one block-structured imperative dynamic language, it's not that hard to learn a new one or switch between them. Julia's closest to Lua or Matlab in syntax, and my code's not doing anything especially complicated with macros or multiple dispatch that wouldn't translate as well into other languages. JavaScript should be fine, and is the most convenient thing to work in for a web app (though maybe TypeScript, CoffeeScript, or Dart would be a little nicer once the total code size gets beyond a certain point). You can go to juliabox.org and get a shell and notebook interface to run J
  3. Depends on the image resolution and what language they're implemented in. The calculation procedure was different when I originally had it in Matlab, but you can still read the Julia code which does things in a cleaner and more efficient way. It lays out the calculation, along with SRB's and other engine types. The part stats, list of small-tank combinations, and handling of atmospheric numbers would have to be updated for 1.0 of course, but the main part of the algorithm still applies. As long as you run things in a language with a JIT compiler that can do loops quickly, it's not that much sl
  4. For small payloads and small delta-v's, that dry-mass discretization would be a substantial fraction of the differences you're trying to show. You don't have to solve the full mixed integer problem unless you also want to impose part count or cost constraints, or factor those into the objective function. For a single engine type and ignoring part count and cost restrictions, you can take all combinations of different size tanks (ignoring the larger ones assuming they're still just integer multiples within the same family), sort by dry mass, then remove any combinations where the fuel mass is n
  5. You need to fix that. Otherwise your results are flat-out wrong for small craft.
  6. Just dropping by for my couple-times-a-year visit, I don't actually plan on updating KSP or have much time to modify the code. If it's just that rocket engines now have more than 2 points in their atmosphereCurve, then it's a piecewise cubic interpolation like we figured out for the jets some time ago. Either the incoming and outgoing slopes at each interpolation point are given if there are 4 numbers, or the average slope for the 2 neighboring segments is used when there are only 2 numbers IIRC.
  7. Max thrust changes with atmospheric pressure now, right? Is it a linear relationship, or are people still testing and working that out?
  8. Not exactly a closed-form equation, but if the initial and final altitudes are the same and you want to stay at exactly zero vertical velocity through the entire burn, you can use the same differential equation just with custom initial and final horizontal velocities instead of the specific values I used here (which were based on orbital / rotation speeds).
  9. That's fair. The comprehensions in Julia don't support filters yet (hard to make that high-performance if you don't know the size of the output array ahead of time). Exceptions, well, I'll leave that topic alone. Don't know whether you saw, but there is a Julia package called PyCall.jl that lets you call arbitrary Python code from Julia. There's a pyjulia project for doing the reverse as well.
  10. I highly doubt that. It's quite a bit more sophisticated and higher-performance as a language than Python is (consider how much of the core language and standard library is implemented in Julia, as opposed to Python being largely implemented in C - sure there's PyPy but that still doesn't support numpy or much else), but of course the syntax is different so if you're more used to Python then use whatever you want.
  11. @taio in case it's helpful, here's a dumb cfg file parser in 30 lines of Julia code that I wrote a while ago: http://www.reddit.com/r/KerbalSpaceProgram/comments/23nxde/mass_optimal_engine_charts_updated_for_0235/ch0teog Consider that released under the same BSD license. Someone on reddit did some work to put in RCS engines and automatically put the thumbnail engine pictures into the legend, they contacted me via PM on reddit a while back and their modifications to the code are on github, but I don't think they finished them. There were also some bugs in the way they did fuel-tank combinations
  12. Hiya numerobis, been a while. Shouldn't be too hard, you probably don't need the fancy variable-step integrators that Mathematica uses here. Simple RK might work well enough with small steps. Interesting thing to play with here is the variable transformation of whether you want to integrate velocity as a function of time, or the other way around.
  13. The difference is down to the sidereal rotation velocity at the surface. You're right that a hypothetical orbit at 0 altitude around the Mun has orbital velocity of 570.7 m/s, whereas around Eeloo it is 595.3 m/s. But Mun's sidereal rotation period is (or was, as of 0.18.2, I don't know whether it's changed since then?) nearly 140,000 seconds, which only contributes 9 m/s to a prograde equatorial launch. Eeloo's rotation period is 19,460 seconds, which contributes 67.8 m/s to a prograde equatorial launch. So if you land from or take off into an equatorial orbit to take full advantage of the su
  14. Sorry about my lack of responsiveness here, I no longer play KSP and it's been a while since I last checked the forums. I added a BSD license to the code. Go nuts.
  15. Slight bump, but interesting thread that could use some additional clarification. Remember that engines aren't free, in mass or cost. In reality engine cost is much much larger than fuel cost, and terminal velocity is very high for rocket-shaped objects. Mass and cost don't technically matter in KSP yet unless you enjoy optimizing things, but that's a separate issue. In KSP, what are you optimizing for? If it's fuel per unit altitude for a fixed design, then you want to get as close to terminal velocity as you can for a vertical ascent (low atmosphere). But your design isn't fixed, is it? If y
×
×
  • Create New...