Jump to content

Razgriz1

Members
  • Posts

    171
  • Joined

  • Last visited

Posts posted by Razgriz1

  1. 10 hours ago, Shadow Wolf TJC said:

    However, perhaps this mod could be trimmed down in size? For starters, perhaps the core functionality of this mod could be split off into a core mod that the rest of the Bluedog Design Bureau gameplay experience would need to use as a dependency, while all those textures, 3d models, and such could be placed in separate mods, with options for using stock textures only (but original 3d models) for the highest performance experience, or for using original textures at low quality, or high quality, as desired by the player?

    On 9/30/2015 at 2:21 AM, CobaltWolf said:

    I don't want to download all this, can you split up the mod?

    I wish it was that easy! At this point, splitting up the mod would be a good deal of work, as well as additional overhead to maintain. Additionally, despite the frequency this gets asked, nobody seems to agree on how the mod should be split up! However, the mod is easily prunable. Deleting folders inside Gamedata/Bluedog_DB/Parts/ will delete that part family without breaking other parts of the mod. For finer pruning, mods like Janitor's Closet can be used to remove parts from within the game.

    Answered by an easy read through the original post.

  2. 1 hour ago, CobaltWolf said:

    What RP-1 experiments are you talking about? Anything that would be worth adding directly to BDB for the X-15?

    RP-1 includes Hypersonic Flight (> 1.5 km/s & Flying Low) and High Altitude Flight (> 650 m/s & Flying High) for the X-15 cockpit.

    These are, however, using the Kerbalism science system. I'm not sure if that sort of thing is possible with stock science.

  3. 5 minutes ago, Zorg said:

    Interesting, didn't know about this tbh. I've got a fair amount of Atlas A pics in my refs but none of the conical nozzles. But probably not worth doing even if I had though,  if as you pointed out only a handful of flights used them.

    Atlas 8A at the Strategic Air Command and Aerospace Museum has conical booster nozzles, though for some reason they also stuck a sustainer engine on it for display. I agree though that it probably isn't worth doing for Atlas.

  4. 2 hours ago, Spoq13 said:

    I encountered this problem. There is no payload in the service module tanks. Specifically Com Sat, Weather Sat and Nav Sat payloads.

    It's not a bug, the satellite payloads now use their own dedicated part, which is found in the "Satellite Era Electronics Research" tech tree node.

    Also I believe that WeatherSat payload no longer exists at all. The Weather Satellite missions now use NavSat payload.

  5. On 11/14/2023 at 4:01 AM, Majk said:

    Any pointers on how to get out of this pickle?

    The next thing you'll really want to start looking at is the science you get from the lunar flyby/impactor missions. If you have heat shields, then you should have more than enough tech to get a probe out that far, you're probably just going to have to work on your launch vehicle some. You're probably going need a rocket more around the 60t mark to get it there. A 30t launch vehicle really can't do anything beyond the first couple of orbital contracts.

    Edit to add: The first generation heatshields (heatsink-style) actually require a steeper reentry than you might think. They also need to make up a substantial portion of the mass of whatever you're trying to bring back.

  6. 5 hours ago, peter_12 said:

    thanks for answer!However, when I loaded the Saturn V under RSS, its F1 engine proportions and fuel tank were severely out of sync (I had tuned and scaled installed)

    First, the included BDB craft files will not work at all in RO, they are built using the standard parts and thus part placements will not get rescaled when you move to RO. You will have to build your own from scratch.

    Second, RO essentially creates their own parts using the BDB models, and rescales them appropriately, so I don't even thing the part names would stay the same. They don't rescale the fuel tanks at all, but they do include a select few of them, mostly the Saturn V tanks, in the modular fuel tanks that are a part of ROTanks, which is a part of the Realism Overhaul suite of mods.

  7. On 2/21/2023 at 3:28 PM, DJ Reonic said:

    For anyone who uses Photon Corp with SOCK: Which is the better thrust profile to use (obviously not the flat one)?

    26 minutes ago, CirrusUpdraft said:

    For me it depends on the target orbit I'm going for, if I'm going for a higher orbit (Ala Hubble Space Telescope Servicing Mission) I'll use the default thrust profile, if I'm going for a lower orbit I'll use the steady drop profile

    FWIW, the default thrust curve is the most realistic one, where it ramps down around Max Q and then back up.

  8. 49 minutes ago, DJ Reonic said:

    @benjee10 Is the revised rudder model you mentioned a while back available, or will it be a KSP2 thing?

     

    Just now, benjee10 said:

    Not sure what you're referring to exactly, but not planning on any changes to the orbiter model in KSP1. 

    Unless you mean the Columbia SILTS pod, which is SOCK Recolored adds.

    Might be asking about splitting the rudders and the vertical stabilizer into separate parts so that they can work with FAR?

  9. On 1/19/2023 at 7:05 AM, Kurld said:

    Well I messed around with setting up a pitch program this morning.  Maybe I don't really understand "gravity turn" but in no case have I been able to hand things over to active guidance and not have it pitch up to nearly vertical and reset throttle to 100%.  This results in the apo being 600 to 700km on a planned 115 km flight path (remember I am in vanilla KSP.)  At the handoff I am somewhere around 60km altitude and nearly horizontal with a predicted APO of about 90km  I can't recall what my velocity was but I'm guessing the algorithm must feel it is much too low to continue on to the planned orbit.

    I also made PEGAS crash.  If it gets to the end of the pitch program before handing over, it blows up with another index out of bounds error.  I'll try to make a more full report on github after work.
     

    To be honest, PEGAS isn't actually particularly well suited for stock KSP, as it can't do a coast. Stock rockets generally have fairly high TWR, which when combined with the Earth-like atmospheric density and the relatively low orbital velocity, often makes a coast to apoapsis the best ascent path. The RP-1 wiki actually has a section on MechJeb's PVG, which is a similar algorithm to PEGAS (though it can incorporate a coast) and it explains a bit why the rocket it doing what it is: https://github.com/KSP-RO/RP-0/wiki/TroubleshootingMechJebPVG#my-rocket-is-burning-down-not-a-problem

    You could probably fudge it a little bit by either setting a pretty low g-limiter in PEGAS, or actually set the throttle limiter on the engine to a lower value, just don't forget to tell PEGAS what the maximum limited throttle is.

  10. 22 minutes ago, Kurld said:

    OK, so the latest version of the pegas_misc file solves that issues.  I have it working now.   Sorry for all the noise.

    Getting a proper gravity turn working is a lot of trial and error, and I still haven't figured it out, really.   I can set the throttle at increments of time, but again this is a LOT of trial and error.

    I noticed in the reference that you can set up some kind of delegate function as a sequenced event.  Today is "day one" for me working around in kOS.  I'm wondering if it is possible to call a delegate and have it manipulate the throttle so that time to apoapsis remains e.g. 45 seconds in the future, or else maintain some relatively constant acceleration BEFORE the active guidance takes over?  

    This will be really really cool if I can figure out how to make it work.

     

    You probably can (you can do a lot of things with delegates in PEGAS) but I'm not sure you'd really want to do that. The open-loop guidance portion, a.k.a. before "active guidance" is mostly to get you high enough in the atmosphere so that the closed-loop portion can take over. Your open-loop portion should be over fairly quickly before you'd really want to control your time-to-apogee. You'd probably be better off setting up a pitch program instead of a simple pitch angle. You can make a okayish ascent profile without too much effort.

  11. On 12/24/2022 at 8:47 PM, Richmountain112 said:

    Does this work with Outer Planets mod? 

    As in, does it explode when you enter Kerbin's atmosphere all the way from Sarnus or Neidon.

    The IRL shuttle isn't designed to be used for anything other than low earth orbit, and this one is modeled fairly realistically. It does not contain any ablator. I doubt this shuttle can survive any interplanetary reentry speeds, though I will caveat that I have never personally tried.

  12. 2 hours ago, halverson said:

    Did the PVG settings change with an update? I cannot get the shuttle into orbit using RSS and PVG, no matter what I try. I've used both the provided craft file as well as building my own per the manual and PVG keeps giving thrust is off errors as I approach SRB burnout and pitches up rather than continuing to turn. I have tried to replicate the profile manually as well and there just doesn't seem to be enough deltaV to get it into orbit. I'm obviously missing something but I can't figure out what. 

    The RSS/RO group is responsible for the RSS configs for this, not Benjee.

    As for the "Thrust is off" errors, that's due to the fact that the RSS configs simulate the tail-off in thrust that occurs toward the end of booster burn, but MechJeb doesn't know about that. It assumes solid boosters burn at 100% thrust all the time. As for what you could do about it, you can force MechJeb to wait to start the PVG until after the boosters separate ("PVG after stage X", or something similar)

    The PVG settings in the user manual are also designed for stock-ish sized systems, and the stock shuttle. RSS will likely require different settings to work correctly.

  13. 8 hours ago, septemberWaves said:

    Does anyone happen to know what causes this error? It's a new install of BDB, via CKAN.

    f8fpjbr.png

     

    24 minutes ago, CAPFlyer said:

    What did it turn out to be?  It's useful for anyone coming in here later that may see a similar issue to know what the reason was so they might be able to find the solution as well.

     

    21 minutes ago, septemberWaves said:

    I don't know exactly, I just know that it was something else I had installed.

    I believe that it's Skyhawk Science System.

  14. 1 hour ago, OrbitalManeuvers said:

    idk prolly not really 15 - the video shows real time not game time. I realized after I posted it you maybe can't tell that the eventual staging was not me hitting the spacebar, and was indeed MJ finally staging. It's not MLP because a rocket that autostages normally will still autostage normally on the Saturn mobile launcher, and a Saturn V launched using the stock launch clamps still takes several seconds to lift off, even if you tell MJ to stage after 1 second. The last variable (that I can think of) is MJ + BDB engines that ramp up.

    If you look at the mission time, you start the engines at 1:35, and MJ lifts off at 1:44. This, as you mentioned, is due to MJ waiting for the engines to reach 99% rated thrust before liftoff. BDB does simulate engine spool-up time, and this is pretty darn consistent with the actual F-1 engines. On a Saturn V launch, the engine ignition command was given at t-10 seconds before liftoff.

  15. 9 hours ago, SpaceFlightNut said:

    Hello!

    I am examining your code, and I was wondering one thing: What is the purpose of the launch vehicle descriptor file, such as

    PEGAS/kOS/boot/AtlasV-532.ks

    It contains parameters (such as massTotal, massFuel, isp, thrust), that can surely be obtained from the vehicle itself, correct? 

    It seems as if they are redundantly specified in there, unless I am missing somethng.

    Thanks!

    Programatically determining the staging for your rocket via kOS is not a trivial problem, and relies on various assumptions about how a user sets up staging. It also pretty much entirely breaks down in non-traditional staging cases like the booster skirt jettison for the Atlas rocket, which isn't reflected in the stock dV readout at all. You also can't assume any other parameters such as engine ullage requirements or hotstaging requirements (useful in RSS/RO) and so having the user define their vehicle parameters is a much cleaner way to do this.

  16. 1 hour ago, Kaduloso_007 said:

    Hi!

     I was very interested in using this tool, I really liked what I saw.  I just have a question regarding the orbit simulations: In my case, I'm starting my first save with the RSS and Principia mods, I really like to carry out more complex missions together with kOS (like in real life), with this tool , does it have the ability to simulate the orbits that the Principia mod provides within the game?  For example, Lagrange points, gravitational perturbations between n-body and among others?
     If yes, I will be relieved and happy to have to use this wonderful tool!

     Thanks in advance!

    Yes this allows you to simulate n-body physics

  17. 26 minutes ago, benjee10 said:

    If this would be useful I could add .mu files of the stabiliser and rudders in the next update. I don't have any knowledge of RO/RSS configs myself, but perhaps these could be made use of in a patch/config. 

    The split rudder is the primary thing that makes this not play nicely with FAR. If that was split into 3 parts (vertical stabilizer and two rudders) then it should be possible to get it working with FAR just in general.

×
×
  • Create New...