Jump to content

Nittany Tiger

Members
  • Posts

    307
  • Joined

  • Last visited

Everything posted by Nittany Tiger

  1. I know. Many missions going to the outer planets do dark-side flybys of planets like Earth and Venus. My point is that this is what a dark-side Venus flyby looks like in stock patched conics. Leave Earth, swing by Venus on the dark side, and you somehow end up dipping below Mercury's orbit. What it's supposed to look like is: That's the plan given on the first pages of the book (in my copy). Apologies for the bad quality of this pic. Only photocopy I could find (Unless I photocopy the one from my copy). I think you can at least see that the Venus flyby leads to a Mars intercept. If you're curious about the dates, Earth departure is March 22nd, 1985; Venus flyby is September 8th, 1985; and Mars arrival is March 25th, 1986. When I actually looked this problem, I did an experiment with where I placed a maneuver node just outside the Venus SOI at ship departure and played with it until I got a Mars encounter. So Venus does give Ares a substantial velocity boost on flyby. Furthermore, without the boost, in stock patched conics, the arrival date at Mars is always in July. With the correction above, the arrival date at Mars is March 22nd, 1986. That's why I concluded KSP's patched conics is missing something with planet-craft interactions during flybys. Planets don't give craft the proper velocity kick. They just change the direction of flight. In real life, planets must somehow give spacecraft a velocity kick when the spacecraft falls into the planet's SOI, and I feel it has to do with the planet's orbital velocity around the sun. That's what my research tells me. I called it momentum transfer because I thought the planet was giving some of it's orbital momentum to the spacecraft (and the spacecraft is probably giving a very tiny tug on the planet). It doesn't violate conservation of momentum because in the spacecraft-planet system, the total momentum of the system does not change. It's akin to an elastic collision, but with planets and gravity fields, and one site equates flybys to elastic collisions to set up the conservation of momentum argument. This was my whole point in saying stock patched conics is missing something with flybys, and what Prinicpia might provide. Neither system has to give a momentum change to the planet because it's so small that it's negligible on time and space scales of this game. Nonetheless, it seems significant to the spacecraft. Hope this clarifies my understanding of flybys, but this is possibly off-topic of the thread. My original question was will Principia allow me to do the opposition-class Mars mission as done in Voyage with a dark-side Venus fly-by and 30 degree velocity vector change boosting my craft to Mars and not Mercury?
  2. I meant under conservation of momentum. I'm aware of the laws of physics, and I'm also aware gravitational fields are conservative, so in the body frame of reference, vin = vout (because no net work is done on the craft), or the speed you enter the SOI in is the speed you leave with. I know in stock, what matters more in flybys is the direction in 3D space and periapsis at flyby. It could be possible that the flight plan in Voyage is wrong, because my first instinct was that if you flew by Venus on the dark side, you should exit with an orbit going closer to the sun, not farther. You'd need to fly by the light side of Venus to get the boost to Mars. Flying by the dark side of Venus, getting a 30-degree velocity vector change that would result in an inward-bound orbit, and then going to Mars just didn't make sense without Venus giving some sort of acceleration to the small craft during flyby. Might just need to do some experiments with KSP RSS, both with Principia and stock patched conics, and do some research to see how Venus flybys are used in real missions. I think Galileo and Cassini used Venus flybys to get to the outer planets.
  3. I'm aware how gravity assist work in stock. I see them as gravitational bodies changing the direction of a velocity vector but not the magnitude. I'll still watch the video again to be sure. I just need proper momentum transfer for an opposition class Mars mission via the Voyage novel. I know you can do the mission with patched conics, but you have to fly by Venus on the opposite side to get the velocity vector change needed to reach Mars. With momentum transfer, you can fly by the dark side and get a Mars-bound trajectory that's shorter, and a dark side flyby of Venus is what happens in Voyage. I do want to test and see if craft velocities obey the math in this link: http://www.mathpages.com/home/kmath114/kmath114.htm
  4. I do wish Principa worked with Hyperedit, but I'm glad it works somewhat with the stock orbit editor. I need the ability to place objects in LEO in any inclination and LAN. I haven't confirmed this yet, but I suspect KSP's patched conics doesn't do momentum transfer during planetary flybys. In other words, if you fly by a planet, your entry and exit speed out of an SOI is the same if you don't accelerate. The only thing that changes is direction. In real flybys, you actually gain velocity from the planet's forward motion. I'm hoping Principia's gravity model does capture momentum transfers.
  5. How hard is it to make science definitions for the new moons? Possibly could make some up if they are just config files or buried within the Kerbalism config files. I also wonder how hard it could be to make Kerbalism solar panels work for two stars? If it's just an issue of solar panels, I could live with that. Galileo seems to imply that Kerbalism for GPP is malfunctioning for more reasons that just solar panel issues.
  6. Yeah. I read that Kerbalism support was temporarily removed from GPP. I think the latest GPP has new planets, so dunno how an older version of Kerbalism will handle that.
  7. @OhioBob This thread is old? It's still active. If you have an idea for my install, go for it. Actually haven't finished building it.
  8. That's why I wanted to post the whole script. To give context so you can see what my script does. I did do a LIST PartModules for the FASA Apollo LES, and it showed something called "DecoupleModule," and I didn't see a "Decouple" in the list. I tried both DOACTION("DecoupleModule",1) and DOEVENT("DecoupleModule"), and kOS still complained to me. I read the kOS Wiki before this, and it mentioned the right click menu actions and actions that usually go in an action group. The part has a decouple action in both cases, but when I use DOACTION or DOEVENT, kOS will either give me an "argument is out of range" error or "This can't be done with type Engine." The latter shouldn't happen because a part of type Engine should be able to use structures of type Part and PartModule. I'll try @Pand5461's solution. The way I read the kOS Wiki, I thought that LES:DOACTION or LES:DOEVENT would work. EDIT: Yeah, I was just using the DOACTION and DOEVENT structures improperly. Toss that to me still learning kOS and the kind of programming it uses. I only program as a hobby and am largely self-taught. By the way, does kOS have the equivalent of a DO{} WHILE loop, or is that just the ON{} and WHEN THEN {} loops?
  9. I didn't know if I was supposed to post the whole script or part of it. Sorry.
  10. Sorry about that. The line in question is in AresLaunchDisplay.ks. ELSE IF (J2S:IGNITION = FALSE) OR ((2)*(9.8 * J2S:ISP * LN(SHIP:MASS/(SHIP:WETMASS - MSII:WETMASS))) > 2881) OR STAGE:NUMBER > 19 { //dV calculated here is 400 more than possible stage dV. PRINT AbMode[3] at (la,0). //AG27 on. LES:ACTIVATE. LES:DOACTION("Decouple",1). } This is the line that, once the Saturn VB goes above 80km, it's supposed to jettison the Launch Escape System and display "II" for the abort mode. The LES variable is the variable set in the main script, and it's the Launch Escape System given the name tag LES in the VAB. SET LES to SHIP:PARTSTAGGED("LES")[0]. EDIT: I should mention that I used to tie the LES jettison to an action group (The AG27 on statement), but with the latest Remote Tech and AGX for KSP 1.2.2, the action group won't trigger in the script even with Remote Tech disabled in that save. That's why I tried to trigger LES jettison directly.
  11. I had to drop KSP-IE when IFS updated and started causing all of my craft to vanish. I did download a standalone Alcubierre Warp Drive mod from @RealGecko that apparently installs just the KSP-I warp drive without the rest of the stuff. It stinks because I really like KSP-I's heat and customizeable engine mechanics (at least when I last played it when FractalUK was developing it). In the meantime, I've been working on my own tech tree for this install. https://docs.google.com/spreadsheets/d/1ecyT1JK3UAzalXNQ314C1civxc3aqI2mL9B77uaH0IM/edit?usp=sharing I was hoping to make a more realistic progression about BDB parts along with making early-game progression not be too fast. Therefore, I got the idea of splitting each rocket in the BDB pack into its own node. I also want to add a whole branch for cryogenic engines later on. Other than that, it's just the Community Tech Tree. However, trying to make a tech tree is tedious and I put this on hold for now. I might see if Cold War Progression Tree might be a better fit for what I want in this playthrough. Also, basing early and mid-tier progression about BDB might mean trimming parts that are either redundant or might be cheat parts.
  12. Shouldn't Get PART:MODULES work for an engine type part? Been trying to debug why LES:DOACTION("Decouple", True)*. or LES:DOEVENT("Decouple")* doesn't work for this launch escape tower though it has a decouple module (it's a FASA Apollo LES). It also says in the kOS documentation that part suffixes work for engines. Therefore, I should be able to activate the decoupling feature of the launch escape tower even though it's an engine type. I have tried to list the modules for the part, but I'll get "argument is out of range" errors as if there are no modules for the part I guess. *I do have tags set properly.
  13. I got the Saturn VB version 2 flying. I had to trim some weight in the Ares Command Stack because the RSRMs aren't as powerful as the UA-1564s. Meant less fuel in the Apollo CSM, less fuel in the OMM, less RCS fuel in the Ares Mission Module, and rebuilding the life support system with CO2 filters and a water recycling system. I did manage to get the weight down enough for the new Saturn VB to make orbit. This also means more dV for the Ares itself when it goes to Mars since the only changes so far to the Ares Propulsion Module are the addition of heat pump radiators to prevent boil-off.
  14. The chat issues do finally seem to be gone. I know it was frustrating for me not to be able to make posts. I did try clearing cache and disabling my adblock before. It seemed to work sometimes. I am glad the problem is corrected. I was scratching my head and trying almost everything under the sun between myself and mod trying to fix the issue before he brought up this post. Thank you, forum team, for getting things fixed.
  15. Mini update just in case I can't make one due to having the forum bug going around. 1. Ported Saturn VB model over to KSP 1.2.2 with RSS+RO. It's a bit wobbly. Might have to rebuild it, or part of it. (EDIT: Forgot KSP 1.2.2 had autostruts). 2. Found out from the book that the Saturn VB in Voyage did use the Space Shuttle RSRMs, or at least something like them. Therefore, I have some rebalancing to do. 3. Had to abort my last attempt at the mission. A problem I thought I fixed way back hit me, which is LH2 boil-off. I could swear I set my tanks to cryogenic, and I tested cryogenic FASA parts and I could swear they didn't boil-off the LH2 within days. (I do have a mod called Heat Pump for this now).
  16. It does, but I was practicing landing on Mars so I didn't go all the way to Mars to make cheesecake-flavored Kerbal pancakes. Hyperedit became my simulator for most of the Ares mission. I still fudge up landings in stock KSP, so I wanted to make sure I could pull it off in RSS. It did give you some feedback on how the craft flies in RSS, though I didn't use the ballute and chute due to trying to stick to the book's version of the landing. Using airbrakes throws that out of the window, but still fun to try to land the MEM without the chutes and ballutes. I have a procedure down to the point where I could have kOS do it for me. Voyage's MEM is pretty much the NAR MEM except with metylox fuel (CH3/LO2 instead of CH3/FLOX) and no chutes/ballutes. From what I've read in the book, everything else is the same. I still need to read up on the SRBs for the Saturn VB, because if they are 128" SRBs, then I might need to trim some weight. I might need to anyway because I suspect there's not enough dV in the Ares propulsion stack to do the mission, and my Ares stack is, as far as I know, built exactly like the book specifies.
  17. I didn't do much other than test your craft in RO 1.1.3. You did all of the coding. Still nice to help someone out.
  18. I could just patch your MEM to 1.2.2 myself so you can focus on 1.3. If it's a MM config, I can do it myself. I've been learning to use MM more with a custom tech tree mod I've been making, so I can update the DEM RO patch to 1.2.2 if needed so you can focus on the 1.3 patch. I don't know what's different between RO for 1.1.3 and RO for 1.2.2., but I'm confident that either the MEM patch will work find as-is, or it'll just need some tweaks. Also, some of the KSP modders tell me the Saturn VB was supposed to only have 128" SRBs, and they were more akin to the RSRMs than the Titan UA series. I need to thumb through the book myself to verify this, but if this is true, it's going to require new launch tests followed by potential changes to part weights and the kOS script. Fun. I might just make different versions of the Saturn VB with different SRB configs to see if they all can fly with the Ares command stack.
  19. I know about that option. I turned it on in my stock playthrough. What I was thinking about was having more tech nodes after the start node for different rockets of the BDB pack. This is instead of just shoving a bunch of the parts into one or two stock nodes. So for instance, I'd have a node for the BDB Vangard, and then another for the BDB Redstone, and so on.
  20. I came up with an idea for a BDB-centered tech tree based on the BDB universe and real progression of rocket tech in the US space program. It doesn't include nodes everything in the BDB pack, and it was built largely on the information in the BDB manual. It also doesn't include nodes for stock parts. https://docs.google.com/spreadsheets/d/1aINwkVDKztzuvfpryEJ2MelrBx4Z3J_ceJ3c6bFh6jg/edit?usp=sharing I feel this might favor a gameplay style that was slower than normal, meaning no Munar missions until tech level 7. However, that can be changed. I introduced a lot of "intermediate" tech levels in my idea, and this can facilitate tech progression that doesn't end when the player is able to unlock the parts for an Apollo-style Munar mission. It also includes a hypothetical tech node for Saturn V MLV rockets, though many of these rockets can be built with Titan III and Titan IV boosters. There also needs to be a tech node for Skylab. Again, this is just a rough proposal and not a final idea for a mod which I would create if anyone was interested in a BDB tech tree.
  21. Currently using Module Manager to construct a custom tech tree using CTT. Right now, just shifting parts around so that I can't reach orbit at tech level 0. I don't want to be able to do unmanned orbital launches until tech level 1 and manned orbital launches until tech level 2. Also considering new nodes for cryogenic engines. Overall, trying to go for the semi-realistic tech progression. EDIT: Also considering creating separate tech nodes for each of the BDB rockets in @CobaltWolf's pack. Use science and funds to unlock each rocket instead of getting a bunch of them in one node.
  22. Going to try the latest stable 1.3 build with GPP and Kerbalism.
  23. Ahh. Thank you. I just made the pull request then.
  24. PR? What's that? EDIT: Oh. Pull request? I'll have to figure out how to do that.
×
×
  • Create New...