shoe7ess

Members
  • Content Count

    230
  • Joined

  • Last visited

Everything posted by shoe7ess

  1. That's my additions to the OP KSC Launchpad. I added a few more fuel tanks, a (static) fuel truck parked to the left, and the large tower is actually the static weather tower from KSC++ (or one of its' dependencies). I also added the new floodlights at 0.2x scale to the Mercury launchpad (LC-5), as that has a built in static launch tower I believe so it fits in nicely. I also found that using the in-game KK control panel allows for pretty decent control of cone-angle (either by scaling, pitching, or just moving them further from the launchpad). For the alternate texture you mentioned, a separate config file for another model could be a start, at least then it'd get added to the base KK statics, and be available to via in-game editor.
  2. Here you are: Blender Link (If you prefer Blender) .mu import/export for Blender (Instructions are pretty easy to follow in the OP) (for important .mu files into either Blender or BfA) BforArtists Download Page (as it says on the front page, BfA is just a fork of Blender, so it's pretty much Blender++ ) As for resources, I'd suggest picking up the source (almost always available on the more common known mods) of a part-heavy mod and checking out those models, and maybe even use some as a template or jump-off point. Good luck! Also, it looks amazing Stone Blue!!! (That's the BDB Mercury Redstone on the launchpad, I may edit my statics from 0.75x to 0.5x, gotta check out the Saturn V first though )
  3. I appreciate the gesture, but honestly you got more done than I would have by now. I live in NJ and we finally started to get back to work this last 2 weeks so I'm glad you were able to take up the mantle. I can't wait to test out the updated floodlights
  4. <removed by author> Looks like Stone Blue got the go ahead from Divico, sweet! We look forward to it Stone!
  5. I've actually been following that mod (the original, I had no idea you had adopted it so I checked it out). I love it, and I've added it as "separate" way of doing what this mod did, but I think the idea here (can't speak for anyone else) is to get it integrated as an instance on the launchpad by default. If there was a way to make the spotlights work as a KK object it would be perfect, just to help keep down the part count (like if attached to a launch clamp) or having multiple vessels loaded on the launchpad (if using some mobile "lighting truck/sign"). BTW for those interested, the floodlight mod is pretty amazing (plugging your adoption LGG, it's amazing), you can get that here: In the meantime, since I can't find the author's source code anywhere, I'll attempt to use blender and dabble with the model file. If anything comes of it I'll check out license and see if I can redistribute an updated .mu. If I'm able to I tinker with it and get the intensity a little stronger and post a download link I'll update this post in the next few hours. Also, the left-click action is an action in the KK module within the config file (I have no idea what actions work within the object modules by default for KK objects, but the right-click PAW GUI module isn't difficult to integrate into parts themselves, so maybe there's an easier method of switching out the "AnimateOnClick" action without the source?). Edit: Unfortunately I haven't found a way to make light intensity changes without the source code. I sent a message to Divico, asking if he can update this thread with a link to the source (or a PM'ed link if he still has it readily available).I am in no way promising I can recompile something like this anytime soon (I'm not a programmer, I'm more of a tweaker; I can do MM patches or edit .dds/.cfg files for days), but recompiling script for KSP is something I've only dabbled in. In the meantime, I'd take advantage of LGG's adopted tracking lights mod. My hope is to get this updated (PAW GUI + Intensity/RGB slider) if possible, but Tracking Lights is a great alternative if you don't mind the light being a part piece as opposed to a KK object. I'll update if I can get in contact with the mod author.
  6. That or scale them down in the config/KK menu (I have mine at 1.5 forgetting how big even a 20m craft it's hilarious, the towers are I thnk 700m tall lmao)... I know I still have .dds edting tools on this PC, I believe I have what I need for editing .mu files. I'll take a look a little later. Nice find man.
  7. Ah, that's interesting. Mine are so spaced out from the launch pad that I don't see anything in night launches. Maybe if I move them closer it'd show up (the lights themselves look lit, they just don't seem to illuminate anything from what I can see). If the source was somewhere I'm sure the light intensity might be an tweak, could get this thing up to modern times (by that I mean 1969 Apollo times) . Thanks for the heads up.
  8. Looking for some help with an MM patch for graduated response for all engines. I already have a version with a set accel/decel rate that encompasses all engines in my game that KW doesn't already patch with a flat rate, but I want to vary that rate using some arithmetic (either on engine mass, propellant type (for RF), or maybe a combination of both). The only question I have is how the integer works, i.e. do higher values = faster response or slower response? I've tried looking at the KW engine patches and figuring it out based on (oh yeah, that's the huge engine vs the little engine) but I can't quite pin it down and I couldn't find an answer through the search engine (so I apologize if this has been answered a few times before). Does anyone know how the rate works? I have a formula in mind if a higher value means a slower accel/decel rate (I just don't like working with a flat rate model, doesn't make as much sense to me), could use some help tweaking it... @PART[*]:HAS[@MODULE[ModuleEnginesFX],~useEngineResponseTime[],!PROPELLANT[SolidFuel]]:FIRST { @MODULE[ModuleEnginesFX] { useEngineResponseTime = True engineAccelerationSpeed = #$/mass$ @engineAccelerationSpeed *= 0.1 @engineAccelerationSpeed += 0.8 engineDecelerationSpeed = #$/mass$ @engineDecelerationSpeed *= 0.1 @engineDecelerationSpeed +- 1 } } Will this give the opposite effect that I'm trying to achieve? (Larger mass = slower acceleration being the goal in this case)
  9. Weird, I get no context menu when I click them in mine, but I'm using a ton of mods, something may be blocking the GUI popup. Thanks for letting me know!
  10. I've been slowly adding more and more mods into my 1.9.1 game and recently one of them broke the deltaV/vessel information/active missions/etc buttons in the VAB so that they do not pop up. I am using a handful of mods that aren't updated for 1.9.1 and I've narrowed it down to the time I started having issues with UI (Blizzy's toolbar is also missing in the space center, but shows up everywhere else so that's fine, just annoying). The buttons I'm talking about: The buttons in the red rectangle will not open any windows. My modlist: The mods I added before I noticed this issue were Decal o' Mania, Planet Shine, RCS Build Aid, and the QuickMod "Quick GoTo". I also added KSC++ and made some custom constructs on the default launchpad around that time, though I can't see that creating an issue. The decal mod just adds parts so I doubt that's the culprit but included it none-the-less. I tried opening the debug console during the scene but nothing abnormal populated. Here's my KSP.log for anyone that knows how to interpret it better than I do: https://www.dropbox.com/s/c1522ez70ebdgnf/KSP.log?dl=0 Thanks and I appreciate any help you can provide! *Quick Edit* Took a look through my log and found: [LOG 21:22:52.395] QuickGoTo(QBlizzyToolbar)[1.40]: Destroy [LOG 21:22:52.395] QuickGoTo(QGUI)[1.40]: OnDestroy It could explain the GUI issues.
  11. I seem to remember them working as posted in the OP. I'm assuming at some point post 1.3 the UI updates broke the comparability. I've been using the floodlights using KK to create some cool looking day launches, but I'd love to figure out a way to get them to light up for night launches. I can't find a single object in KK (I'm a newbie to using it, but I have the most recent 1.9.1 KSC++ installed with all dependencies and haven't found an object that lights up). PS: Sorry to necro this, but I haven't found a substitute for launchpad lights (aside planting them on launch-clamps) and KK still links here /shrug
  12. I'm currently using it in a heavily modified 1.9.x game (no RSS/RO, just stock-alike configs, with BDB, KWRocketry, NovaPunch, and Procedural Parts) and have not run into any issues so far. I haven't checked my debug log while playing, but I haven't had any crashes.
  13. I'm having an issue with Real Fuels compatibility. I tried grabbing the Saturn SI-C sub-assembly and noticed that above the first stage, the part adapter tank (I forget the size) for whatever reason only has an LF/O config, but the engines are set up to accept LH2/OX I believe so the sub-assembly won't work unless I change out that specific part with a procedural. This is just the first case I've found where this has been an issue so I don't know if there are further tanks but it doesn't even have the B9PartSwitch module it seems, and I can't find where the patch from stock to real fuels is getting applied for BDB to try and add it myself. Will update shortly with a screenshot if needed but was wondering if anyone else has had this issue or BDB just isn't fully compatible with Real Fuels and that's the reason. Thanks for any help you can give!
  14. Anyway you can drop that config on dropbox? I have no idea what to change but I have seen the "spawnmarker" names in most of the .cfg files but only a handful of use-able launchpads (haven't gone in and ticked the missile rows, etc. as possible launchpads) and everything is incredibly spread out for me (using RSS so at least most things are level with the terrain, aside from the actual KSC terrain mesh lol)
  15. Great, I'm swamped and really have barely enough time to myself let alone to this project at the moment. I'm looking forward to it!
  16. Since I didn't see a followup to this I'd like to bring this up. somewhere along the way the part names for TantaresLV's parts name structure in their config files changed and there hasn't been any update to the compatability path to reflect that. For example: RO calls for: ALV_Engine_A for the proton rocket TantaresLV has since renamed the engine to: ALV_1_Engine_1 (not sure when this changed, but it was pre-1.3.1 release) Since this naming scheme was changed for every TantaresLV part they will not be compatible unless a) you go through the comp. patches and make them point to the correct name or b) you wait until someone updates the patch. I'd do this myself, but even though I really, REALLY, love TantaresLV's designs I'm about burnt out on modding text files for this game for the time being. If I change my mind at some point I'll try my best at guessing which part matches the new naming structure (the biggest headache in all of this, since some of the naming structures had me scratching my head as to what part they were referring to) and post it. I've decided to at least start a project for this on my github. After I get it organized I'll throw a link up for it. Here: https://github.com/shoe7ess/KSP/tree/master/RSS-RO/RO_SuggestedMods/Tantares
  17. See post above. I'd love to be able to go FASA/BDB as that would make things a lot easier. Could even edit the .dds for the SM to show damage under its covers and include it as optional, but I think the main goal is to stick with stock so people unfamiliar with modding or those just stepping into the game don't get separated from those like us that push the 64x build to its' limit Hell, since I have any updates from Mr Rocketeer, I may just go ahead and finish what I've started on the stock version then make an alternate "hardcore" version that would either require BDB or FASA, TAC-LS or USI-LS, Module Manager, and a handful of MM configs to allow for things like 3 seats in the LEM, changes to the capsule (to allow for accurate simulations of different events). It would also give me the ability to kill the scrubber and allow it to be repaired or turned back on in some sort of realistic way though I still don't know how to do it in an engaging way (maybe make them repairable only after a specific event has triggered if that's possible). LIke I said, I'm new to the mission builder but I've spent more time modding KSP than playing it (like 4:1 ratio at this point), for some reason I find it more fun to take a mod and make it "my own", so maybe it won't be as hard as I'm making it out to be in my head.
  18. I'll have to see if that's even possible, I'm not very intimate with the Mission Builder yet. If I could make this dependent on BDB or at least MM things would be so much easier, but then that cuts the community in to the bits that don't bother with mods
  19. Thank you! So what was happening to me, at least I believe, is that since I wasn't touching default scale before, just setting it to freescale, other patches were changing the scaletype, after my patch goes barreling through I'm assuming the leftover scaletype info was getting used as free instead of whatever it was before (stack, etc.), making most bits start at 10%. So fixing it should be as easy as adding in !ScaleType{} before I create the free scaletype, that way any information from other patches for scaletype variables gets pushed out and then my patch comes through, sets the scaletype to freescale and sets the defaultscale to 100 (which should be all I need) Result: @PART[*]:HAS[!MODULE[ProceduralPart]]:AFTER[RealismOverhaul] { -MODULE[TweakScale] {} %MODULE[TweakScale] { %type = free %defaultScale = 100 // Actually, since this is now a blank TweakScale module, shouldn't it default to this anyway? } } *Update:* Now this works exactly as intended. May be "career-breaking" if you are trying for a completely realistic RP-0 career where large engines and fuel tanks shouldn't be obtainable from the start; however that is up to the user to decide how it is used (great power, great yada yada). Personally I use this because after so many parts are added in my game that I end up with parts that ALMOST align with other ones or ones that I wish had a smaller version for smaller craft (ScienceJR being one of those, as well as construction pieces like girders and the like) and tweaking the scale on a percentile basis allows me to build my ships/planes so much easier. Thanks for your help @pellinor, I hadn't even thought of the fact that I had fragments left over of non free scaletypes and that was the cause.
  20. I'm sorry if this has been asked here already but could use some help on a tweakscale config that works in my games that are highly part-modded, but isn't nearly as useful (or goes too far) in overhaul packs (like RSS/RO) where there are a lot of MM configs that contradict the intent of the file.So I originally created a tweakscale config that added free-tweakscale to every part in the game. It worked great and could (after a few hiccups with other tweakscale MM's superseding it and disabling them) allow me to scale everything in game: Now I'm attempting to adopt this to my 1.3.1 RSS/RO game and can get it to either tweakscale everything or just a handful of things and both of these are to the extreme. When it allows tweakscale to everything (basically with just :FINAL tagged on the part line at the top) it starts almost every part at something like 10% of their normal size, I then step the size up to 100% and it shows a 200% version of said part, then I step it down once and it shows 50% but that is the default scale of the part I'm working with. This is a huge pain to deal with every single part in the game. So I've tried alternate tags like :AFTER[zzzVENSPATHPATCH] or something to that extent as it's the last MM config loaded on my game I believe but I might as well not have an end tag altogether at this point as now it allows me to tweak only a few items. So what I need help on is the first "extreme" where it allows tweakscale to apply to everything but I need the defaultScale to be the default scale of the part it's adding the module to and that's where I could use some help. I'm about to try the following script but since the default scales come in sets of 3 (x, y, z) I don't believe it will take. My next idea will be to set default scale to the rescale factor of the part, which will hopefully keep the scale to the default scale (after realism overhaul rescales the item) but to save me a few 20 minute startups just to debug this I thought I'd ask if anyone has an MM patch that can do this? I believe it would make my original patch more stable and versatile in that I should be able to add it to any scaled system or alternate planet pack, or add any part mod and have tweakscale's module added by default. Here's the patch I'm currently about to test: Thanks for any help/advice you can give me in advance. If I can't find any help and one of the above methods works I'll post the "winning" script for anyone that wants it in the future. Edit, the first method didn't work, going to the second setup now.
  21. Since no one got back to you I thought I'd do so. Since this mod relies on Kopernicus as a dependency, if it has not been built against the latest Kopernicus for 1.3 it will not work in 1.3 (took me about 20 or so hours to get my 1.3 RSS working, and at least half of that was making sure the right versions of each dependency of RSS and RSSVE were using the correct dependency versions (otherwise the RSS systems wouldn't load). I'd love for an RSS expansion mod for 1.3.1 but it looks like none are there yet (not that there are many to begin with, only ones I know are this and RSS Extrasolar).
  22. Updates!!!! Craft now compatible with 1.4.2 Craft's staging is now correct Action groups 1-10 are now set and in order from shedding the fairings on S3 for docking all the way to shedding the CM service bay for parachute deployment on the way back (strongly suggest using them as they make things way easy if used at the right time [they're in chronological order of use]) Last update may be a launch tower. If so I'd likely go with a pre-fab from Kerbal X if I can, but the part limit is so high already that I may leave this in the maybe column. As far as the actual mission goes I've got everything set up until orbit (so in other words, the easy bits, including the center engine cut-off at a certain altitude that attempts to ape where it cut-off on Apollo 13 as much as possible). Again, craft file is at: https://kerbalx.com/shoe7ess/KSA-Saturn-V-Making-History-Expansion-Realistic-TWR-Values
  23. As an update, I've decided to take on this project for now. I'm currently familiarizing myself with the mission editor and looking for ideas on how to simulate certain events. Also updated craft to be 1.4.2 compatible, fixed staging, and added action groups (easy and in order starting from shedding the fairing on Stage 3 for docking CSM to LEM all the way to landing back on kerbin, using all 10 action groups in order of necessity).
  24. Love this mod and have used it since... well since it's inception I believe. I've finally taken the time to create an MM patch that covers a multitude of mods and because of the setup of this mod (and I love PrivateFlip for this) it is possible to add resources that you do not have access to in game, making it easy to create a single Module Manager patch to add in resources for as many mods as you can think. So I did just that. The following MM patch adds in Ore as a possible resource for stock, and support for the following mods: USI-LS (5000 of each major resource, didn't spend as much time on this one yet, need to find a LiquidFuel to Mulch, Fertilizer, Supplies, Machinery, weight ratio) Extraplanetary Launchpads TAC-LS Real Fuels (Used the config file RealTankTypes.cfg to get a baseline mass ratio and added in the most common fuel types (around 30 I believe) so all fuel ratios are equal to the Liquid Fuel that is provided by stock Davon Supply Mod KSP Interstellar (This is highly WIP as I am not currently using KSPi so have not put in the time yet to add every resource, but used the same ratios as provided by RF for the ones here) The MM Patch is here: As stated before this MM patch can be used for any of these mods, you can remove the resources you don't need in order to clear the clutter of un-used resource choices on your drop-down menu in-game. Until I can figure out how to implement B9_Tank_Switch types in order to sort between mods (no idea where to start honestly) this was the best I could come up with. Tested in 1.4 and works (as well as my 1.3.1 stock modded and 1.3.1 RSS installs. As far as balancing is concerned, that's up to you. I personally set up a non-exponentional/linear setup for every resource adding 12 tons to the mass (probably a bit under what it should be) and about 350000 to the cost. I may come back to this creating a sub-resource-module per mod and multiplying the cost and mass by some some integer (like between 0.5-1) per mod, giving range of 2.5x to 5x of the base cost and mass. 5.11.2018 - Updated to -ACTUALLY- include TAC-LS resources.