Jump to content

JH4C

Members
  • Posts

    416
  • Joined

  • Last visited

Posts posted by JH4C

  1. @Nertea, there's a bug being flagged by B9, although it's not a show-stopper:

    B9PartSwitch has encountered a serious warning. The game will continue to run but this should be fixed ASAP.

    Subtype has no name: PartSubtype

    Duplicated subtype names found on ModuleB9PartSwitch (moduleID='meshSwitch3') on part truss-spinal-01:

    Please see KSP's log for additional details

    Despite the last line there's no further information in the log about the error.

  2. On 9/19/2018 at 9:38 AM, JH4C said:

    Well here's an interesting brainteaser... Cross-posting in both threads, apologies for duplication. FAO @Patrick_the_big

    Today I installed BetterSRBs because, well because bigger rockets. However, on loading ModuleManager throws up some errors - not in BetterSRBs, but in Jet Sounds Continued!

    errorladen.png

    "Hm. That's weird," I think to myself, and I quit the load, save the log, remove BetterSRBs and retry - success, no errors:

    errorfree.png

    Obviously this isn't the end of the testing cycle; there could be a third party at work here, so I need to eliminate that possibility. I empty my GameData folder except for Squad, SquadExpansion, BetterSRBs, Jet Sounds Continued, and ModuleManager, and try again - and the errors are still there, albeit on fewer parts as it's not trying to patch the SXT engines. The log of this attempt can be found here, it progressed all the way to the title screen but it's still smaller and easier to decipher than the previous one.

     

    As far as I can tell, the mods don't interact with each other or any common parts, so how/why this happens? All I can say is "good luck!"

    This error is back; I've only just got around to moving this into 1.5.x as almost everything else had updated, and on boot I found the exact same issues as before. As I still don't use RealPlume, I'm just gonna edit out those parts of the patches for my own use, but they really need another look when someone who knows more about everything involved has a chance.

    ETA: inspection of the log file shows that the problem appears this time to be related to the pathing within the RealPlume patches, even though those versions of the patches shouldn't be getting applied on my system. Example:

    [ERR 23:32:44.649] [ModuleManager] Error - Cannot parse variable search when inserting new key localRotation = #$../../../PLUME[Turbofan]/localRotation[0]$,$../../../PLUME[Turbofan]/localRotation[1]$,$../../../PLUME[Turbofan]/localRotation[2]$

    There was discussion before about issues when using NEEDS: and FOR: in the same line, and that's part of the checks used to apply these sections of the patches.

  3. 3 hours ago, elGremlin said:

    Excellent mod, I only have a issue that I got fatal error from B9 Switch and it closes KSP program. I just opened saved craft. If you are interested I can send maybe some logs, etc. to help.

    The error B9 throws up would be very useful to see; they're pretty good at explaining what's gone wrong. However as B9 isn't any kind of dependency for this mod, it's likely to be some other add-on that's causing this.

  4. 7 minutes ago, Lisias said:

    I think it works as designed and intended.

    Command Seats have this name because it's all what they are: a seat with a command stick.

    If you need a full featured cockpit, I think you need to use... A cockpit! :)

     

     

    Oh, I fully understand that - the issue I'm reporting is that there is a Crew Report experiment built into the part that cannot succeed, which I doubt was the intention. There seems little purpose in fitting a component that will never function.

  5. Just been doing some playing. The airbags seem to work as intended so the .dll probably only needs a refresh. The Meadowlark cockpit with its two command seats simply requires "CrewCapacity = 2" to gain modern function, but the Crew Report function is still inaccessible - "Crew Report requires the {part} to be manned." Probably best to delete that module from the part, along with the accompanying science container definition because it appears to be inaccessible - right-clicking the part offers no data storage/retrieval options.

    I'll submit all this to the GitHub as an issue.

  6. 17 hours ago, putnamto said:

    sometimes the dependencies have the same name as the parent mod, so how do i go about copying these to my gamedata?

    The dependencies never share the same name as the parent mod. However, the point of dependencies is that many things use them to make things work more easily, and so you'll find the same folders in multiple downloads. In your example above it sounds like you're unnecessarily downloading EVE as it's already included in the other download.

    A more accurate real-world example: Nertea's Near Future Technologies add-ons. Inside all of them will be a Gamedata folder (as is standard), and inside that will be the specific folder for that mod (let's say this one's called "NearFutureCandyDispensers") as well as "B9PartSwitch" and "NearFutureProps" which are required dependencies. If you already have another of Nertea's addons, such as NearFutureSolar or StationPartsExpansionRedux, they will have already installed the same dependencies - so what you need to do is see if the copy you have installed is newer than the one that came with the add-on being installed. In this example "NearFutureCandyDispensers" is an older mod, and the dependencies you already have installed are much newer, so  you only need to install the main folder and can ignore the others.

    If you know how to merge folders on your operating system, that'll usually put everything in the right place. Alternatively, you might find it easier still to use CKAN, which will do all the worrying about dependency location for you.

  7. I don't recall if this works the exact same way on Windows, but on MacOS I can open the Gamedata folder, Select All, Copy, then Paste that into a text document and it'll turn into a list of the folder names.

    Another option would be to install the full-fat version of AVC, which would report on everything that has a .version file.

    And of course there's always opening KSP.log and copying the list of loaded mods from there. Open the file in your text editor of choice and search for Mod DLLs Found; you'll have a list of all the add-ons that use DLLs first, then all the folders within Gamedata follows directly behind. Of course not every mod uses a dll, and some share common folders, but that's about as close as you'll get to everything with minimal effort needed to fill in any missing details.

  8. 24 minutes ago, espartanlast1 said:

    ok, but what about A330 / A340 cockpit and 787 cockpit, 

    It might be an idea for you to look through the thread more thoroughly, as you're suggesting some parts that are either already included or that have been listed as likely to be excluded due to similarities to existing models. Just have a play with what's already been made, see what you can come up with; the idea here isn't to emulate every aspect of a flightsim, but to allow us to build something new.

  9. 17 hours ago, linuxgurugamer said:

    So I assume that all the above messages are referring to 1.4.5?

    As you can see from my previous message, I think this is too good to lose, I'm hoping that @Sam Hall replies.  In the meantime,  if you do update it, I'd appreciate seeing the changes

    Sorry, didn't mean to confuse the issue; I didn't mean to suggest that I'd adopt it, just to get that part working as now intended in my own game - it was a vote of support for your suggestion to keep it alive, poorly worded. And as you can see from the other replies, we're not alone in this!

    That said, I first started using it after reading @Daniel Prates's post, which meant I only ever installed it in 1.4.5 and the parts I used worked as I expected/wanted. I believe the configs for the lights are referring to getting them functional under 1.4.5 (which I don't think I was concerned about) but I believe @Mecripp would know that better than I.

    I'm in two minds about a rebuilt IVA; the unconventional crew layout is part of its charm, I just cope that can be retained.

  10. It has been tried. First result for "KSP ring world": 

    Putting a habitation ring all the way around a planet has major issues, not least because of the render physics distances required to even try to make it stable. Someone scaled up a single part to encompass Kerbin and it cast a shadow, but you can't do anything with it because you're considered "too far away" from the centre for it to be rendered when you approach any of its surfaces... Which is a good way to end up dead very fast.

  11. 1 hour ago, TriggeredSnake said:

    I love this mod and all, but the IVA's definitely need some work. Most of them just have kerbals floating in mid air, glitched into walls and consoles. For example, the 1.25 and 2.5 meter centrifuges have kerbals glitched everywhere, and the 1.25 meter cupola for example has switches and controls floating in midair next to the kerbal like the IVA was very lazily produced. Also, the winston and volleyball inflatable modules have some of the worst IVA's I've seen in a while, an empty blob with a big thing in the center with 3 kerbals floating without seats, despite sitting in a seated position, and the big 2.5 meter observation window pod really lacks detail; it works fine, but it would be better with some kind of detail, maybe a plant in the middle or something. It's a shame that such a great mod has such bad unfinished IVAs.

    Considering the post above yours praises the IVAs, I would be interested in learning why you find them so terrible. I assume you did install the associated Near Future Props dependency? I just made a test "station" using every single habitable unit (requiring me to hire 70 additional Kerbals!) and every single one of them was sat properly in a seat, nothing was clipped through anything. There's obviously something not right with your install.

    OT: Everyone's entitled to an opinion, but if you're gonna offer criticism try and be constructive about it instead of just ripping something to shreds with no suggestions as to how it might be improved, or even basic investigation that it's been properly experienced. Uninformed posts like this are how we lose people from (or worse, drive them out of) the community.

×
×
  • Create New...