Jump to content

Deimos_F

Members
  • Posts

    27
  • Joined

  • Last visited

Reputation

0 Neutral

Profile Information

  • About me
    Rocketry Enthusiast

Recent Profile Visitors

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

  1. I know, which is why I made this suggestion to begin with.
  2. Do you mean body:geoposition? There's no "position" suffix for the "body" structure in the manual. And either way, this solution still involves invoking two different values and performing an operation to get a third value out of them. Not to mention this only works for the current position, not the more useful Apoapsis or Periapsis positions, frequently used in orbital math.
  3. Hi. Not sure where to post feedback/suggestions, but there's a really really simple thing that's bugging me a bit: For calculating certain aspects of spaceflight, most equations are written with "total distance to center of mass" variables, not "distance to surface" variables. So for example, if I'm using the Vis-Viva equation to calculate orbital speed at a point in my orbit, one of my variables is going to be the distance between that point and the center of mass/gravity" of whatever planet I'm orbiting. However there's no simple method in kOS scripts to invoke this number. For example, if I'm trying to calculate what the vessel speed will be at apoapsis, to obtain the true distance between apoapsis and the center of gravity of what I'm orbiting I need to get body:radius and either ship:apoapsis or orbit:apoapsis, add those two into a new variable, and THEN proceed with the calculations. Implementing an item in one of the structures so you could do something like "orbit:trueapoapsis" to get the true distance from the center of gravity would be a tiny yet very noticeable improvement, allowing koders to save some lines of code and not have to get two values separately and then sum them into a new variable. There are many possible ways this could be implemented. Off the top of my head I can think of two distinct ones: - make it so orbit:apoapsis returns the actual total distance to the center of gravity of the currently orbited body, while ship:apoapsis returns distance from apoapsis to surface. It's probably the "cleanest" option but might break a lot of code for a lot of people, which brings me to option 2 - make a new suffix under the ORBIT structure called something like "trueapoapsis" or "total apoapsis", so that the total distance can be gotten directly from it. (I keep mentioning apoapsis, but the implication is that something similar would be done for periapsis) Other than that, can't really think of anything else. Loving kOS despite being very new to it. Keep it up!
  4. Right now when it comes to rendering connections between vessels in map view, I believe the mod checks for all vessels within range and renders those connections, on a per vessel basis. The problem is, this creates an insane amount of visual cluttering. Would it be possible to instead have only the minimum possible amount of connections get rendered? It would be more like a tree of connections, instead of having an independent line for each individual "in range" pair generating the insane cluttering.
  5. Howdy. I read your post in the MKS/OKS thread about your "training tour" ship, and I'm wondering if you could give a slightly more detailed description of the craft. I've been trying to design something along those lines but failing miserably.

    How much fertilizer & supplies per kerbal?

    Are those engines from some other mod? Would the hydrogen engines in MKS/OKS be a viable alternative TWR/ISP wise?

    Could you perhaps grab two frontal screenshots zoomed in, so the design becomes easier to understand?

    Thanks for reading.

    Fly safe!

  6. Yep. The issue is, even if you make it really close, it's never perfect, and that's all it takes. Hit the nail on the head.
  7. Jesus Christ that's horrifying. Here I am trying to suggest solutions for a problem I run into about once every two game years, and you live like that? Damn, let's meet up or smth, you need a hug ASAP.
  8. People seem to be missing the point I was trying to make. I'm not complaining about the need to go up into the perfect orbit height. That's part of launching a satellite. Though it is indeed impossible to have a constellation in perfect sync, so the ability to tweak the SMA value for the vessel is essential. And more importantly: THIS is what I was talking about. You can set it up near-perfectly, but if for some reason you need to take control of the vessel it all goes down the drain and it needs to be readjusted. Having an SMA tweaking ability in the mod would mean I wouldn't need to stop everything, shut down the game, go find the persistent save file, back it up, open it, find one of the satellites in that constellation, find its SMA value, copy it, go find every single one of the other satellites on the constellation, overwrite their SMA values, exit the save file, fire up KSP, wait for it to load, load my saved game, and finally go back to what I was doing. And god help you if you ever accidentally switch to one of those vessels, you'll have to do it all over again. Though I quite like something I believe was suggested here: an addition to the tracking station building that would serve to monitor satellite orbits and automatically maintain them. You would need to send your satellites up with extra fuel, which would be slowly deducted over time to simulate the corrections, and when the fuel runs out the satellite can no longer be adjusted and drifts, which may create the need for a replacement.
  9. I install this mod for the added challenge of having to design, launch and setup communication relays, not for the need to fine-tune the orbit of about 12 satellites every 400 in-game days. There's a difference between a game and a simulation, and that difference is where the arbitrary realism line is drawn. There's plenty of things in this game that are not 100% realistic, but as long as there's an underlying plausibility, they are acceptable. For example, in real life the orbits of satellites are closely monitored and adjusted/maintained by dedicated staff, not NASA mission control. So to me, suggesting that micro-managing your entire satellite constellation is a realism feature makes about as much sense as demanding the game to force you to manually drive the fuel trucks up to your rocket to refuel them before launch.
  10. There's something I feel is very necessary in this mod. As is mentioned in the instruction page, getting a constellation of comm sats up in equal circular orbits is basically impossible, due to limitations of the game engine. Yes, one can launch the satellites and position them in near-perfectly identical orbits, but the slight difference in each semi-major axis, that cannot be nullified due to the low precision of flight controls, means the constellation will drift out of shape, and coverage will eventually break. The instructions of the mod suggest we go into the persistent save file, and force equal SMA values for each satellite in the constellation. However, this would need to be redone every single time you have to, for some reason, switch to one of the satellites, as their physics values stop being on rails and the SMA suffers small changes. I think it would be adequate to have a tiny button/menu stowed somewhere in the on-board computer panel that would enable setting, storing, and resetting of the SMA value of the comm sats' orbit. I'm by no means versed in Unity programming, but I would think a simple adjustment of a variable's value would be easy to do. I would like to avoid being forced to install an entire mod (Hyperedit) just to be able to manage my swarm of communications relays without having to leave the game and go save-file tweaking every time I do it. On a related note, I'm bumping a previous suggestion I made:
  11. If you want to tie your ability to progress throughout the system to the tech tree, "exploring a certain body more" basically means grinding.
  12. The cap itself, no, but the fact is, when you shove the extra data in there, the rate skyrockets. It's the amount of stored data, not the cap. The problem is, if you change the data cap to say, 1000, over half of the possible data storage amounts generate insane rates above what should be the maximum, because what is taken into account is the "number" of stored data points, not "number/total". I have tested this, and that's how it works. That's why I've been saying the equation itself needs tweaking in the module.
  13. The problem them becomes the fact that a lot of parts are essential for doing a lot of things. Entire mission profiles are impossible without many high-tier parts. So, as I said, I feel like the tech tree needs to grow, not become stretched. Interstellar mods this very nicely.
  14. Yes, money. There's a science --> funds policy, which allows you to convert 500 science into 50.000 funds. I have two labs on Minmus pumping out 100.000 funds every ~100 days. And to those suggesting the lab needs a nerf because of it easing finishing the tech tree before even leaving Kerbin SOI: that would only make sense if everything stayed the same and the tech tree became bigger. Think about it. Are you going to force people to travel beyond kerbin SOI before they unlock tier 3 engines/fuel tanks?? Makes no sense. We went to the moon in the sixties, using computers that were less powerful than the most humble smartphone. And after all these years and advancements, going beyond "Earth's SOI" is still an extremely daunting undertaking. Finished the tech tree? Use labs to generate funds. Want to take longer to finish the tech tree? I would like it as well, but for now all we can do is use mods.
×
×
  • Create New...