Jump to content

Starstrider42

Members
  • Posts

    866
  • Joined

  • Last visited

Everything posted by Starstrider42

  1. For those who might stumble across this post later: It turns out that, while the coordinates do change between game instances, KSP always handles them self-consistently in the sense that the statement orbit.UpdateFromStateVectors(orbit.getRelativePositionAtUT(ut), orbit.getOrbitalVelocityAtUT(ut), orbit.referenceBody, ut); never changes the orbit. However, the coordinates are in the frame given by Planetarium.ZupRotation, so any attempts to transform those coordinates need to include rotations by ZupRotation and/or its inverse.
  2. There will be a patch release of Custom Asteroids out within a few days. This patch will fix the Custom Barn Kit bug (though AFAIK sarbian's already done a workaround on their end), the inclined orbit bug, and a compatibility bug with Extraplanetary Launchpads (and any other bugs I spot along the way).
  3. I would never have guessed that casting Instance to a generic object would make a difference (heck, C# is the only language I can think of where it *could* make a difference). Thanks for the help. @Thomas P., I believe the same bug can appear in Kopernicus.
  4. Pretty sure the reference is up-to-date, since I don't cache it or anything: if (GameVariables.Instance == null) { #if DEBUG Debug.Log("[CustomAsteroids] GameVariables.Instance not found!"); #endif // It probably means the game isn't properly loaded? return false; } This is called periodically as game time advances, so it's not a first-frame-after-scene-change bug or anything like that.
  5. The root cause is that GameVariables.Instance appears to always be null. Sarbian, is there some alternative API we should be using to check facility levels?
  6. It looks like RoverDude updated the compatibility data 2 hours after your post.
  7. Well, that didn't give me any great insight. You load the stockalike and inner-system configs successfully, shut down the stock spawner, and then... nothing. No errors, no warnings. There's errors from other mods (especially Contract Configurator, don't know if you were aware of that), but nothing that looks like it should affect Custom Asteroids. I'll look into the Custom Barn Kit angle... the only thing I can think of is that the asteroid spawner might get confused about whether the tracking station has been upgraded or not.
  8. The expression "@RESOURCE[@name[MetalOre]]" looks for something like: RESOURCE { name = @name[MetalOre] } which doesn't exist. You need to use "@RESOURCE[MetalOre]", like in the first example I listed, or "@RESOURCE:HAS[#name[MetalOre]]", note the # and :HAS. All your smelter patches have too many closing braces, which causes KSP to skip reading the rest of the file. Possibly related, your smelter patches don't mention ExConverter, so they look for resource nodes that are directly under the part. Try, e.g., @PART[Smelter] { @MODULE[ExConverter] { @INPUT_RESOURCE,0 { @ResourceName = Ore @Ratio = 1.0 } @INPUT_RESOURCE,1 { @Ratio = 60 } @OUTPUT_RESOURCE,0 { @Ratio = 0.5 } } } That should be it.
  9. The Wiki is helpful, but I think ,* (btw, asterisk ≠ Asterix) might not actually be needed any more -- the default behavior is to mod everything that matches. When I tested your patches, the descriptions and titles appeared to be fine -- it was only the actual resources that didn't get changed. In my experience that only works for values. I posted about it on the MM thread a while back but didn't get any answers that weren't workarounds.
  10. Hi all, There's a bug on the inclined orbit code that causes it to only give the right answer in new save games. I'll release a hotfix once I figure out the cause (so far, all I know is that the position and/or velocity reported by an orbit can be completely wrong), but for now don't use it.
  11. Well, your first config refers to a module called "ResourceName", which isn't found in any part. I don't think the ".*" is valid syntax, either (though I could be wrong). Try: // Fix resource storage @PART:HAS[@RESOURCE[MetalOre]]:NEEDS[Launchpad]:Final { @RESOURCE[MetalOre] { @name = Ore } } // Fix resource conversion @PART:HAS[@MODULE[ExExtractor]]:NEEDS[Launchpad]:Final { @MODULE[ExExtractor]:HAS[#ResourceName[MetalOre]] { @ResourceName = Ore } } // Fix resource conversion @PART:HAS[@MODULE[ExConverter]]:NEEDS[Launchpad]:Final { @MODULE[ExConverter] { @INPUT_RESOURCE:HAS[#ResourceName[MetalOre]] { @ResourceName = Ore } @OUTPUT_RESOURCE:HAS[#ResourceName[MetalOre]] { @ResourceName = Ore } } } // Fix resource detection @PART:HAS[@MODULE[KethaneDetector]]:NEEDS[Launchpad]:Final { @MODULE[KethaneDetector] { @Resource:HAS[#Name[MetalOre]] { @Name = Ore } } } // Fix resource detection @PART:HAS[@MODULE[ModuleResourceScanner]]:NEEDS[Launchpad]:Final { @MODULE[ModuleResourceScanner]:HAS[#ResourceName[MetalOre]] { @ResourceName = Ore } } // Fix resource detection @PART:HAS[@MODULE[ModuleAnalysisResource]]:NEEDS[Launchpad]:Final { @MODULE[ModuleAnalysisResource]:HAS[#resourceName[MetalOre]] { @resourceName = Ore } } (The :HAS on the top-level parts is not strictly necessary, and prevents you from having one @PART block around everything else, but why should ModuleManager have to carefully scan each and every part that's unrelated to resources or EPL?) BTW, you may need to adjust the ratios on ExConverter for the modified conversions to stay balanced. I'm not sure if that was an oversight or not. For the second patch, the experience and productivity patches appear to be correct. For the unmanned bit, try either "%IgnoreCrewCapacity = true" (the old version did nothing if the config did not have IgnoreCrewCapacity) or "!IgnoreCrewCapacity = anyvalue" (the old version should have been marked as invalid, as it had neither = nor {}). I can't comment on whether these changes will actually enable probe builds, it's been a long time since I've played EPL. The biggest problem with the third patch is that it's run in the second round of MM patches (since you don't give a :FIRST, :FINAL, :BEFORE, :FOR, or :AFTER). Since ExSurveyStation is itself created by a MM patch in :AFTER[Launchpad], the part does not exist at the time you're trying to modify it. Since you need to force execution after :AFTER[Launchpad], I'd suggest using either :FINAL or :FOR[<my-mod-name-that's-alphabetically-after-L>]. A second problem is that the station already has an ExWorkshop, so after your patch there will be two. My final recommendation is @PART[ExSurveyStation]:NEEDS[Launchpad]:FINAL { @MODULE[ExWorkshop] { %ProductivityFactor = 2.5 } MODULE { // Only produces parts at half the speed of the full workshop, // but it allows for building smaller ships and bases. name = ExConverter StartActionName = Start Part Production StopActionName = Stop Part Production INPUT_RESOURCE { ResourceName = Metal Ratio = 0.00975 } INPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 5 } OUTPUT_RESOURCE { ResourceName = RocketParts Ratio = 0.35 } } } (I *really* wish MM had a way to say "create a module by this name or modify it if it already exists", but as far as I know doesn't.) I can't help much with the fourth patch, because I know nothing about part models. Reading GameData/ModuleManager.ConfigCache (which is an excellent MM debugging method, I highly recommend it), the modified ExWorkshop config has: MODEL { model = ExtraplanetaryLaunchpads/Parts/Workshop/workshop position = 0.0, 0.0, 0.0 rotation = 0.0, 0.0, 0.0 scale = 1.0, 1.0, 1.0 texture = ExLtweaks/Textures/Workshop/Hatch, ExLtweaks/Textures/Workshop/Hull } Is that what it's supposed to look like?
  12. I found something weird when trying to debug a new feature in Custom Asteroids (https://github.com/Starstrider42/Custom-Asteroids/issues/26). Can somebody explain this to me? Load Custom Asteroids with the following config only: (For those not familiar with CA config syntax, this creates asteroids on a fixed orbit, always spawning at the same place). Start a new KSP (1.1.0) game and let the spawner log the orbital elements and state vectors of new asteroids: Exit KSP, restart KSP, load the game from step 2, and let some more asteroids spawn: The tracking station shows the asteroids spawning on the same orbit in the same spot. The orbital elements are identical. Yet the state vectors have not only absolute values different by about a percent, but OPPOSITE SIGNS in the two sessions. Why is this? In case anybody wants it, the code behind the logging:
  13. That doesn't sound like something that would be caused by Kopernicus. If you send (or upload) the log I can take a look at it.
  14. I'm pleased to announce the release of Custom Asteroids 1.3 for KSP 1.1.x. At the risk of sounding like a parrot, this is the biggest change to Custom Asteroids since the 1.0 release. There are lots of new features for config-writers, though it may take a while for them to become visible to other users. New Features Limited support for different asteroid types -- affects science and resources, but no new appearance or 3rd-party integration yet. Can now customize asteroids on intercept trajectories with any celestial body. Asteroids can now appear only under certain conditions (body visited, orbited, currently on the surface...). Asteroid population blocks now support the log-normal, (rescaled) beta, and gamma distributions. Asteroid .value syntax now supports several characteristic periods and speeds. Asteroid orbits can now be given relative to an inclined plane. Useful for mods like RSS and Harder Solar System. Changes DEFAULT config blocks are now deprecated. They will be removed in version 2.0.0. Stockalike asteroids have been split off into their own config file. Only stockalike asteroids are included by default; you can copy the other configs from the "Standard Setup" folder in the zip. Some tweaks to asteroid spawn rates. ModuleManager is now required. Bug Fixes Invalid populations will no longer stop other populations from loading. Near-Kerbin asteroids will no longer appear on unbound orbits, and are much less likely to appear in the main belt. A large number of asteroids will no longer appear when the tracking station is upgraded while using the fixed-rate spawner. Mean anomaly and mean longitude of celestial bodies are now calculated correctly. Yes, Thomas P. and I discussed things a bit but never came to an agreement on how to handle dual installs. I think the burden will be on config-writers to use ModuleManager to detect when both mods are installed and select whose system to use. On the subject of mod conflicts, Asteroid Recycling Technologies and DMagic Orbital Science only work with Stony asteroids at present. I've alerted the developers of both mods about the problem, so it should be fixed soon.
  15. Sorry, I didn't learn about the 1.1 release until yesterday (apparently the Steam pre-release program doesn't actually dump you out of pre-release mode when it ends ). I have to make some changes in CKAN related to the new zip format, plus since this is an official release I'll have to go through and test everything all over again... I'll try to have Custom Asteroids 1.3 out by the end of this weekend, but probably not sooner. Glad to hear it. However, I don't really know in detail what CactEye is doing, so I can't make any promises about current or near-future compatibility. BTW, what are the four? I can only think of CactEye, Kopernicus, Custom Asteroids...
  16. There is, in fact, an automation tool, NetKAN. AFAIK it isn't a push system, it polls download sites (in particular, SpaceDock and GitHub) periodically. Don't know what the period is.
  17. Slight change for KSP build 1209: now only asteroid configs are separated from the main Custom Asteroids install; the new part/science definitions are always included. It should make things easier with third-party packs. I think this is the arrangement I'll want to use for the 1.1 release, so please let me know if it works for you.
  18. A beta version of Custom Asteroids is now available on GitHub for KSP 1.0.5 and KSP 1.1.0.1183. This is a beta, so I take no responsibility if you use it in your main career save and stuff breaks. As this is a development build, expect more log spam than in official Custom Asteroids releases. Also, don't get confused by the "Survey Asteroid" button that shows up in asteroids' right-click menus: that's a debugging feature that won't be present in the final release. (If you encounter a bug related to resources, though, by all means click it and send me the log. ) Key changes: Asteroid config files, parts, and science definitions have been separated from the "main" Custom Asteroids install, as suggested by @CaptRobau and @wasml. Let me know how it works, both from a "normal user" standpoint and from the point of someone who wants to write configs but not make new asteroid types. Partial support for custom asteroid types. These do NOT have models yet (though I'm hoping the new AssetBundle feature in 1.1 will make those a lot easier), but do have science flavor text and their own resource distributions (only resources from Community Resource Pack are supported, but you'll see the resources even if you got them from a different mod). You can now create asteroids on intercept trajectories with any celestial body. Asteroids can now appear only under certain conditions. Asteroid orbits can now be given relative to an inclined plane. Useful for mods like RSS and Harder Solar System. See http://starstrider42.github.io/Custom-Asteroids/newbelts.html for how to configure the new features. Known issues: There's no way to identify the type of an asteroid until you claw it. Some asteroid mods will only work correctly with stony (a.k.a. stock) asteroids. I've raised the issue with the appropriate mod developers. I don't expect to be around for the rest of this week, but please leave me your feedback and I'll get back to you.
  19. If you mean with the spawner, then yes. Neither Kopernicus nor Custom Asteroids use the stock spawner, so Cacteye's spawner may conflict with them. One of my planned features is an API to let Custom Asteroids talk to other mods' spawners or vice versa, but that's a long way off.
  20. Sorry, I wasn't clear. That's also not supported at present -- the difference is I think I can actually add a feature like that (probably to the release after next, since I really shouldn't add more to what's already lined up for Custom Asteroids 1.3). Sorry to disappoint.
  21. Well, you can make a specific orbit just by setting all the orbital elements to <element> { dist = Uniform min = <value> max = <value> } Size control is not yet supported. I'm not sure about the "single asteroid" bit. Do you mean that you'd want a config to create a single asteroid, at some point in the game, and then remember to NEVER create any more asteroids until you start a new game? I'm not sure how to do that, especially when configs can be edited or changed out. Will "one asteroid exists at a time" be good enough? Broader question for everybody: I've seen the hype about the 1.1 pre-release. Would people be interested in a beta version that works for the 1.1 pre-release (although, TBH, I doubt I'd be able to create a new Custom Asteroids build for each pre-release build)? This would also give me a chance to try out @wasml's suggestion for re-organizing the download.
  22. I consider that the solution of last resort, because then the MM patch wouldn't preserve the order in which resources are declared. Since KSP save files don't record which numbers go with which resource, the effects on an existing save game would be... amusing.
  23. Ok, I thought I knew how to write ModuleManager configs, but I've run into a problem that has stumped me. Can someone point out the obvious mistake I'm making? I'm trying to write a config that adds the Water resource to asteroids if it is absent, or modifies the existing resource if already present (e.g., from Community Resource Pack). My first attempt was: Testing with Community Resource Pack installed finds that the patch always adds a new ModuleAsteroidResource, ignoring the water resource that already exists (even though an @ operator with the same syntax lets me update the existing resource, as expected). My second attempt was: As written, the first patch does not match (when it should), while the second matches (when it shouldn't). I've confirmed that removing the redundant :HAS clause on the first patch's @PART causes it to match, while removing the :HAS[#resourceName] clause from the second patch causes it to not match. Can anybody tell me what I'm doing wrong? The manual does not list :HAS as a forbidden option with the % operator (it only rules out wildcards and indexes), and while I can't find any documentation on the allowed contents of :HAS blocks, what I'm trying to do seems similar to the examples (e.g., "engine using a specific fuel").
  24. It's been way more than two minutes, but in case anybody else is wondering: no, I don't foresee any problems. I'll be updating the KerbalStuff links to point to SpaceDock shortly.
×
×
  • Create New...