Jump to content

Hyomoto

Members
  • Posts

    980
  • Joined

  • Last visited

Reputation

317 Excellent

Profile Information

  • About me
    Kerbal Space Industries

Recent Profile Visitors

3,493 profile views
  1. Well this was weird. I found the culprit. Digging through the files we can see the base attributes are applied by OPT_00Clean.cfg, and then OPT_B9PS.cfg is used to add the switch module using those attributes. That is really clever. I don't know if there's a way to inspect parts to see if the first patch is applied, but assuming it is then the issue lies here: // = = = = = = = = = = = = = = = = = = = = = = // Create fuel module @PART:HAS[#manufacturer[OPT*Division],#refVolume[*],~TankTag[OPTlab]]:NEEDS[B9PartSwitch,!ConfigurableContainers/Parts,!Pathfinder,!ModularFuelTanks,!RealFuels] { MODULE { name = ModuleB9PartSwitch moduleID = #$../TankTag$ switcherDescription = OPT Tank switcherDescriptionPlural = Tank Selections switchInFlight = True baseVolume = #$../refVolume$ } } Well, MM never calls this out so NEEDS, as far as I can tell, are being satisfied. All the other blocks that fail the test are culled. So, we're left with the HAS block. If the first config is properly applied, which its at least safe to assume it is, then all these tags are correct except for one, the manufacturer tag: title = #LOC_OPT_j_2m_tanks_title manufacturer = #LOC_OPT_manufacturerA description = #LOC_OPT_j_2m_tanks_desc As far as I can tell, that won't pattern match. But, that's because if this is meant to do localization, it's not applied. Check the screenshot above. Interesting. So, what does the localization file say? That the tag is not defined. Which, leads me to believe that localization is applied before these MM does its patching, and that would explain why it's not matching. So, where is that definition? I checked legacy and it's not there, and I even went back to the original OPT which didn't have localization files at all. Checking the git history, this name wasn't in the original commit either. It was added to OPT Reconfig in October 2020, but it's not present in OPT branch so what bugged ass release did I download? Apparently the github link on the main page leads to the wrong file and that file happens to be missing this string. This week has just been a "How does KSP work" week for me a I guess. So in short, if you do use the GitHub link, you have to go to the repository and download the latest release.
  2. Well, this is weird. B9PartSwitch isn't working. Digging through the log, nothing from OPT_B9PS.cfg ends up being applied to the parts. It seems like the nodes do end up matching at some level, but the module itself is never added. The best I could muscle out is that HAS[#moduleID[]] is perhaps unsatisfied since I couldn't find where these module ids are applied and they didn't seem to be part of the base parts. Of course, digging through all the configs looking for it I might just have missed something. Nevertheless, the result is that none of the structural pieces or wings have tanks added to them when using B9PartSwitch. Other mods are properly apply it to their parts, so the part switcher is installed correctly, these parts just aren't having it added. Edit: nope, tried to just brute force add the module by getting rid of the HAS and it did not work. Something else is afoot.
  3. I think I was on an older version of Parallax and that's why I thought the experiments were still sunk. I first tried this at 1.2 but apparently missed the 1.2.1 and 1.2.2 updates and hadn't played with the experiments since then. They are still troublesome, they don't always rise properly, but it sounds like you are already on the case which is exciting. I may not have done anything useful but I guess I learned how to set Visual Studio up for KSP (the forum post is out-of-date, it says use .NET 3.5 but Kopernicus was compiled against 4.7.2, etc...).
  4. Well, that was a waste of time . I resolved all the conflicts and was able to update and recompile the DLL. Problem is, apparently the instruments already float to the surface. I assume that is your doing because the issue ends up being that when you go to place the instruments they claim to be an on an illegal spot. However, if you walk around and spam the space bar you can usually find some location that will allow placement. Once on the ground, if you bump them they'll just rise to the surface. Neat. So the trouble is just getting them placed in the first place, otherwise it can already find the offset and makes all that work on my end pointless. Huzzah! It seems like placement is "bugged" in this case. I might take a stab at fixing that but given how useless my original efforts were, I figure it's best to ask if you have any thoughts on that first. Is this a known problem? Are they supposed to float to the surface?
  5. You mentioned that it would be difficult to have arbitrary shapes interact with the parallax system. However, there are some parts which probably could be included that aren't and might be expected to be: science deployables. I'm going to feel like a jerk for writing this, since I would prefer to test this myself instead of fire off a "this should work" and wander off, but I'm not set up for KSP modding. I can only prostrate myself and beg your forgiveness (for the record I gave it a shot, but the setup guide only got me to 1191 type errors and I'm fighting both VS and KSP knowledge). That said, looking over ParallaxCollision.c you have a block which tests if the vessel is a single part and if that part is a Kerbal. Thus, extending line 165 to include a test for deployables should give favorable results? if (vessel.parts[0].isKerbalEVA() == true || vessel.parts[0].isGroundDeployable() == true) Again, I apologize for not testing it myself. I hate to offer drive-by coding advice. I'll probably still see if I can get it set up, but I am hoping it's just that easy to add those parts.
  6. Small update here. Did a bunch of testing, including rolling back to previous versions to see when exactly volumetric clouds stopped showing up and the answer is... they didn't work with any version. That seemed pretty suspect so I deleted settings.cfg and gave it a try again. In which case the clouds did show up again. So I went ahead and brought the game back up-to-date and again, clouds. So finally, I reinstalled all of my mods and its not working again. Dear lord. So then I start painstakingly installing one mod at a time to figure out which one is the death boi. Which, surprisingly ended up being the first mod I tried: Scatterer. Next up, try installing every mod except Scatterer and sure enough ... same problem. Alright. What the literal hell? So fiddle, fiddle, fiddle aaaaaand settings. It's definitely a setting. Resetting them back to default fixed the issue, but what the heck about them is causing this issue in the first place! I'm invested now, how can I not keep going? Reinstall scatterer, try again. Clouds are there. Hurray. Fiddled with a few graphic settings to see if I could figure out which one was the culprit but nope. So I have no idea what setting is breaking things, but it does seem to be a setting. That's a very long-winded way of saying if your volumetric clouds aren't showing, you can try reverting your settings to default and then reenable them to see if that fixes the issue.
  7. A modder can't live on praise alone, but it surely can't hurt! This is all stunning work. It reminds me a lot of when Scatterer first popped up, where there were a lot of issues but over time he figured most of them out. I didn't even see this until 1.2 beta, and it's crazy what you've been able to accomplish.
  8. I'm not sure a screenshot is really necessary here? The issue is the volumetric clouds do not display, but the cloud layers are visible. That said, if it helps then here is a screen shot without volumetric clouds: The cloud layers display, but the volumetric clouds do not. It's hard to see in this picture because they aren't there, but the clouds overhead still fade out as if the volumetric ones were being drawn but they aren't. Again, multiple texture packs, etc...
  9. I'd like to throw my cards in the "I'm not seeing volumetric clouds" hat as well. I tried Spectra and Astronomer's pack and neither of them display volumetric clouds. It looks like Spectra doesn't have layerVolume defined, but Astronomer's does and still nothing. I also tried the original BoulderCo and ... still nothing. For clarity, as far as I can tell, all other effects are present. There are the 2d layer clouds, and when you pas near to them they fade out as if the particles are being generated, but there are no particles. Is there an option somewhere I'm overlooking to turn them off(or more importantly on)? I'm using Scatterer.0.0723 and EVE-Redux1.11.2.1. Edit: Probably should've done this first, but I threw out all mods except for BoulderCo and EVE and ... no volumetric clouds. So, I'm really not sure why they aren't showing but it doesn't seem to be a mod conflict. Here is the KSP.log if that helps. https://www.dropbox.com/s/otl1vmx1kskzga1/KSP.log?dl=0
  10. Yes, that did it. Disabling steering on the rotor blades was definitely the issue. They are still difficult to fly, but in a way that doesn't feel like something very, very wrong is happening. I'd still love to be able to fix that, but hey, I can fly a helicopter now! Thanks! EDIT: More fiddling and ... I dunno. It seems like helicopters are broken. Not completely but there are definitely some odd interactions. It seems that particular issue I was having was localized to the rotor I was using. Using the dual rotor, things control mostly as I would expect, so much so it's even possible to control it without SAS! However, constantly I'll be flying straight with no issues and BAM, suddenly the helicopter will become unstable. Sometimes it's a minor nuisance, I lose a bunch of speed and press on, but other times the helicopter will just start violently swaying as I enter tiny corrections. It's never too far between these problems, but it does seem random how often it happens which almost makes it worse. It's like, it is flyable, and sometimes it's even pretty fun, but it feels really buggy.
  11. Are they just impossible to control without SAS? The reason I wasn't using it is because you get stuck trying to face whatever direction it was enabled at. So do you have to continually reset the SAS while flying? I mean, I can fly planes without SAS. You just have to build them well. In this case, that doesn't seem to be an option then? Turning it on seems to HELP, but it still seems utterly uncontrollable. Like, tilt forwards shouldn't be illegal, but I press forwards and I start to lean right. Again, I stress this isn't a "I don't know how to touch controls." situation. If it was as easy as "be gentle" I'd have circumnavigated the planet. It literally feels like it's completely broken to the point I'm fighting the controls. Based on your response that doesn't seem like the intended outcome, but I'm wondering what could be the problem then. EDIT: You know that gave me an idea, so I just switched to the keyboard and yes, pressing forwards leans right and pressing backwards leans left. That can't be correct. I swapped off steering on the rotor and that seems to have helped. I think I'm seeing the issue, it is completely uncontrollable and there are phantom inputs, but it's definitely firespitter.
  12. That reminds me, last question I hope, and I feel I have to ask: do the firespitter helicopter blades work? I see you have that V22 design, which I'll assume flies. In my case, I set the props directly over the center of mass but it behaves like there are phantom forces. If I tip to the left, the helicopter shouldn't swing back to the right... maybe? Like, if I touch nothing, it will be out of control. If I touch anything to try and correct it, it ends up even more out of control. They feel completely uncontrollable. Could just be my design of course, but you solved my cargo conundrum, perhaps you can explain why the helicopter parts seem to behave insane or perhaps I just have a bad something? This is the craft:
  13. I can certainly appreciate that but if I may ask a question, why not just make an offset that doesn't require doubling them up? I appreciate the "because it's more work than zero" reasoning, but it might be a nice part to have even outside of this particular niche (it's just this niche certainly adds to it's desirability). Amusingly the first thing I tried was that offset thinking maybe it had an alternate version. I was not clever enough to consider just stacking it.
  14. In that first plane it appears you are using a smaller spacer, do you recall what the name of that part is? Also, thank you for the feedback. I tried moving some stuff around and deleting parts, but it seems like the space is too tight. I'll have to give LGG's topic a try at some point, but if it's as simple as adding a spacer I'm not going to be upset. Edit: And yeah, adding a cargo tube seems to have added the necessary space. Apparently that part by itself is just a wee bit too small. If it's possible to tweak it, that would be awesome, but I'm glad it's functional nonetheless.
  15. So, this isn't a phenomenal picture, but last time I played you couldn't do this. Any of this. Well, flags have been around for quite a bit, but it's crazy how many things that used to be mods are now stock in one way or another.
×
×
  • Create New...