Jump to content

Stone Blue

Members
  • Posts

    5,100
  • Joined

Everything posted by Stone Blue

  1. -Heisenberg Airships also has a couple props The thing about Heisenberg, is it has a WildBlue .dll that deals with *how* props work. The only other plugin which deals with *how* props work, that I can think of, is Firespitter. These are good if you wanted to make your own props to add to KSP.
  2. Just in case anyone is ever looking for this, the link in the OP is broke since Curse changed its format. Here's a current link that still works: https://www.curseforge.com/kerbal/ksp-mods/benjis-light-up-command-pods
  3. Best thing to do before asking if a mod works in current or newer KSP versions, *other* than whats officially listed for the mod... Is to read back in the thread, to see when it last worked for people. Second, is to try it out first, yourself, *on a NEW SAVE*, in sandbox mode (that way you shouldnt corrupt any important/existing saves)... If it works, it works If not, then come report any issues/questions on the forums
  4. @Caerfinon even tho Eskandare says the models need updating, I belive they still finction pretty well... but it would be awesome if you included his old Oceania static(s)...
  5. Try: MODEL { model = Eskandare_Heavy_Industries/Carrier_Vessel_Expansion/Parts/Nimitz/nimitz } instead of the mesh = line the mesh = key has actually been soft deprecated... whwnever updating anything, should *always* be updated to MODEL {} node... it has much moar builtin flexibility & function... like, being able to texture switch right in the MODEL{}, for one yeah.. thats because "mesh =" is limited to specifically only being able to grab the model (and textures), from the *same* folder its reading the cfg from.. thats why just defining t he filename alone works. it already knows the *exact* folder to look for the matching model, based on where the .cfg is. MODEL{}, uses the whole file URL... thats what makes it possible to grab models *outside* the folder, where the cfg is. Note that the *textures* still need to be inside the same folder as the model. **UNLESS**, you do a texture switch line in the MODEL{} node... altho you still need a basic, single color, 4x4 pixel "placeholder" texture in with the model. model =, has no idea how to deal with a full folder URL
  6. Is the model defined with a "mesh =" key in the cfg, rather than with a "MODEL{ }" node? Thats what it sounds like anyway... could try updatig to a MODEL node... vOv
  7. I've poked this mod, too. So, I'm guessing with the green light, Sumghai probably checked the "Play Automatically" box in Unity, for that one... at least the always-on rotation (animation), seems to bear that out. I found the same with defining multiple light names in the cfg key. I found out, you can fix that, simply by naming *both* light game objects, the *same* name, *in the model, before export*. Works just like naming seperate animation tracks, the *same* name, to get them *all* to play as a single animation I'm close to having these fixed, except for one small, but major problem: They work like they are supposed to, *except*, they only rotate once, then turn off. The problem is, i cant seem to get the animation to keep looping while activated.
  8. well, RPM, JSI Part Utilities, & several other mods, are outliers... in that, they are completely different, seperate mods, by several different maintainers... **yet, they all share a common GameData folder (/JSI/)**.. which doesnt even really match or seem to have to do with some of the names of mods that go there... So dont feel too bad about this one
  9. Seems to be two seperate things there... or both installed incorrectly... idk where the oeverlap would be.. vOv /BahaSP/ is this: LGG's first version of this, when he first too it over, is v1.3.0... I'm guessing Baha's *original*, very outdated version is installed.. vOv and "QTAP" is probably something to do with: OH!... coincidentally, same with this one.. LGG's first version is 1.3.0... I bet the outdated, *original* version is also installed Ahhh ha.. *both* mods come bundled with "BDAnimationModules.dll"... maybe thats it? vOv Both *original* mods, IIRC, were last updated for KSP v1.0.2 ... lol FYI @pp_extended
  10. i could be wrong, but i believe you still dont have JSI Part Utilities installed... Also, (most likely not your issue), but I would suggest ditching ALL copies of the ModuleManager dll *except* for the 4.2.2 one. (thats the latest)
  11. One of the mods has one or moar parts that are triggering the 1km spawn bug. (known issue) Most likely due to animated collider origins in the part model. I suggest removing mods one by one, to find out which it is. I would start with those mods you are using to build the specific craft that it is happening to.
  12. Well, have you even *tried it*, without TMP? vOv That first link you posted, was someone trying to make something that required working with... *displayed text*... so no surprise its needed for that.
  13. If you're not making/editing any plugins, and just modelling parts & IVAs, you shouldnt need TextMeshPro *at all*... i havent had it installed for the last few years & versions of Unity. (I wasnt installing it, even when it *was* available/updated)
  14. @KADC this happens, even while *pinning* them, by clicking the pin icon?
  15. Almost looks lie you have different reaction wheels doing adjustments on opposite axis... vOv
  16. Ifyou do a mainly manual install, & NOT CKAN, I suggest installing KSP-AVC mod, to help eep you notified of installed mod updates: (I know it says 1.8.1 & later, but it *does* work up to 1.12.3 or .4)
  17. @coyotepunk05 I imagine AoA is *supposed* to be used with/supported by BD Armory, but that mod isnt even mentioned in AoA's OP... vOv But that error you posted, seems to be thrown by one of the BD Armory plugins. And since AoA thread is kinda old & slow here, I suggest going over to the BD Armory thread, to see if they can help there. But first, double chec you have the correct & most up-to-date version(s) of any BD Armory mods you have... I know several of the BDA mods have changed hands a few times since AoA was made/last updated.... vOv Also, I suggest reading the OP on this thread, and learn how to post your logs correctly. Providing logs right off the bat, with a support request, will moar likely get you an answer, and quicker, too Then post here: (I believe this is the current, main) BDA thread:
  18. Nope... If you are using any of Lisias' mods, ie Tweakscale, KSP Recall, etc, and you have a ModuleManagerWatchdog file or folder, you NEED to go to one of Lisias' threads to post, or to PM them directly. They have their own *experimental* version of ModuleManager, and it is NOT supported in the official Sarbian thread. https://forum.kerbalspaceprogram.com/index.php?/profile/187168-lisias/ DO NOT POST on the MM thread by Sarbian. FYI @ChadOverboard
  19. no... having more than one .mu in a folder is not an issue
  20. Should be.. this mod is only a few (relatively) simple parts... Parts-only mods are generally less prone to be broken by KSP updates/differnet versions of KSP.
  21. Well, this is off to a pretty good start I do see, most of your .png textures are dbl/tripled-up... But i see you have a /Textures/ folder already.. so it looks like you know you only need *one* copy of shared textures, instead of a copy in each relevant folder with the models/cfgs. I notice Greeble8k has two copies, that while the file properties seem different, visually, they look like the same tetxure... could probably delete one.. vOv Also, I see for the GreebleBakeManara texture, you could do some optimizing on the model's UV mapping, and be able to shrink that texture down in half or quarter what its at... Making all the above changes, & converting to .dds, you could probably easily shrink the mod size from 1 GB, to about half or smaller... I dont know how it would affect RAM usage (couldnt get worse, anyway ), but right now, as-is, the mod alone adds ~3.2 GB to my RAM useage. I really hope you get the opportunity to tweak the mod a bit, and that hopefully, someone comes along who does base building with Kerbal Konstructs, fully takes advantage of the statics in here.
  22. Hmm... I didnt realise the Mechjeb stuuf was so related to actual hard-coding... Sorry
×
×
  • Create New...