Jump to content

Starwaster

Members
 View Profile  See their activity

  • Posts

    9,282

  • Joined

  • Last visited

 Content Type 

Everything posted by Starwaster

  1. Starwaster
    My guess would be that it is controlled by torqueCurve. Though I don't like guessing, I don't see anyone else stepping up. What sort of changes have you tried making to it? Looking at it, the first number (the key) is probably a velocity value. The second number (the value) would be the torque. Ignore the 3rd and 4th digits. (2nd key only has 3; I forget if that's a problem. It might be actually; there should be 2 or 4 digits) torqueCurve { key = 0 250 0 0 key = 20 100 0 key = 30 14 0 0 key = 34 0 0 0 } So at speed 0 it has torque 250. (that's going to be its maximum) As it goes faster and faster its available torque is dropping until finally at speed 34 it has no torque. In practice it would never actually reach a speed of 34, so you would want the final key to be higher than the maximum speed you want to attain.
  2. Starwaster
    Completely wrong. What burnt up in this picture was the large SRB from the NASA pack with some fins and one of the I Beams, launched on a trajectory that leveled out at about 20 to ensure maximum heating. It burnt up on ascent. Edit: Also, you mentioned setting PhysicsSignificance to 1. Either you did so improperly (case sensitive) or something undid your change in another config. Setting PhysicsSignificance WILL cause DREC to ignore your part for both reentry heating AND G-Force damage. If you include your logs like I told you to, we can see every single config patch affecting that part and maybe other errors as well like parse errors. How did you make your change? Did you make a separate config file to patch it? If so then let's see your patch, maybe there's a problem with that.
  3. Starwaster
    I looked at your pictures but it's hard to tell from them which one is the part you're referring to or where it's situated. But the final picture indicates it failed due to excessive G-Forces, not overheating... granted it was only 2.5 G so there's something unusual going on. You need to post some log files. output_txt.log (or player.log if Linux or Mac)
  4. Starwaster
    It's useful in balancing power consumption to power generation. The name doesn't have to be changed for that (and shouldn't be). Just change generation values and battery storage values. Realism Overhaul does that. ElectricCharge is treated as one thing for generators but treated as something else for battery storage. But it's just a concept used in determining values to assign and from the player's side it's all invisible.
  5. Starwaster
    It doesn't do that to me. I have never EVER in a year of using KSP / MJ2 seen it close solar panels. I don't believe Mechjeb is responsible for what's happening to you.
  6. Starwaster
    It should be plenty for just that pod & heat shield. Post your output_log.txt file (or player.log if Mac or Linux) To find your log file: Windows: KSP_win\KSP_Data\output_log.txt Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log
  7. Starwaster
    1. See first post 2. It changes how things are affected by drag and mass will give inertia (instead of increasing drag) which means they are affected less by drag than if they would if their mass were lower. That matters in the upper atmosphere which is where you want to get as much deceleration as possible. 3. 'gliding down slow' isn't what lets you survive reentry. Parts need heat shielding to survive. The nose of the first ship can survive; it has space plane parts that could survive but their shielded side is turned inwards and it has a medium fuel tank with no shielding at all. It might survive reentering tail first. Second picture; I haven't a clue about those parts.
  8. Starwaster
    FAR doesn't actually alter stock atmosphere density. Its atmospheric modeling is applied to its own drag model, which replaces stock drag. That's all implemented in PartModules. It's not likely to be the cause of your problem.
  9. Starwaster
    That's because you didn't install one of the engine configs. Go back to the first page and read. There are links to the engine configs in the second post.
  10. Starwaster
    No, Module Manager is NOT causing your center of mass to move at all. A Module Manager PATCH (used by one of your mods) might be doing that but Module Manager itself only runs ONE time, when the game first starts up. What it does it apply patches supplied by various mods, or even potentially written by yourself. And then it shuts itself down and pretty much does nothing at all. If the database is reloaded from the debug menu then it will try to apply patches again, but that's it.
  11. Starwaster
    And (by extension), no fairings will help because the mod isn't fairing aware.
  12. Starwaster
    Yes, there are two buttons. One for the main and one for the secondary. Scroll down to find the second button
  13. Starwaster
    Forget I said anything. I'm helping ted through private channels; just saying it can be done is all.
  14. Starwaster
    Transforms can be added through separate models though that only exist to package the transforms.
  15. Starwaster
    OMG, not just that but EVE. That's like pea soup. I once popped chute in the upper atmosphere and had to go away for 25 minutes and left the game on phys timewarp x4. It was still descending when I returned.
  16. Starwaster
    Assuming a typical and simple stack, the net result of your fix would be to add drag to the bottom piece (an engine) while leaving everything else alone. That's not necessarily wrong (well, it is actually but no more wrong than the stock system itself). But it's probably getting too much added. It would probably help would be a substantial reduction for all the stack pieces in between (with shielded top and bottom nodes). The global drag multiplier might then need adjusting to make sure that net drag is balanced to something sane. That's the main reason it exists is that at some point I anticipated needing to do something about the fact that multiple pieces were all contributing an amount of drag that makes no sense given that they weren't actually facing against airflow. Actually, that wouldn't be realistic. I'm not terribly committed to full realism for SDF but it wouldn't make sense for the craft to have parts of its side oriented to the airflow and not have them subject to drag. There's a solution here but I'll not likely get around to it until the update I'm planning for Ioncross is released. I'm not sure about some of the bugs you're referring to but I'll take that part of the to the pull request on Github
  17. Starwaster
    Thanks, I'll take a look later tonight. Have you tried comparing the results either against real life or either of the other two drag mods?
  18. Starwaster
    Does this happen with all MechJeb parts or only ones that you added MechJeb to? For instance, if you have a MM config that adds MechJeb to your command pods, have you checked to see if it only happens to those or does it also happens with the AR202 part? And have you literally verified that every single function is available when it shouldn't be? (for instance, some MJ modules might have partial functionality but require multiple unlocked. The Ascent Autopilot can fly your plane but requires the Translatron to be unlocked or it will not control the throttle)
  19. Starwaster
    Well, there is a way to minimize the danger of such mishaps: staged = false Requires the assignment of action groups. Be warned though that less mishap = less fun!!!! @PART [*]:HAS[#category[Pods],!MODULE[ModuleDecouple]]:Final{ MODULE { name = ModuleDecouple ejectionForce = 250 explosiveNodeID = bottom staged = false } }
  20. Starwaster
    You're right, I should not have mentioned editing actual files and I never ever do that so I don't know why I suggested doing it that way now. Chalk it up to another case of the creeping senilities...
  21. Starwaster
    Thanks, I'll give that a look. Edit: Actually it does give the volume covered by those power requirements as 27.186 m3 And if I'm reading that right it's the 5th document in the set so maybe the amount of crew is given on the preceding pages. I'm thinking 4-6 crew.... it mentions a 'standard habitat' so hopefully they actually defined what they considered standard somewhere else.
  22. Starwaster
    Thanks for your input Chase!
  23. Starwaster
    The only difference is that 2.2.1 adds some button code. Any perceived problems were likely coincidence. 2.2.2 btw adds code to hide the button when not in use
  24. Starwaster
    No, not at all what I mean. Module refers to the 'MODULE' config node that you insert into the part's *.cfg file Edit the cockpit's config file and insert MODULE { name = ModuleDecouple ejectionForce = 250 explosiveNodeID = bottom }
  25. Starwaster
    Yes, it's possible. I think you could also just put the decoupler module on the cockpit so that it pops off....
×
×
  • Create New...