cvod

The problems noted in the past couple posts are because there were a few 0 cost nodes, and none of the nodes were set to "hide if empty". Should be fixed now.

Nothing pretty to look at yet, but here's a new thread discussing our plans for the mod: NEW THREAD

This mod will add radiation effects to the game and give you a new aspect to consider when planning your missions. This mod is going to be a two-person project. The other developer may post on this thread as the user “Doctor Manhattanâ€Â, so that’s who I’m referring to when I say “weâ€Â. You’re probably curious about what we have planned for this mod, so here’s a wall of text: Radiation Sources: Cosmic radiation: Background radiation with roughly uniform intensity throughout the solar system. Cosmic radiation comes from every direction, but planets/moons can block it. Even though the Mun has no protection from an atmosphere or Van Allen belts, the cosmic radiation dose is essentially halved for a vessel on the surface. Being in low orbit of a body will also reduce the amount of cosmic radiation a vessel receives. Once solar activity is implemented, cosmic radiation will fluctuate accordingly (lower cosmic radiation for high solar activity, and vice versa). Solar radiation: Created by the sun with an intensity dropping as the square of distance from the sun. Solar radiation will also be occluded by planets and moons. There will be some sort of wake behind the body that is relatively safe from solar radiation. As mentioned with cosmic radiation, we would like to implement periodic solar activity that changes the levels of radiation in the Kerbol system. We may or may not implement solar wind interaction with the Van Allen belts and magnetospheres of planets. This would essentially be a modification to the solar radiation occlusion code to account for there being a strong magnetic field (basically, a bigger wake). Nuclear reactors and engines: Radiation sources with their intensities dropping as a square of distance, thus only affecting nearby craft. Significantly more radiation when active than when off. The calculations for radiation dose will probably be based on the distance between the nuclear part and each of the manned parts (but we do not think that we can have it account for other parts in between blocking the radiation). Shielding and Protection: Planets with magnetic fields will provide a degree of protection from the first two sources while near the planetary surface or within safe zones between Van Allen belts. Van Allen belts, consisting of trapped charged particles, are areas with high radiation levels and are the result of otherwise protective magnetic fields. Currently, the only bodies that will have the protection of Van Allen belts are Kerbin, Jool, and Laythe. We are also considering adding them to Eve, but that is subject to change. Atmospheres will provide protection from radiation sources, but it will not be complete protection in some cases. The shielding the atmosphere provides will be based on the local density of the atmosphere. The amount of protection will also be dependent on your position in the atmosphere, although the difference will probably only be noticeable in the upper atmosphere. Until further notice shielding/shielded parts will not be added. Instead, existing probes and manned capsules will be given a shielding resource that can be adjusted in the VAB. Fairings and cargo bays will help shield contained parts and possibly will have their own shielding resource.The amount of potential shielding resource available for each part will be handled by Module Manager and will be a function of its mass, cost, and crew capacity. The thought behind this is that big (heavy) pods will allow for more shielding, cheap pods won’t allow for much shielding, and parts with large amounts of crew will have a little bit extra shielding to protect the extra Kerbals. We think this will add more to the gameplay than adding shielded parts would. We want to avoid having the player just slap on an extra part and then no longer having to worry about radiation. We also want to avoid limiting your options on what pods you can use, hence why we are using Module Manager to affect all parts (including mod parts). Later, we may add some manual configs for stock parts and popular mods to have more diversity in shielding stats, but we think the automated configs should be fairly effective on their own. We are considering having two shielding resources. This probably adds more to the gameplay aspect than the realism. Realistically, different materials have to be used to stop different types of radiation. Sometimes multiple shielding materials (and in specific order) are required to stop all the radiation. We would just grossly oversimplify this process by splitting it into “heavy shielding†and “light shieldingâ€Â. Heavy shielding will (of course) weigh more and be much more of a necessity in interplanetary space. Light shielding will be fairly light, so cost will be the limiting factor. You could probably rely on only light shielding in certain areas where you are either protected by an atmosphere or Van Allen belts. We think this will be beneficial to gameplay since shielding will play a bigger role in mission planning this way. For instance, if your satellites are never going to leave Kerbin, you could get away with only light shielding. Another example, if you send a rover to Duna, the rover itself could have minimum shielding (since it should be protected by the atmosphere) and it would rely on the heavy shielding from a fairing/cargo bay for the trip there. We also found some sources discussing waste matter being used for shielding on manned vessels. We may later implement this as a feature. It would detect waste materials on board the manned parts and consider that in the shielding calculations. Damage and Consequences: Kerbals will have a persistent value for accumulated radiation. There will be a critical dose of radiation at which the kerbal dies. We’re also considering implementing something similar to USI life support’s “grouchy†state as a toggleable alternative to having kerbals die from radiation. Probe cores and controllable manned capsules will also be subject to radiation damage and will be repairable by an engineer (possibly only higher level engineers). Kerbals: will lose capability to pilot craft (high level pilots may be able ignore radiation sickness), at higher radiation levels the Kerbals will be given a probability of dying within a certain (undecided) time frame. If you manage to max out the Kerbal’s radiation level, it will have a nearly 100% chance of dying within that timeframe. Kerbals themselves may also heal (very slowly) from radiation damage over time to make it easier to maintain space stations and permanent bases (this may become a toggleable option). Kerbals with the “badS†flag will have a higher probability of living longer after exposed to lethal levels of radiation. Eva-ed Kerbals will take in significantly more radiation. This will probably make you think twice before taking the crew out of the protected capsule. Probe cores: will lose SAS, then lose operability at higher radiation levels. Probes will be able to tolerate significantly more exposure to radiation than the Kerbals will. This will probably give more incentive for unmanned missions in certain situations. Manned capsules: The computer components get fried and the part loses the ability to be controlled even if the pilots are fine (same idea as the probe cores). Science experiments: will probably not be affected Antennas: reduced science transmission value in highly radioactive environments Solar Panels: performance degradation Batteries: will probably not be affected Lights: will probably not be affected Ion Engines: will not be affected Other: -Van Allen belts will be defined by a config file, so it will be easy for users to adjust the values and add/remove belts for specific bodies. This will be useful for mods that scale the planets, real solar system, and even mods that add planets. -geiger counter part for tracking the radiation level and as another science experiment -visualizations for Van Allen belts -visualizations for solar activity -glowing kerbals when highly irradiated -possibly make the Kraken a radiation source *Future plans (not guaranteed) *Added/Modified plans from original post *Removed plans from original post

Yep! We're still working on it and making progress with the code. There's been a lot of discussion and some changes in our goals for the mod since we adopted it. I think we have a direction we're happy with for now, so I guess we better get that new thread started.

Just updated the download to a bit of a half-baked update. Not all mods were fixed, but it should be in a better state than the previous version.

Little bit of an update. I have actually been working quite a bit on this for the past month, but indirectly. I've been developing an in game tree editor. It is not in a releasable state, but it is now functional enough for my purposes. All the tree editors have died, and this should make it much easier for me to release updates once school starts back up. On another note, I'm looking for anyone who may want to help sort mod parts and add to the supported mod list. I particularly would like help with large part packs that I am unfamiliar with such as FASA, NovaPunch, Tantares, etc. If anyone is interested, send me a message. This could be a one time thing, or you could stick around and help with multiple updates. I would prefer that it be someone who has used the tree quite a bit and is familiar with how it's organized.

Our plan is to make it compatible with anything that adds crewed parts.

Sorry for not posting about this sooner. I have adopted the mod and it will be a joint project between me and my roommate. He happens to know a ton about radioactivity since he is studying nuclear engineering. We have been discussing what our plans are for K-radiation, and we will be making a new thread for this soon.

Originally I wasnt sure what good changing the format would be, but that's a really good idea.

Looks great. Only question, how does this aid in creating tech trees? Is it just by supporting a simpler file format?

I think this might be what you're looking for.

That works. Now I need to figure out how to fix the arrows. I found out how to manually remove them, but not how to re-generate them. As an alternate solution, I found that after moving a node I could click the "Rebuild Tree" button in the debug menu to fix the lines. It doesn't appear that I can call a function for that button, but I assume it uses the functions SaveTechTree(), WipeTechTree(), and LoadTechTree(). For whatever reason the first two functions work fine for me, but I cannot get it to reload a tree. The arguments for it are RDTechTree.LoadTechTree(string filePath, System.Collections.Generic.List<RDNode> rdNodes)I know I have the first argument correct. For the second argument I've tried the list of the nodes right before they were wiped, the reference "RDController.Instance.nodes" (which is empty after the wipe), and I've even tried sending it an empty list. All produce the same result. They load the start node with max scale and no picture, and nothing else. Any ideas what the second argument should be?

Sorry, I don't see how that helps. I'm eventually going to implement dragging the nodes similar to how TreeEdit functioned, so I don't think my solution will involve ModuleManager.

I'm attempting to update the position of RnD nodes (in game). I've been able to call the node position using "RDNode.transform.localPosition". I have tried using "RDNode.transform.localPosition.Set()" to change the position, but nothing seems to happen when that function is called. After I use the function I call the value again and print it to the screen, and it just stays the same. Any ideas how I could force it to update the node position? I know TreeEdit was able to do this (along with dragging the node), and based on the source code for TreeLoader, it was using the same "RDNode.transform.localPosition" to get the node positions. Any ideas? Also, I'm looking for a way to update the RnD sidebar menu. When I change info or what parts are assigned to a node, the changes do not show unless I select and deselect the node.

I haven't found the reason yet. It sometimes shows an error when I'm working on it, but half the time it doesn't. So I'm not sure what it could be. I found the debug data on it once and it looked like KSP was complaining that there were two definitions of the module "TechTree". As long as the tech tree loads, I don't think the error matters. All it may need is a module manager argument before the TechTree module definition in the Mod-Oriented tree .cfg file.

Just thought of this and thought it would be an interesting mod idea. When I first started playing KSP I always thought it was silly how the tiny little yellow tubes could transfer fuel so quickly for asparagus-staged rockets. I think it'd be cool to have a mod that puts limits on the fuel lines and adds a slight penalty for using them. I assume in reality it wouldn't be so simple to pipe fuel all over the place like we do in KSP (especially at the rate we transfer it). What I had in mind was a single fuel line part that would have a fixed flow rate and a (relatively small) mass that is determined by the length of the fuel line. Then in the VAB right click menu, one could increase or decrease the flow rate. Adjusting the flow rate would then change the diameter of the pipe and increase the mass of the pipe. It probably wouldn't be a huge game-changer, but I would definitely enjoy having a mod like this. What do you guys think? EDIT: although the actual pipe part would need to gain mass with diameter, theoretically there should also be a pump on one end and the pump would have to increase in mass to increase the flow rate. Would it be possible to add the mass of a theoretical pump to the tank part that the fuel is coming from? The mass of the pump would probably be more of a limiting factor than the mass of the pipes.

I'm still having trouble with this part [COLOR=#333333]ConfigNode allNodes = GameDatabase.Instance.GetConfigNodes("RDNode");[/COLOR] This produces a list of length zero. And if I replace "RDNode" with "TechTree" it produces a list of length two. Neither are results I would have expected.

I'm not sure if this is doing what I think it's doing. There's probably a better way to do this. I'm trying to load the tech tree data using ConfigNode. Is this the correct way to do it? ConfigNode allNodes = GameDatabase.Instance.GetConfigNode("RDNode"); If it is, for some reason my plugin stops working when I try to get the RnD node position data. string[] allNodePos = allNodes.GetValues("pos"); What am I doing wrong? Also, does the GetConfigNode method get sub structures in the config files? So will it get the Parent structures within the RDNode structure?

I could do something similar to the unmanned version of the tree. I could swap the rocket parts in the starting node for bare minimum plane parts.

Awesome to see someone answered that request so quickly. Looks great.

What changes to this tree would you have in mind for that? This one already makes it viable to tech flight first if the player chooses to.

What does the template parameter do for file IO commands? I'm trying to check that a file exists, but I'm not sure what to put for "T". Also, does the directory for the file not need specified? KSP.IO.File.Exists<T>("filename")

I'm asking a lot of questions so I'll just put them all in this thread instead of making new ones. I'm trying to get information on the node that is currently clicked such as it's name and the parts assigned to it. I found the class "RDNode" which has a "OnNodeSelected()" method, but I can't figure out how to use it. Looking at the old Treeloader source, it makes use of the "ConfigNode" class. I'm not really sure how to use either or what I should be looking for to get the info of the clicked node.

I found how to do it in the editor (using the code below), but what would I need to use for the Space Center and RnD building? [COLOR=#333333]EditorLogic.fetch.Lock(false, false, false, "")[/COLOR]

This is a problem with the parent module. When one node has an invalid parent, it and all of the nodes that follow have this happen.