Jump to content

Starwaster

Members
 View Profile  See their activity

  • Posts

    9,282

  • Joined

  • Last visited

 Content Type 

Everything posted by Starwaster

  1. Starwaster
    Certainly it's possible. That's more or less what I do, although I'm only using a 10x scaled Kerbol system rather than RSS these days. (Hey! I have to LIVE in the solar system, I play KSP to get away from it...) Mostly my engines are from the stockalike engine pack with some RO engine configs for parts packs like SSTU and some engine configs I crafted myself. It works well enough.
  2. Starwaster
    Don't uninstall that modelling program just yet
  3. Starwaster
    Uhmmm link?!?? (also, of course he's gonna change it again... )
  4. Starwaster
    If you're talking about what's actually checked for contact then you're talking about a transform and from a practical standpoint it's not something you can change. Also, it does not have to make physical contact with anything. Whether it attaches depends on whether the range between the transform and the surface of the thing being grappled is shorter than captureRange which is something you can change in the config file if you really feel like the collider is what's keeping you from attaching. (captureRange is one of the fields in ModuleGrappleNode)
  5. Starwaster
    Looking at the part, it's configured for a max relative velocity of 1. (the code actually compares squared velocities but 1 squared... well, you know) So it should be pretty tolerant.
  6. Starwaster
    Which way it's oriented depends on which editor you're using. In the VAB it always starts out with the windows pointing up because that's the Y axis which is always roof to ground. However, in the hangar, the Y axis is hangar door to wall. So the windows point towards the hangar doors. Same with spaceplane parts. The cockpit points out the door because it's a plane and you want it oriented horizontally but in the VAB you're launching it on a rocket so the cockpit points up. Basically it always aligns the Y axis of the craft root to the Y axis of the editor space.
  7. Starwaster
    The craft files need updating. The command module had to be changed and it broke placement in the craft file. It's easy enough to fix, just reattach the parts.
  8. Starwaster
    A year later, a fix for the SRB issue that doesn't involve deleting the upgrade file outright: Replace the contents of MaxSizes.cfg with the text in the spoiler.
  9. Starwaster
    I too am using it in 1.3.1 There are dependencies and you should try to ensure that you are using a compatible version of the appropriate plugins.
  10. Starwaster
    Sounds like maybe you've got an older version? The breakingForce and breakingTorque values were either too low or for some parts I think they were non-existent (if not specified then it defaults to some really low value like 20 or so). @JadeOfMaar went through them and bumped them up. To get those changes you need to download right from the Github repository from the master branch at https://github.com/damonvv/TundraExploration (click the green button that says 'Clone or Download' and then select 'Download ZIP')
  11. Starwaster
    If it was a game event, always check for nulls. I have in the past caught the same game event firing multiple times when it should only fire once, and only one of those had valid objects being passed as arguments. onVesselOffRails being an example offender; fired several times with a null vessel reference. I don't know how often that still happens but I always assume it to be the case.
  12. Starwaster
    Yeah, not using RSSVE, I just saw 'scatterer not working between 140km and 200km in low orbit.'
  13. Starwaster
    That's been like that forever and I have no idea why.... and I've tried to figure it out.
  14. Starwaster
    Yeah, FOR doesn't work that way; it just specifies what phase (or pass) to run in and satisfies conditions. As far as order goes you could take it to mean 'during' (BEFORE, during, AFTER)
  15. Starwaster
    That statement is not true. I don't know how you conducted your experiment but the presence of FOR[some-mod-name] ANYWHERE in ANY config file will automatically satisfy any NEEDS[some-mod-name] no matter if they are in separate config files, separate folders or even running in different phases. THIS IS BY DESIGN At the time that Module Manager begins applying patches, all phase ordering AND conditionals have already been determined and exist concurrently. Consider the following: @PART[*]:NEEDS[TestForFORDependencySatisfaction] { FOR.Met.Conditions = true } @PART[*]:NEEDS[DummyNEED]:FOR[TestForFORDependencySatisfaction] { // Don't do anything } Go ahead and save that as a config file and run KSP. Let it finish loading and then check your ModuleManager.ConfigCache file and you will find the line FOR.Met.Conditions = true in every single PART node. Note that the two patches occur in separate phases. The first one doesn't have a phase specified so it is applied during the LEGACY phase, which occurs just after FIRST. The second patch doesn't even perform any work, its sole purpose here was to satisfy the conditional in the first patch.
  16. Starwaster
    @LatiMacciato Not sure what you're trying to get across with the MM documentation quotes other than it is a reiteration of exactly what I already just said. No, the behavior of MM should not be what you describe; instead of using FOR (since you are writing for a separate mod that is NOT Snacks) you should be using either BEFORE or AFTER. Using FOR the way you specify can cause unwanted behavior for even more mods that might be performing conditional checks for Snacks mod.
  17. Starwaster
    Yeah, but you can't roll up a mod and eat it sub style!
  18. Starwaster
    No. NEEDS is only a conditional and does not specify a phase in which to apply the patch. FOR is not a conditional at all and it specifies a phase in which to apply the patch. Additionally, FOR will satisfy any NEEDS by the same name. So, it doesn't contradict itself but if the NEEDS and FOR are the same then the condition will be satisfied. (i.e., :NEEDS[DeadlyReentry]:FOR[DeadlyReentry] would cause the patch to be applied even if DeadlyReentry is not installed, which is also why FOR[DeadlyReentry] should never be used by any mod other than DeadlyReentry - to use an example)
  19. Starwaster
    Please PLEASE tell me that you are not talking about this: Can you really not see what is happening there? No, it is NOT squashed. Yes, it IS rotated. The part that is the front in the first image is now on the top due to rotation. The port and starboard sides (with hatch and flag) have changed sides for the same reason. No, that should never have worked, if it ever did.
  20. Starwaster
    That's always been the syntax. Sounds like either MM is enforcing things it let slide before, or more likely that it is throwing errors on things that were failing silently before.
  21. Starwaster
    @Sparrowhawk or anyone else using Deadly Reentry: Save this file to your DeadlyReentry folder (in GameData) https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry-Tundra.cfg It ONLY covers the BFS and not the BFB which shouldn't be an issue or any other Tundra parts. (I haven't used Tundra previously so it wasn't on my radar for DRE at the time) It is a blanket stopgap solution and is NOT representative of how Elon says the ship will be protected, which is with ablative shielding. It also hasn't been tested with these particular parts but you should be ok if you keep to a shallow reentry. When Deadly Reentry updates next, the file will likely be updated to something else. If @damonvv changes how the ship is protected then either I'll adjust these configs or remove them depending on what he does and how it behaves with Deadly Reentry.
  22. Starwaster
    Are you using Deadly Reentry and/or using a scaled up star system? Either one could be problematic as these parts aren't really configured properly for reentry. Basically it looks like they were brute forced with a maxTemp of 5000K which will protect them in a stock reentry. However in a scaled up system, your reentry temperatures will be hotter. It's hard to say if they would be as hot as 5000K but it's possible. Deadly Reentry will definitely screw you over because it disallows maxTemps over 1523 by default. It automatically exempts anything configured as a heat shield as long as the shield is still intact and hasn't burnt away. Or it can be configured as a shuttle tile like system. I'll have support in Deadly Reentry for these parts in the next update.
  23. Starwaster
    Just download the previous version and grab the part from there: https://github.com/sumghai/SDHI_ServiceModuleSystem/releases/
  24. Starwaster
    Well, I was thinking more along the lines of a certain show with a certain antagonist with a costume with a snake emblem and a mirror helmet..... but that works too I guess.
  25. Starwaster
    It's probably a browser issue. Safari has been known to do that or some browser plugins might cause it. Google search for too many redirects google drive
×
×
  • Create New...