Jump to content

birdog357

Members
  • Posts

    232
  • Joined

  • Last visited

Posts posted by birdog357

  1. 7 hours ago, septemberWaves said:

    The first question that immediately comes to mind is "how quickly are you turning the vehicle?" The second is "do you have stability assist enabled?" Finally, "is the rocket flexing like it doesn't have sufficient auto-struts?"

    Early Atlas in particular is not trivial to fly manually, because you have to take the half-stage into account, but it shouldn't be unstable so close to the ground unless you're trying to turn it too quickly.

    For a flight profile that should work: normally I wait until 1km above ground before I start turning, and then I turn 1 degree every 200 meters altitude (or, for manual flight, 5 degrees every 1km) until the rocket is 60 degrees above the horizontal. Then it's half that rate of turning (1 degree per 400m, 5 degrees per 2km) until 50 degrees above the horizontal (should happen at 11km altitude). After that, I wait until 15km altitude, and start to turn 2 degrees per kilometer altitude until reaching 40 degrees at 20km altitude. Then, I turn 1 degree per kilometer until reaching 20 degrees at 40km altitude. At that point, you can start thinking about orbital insertion, and your approach will vary depending on the vehicle's specific design (in particular, its upper stage burn duration), but most of the time I reduce to 10 degrees by 50km altitude, 5 degrees by 70km altitude, and then wait until apoapsis is out of the atmosphere before I reduce angle above horizontal to zero. Alternatively, if you're playing at stock scale instead of 2.7x scale (the latter of which is what BDB is balanced for), once you reach 40km altitude you can just burn until your projected apoapsis is where you want it, then coast to orbit and circularize. This general approach works extremely well for the vast majority of rockets, including everything I've tested in BDB except Scout (and I've tested almost every major rocket configuration in BDB by this point).

    For early Atlas, auto-jettison of the half-stage engines should typically be set (on the engine shroud) to an acceleration between 3G and 4G, depending on upper stage, payload mass, and required orbital parameters: if your upper stage burn time and/or thrust-to-weight ratio is particularly low and you have sufficient delta-v margins, set the cutoff to a higher acceleration (which allows your first stage to put out more thrust more quickly (giving your upper stage more time to burn), but reduces its delta-v); if your payload mass is particularly high and/or your delta-v margins are otherwise very limited, set the cutoff to a lower acceleration (which allows you to maximize the delta-v of the first stage at the expense of thrust).

    If you have very limited delta-v margins and an extremely long upper stage burn time, you'll almost certainly need to adjust the main launch profile so that the first stage (especially prior to half-stage separation, which should occur at as low an acceleration as you can get away with, but almost never lower than 2.5G) spends more of its fuel burning with a partially-upwards vector, and aim for a higher apoapsis than your actual intended parking orbit (this allows the upper stage to burn horizontally for a long time and it eventually falls down from the initial apoapsis to circularize nearer to the atmosphere). This is an advanced technique that's not necessary for canonical payloads included in BDB, and is just about useless if you play mostly-stock and in a stock-scale solar system (unless your upper stage engine is nuclear or ion), but it can be very important in the circumstances I described.

    If you're not turning too quickly and you have stability assist enabled, then you've assembled the rocket wrong. If the rocket is flexing, autostrut the big main fuel tank part of the Atlas rocket (the part with the side greebles) to the root part (which should be the probe core) and that should prevent flexing. Regardless of whether the rocket is flexing, double-check that the root part is indeed the probe core. Check staging to ensure that: the sustainer, half-stage, and vernier engines are all ignited simultaneously on the launch pad; the half-stage skirt is jettisoned after first stage engine ignition and before upper stage separation; the Agena engine is only ignited after the Agena decoupler fires; the fairing is either auto-staged at the default altitude or is manually staged at some point after the half-stage skirt separates (for almost all circumstances I recommend just turning off manual staging for it, assuming you're using the Simple Adjustable Fairings one); the payload only separates from the upper stage after the fairing is deployed; and the payload engine only ignites after all of the above. If the rocket still doesn't work, make sure you've attached all nodes properly and not accidentally surface-attached the Agena to the payload or something similar to that, because KSP aerodynamics doesn't care about the shape of the vehicle (unless you're using FAR), it mostly only cares about whether an unoccupied node is pointing forward, or whether any part at all is outside of a fairing/cargo bay. Finally, check that you've used the correct SAF fairing for Ranger: there are a lot of Agena fairings, and not all of them can contain all payloads - a non-Ranger fairing might leave some parts of Ranger clipping outside of the fairing, which will ruin the aerodynamics and could cause flipping (or, at best, it will seriously impair the aerodynamic profile of the vehicle).

    EDIT: One final question just occurred to me: did you remember to throttle up before launch?

    The rocket was going into a death spiral as soon as the clamps released. It turns out my stick was out of calibration and commanding full left roll and yaw as well as full forward pitch.

  2. I know I'm missing something simple. Ksp 1.12.4 and current release of BDB. I've built up a Ranger block 2 stack on an Atlas LV-3/agena-b just like IRL. I can not get the thing to fly. It swaps ends before it's even one booster length off the ground. I built it up from the stock craft files in the download. Yes, the nav ball is pointing up. I'm sure this is a PEBKAC error. What am I doing wrong?

     

    Edit: It was something stupid. Fly by wire lost calibration, so it was commanding a full stick throw left down and yaw left.

  3. On 6/16/2022 at 11:45 AM, CobaltWolf said:

    Ok, thought about this a bit on the drive in to my office. I'd just stick to BDB v1.9 if things are working well for you now - BDB v1.10 was almost entirely focused on updating the Saturn and Apollo parts, so if you're already happily using the existing versions of those, there isn't a lot to get from the update. My chief concern, if you were to try and 'merge' 1.9 and 1.10, is that stuff like the compatibility files, things like that, are all updated and pointing at the new part names, not the old one. So I think if you tried to use BDB v1.10, but with the v1.9 Saturn folder, those Saturn parts would have issues.

     

    I actually did briefly look into that while I was making the shortened S-IVB. I wanted to take the green 'cone', and everything that attached to it, and stick it on the tankbutt in the S-IVB mount. Zorg did the same thing, in reverse, for the single engine S-IV mount. I didn't work well, but I think I can make it work with a bit of elbow grease.

     

    First off - I'm really not taking Gemini requests right now. I've got a pretty long to-do list at the moment.

    Regarding "wide nose" Gemini, and this pretty much all applies to the Apollo as well, it's actually a pretty big ask. From a real-life hardware perspective, once you start changing the shape of the capsule like that, you're suddenly designing an entirely new spacecraft. So it's a somewhat unrealistic solution. With the Gemini, you also rapidly lose visibility out the forward windows.

    Then there's what it would actually take me, the modder, to do such a thing. I'm going to try and illustrate this, so people understand the problem with doing something like this.
    Here's just a normal cylinder, ring of vertices on the top and bottom. It's easy to change the diameter of one end by grabbing them and scaling them.

    0aClhSq.png

     

    Here's the Gemini capsule. As you can see, the geometry is much more complex (to a fault, almost), and selecting the top to change the diameter just results in a really jacked up model. Properly changing the slope would take an extensive amount of time moving all those vertices by hand - and the end result probably wouldn't be that good.

    pEBA71i.png

     

     

    Yeah it's been on my to-do list for a bit now.

     

    I don't see why not, I suppose?

    But Cobalt, it's easy, you just push a couple of buttons don't you? (real conversation between a PM and me, the drafter, he's lucky I didn't strangle him...)

  4. On 4/27/2022 at 10:47 PM, Vini said:

    Is this mod dead forever? Or will there still be an update sometime in the future? I know this mod works in the current version of KSP 1 (the last one until KSP2), but i was hoping they'd add Eve's rings back sometime, and it kinda hurts seeing such a lovely mod like this starting to be forgotten, i mean, the last post on this forum was in the beginning of this year, so yeah... :(

    This works in 1.12.3?

  5. 47 minutes ago, linuxgurugamer said:

    CKAN would have installed it correctly.

    For full log info (link is in my sig): Read this BEFORE asking for supporthttp://forum.kerbalspaceprogram.com/index.php?/topic/83212-how-to-get-support-read-first/

    If you think CKAN installed it incorrectly, please post the entire directory:  <Gamedir>/CKAN

     

    The only other thing I can think of is that your antivirus is either blocking or deleted one or both of the files:

    • SDL2.dll
    • XInputInterface.dll

    which should be in the main game directory

    I've got it installed correctly now and it seems to be working. Except I can't get wheel throttle to work. That's probably just me not being able to understand the devs weird ways of doing things.

  6. 12 hours ago, Invaderchaos said:

    Just about done modelling the ASTP Docking Adapter!

    Capture.PNG

    shouldn't the docking target be on the other end of the adaptor? On a related note, would an independent visual docking target be possible? Something that snaps to the node behind the  docking port so the position is correct to the axis of the port? I prefer to hand fly my docking, eyeballs out, and not use nav tools.

  7. 19 hours ago, linuxgurugamer said:

    Not installed correctly.

    I prefer Player.log, but this is the error:

    [EXC 15:31:06.209] DllNotFoundException: libSDL2-2.0.0.dylib
    	KSPAdvancedFlyByWire.SDLController.InitializeSDL () (at <aa89e93a18714f9599fdcfaba3d730f5>:0)
    	KSPAdvancedFlyByWire.SDLController.SDLUpdateState () (at <aa89e93a18714f9599fdcfaba3d730f5>:0)
    	KSPAdvancedFlyByWire.AdvancedFlyByWire.Update () (at <aa89e93a18714f9599fdcfaba3d730f5>:0)
    	UnityEngine.DebugLogHandler:LogException(Exception, Object)
    	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

    From the OP:

    Windows

    1. Download the latest mod archive from SpaceDock

    2. Copy the contents of the archive inside KSP's root folder. You should see the game controller icon during flight mode.

    3. Please note that XInputInterface.dll and SDL2.dll must be in the same folder as the KSP executable and not in GameData.

    That's what I get for using CKAN...

    I don't have a player.log?

  8. 9 hours ago, linuxgurugamer said:

    How about a log file?

    https://drive.google.com/file/d/1UbIzRiu3V0V-s1ZOploG-CyaVQuWE2Xp/view?usp=sharing Had to zip it. It's 80 megs

     

    KSP 1.10.1 BTW I'm trying to use my new X56.

    This the problem? 

    [LOG 15:30:44.274] [AddonLoader]: Instantiating addon 'AdvancedFlyByWire' from assembly 'AdvancedFlyByWire'
    [ERR 15:30:44.276] ADDON BINDER: Cannot resolve assembly: AdvancedFlyByWire.XmlSerializers, Culture=neutral, PublicKeyToken=null
    
    [ERR 15:30:44.276] ADDON BINDER: Cannot resolve assembly: AdvancedFlyByWire.XmlSerializers, Culture=neutral, PublicKeyToken=null
    
    [ERR 15:30:44.276] ADDON BINDER: Cannot resolve assembly: AdvancedFlyByWire.XmlSerializers
    
    [LOG 15:30:44.315] Exception deserializing C:/KSP Installs/Mod KSP 1.10.1/KSP_x64_Data/../GameData\ksp-advanced-flybywire/PluginData\settings.xml, Could not find file "C:\KSP Installs\Mod KSP 1.10.1\GameData\ksp-advanced-flybywire\PluginData\settings.xml"
    [LOG 15:30:44.329] Exception Deserializing: Could not find file "C:\KSP Installs\Mod KSP 1.10.1\GameData\ksp-advanced-flybywire\PluginData\advanced_flybywire_config_v21.xml"
    [LOG 15:30:44.330] Advanced Fly-By-Wire: Initialized
    [LOG 15:30:44.330] [AddonLoader]: Instantiating addon 'AdvancedFlyByWire' from assembly 'ksp-advanced-flybywire'
    [ERR 15:30:44.333] ADDON BINDER: Cannot resolve assembly: ksp-advanced-flybywire.XmlSerializers, Culture=neutral, PublicKeyToken=null
    
    [ERR 15:30:44.333] ADDON BINDER: Cannot resolve assembly: ksp-advanced-flybywire.XmlSerializers, Culture=neutral, PublicKeyToken=null
    
    [ERR 15:30:44.333] ADDON BINDER: Cannot resolve assembly: ksp-advanced-flybywire.XmlSerializers
    
    [LOG 15:30:44.337] Exception deserializing C:/KSP Installs/Mod KSP 1.10.1/KSP_x64_Data/../GameData\ksp-advanced-flybywire/PluginData\settings.xml, There is an error in XML document (2, 2).
    [LOG 15:30:44.344] Exception Deserializing: Could not find file "C:\KSP Installs\Mod KSP 1.10.1\GameData\ksp-advanced-flybywire\PluginData\advanced_flybywire_config_v21.xml"
    [LOG 15:30:44.346] Advanced Fly-By-Wire: Initialized

     

  9. On 11/22/2021 at 10:17 PM, Pappystein said:

    Actually I just re-read the "master" Douglas report on S-IVC.    Aside from the cool linear docking of multiple S-IVCs together they also were to use a Slush fuel meaning fuel densification.  

    So when compared to the 16.7m long MS-IVB derivitives (there were three) the S-IVC gives up the structural changes from the MLV program, adds Desnsified Fuel, new LOWER RCS, new nosecone that protected the forward docking port and utilized the old style Saturn V RCS, and inline S-IVC to S-IVC docking... at-least according to NTRS 19690006388

    The report is a little thin which is why I didn't read it in-depth before (and I have already work 26 hours this week (2x 13hr days) so my eyes are bleary :D  

    I was actually referencing the viability of the Hydrolox engine, not how to make it in KSP.   Even a Kerolox SM would suffer from boiloff of the LOX stage before you got to either destination.    I think the ESM would have ended up with either 2x AJ10 developments or TR-201 derivatives.

     

    Could you point me to the Douglas report on the S-IVC? Or just give me the NTRS number?

  10. 1 hour ago, Pappystein said:

    Just found some Saturn information from Ed Kyle on NASASpaceFlight quoting his post from earlier today (unrelated to me being there just lucked into it!)

    Hope that is helpful

    They dialed in the fuel system better as they went. There was less fuel left over at burnout. That would account for a lot of the mass differences.

  11. 54 minutes ago, pTrevTrevs said:

    The idea being that I speculate this is one of the ways they could have made the lunar shuttles work in For All Mankind.

    I'm following you now. The problem is RS-25s are not restartable, the ET would boil off before the moon was reached, and the OMS doesn't have a fraction of the fuel needed to enter and later break orbit.

×
×
  • Create New...