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.