Nertea

I was going to post a bunch more thoughts, but I decided to just lay out some nodes . This is 41 new nodes. I'm gonna cap it at 45, 50 at maximum cap. I fully expect people to object to some of it, so here's some rationale on some areas. Nuclear Power Branch There are at least 3 mods playing in this playground so it has to have room for a decent progression Nuclear Support Technology is an extra node that I want, but I don't like the name (In NFT it's Advanced Cooling Systems, which is too specific) There should be enough here to support KSPI's abundance of reactors, NFT's reactors, KSPI's fusion (two levels) Larger Rocketry Branch Pretty generic extension of the stock tree Suggest this for 5m parts and the like Name of the second node isn't great Nuclear Propulsion Branch Two new nodes gives room for 2.5m and 3.75m parts, if you follow Squad's progression. There aren't enough NTR mods to justify that much more. Construction Branch Three new nodes focused around larger parts As Rover requested, later nodes are Orbitally focused in names Ion Engine Branch I need this many nodes for NFP KSPI can play here too Science Branch Room for a node's worth of new parts Two nodes with nomenclature for Station Science (and mods like it) Survey Branch One node for scansat and co One node for ISRU scanners I think this is enough, but we might go another node because there are quite a few ISRU scanners now... ISRU Branch Branch running from initial exploration to use to large scale stuff Should hopefully cover the range of solutions out there Colonization Branch I moved this branch to the bottom so it would fit better As suggested, folded life support into this Recycling -> Hydroponics -> Off world living Final tech might require stuff from ISRU and Science branches Future Technology Combines the end of the science stuff with the end of the plasma engines with the end of the fusion power stuff KSPIland. Rover, what would you want to do with your fusion drive? Solar Power Branch I want three nodes here Random other things Electrical Systems Node: KSPI generators or microwave transmitters? could add another node here for transmitters, considering that I have some ambitions of doing that sometime Another Control Node: Another node after Large Control might be good for large command pod mods? Firespitter, KAX, B9: Not familiar enough with these mods to say what they might want or need. However, be my guest and suggest a few nodes wherever (though do pay attention to the locations of the lines, it's hard to make things fit sometimes in the middle). I also solicit comments on (some) names. A few are evidently bad. I'd like to stay away from the high tech-> miniaturization though. It's the opposite of how the stock tree goes in a lot of respects. That doesn't mean you couldn't put those in with your own mod, but in most cases I've gone with "advanced", "high effic", "large scale" which neatly sidesteps the size question (yes, large scale could be many small ones ).Things also only get specific when I'm really sure that I know all the mods that play in that area, and that I can cover them all with a statement.

Yeah, node names... going to be finicky. They need to be broad enough to encompass all the mods' content, but specific enough not to lose meaning. I plan on working off of the NFT tech tree (see first post) for the fission reactor area, though with simplifications.

I do not know, but it should remove some of the drag issues with cargo bays.

FAR users, please try this config (you'll need MM). It uses the same method as SP+.

1. Fair enough. At this point I don't think it matters too much, but I'll update it when I get a chance. 2. Large girders, large habitation or station modules, large... things. Look at Rover's FTT for examples or really large parts, or NF Construction's octo-girders. 3. Thanks - thought it made sense. It could have interop with scanning, but it would have to be carefully managed so that nothing depended on anything. I guess logically you might want to lock Kethane tanks until you discovered the Kethane scanner. 4. Sure, it's unclear. I've changed it for clarification using colours. That entire area would be subject to the exact nodes that end up going in there.

I'll make those changes to the naming. SAS will be combined with a drone core slice by default. Fuel for cargo bays - maybe... Yeah I have no idea either. I'll go look at the SP+ FAR configs or something. I had heard something to that tune about the attach nodes at some point too. I like this list Not as bad as I thought it might be! The nose bits do have an attach node as far as I can see. It's hidden inside the docking retractor mechanism for the docking, but is visible to me for the standard nosecone and the cockpit itself. I can make the docking one larger I suppose, so it's visible. . 1. They might. You mean for the cargo bays? 2. I'm not exactly sure what you mean, like a crew bulkhead running the length of the bay? 3. I'm dead set on minimizing plugins. The only one I want to use is RPM. 4. Maybe. I know we will get some with the next Squad update, so I'm doubtful of the utility, and there was a redo of the one we have in the works too. 5. Yes, planned. 6. Of course! 7. I have two more rear adapters (to 4x1.25m and 2x2.5m) planned, as well as two intakes, an inline cockpit, and a few other things. The nose... eh, perhaps. I was going to make a pointy thing full of gas, but I could replace it with a pointy thing full of nothing. Yes, I have a sketch for this, but it has to wait until inline cockpits happen.

Okay, I had a shot at laying out areas of technology, and drew up the KSP tree in an online tool so everyone can have a look. Arrows represent areas of tech, and about where they would branch out from a stock node. Their horizontal extent across the tiers shows about what area the node would cover (eg, the Colonization section might cover two tiers). This works out to about 30-50 new nodes total at the moment, depending on how many splits in a tier there are. Notice that no area of tech really derives from a new area (except in the case of KSPI which adds several areas of tech that are subsequent). This limits inaccessible nodes. A few things: I think very few nodes are needed for life support (2 or 3 at the most), most parts fit into stock nodes beyond recyclers, greenhouses Locations of branching aren't totally clear for some branches. Solar, nuclear, ion, these make sense. Life support, scanning, they could probably be moved around. It's easy to cover everything except KSPI . This is because KSPI does these things like thermal nozzles, which don't exactly fit anywhere (could be fusion, could be AM, could be nuclear). I made up tier costs on the spot. Comment as you wish.

I think that most of these issues are surmountable, but really in general I aim to provide a framework. It'll be up to modders to support that framework with a fair idea of its limitations, or not to use it. The issue with one off parts is that they're one off. Do they expect tech tree support off the back? Is it a bonus, instead? I can think of a few ways to address these. More when I get home.

Most interesting. As far as I know you are the first person to test it with FAR, so this is good to know. I expect I'll have to look into it more, I don't know how it calculates drag. If anyone knows, feel free to chip in ! I can look into the cargo bay connection, I think that it might be that there are two nodes on each end. I made one size 1, chances are the connection between tank and bay sometimes uses that one by chance. I will adjust. I am also glad you like it! Yay! Glad you like.

Excellent.

I might cautiously say that the number of new nodes should not exceed the number of stock nodes. Which is 53. Yup, I'd extend the structural tree a few nodes further for really big stuff, and toss colonization stuff into a branch related to ISRU and life support. Yeah, and working additively (no rearranging, renaming or anything) from the stock tree also somewhat ensure that any combination of mods should in theory be playable. The only (partially) forced dependency I can foresee occurs when you might add up all the costs of the new nodes; it's quite likely that you might want more science equipment to max it out more easily. Of course, contracts give the needed science too, so it isn't an ironclad rule. I lean towards not doing part assignment, and having mods do it themselves via MM. Mods would be responsible for implementing their own balancing, their own layouts. That effectively removes like 90% of the difficulties I can foresee with the project Caveat: I don't know if this is possible with TechManager right now. That is the idea, yeah, a set and layout of nodes that modders can use, rather than a sorting nightmare o' doom. I'll start knocking together some more concepts, but I would really appreciate a post here if you are a modder and you are interested.

If you're new to the thread, check out current work on the tree. ------------------------ As suggested by RoverDude here, now that we have a tech tree editor (any maybe two of them soon) that can handle more complex trees than stock, it might be a good idea to see if a collaborative community tech tree could be designed. Because I like being involved in such a thing, I volunteer to curate and work on it. Can't let Rover have everything. In my view this would be limited to an expansion of the stock tree, so none of this "unmanned flight first" lunacy ( ). We would try to come up with a nice way of adding high-tech endgame nodes with high science costs and potentially some new branches starting at lower levels. Off the top of my head, mods that might benefit from this: MKS/OKS/RoverDude's huge stack of mods (heh) Karbonite/Kethane (resource extraction technologies) Near Future Technologies (nuclear, solar, ion engines) KSP Interstellar (fusion, really fancy stuff) Station Science (and other science-instrument mods) TAC-LS, Snacks (and other life support mods) That's quite a lot of mods, and I can see a huge line of 400 tech nodes stretching into the distance... my approach would be to try and break the contents of each mod into their component areas of research, and either extend existing branches or consider adding new ones where appropriate. My own stuff will probably be my goto example, so... here's my NFT tech tree extensions. Broken down into three main areas of research: ion engines (extension of existing branch), nuclear technology (new branch), solar technology (extension of existing branch). I think if we can ID the areas of research like this for all the mods that want to join a community tech tree, we can figure out what overlaps where and therefore how to keep the additions relatively focused while still trying to take into account the large ranges of mods we could have. Based on what I have above in that mod list, I can kinda see the following set of vague branches and extensions. Some are very self serving. ISRU branch (Kethane, Karbonite, MKS/OKS) Ion engines extension (NFT, KSPI) Nuclear engines extension (FTmN AR, KSPI, FTT) Nuclear power extension leading to fusion (NFT, FTT, OKS/MKS, KSPI) Life support branch (Life support mods) Construction extension (MKS/OKS, NFT, FTT) Solar power extension (NFT) Science instrumentation extension (Station Science, KSPI) Doomsday endgame things (KSPI) So I'll open up some questions: do you have a mod that might benefit from fitting into a stock tree? What areas of research does it contain? How many nodes would you like in that area?

This is pretty sweet. What are the chances of being able to add new node images in in the future? That would really make my day (well, even more).

Well, it didn't have a functional hatch before now... A new prerelease appears! Important Changes Textures for pretty much all the parts (except as below) Optimized and improved colliders for all parts Hatches and such work on the cockpit Improved attach points across the board New parts: Mk4 LFO Fuselage, Mk4 Utility Fuselage Tweaked weights/costs/properties on some parts Issues Mk4 Utility Fuselage and the two Mk4 adapters don't have normals/spec maps, and so don't match exactly well yet Mk4 Tail Cargo Bay and Mk4 Blunterator (name subject to change) don't have textures. Mk4 Tail Cargo Bay is purely for testing, it lacks meaningful collision and geometry is still WIP UV seams are visible on a few parts when zoomed out due to poor planning. As always, looking for balance feedback.

I see, I see. Mayhaps! Yeah I think I will only do that. And yes, there will be those cargo bays, though they will be less cargo bays and more equipment storage bays suitable for orbit Yeah yeah So I didn't realize it before, but the stock crew transfer thing allows the choice of which hatch to EVA out of! So you can actually use the rear hatch on this thing the way it's intended to be used! I welcome opinions on whether the end of the tail cargo bay should adapt to a 1.25m or Mk2 connection.

Yes, there will be a crew cabin, but not yet. No docking port slice I'm afraid. I plan to include an extending cargo-bay thing like the shuttle does, but that's actually going to go in SSPX (though will be designed with this in mind). I'm not sure exactly what you mean by a fuselage truss, do you mean a vaguely Mk4 shaped skeletal thing? Things I will certainly do (and need to be in the project before it goes to the release forum): Crew cabin Aft cargo bay door (possibly with tail adapter) Drone core/reaction wheel Mk4 to 4x1.25m adapter Rounded Mk4 "end cap" Things I might do, or will do after: Large surface attachable air intake Inline cockpit Mk4 nose cap (pointy) Forward cargo bay door Engine pod Things that are nice to have, but are long term: Double-size fuel fuselages Double-size cargo bays

Sorry to tease again, but I finished the adapters, the LFO slice and the two nosecones I'll do a proper prerelease after make specular and normal maps, and I model the monopropellant slice. Speaking of which: The idea is that it will be hollow collider-wise, so you can place things in there (battery packs, for example). It attaches nicely to the end of a cargo bay. It has enough volume for about 300 MP, could be more if you violate physics.

Dude, no need to bite my head off. I'm just trying to help you solve your problem. You asked why the doc example doesn't specifically use FixedUpdate, and I answered that. Yes, that's what I was saying, you're adding steps with potential error in them. Create a GameObject in the editor, place it as a child object of the object you put the PartTools exporter on, and name it something logical eg "raycastOrigin" - you can get the positional element of the gameObject (the Transform component) by using that FindModelTransform(gameObjectName) function. You can access that Transform component's very useful properties then, such as direction vectors and position. Not really. A cylindrical cast would have a "cap" at the beginning and the end, with the swept area looking more like a capsule. So you might call it a CapsuleCast... of course, that's actually a different thing. Time.deltaTime gives you the time the last Update() took. Nah, the code will be completed just fine. It'll just cause lag if it takes longer than the update period. The behaviour you describe would be very... bad for Unity as an engine .

Sorry, didn't think I needed to explain Spherecast. Imagine a raycast, but instead of moving a single point through the scene and tracking collisions, it moves a sphere, which is necessarily wider. Think of it as throwing a beachball instead of a golf ball. If you're missing with the golf ball, and the beach ball hits, you have some idea of where the target must be. The method I describe would give you the transform of an aiming point, specified in the Unity Editor which would be superior to the getting the transform of the part itself and then adding an offset, and then giving it a rotation. I can tell you that the code I directed you to is pretty ironclad, all it (seems to) to do is traverse the GameObject hierarchy and gets the transform with the corresponding name in the part. Never had any problem using it, and I use it for raycasting in Near Future Solar. Ok, sure. You should indeed draw your user-facing line renderer in Update, but that's not helping me fix your problem . I'm not saying that it's faster, but it will frequently be faster. I'm saying it's inconsistent. Seems what you want to do is run it less frequently than FixedUpdate, and running it in Update because it's slower on *your* system is pretty bad practice. Say you ran it on mine, with 2 part ship. I get pretty nice framerates there and it would run way more than needed. I highly recommend running it either in FixedUpdate, using a frame counter to only run it every 3rd or 4th frame or so, or run it in a coroutine.

Not sure if you get what I mean. Use Spherecast and see if it works. Test multiple radii. If it works, you can eliminate possibilities for what's wrong. If a radius of 0.5 is hitting and 0.4 isn't, you know that something is off by 0.5. Yeah, but why not use a much simpler formulation that's more flexible? Eliminates possibilities for error. Transform castPoint = FindModelTransform(nameOfGameObject); origin = castPoint.position; pointing = castPoint.forward; //blue axis of transform in Unity (Note that I don't remember offhand the calling syntax for FindModelTransform because it's a KSP, not Unity method) Well, what you're doing to visualize is kinda useless then. I'd say you want to visualize exactly where your ray is starting from and pointing - if you're running your visualization code from things updated every frame (Update), it will be inconsistent with what's actually going on. As to your last point... The biggest problem with using raycasts in Update isn't that it's necessarily *wrong*, but that Update runs every frame (up to the FPS cap) and that FixedUpdate runs every physics frame, which are less frequent and always happen at intervals of Time.fixedDeltaTime. Doing 60 raycasts per second is not great for performance... especially when it adds up with multiple objects doing this. Basically if you run a physics-based calculation every actual frame, you could get correct results, but you might not. More likely you'd get the same result for a few frames before the next physics update tick went through.

I am not fully happy with how the top looks either, so I'll probably be detailing it somewhat in the next pass I have at it. The two fuselages and adapter do look better than the end of the cockpit (experience) so I'll have to propagate advanced techniques that way sometime. Thanks for the cool pictures

So here's some things to try: Is the behaviour the same with Physics.Raycast() as well as Physics.RaycastAll()? In the past I've had issues with RaycastAll() in my own Unity projects. Try using Physics.Spherecast() with an appropriate radius, which does what you'd expect it to (raycast with a sphere instead of a point). It's more expensive, but it should get you an idea of what's going on. If you're thinking that there is positional jitter that is causing your error, using a Spherecast will help determine that - if it is hitting but the raycast isn't, there's a small jitter involved. If it's still not hitting I don't know exactly how the methods you're using to get your laser aim start point and direction are working exactly, but it seems like a far easier way would be to place a transform in your model file (placed and oriented as your laser origin), get it via a standard method, and just use that transform's position and forward parameters to aim the beam. I'm not sure why you're doing otherwise, but as you're raycasting within KSP's physics bubble against things inside the physics bubble, you shouldn't need to do much else. If all else fails, you should try this. Related to point 3, how are you drawing your LineRenderer (I don't see it in your code)?

Waiting is required. Like I said earlier... better visibility than the Mk2 cockpit in terms of both side facing and foward view. Due to how large the part is, it may be hard to see, but the vertical extent of the window is about the same as an entire oversized kerbal head.

It's fine.

Thanks for the detailed feedback! I'll address some of them below. Ok, good These two are staying. They are key elements of the design reference, and I like it I'm not sure I want it to look graceful. This is a difficult one. I would not be a fan of removing them and replacing them with specific shoulders, because then I need to make a single-use part to go there. I really don't like single-use parts, and that area is about 25% too small for a standard 1.25m node. The options are keeping it as-is, modifying it to accept 0.625m nodes (holes I guess), or integrating something different into the structure there. The design reference has air intakes at that location - adding integrated intakes to that area is not completely out of the question, but I'm not sure... not yet, for sure, I need to step back from the part for a while before I come back to it. I guess everyone seems pretty convinced of this. I made them smaller, but kept the whole area dark grey/black (though I may add some detail to it). It was the easiest solution in terms of limiting reworking of the UVs. Yeah, they are not very done. There will probably be a third one too. It annoys me too. I could move the CofM down, but that will run into problems with engine alignment. The adapters would no longer give you engines centered on the CofM (and it would be impossible to rework them completely, the 1.25m ones maybe, but the 2.5m node just can't move down far enough). Anyways, thanks for your comments, even if I can't implement them, they are appreciated. Essentially I'm totally open to changing a part until I unwrap it, then I get really reluctant (even more so if it's textured). I textured the small LF fuselage today, later in the week I'll have time to texture the LFO version and the cargo bay (which is getting a number of model tweaks). I also made a start on the other two adapters that I plan - a Mk4 -> 2x2.5m and a Mk4 -> 4x1.25m one. Besides a possible cargo bay/tail adapter, I don't expect to do anymore. They are sloooow to unwrap.