Nertea

October 31, 2014

I very much do not intend to assign parts to nodes. That's a bloody nightmare for maintenance, imagine that every time a mod gets updated, I'd need to update the tree. Awful.

I'll start laying out the tree in game tomorrow. I don't have a huge amount of time this week, but maybe it'll be available by next weekend. I have my other projects to work on too.

October 30, 2014

annonish, what's the chance that we could get some kind of support for custom node icons? I realize from my own attempts at tech stuff that it's an internal enum that's defining them, but I'm wondering if it would be possible to hack some kind of overwrite by getting the renderers or UI components being used to draw the nodes and replacing their textures. Would not be pretty but... not having new images bugs me more than it should .

I'll investigate myself when I have time if you don't . Just thought I'd mention it in case you had any ideas.

October 30, 2014

Updated the tree:

Added node: Fusion Rockets (what could this be...)
Added node: Subsonic Flight (propellers!)
Added node: Advanced Aerospace Composites (Advanced spaceplane parts)
Added node: Experimental Aircraft Engines (Advanced aircraft engines)
Added node: Heavy Control (larger pods and reaction wheels)
Added node: Power Transmission (microwave networks)
Moved the nuclear propulsion branch above rocketry
Renamed a few techs
Rearranged some more techs

Comments on comments:

I think these additions to the tech tree would make it even more flexible than it currently is:
1.propeller engines node for firespitter, retrofuture and kax branching from the aerodynamics node
2. 2-3 nodes for space telescope mods like the tarsier and cacteye that would branch from space exploration while being a separate node from the planetary surveys
3. an experimental AI node that would cover things like the interstellar AI core and a few other super advanced probecores.
4. a new node meant for rover systems that use alternatives for wheels like tracks or antigravs.
5. 2 lategame nodes meant for VTOL and SSTO planes and helicopters.
6. thermal propulsion node branching from the nuclear propulsion node.

1. Ok

2. I think these fit perfectly well in Specialized Science Tech and Long Term Science Tech

3. I think that's not quite needed. I'd rather give KSPI microwave transmission a node

4. Experimental Motors not enough?

5. Fair enough

6. Covered in Nuclear Propulsion, really.

This rocks!
RE the fusion drives and upcoming torch ships - I'll fit those at the far end of the tree, likely in KSPI-land since mine are comparable balance wise to KSPI's.

Gave you a fusion engines node. Some other mods could find it useful.

Looks great.
Regarding node dependencies I have a question, more a potential problem we need to decide how to act before it grows.
Whenever we make a new node dependent of another new node we should be very careful. I'm not referring to the problem of some small mod putting its part in a node in the last leaf of the tree (which could be a problem but I agree with roverdude being something that the modder should resolve rather than been solved here).
words

I think that I've solved that problem by not making co-dependencies unless mods can be confirmed to fill everything.

Amazing!
I like the requirement for both Automation and Robotics for Off World Manufacturing.
I also see your point in adding Orbital Surveys and Resource surveying as dedicated nodes, given how many mods use them. Not sure about having a technology tree pathway/branch dead end by tier 6 though. As it stands, Scansat's more advanced scanners are further down the tree than that. Also, nobody should want to start extracting resources without first having the detection tech researched.
Maybe tweak it so that Resource Utilization follows on from Resource surveying- that removes the dead end early on and and gives resource finding/mining/exploitation its own whole branch from Tier 5 onwards.
As for the nomenclature, the progression of Basic -> Advanced -> Specialized -> Cutting Edge (or Experimental) works well.
I note that Advanced Solar goes to two Tier 9 nodes, that both dead end. whats your view on bumping Cutting Edge to tier 10?
Or are there enough different solar components around to warrant the two?
I'm just thinking about avoiding empty nodes with say, only 1 mod installed- the fewer dead end branches there are, the easier it is to arrange parts logically
Really though I'm just nitpicking some minor details. The overall structure there is logically arranged, and it is fairly intuitive as to where I would expect to find various parts.

1. I see what you're saying there - I could see renaming Resource Detection to Advanced Surveys or something and moving it a few levels down. Merge resource scanning parts into Resource Utilization. I don't want to tie the surveying bits to the resource tree though. Seems... messy.

2. It makes things a little more interesting? But seriously, I already have like 20 panels (and more planned) to distribute in those nodes. None are really better than the others, so they're colocated.

October 30, 2014

I'm going to let you guys fiddle around and use whatever FAR stuff you come up with.

Those part really look great They are chubby-cute
Anyway, the FAR drag issue could be due to this:
If the nodes between two things are different, FAR assume that the inline front face isn't completly shieldied. At least if I remember correctly how far worked. Try to ask ferram about it.

I had been told that calling the part "Cargo bay" eliminated that behaviour. hm.

Thanks for the prerelease for the spaceplane parts, it is good to have a plane with a 2.5m cargo bay. All of the parts of well designed. I have a few suggestions about the new tail part that opens with a ramp: overall the design is great, would it be possible to make the ramp longer so that it touches the floor when using the standard landing gear, also the attach node on the back to too low so everything you place on it is slightly misaligned. The bulges on the side of the parts make it tricky to align fuel tanks but I am not sure if that is possible to change. Thanks for making these parts.
EDIT: Sorry to keep making suggestions but I think for the tail cargo bay the entrance needs to be bigger because you can't get 2.5m parts out of it. Thanks for making these parts.

I will make it touch the ground, but there's not much you can do about the entrance issue without compromising the tail component. Which I might be ok with, but it's pretty cool looking. Plus, I'm not too worried... I don't think 2.5m rovers would fit in the bay anyways (2.5m core plus wheels would be too large).

Actually.. what do we think of something like this? Move the attach node above the fuselage to make more room.

I've looked into the part cfgs and, er -
I'm not sure if the second parameter is even used, but something's definitely wrong here...

Me neither, but that'll teach me to just copy cfgs.

Nertea: You are a Golden God for making these parts. I definitely dig.
Re: FAR, I didn't have many problems after applying these MM configs (I basically just copied the FAR MM config for the SPP parts):

Thanks. Always happy to... make people happy.

It'd be a lot of work, but I'd also love to see those wing mounts capable of carrying fuels. Perhaps, similar to B9's use of texture switching for each part. In that respect, it would be "closer" to real life in that most planes carry a significant portion of their fuel in their wings. I know reality isn't KSP, but I digress.

I don't think it would be that much work, just need to add some numbers to the cfg, unless I'm misunderstanding.

In the same vein as the fuselage parts, I'd eagerly welcome 2x or even 3x longer cargo bays. It would help for those large loads, like USI's MKS modules, and it would reduce part count. Again, real life doesn't equal KSP, but you don't see many short and fat cargo lifters. Not saying they're not out there, but most large lifters are long to match...thinking C-5s and even KC-135s. Then there's the Antonov....
My final thought is just a general wish list thing....as such I know it's a long-shot. For myself, who only uses FAR, one of the only reasons I have any B9 parts installed is to use their Air Brake parts. Having some means by which to increase drag is almost essential, and using ailerons as flaps and spoilers just doesn't cut it. Having said that, I'd love to see an air brake part for the MkIV that is curved to match the dorsal fuselage. Sure, cargo transports usually don't have dorsal air brakes, but they just look so damn cool on F-18s.

The first is not unreasonable, 2x cargo bays and fuselages will be coming eventually (in fact the models are trivial to make). Texturing is a long proposition and I'd rather focus efforts elsewhere at the moment.

You may be in luck with airbrakes at some point. We'll see.

edit: I have one more thought, but it's small. While RCS can be placed anywhere, I prefer to have my RCS pods in line with the CoG/CoM laterally. In that fashion I can balance the power with 4 pods instead of 8, or having 2 each on the dorsal and ventral. Those gorgeous bulges of the fuselage sections I dig so much make placing RCS pods rather interesting. To that end, it would be cool to have a small flat, or less curved, surface on those bulges. That way when symmetry is on, the RCS blocks would have somewhere to go that's flat.

Hmm, there should be a flat area of collider right on the bulbous bit. I suspect you mean cosmetic though.

I'm considering making the drone core hollow. Thoughts?

October 29, 2014

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.

October 29, 2014

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.

October 29, 2014

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

October 29, 2014

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

October 29, 2014

Looks nice, and I agree with the general strategy comments you've outlined above. A few quibbles:
You made a few mistakes in the stock part of the tree. The two that are likely to affect the CTT are that nanolathing now derives from composites, while meta-materials leads to experimental rocketry (along with very heavy rocketry).
Can you clarify what sorts of breakthroughs go in the Heavy Construction path? That's the only one where I can't really visualize what is involved.
Making ISRU a branch of Field Science was pretty clever, I wish I'd thought of that. Would it also have interconnections with surveying, or not so much?
Can you spell out the children of Automation and Robotics, along with the prerequisites for Spaceplanes, Colonization, and Gigantic Rocketry? The intersecting lines make it hard to tell if we're all on the same page.
That's about it. Thanks for putting this draft together so fast!

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.

October 29, 2014

I'm also testing it with FAR and I'm loving it!
The wobbliness is due to the breakingForce/Torque being at 50, I changed it to 1500 and now I'm not getting any now. Testing is testing.
Also suggestion, rename the Mk4 Utilities Fuselage to 'Mk4 Service Compartment' and it'll consider things inside it as shielded for FAR/NEAR. It'd also be awesome if you could add some SAS to it.
Another suggestion is to add some LF/O to the Cargo Bays to help balance out the COM, You can fit 3/4th's of a 400 unit 1.5m fuel tank on either side in the bubbles so that would be a nice number.
http://imgur.com/a/AkKOa

I'll make those changes to the naming. SAS will be combined with a drone core slice by default. Fuel for cargo bays - maybe...

I use FAR and also experienced quite high drag on cargo bays. I believe FAR attributes high(er) drag to objects with an unused attach node, so perhaps FAR is not shielding these extra nodes and thus creating extra drag. I did a bit of testing and found that a craft with no cargo bays will still create rather a lot of drag at relatively low AoA, so *something* else is creating drag also. A vessel with a TWR of 0.5 was barely able to crack 110m/s at 2km altitude, for instance. I don't know much about creating FAR configs so I can't really do much to actually help at this point, but that behaviour doesn't feel right.
I remember reading (perhaps mistakenly) that FAR generates drag/lift values for parts without FAR configs from the part mesh - I can't recall with any authority if it was the visual mesh or collision mesh, though - so perhaps it's mis-interpreting something in the mesh and generating abnormal drag? The cockpit especially looks like it's generating more drag relative to other cockpits.
I wish I could help more, but when it comes to FAR I'm more of a 'consumer'. I've only ever set up a couple wings, not an entire fuselage system!

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.

The Good
The overall design is awesome. I mean seriously cool.
The flat bottom. Great for mounting gears, intakes, anything really.
The space in the cargo bays is great.
As someone else mentioned, the monoprop slice is a good idea - great for ballast, mounting life support pieces etc.
The cargo tail ramp looks nice and wide!
I didn't have a problem balancing CoM and CoL on a couple of quick test craft.

I like this list

The Bad
Docking port nosecone (and the cockpit nose I think) need an attach node
FAR flight characteristics are 'odd'.
Wing mounting on the fuselage 'bulges' can be tricky.
EVA Hatch on the underside is a bit odd, but maybe I'm not thinking creatively enough about ladder mounting!
I don't want to use B9 S2W now that I've had a taste of this.

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. .

The Suggestions
The bulges on the side of the fuselage pieces look like they could accommodate fuels?
Bulkheads on cargo bays w/ cutout for Kerbals to walk through?
Incorporating the method B9 uses to cycle through tank types and toggle mesh visibility (Firespitter?) could be useful for the above.
Custom landing gears?
Drone core?
Cockpit window illumination emissive?
Off in the realms of 'If You Ever Run Out Of Things To Make' - custom RCS, intakes, an inline cockpit, more rear engine adapters would be lovely. Also, the double hinged nose from THIS post would be rad. I don't know why I'd want to deploy payloads like that, but I really really want to now that I've seen that.

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.

I also just wanted to throw this idea out there:
http://www.moveoneinc.com/blog/wp-content/uploads/2011/02/Cargo-airplane-nose-open.jpg
Imagine landing Big Bertha on Laythe, opening up the nose, lowering the ramp, and barreling out onto the beach with a souped up rover! For science!

Yes, I have a sketch for this, but it has to wait until inline cockpits happen.

October 29, 2014

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.

October 28, 2014

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.

October 28, 2014

These Mk IV parts are going to be the stuff of legend! The cargobays are HUGE, and rival the B9 HL bays for size and most importantly, usefulness! Anyway, I was doing a bit of testing with FAR, and while I don't know which mod is the culprit, for lack of a non-offensive term, I wanted to throw this out there:
https://ls785w-sn3301.files.1drv.com/y2puhFMcLYQu2jGyFQMRFQZZhlyLEceC5VDMM_C1XOZVlPu4P4wpPKd1UOodZvWIejLhlJWTBE0U8RmQmyDCTdCxf48DAS9AW6UtOzd2CI-y5E/screenshot40.png?psid=1
Half the ship is comprised of cargobays, and while the one up front is shielded, the three aft bays are creating a huge amount of drag, which made it very difficult to get up into space, but she did get into space! There's also an issue with the way the wings attach to the various parts. The frontmost section, highlighted by a very bright drag indicator, didn't quite surface mount to the cargobays the way the aftmost wing sections attached to the fuel tanks. I had angle snap off, and couldn't quite get them aligned just right. Cosmetically, it's a non-issue, but FAR does the math, and calculates that it must fight me!
Also, the connection strength between the cargobays and fuel tanks seemed very weak. Wobbly shenanigans ensued.
Again, not sure if any of that is useful or not, but there it is.
I love the flat bottom hull, and makes wheel placement a breeze, given the limited sizes of landing gear out there. Very cool! When the IVA comes in the future, my only suggestion is to make the cockpit windows as large as possible. I know it's hard with the Kerbal head size to do that in an elegant way, but one can wish. Thanks for the hard work!

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!

Nert, dude. God damn.
http://cloud-4.steampowered.com/ugc/49864244462198306/5158C4A0C3AC851C7BDB2312E27B33E5529C1F23/
P.S. I really like the way you handled the monoprop slice, allowing it to function as a kind of transition piece between the payload bay and cockpit, as front ballast, and at the same time leaving plenty of room for extra gadgets, life support, and what have you. A superb effort, sir.

Yay! Glad you like.

October 28, 2014

It is. http://forum.kerbalspaceprogram.com/threads/98293-0-25-TechManager-Version-1-1?p=1506287&viewfull=1#post1506287

Excellent.

October 28, 2014

Just keep it simple, don't go into hundreds of techs and I'll applause this

I might cautiously say that the number of new nodes should not exceed the number of stock nodes. Which is 53.

Love it
The options you have up there make sense, with the only distinction off the top of my head being colonization type construction (I'd toss MKS/OKS/Asteroid mining there) and 'Make really big ships' construction (for FTT, 5m+ rocket parts, ELP, etc.)
110% in and will use or adjust to whatever you end up with!

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.

Two things.
Firstly, this doesn't have to cover ALL THE MODS. Even if it only brings collaboration to 50% of them, it'll still make life much easier and more pleasant for players who are using a suite of mods that do play nice. And while I can't talk for others, it would certainly influence my decision on whether or not to install a mod if I knew that it wouldn't work well with the other mods that I already had from the suite.
Secondly, it seems that the thrust here and in the Tree Modifier mod is towards the tree.cfg defining the nodes and their interconnection, and the part files defining which nodes they want to be in.
Having this community project as a base would actually make it easier for people who want to create their own completely independant trees, since it would make it possible to target the parts in various nodes with catch-all ModuleManager scripts to push any "other" parts into spots on their own tree after they had moved all the specific parts they cared about. This has been the biggest problem with custom trees in the past - you not only have to play with the creator's tree, but also with pretty much exactly their set of other mods, or else parts are missing, or weird nodes appear past the end of the tree, or stuff is in bizarre places.
This project could at least help focus on a baseline that could help reduce that sort of thing.

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.

EDIT: there is also one question I have. This Tech tree should force parts to tech or leave that liberty to other mods? In my opinion this is the main difference between it being use for personal tech trees that move things around (usually to be more "realistic") or create the room for other mods to play.
My vote is for the later: it should only create nodes (with name, icons, cost, etc) as frame for other mods to add their part wherever they prefer. Moving parts should only be done for very specific reasons.

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.

(In an effort to not clog the other thread with offtopic)
I potentially misunderstood the scope and purpose of what you initially proposed. You're not trying to design a tech tree as such. You're trying to design a web of nodes that modders can plunk their parts into as they see fit.
Am I getting it right this time?

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.

October 28, 2014

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.

Javascript is disabled. View full album

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?

October 28, 2014

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).

October 28, 2014

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.

October 27, 2014

By a fuselage truss, I mean a quasi-aerodynamic piece intended for things to be mounted outside of it - an external cargo bay, of sorts.
It's sort of like if you took a solid Mk4 fuselage slice, then took two 2.5m tanks side-by-side with a small gap between them, and then ran a boolean difference operation on the whole set.

I see, I see. Mayhaps!

Maybe you could stick a port in the monoprop slice if it's long enough, ala SP+? Although I honestly think that between the nose port and the cargo bays what's already there is sufficient.
Also does this mean 2 & 3 meter cylindrical cargo bays in SSPX? Because I would be pumped for that, no one has made a good plain cylindrical cargo bay.

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

... I want this so badly... All it needs is an IVA to be perfect.

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.

October 26, 2014

That looks spectacular, Nertea. It still needs sprucing up the topside, but it's already great. The short stubby design is hilarious.
Will there be a crew-cabin slice? How about a fuselage truss? (i.e. a centerline structural component meant to have things fitted on the sides, for instance a pair of 2.5m surface-attached modules) Maybe a slice with a pair of sideways-extending docking ports?

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

October 26, 2014

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.

October 24, 2014

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.

It's not just "a" rotation. It's *the* very rotation of the part itself, gotten from the same transform as the transform that got the point. Is there a way to tell the Unity editor to put a marker at a location inside my model and give it a name I can reference later, rather than the location of the model as a whole? I don't know the Unity editor well enough to know if there's a way to name a specific spot within the editor and reference it later in the C# code rather than the transform of the model as a whole.

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.

Wow if that's what it does then it's named very weirdly. Because what you're describing would be better called a cylinder cast - a raycast with a diameter to it.

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.

can query the physics update time but not the FPS rate time, as the FPS rate is fluid anyway and depends on what's being executed)

Time.deltaTime gives you the time the last Update() took.

As I understand it, Unity enforces the FixedUpdate rate by aborting code partway through if it's taking too long.

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 .

October 23, 2014

But it would differ from the actual problem in a massively important way - I'd be the one creating the sphere that I'm aiming the ray at, and the problem is dependent on the timing of my raycast's positioning versus the parts' positioning. If I'm the one in control of setting both the ray and the sphere it's hitting then I'm not really exposing where the problem is happening because I'll be deciding when the sphere moves. The frustrating thing I'm having with most of the google-able advice is that it's written for people writing their own unity game from scratch and telling them how to interleave the movement of their objects with the raycasting to try hitting them. As I'm not in charge of when SQUAD choses to move the parts around and what the timings on that is (nor can I even discover what it is because it's not public source code), such advice doesn't work in my case.
Or do I not understand what you're asking to do?

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.

I agree with the principle to do it as simply as possible to remove the unknown variables, but that does not look simpler than what I did. Not to my eyes. FindModelTransform is adding an unknown I'm not in control of. Getting the transform of the part directly from Unity like I did is less of an unknown.

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.

I should be clear that the linerenderer isn't just there for debugging purposes. It's intended to be visible to the end-user as the laserbeam. And I was told you do your animations in Update() because it's what runs every animation frame. As the linerenderer changes a bit each frame (making a pulsating effect where the line changes thickness and opacity each frame), it should be getting updated at animation frame rate, not physics frame rate.
I could add a second linerenderer for debugging that's NOT the one the user will see in the end, and update it during fixedupdate().

Ok, sure. You should indeed draw your user-facing line renderer in Update, but that's not helping me fix your problem .

The assumption that framerate is always faster than physics updates is false. On computers with high speed and good graphics cards it is. On less powerful machines it is not. The default physics rate is always 25 FixedUpdate()'s per second regardless of computer speed, while Update() rate depends on the quality of your machine and your video card and can be either faster or slower than 25 FPS depending on the computer. My computer is not a super awesome gaming machine. It's a macbook pro laptop that's been repurposed to run Windows instead of MacOS. I get about 20 FPS when part count is low. Worse when it's high.
In my case, putting work in Update() makes it impact the system *less* than putting it in FixedUpdate. If you see back in the thread, I've been consistently describing a situation in which more than one FixedUpdate() happens between Update()'s.
In a way I'm sort of glad my machine is not great. Otherwise I might not have experienced the problem and might have released a mod that's broken on slow machines and not realized it.

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.

October 23, 2014

This isn't workable in this case because I don't hardcode which part I'm trying to aim at. Its "return the hit on whichever part you hit that's nearest".

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.

That's what this is:


            origin = this.part.transform.TransformPoint( relLaserOrigin );
            pointing = this.part.transform.rotation * Vector3d.down;

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)

It's done during Update(), using a recalculation of origin and pointing (since the location of things can be different during Update()), but capping the distance of the line at whatever the distance result of the raycasts in FixedUpdate were. So FixedUpdate is picking the distance of the hit, then Update() is drawing using that distance. I don't think that will make much difference but I could move the drawing code to fixedupdate too. The problem isn't the drawing, but the calculation of the distance is missing the hit entirely.

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.

October 23, 2014

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

Profiles

Forums

Developer Articles

KSP2 Release Notes

Posts posted by Nertea