Deimos Rast

TLDR: Not a bug; the cause and possible remedy is found inside of the SpareParts.cfg inside of the DangIt/ModuleManager Folder. Long explanation: I had an even longer one written, but I'm changing it, because I didn't realize the Community Resource Pack is listed as a dependency. This has to do with Dangit not defining its own resource, SpareParts, and letting the CRP do it instead (12.6 per unit). DangIt then decides to change the cost of the container of the SpareParts (i.e. your brand new Mk1 Pod) by an additional amount, before the game has even loaded. If you remove the added cost from the config, all your command modules will have screwed up costs (your $600 Mk1 Pod is now -$50) and I can't figure out a way around that. If your curious, the added cost to the Mk.1 Pod is $630 for 50 SpareParts, which works out to exactly the same price per unit of 12.6 already being charged to you by the Community Resource Pack. Why they need to double charge you, and why it still balances (that's what worries me), I don't know. I've torn the installation apart, the only thing I can't touch is the plugin, so it probably happens there. Seriously though, do you really need the CRP if you're just defining one resource (there could be other reasons that I don't know about). Hope that helps (probably not). Cheers.

Could you be more specific about how it "breaks"? I'll admit, I'm not far in my game with this mod yet (and it works fine), but is there a particular reason you need to set your craft to "base"? Also, @iamchairs has posted in this thread on Feb 10th, a little over a month ago. That's not quite gone. Not quite as active as I'd like, but still. Most mod authors are waiting for 1.1, which is coming Soon. It could be that, or he could be he's just a busy guy. I don't know, never met him, or said more than a handful of words to him. You've done a service to the Kommunity. Cheers.

I actually just had this conversation with @iamchairs on Friday. I'm in a similar situation as you: I have a copy I got from the KerbalStuff torrent and I was going to off to throw up a dropbox link in the mean time, but couldn't find find his liscense (which is MIT by the way). I PM'd him, and he responded within 24 hours (actually within 6 minutes). I thought he would take the logical next step and you know, post his license, or reupload his mod, but he hasn't and I'm worried this thread will get locked (hence why I handled it via PM). Since you've let the cat out of the bag, I guess you could try PMing him like I did. I don't want to nag him, and he hasn't been gone that long, and he has an active repo, eh...but still. His Response hopefully he won't mind me sharing his response (if so, sorry!): Not that I think it'll matter much if he doesn't update the OP with it. In the mean time if you're looking through the KerbalStuff Torrent, v0.3.4 of State Funding can be found at: /iamchairs_13651/State_Funding

Thanks for taking the time to reply. Twice. I think this is also a good intro, that answers a lot of the questions I had, but I didn't find it until recently. And I don't play stock either - perish the thought! I have a lot of mods, just not RO. (The reason I don't have RO, is because I have too many mods already, heh.) It'll take a bit of digesting your response before I can make a proper one myself, I just wanted to say thank you. Also, since everyone seems to be focusing so much on Engines for whatever reason (my guess is they're neato and there is a lot of data available), I decided to head in the opposite direction: Life Support, specifically TACLS. I didn't care for the one size fits all approach of the Resource/Fuel config (though serviceable enough), and I felt that life support was a bit more of a delicate matter (not everything should explode in other words). I also like the idea of almost always being able to have a slight chance to repair the damage and stem some of your losses (when it makes sense) - adds to the drama. Will I be able to repair the leak in my O2 canister or do I have to sit here and watch it slowly leak out into space? I also tried to incorporate multiple reliability curves (such as pressure and temperature) for added variety when relevant, (although I don't know what the pressure curve looks like at the moment). Unfortunately, I haven't had much time to test it yet (I'm actually building a test craft for it on my other monitor as we speak), but I do successfully get data on the parts I've tested. No failures yet. I figure I'll work on Heatshield and Parachute failures next, which will no doubt be a winning combination (I play with DRE and FAR). Cheers.

Oh, if you want an atmospheric converter that shouldn't be that much more difficult. I just tested my version and it actually worked perfectly the first time around. Which is totally how all my creations work out. Values could be increased, since it turns out ISRU takes forever, and this is my first exposure to core heat, but there are plenty of well documented values to tweak included. Do you even want core heat? It could always be optional, or there is a simpler, "if overheat, shut off" model. Also, I don't think you necessarily need to use CRP if you don't want, since it is an added dependency (at least for the full effect). You can just define your own resource and it's availability. Example: You would then use this resource in your intakes and production chain. If you're curious, CTN_Air is basically IntakeAir renamed. No personal experience doing it myself, just looking at other examples. ------------- Also, I didn't expect the lander can to have no bottom, which might change things a bit. I assumed it was basically another lander and designed accordingly. Meh. ----------- I'll PM you a copy of the current ore fuel ISRU lander, so you get an idea what I'm thinking. I'll rework it to use Intakes for "CTN_Air" (working title). I have no idea which planets are supposed to have atmospheres in this game (a short list I found says Kerbin, Duna, Laythe and Eve), but if you're going for C02...I found the CRP file on CO2 and I can work from that (FYI: CRP says it's CO2 is only on the planets I just listed) . Do you want it to just be C02? Also, just CO2 from the air (i.e. no storage containers/exhaling)? One also has to think about people (like me) who play with additional planet added, which I don't think CRP accounts for either. You could define it as a global resource and the make local exceptions, that would hit everything I think.

Yeah, I hear you. I figured as much, over and done with. Moving on: I'm building you an ISRU. Well, making a new part config, and probably a couple others. I saw yours. It looked swell. I was wondering where the C02 was coming from, since to the best of my knowledge, you need more than the CRP to get a resource to work. I believe, and don't quote me on this though, that the CRP is just the standardization of commonly used resources used by other mods. The CRP doesn't use or include any resources in and of itself (well, technically it defines them, so it does include them, but it doesn't include any parts that generate the resources, so a player has no way of accessing the resources, nor does it generate any resources "on the ground" I think). To get your ISRU to work, as it stands, the player would also need to have Thunder Aerospace's Life Support mod installed, and would be converting CarbonDioxide (which is the waste product of Oxygen, a Kerbal's breathing air) from the Waste C02 tins (or from the C02 that slowly builds up from exhaling kerbals) from that mod into rocket fuel. That seemed a bit odd. I could be reading it entirely wrong though. I should also mention I've never made it to Duna, so maybe it has a C02 atmosphere after all. ------------------- What I've done is basically stuck together your base lander with a miniISRU, fully featured. If you'd like, I can include Carbon Dioxide > Rocket Fuel, but I feel like that adds too much complication (and unnecessary dependencies), as that can already be produced with ore. Wait, you do want ore > rocket fuel, right? I also added and balanced out some features (hint: crew reports, science container, your max/min drag values are flipped, crash tolerance is a tad low, added modulecommand/mincrew1, vesseltype lander, category pods, etc) I can shoot you a PM with a dropbox link of the ISRU if you'd like. It's not done (needs intakes & atmo checks still and there is balancing to think about) but it should work as is (was about to reload my game to test it actually). More importantly, I commented/documented/explained all my changes if you're curious as to the why. Also...there is core heating now to think about. When I said I stuck together an ISRU and your lander, I meant everything, and I think it's probably necessary for gameplay balance. We shall see. Currently, all the values are exactly ripped from a miniISRU (all standard fuels/combos can be made from ore). Not saying you have to go with this, or even use it at all. As usual, feel free to incorporate my suggestions into the base design or not. My suggestion, and this is direction I'm going with, is make two identical looking lander cabins (or maybe add slight ISRUish looking wiring/pistons to the second if you really feel like it): the first is a bare essentials lander, no ISRU; the second contains the ISRU but is also x2 the mass (mk1 lander is 0.6, your lander was 1ton, miniISRU is 1.25, I made mine 2.1). I might play with it a little more to make it seem a little more awkward (could adjust CoM, or drag), nothing too major though. Thoughts?

@-ctn-This post might be a little bit of a departure from my usual "I love all your stuff" mode, and while still true, I think some of what @Wolf Baginski might also be true. Granted, I don't particularly like his delivery, but I think he might be right about the attachment nodes. I don't know much about nodes, having never created or edited them, but I have spent a fair bit of time in other people's configs lately and it seems like pretty much everyone does it like that. I don't know if it makes it "better" but to my mind it makes it more organized, which is inherently better. I have also spent no little time in your configs as well (out of curiosity, but also for balancing/testing and such) and this is something I've been meaning to bring up, and now seems the time to, but your naming conventions could use some work. It's a trivial thing, but instead of naming your solar panel "solar" why not "ctn_solar" (at this point, changing it will cause save breaking issues I think) and your 2.5m solar panel has a space in its name ("2.5 solar") which breaks MM configs (unless a wildcard * is used, that's when I learned about wild cards, heh). By naming your solar panel something so obvious and generic, you run the risk of conflicting with other people's mods (it can be changed by the user obviously, but we're talking best practices moving forward here). Keep in mind I have no formal training in any of this, in real life, or in KSP, this is just stuff I picked up over the past couple of months, seat of the pants like. You have way more experience than me at this, but I see you making these few mistakes (but you do seem to be improving with the last few releases). We could also talk about consistent folder structure, but I think that's more of a personal taste thing, and you seem to have settled into a groove on that. Just keep in mind if you make in wild swings now (renaming everything, rearranging things) you run the risk of breaking people's game saves (which is bad), unless you specifically include legacy support (which I guess is just keeping a symlink/duplicate copy at the old location/name). Also, to be critical of @Wolf Baginski now: he mentions the Kiwi engine from Necrobones, and starts throwing around its TWR numbers. With respect to Necrobones (and I literally have every mod he's made, and they're fantastic), the Kiwi and it's big cousin the Moa, are odd engines. Besides being surface attachable (which, whatever, it's a thing I guess), they are just all around overtuned (and overpriced in my opinion). Moreover, you have to know the perils of taking a single engine from another mod pack (popular though that mod pack is) and then saying "your mod doesn't perform well with this small sliver of this other mod pack, fix it." That's what MM Configs are for. That whole paragraph, which I should quote in full, but won't due to the length of this post already, is riddled with extremes that there is no way it could be balanced around. Unless the mod author specifically mentions "this mod pack is for XYZ" ....I'm belaboring the point, you get the idea. I just think you're being unfair. --------------------------- And lastly, on another topic: ISRU. Could you describe a little more what you'd like the ISRU you function to look like? I don't think you'd need an actual plugin, everything should be able to doable with an MM config. I think. You seem keen on the idea of atmosphere checking, which might be the only kink. Basically, my current thinking is to clone your parts (copy the configs really), gut them, and stick in an ISRU, maybe add some Ore storage (with optional Kethane/Karbonite MM configs) to the fuel tanks (I'm still not sure yet which parts you keep, my saved game got corrupted before I could try it). Atmo checks could be handled a number of ways I think, but I'd need to look around first. ------------------------ TLDR: I still love your stuff, but I wouldn't just dismiss Wolf with a "not every mod is for everyone" even if that is true, and even if his posts were a bit off, I still think he's on to something. Maybe. Cheers. (posted without morning coffee yet)

@Bloody_looserI like your backpack, but I unfortunately play with TAC-LS, so I re-wrote the config to give it compatibility and added some KIS storage space. And I had such a grand old time doing that, I decided to um...expand your line of backpacks to include the entire functionality of KIS. Yeah. It was at the point that I turned my attention to the Community Resource Pack and started seriously thinking (and indeed started to) make configs for separate backpacks for those resources, that I figured I better stop a moment and check to see if you're okay with this. Your license is CC 4.0 BY-SA-NC which I believe does allow me to do this, but I'm more concerned with not stepping on your toes or stealing your thunder, as you expressed an interest in expanding your line up and this sort of overlaps that. My plan was to share the configs here, under the same license, giving credit to you naturally, because they use your backpack model and texture and I referenced your config (I would also likely credit the makers of KIS, due to the extensive usage of KIS modules). Anyway, let me know your thoughts; can be either public or via PM. Cheers.

So I figured I would give this another go, since other mods aren't quite giving me the level of explosions that I require. Initially, I was (and still kind of am) put off by the amount of leg work this requires, but diving into and messing around with the configs for the past hour or two, I have to say you guys have created something really cool here. (I still don't get why there is a combination of both good documentation and great features, but almost no configs! I feel like I'm missing a download or something, but no ). All I've really done is read through the wiki, taken notes, read through the Stock and RO configs, taken even more notes, all so I can blow myself up more frequently. How kerbal. So if you'd please, I have a few questions, which if you could answer some or all of, I'd be much obliged (even if it's just a link to more info). In no particular order: --------------------------- What would the TestFlightReliability_SkinTemperature (or InternalTemperature) curves look like? It says "1.0 is normal, higher fails more" so for a 10% failure rate at 0 data...? temperatureCurve { key = 0 0.9 key = 10000 1.0 } I looked through the entire Stock Config and RO config, and nowhere are these curves used, so I don't have any examples to go by (and up till now, I never knew what these "curves" even were!). -------------- duRepair = 50 duFail = 100 What does this mean? If I remember correctly, "du" is the data unit, correct? I thought it might be the minimum data required to repair, which might make sense, but having a minimum required to fail doesn't really. -------------- Failure Rates: I feel like I should know this already, but are failure rates solely determined by the curve, and then the type of failure it determined based on the weight assigned to it? ------------------------- TestFlightReliability_EngineCycle -------> ratedBurnTime What are the units on this? My guess is seconds? ------------------------- Repair Module: canBeRepairedInFlight Does this mean in the "Flight Scene" (as in while you have the vessel actively selected) or while the vessel is "In Flight", as in engines burning, flying. It has to be the former, but it's late, I'm tired and I need clarity. I have a great mental picture of the latter, though. canBeRepairedByRemote The opposite of above I'm guessing (assuming the former is correct)? --------------------- That's it for now. If you have any suggestions for further reading, please let me know (I still have to read through this thread). Off to go see if my test engine config works! Thanks.

It's a parts pack, so unless RO changes the "ElectricCharge" resource (which, it might come to think of it, or Real Fuels might) it probably will work, since that's the only resource currently included. @-ctn- This is probably a question you'll get a lot seeing as RO, or at least the Real Solar System mod, actually adds Mars. Next question will be: "how well do your solar panels work on Mars/Duna?" (since the suns rays are weaker there and such). Re: Rx Wheels: I think the reaction wheel issue might be a gameplay compromise, since to my knowledge, stock (and most mods) don't have radially attaching reaction wheels, so unless you add one interally, the player is kind of hosed. If you want to compromise on a compromise, you could set it low. There is always the option of the player adding rcs thrusters, but that seems silly in my opinion with something this size. You could also add it as an optional MM config if you really wanted to distance yourself from it, heh. Options options. Re: the lights. I think that picture might be more hollywood being dramatic than an actual realistic shot, but yeah, your's look about like that. This one might be more to taste, since I'm usually cranking up ambient lighting and slapping head lights on everything, so might be best to get additional input. Oh, and I was right about the TAC Life Support: It automatically adds 3 days worth of food/water/oxygen to the rover, which is probably fine for now. When you add more capacity, I might bump it up to 5 or so (can't have anyone fighting over snacks!). Also, the "vesselType = Probe" comment I made: I think that just means the rover would be classified as a Probe on the Map screen, which the player could change in game. It wouldn't give it the ability to be unmanned or anything (that would require both "minimumCrew = 0" & "CrewCapacity = 0" I believe).

Note: I write this about the 1.0 version, haven't checked out the update yet. Also keep in mind I have no idea how to Rover. Alright, I let Jeb give her a spin and the results were a bit mixed (partly because it was Jeb and also because I don't know what I'm doing). I spent a fair bit of time on my back, but she was a trooper (battery kind of got wrecked though). Tires were the stock ones in the OP, they attached very nicely. The entire Rover looks great in the VAB and puts together well. Some thoughts and feedback in no particular order: - The biggest complaint I have is with the trailer, specifically the hitch (see screenshots below). No matter how you try, you can't get it flush with the Flatbed in front of it. I think this could be solved if you made the hitching post underneath flat instead of angled, because as it is now, you can't attach to it (unless you want to use the angling tools) without it coming out skewed. You can compensate by dropping down the wheels so everything at least has an even contact surface, but it still isn't flush on top. I was also disappointed that you hadn't magically discovered how to create a working ball and socket joint, but I suppose KSP is still KSP at the end of the day (Infernal Robotics maybe?). No biggie. - Lights could stand to be a tad brighter maybe; as it is, I can't see them in the VAB and only at night outside can I tell if they're on. Have you thought about adding Cabin Lights as well? - What about an attach node on the top of the rover cab? Sure, surface attach things work currently, but it would make the "roof rack" concept a little more flexible. Might break up the lines/shape though. - Since I flipped a few times I noticed something: there is no included reaction wheel. It wouldn't be a misplaced feature (I know I'll add one regardless). - KIS: I don't know how it works exactly, but I think the way you have the configs written makes KIS a dependency of ARES to get the Cabin/Trailer to work. You could add a ":NEEDS[KIS]" to the relevant module, and I think that would work, but it might not be a bad idea to make a separate MM config that adds KIS to the parts, that way people without it can use the rover without having to perform config surgery. Not a 100% sure on this one, but I figure I'd mention it. - KIS: Inventory Size (volume) of 4000 in the cabin seems a bit generous (2000 also does as well, but that's a trailer). If you do change it, please don't change the X,Y layout, as I hate it when I'm confined to a tiny little box (what you have now it great). - Handling was crisp and seemed relatively balanced (front to back) but I'm not sure how much of that is the wheels. Braking too sharply was bad, which you never are supposed to do anyway (she titled forward). I forgot to check my COM before hand, but here's a screenshot of it after the fact. It seems a bit high, but I'm not entirely sure what it should look like. Note: the battery weighs 2 tons, as does the trailer its sitting on, whereas the cabin itself is only 1 ton. Here is a shot of the offending trailer hitch. My suggestion is making it smooth/level/flat/flush/whatever so I can attach the pin to it straight on (I hope that makes sense). It would effectively allow the trailer to down a couple of inches (or a few centimeters, take your pick). Overall, I think you have a winner here. Does it come with a payment plan or roadside assistance?

So I looked through the configs out of curiosity and to make some adjustments, and here's a few points of feed back, mainly nitpicks, (obviously this a WIP release, but the goal is eventual balance, which is a subjective thing): Cockpit: Crash tolerance of 9 seems a bit low and there isn't any breakingForce/Torque entries (not sure if the game has default values for these?), but seeing as the trailers have crash ratings of 80 (granted those are solid metal). vesselType = probe & RequiredTech = largeUnmanned; is it intentional that a manned rover follow unmanned tech requirements? OP states it uses Mk1 pod internals when it's actually the Mk1 lander cabin, unless "landerCabinSmallInternal" is actually the mk1pod internals? Trailer & Hitch Cost of $30 seems low given the higher priced entry costs Trailer Hitch's title reads "ARES Trailer Flatbed" which I'm assuming is a typo. Battery looked fine. None of the above are major issues, but I figured someone would post them eventually, might as well be me. Also, I'll probably make a TAC Life Support MM config for this, and if I do, I'll probably post it. Is there a certain number of days life support you think is fitting? TACLS will automatically add food and such to this, but my guess is it'll be only like 3 days (1 crew capacity currently, same as Mk1 pod), which seems low for such a contraption. Off to actually give it a spin!

Grats on the (working) release. Smart move on the wheels, I was worried this would be sidelined because of that. Downloading now; should be fun.

Ah, I meant the Filter Extensions Mod Yeah, I get what you're doing, and it seems pretty clever, I've just never seen it done in my brief time looking at configs. Out of curiosity, how did you come up with your numbers for the resource conversion? I realize that's a rather broad question (answer: "maths"); your configs are rather well documented, I still need to work my way through it all. Did you just look at TACLS's numbers and work from there or...? What I mean is you have numbers like "0.07123842592593" (whereas I would just round it to the hundredths and call it a day, heh) and I guess I don't get where they're coming from. Cheers.

Some inflatable habitats are defined in the configs as having 0 crew capacity, but have a module that has an effect that then adds crew capacity to the part upon inflation. How is this any different than what you said? It's not really, except that Ship Manifest probably doesn't read into the the individual modules, only sees their effects. Just a hunch. None of this helps you any, but might help @Papa_Joe understand the problem. Example from Porkjet's Habitat Pack: MODULE { name = deployableHabRestrictor animationName = deploy crewCapacityDeployed = 4 crewCapacityRetracted = 0 }

Yeah, I'm running 0.20.3, I suppose I could reinstall it and try that again. I'll try a clean install of Ship Manifest again too. And I suppose I'll do it on a clean install of KSP while I'm at it. The thing is, you said in the change log to 5.0 that you were using a Deep Freeze dependency or something, which you moved away from ("Removed need for DFInterface.dll. Now using new reflection class method for soft dependency to DeepFreeze") Or maybe not, not sure how to interpret that statement, now that I look at it. I already have a copy of DFInterface.dll from JLRepo (I run a number of his mods) - could the two be conflicting? Switching to 5.0 made the problem worse, as the roster closed out completely. In the previous version, it was garbled, but still somewhat usable (and I've switched back to it for the time being). I looked at the two DFInterface.dll's side by side, and while I don't know how to read them, the bytes both read 10,240 and date modified is Tue 10 Nov 2015 02:40:38 AM CST for both so I'm assuming they're the same. That is the only thing I can think of. I'll bite the bullet and upgrade to 5.0 again so we don't have to deal with a potentially outdated issues that might no longer be relevant in 5.0. Any known mod incompatibilities? I have a lot of mods as I mentioned and I'm a bit reluctant to just stab blindly in the dark to try to troubleshoot this. Anyway, thanks for the response, much appreciated.

uh...I knew that, I was just testing you. Congrats, you passed! o7

@Bonus EventusYou do some wonderful work; reading through this thread has been fascinating to watch this develop. I've had this pack installed for awhile but only now just started to unlock parts for it - not what I was expecting at all. From a design perspective and aesthetically, they are very different from every other part pack I've seen and stand out. And the parts are big! Well done!

So...this is strange, but your parts aren't picked up by Filter Extensions, at least in the Manufacturer's tab (the only one I've checked, but I actually sat down and searched through every item in my game), but searching for them (via the mod QuickSearch) they show up. I looked at the parts, and I think I know why it is: you define your parts an addendum to another part (or something, not sure what to call it) and I don't think Filter Extensions likes that. It also makes it extremely hard to modify with MM configs. Basically as it stands, I think I would need to rewrite all the configs (which may or may not take that long) to get them to show up. I'll admit I'm pretty new to reading configs myself (and MM), but this is the only explanation that jumps out at me, and the only time I've ever seen anyone do something like this...ever. I'm not trying to be critical, I'm just confused. Still interesting though, especially the resource conversions. Cheers.

Today I learned there are monoliths in game... This looks fun. Might I suggest making a link directly to the github release page in the OP for people who don't use CKAN (namely me)? I had to dig for it, and it took like...two extra clicks. https://github.com/jrossignol/ContractPack-AnomalySurveyor/releases/ Thanks! (and I have SCANsat, so I knew...something...was out there, already, just not what)

@nightingale thanks for all your work with this and other contract packs (and Strategia); really adds a lot of immersion. My favorite is by far the tourism plus one; those missions are a bit crazy, but provide a lot of fun. Cheers.

big fan of the Alternative Resource Panel, but you're right, not enough icons! Downloading now. Thanks for this.

/storage/regex_94/KSC_Switcher

Congrats on being mentioned! Check out his other stuff too.

Here is my log in the off chance it's of use. It's not a complete log (till game close) and doesn't capture the successful transmission of the "bad" data (as my game has since overwritten that log unfortunately) but it does show me trying to transmit that same data from the other two satellites, so that bit might be of interest. Also of possible relevance was that I was using hyperedit to...adjust....orbits of the other satellites (from minus/mun back to kerbin) which might have affected things, but hasn't in the past. Cheers.