Jump to content

rasta013

Members
 View Profile  See their activity

  • Posts

    664

  • Joined

  • Last visited

 Content Type 

Everything posted by rasta013

  1. rasta013
    @MaxL_1023 @CatastrophicFailure @Aelfhe1m @Gilph @astroheiko Man I wish I had more time this week to seriously dig into this...my brain is about to explode with hypotheticals... Something I came across and have not had a chance to work through the math on yet but it has direct bearing on this conversation. There's n upper limit on how much dV can be obtained from an assist but I've never worked through it before. (never occurred to me to even try maximizing this in KSP until now...) https://physics.stackexchange.com/questions/128356/gravitational-slingshot-maximum Now, this is is of course RL so it's never going to translate directly but I think it's going to have enough of an effect on this kind of assisted transfer to make a difference on the Race to Grannus...also...what are the parameters here? Fastest transfer vs. insertion vs. return flight will have differing best case scenarios and we all seem to be discussing different kinds so far... And do I smell a challenge in the making here?
  2. rasta013
    This is your best bet. I have a saved parts directory from DMOS that I move in once I install PP to trim them out as well. If you do a lot of this you might take a look at Janitor's Closet since it allows you to both prune or hide and anything hidden can always be restored later...
  3. rasta013
    Yup. They were removed because of some small issues arising around them. In the next update the reports will start making their return and each update after that I will be adding more and more until all stock experiments are completed for all bodies in GPP. This is obviously a long term project but they will be returning.
  4. rasta013
    Indeed. Another good suggestion and likely would result in a quicker route than Otho/Nero - again...haven't plugged any of these in yet and kind of spit balling here but @MaxL_1023 is likely on to the best idea with this one and past experience would indicate it's a good chance.
  5. rasta013
    Well - I use the GUI anytime it's there since I generally know exactly which nose/mount I'm looking for and can get to it a lot quicker using the GUI. That said, if it's easier to do it via slider and results in less work/maintenance welllll..... Convenience is a beautiful thing but I'd sacrifice it in a heartbeat if it's easier for you since the selection ability is the important piece, not the convenience.
  6. rasta013
    No I haven't but to be honest, I also haven't toyed very heavily with it for the long intercepts. Typically, I pull KSPTOT when I want to plan complicated multi-body fly-bys Voyager style. I've also used it for a few out-body shots for gravity assists in early points of careers to take advantage of physics instead of tech, but again that's a multi-body approach use as well. AND I haven't made an attempt yet at one of these types of approaches to get to Grannus either. So that's the long version of "No." EDIT: But now you've got me thinking and just wondering (haven't plugged this in yet)...have you tried an Otho gravity assist? I used that approach for a drastically shorter fly-by of Leto and I'm in the early planning stages of a Otho/Nero shot to park something at Hox. Honestly, I just haven't really started working on things to try and get to Grannus yet since I haven't pulled these others off but you've really got my brain tweaking now...
  7. rasta013
    It's known and is working on being addressed in coming releases.
  8. rasta013
    Great addition man! Just as a note on this...the only other lab of consequence in BDB is Skylab and this is such a good idea I may run with it a bit and add the Zoology bay to Skylab as well since that would give both labs necessary for Station Science. Really good idea!
  9. rasta013
    I think I mentioned this a while back when I first jumped on this thread but for complicated flight paths and multi-body encounters you can use @Arrowstar's KSP Trajectory Optimization Tool. It is an external tool that interfaces with KSP to extract and inject information into the game. With it you can plan literally any kind of flight path you want. It is by far the most robust tool available for flight planning. It works with GPP but you will have to create a custom Bodies.ini file for it although that is a very simple process. The learning curve for this tool is steep but well worth the effort and time I've put into learning how to use it (although I'm no expert by any means ).
  10. rasta013
    OK - so did some digging on this question for you and here's what I've found. The Polyus FGB was, of course, the Soviet Star Wars platform. It was mated to Energia via the FGB Block (Functional Cargo Block) and the FGB Block used for the Polyus was the standard TKS platform made up of the 11F74 and 11F77 pieces (VA and FGB blocks). The Polyus FGB was launched strangely (upside down which lead to its untimely demise) but it doesn't appear that anything besides the inertial navigation system was different in that block leading me to the conclusion that it's the standard propulsion used on the TKS as mentioned above by @liquidhype.
  11. rasta013
    I love the idea of #3 but I completely understand the hesitation in introducing something that is likely going to result in support requests. With this in mind I favor #1. Even though the part list may be extensive the nightmare of recoloring by having to select each individual part and hunt down each button on each part is worse. With #1, would it be possible to use part highlighting to identify which part is being targeted as you scroll over the list? That bit would make identifying the part you're working on easier for large craft and keep us from having to constantly hunt down buttons in complicated lists. This could even be easier if the part list was able to be sorted by name (not necessary but a consideration maybe). Just spit balling a bit here...
  12. rasta013
    New one to add to the Compatible list for contract packs: Kerbal Academy seems to be working fully. I've been able to receive contracts for all the classes and for off world bodies. Looking through the code of the pack itself I do not see anything that should throw it off either. Unless someone else has run into something (been testing this for about 2 weeks) I think it can be safely added to the list now.
  13. rasta013
    OMG YES PLEASE! That's lovely...
  14. rasta013
    New screenies of the LEM look MUCH improved over the first ones. Looks considerably better even if not proper without PBR...
  15. rasta013
    On that last pic I understand where you're trying to go with it and the back panels are good for now even though they were historically a lot more f'd up by the time they land. The one thing for me is the foil. It seems kind of flat and dull looking from this angle. I don't know if that's a simple product of the lighting angle that it's sitting at though. One other thing, the shadows in the folds of the foil look a bit too dark...again that may be a product of lighting angle but those are the things that jump at out me. EDIT: Flat isn't the right word...dull sheen and less "pop" than it does in other lighting situations hence the reason I'm not entirely sure it isn't just a product of the screenie...
  16. rasta013
    Almost - technically the TRIXIE doesn't have the mineral scanner capabilities of the second multispectal part from SCANsat and since I've largely not been testing using stock I'm not sure if it scans anomalies like the other base multispec part...I think it just does biomes (again not 100% on this and it could easily be rectified). Also, there's the ASERT scanner but that's really only important to those of us who regularly go after asteroids because we are so science poor we can't pay Soviet rates. Oh and also the GORESat experiment and the recon scans as well... EDIT: Other than the anomaly, mineral and water scanning though that's it for mapping...the experiments do have quite a few others though but @akron's getting there in a beautiful way so far.
  17. rasta013
    That's a good question and I'm not 100% positive of the answer. My understanding is that it would work like this... Contract is generated ->Chooses Body->Chooses Applicable Situation->Generate Parameters->Generate Reward In that order it would be looking into the config file for the chosen body and situation and generating the contract and ultimately the reward based on those initial parameters. As suchThis is a bit of an educated guess though and I'm definitely not the expert on this. To get the real nitty-gritty on it you might ask over in the Contract Configurator thread and see if @nightingale can give you better insight into the mechanics than I can.
  18. rasta013
    Well no...but yes. I'll explain. GC actually, in its base form, uses Metals as the primary build resource. This is housed in the CRP and @allista could explain it in a lot better detail than I can how the process works. What I mean with the yes/no answer is that they do use different resources but to date I've had absolutely zero compatibility problems beyond that little detail. Just as an FYI - in scanning the GC thread I may be wrong on one detail - it may be possible to build the DIY container in an EPL orbital, fill it up with the resources housed there and then land it to build...or possibly land it, fill at a ground base, build it. Would have to test this out though as I've never tried.
  19. rasta013
    Maybe I wasn't clear enough, my apologies. The situation number is the number you're looking for to use in your calculation. Depending on where the experiment is run that science body multiplier will change. For example, when in-flight low on Tellumo your science body multiplier for any given experiment that can be run there will be 7. Take the exact same experiment and land it on Tellumo and your science body multiplier becomes 9. Does that help explain it better? Sorry I wasn't very clear to begin with.
  20. rasta013
    I have the same kinds of problems actually. To be honest, I'm running EPL/Keridian Dynamics side-by-side with Ground Construction/Konstruction. I use the EPL-KD solution for orbital construction since it tends to be simpler to build out in space with multiple smaller parts. For the ground though, I'm using GC-K and loving it. Although I do have to move the pod to the ground location I want to build at it's a small price for the convenience of laying it all out in the editor and building in-situ. This gives a real nice balance between the two abilities - I haven't tried building the landing pod from GC using an EPL pad though so I don't know if it works but I'd highly doubt it. Just a bit more info for you off-world construction fun...this is my love too. To find the science values for each planet and situation you need to look in the \GameData\GPP\ directory and browse each individual body's config file. In there you will find a section that looks like this (from Gael's config) There's all your science values - you can extract them with regex or grep pretty easily or just manually open and grab them. This section sits at the top of the config so you'll see it pretty easily. Hope this helps!
  21. rasta013
    Nert - been a while coming but I've actually got these parts loaded in a career to see how they play and I've just started getting to them. I will have more feedback in the coming days regarding their uses/bugs but just from the early results I would like to say a gigantic... THANK YOU! I'm playing on the Galileo Planet Pack (yeah, big surprise it's all the rage...) and these parts are shaping up to be extremely handy. There's several reasons why. First and foremost are the distances to the furthest reaches. The outermost planets, Hox and Leto, both have massive orbits requiring a significant amount of either fuel or time to get there. These engines help solve the fuel issue so that I don't have to deal with the extended times it would require. The outermost planets aren't the end though. In the most recent update a sort of borderline sub-stellar L or low M Class star was added that is within travelling distance, albeit with stupid times and fuel requirements which this mod one again helps to address. Plus, it's giving me things to work towards on the high end finally without being stuck completely with having to go toward warp drives as a peak technology. As always - Thanks again man!
  22. rasta013
    You beat me to the punch by about 30 seconds... I just tested this thinking I may have been babbling and lo' and behold my previous babble is meaningless...hmmm... With this in mind the change makes a lot more sense.
  23. rasta013
    Max orbit height just denotes the max you can scan from, not the ideal (or lowest) scan height. More importantly, the max height is actually meaningless for mapping purposes. The height of the atmosphere of a planet doesn't matter since SCANsat looks at your height above the atmosphere NOT the height of the atmosphere for determining the altitude of the instrument in question. In other words...if you're 500km above a gas giant's atmosphere that's 500km high or 500km above a terrestrial atmosphere that's 70km high then in both cases your altitude for SCANsat instruments is 500km since it measures from the edge of the atmosphere, not the surface. For any gas giants of OPM or GPP you don't need to add height since the max only defines the limit. All you've done is make it easier to get perfect scans of altitude, terrain and biomes from higher altitudes on all bodies - not just gas giants - and you've eliminated the challenge of needing to scan at different altitudes since the instruments don't all overlap in altitude ranges. UPDATE: As an edit, you've got me thinking now about behavior in game and I'm testing something real quick to see if something has changed...stay tuned. See below.
  24. rasta013
    I didn't get to test as much as I wanted too last night but first brush is pretty cool. The idea of tweaking in more levels of DSN might work better than anything else actually. The other issue I see would be people taking umbrage at having to install another mod to launch or breaking immersion by using tiny antennas that have massive power for no other reason than as placeholders. More testing is coming for the first but a suggestion on the second - instead of using scaling to create multiple new copies of larger, more massive sizes, instead create only a single upgrade to add one more tier to the relays. Then employ the new upgrade system to add additional power level upgrades to the 4 levels of antenna. The additional antenna is the peak power model (say 500G or 1T) that can have the higher mass level and operate as the core network antenna (kind of like the JX2 is right now). This would help prevent people from feeling like they need to run another mod to make their antennas feel right (or even be able to launch) and keeps the control firmly in the realm of advancing tech. I know I'd hate to feel like my tech is advancing but comms are doing nothing but getting larger.
  25. rasta013
    Cool man thanks - saved me a bunch of time digging back through to try and remember who posted when and where. 'preciate the work!
×
×
  • Create New...