NermNermNerm

Members
  • Content Count

    107
  • Joined

  • Last visited

Community Reputation

50 Excellent

1 Follower

About NermNermNerm

  • Rank
    Director of Dangerous Activities

Recent Profile Visitors

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

  1. So there I was, minding my own business, trying to figure out how to do animations in blender/unity/ksp/etc and was trying to gain some wisdom from this video: And at 11:18, he's in the KSP and his part is not all that he hopes for, he goes to the Space Center view in KSP, there's a ModuleManager dialog there and lo, it contains a "Reload Database" button. He presses it and tada! The fixes he just applied outside of the game are now in force in his game. No restarting KSP required! I've never seen a ModuleManager dialog. How is this magic worked? The video is pretty old so maybe it used to be a thing & isn't anymore...
  2. News update! KSP 1.8 Since the mod, in its current release, runs just fine under 1.8, I haven't hurried a release or anything. I do have it building under 1.8 with the new Unity framework and such, but I've been sitting on that release, because there's no change that you'd really see. New Snack Storage Parts! I've managed to get some rudimentary skills in Blender & such to create some simple parts. So here's the first installment: They come in three sizes and are built with particular scenarios in-mind; I didn't just spam all the Configurable-Containers stuff across them. The scenarios I went after are ones where the configurable containers don't do well at. The Space Rated Lunchbox is a surface-attach part, which carries 3 Tier-4 snacks. It's built for extending those early-day Mun missions and, once you're further along, take some of the drama out of the crushin-scrounging expeditions. It doesn't support any configuration - it just does 3 snacks. If you want to quibble about how you're apportioning 3 snacks, you're getting a little too fancy, so, for simplicity, it just has the one loadout. The Snack Bucket is a 1.25m part which holds 45 kerbal-days worth of snacks. This part is designed for longer hops - for example it can take a 3-kerbal crew to Minmus and back (assuming you get your maneuver nodes done reasonably optimally). It'd also be good for trips around Jool. Since it is fully 45-days' worth, this part is configurable - but only among snacks. One mode is purely tier-4 snacks, and that's simple enough. But it also has a Tier-0 snacks mode - in that configuration it carries 27 Tier0 snacks and 18 Tier4 snacks - because that's what a Kerbal will consume in 45 days, exactly. Likewise for the other tiers - e.g. all the way up at tier 3, it's 1 Tier-4 snack and 44 Tier-3. So you can take your Kerbals off your colonized world without cutting into your precious stocks of Kerbal snacks and without having to get too fiddly with tank management. The Orbital Pantry is a 2.5m part; the large size actually makes its use more niche. If you need to store that many snacks, you're really at a point where configurable containers are the way to go. The only really solid application I have for it is early space stations. If you read the posts in this thread, people are clearly struggling with knowing how much of what kind of stuff to bring. The base loadout of this part is meant to fix that problem; it consists of tier-4 snacks and fertilizer, in roughly the proportion that you'd use in a station using early hydroponics. Beyond that, the only application I can imagine would be a simple desire to have container parts that look the part. That is, you just want your snack storage module to look like it stores snacks. For that case, there are loadouts for purely T0-T4 snacks. Another need, which I haven't addressed yet, is for a small container for fertilizer for early-game. The Orbital Pantry might just take care of that requirement; we'll see how we get on. Orbital Scanning I'm pretty well settled in the idea that Tier-2 plus scanning will require 2 crewmen, thus making the size of the station bigger and encouraging a more station-like build. (As opposed to now where folks are basically encouraged to combine the mission of the interplanetary-transport and the station). I had started modeling a large, fancy part for the job, but I got to thinking that in modeling all that fanciness, I'm doing the player's job. You know how you always like to stick on a mess of antennae and whatnot on your station for no reason at all other than looks? Well, what if that bristling array of random stuff actually had a purpose? I haven't really cooked the idea fully yet, but the basic idea is that the part will work "better" if your station has a variety of whatnot attached to it. Stay tuned, I should be able to at least get the snack cans and 1.8 changes out this weekend or next... Sometime after I get the gutters cleaned...
  3. Thanks for looking that up for me! (Way beyond my ability to figure that out right now). I'm just gonna have to man up and make my own part from whole cloth.
  4. Dunno what to say, but nope, I get a face-full of Null Reference Exception. I suspect that the trouble is that I'm not trying to replace a flag or a sub-texture, like most of the posts here, I'm trying to replace the base texture. If you wanna say I'm wrong, try this: Create a new CFG file for a part (or just start with the mini-isru one and give it a new name), copy it to a new folder under gamedata Copy the stock .mu file to that folder Copy the stock .dds file to that folder Copy the stock .dds file to a new .dds file Set model.texture as I've done above Boom.
  5. Thanks @Electrocutor , does that process work for you? Looks like the results of the participants in that thread are a bit mixed. I got the same result that @JoePatrick1 got - a null reference exception. Did you ever get that figured out? My process was: 1) Create a new part, using the model from the stock 1.25m ISRU. In the cfg I've got: MODEL { model = Squad/Parts/Resources/MiniISRU/MiniISRU texture = ksp_s_processorSmall_diff, Squad/Parts/Resources/MiniISRU/ksp_s_processorSmall_diff_scribbles scale = 1.25,1.25,1.25 } ksp_s_processorSmall_diff is the name of the .dds in the stock folder. After suspecting the file format of my _scribbles file for a while, I have reverted to just copying the original file into _scribbles. No joy, still busted. So no chance it's a bad image file. There was also a lot of handwavy in the thread about which folder it should be copied into, but I tried: With _scribbles alongside the original With _scribbles in another folder With a copy of the .mu in my folder (the folder with the .cfg in it) alongside the _scribbles file (This fails with "can't find a texture to replace because I didn't copy it) Same as above, plus copy the original .dds file. I'm out of stuff to try.
  6. Is it possible to create a new part (new CFG that is) which uses a stock .mu with a custom texture? MODEL { model = stock/path texture = my/mod/path } I see other parts setting MODEL/TEXTURE, but since I don't know of any mods that do this, I kinda think it's not a thing. But there are mods like "stock parts overhaul", and I find it hard to believe they started from nothing... But I see they have their own .MU files for most stuff. Is there a way to decompile the .mu, maybe? Is that a thing that's done? Usually that sort of thing runs afoul of license agreements...
  7. This video might help you out; it's got a few minutes of content regarding thrust &c. that might help provide ideas:
  8. Jacked with it until it worked. I think my mistake was in copying some other parts that did 'mesh = blah' rather than 'MODEL { model = blah }'. My guess is that 'mesh = blah' doesn't do anything, really, and if KSP doesn't see a MODEL object, it looks for a .mu file in the same folder as the .cfg file and uses the first one it finds. The shimmering I reported is because I fail at smoothing, and one of my cylinders is actually still an n-gon, and as the image is rotated in the preview window, the model gets one pixel wider a few times a second.
  9. Yesterday I finally got my first ever part in a state that I was reasonably happy with and incorporated it into my mod! Yay! So I made a second one! And that went well too... But now I notice something I can't explain: my first part is now using the model from the second. Now, you can imagine there are a variety of ways I could have boneheaded that. But I've checked it every which way, and it's just not so. My .cfg's are pointing at different .mu's, and git assures me I haven't inadvertently overwritten my first .mu. Idunno - is there some kind of identifier baked in to the .file exported by Unity? I am using the same unity project for both parts. I also notice that when I look at the part-info page, the preview pic of the parts both seem to shimmy... Like it's actually drawing both models, one then the other.
  10. Per this guidance, it doesn't matter: FWIW, I've got the debugger working, but I too am being hit with the ~10sec delay after attaching the debugger. The guidance also now specifies copying in a new version of UnityPlayer.dll and WinPixEventRuntime.dll, which could use some commentary on the following in the OP: Is this really necessary or do the old DLL's work (haven't tried it yet in that configuration) If it's really necessary, then it's kindof a breaking change in that you're pretty much forced to keep a development KSP folder around, one that's not Steam-Updated, as Steam's likely to stomp those back into its own version. That was sortof a good idea anyway, but it was never an idea that I followed since I spend as much time or more playing the mod as I do developing it, I like to play it in non-debug mode.
  11. I'm just updating to 1.8 and hit a snag. I've got code that's trying to load a button image, but the old Texture2D.LoadImage method is no longer a thing. (See my example of what used to work in my GetButtonTexture method). Anybody got a pointer to a different way to load a texture in 1.8? Thanks. Derp, got my own answer by RTFM:
  12. I am completely new to modeling parts for KSP and near complete neophyte at Blender, so this is bound to be a dumb question... I'm starting out by trying to create a thing that looks like a Tank. 1.25x.5m tank. That's it. And I've managed to do it, if you don't mind that the tank is faceted. I've tried using a "Subdivision Surface Modifier", which makes the magic happen in Blender, but when I export it (via collada) and import it into Unity, its effect is gone. The "Smooth" modifier alone seems to do absolutely nothing to help, and when I look at the manual, I get the impression that it's not the right tool for the job at all. I can see how I could fix it by just making sure that when I generate my Cylinder in Blender that I make it have a whole lot of facets, but I somehow have the idea that's not the thing to do and it'll tank performance. Any tips? If somebody can at least point me at the magic word to google, I'd be obliged. FWIW, here's the tutorial I've been following to learn the basics of Blender: And here's the video that I've been following to get a Blender model into KSP:
  13. Have a look at the wiki help for this: https://github.com/SteveBenz/ProgressiveColonizationSystem/wiki#kerblab It's intentional that it's 5k days - you should bring more Kerbals. "Production" means how many are being produced & stored. I'm still looking for a way for the dialog to clearly state what's being produced & stored vs. what's being produced & consumed locally without being too chatty and confusing the issue even more. Thanks! I haven't used Configurable Containers - I presume that doesn't include any actual container parts, right? Which mod are you using for containers? (Or does this just re-use the stock fuel tanks for containers?) In theory, you shouldn't need to mess with volumes & masses. The Resources themselves specify mass/unit & volume/unit. (Though, as I recall, not in those terms exactly). So assuming Configurable Containers is built right, it oughta just work.
  14. My 11-year-old son and I talked over the space station problem - he gave me the idea that sounds like it'll kill two birds with one stone, at the cost of raising the difficulty a bit. The trouble with the station requirement is that what makes the most sense in the game is to not have a space station. You're better off building a single crew-transit ship with the scanner part just bolted on. Also, the part only requires one crew, so you end up with a station with one kerbal all alone up there - because until you get Tier-4 hydroponics, it doesn't make a huge amount of sense to have a biologist to run the hydroponics equipment. The idea we came up is this: When we design the new scanner part (assuming I ever can find the time to learn how to build cool parts), we'll make it much much bigger than the current part and make it require 2 crew, not one. That should help on a number of fronts: It'll make it so that you'll want to have an orbital station that you leave in-place, because you no longer will want to pay the delta-v cost of making it an integral part of a inter-planetary vessel. With 2 kerbals to support instead of 1, it'll make sense again to have a biologist on the station to run the hydroponics. It should help to balance the specialists -- right now you inevitably end up with too many pilots, geologists and biologists. On the down-side, it'll increase the amount of stuff you'll need to move up to orbit to support the station. I'm concerned that it'll make early game painful. I think the way to fix that would be to make a "Scanner-Junior" part that's not-so-massive and only requires one kerbal to operate, but it won't support T2+ operations.
  15. I released 1.0.7, which includes the changes I mentioned to allow for upgrading parts from Tier-2 onward. I've used it quite a bit in my own play-through, and I like it. I added a section about it in the Wiki. It's a bit challenging to get it done right, but I like to think that anybody familiar with EPL or PKS will be able to piece it together without reading the wiki. The only rough spot I can find (that I haven't already ironed out) is that the automatic resource transfer system will always want to transfer stuff away from bases that produce stuff. So, for example, if you have a base that produces rocket parts, but it doesn't produce enough rocket parts to upgrade everything you want to upgrade, you can't send down more rocket parts easily. You can do it, but you need KAS or some other shenanigans to link the ships. My own playthrough is progressing. I'm Tier-4 at Mun, Minmus, Duna and almost Gilly. I've got a base on Dres at Tier2 now. The Dres base was really challenging, as it's a bear to get encounter nodes to Dres and it takes a crapton of Delta-V and you've got to ship a lot of heavy loads out there to ensure that it can be a one-way-trip for the Kerbals. I just about blew it, coming into Dres too fast and had to eject some Rocket Parts from the crew module, which allowed me to just barely get a capture, then I had to use one of the cargo modules I had sent in earlier to shove the whole mess into a circular orbit. Then I discovered I didn't have enough power to actually run the ship when I decoupled the supply ship and had to use a bunch of rocket parts to build a wad of RTG's onto the ship. Planning! Yeah, that's a thing you can do! But I didn't. Or at least not in a timely fashion. Upon arrival I had a ship with a big slug of reactor fuel a few hundred days away. So the Tier-0 base sports a veritable porcupine of RTG's - mostly in order to support the ISRU unit. The next step on Dres is to build a Tier2+ base, plus a crushins rover on the limited budget of rocket parts available. Have you guys tried Near Future Electrical? I tried it in the past, but I just installed it again to find a really great new dialog for power & heat management! It's great stuff! Perhaps I can find a way to run my Dres base off of Solar after all.