Ruedii

Members
  • Content Count

    983
  • Joined

  • Last visited

Community Reputation

130 Excellent

About Ruedii

  • Rank
    Spontanious Unplanned Disassembly Expert

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Don't put your engines too close together, and certainly don't clip engines together. Second, you shouldn't need that much power to launch anyhow. You need about 2.0-4.0 TWR for the first 20-40 seconds of launch followed by 0.5-1.5 TWR for the remainder. Angle 5 degrees from horizon, lock to surface-forward and get your time to apoapsis to between 45s to 1m and hold it there until the apoapsis reaches the desired height (between 70.1km and 80km, really your choice). After that, circularize at apoapsis and you are good. p.s. Now I'm going to prepare to be called a heretic for suggesting you need less launch power.
  2. Ruedii

    [1.5.x] MSP-3000 Material Science Pod

    Any way you could make a few Science Senior parts that incorporate several experiments and a science storage. Here's a quick list: Science Sr. 1.8m diameter (with top/bottom designed to look clean when attached to 1.25m parts) Materials Bay Mystery Goo Thermometer Barometer Science Storage Unit Some KIS storage (if KIS is installed) 400 electric charge Ultra-Short range science transmitter (500K) Science Sr. XL 2.5m Diameter (Same nice top and bottom for fitting 1.8m and 1.25m parts cleanly) Everything in the Science Sr. Second Material Bay Second Mystery Goo Acceleratometer Fluid Spectro-Varometer More KIS Storage (if KIS is installed) 1000 Units Electric Charge Medium Range science capable transmitter (50M) Science Sr. XXL 2.5m double height, or 3.5m single height variants available Everything in the Science Sr XL Lots of KIS storage (if KIS is installed) 3000 units electric charge Long range transmitter (500M)
  3. A few requests: Multiple colors/styles, some using stock textures. More tank sizes (of course) Matched radial decouplers for heavy lifter designs. Base engine operates as technically 3 engine modules (Center, Side, and Booster) that can be toggled individually using action groups or toggles. Multi-Parachute stage cap assembly for those of us who prefer the inaccurate but easier chute-based landings. Matched style in-line probe core. Theoretically it should work, just add the appropriate additional modules to the config file. Please note the disclaimer of "Theoretically." I've never seen that combination be done before, so it might not work. The drone core modules are non-animation modules and thus can be added to any part in theory, but the fairing base creates a child part-set (the actual fairing), and that could create issues. I'd make sure to test it, because you know Murphy's law.
  4. Ruedii

    FPS > Hz?

    Old laptops sometimes had them. Some tablet computers still have them. 60Hz interlaced was actually common on older CRT monitor displays for higher resolutions, because the horizontal sweep couldn't reach high enough rates to handle the higher row count. 1080i is technically 30Hz for a full refresh (two vertical sweeps for a full refresh).
  5. Ruedii

    Ending 32-Bit Support with Update 1.5

    Technically Direct3D 10 w/ SM3 is just as good on KSP. I don't even know if KSP uses SM4/SM5 shaders at all. Direct3D 10 changed the context management method for texture maps, improving memory footprint drastically. OpenGL probably has the best memory savings. BTW (Vulkan probably better still, but it's horribly buggy. I'm surprised they build with the beta Vulkan support in Unity.) They went released 1.5.1 only a couple days later with a small number bug fixes.
  6. Well the problem is that earth is significantly larger than Kerbin, so it takes a lot more power to get things into orbit. You absolutely need a minimum of 2 additional stages to get even small satellites into orbit. While SSTOs are quite easy in the fantasy world of Kerbin, on earth they are near impossible.
  7. Ruedii

    1.5.1 Hotfix

    Thanks for the fast fix. I didn't notice the issue, but I'm sure other people ran into it.
  8. Any chance we could get a control node for being in a specific altitude range? I need that for a mission I want to build. We also could use variable storage, a Boolean expression node and an advanced algebraic expression node. (Check if an algebraic expression is true, and do something as a result.) You should be able to access a wide number of stats about the current in-flight in this node, making it a universal advanced configuration node.
  9. No, and in fact I just read the API documentation a few days ago. I'm just really familiar with what causes problems in object oriented code. (Sort of a natural with object oriented and prototype-oriented code). BTW, there is a switch to hide and unhide stage icons, while it also isn't used in-flight anywhere, it is far more likely to be safe, as it retains the staging order objects were placed in. You probably should see about using that. This way you aren't destroying and creating objects dynamically in-flight, which always slows stuff down. Simply hiding and unhiding always works better than creating and destroying. I also noted you were not assigning staging order to objects before creating the icon. That might be the issue. Recent compiler changes in Unity made null and void no longer equal zero in a lot of objects, and I noticed that KSP had a unity version release. Still, the easiest way to deal with this is just assign a deactivated staging icon to every single part in the game during game loading (all the way back at the loading screen before the title screen.)
  10. Ruedii

    KSP Weekly: The Moon Race

    Yeah, and a half-powered variant of the swivel, and a selective mount base for the vector.
  11. Ruedii

    How about a 1.875 SRB?

    EXACTLY! Also (when using the same fuel) a smaller radius booster of the same length will create the same amount of thrust for a shorter amount of time. Yeah for science! It's perfect for that massive off the pad TWR that is so Kerbal! Furthermore, thinner, means less drag! However, yes, why not both?! 1.8 sized would be perfect for attaching to the sides of our behemoth rockets.
  12. The thing is that the Chetah contains Size 1.5, and Size 1 bulkhead modes. It's mode without a base mount is a Size1 and with a base mount is size 1.5. It thus has two shroud nodes at the bottom as well. The upper one is a Size 1, the lower one is a Size 1.5
  13. I'm going to look deeper into your exact issue, though. I found the documentation, and I'm going to RTFM when I get home this afternoon. I'm already running late. However, I highly recommend moving to a behavior that doesn't create and destroy staging icons inflight, if only for the sake of optimization. The create routine for stage icons wasn't intended to be run on a frequent basis, and thus will likely lag you a lot. It seems that a null comparison is fine in C# to detect the instance of an object. I personally don't like that method of doing things, but I didn't create the programming language.
  14. Well, staging icons weren't really designed to be added and removed dynamically, and thus should not be considered an operation to do safely. Running part.stackIcon.CreateIcon while the game is inflight is an unsafe operation. The game pauses to avoid unsafe behavior when handling part detach and part destruction removal of staging icons, and resetting the staging order when docking. Pausing the game frequently is not something I would recommend. The way I would recommend fixing the issue is just doing it in a manner more inline with standard KSP behavior. You should instead take parachutes as a model for behavior. You should have the icon attached to the base tree of the part from KSP's startup. (This can be inserted by your module). For any state indicator you should change to color of the icon. You should never have to remove or add an icon add an icon. The icon should be added in the parent object that attaches in automatically to every BDArmory object with the specified capability. It should be attached automatically before vessel-load and only be removed when the part is removed from the craft, and KSP automatically removes icons for destroyed and detached parts, so you shouldn't have to worry about this. In other words, this code shouldn't be necessary at all, because your mod should be written so that the icon exist attached to the part at least from the VAB, if not from game startup.
  15. A few quick sanity checks first before you pester the KSP devs: This is an issue with DLLs? This appears to be an issue with porting to Win64 architecture (i.e. changes to the INT and Pointer typings). Are you ALWAYS handing ints and int32? Are you moving an Int32 to an Int and back to an Int32? Are you moving a pointer into an Integer of any sort? While Int32 should be type-compatible with Int and Long, there are options in the compile template in Win64 to override this standard. This results in various issues. They are not type compatible with Pointers. Simply put, never cross types. If it's a pointer, ALWAYS use a pointer, if it's an Int, ALWAYS use an Int, if it's a Long, ALWAYS use a Long, and if it's an INT32 always use an INT32. NEVER assume they are compatible even if they traditionally are. I hope that helps. If not, default to the devs.