Pirsig

Hey so if you were still interested in using stuff from this for something the license totally allows you to do so without even asking so long as you give credit and license accordingly so do feel free to do so. I've honestly had a rather busy and anxiety filled first half of the year which is why I just kind of disappeared. Wasn't playing any KSP or working on this at all either. With life dying down a bit (hopefully, still have a move coming up) and KSP now fully released I will most likely come back to this as I still feel the stock tech tree is junk and there's still plenty of room for most of what this mod does/was intended to do. When that will be I don't want to make an promises or anything, but I did want to stop in and just say I'm not dead or anything XD.

I can assure you that code really does nothing, @ doesn't add parameters it only edits ones that already exist. After talking to Arsonide (author of Fine Print) and confirming that in fact the only condition Part Test contracts are looking for is your first launch from the launchpad, I believe I've found the culprit. The launch does not count if your vessel is not touching the ground. This means that when using a launch clamp or something, you might actually not be touching and therefore your launch won't count. It is mere coincidence that you had a launch that registered correctly when having the RT-10. This merely has to do with how you design your vessel and is why I was able to have problems with the contracts on one install but not another, and why you're experiencing issues, but galen isn't. Sorry about that, I figured all LS mods handled it such that vessels don't require LS resources when in atmo on Kerbin. I'll make a change for the next release that gives the atmo cockpits 1 LS resource (1 day's worth) per kerbal for interstellar.

That line is useless. As far as I can tell (can't actually decompile per eula) the part test contracts aren't looking for any sort of check on tech. Without going too deep into how contracts work, the only check I can find for it to begin generating the contracts is, "have you launched a vessel from the VAB?" This means there is no way to change the conditions that it's looking for short of a plugin that replaces the contracts with a new version with different generation conditions, just like the altitude contract issue. Also, that line is useless because Test{} has no Tech parameter in it already. @ is used when you want a patch to overwrite an existing parameter, but not create it if it doesn't exist. % will overwrite if exists and create if it doesn't. No prefix creates a new parameter, if one already exists with the same name, you'll have two. So the way that is currently written it changes absolutely nothing, which is good because it might muck things up for you if it actually worked. This same reason is why no, the Tech parameter in the contract fix should not be an @. If it was, it wouldn't work and would do absolutely nothing. No worries, unfortunately the documentation for Module Manager is a bit... scattered. For instance, if you want to learn how to correctly use the variables I think you still need to find the post in the thread from when the first version with variables dropped. S o yeah, finding documentation for certain stuff in MM can be a bit wonky. That said, the front page and this from the wiki are the two most cohesive source of information. Everything else is kind of scattered throughout the thread and various discussions. Beyond that it's like any programming language in that you can glean a fair amount just from reading other configs once you have a basic understanding. Though there's lots of configs out there following very poor practices, because why follow standards when you can be different and difficult for no good reason? Sorry, giant pet peeve of mine... Yeah, I wish there was stuff to help differentiate performance capabilities of cockpits more as well, but alas... Also, upon further examination in general I feel like some of the parts are too far up? Most modern aviation technology all seems to have come into its own at relatively the same time spanning 15 years or so surrounding WW2. (Most of this is centered around advancements in turbine engines for aviation at the time) So helicopters, for example, after crewed rocket flight seems kind of odd. The only exceptions would be the jumpjets (harriers are from the 80's) and the electric propellers (70's, though still largely experimental even today). I know I don't have specific written guidelines (I really should, they already partially exist for my own benefit) but the tiers do loosely corresponded to time frames, among other things. I'm gonna take a quick pass and shift a few things around, post it, and you can let me know what you think. On the other side of that, a couple of the changes you made to stock for KAX are probably going to become base KSAEA changes, for sure the tail section at any rate, not sure why I had left that so far up the tree.

So, a couple of things. First, :FINAL[] and :FOR[] are not used together as they're both telling MM which pass to run the patch in. So if something has :FOR[KSAEA] it runs in the pass for KSAEA, if it's :FINAL it runs in the final pass. Good practice is to keep things in a mod's particular pass whenever possible (KSAEA in this case) and to keep stuff out of :FINAL unless a patch wouldn't work otherwise. For personal use :FINAL is fine. In fact that's why it's good practice to keep it clean, so people can use it for personal modifications without having to resort to crazy naming crap to make sure a patch absolutely runs after something else. For your personal use until integration you'll want to take out the :FOR[KSAEA] on the stock stuff and just have them run in final. When I do the .5 release, which'll have the KAX config in it, the way I get around this is just by adding an exception (:NEEDS[!KAX]) to all the parts in StockTechTreeRebalance.cfg that will be modified if KAX is installed. You can look at the starter antenna in that config if you want to see it, only difference is that's an exception for remote tech, but yeah. The exception allows the mod config for KAX to then still run in the KSAEA pass. Also, I was curious why the move for the nose cone and the mk1 cockpit? Unless I'm missing something I feel this is unnecessary.

I think firespitter's always been a bit of a laggard but the .dll is usually up to date since several other mods rely on it, and I believe it has in fact been updated for .90. Not sure if all the parts work the way they're supposed to and such though or not, think latest posted version is 24.2 for the parts? That doesn't mean they won't work, just that they might not. Either way obviously I've got no problem with you giving it up for the time being. Especially since it is in a weird state at the moment, though so are a couple of the LS mods. Personally, KAX has tempted me more than Firespitter in the past anyway. Thanks, glad you like it. Unfortunately it's not just the SKGU that won't let you complete those altitude missions, it's ALL probe cores, as galen said. Unmanned flights cannot complete these missions because that's the way squad programmed them. After some investigation prompted by earlier discussion on the subject, it seems that there is no practical way to change this. The only solution I can see would be a plugin that adds a new contract that is basically a copy of the altitude contract, but also allows probes to complete and then prevents the original altitude contract type from spawning, which I'm not sure that second part is possible/allowed. Either way it's outside the scope of what I intend to do here. On the subject of contracts I've also spent some time trying to figure out what was going on with the part test contracts. I thought I was experiencing issues on one of my test saves, until I launched a vessel and then they showed. After messing around a bit, it seems the part test contracts won't spawn until you launch a vessel from the VAB (not SPH) that gets at least a few feet off the ground. Probably once you're out of the launch pad's weird pocket of space. Why on earth they would tie the part test contract generation to such a condition is beyond me, but that seems to be the case. In light of this, if anyone is still experiencing issues with the part test contracts I'll need some more information on the matter otherwise I'm considering it solved. Also galen, sorry, i typed this last night and forgot to send before falling asleep so I haven't looked at the KAX config you posted at all yet, I'll probably have a chance to go over by the weekend.

Ever since the difficulty settings were added this mod has no longer really modified total science values, and it never modified the body multipliers. Originally I was basically providing the same functionality as the Science Rewards slider does now, with a default setting of 80%. I removed that with the introduction of the slider and now only one or two experiments have their actual total science (scienceCap) modified by the mod. The only thing I can really recommend is to bring the slider down further for science rewards, and maybe up a bit for funds rewards if you're having an issue there. I've been getting part test contracts with fully researched versions of the tree, so yes it's probably the same as the problem that was keeping the survey contracts from showing up early, I'll look into this. Also, most of the parts added should still have modules for the part test contract. As for actually modifying contracts, I had given zero thought to it thus far to be honest. I'm not saying it's totally out of the question, just that I haven't looked into it really at all. It's something I'll put a bit of thought into considering now, but wouldn't expect to see anything on the matter too soon. For action groups I would recommend Action Groups Extended. Aside from all the handy extra action groups and such it can also be used to override the lockout.

Eh, yeah, it would seem I changed the values but not the part names. Glad you enjoy the mod and thanks for pointing that out, it'll be fixed in the next release. Also, with the names changed to the correct parts for those two configs nothing about elevon 4's capabilities should be getting modded by KSAEA, just its tech tree position. If elevon 4 is in fact weaker it's most likely coming from somewhere else. As for elevon 6 being weak, it's supposed to be, its small and supposed to be used for controlling small rockets at the beginning of the tree before you have other control options. I just did a quick flight with the SKGU(no reaction wheel), a nose cone, couple mx fuel tanks, an lv-01 and quad lv-1r's (no gimbals) with the structural wing E and elevon 6 for control in a quad arrangement and had no problems reasonably controlling the craft.

Ok, yeah, it was actually super straight forward. Wasn't sure it would be, but simplicity wins, hurrah! Just put this config in the KSAEA folder and that should fix the visual surveys contract issue. ContractFix.cfg

I still have very little actual "play" time with current patch so I hadn't noticed this at all, I'll look into making an MM patch to fix it. I don't think MM explicitly states that it can target other stuff besides Part configs, but it does. That said, the Contract config is not setup in such a similar way as say the experiments config and so might not be doable, or may be interesting to make work. We shall have to see, but I suspect there will be a way to make it work.

Pretty sure I got all the new parts covered for the moment and everything seems to work ok, but you're going to want to delete StockFixes.cfg and make the following changes to noseCone0625.cfg: rescaleFactor = 0.5 node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0 Squad fixed the problems with the stock model that was compensating for.

Alright, so just a quick and dirty update for .90 to cover all the new parts. I also added a small wing and control surface to start for controlling small rockets. I did not mess with any of the new SAS level stuff yet, I'll add that to the SAS rebalance for .5. I also did a couple of quick patches for small mods, MechJeb, RealChute, and SCANsat. I did not mess with science values for SCANsat at all since that has it's own thing based on % scanned and stuff that all makes perfect sense and I felt no need to mess with it. There's also a couple tweaks to existing reaction wheel values and the SKGU. v .43 -Tech Tree Rebalancing for SCANsat -Tech Tree Rebalancing for Real Chute Parachute Systems -Tech Tree Rebalancing for Mech Jeb -SKGU Probe Core Electric Charge increased, consumption rate decreased -MK2 Drone Core SAS torque has been decreased to .75 -Probodobodyne OKTO SAS torque is now equal to that of the Probodobodyne HECS -The new MK3 Cockpit has had SAS rebalanced and is now governed by the global reduction -New Aerodynamic parts for small rockets, includes FAR & DR support -Tech Tree Rebalancing for new stock parts Download v .43 So, next version should have the new approach to the upper tier construction nodes I was talking about as well as rebalancing for probes. This currently involves changing weight, power consumption, and adding decent amounts of onboard electric charge. I'll also add the new SAS level stuff to the rebalance, and probably break out the reaction wheel stuff to be its own config. The ridiculous capacity of the MK3 passenger section is also something I plan on remedying. I'm also going to add a .version file for KSP AVC and switch to that versioning scheme with 0.5.0.

Hey, yeah, I'm working on putting out a quick update with some of the minor stuff I've done the last couple weeks and making sure everything is all good in .90, which I've just gotten a chance to install today. Browsing the changelog the only thing I could see causing issues with stock stuff is if the MK3 rework changed names or added parts or anything that stuff will need to be fixed up, which I'll be looking at right after this post. Other than that I don't see anything which screams out that it would cause an issue. How do you feel you're coming on the firespitter thing? If it's nearing a point where you think it's ready for folks to try it out I'd like to get a look. Also had not seen that stock revamp thing before. Assuming you're using it, are there any issues with compatibility for that I should take a look at? Glancing over it seems it just changes model stuff, is that right? If so I think the only thing would be the part rescales using old models which I can easily make a fix for.

Thanks, I hope you enjoy it. As for control, atmospheric flight should be controlled using control surfaces and gimbaled engines and space flight is RCS controlled. That is definitely cool and I've already downloaded it it to take a look at. Thanks for pointing this mod out to me.

So I searched through the thread as well as looked over the various different config options provided by the mod and didn't see anything so I'm figuring the answer is no, but I thought I'd ask to make sure. Is there a way to limit the sizes available based on tech tree progression? If not, are there any plans to implement this in the future? Edit: Another follow up question, if the answer to both of these is no, are you opposed to me making new part configs from the current ones and distributing them with my own mod? With whatever attribution is necessary of course. This would basically be another version or two of each already existing part, just to split up the size availability, everything else would remain untouched.

Good evening everyone, back in with another update and a quick look at where some things are headed. First off I've got .42 out for you here which includes the previously mentioned Universal storage integration as well as all the mods supported by it. I've also updated the DMagic configs for the new parts and experiments recently added to that mod and all of its US parts are now integrated as well. .42 also adds a life support rebalance, removing LS resources from atmospheric only cockpits for all supported LS mods. The SKGU Probe Core has also been added, a new probe that is researched in the starting node with poor properties that hopefully make it obsolete quickly. It's expensive, has high energy drain, and no SAS of any kind. Nathan, you mentioned adding a new small gimbaled engine or reworking one of the existing ones to go along with this, I haven't ignored this advice I just haven't decided how to proceed yet. I've also added patches to the end of all the KSAEA parts for DR. This is mostly copy/paste of the values used by DR for the normal version of the parts, but not in all cases. This was done with the new beta maxTemp values in mind, not the higher temps present in the current stable release. You might notice I've also renamed the mod a "Tech Tree and Game Rebalance." I felt I was clearly outgrowing the original scope of only modifying the tech tree and science values and this should probably reflect that. v .42 -Tech Tree Rebalancing for IFILS -Life Support Rebalancing for IFILS -Tech Tree Rebalancing for ECLSS -Life Support Rebalancing for ECLSS -Life Support Rebalancing for Snacks! -Life Support Rebalancing for TACLS -New part, SKGU Probe Core Added -Science and Tech Tree Rebalancing for new DMagic Parts -Tech Tree Rebalancing for Universal Storage -Tech Tree Rebalancing for Universal Storage ECLSS Pack -Tech Tree Rebalancing for Universal Storage IFI Life Support Pack -Tech Tree Rebalancing for Universal Storage Kerbal Attachment System Pack -Tech Tree Rebalancing for Universal Storage Snacks! Life Support Pack -Tech Tree Rebalancing for Universal Storage TAC Life Support Pack -Tech Tree Rebalancing for DMagic Orbital Science Universal Storage parts -All KSAEA parts now have compatability patches for Deadly Reentry Download v .42 As for what's coming, realchutes and maybe a couple other odds and ends, but the next major update in my sights now is redistributing many of the items currently in Meta-Materials so that the node actually reflects what it is. I don't like nanolathing, but that's going to become the new 'ultimate' construction node as it were, instead of Meta-materials being that and actual plausible meta-material parts like it is now. This'll mean moving several parts that already have established positions again, but I've never been happy with the way that part of the tree has shaken out so it needs to be done. At the moment that's kind of my last major area of unease with the tree, after which I might feel more comfortable in the permanence of things to start looking at a parts pack or two. When the changes to Meta-Materials come about I'll also have a chance to make any other minor shifts I feel are necessary like moving another small tank or two towards the start of the tree. I'm also looking at doing some sort of balancing run on the various intake parts if anyone has any input on the matter. Hey there, thanks for noticing and for Science revisited! Glad you like what I've built off it. I'd been running with a customized version of your configs for awhile that eventually evolved into the basis for what's here now.

Yeah, I kind of was trying to figure out what your plan going forward was. I think I get where you're coming from now. Thanks for the clarification

So if I understand correctly, you're intending to indeed get rid of those @maxTemp changes for non heatshielded parts then, yes? And then all changing of maxTemp for non heathshielded parts will be handled by the automated checker in the .dll? Sorry, I just feel like we might be slightly miscommunicating to each other on both sides here and want to make sure.

This is all with the 6.3.1 Beta build, but yeah, the part about ignoring parts with the heathshield module for the auto maxTemp reduction makes everything make sense now. That said I think the last part of my previous post still stands, would it be better to remove all the @maxTemp stuff from the configs, minus those relating to heatshielded parts? I would think, though I could certainly be wrong, most people have created parts with maxTemp values comparable to those in stock. With that in mind shouldn't the values for maxTempScale and ridiculousMaxTemp be designed to produce desired reduction results when applied to stock value ranges instead of being designed with values that have already been reduced once?

Ah, I didn't realize there was any sort of auto-detection for modifying maxTemp. Just to make sure I understand correctly then, any part with a temperature above ridiculousMaxTemp is having its maxTemp multiplied by .5, that's then being checked against ridiculousMaxTemp and whichever number is lower is applied to the part's maxTemp, correct? And this is being done by DeadlyReentry.dll? I'm confused about when exactly this is happening. As I continue to look at this now knowing that there's this auto checking for MaxTemp I'm finding inconsistencies. The Mk2 Series cockpits and parts all seem to be using the values provided by SPP.cfg, which are higher than 1250. However, my own configs for my part rescales which are above the threshold are hit with the .5 multiplier. In another example, the Mk1 series cockpits have maxTemp values above the threshold corresponding to those in DeadlyReentry.cfg. However, the maxTemp of the Mk1-2 Command pod, which is modified just a few lines earlier in the same config file, is hit by the multiplier. Is there some wonky, unintended behavior going on here that needs to be fixed or am I not understanding correctly? Should all the @maxTemp changes be removed and all of that handled by the auto checking for more consistency, possibly with a different value for ridiculousMaxTemp if the current temps above the threshold are intentional?

Hi, I was curious if I'm missing something or are there no configs for the NASAMission parts? I've been using Deadly Reentry for awhile but hadn't really noticed until I went to do DR compatibility for some part rescales.

Well that was really dumb. Put out .41 without actually redoing any of the science stuff for DMagic Orbital Science, just the tech tree changes. So I've quickly worked up the science config and everything seems to be all good. Even though this doesn't move the DMagic US parts around yet, the config should target those for the science changes as well, including those using stock science experiments. DMagic uses a custom module for the science experiments so I've only targeted that, if any one runs into issues because they use a mod that uses the DMagic experiments with the stock module let me know. As far as I know this doesn't exist, but I can easily remedy the situation if I'm wrong and it's necessary. v .41a -Science Rebalance for DMagic Orbital Science Download v .41a If you already downloaded .41 you can just extract the DMagicOrbitalScienceScienceRebalance.cfg to Mod Configs if you want, or install like normal.

EDIT: I totally forgot to actually change science values for the experiments in DMagic, just did the tech tree stuff, so I'm remedying that at the moment and will have a .41a up with that included shortly. Hey folks, got some time in to add support for a few more mods as well as a preliminary run through rebalancing SAS. All stock parts with SAS have been reduced to 25% of their original values across the board to start and some command pods and SAS modules have had values individually tweaked from there. The base reduction is also controlled by a global variable in KSAEAVars.cfg for easy tweaking. Definitely curious for some feedback on this SAS stuff as this was just a pretty quick and dirty run through to get everything powered way down. No modifications have been made to electric charge consumption or anything like that at this time, just torque values. I've also removed SAS entirely from the initial plane cockpits and the cupola. A quick note also about the DMagic config, if you're using Universal Storage I've not yet done compatibility for those parts. When Universal Storage is integrated those parts will be adjusted as well. Planning on getting all the mods compatible with US integrated first and then I'll do a config for US and those mod's US parts. This should be relatively easy since the only mods left after this update are other LS mods and I already have a framework for where to put that stuff that I expect to stay fairly stable. v .41 -Tech Tree Rebalancing for DMagic Orbital Science -Tech Tree Rebalancing for Kerbal Attachment System -SAS has been rebalanced -Mk1 Cockpit, Mk1 Inline Cockpit, and PPD-12 Cupola Module have had SAS removed Download v .41 As always, I recommend deleting the previous version of KSAEA before installing any update.

First off, thanks again to everyone who's been downloading and enjoying this and thanks to those providing feedback, it is much appreciated. Sorry I haven't been around since dropping that last release, I'm going to be spending some time today working on adding a new mod config or two and a couple other new things to put out soon. Thank you, glad you enjoy it and also thanks for pointing that out to me. The newest version changed this to be hardcoded values that are different from stock PF in some cases, in retrospect I'm guessing this might not've been friendly to people using size overhauls. If that's the case I can put out a fixed version of the older config for PF. Though I might just roll this back entirely as it seems kind of in contrast with my original ideas looking back on the decision. Interested to hear what people think of this change and if it does indeed cause an issue or if the sizes used are still ok. Things have already continued to grow outside the original scope of this and I don't have any immediate plans for more science experiments. There are lots of mods out there that do add more science experiments that you can put on probes, or whatever else, over time they'll be integrated. D magic orbital science would be at the top of the list probably in that regard. Also, manned atmospheric flight will always be basically first. Caveat here being I want to find a way to put some sort of really bad probe core at the start that you'd never want to use once getting another, but I haven't come up with a way I like to do that yet. If you're referring to the smaller wing parts added by SPP being closer to the beginning, I thought this would help add some more variety without giving anything too overpowered. I'm curious to hear from people if I'm wrong on that. That's awesome and thank you. I'm gonna be working on Dmagic today probably so don't worry about that one if that's something you're still thinking about doing. As for the large parts packs, I've been waiting on those until the progression of the tree feels pretty solid because it would really suck to make a major change to the progression of the stock tree and then have to do it for all the stuff in those major parts packs as well to make them fit. And yeah, I really wish there was another set of nodes as well. I also don't like nanolathing's lack of requirement in the immediately preceding tier, it makes it far less useful of a node in my opinion. There's a couple of the .625m parts at the start now and as I was saying, I want to add a really junky probe core here to go with those. The rest coming at basic rocketry I think makes sense and helps keep the 1.25m parts further up the tree. You shouldn't get any 1.25 m parts until the fourth tier now and I think that's fitting and helps keep early rockets sub-orbital without getting really creative, I hope. Moving another tank or two back to start might not hurt though either.

Also, the easiest solution I see to the firespitter problem is to just make the compatibility config for it a separate download. That way only those actually running full firespitter end up using it, and no one who doesn't know any better gets their stuff messed up.

Alright, sorry folks, a day later than I said, totally my bad. I ended up shuffling things around a bit more than originally anticipated but I feel like things are starting to settle in to a pretty decent spot. A whole bunch of stuff has moved around again to give a bit more room at the start of the tree before you're jetting off to the moon and integrate the new space plane parts. I've also added in some part rescales to help make up for the lack of some smaller parts without forcing any sort of dependencies. One note on the launch clamp included with these rescales, it displays incorrectly the first time when loaded to into the VAB, but will function correctly and displays correctly on all subsequent loads. If anyone knows what's causing this and/or how to fix it, please let me know. v .4 -Added several part rescales -Fixed placement and scale for the Aerodynamic Nose Cone -Revisions to the stock Tech Tree Rebalance -Space Plane Parts Tech Tree Rebalance -Revisions to Deadly Reentry tech tree rebalance -Revisions to Tac Life Support tech tree rebalance -Revisions to Procedural Fairings tech tree rebalance Download v .40 Delete any previous version of KSAEA and I would also recommend starting a new game since so many parts have moved.