Pirsig

May 21, 2015

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.

January 10, 2015

Hmm. That is odd, then, because without those two changes I can't get contracts to work using only the "start" tech node.
With a fresh install, unmodded aside from KSAEA, I determined that the test and survey contracts are most likely dependent on the RT-10 booster. They won't show up until Advanced Rocketry is researched and the booster is unlocked (provided a rocket had already been launched, of course). Moving RT-10 back to the start node allows the contracts to show up immediately after the first launch. There is definitely a tech dependency there, it's just not listed in contracts.cfg. Probably a default value in the C# game object.
I can assure you that the code is not useless: it allows contracts to appear in T0 without changing the tech tree from the KSAEA default. Neither contract type will show up on any of my clean tier-0 saves without those prefixes. Maybe modulemanager operates on the game objects and not the raw cfg's?

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.

Interstellar Flight Inc. Life Support doesn't appear to handle having life support removed from the cockpits. Pretty much instant death.
spink

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.

January 9, 2015

I can confirm. Test contracts came online in a clean install by adding this to the contract fix and launching a brave probe straight into the ocean:
    @Test
    {
        @Tech = Mark1Cockpit
    }
By the way, I think the "Tech = " line in the original contract fix also needs the @ in front of it.

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.

Gotcha. I'm pretty new to ModuleManager and had trouble finding documentation on the ":FINAL" function. I searched the modulemanager thread and read the github wiki, is there another good place to look?
Ok, that makes sense. I didn't want to fiddle with your included configs when making my own.

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...

I was thinking that there's not much point in putting a nose cone and nose cone-ish cockpit in the starting node because they only fit with 1.25m parts, and the front of 1.25m things would be the 1.25m radial engine, but now that I rethink it, one could make a P-38 Lightning-style airplane with the nose cone or mk1 cockpit. I was also hoping that there might be some kind of tech progression in the inside of the cockpit as well as the outside. But again, on rethinking it, maybe later we might get a cockpit that only works in atmosphere separate from or needing an upgrade to function as an orbital cockpit (which might have better IVA instruments, for example), but that functionality doesn't exist within current versions of KSP. You're right, they should go back into start.

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.

January 9, 2015

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.

January 8, 2015

Pirsig, it looks like Firespitter isn't going to be updated anytime soon, so I'm going to shift my focus to the Kerbal Aircraft Expansion (KAX) mod. KAX is much like Firespitter, but is more stockalike and built to be used with the standard Mk1 and 2.5m fuselage. This means the parts are more versatile and not limited to being used with Firespitter, and that part redundancy is reduced. I already know where I want to place the parts, as I had intended to include them with my Firespitter config. I think this will make propeller aircraft simpler and a lot more fun.
My only regret is that it won't have the gorgeous F-86 parts that snjo made.
Also, I seem to have no trouble with the part test contracts, but I'm running a pretty heavily modded install.

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 for this! It's exactly what I've been looking for. Got a question/problem. I'm been unable to complete altitude contracts using the SKGU probe core. Is this by design or do I have something wrong? I've tried from a clean install with the same results.
thanks
spink

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.

January 6, 2015

Yep. With galen's suggestion (thanks galen!) I was able to use Elevon 6's as pretty reasonable ailerons. And the difference I thought I saw in the Elevon 4's was from actually the reduced lift on the structural wings, before I noticed they were also bugged -- my plane was still having trouble getting off the runway. Everything is flying just fine now!
On another note:
I love the tech progression early on! I just wish I had enough cash to use it!
Playing on hard mode, I find myself high on science, but low on pretty much everything else. Using my starting craft alone, I find I can easily research tech level three before paying so much as a single startup cost. And that's without spamming research in the KSC biomes. Perhaps the science multiplier for Kerbin should be decreased a little more?

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.

Also, part test contracts are suspiciously absent; are they tied to the original start capsule? If they could be brought back in, and perhaps added to the new .65m parts, I bet the early game would be more like the starting days of the NACA: develop and test new and more effective planes and rockets for atmospheric use.
A few more thoughts:
- If part test contracts can be brought back, can they be limited to only have sub 22000m altitudes until you have demonstrated upper atmospheric capabilities?
- Can the 33000m+ height record contracts be changed to accept unmanned craft? Probes should realistically be the first things to reach that altitude, but doing so (I think) will invalidate the contract, and the reward.
- Can action groups be added to the level one hangar/VAB? Landing planes without flaps or spoilers is a pain and a half.
- Can lateral speed contracts be added? It would be cool to have to research your way up to mach speeds and build your own X-1.

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.

January 6, 2015

I installed this mod last night; I've been looking for a good tech tree rebalance since I got kerbal, especially one that plays nice with other mods. I really like the arrangement of the tech tree in this one!
Looking at theonegalen's comment from earlier, I decided to start my progression with planes only. Unfortunately, it looks like both of the starting elevons are bugged with regards to FAR:
- Elevon 4 does not do any controlling at all. The surface moves, but the physics model doesn't look like it registers the deflection.
- Elevon 6 still uses the default physics model, so FAR freaks out.
Poking around in the configuration files, it looks like there may be a typo in tinyCtrlSrf.cfg
//Changes for FAR, this is just a copy of the Elevon 4 config with values reduced the same % as size
@PART[[B]smallCtrlSrf[/B]]:NEEDS[FerramAerospaceResearch|NEAR]:Final
Was the part name supposed to be tinyCtrlSrf instead?
After a clean install with the swapped name Elevon 4 works, though it still feels a little weaker than with default FAR. I can't tell if Elevon 6 works because it is so weak.
EDIT:
Found the same sort of typo in the FAR compatibility for structuralWing5.cfg, as well.
Things are going pretty well starting out the campaign mode with a basic jet!

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.

January 3, 2015

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

January 2, 2015

Edit: I noticed I was only getting "check temperature" survey contracts instead of the visual survey contracts with KSAEA, so I added a line to the contracts.cfg in Gamedata/Squad/Contracts under those kinds of surveys (EVA, Visual, Suface Sample) saying "Tech = Mark1Cockpit" and now they show up again. I'm not hugely familiar with modulemanager, but I don't think it supports changing that sort of cfg, does it?

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.

December 31, 2014

Playing 0.43 on 0.90.0 now to see how everything works together.

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.

December 27, 2014

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.

December 22, 2014

I'm really wondering if this mod will work / update? I loved the tree!

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.

Haven't tried it in 0.90 yet, but my playthrough of the stock career mode has me more convinced than ever that we need to start with aircraft. Aircraft are essential to getting to completing the early Kerbin survey contracts added with Fine Print stock integration, which are invaluable to getting through the grindy first levels of the tech tree. And with aircraft, the "Set a new altitude record" contracts really have more meaning, as you can have a sense of progression as you refine your initial aircraft design. So I'll design my firespitter integration to KSAEA with that in mind.
My two cents.
EDIT: Also, Ven's Stock Revamp is now modulemanager based and has it's own folder in gamedata (instead of replacing things in the stock Squad folder), which is going to change it's integration with Firespitter and Advanced Jet Engine too. Exciting.

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.

December 12, 2014

Nice, just last night I was grumbling over having invented jet engines but not wheels... Reckon this mod might be just what I need to solve that, and I like the other changes you've added in too - solar panels extend-once thing is pretty interesting, and it'll be nice to have a purpose for the science lab. Thanks for the hard work
One question though; what's the general plan for craft control, given the reduction in SAS strength?

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.

You might be interested in this stuff: http://forum.kerbalspaceprogram.com/threads/102502-0-25-Sounding-Rockets%21-Start-small-Dream-big%21-0-0-1-2014-12-09

That is definitely cool and I've already downloaded it it to take a look at. Thanks for pointing this mod out to me.

December 8, 2014

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.

December 8, 2014

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.

Just noticed you based some of this mod on my concepts. Glad someone liked my ideas. Cool mod!

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.

November 24, 2014

If you're asking for a specific course of action, I haven't decided yet and am not going to commit to one other than to say that I will be going through the entire list of parts in those files and deciding if any need specific handling, which is why they are in that file in the first place.
Each part on a case by case basis. If any need further adjusting then they'll be adjusted instead of being removed. There's a lot of parts in there and I'm not going to blanket delete them from the file.

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

November 24, 2014

The ridiculousMaxTemp cap was set with what I thought was a good max cap that nothing should go above. It's a subject that's come up before with the previous cap as having been judged to be too high. But the intent wasn't to set that capbased on parts that were being adjusted elsewhere. Those parts were just caught in the crossfire and that will be dealt with.

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.

November 24, 2014

...Actually, 1250 is from the beta. I cut the value for ridiculousMaxTemp in half. The latest official is 2500 so 1700 (for the Mk1-2 and others) is well below the cap. So, if you're looking at the latest official then those numbers are ok. The beta numbers are still subject to change so the maxTemp adjustments will come down to something suitable. Unless I raise the cap back up.
In addition to that however is that (oops sorry, I left this out of my explanation) heat shield parts are exempt and that includes the SPP parts and most other plane related parts. In fact, those have to be fairly high because their heat shield configurations are reflective only and lack ablative shielding. Typically those parts will reflect 10% to 25% of all incoming heat which is sufficient for stock Kerbin. (RSS... not so much)

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?

November 24, 2014

No, there's not, but it's not really an issue for most of those parts. The reasons for having configs on any of them are:
to add a heat shield
Adjust the maxTemp to something sane (since most parts have maxTemp values that are way too high)
There are no parts that require a heat shield in the NASAMission parts (with the possible exception that maybe the LES part could use a weak 0.05 - 0.10 passive reflective shield) and there's code in the plugin that will check for insanely high maxTemp values and set them to the lower of half of maxTemp or ridiculousMaxTemp which is defined in the DeadlyReentry.cfg file (which, I think I didn't document this but I cut that in half from 2500 to 1250)
In fact most parts out there for most mods have no DRE configs either but will do just fine without them.

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?

November 23, 2014

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.

November 20, 2014

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.

November 20, 2014

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.

November 16, 2014

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.

I'm enjoying this a good deal on 6.4x.
A note on your variable use in PF: unless you've fixed it by now, it's got a serious problem. You're using ../ syntax when you're already inside the nodes. it should be *just* foo = #$othernode$ not PROCWHATEVER/othernode.

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.

This is really something I always looked for! I know RO Tech Tree has it but since its all outdated and such I can't play with it. I for sure will look into this topic daily. I really want it to succeed, I might try it out soon as well but I would love to see more mods compatible with this. as someone wrote before as well probes should be way before manned flights, more probe sciences should be made! There really should be more use of probes and Realistic Progression LITE does that well.
I would love to see that in this mod. Give probes more means to the game!

So are there any plans for more use of probes/making probes be useful and actually do science and be way before manned missions? with that perhaps BoxSat mod would work nice too.

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.

EDIT: Just checked out the mod, I have a question. Shouldn't the plane parts be unlocked later beside be given in the start for the player?

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.

Did a lot of work on the Firespitter tree last night. Interestingly enough, Pirsig, starting the KSAEA tree with propeller planes means that most of the aircraft parts you moved are getting moved back to their original node.
Started planning for other mods as well, station science, Dmagic, KW, B9, AJE, etc. Not sure how KW will fit in with the current KSAEA progression, which I very much like. I wish there was one more tier of nodes after the Experimental ones. Perhaps high buy-in costs will balance everything out.

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.

Have you considered moving the 0.625m parts to the start, and the 1.25ms to the early Rocketry nodes?

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.

November 4, 2014

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.

November 4, 2014

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.

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by Pirsig