yongedevil

I can give you the diagram use when creating the tree. It has information on all the tech nodes. The format is: tech id [* indicates a stock tech id] icon name [this is not up to date since I added custom icons] tech title (cost) list of parts Dashed outlined square are just extensions of the tech when all the parts wouldn't fit. Red outlined techs are hidden if empty. Red part names are mod parts.

The tree has been updated to v1.1. This adds in support for the Asteroid Day Mod. One new node has been added, Long Range Communication, between Electronics and Deep Space Communication. I also converted most of the textures to .dds This means you will need at least v1.3 of the Tech Trees Plugin. This won't break anyone's save, but it will mean anyone who has researched Deep Space Communication will lose the Communotron 88-88 until they research Long Range Communication. Deep Space Communication will also be hidden if you do not have the Asteroid Day Mod (no stock parts are in it any more) MK3424, thank you for passing that on. That is very cool. As for the kerbals, of course I don't want to kill them. Well not all of them, Joemore knows what he did. The tree is supposed to start with a new part, the CONE probe core, to avoid pointless deaths until the discovery of parachutes. The Mk1 Pod is should be in the Command Pods tech, which requires Recovery first. Here is the CONE core, it might be mistaken for the Mk1 Pod in thumbnails. The other possibility is there is something broken with the Tech Trees Plugin. In which case any additional information on what is appearing broken would be most helpful. With the solar panels, I don't think there's a reason to worry about difficulty. The static solar panels are actually at about the same level as stock (141 total science vs 155 for stock), so the real change is the fuel cell is available significantly earlier. I will admit I don't use the fuel cell, so I don't really know if having them there fits with how people do use them. So feedback is always welcome.

That certainly qualifies a simple solution. I've done some experiments to see how nodes can be moved around and it looks like it might not be possible to do so without editing the file. Having the game edit the .cfg files is not the best practice. Another option is a separate program to do the coordinate conversions, which honestly isn't really worth the effort for such a simple task. However, it wouldn't take much effort to add such a feature to the Converter. It wouldn't be the most user friendly solution but the plugin already exists to assist in creating TechTrees. Would that still be useful enough to be of interest? You would have to launch Kerbal to generate the output file with the converted positions before releasing the tech tree.

First, a updated to v1.3. This adds support for .dds icon textures. Second, the Tech Tree Converter is working. This will fill out the Unlocks node for any installed tech trees by adding all parts that: Have a TechRequired of that node. Are not listed in another tech node's Unlock section. The output is written to files inside the ConvertedTrees directory. To use install the tech tree you wish to convert and start Kerbal. The Tech Trees Plugin does not have to be installed for this. Once the main menu loads you can quit and look inside ConvertedTrees for the output. Find the tree you were trying to convert, sorry about not giving them meaningful names. You will have to add the "title" and "description" fields and renamed the file to .cfg. This is obviously limited to converting one tree at a time, and it is not the fastest process in the world. I suggest removing the plugin when done with it, or at least setting the "enable" field in the config.xml file to 0.

I'm sorry, but I think it is too complex a problem for me. However, if anyone knows of any simple solutions I can take a look at it. That seams like a very good idea and it got me thinking that it would be handy to have the game print out a list of parts attached to a tech node, which led to the realization that it should be quite simple to just have the game print out a complete TechTree node and fill in the Unlocks node with parts automatically. Basically it could convert from the Stock or a ModuleManager tree into a YongeTech tree. If this is as easy as I think it is I will have something rudimentary tomorrow (out tonight, holiday). And apologies to you Wolf Baginski since it sounds like you've done a lot of this work already.

As far as I know the update added the following parts. Two static unmovable radiator panels: radPanelSm "Radiator Panel (small)" in the survivability tech node radPanelLg "Radiator Panel (large)" in the basic science tech node Three folding radiator panels: foldingRadSmall "Thermal Control System (small)" in the electrics tech node foldingRadMed "Thermal Control System (medium)" in the advanced electrics tech node foldingRadLarge "Thermal Control System (large)" in the large electrics tech node

UPDATE: MK3424 was very helpful in tracking down this issue and v1.2.1 of Tech Trees Plugin fixes the larger problem of the tree not loading. The issue remains that mod tracking parts by their name, and when your Kerbal install has multiple parts with the same name it can't differentiate them, but at least it doesn't crash now. MK3424, can you open your save file (saves/<save name>/persistent.sfs) and do a text search for “TechTreeUrlâ€Â. There should be two results, in CAREER and SCENARIO nodes. They should look somethign like this: CAREER { TechTreeUrl = GameData/YongeTech_GreatBigSkyTree/Resources/TechTree.cfg StartingFunds = 25000 StartingScience = 0 StartingReputation = 0 FundsGainMultiplier = 1 RepGainMultiplier = 1 ScienceGainMultiplier = 1 FundsLossMultiplier = 1 RepLossMultiplier = 1 } SCENARIO { name = YT_TechTreesScenario scene = 5 treeSelected = True TechTreeUrl = GameData/YongeTech_GreatBigSkyTree/Resources/TechTree.cfg } Please let me know what the value of TechTreeUrl is in both nodes.

YongeTech: Great Big Sky Tech Tree version: 1.1 last tested with Kerbal v1.0.4 Kerbal Stuff Link Requires: YongeTech Tech Trees Plugin About the Tech Tree The goal for this tech tree is to group similar parts together and remove dependencies on unrelated parts. To that end the tree is much wider than the stock tree, but total cost are a little bit less. This tech tree starts with uncrewed solid rockets without steering, landing, or recovery capability. The first 5 tech nodes provide choices on how to control and recover science from the rocket, and are cheap enough to unlock several just from a temperature reading on the launch pad. Installation Copy the contents of GameData into the Kerbal GameData folder. Requirements This mod requires the YongeTech Tech Trees Plugin. Previous Versions If replacing a version before 1.0 you will have to remove the old version manually. Versions from 1.0 and latter will not overwrite versions pre 1.0. v1.1 Changed name of added Procedural Fairings unlock parts to include YT_ prefix Converted most textures to .dds Added support for the Asteroid Day Mod Created new impCommmunication tech between electronics and advCommunication Set advCommunication to be hidden if empty Moved commDish from advCommunication to impCommunication Added HighGainAntenna to advCommunication Added LgRadialSolarPanel to solar Added HECS2_ProbeCore to advUnmanned Licence Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Updated to v1.2 with an arrow for the dropdown button. Thank you Wolf Baginski. Also made sure the stock tree will always be first in the list. EDIT (2015-06-24): Updated to v1.2.1 to fix and error where the plugin crashed if given two parts with the same name. It still won't handle the parts correctly, but it won't crash.

I made a small update to the mod (v1.1) to fix undoing other mod's changes to the TechRequired field. This was causing a problem with the unlocks for additional features in MechJeb. I don't have much else planned for this mod now, but I have a short list of features that should be possible. I can look at adding the following if there is demand for them: Option to link a texture to the tech tree for the selection window. This would give the player a visual cue to remember each tree. This could be a small logo, or a link to open a larger image such as a preview of the tech tree. Option to move all parts that are, by default, unlocked by one tech to another. This would allow creating tech trees without worrying about mod parts getting lost in the missing techs. Tech tree debug tools. This would be an option to enable debug messages for a tech tree and could check for some problems such as: Missing default tech nodes, which can cause parts added to those node by mods to not show up unless the parts are specifically reassigned. Parts whose TechRequired doesn’t exist in the tree. Basically the above problem but only checks installed parts. Unknown part values in the Unlocks. These can be legitimate if you add support for mod parts not currently installed, but they could also be typos. Duplicate part values in the Unlocks. And I am sorry I wasn't able to get the mod out sooner. I put this aside due to the ModuleManager conflict for about a month (28 days according to commit logs) because it seamed it might be a dead end. Normally I don't have a problem with being incompatible with another mod that does the same thing (both this mod and ModuleManager edit the TechTree for saved games), but ModuleManager dose too many other very useful things to ask people to uninstall for this mod. In the end though, the workaround was one of those simple solutions that make you feel like an idiot for not seeing sooner.

I would guess the log writing is the cause of your performance issues. File I/O is very expensive and it looks like something is writing to the log several times a second. The Parsing messages are what the game prints when reading from a plugin configuration file; although I don't know if that is the only case where it print those. My guess would be some mod is repeatedly fetching data from the file rather than storing it in memory.

Yes, the main intent for the mod is to avoid having to setup edits for each individual PART node. As an added benefit though, with the part unlocks stored in with the TechTree it is easy to have multiple trees installed and pick one to be active.

YongeTech Tech Trees Plugin version: 1.3 last tested with Kerbal v1.0.4 Kerbal Stuff Link Source on GitHub About the Mod The Tech Trees Plugin provides support to make creating and using custom tech trees easier. Allows part unlocks to be listed in the TechTree ConfigNode rather than having to edit every Part ConfigNode. Adds support for using custom textures to create icons for the tech tree. Adds a tree selection window to let the player select a tree for each new game. Installation Copy the contents of GameData into the Kerbal GameData folder. Known Issues This mod tracks parts by their name field. This means it does not work properly when multiple parts have the same name. Both this mod and ModuleManager (on version 2.6.5 as of this writing) attempt to edit the tech tree of the current game. This mod's changes should have priority. If you would like to disable the option to select a tech tree and the conflict with ModuleManager change the "allowTreeSelection" field in PluginData/YongeTech_TechTreesExpansion/config.xml from '1' to '0'. This will keep support for the TechTree ConfigNode additions and custom icon support, but remove the option to select a tech tree. Tech Trees YongeTech: Great Big Sky – Wide and shallow tech tree. Feel free to use as an example on how to setup a tech tree with this mod. Using a Tech Tree When starting a new Science or Career game a window will appear asking you to select a tech tree to use. Pick a tree from the drop-down list and below it will show the description and some stats for that tree. Total Cost and Total Nodes are the total cost to researcher all nodes on the tree and the total number of nodes in the tree. These numbers exclude hidden nodes. The tiers for the nodes are those nodes that can be researched at that tier of the Research and Development facility. Creating a Tech Tree Create a new TechTree ConfigNode and place in your mod. This mod will locate and add any TechTree ConfigNodes to the list automatically. The TechTree should be setup like normal with some additions shown in the code below: TechTree { title = Sample TechTree description = An incomplete TechTree showing the basic setup unlockAllStartParts = True RDNode { ... Unlocks { part = solidBooster_sm part = probeStackAdapter part = standardNoseCone part = sensorThermometer part = basicFin } } ... } TechTree ConfigNode: title: The name of the tree. Displayed in the tech tree selection window when starting a new game. (approximately a 45 character limit) description - Single paragraph description of the tree for the player. Displayed in the tech tree selection window when starting a new game. (approximately a 400 character limit) unlockAllStartParts: (optional) If set to True the mod will unlock all parts attached to the starting node(s), that is all RDNodes with an entryCost of 0. This is only relevant if No Entry Purchase Required on Research is disabled in difficulty settings. Unlocks ConfigNode: part: name of a part to unlock with the parent RDNode. Custom Icon Textures The mod will create icons for use in a tech tree from any png or tga files it finds in folders named “RDSimpleIconsâ€Â. The icons will have the same name as the image file, without the extension. .../RDSimpleIcons/customIcon_tech.png will become "icon = customIcon_tech" Tech Tree Converter The YongeTech Tech Tree Converter helps convert existing tech trees by filling in the Unlocks nodes for all techs. It will add all parts that: Have a TechRequired of that node. Are not listed in another tech node's Unlock section. It writes the filled out TechTree to a txt file in the mod's directory. It performs this conversion for all TechTrees installed, and it also dose not name the output files in any meaningful way. It is necessary to inspect the output files to locate the correct tree and then add the title and description fields to it. Licence Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Why not guide the students towards good rocket designs and flight planning by having them run some experiments? Students could experiment with single stage rockets with different liftoff thrust to weight ratios and see which ones lift the rocket the highest or deliver the most mass to orbit if pilot variance can be dealt with. Others could experiment with multiple staging. Experiments can be done both on the number of stages and on comparing parallel, sequential, and asparagus staging. This offers the students opportunity to use the rocket equation and learn why delta-v changes with each configuration. They can also do calculations to compare with experiments (if the rockets can be tested free of gravity and drag which would confuse the calculations). Another experiment could compare accent profiles. Have students compare making more or less aggressive gravity turns. This would depend a lot on piloting ability so maybe only try it if some students have played KSP before and think they can do so. Alternatively mechjeb could be used. Afterwards the data from all groups can be presented to the whole class and the students then challenged to put the results to use designing their own rockets. Have the top performing rockets’ designers explain how they used what they learned from the experiments to design their rockets. KSP would be great to reinforce what students have learnt about energy too. The orbital velocity and energy level of different circular orbits should be simple for the students to calculate, but the Oberth effect isn’t so obvious. Have the students try different orbital transfers including a direct Hohmann transfer, a multi-stage Hohmann transfer with intermediate circular orbits, and a bi-elliptic transfer. Maybe some of them will be bright enough to catch onto why although the energy difference between orbits is always the same the delta-v requirements are not. After explaining the Oberth, the students can be challenged to figure out and test to confirm when a bi-elliptic transfer becomes more efficient than a Hohmann. There’s also a lot of other interesting related orbital maneuvers including bi-elliptic plane changes, and transferring between two eccentric orbits (compare Hohmann transferes apoapsis to periapsis and periapsis to apoapsis), and changing the longitude of periapsis (compare using a single radial in or out burn to using a pair of prograde/retrograde burns to convert to a temporary circular orbit then back to elliptical, also compare doing so at the apoapsis and periapsis).

I suspect it is due to Squad using a new module, ModuleEnginesFX, on the new parts in place of the old ModuleEngines.

I think it is about time to admit that I don't have the time to keep working on this project right now. For anyone wishing to make use of it I've made the current working version available for download.

soranno, the reason scrubbers are toggleable is the recyclers. If you are using recyclers you don't want the scrubbers on removing all the CO2. I have managed to fix the bug that was causing the scrubbers to turn off, so they'll work again after the next update. I am however tyring to track down another bug that is causing some of the modules to save incorrectly and I can't release the next update until I can solve that. Wish I could give an ETA but I don't really know how long I'll have to work on the mod in the next couple of weeks.

I've had success avoiding the crew death bugs so that will be fixed in the next update. I kind of miss having the static effect, but completely removing the crew so there picture disappears avoids the bugs. Fraz86, at this point you cannot remove a ION_POD_GENERATOR or ION_POD_COLLECTOR. Actually right now I can't modify them because the save/load code isn't working properly, and I'm not sure if these problems are present in dev4 or are something added when I started to try and fix the code. At any rate, when I get things working properly you will be able to modify the module to do nothing, as you did with your code sample, and set all the hide variables to true to clear the clutter. @PART[partname] { MODULE { name = IonModuleCrewSupport ION_POD_GENERATOR { generatorName = CO2Scrubber hideStatus = True hideStatusL2 = True hideEfficency = True hideOutputControls = True hideActivateControls = True } } } effectOnEfficency is how much the output rate is affected when that resource is depleted (or full). If set to 0.6 then when the resource runs out output of the generator will drop to 40%. The input rate will only be affected if effectOnEfficency is 1.

I hadn't realized it before, but that pretty much sums up why I haven't been overly keen on actually implementing food and water requirements as an option. If though as Morden96 suggests, there was a way to separate the resources so they are handled differently it might be worthwhile. At this point what I would really like is a way to collect ice from polar craters where there is no sunlight and to produce food where there is sunlight. This appears to be a bug with Kerbal. All I do is call the crew's Die() functions to kill them, and what should happens is their pictures get replaced by static with “K.I.A.†over top. This only stays until you leave the vessel and then come back when the picture is removed. However, it appears the EVA and IVA buttons still work in this state so the crew can be revived, as you found out. I don't know why you're not seeing the pictures replaced by static. I can't change the game's functions like Die(), so I can't fix the bugs with it and I need to use Die() in order to have the deaths properly recorded in the log. I may be able to work around the bugs to some extent though. Out of curiosity as to why you're not seeing the pictures turn to static, what version of Kerbal are you using, including operating system?

What happens is when you place a manoeuvre node near to your intercept the game switches to show you the intercept information one orbit after your manoeuvre. This makes sense as you're almost always aiming to tweak your intercept on the next orbit when placing a manoeuvre node on top of an your intercept point. There is a bit of a buffer zone ahead of the intercept point on the orbit too, which is why you're seeing the information change in the video without the manoeuvre node being right on top of the intercept point. If you were to move the node back far enough though you would see the information switch back to the current orbit.

Joints in Kerbal are not perfectly rigid and will flex some in flight. For engines placed out from the centre of mass this flexing will usually lead to some asymmetric thrust vectoring resulting in spinning. At least that's the best explanation I have for the phenomenon. I've found the best solution to be to stiffen the rocket so there is less movement and adding controls to counter what is left. 1-2 struts between each booster and the core will usually be enough, with in very bad cases, an extra 1-2 struts linking each booster to its neighbours.

Renaming the folder the mod is in shouldn't have any ill affects. At no point do I reference anything using the folder name.

Right now the logic for draining resources is very simple. So yes the pods will drain first, and no that doesn't make the most sense. However, it shouldn't be too big an issue for reentry as your kerbals can go for one hour without resources and reentry doesn’t take that long. Just make sure you don't jettison everything until you are definably coming down. The bigger issue is probably that oxygen won't drain from symmetrical tanks evenly possibly throwing of the centre of mass if large enough tanks are placed far enough from the centre. If the crew can't get a needed resource, like oxygen, they should die. I don't see how disabling a tank could possibly allow the crew to survive forever with the way the mod works and I cannot reproduce the behaviour in my own tests. If this is happening then there is something else wrong, or I think most likely, your crew is getting lucky each time a death roll is done.

To get to Mun you will have to raise your apoapsis up to intersect Mun's orbit so that your ship reaches that point at the same time as Mun. To raise your apoapsis you want to burn prograde on the opposite side of the orbit from where you want your apoapsis to be. Getting the timing is pretty easy if you plot a manoeuvre node to raise your apoapsis and then drag it around your orbit until you get a Mun encounter. You can then tweak the manoeuvre node to get the periapsis at the encounter to the desired height. Once you reach Mun you will probably want to circularize your Mun orbit by burning retrograde at your Mun periapsis. You might run into trouble if your orbit around Kerbin isn't equatorial since your apoapsis may pass too high over or under Mun. In these cases, if you click on and target Mun you will get two markers on your orbit for AN and DN, the ascending node and descending nodes. These are the point were your orbit crosses the orbit of you target, the Mun. To adjust your orbital plane to match the Mun's you can plot a manoeuvre node at one of these points to burn normal or anti-normal (pink triangle markers on the manoeuvre node).

Patupi, first off I have not run into an issue with folder name or seen it mentioned before myself. I ran a quick test with the Firespitter mod and I did not have any problem adding IonModuleCrewSupport to the parts without renaming any folders. I might be doing it wrong, but I've not had problem. Secondly your code looks good; I copy and pasted it and it worked for me. I also tried creating a craft, saving it, and then adding the ModuleManager edits and reloading the craft in the VAB, and upon going to the pad it showed having the Ion module attached. It would still be my guess it has something to do with designing the craft before making the changes. I don't really fully understand how Kerbal loads data for parts but most of the time I don't see changes to the part.cfg taking affect on already placed parts. I wasn't able to reproduce that in this case, but I don't really understand why. You could try building a new craft with the part and seeing if that one works; it'll at least test if the problem is because the craft is older. How long are you waiting after running out of oxygen or filling up on CO2? I've had kerbals die from both cases myself and the code for killing them is pretty much integrated into the code for using the resources so if they're consuming O2 they should die when it runs out.