Poodmund

Members
  • Content count

    832
  • Joined

  • Last visited

Community Reputation

859 Excellent

About Poodmund

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

7046 profile views
  1. I very much like the look of Gersemi. I hope you continue to keep knuckling down and working on this, it shows some good promise.
  2. This is all looking really nifty now. Congrats on the recent major implementations.
  3. *Insert quip about the Monkey SQUAD business name and logo here*
  4. [1.1.2][Kopernicus] Stock Planet Expansion

    This is a pretty nifty trick you have here, TWG. Congrats.
  5. [1.3.1]TextureReplacerReplaced v0.5.2

    As someone who is offering a "Texture" mod at the moment, I am currently packaging it in a way that supports the directory structure requirements of 'TextureReplacer' whilst also including a config file in that directory that patches in compatibility for 'TextureReplacerReplaced'. Hopefully that way it covers most ground for the end users.
  6. The MM issue, maybe, was the fact that Scatterer's default behavior was set to resave the config files on scene change. Due to some configs using the @ (Edit) node modifier to change existing configs the 're-saving' of the configs perhaps adding in the new, edited config node patch below the existing patch which was causing the configs to double up and all get added to each other within the same nodes. Basically got really messy. I think this was resolved if the option was turned off. Thats all off the top of my head. It would require verifying that it is the case. @Galileo, did the issue with coloured (not 255,255,255) EVE cloud layers getting recoloured back to 255,255,255 when 'integrateWithEVEClouds' was enabled get fixed?
  7. That method won't really work with what I require though as then TextureReplacer and TextureReplacerReplaced would have to have a dependency on, say, "Skybox-provides" of which then all the skyboxes on CKAN would have to update their metadata with a "provides: [ "Skybox-provides" ] " which is unreasonable as not everyone who installs Texture Replacer or TextureReplacerReplaced necessarily wants to have a custom skybox... also the two said dependent mods are not my mods, I have no involvement with them, and as such I shouldn't be making requests on them to be dependent on my mod(s) to achieve this behavior. Does that sound reasonable/make sense? EDIT: Ah, it seems TextureReplacerReplaced currently "provides": ["TextureReplacer"], so it is listed as a possible dependency satisfier when one of my skyboxes is selected for download in CKAN. I now get what you meant @HebaruSan with your above post. I can specify my mods to require TextureReplacer but TextureReplacerReplaced can be listed as a provider of that identifier also. All is good.
  8. Does CKAN have the capability to list dependencies as an OR case? For example, you require either Mod A or Mod B but not both. I am trying to add support for TextureReplacer and also TextureReplaceReplaced at the same time but let the end user decide as to which they wish to use but I would require an OR behavior in the metadata dependencies node.
  9. Currently in a predicament where I do not have access to my PC due to flooding but as soon as I do, I'll be sure to check it out. ... and no, that wasn't a cue for a Scatterer KSC glitch joke.
  10. StarMods:  Selection feedback.

    The issue here with "Star Mods", I feel, is that by a SQUAD representative posting a mod in the "Star Mods" section on the Official Kerbal Space Program Forums they are pretty much endorsing said mod as being a good, solid representation of what their game is/can be/can do . What has obviously got people upset is that they feel the are mods out there that have been released that haven't been given endorsement by SQUAD that they feel does represent what KSP is or can potentially be whilst a particular selection are being listed in the "Star Mods" section that are either not currently 'fleshed out', are of a much lower standard compared to others or could subjectively be argued against being a good representation of a mod for Kerbal Space Program. All this being said, I think a simple solution would be to get those who chose the mods that get featured to actively be involved in the playing community of the game to grasp an understanding and better knowledge of the modded KSP community. EDIT: To add to the above point, generally a lot of modders don't even play the game anymore as they spend most of their time with KSP either coding plugins, doing artwork etc. I don't see why being a SQUAD member of staff, having to work with the game in a job environment, would be much different. Maybe its time to outsource these decisions to community based members/community based group?
  11. The solution is discussed here: However, I am not sure that it can be resolved unless the light parts are re-exported through Unity.
  12. SO... for patches that need multiple passes, how should we get around this issue?
  13. PQS mesh colliders only allow for convex surfaces so Caves or Tunnels are not possible.
  14. On the contrary, tidal locking of a satellite to its primary body is exceedingly common: https://en.m.wikipedia.org/wiki/Tidal_locking
  15. Just spitballing here Linux, but would it be at all conceivable that a Rectangular Array function could be possible in the Editor scenes when adding parts? The Rotational Symmetry tool is just a polar array around the part's origin at the set radius of the collider mesh's distance... could you specify a rectangular array to do something similar (even if its just limited to one row) so that you could place down like multiple parts down in a line with equal distances between them? This would be useful for situations like placing down lines of Solar Panels, equidistant lights down a vessel etc. Let it be known I have no idea how this could be implemented as its not something like changing an existing behaviour but introducing a brand new one.