• Content Count

  • Joined

  • Last visited

Community Reputation

574 Excellent


About Aelfhe1m

  • Rank
    Inveterate Tinkerer

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Not the problem in this case unfortunately. OSE Workshop creates its own independent config nodes which are being read by the loader. The only thing shared with the other mods is the name of the resource (ablator). It looks like there has been some change in the way that the config node reader or co-routines work in the latest version that is causing the loading code in Workshop to fail for installs with a larger number of parts. It works OK with just Wortkshop and stock parts or even with a few small part mods but adding KSPIE or any of the other larger part mods seems to trigger this error. I'll keep digging and if I can't figure out how to fix the current code I'll change it to use an alternative loading method that I know does work.
  2. @Leandro Basi and @COL.R.Neville OK, I confirmed this with KSPIE installed alongside my test build of Workshop. I didn't get the Ablator recipe error but it's almost certainly related. Not sure what's going on here since the recipe loading code hasn't changed in 2+ years. Maybe it's the upgrade to a new version of Unity in KSP 1.4. I'll investigate and find a fix.
  3. Version 2.3.5 for KSP 1.4.x - GitHub - SpaceDock Recompiled for KSP 1.4.x
  4. New version 1.2.5 for KSP version 1.4.X - download GitHub or Spacedock Recompile against KSP 1.4.2 Fix NRE in recycler window Refactor window drawing code Add handling for "vintage" EVA kerbals from Making History if installed Sorry for the delay folks but I've been quite ill for the last couple of months and I am only just getting back into KSP.
  5. @chrisl To access another root level node you use #$@...$. Also you don't use #name like that - it would be [#name[XXX]] but can be shortened to just [XXX]. Try this: PART { . MODULE { . CAP { name = Adapter-2-1-Short volume = #$@SSTU_MODEL[Adapter-2-1-Short]/volume$ } } }
  6. @Li0n, @Angel-125 I've already posted a reply on the pull request that I don't think this is the correct fix for this MM error. Here's a copy of my reply for the thread:
  7. The heads folder where this mod's textures reside only affects in-flight Kerbals. To affect Werner and others you need to add the correctly named textures to the TextureReplacerReplaced/Default folder. I tested that this still works (although I couldn't find all the texture names) : Werner von Kerman: Default/wernerVonKerman_head Gene Kerman: ??? Motimer Kerman: Default/kerbal_old Linus Kerman: Default/kerbalHead Walt Kerman: Default/kerbalHeadBeard Gus Kerman: ??? There are also either two or three separate textures for the ground crew in VAB/SPH one of which (the guys in the hard hats) seems to be Default/kerbalHead as well. The guys in the lab coats and the guys near the doors waving the guide batons don't use Default/kerbalHead but I'm not sure what texture they do use.
  8. From the main KSC screen open settings, click the "Difficulty Options:" button then select "Editor Settings" on the left and make sure that "Hide Unpurchased Parts" is de-selected.
  9. The WBIDualAxisSolarArray module works in conjunction with the stock ModuleDeployableSolarPanel - the stock module is defined first in the config to control one axis of rotation and then the WBI module is defined after it to control the second axis of rotation. The rotationModuleIndex = X line inside the WBI module is used to tell it where to find the stock module in the config. (e.g. in the solar truss config the stock module comes first at the index 0. If there had been any other modules defined before the stock module then a higher index would be specified). Looking at your part you only have one axis of rotation (on the part itself - the other axis would be controlled by whatever you attached to the end of it) so you could just use the stock module without needing the WBI module. Edit: upon further thought I'm not sure whether this would work. Most parts in KSP don't move other attached parts with their animations. That requires more complicated specialist code (and rigging) along the lines of Infernal Robotics or USI Konstruction.
  10. @ksp_circles Going to an asteroid uses the same methods as rendezvousing with another vessel. Get into the same SOI and then "match planes", "Hohmann transfer" , "fine tune" etc. either manually through Maneuver Planner, semi-automated through Rendezvous Planner or using Rendezvous Autopilot.
  11. The pieces of code I linked in my earlier message are part of compiled DLLs. You would use them by including the mod containing the DLL as a dependency for your mod and then referencing the part module in the config file in the section noted. For example the config file for DSEV solar truss is here and uses two part modules to define the two axes of rotation - a stock ModuleDeployableSolarPanel in lines 37-50 and the custom WBIDualAxisSolarArray module in lines 52-67. The pivotName and raycastTransformName refer to specific elements defined on the model file in Unity (see this post for basics). There is a mod - DebugStuff (it still works fine in KSP 1.3.1) - that can be used to examine parts inside KSP to see how the various coliders, meshes, transforms etc. are defined. Then look at the parts' config files to see how those names are used inside modules. To use stock modules or modules from other mods that you define as being dependencies then a simple text editor is fine. If you want to write your own custom module or modify the behaviour of an existing module (beyond just setting different values for fields) then you need to set up a code compiling environment in Visual Studio, MonoDevelop or similar.
  12. Yes this is possible and has been done at least two times to my knowledge - WildBlueTools includes WBIDualAxisSolarArray which is used in DSEV - solar truss MOLE - solar battery module Pathfinder - Sombrero Solar Array SSTU includes SSTUSolarPanelDeployable used in SSTU - ST-GEN - DSP-ISS (and several other single axis panels) Edit: the DSEV solar truss is the most similar to the NFC octo trusses.
  13. @helaeon I did a quick test and I'm not seeing any problem with the Tranquility Mk2 Habitat switching between "Ponderosa" and "Blacksmith" using an install with the latest versions of DSEV, Pathfinder, KPBS and OSE Workshop. (I did change this line to @PART[WBI_D2Hab]:AFTER[Pathfinder] for compatibility with MM 3.0.1).
  14. @linuxgurugamer Just an FYI - somehow the new zip has two copies of PreciseNode.dll in the plugins folder...