rasta013

Oh man you rock! Thanks so much for sparing my severely limited coding brain from trying to dive into this today. I can comfortably fund myself and be content to live in my world of Cisco...

Awweeesommmeee....Thanks Obi! Really appreciate the update for one of my favorite mods!

Well I'm not a coder either or I'd be more than willing to take a look...however Have you taken a look at Kerbal Research and and Development ? This is not exactly the same as PartUpgrade was but offers similar features. It is designed to use excess (or not) science points in career mode to purchase upgrades for various parts. Not all parts are covered but engines is one of them. It's newer and @-MM- is still working on fleshing it out and getting it balanced but it's pretty nice so far and works cleanly. Since you have to use your points it's not the automagical upgrades of PartUpgrade but that does makes it fit more logically with a career game. Hope this helps!

Because of the massive level of changes to several critical pieces that are affected by Unity 5. Specifically, huge changes to the wheel modules and meshes that were going to throw everything he was working on for a loop. Instead, he decided to freeze development and wait to see what was coming rather than put in many hours only to have to redo everything. Side note Alex, great work on everything you do and just knowing that you're working on updating your mods to 1.1 leaves me with a nice warm, fuzzy feeling.

@Carbonjvd Great work as always and thanks so much for the 1.1 update!

So glad to hear it and read all the tasty updates and plans you've got coming for us. Great work as always and really looking forward to your latest release! As a side note, looking at the Dark Side and Solar SOI windows I personally can't see any reason not to integrate them since the Solar SOI looks to be duplicated buttons with nothing more than selected body information provided that could be listed in a combined window.

Not to my knowledge unfortunately. If there is, I'd sure love to know about it also since we're waiting for updates on this, ScienceAlert and ActionGroupsExtended too...

All kinds of things can happen depending on which switcher actually altered the tank and the cfg/MM code used to implement the switch. The more complex the switch, the stranger and crazier the behavior. Near Future's implemented B9PartSwitch is a perfect example of this issue. Being both highly complicated and extremely hard coded on numerous values any affected tanks are thoroughly discombobulated As to the other question - it only happens if you choose to upgrade a switchable tank. So long as you choose not to upgrade a tank KRnD can be used side by side with any tank switcher. Furthermore, if a tank is not affected by a switcher (happens frequently on many cfgs for monoprop tanks) those can be upgraded by KRnD with no issue that I've seen. One caveat here is related to multi-function parts. In some cases parts may have tanks built into them along with other functionality. The above applies equally to these parts also. If it has been affected by a tank switcher, it cannot be upgraded with KRnD without weirdness galore but if has not, it doesn't seem to have a problem that I've uncovered as of yet. Will keep watching and report back if I see any other weirdness as I'm now running 190+ mods and have a wide breadth of potential problems available to see...

+1 Indeed!! Thanks to both @TriggerAu and @Fishbreath both for the work to get this up to date. An absolute must have for any reasonable long-term player.

A couple of things for you...foremost, be aware that Taranis Elsu is no longer updating TACLS but has said there is interest from someone in picking it up and continuing it forward since it is so well liked in the community. Unfortunately this means there is no telling how long we may be waiting to get TACLS for 1.1. A suggestion would be to at least give the USI-LS option a try. It makes integration extremely seamless and easy with all of Angel's mods, KPBS and of course the USI suite. Personally, up til now, I've preferred TACLS also, but I'm currently using USI-LS because unlike TACLS, RoverDude has started incorporating other life support features - namely habitation and long term effects of living in cramped quarters. He is also experimenting with having to deal with radiation exposure as a potential feature making the suite a little more rigorous than just supplies. Just a thought... As for your questions about base locations...I can't recall setting up a Mun base that was close to the capabilities of a Minmus location primarily due to resource concentrations. They tend to be more tightly packed due to its smaller size making coordination between multiple sites easier. Furthermore, the far lower gravity makes transporting resources to a main facility simple thru short distance sub-orbital hops. Last but not least, building a launch site on Minmus (via EPL) for interplanetary journeys means a huge savings on fuel costs, again because of the gravity differences. Just my 2 cents and I hope it helps. Good luck!

Yup. CKAN was the culprit for me. Came back to it later and looked around before stripping it out and reloading and noticed that all was fine, all was well...except that CKAN just dropped the Pathfinder folder directly into GameData instead of the WildBlue folder. The AVC file definitely solved that little nag issue too. As a side note, after seeing the CKAN goof up I pulled it out and tested it again - 3 more times actually - and all 3 times CKAN got it right and put it in the correct location for me. May have been some kind of fluke on the first install...don't know. All is well with the world now that I have your wonderful mod back. Thanks Angel!

Yeah I just tested quite a few different types of switches and found out exactly what -MM- just posted about. Any tank that has a fuel switch on it of any kind is going to...well...act weird at best and not at all at worst. This will hold true for IFS, B9Switched or MFT altered tanks. There's not really going to be any sort of easy fix that I can think of either as what -MM- mentioned, the values under the tank switchers are static, not variable.

Hey Angel...finally got time to start playing with 1.1 this weekend and ran into this today right off the bat when trying out the latest Pathfinder build and couldn't find any parts in the editor... From Output Log Double checked both my Pathfinder and WildBlueTools packages to make sure all are up to date and they are. I can post the additional log info if you need it. For info's sake I'm using the x64 build under Windows 7. I do have a excrements ton of mods loaded and can provide the full list if needs be. Will also perform a stripped down test later today after my Stanley Cup game is finished to make sure it's not something else I've got loaded that might not be playing nice.

Ohhhh...salivating in anticipation. Thanks to lo-fi and everyone else working on Foundries who put in so much work on some of the best ground vehicle parts available. Great work as always...

I'd love to help with coding or modelling...except I'm neither. What I am good at though is testing and as you start rolling out changes for 1.1 I'll be more than happy to dive in and help test this as much as I can. Started playing with this back in 1.0.4 and really enjoyed goofing with it but never ran a long term save. Looking forward to seeing what new minds start adding to this excellent idea...

Ouch. That hurts...my NREs aren't that painful.

That's a pretty good idea actually. Instead of a downgrade path, expanding the functionality to improve your manufacturing capabilities is pretty much just expanding the existing science based functionality into funds based instead. This sounds a lot easier than a downgrade path.

Well at least you caught the joke... I'd disagree that your analogy is any better than mine since you're trying to compare early 20th century tech to early 21st century tech. I was more referring to an idea similar to differences between using cold roll vs. hot roll steel. Regardless, neither of our analogies is very good in relation to the game or the current state of the mod anyway... LOL To be perfectly honest, I wasn't arguing in favor of putting downgrade options into the mod; only that I can see a justification for having pre-upgrade technology available in some limited cases. But, by and large I agree there isn't a reason to do so for the simple reason there are plenty of workarounds as to generally make it a non-issue. The sole reason I would actually want a downgrade path would be if the price/cost of the items get affected because that's something that is far more difficult to engineer around. In that case, having the option of reducing costs by using older tech becomes a trade off decision between the better performance/design or better economics.

Agreed. With 1.1 out, 64 bit in play, and so many mods that have been dropped it would be really nice to be able to see all the errors popping up to isolate the problem children and test potentially abandoned mods with a possible eye on being to get some of them up to date.

Here's the original file packaging for version 1.5.1 from 6/30/15 of last year. I have not tested this but just glancing over the recent changes nothing jumps out at me that may cause a problem. Also, I haven't made changes to anything including the MM file within so if you find problems, please post it so Freedom can see it if/when he comes back. https://www.dropbox.com/s/x1ouhzs1r6p22bl/FreedomTex.zip?dl=0

Right now, the upgrades actually change the base item permanently. Once upgraded you no longer have the older part available and there is no downgrade path. With the state of the mod currently regarding what items can be upgraded this is not really a big deal. All the things being affected have no real reason to get downgraded later since previous iterations would be worse in every way offering no real advantage to using the older version. I was just making the point that if you get into doing R&D/Upgrading of items like fuel tanks where the intrinsic nature of the upgrade is going to change an important stat like mass then either a downgrade path or previous version should be considered in some way provided it doesn't take a year's worth of coding. The main reason I could see for not offering copies (which I think would be fairly easy) of the existing part after upgrading would be memory constraints. It wouldn't affect those of us running Linux/64-bit but could easily play havoc with anyone running 32-bit especially if you upgrade the same item multiple times and end up with 3, 4, 5+ copies of the same item. It also would make the editor screen annoying trying to determine which one is which since in all likelihood they would look the same no matter which iteration it is. Just my 2 cents...

Well I guess that's why I downgraded the Windows 10 install I tested to Windows 7 because no one ever wants to go backwards to "outdated" technology... Point being is that sometimes your R&D decision that seemed really good to begin with turns out not to be a wise idea. I would agree that given the current parts being modified there's no real reason to want to downgrade parts. However, if you get into tank upgrading that makes the entire picture change. Sure, I might want that SBOT to have a greater fuel capacity at this time...even the next 5 missions. But all of a sudden I'm starting a new mission that is going to require a tank setup that would greatly benefit from the pre-upgraded SBOT because the mass increase from the greater fuel capacity is just not going to work nor have I researched enough to have a suitable replacement. In this case, you would want to have access to the old tank and if there's no way to get it back then you are screwed. I'll admit this is a bit of a stretch because I think many of us (not all) play with part mods and would have viable tank alternatives in this scenario, but this is an example that instantly popped in my head when I started thinking about downgrade possibilities. Sometimes you just want to have that old part available to use because it is a better solution or you simply need it. All this said, I would say that you would need to penalize the player for having to downgrade. Call it a reconditioning cost to bring out the mothballed tech but to say there's never a reason to downgrade is not entirely accurate. If the downgrade scenario is WAY too difficult to code though - forget it - you've got a great mod going here and that piece of missing functionality does not detract from you've built. One other note...if you ever consider changing costs due to upgrades then the downgrade scenario becomes almost necessary if you even think about using this in the early game...

That would explain it right there actually - I'm running Ship Manifest also. Will patiently await the update and give it another whirl!

Outstanding, can't wait to see what you put together since it would really be nice to have numerous choices for RCS pieces. A few of the mods I can remember that have RCS with non-stock curves: Bahamuto Dyanamics Parts Pack Modular Rocket Systems Ven's Stock Revamp (1 or 2 of them iirc) and I think NovaPunch also has a few but not sure about this one Hope those help out some...

Great to see this mod maintained and updated so nicely, wonderful job! I haven't been using it until now but started a new sandbox game for doing some OPM interplanetary stuff and figured I'd use Deep Freeze instead carrying 24651424 years of life support. Ran into a problem though. On the first test ship I ran with a CRY-1300 freezer and while attempting to freeze a kerbal it repeatedly spooled through all 3000 EC and the Glykerol resource until it was all used up, never froze the kerbal and spammed the log with this every time the freezing process reset: NullReferenceException at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject () at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0 at UnityEngine.Component.GetComponentsInChildren[Renderer] (Boolean includeInactive) [0x00000] in <filename unknown>:0 at DF.Utilities.setFrznKerbalLayer (.ProtoCrewMember kerbal, Boolean setVisible, Boolean bodyOnly) [0x00000] in <filename unknown>:0 at DF.DeepFreezer.FreezeKerbalConfirm (.ProtoCrewMember CrewMember) [0x00000] in <filename unknown>:0 at DF.DeepFreezer.FixedUpdate () [0x00000] in <filename unknown>:0 I do run an EXTREMELY heavily modded game and I am running TACLS but have pulled down your .dll fix and was running that. I don't know if there is some conflict arising with one of the many mods I have or what but figured I'd drop this in here for you. Just for info's sake, I tried each one of the freezers after getting this initial error and it repeated for all parts. None of them are working for me at all. If you'd like to see log files I've got them saved and can get them to you if needed.