Starwaster

Members
  • Content count

    8,062
  • Joined

  • Last visited

Community Reputation

2,527 Excellent

5 Followers

About Starwaster

  • Rank
    Defender of the Sandbox

Recent Profile Visitors

7,511 profile views
  1. I pushed it here: https://github.com/Starwaster/KSP-BonVoyage/tree/Battery-Support And updated it. I'm not sure what state the rotation correction is in; I was screwing with it and it doesn't work the way I had it working before - the working code is still in there in one of the commented out bits or in one of the commits. Also, there's other things in that that are not stable that I was experimenting with so if you build that code it can be buggy. Things like amphibious support for Lynx parts and it has on occasion broken my saves plunging vehicles to the bottom of the ocean requiring me to edit the save to fix it. Still, have at it if you want
  2. The umbilical should be placed ventral regardless of whether or not it's Orion accurate. It's not like either the Mk 1-2 or 1-3 pod were particularly accurate to begin with and that's ok. Not sure I understand the issue with the fairing; are you asking if it's possible for the stock procedural fairing to limit its size? If so, yes; you can keep it from going over a given diameter. I don't think you can restrict it to ONLY that diameter; I think it will always be possible to taper it, but it's better not to restrict the player anyway.
  3. Starwaster

    [1.3.0] Procedural Parts - Starwaster Branch

    No it's a definite known bug linked to the model gimbal transform and it started happening when certain changes were made to the stock gimbal code. As far as I can tell, gimbal transforms were not originally axis sensitive. It just served as a point from which part of the model could be rotated. But when gimbal functionality was changed to limit gimbal rotation to certain axes some older engine models broke. This is something I have fixed locally but the fix has certain graphical glitches in the editor inventory screen where the SRB thumbnail has two visible bells. And that's something that I have suddenly lost the ability to change when I updated the unity editor and it doesn't want to open the mesh scene file anymore. I never got that issue sorted out and didn't want to release it looking crappy like that.
  4. Official release for KSP 1.4 (1.4.0 - 1.4.5) This is just a compatibility release and particle update to the new particle system. Some other minor config tweaks and parts compatibility configs... https://github.com/Starwaster/DeadlyReentry/releases/tag/v7.7.0 Known issue: Kerbals on EVA STILL have a thermal warning gauge and there doesn't seem to be anything I can do about it. Bottom line is that Kerbals (like humans) have a very narrow range of temperatures they can live in and for whatever reason, the gauge threshold multiplier is being ignored for Kerbals and I still don't know why. From what I can tell it shouldn't be happening so there's probably some unknown bit of KSP code somewhere that I haven't accounted for.
  5. Starwaster

    [1.0.5] Reflection Plugin Continued 2.0

    Reflections Plugin uses PartModule (MODULE node in each PART)
  6. Starwaster

    [1.0.5] Reflection Plugin Continued 2.0

    Textures Unlimited uses PBR methodology and workflow. It does seem to require a bit more configuration and setup for parts to make use of it than Reflection Plugin did and parts need configurations written up for them before they can make use of it. Result wise it it looks pretty good.
  7. It's used by mods but not by stock. It was added to the stock class for modders to use
  8. Starwaster

    [1.4.2] Kerbal Space Transport System

    Because every PartModule can modify the cost of the part it is on. It does this by reporting a cost delta and there is no sanity checking to ensure either a minimum cost nor a negative cost. Literally every plugin mod potentially is modifying the cost of the part and the more of them you have the more likely that stuff like this is going to happen. (this is done by calling GetModuleCost() on the PartModule in question assuming it implements IPartCostModifier. The only information available to GetModuleCost is the base part cost from the prefab and if the part has resources on it it does not take into account the fact that the player may have adjusted those resources)
  9. All information required is stored on the newly created vessel on only two fields. Everything else can be extrapolated. Again you're overthinking this as being harder than it is. There's nothing particularly difficult about it but you do have to do some thinking.
  10. Because MJ was never 'trained' to recognize Real Chute parts as parachutes. It looks for a specifically named module (really a class) called ModuleParachute and Real Chutes implements its own classes that MJ doesn't recognize and likely would require reflection to trigger. It's not impossible to code for (not even hard really unless you're like me and just absolutely hate having to use reflection because you hardly ever use it and so don't remember how because it's been months since the last time you used it...) it's just that nobody has ever gotten around to writing the code required to make it happen.
  11. That sounds like MJ being unable to calculate thrust or deltaV. If it cant determine those then it has to default to starting at node
  12. It depends on if you actually made use of new features that aren't supported in the most recent Monodevelop release. The latest Monodevelop is actually up to date in that regard in the source but there are no publicly available builds of that code. There are also downloadable packages add compatibility and I have successfully used them in compiling mods that used otherwise unsupported C# features. (MJ2 for example) So there are still options open for Mono users. It's not really a big deal sticking with it over VS.
  13. Technically speaking you could but why??? i can't even...
  14. Then you've probably got a bit of a learning experience ahead of you. For editing and compiling the source you're going to need something like Monodevelop or Visual Studio by Microsoft, both of which are free. Or rather, there is a free version of VS but you have to apply for a license. (basically have to register with MS is all it is). I prefer Monodevelop but it is no longer in development and the last version didn't support certain features in the latest C#.