JDCollie

This is my first mod; constructive criticism is very welcome! We at Joint Development Inc., like many others, have noticed that the 1.0 Mobile Processing Lab (MPL) is cool in theory, but somewhat lackluster in execution. Specifically, the MPL is greatly lacking in data storage. To remedy this, JDI has crammed a bunch of data storage devices into the standard MPL, along with some basic hardware to operate them. (We're sorry about that thumb drive you left on your desk, we promise it is being put to better use.) What this mod does I felt that the current stock MPL didn't really anywhere very well at the moment. It processes too slowly to be useful earlier in career mode, and has too little capacity later on. Additionally it has truly massive return if you were willing to timewarp babysit the thing. I aimed to fix these issues. - Moves the stock MPL earlier in the tech tree and reduces its weight. Nerfs the data-to-science conversion rate significantly, but dramatically increases peak processing speed to compensate. - Adds two extra MPLs to the tech tree with increased data storage capacity and processing speeds adjusted to that capacity. The parts: MPL-DSD-1 A Mobile Processing Labs sans some crew space. Not only does the DSD-1 boast storage for up to 3000 data, but also contains a co-processor which can greatly* speed processing of stored data. Notice: Data storage on this magnitude requires significant energy investment. *Slightly. Maybe. The DSD-1 is has a better data-to-science conversion ratio than the stock MPL, but converts at a slower rate.* It is heavier than the stock MPL as well, and costs quite a bit more electricity. In general it is probably an upgrade to the stock version except in situations where you aren't expecting much more than 500 data and/or have a serious weight restriction. *All labs, including the stock MPL, process at peak speed with completely full. However, a lab with a slower peak processing rate but higher data capacity may still produce more science even over a short term. This is because processing speed is directly proportional to how full the data storage is. MPL-DSD-2 Utilizing advances in Shove-it-in-Harder® technology, JDI has been able to more than triple the storage density of previous versions. The co-processor was even liberated from a real computer this time! The DSD-2 maintains its predecessors data to science conversion rate, while significantly enhancing available data storage, science storage, and peak processing rate. The downside is significant weight, and an even greater electrical footprint. Future Plans Custom models/textures Heat management Resource requirements Mod compatibility My goal is to create an alternative set of mobile labs which allow for greater data storage and processing efficiency, but will require coolant and/or radiators to function. Additionally, the stock lab, despite its shortcomings, is deeply overpowered. I'm hoping to reign in the raw science production a bit, while improving other characteristics in such a way that the labs are still attractive. I.E., more fun, less cheese. Stuff to Know Most of this information applies to vanilla KSP as well as my mod. A scientist's experience level (number of stars) has a HUGE effect on their effective contribution. Never use zero star scientists if possible, as even one star scientist is six times more effective! The processing speed of the lab is directly proportional to the amount of data stored in it. Try to keep you labs stocked with data. Dependencies Module Manager Download: Kerbal Stuff Source: Github 1.0 - Balanced return rates with my vision for the mod - Added CTT compatibility 0.2 - Added custom models 0.1 - Initial testing release In progress model for DSD-1: [table=width: 500] [tr] [td][/td] [td][/td] [/tr] [/table] All of these are just ideas. I may implement all of them, or none. I'm considering at least four labs total, five if you include the stock MPL. Stock MPL changes Balanced to be an alternative to more powerful options (but which have their own economic and logistic shortcomings). Probably unlock concurrently with the DSD-1. Reduce weight by .5 tons reduce data to science ratio (stock is 1:5) improve processing speed - I'd like to see the lab process about 35 data per Kerbin day when fully crewed, which would finish 500 data in about two kerbal weeks, rather than in a year or whatever. Basic MPL A preliminary MPL designed to be researched early on and give players science options prior to unlocking 2.5m capacity. Frankly, the stock tree is so small that this isn't all that relevant, but I'm building this mod with heavily modded tech trees like CTT in mind. 1.25m (possibly 1.85m) part 1 crew capacity 2:1 data to science return, but no homeworld modifier - currently the game reduces data conversion by 90% if you are landed on your homeworld. This lab would not suffer from that shortcoming. lightweight (1-1.5t) Rover attachment points for surface deployment, as well door placement with rover builds in mind. DSD-1 First DSD MPL, designed for orbital deployment. I'm hoping this one will be the core of early-to-midgame stations. Enhanced data storage over stock. (currently 3000) Electrical cost while active, enough to necessitate electrically minded design and placement. if possible, code plugin to have electric charge usage scale with amount of data stored. - I dunno if I can do this, but it would be cool Heavier than stock Reduced crew capacity, but increased return per science over stock - Net result is a lab with (hopefully) slower processing but better long term return, along with much greater storage capacity. DSD-2 Flagship DSD MPL Greatly enhanced data storage (currently 10,000) Increased power drain. Same science per data as DSD-1, but allow 2 crew - this means a direct performance upgrade due to second kerbal. Heavier than DSD-1 Drone MPL A very rudimentary lab unlocked fairly late in the tree. Designed to be placed on rovers you don't intend to recover. Processes data at the speed of a one star scientist , but operates unmanned. Profile similar to Material Exposure Bay, but heavier. lower data capacity same return rate as Basic MPL. (2 data: 1 science) Heating I'm considering a heating mechanic. If I can figure out how to code it, I'd like the DSD-1 & 2 to produce heat while storing data, preferably scaling the heat production to the amount of storage currently being used. If I did implement this, the heating would be scaled to be manageable with stock radiators. Cooling Alternatively, I am considering making the DSD-1 & 2 consume a "coolant" resource of some variety while they are in operation. The resource would be CRP compliant, and if possible I would just add it as an option to existing tanks via Firespitter fuelswitch. I'm not terribly sold on this idea though, since it adds some extra maintenance requirements, but no real gameplay improvements. COMPLETE Custom models This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Last time I checked (which to be fair was awhile ago) that mechanism depended on staging. If you didn't stage your vehicle, it wouldn't give you credit for the launch.

Did you weld the ring at all? I love those kind of stations, but they seem pretty prohibitive on the parts count unless you do some welding or have a ring mod.

Contracts can be influenced by strategies indirectly, in that most contracts are offered based upon minimum reputation requirements and some strategies influence the amount of reputation you gain, but as to how often offered contracts refresh and what influences the number offered at a given time, I have no idea (and would love to know too ) I don't know if "key" contracts count toward the maximum number of offered contracts (if there is such a maximum), but obviously it isn't much of a problem if you've upgraded your Admin building completely. You can simply accept and ignore all of them. Still, I hope key do not count toward that, because that could be a problem earlier if you somehow end up contract bottlenecked. :\

I'd keep doing what I do anyway, but not have to worry about part count or physics bogging me down.

I admit, it would be nice if mission time was counted from initial launch, not from deployment. The problem of course is that some vehicles use action groups or right click for ignition rather than staging, so it may be difficult for the game to detect/decide what actually constitutes a "launch."

This here was my first permanently habitable Munbase, and as such I made a lot of mistakes that really increased the difficulty of the build. If I did it again (which I intend to ) I think the process would be much more simple, and have a lower part count to boot. I've made lots of things since then (this was in 0.25) that were probably as complicated, but none that were as difficult for me. Oh, and Remote Tech was enabled on this build too On the plus side, despite the difficulty, the base could sustain life support for several kerbals indefinitely, manufacture fuel, and produce and launch vehicles. I actually manufactured about 60% of the modules for the base on site, rather than transporting them from Kerbin. Also, obviously not stock. Mods used included MKS/OKS, EPL, KAS, and lots and lots of others that I can't think of off the top of my head.

Same, I really like this one. I hope you decide to document you RSS adventures as well

In case it is relevant, I found this error as well in the log: [LOG 17:33:15.058] [ModuleManager] compiling list of loaded mods... Mod DLLs found: Assembly-CSharp v1.0.0.0 ModuleManager.2.6.5 v2.6.5.0 KSP-AVC v1.1.5.0 MiniAVC v1.0.3.0 DeepFreeze v0.15.0.5 DFInterface v0.1.5635.36579 / v0.1.0.1 SMInterface v4.3.0.0 Non-DLL mods added (:FOR[xxx]): Mods by directory (sub directories of GameData): ContractConfigurator ModOrientedTechTree MyCFG REPOSoftTech Squad [LOG 17:33:15.062] [ModuleManager] Loading Physics.cfg [LOG 17:33:15.064] [ModuleManager] Checking NEEDS. [LOG 17:33:15.105] [ModuleManager] Applying patches [LOG 17:33:15.107] [ModuleManager] :FIRST pass [LOG 17:33:15.114] [ModuleManager] Error - Skipping a patch with unbalanced square brackets or a space (replace them with a '?') : @PART[OPT [LOG 17:33:15.118] [ModuleManager] :LEGACY (default) pass [LOG 17:33:15.140] [ModuleManager] Applying node ModOrientedTechTree/TechTree/@PART[CanardController] to Squad/Parts/Aero/airplaneFins/standardCanard/CanardController [LOG 17:33:15.216] [ModuleManager] Applying node ModOrientedTechTree/TechTree/@PART[elevon2] to Squad/Parts/Aero/wings/elevon2/elevon2 etc . . . I don't know if the error is referencing ModOrientedTechTree, but I thought I'd post it just in case it helps you out at all. Also, changing "TechTree" to "@TechTree" at the start of the cfg does get rid of the "two definitions of the module 'TechTree'" error, but does not resolve the problem above, and MM still says there is one error error1 relating to ModOrientedTechTree. (which is why I think the above error may be related) :EDIT: Found it; the error is on line 8860, where "@PART[OPT Gears]" should read "@PART[OPT.Gears]"

Here's the cfg code for Mod Oriented Tech Tree compatibility. @TechTree:NEEDS[ModOrientedTechTree] { RDNode { id = cryogenics title = Cryogenics description = Tired of Jeb stealing all the snacks on deep space missions? The boys at R&D have come up with a better option than padlocking the cupboard. cost = 1000 hideEmpty = False nodeName = df_cryogenics anyToUnlock = False icon = RDicon_largeVolumeContainment pos = -885,800,-1 scale = 0.6 Parent { parentID = largeLifeSupport lineFrom = RIGHT lineTo = LEFT } Parent { parentID = lifeSupportConverters lineFrom = RIGHT lineTo = LEFT } } } @PART[cryofreezer]:NEEDS[ModOrientedTechTree] { @TechRequired = cryogenics } @PART[GlykerolTankRadial]:NEEDS[ModOrientedTechTree] { @TechRequired = cryogenics }

Could anyone point me to some documentation for the RDNode config node? I've looked through the original post and the wiki, but I didn't see anything. (Sorry if this is somewhere obvious and I just missed it) The reason I ask is I am trying to make a cfg that creates a node if ModOrientedTechTree is present. I've made the following cfg, and placed it in GameData/MyCFG/ but it doesn't seem to work. @Techtree:NEEDS[ModOrientedTechTree] { RDNode { id = cryogenics title = Cryogenics description = Tired of Jeb stealing all the snacks on deep space missions? The boys at R&D have come up with some better options than padlocking the snack cupboard. cost = 1000 hideEmpty = False nodeName = df_cryogenics anyToUnlock = False icon = RDicon_largeVolumeContainment pos = -885,800,-1 scale = 0.6 Parent { parentID = largeLifeSupport lineFrom = RIGHT lineTo = LEFT } Parent { parentID = lifeSupportConverters lineFrom = RIGHT lineTo = LEFT } } } @PART[cryofreezer]:NEEDS[ModOrientedTechTree] { @TechRequired = cryogenics } @PART[GlykerolTankRadial]:NEEDS[ModOrientedTechTree] { @TechRequired = cryogenics } If anyone can see any obvious errors (of which there are likely many, because I don't actually know what I am doing >.> ) please point them out. :EDIT: Nevermind, I got it working

Cool. And sorry, I hope I didn't come across as demanding or anything. I was just asking with the intent to make and share the module manager patch myself if it didn't already exist, but it sounds like rabidninjawombat is already beating me to it. I'll also look into making a patch for Mod Orient Tech tree.

Out of curiosity, what is the memory footprint for this mod?

Is this mod Community Tech Tree enabled? (I can't test myself because I'm not at my desktop at the moment) Either way I'm still downloading it, I'm just curious

Landing on Mun when batteries fail. Also, " . . . did you check the staging, Jeb?"

I keep getting lag in flight with contract configurator installed. It appears to be tied to these "contract attribute took too long" messages, but I don't know what is causing them and/or how to fix them. (or even if this is normal) It makes me sad because CC is pretty essential to my KSP experience.

Hmmm, interesting, and good to know.

I've been playing career mode, and I've been trying to reach the north pole. However, every time I send an aircraft, its engines start to overheat about 15 minutes into the flight. Turning the engines off and even landing don't seem to have much effect. Is heat not convecting properly, or am I doing something wrong? (This occurs with both the basic and turbojet airbreathing engines for me)

1.0x release? Seriously, thank you so much! I can't play KSP without this mod, it is just too awesome.

Thanks for the replies, guys. Sorry I wasn't more specific I don't think the graph in question was a slide rule per se, though it was similar. This graph was circular like a slide rule, but had lines drawn out from the center, with regular tick marks for values on them. The version the youtuber I'm trying to find was using was intended to be written on, and was used to easily estimate the delta v necessary for things like inclination changes. I'm also fairly sure the graph tool thingy was named after someone, and not just a generic name like circular slide rule. I wish I could remember it better, but then again if I could, I probably wouldn't be hunting for the video EDIT: I FOUND IT!!! It's called a Maneuvering Board, and the Youtuber is PurpleTargets.

Hey all, I'm trying to find a Youtube tutorial about calculating delta V using a circular graph thingy by hand. It was very in depth, and discussed how to estimate delta v for various orbital using this graph-ruler-thingy, but I can't remember the name, and it isn't in my view history. Can anyone help me out finding this? ( I know it wasn't Scott Manley or Bob Fitch, just so you know)

What about that really mathy one? The guy that has videos where he shows how to manually figure out dV requirements and stuff. Anyone know who that youtuber is?

I've played KSP for over 1000 hours. Since I got the game on sale for $17 US, I have paid less than two cents per hour of entertainment I have gotten out of this title. I don't love DLC, but I understand the marketing necessities that drive it, and it would be criminally entitled of me to complain about whether or not it is "worth it" at this point. So yes, I would buy DLCs to support the continued development of KSP if nothing else.

I have only played the game unmodded once. Ever. In over 1000+ game hours.

I'm playing a hardcore career mode playthrough right now (TAC Life Support, Deadly Re-entry, FAR, Kerbal Construction Time, etc) and no respawning. Keeping my Kerbals alive is part of the challenge for me, especially now that they gain experience. So far my only fatalities have been in the aviation department (which is why only Rookies are allowed to fly atmospheric craft)