Jump to content

JonnyOThan

Members
  • Posts

    1,023
  • Joined

  • Last visited

Posts posted by JonnyOThan

  1. 59 minutes ago, Kimera Industries said:

    there's no hatch corresponding to the main upper node.

    There’s two reasons for this: there’s not internal space for that hatch and it’s not historically accurate (for Vostok/vokshod pods).  Is the kv-3 supposed to be a Soyuz?  Maybe I should take another look at that…

    1 hour ago, Kimera Industries said:

    I don't think my kerbals want to go on EVA

    You can place the inflatable airlock on the attachment node.  That’s what it’s for (and historically accurate).

    1 hour ago, Kimera Industries said:

    is it this mod or another one CKAN installed as a dependency that added an attachment node to the hatches/kerbal EVA spots? How well does a craft file port over to a stock game if something is attached to said node?

    That comes from FreeIva, so that you can connect an airlock or docking port etc.  as mentioned above. I’m not sure I’ve tried porting a craft file back, but I do know that attachment nodes are actually saved into the craft file/vessels in flight so I don’t expect anything bad to happen.

  2. 11 minutes ago, NyanTurian said:

    Which cfg file do you mean? I did a comparison of the bluedog_Apollo_AARDV_Cargo_Block1.cfg and it matches the one from the master on github.

    Ah apologies, it was in the master branch but committed since the last release:
    https://github.com/CobaltWolf/Bluedog-Design-Bureau/commit/8b279c0b4bcb85387d08cbeb483061e544679e99

  3. 9 hours ago, NyanTurian said:

    Has anyone had a similar issue with the current version of the mod?

    PartLoader: Compiling Part 'Bluedog_DB/Parts/Apollo/bluedog_Apollo_AARDV_Cargo_Block1/bluedog_Apollo_AARDV_Cargo_Block1' 
    (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)
    
    DontDestroyOnLoad only works for root GameObjects or components on root GameObjects. 
    (Filename:  Line: 589)
    
    Module ModuleB9PartSwitch threw during OnLoad: System.Exception: Fatal exception while loading fields on module ModuleB9PartSwitch on part  --->
    System.Exception: Exception while loading field subtypes on type B9PartSwitch.ModuleB9PartSwitch --->
    System.Exception: Exception while loading fields on subtype PartSubtype Supplies --->
    System.Exception: Exception while loading field tankType on type B9PartSwitch.PartSubtype --->
    System.Collections.Generic.KeyNotFoundException: No tank type named 'Supplies' exists

    I'm likely missing something somewhere since this is a new install. The mods I have installed are somewhat lengthy, but Kerbalism comes to mind as being possibly incompatible? When I uninstall Bluedog, these errors disappear.  Which mods changes the AARDV Cargo vehicle to have supplies?

    This has been fixed in the dev branch of bdb.  You can  grab the new cfg file off github.

  4. 4 hours ago, Ottomic said:

    I'm using Reviva with RP1, trying to get the DE_IVA probe control room. Unfortunately, the RP1 probes don't have the Reviva functionality on their PAW, and it's not defaulting to DE_IVA's. Is there a way to set up a default IVA outside of the PAW (even through modulemanager editing)?

    Yeah you just need to set the name of the INTERNAL in the part just like any other IVA.  There’s probably some kind of “last writer wins” thing going on.

  5. 3 hours ago, mark7 said:

    Can you give me some help?

    Ah I think the storedStrings are only used by the ASET MFDs, not the basic one that comes with RPM.

    If you don't already have a dependency on ASET props, you can write a patch to swap out the basic ones with ASET for your parts, just in case someone has it.

    Oh, and the font texture that the MFD uses only supports ascii characters, sorry :/

  6. 7 hours ago, mark7 said:

    Got it, thanks for your help. Can you provide an example patch or something so I can apply the fix?

    You can just add:

    MODULE:NEEDS[RasterPropMonitor]
    {
        name = RasterPropMonitorComputer
    }
     

    To any affected parts.  If you like, you can add storedstrings to customize the Home Screen of the MFDs. 

  7. 26 minutes ago, mark7 said:

    I'm not familiar with JSI nor RPM, but I guess this could be the problem.

    Yep, sure seems like it.  This part (and any others that use RPM stuff) needs a RasterPropMonitorComputer module:

    [ERR 18:39:51.434] [RasterPropMonitor]: No RasterPropMonitorComputer module found on part KCHS.SZ.Re.entryModule for prop RasterPropMonitorBasicMFD in internal RM_IVA

  8. 11 minutes ago, mark7 said:
    We noticed that there are issues related to Shenzhou spacecraft. When some IVA mods are installed, it could lead to game crashing when launching from vab using Shenzhou Re-entry Capsule or Orbital Module.
    We are looking into the nature of this problem and if anyone has similar issue, please contact us.
    A temporary fix is on its way.

    got any details further than "some IVA mods?"

    I've noticed that some mods that use props that require RPM (e.g. ASET) will crash the game if they're placed in an IVA whose part does not have a RasterPropMonitorComputer.  Sometime in recent history I changed RPM so that it no longer creates the RasterPropMonitorComputer module on demand, because creating partmodules at runtime generally isn't a good idea.  But this causes issues with mods that don't already have it set up and I've had to add compatibility patches as necessary.  If you have a log file I can take a look.

  9. 37 minutes ago, DeadJohn said:

    [TLDR if I understand Kerbalism correctly per-biome orbital scans have some unintended consequences. It might not be practical for Skyhawk to do anything about it. It's not game-breaking.]

    Thanks for your full reply. Regarding the part I quoted, though, I am talking about orbital per-biome experiments. For the atmospheric biomes, sure, build a plane and do some tight turns along the shoreline to stay within a biome; that's fun flying. It's not possible to fly that way when the experiment has to be run in orbit.

    The stock gravioli experiment is an example. With Kerbalism Skyhawk and specific tech tree nodes it becomes a high orbit experiment that needs a lot of time above every surface biome to complete. Staying in control of one satellite timewarping for years isn't fun and neglects other events, but it seems like background processing doesn't work perfectly for biomes.

    This is a consequence of planets that have detailed biomes. A planet with 12 equal sized biomes and a per-biome experiment that takes 90 days to run will need roughly 90d * 12 = 1080 days to scan the surface even if there are no KSP or Kerbalism glitches. The 100% scan time gets more extreme when some biomes are small rather than being a perfect 1/12 of the surface. A tiny biome that only covers 2% of the surface would theoretically take 4500 days to fully scan from orbit.

    This totally makes sense.  I wonder if it would be better to make the gravioli experiment NOT biome-sensitive from space, and instead increasing the science multiplier?  But I guess different experiments can't have different situation multipliers....or can they?

  10. 2 hours ago, AlaSupaKota said:

    I have an issue, there is simply no collision, I just fall through the floor, has anyone else experienced this? I have Module Manager 4.2.3, B9PartSwitch_v2.20.0, FreeIVA 18.3.2 and newest version of KSP, no dlc

    Are you the person who just joined my discord and solved this problem by installing the mod with CKAN?

    If not, I'd suggest installing FreeIVA with CKAN.  Or join my discord (the link is in the OP) and post your ksp.log file.

    On 11/23/2023 at 11:18 PM, orionguy said:

    Found an interesting bug with the MK1 Viewer's Cockpit from AirplanePlus

    BTW @orionguy I didn't mention it but I opened an issue here for tracking: https://github.com/pizzaoverhead/FreeIva/issues/369

    I haven't investigated yet but currently I hope to address this in the next release, whenever that is.  You can track progress here: https://github.com/pizzaoverhead/FreeIva/milestone/15

  11. 4 hours ago, Poppa Wheelie said:

    How do I change terminal font and font size from within the script?  I can see many fonts when I do "list fonts" from the terminal, but I can't figure out how to use any of them. I also see in the kOS documentation on github that I should be able to set Terminal:HEIGHT, but I can't seem to get that working either (although it does work on a "regular" kOS terminal).

    I want to be able to switch font and font size from within the script.  I was told at the r/kOS subreddit that adjusting Terminal:HEIGHT is the only method from within the script for regular kOS terminals.  It would be great if I could use the font used by the template to write the first line, with "CPU:   0  -", "KBRD", and "EXIT".  See how much smaller the text is in the printable part of the terminal.  And see how the top MFD is using several fonts and sizes (although programmatically, and not through the kOS script). 

    R7UzXLi.png

    4eNaHx0.png

    Yeah all the font stuff in kos is only going to work in the normal terminal.  The text in the MFD is controlled by RPM and the text files referenced by the MFD page configs.  You can edit these to change it - the easiest thing to do (and I think what you want) is to remove the [hw] tag at the start of each line. That makes the characters half the normal width.

  12. 2 hours ago, Rocket fan said:

    nevermind its fixed itself somehow

    Ah I was on mobile before - if you're referring to the high saturation, that's a known issue between kopernicus and scatterer.  It'll be fixed whenever scatterer updates, but it's also fixed in the volumetric clouds builds.  This is a transient issue, which means it'll sometimes be fine and sometimes come back.  It didn't "fix itself."

  13. 6 hours ago, orionguy said:

    So is that the same issue for my post above as well? Do I need to post this issue over in Warbirds or Airplane Plus instead of here?

    Probably not, and I’m going to help maintain warbirds anyway.

  14. 4 hours ago, PyjackMeat said:

    Same thing happens with the stock mk1 inline

    Can you elaborate?  Specifically with warbirds or the stock iva?  If the latter, please post your log.

    the warbirds mk1 inline is apparently supposed to represent a modern fighter cockpit and there are cubes that are supposed to block off the lower section of the internal.  But of course those predate FreeIVA and they don’t have colliders. This will eventually be fixed in warbirds.

    If you’re talking about the stock version of the IVA, that certainly used to work so either there’s a new bug or something is installed wrong.

  15. On 11/22/2023 at 6:33 PM, CessnaSkyhawk said:

    I'd prefer to just leave it as is

    Hey good to hear from you!  What you’re going through is normal and common for KSP modders (I say that to mean we understand how you feel), and we all really appreciate everything you’ve already built.  Do whatever you need to for yourself, and rest easy that you’ve already created something something fantastic.

    If we hadn’t heard from you, I was considering proposing putting together a new organization on GitHub to adopt this mod - clearly there are many motivated and talented people here who can help improve it.  If you want to still be involved, I’d suggest that *you* do this so that you maintain control. Otherwise if you’d rather just give up the reins then someone else can, but of course you’d be included so you can keep contributing as you like - or not, that’s fine!

    Just let us know what you’d prefer, and thanks for making this!

×
×
  • Create New...