DMagic

Members
  • Content Count

    3,994
  • Joined

  • Last visited

Community Reputation

3,727 Excellent

About DMagic

  • Rank
    Capsule Communicator

Recent Profile Visitors

15,241 profile views
  1. I think the issue is basically this: Those new engines are absolutely tiny, but seem to have about the same amount of geometry and texture detail as the new (not so new any more) Poodle. They don't look they came from the same period in KSP's development. Instead of having a new set of parts all approaching the same level and detail and quality we seem to be getting a new range of parts, all of them higher quality than the old versions, but still wildly inconsistent.
  2. It's clearing the depth texture before rendering, so it no longer knows what is in front of what (that's a simplification, it likely only applies to some aspects of what it is rendering) so you get transparency. Is there any reason why the clear flag is set to Depth instead of Don't Clear?
  3. Basic Orbit version 8.4 and Basic DeltaV version 5.2 are out. Basic Orbit 8.4 fixes a bug with the background image for the readout panels and adds a new Total Maneuver Node readout. When more than one maneuver node is created this will display the total dV required for all active maneuver nodes. It should work in KSP versions 1.4 and up. Basic DeltaV 5.2 fixes a bug that caused the stage group dV indicator box to become very large. There is also a known issue that sometimes the stage list will become unresponsive after creating a new stage group while in flight. Usually toggling the stage group extra info panel will fix the issue, as will switching to a different vessel. @Psycho_zs Torque is basically related to the amount of thrust directed off-center. Tilting an engine will give torque; engine gimbaling in flight will also cause the torque readout to change. My guess is that those very small torque numbers you are seeing are due to rounding errors, or something being slightly off center.
  4. You just have to tell KSP which module is going to be varying the drag, otherwise it will just get confused about which drag cubes to use. Anything that implements IMultipleDragCube (ModuleJettison, or ModulePartVariant) can do that. But only one can be active. So you have to set useMultipleDragCubes to false for any module that you don't want controlling it, as it seems to always be set to true by default.
  5. While looking at this same issue for some other parts I came to the conclusion that using the part variants to generate drag cubes doesn't make as much sense for vacuum engines like these. You can either have drag cubes based on the different variant sizes, or have drag cubes based on the shrouded vs unshrouded version of the engine, but not both. For vacuum engines it almost always makes more sense to use drag cubes based on the engine shroud. That way, when the engine is in the middle of a stack its drag cube makes sense and matches that of similarly sized engines and other parts. When using drag cubes based on the part variants you get penalized for using anything except the biggest variant. When the engine is used in the middle of a stack and its shroud is turned on, then it behaves as you would expect it to. Turning off the shroud would cause a interruption in the drag, as you would expect. And when the engine is placed on the end of a stack then it should still, in most cases, work out okay. You can do this by setting "useMultipleDragCubes" false in ModulePartVariants and set it to true in ModuleJettison (you can't set them both to true, if you do it just reverts to using procedural drag cubes and the result is more less the same as setting it true in only ModulePartVaraints). There is also some benefit to manually adjusting the drag cube from there, but that would be different for each engine.
  6. Orbital Science does not use Contract Configurator and the anomaly survey science does, in fact, use the Flying Low situation for any results that are collected with the anomaly scanner while not landed on the surface. The anomaly science does not conform to standard science in any way, including this one.
  7. DMagic

    [1.4.5, 1.5.1, 1.6.1] PartInfo

    It tells you the filepath for the part's config file. If you want to write a MM patch targeting that part then you should use the actual config file to verify the part name.
  8. DMagic

    KSP: Graphics API?

    On Windows KSP is a Dx9 game. It can be forced to run in Dx11, but I think there are some problems with that in later versions of KSP.
  9. The stock science parts for Universal Storage are no longer included in Orbital Science. The old parts are for Universal Storage 1, which is no longer supported. A future update to US2 will include new wedges for all of the stock science parts. @_Zee That probably means that the Orbital Science code was the last thing written to the log file before the error. All that code is doing is changing the location metadata for some icons so that they work with contracts. The XRay icon is the last one modified. The log entries from your other post are related to the deprecated US1 science parts.
  10. @MrSystems @BlackHat The FOV value takes into account the celestial body's radius (based on the ratio of that body's radius to the home body's radius), so a scan of Minmus has a much wider scan width than that of Kerbin. But the variance is limited, I think the values are capped at an FOV of about 20, meaning a scan would uncover a 40x40 area on the surface (with maps for all bodies being divided into 360x180 unit grids), and the FOV will never go lower than the value in the config file when scanning at or above the ideal altitude (and below the max altitude). The "resolution" or detail of the maps is basically irrelevant for everything by the low resolution altimetry scanner. All other maps are effectively infinitely detailed; you can zoom in to the point where you're looking at a few meters per pixel, or less. Making the scanning altitude more complicated feels a lot like adding complexity for the sake of complexity. Having fixed altitude ranges means you never have to think about how high or low your orbit must be for a certain body. There are a few edge cases where modded planets are very large, but no MM patches are provided to adjust the SCANsat sensor altitudes, those cases would be best addressed by proving MM patches to do handle that. @eatU4myT I think you would just have to add the other SCANsat parts to the Contract Configurator config files provided by SCANsat. I'm not really sure about the config format for allowing different parts to unlock the contract. Someone more familiar with Contract Configurator would have to handle that. It would probably be best to bring up the issue in the Probes Plus thread.
  11. DMagic

    Universal Storage II

    I think the weirdness that happens when loading sub-assemblies, saved crafts, and reverting has to do with the way the editor loads parts. It handles loading a part very differently from bringing a new part in from the part list. This can really trip things up in some cases, so that probably needs to be looked at. For USModuleSwitch you can target as many fields as you want within one module as long as they are on the same target module. MODULE { name = USModuleSwitch SwitchID = 1 TargetModule = ModuleConnectedLivingSpace //Only one target module per USModuleSwitch TargetFields = passableWhenSurfaceAttached|surfaceAttachmentsPassable TargetValues = true;false;false;false|true;false;false;false } You just have to make sure to separate the values correctly: '|' to separate target fields, ';' to separate the desired value at different switch states.
  12. @_Zee Keep in mind that the values in the config file are only used as defaults for new save files (or existing save files when first installing the mod). The actual values are stored in each game's persistent file. The in-game window allows you to revert to either the defaults specified in the config file, or the stock values.
  13. These two parts are supposed to be different versions of the same thing right? That's what I always thought. Looking at the old versions they definitely look like basically the same thing: Same color and basic shape, same fuzzy white text, similar details on the body of the engine, the engine bell looks similar, the tubing the looks the same. That doesn't seem to be the case anymore: They both have the same orange color (or similar, I can't tell if they are actually the same), but that's about it. The engine bells don't look at all alike, the Spark has lots of other engine details while the Twitch has none, and the Twitch has those weird square panels that show up everywhere. I can see them having different stats. The Twitch could reasonably be assumed to be used in pairs or groups, and is smaller, so lower thrust makes sense. But it's a shame that the two paired engines couldn't be designed to show that they share the same heritage.
  14. DMagic

    I made a thing

    @Shpaget It's only available in primarily English speaking countries now. I want to get some translations done before releasing it more widely. Localization support is already there, it's just a matter of translating the relatively small amount of text and making sure it fits in the UI. It seems unlikely that I'll get to Serbian any time soon, but I figure if I can get it in a handful of languages then most people will be able to find something they understand well enough to play.
  15. I think I see it now. So the top part, which is bolted to the base, is fixed, and the bottom pivots on that recessed, grey section just below the bolts? The pistons can move together to pivot in and out and move different amount to pivot side to side? That's pretty neat.