Nertea
-
Posts
4,792 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Nertea
-
-
I guess what I want is for there to be a minimum of effort required by the end user and the modders who want to add support for their projects. It would be nice if the only extra thing I had to ship to support CTT was a single cfg file for each mod detailing the changes in the TechRequired field.
-
Nertea, awhile ago when Karbonite was just starting out, you posted on the dev thread an image of your replica of the stock fuel tank endcaps for everyone to use. It's been invaluable to my texturing efforts, so I was wondering if you might have a rendition of the 2.5m endcap (like on the mainsail and size 2 stack splitters) that you'd be willing to share.
I do... but not one that I'm very happy with. If you look through the NFT parts they're quite varied; if you see one you like I'll see about providing the psd for it.
Hi Nert,Any new developments? I really like what I'm seeing so far. I haven't yet taken the plunge, but I plan on starting a new contracts career soon, and space planes will figure heavily. This looks like it'll be right up my alley.
I sadly am lacking in time these days. I have remodeled the aft cargo bay, remodeled the end caps for the fuel tanks (they sucked) and started on the few remaining basic parts. There's nothing worth showing quite yet though.
-
Yeah I've got no issues now.
Re: distribution, I'm wondering what to bundle. Some people are very against bundling, but I'm not, so... haha. Opinions? The two requirements are going to be TechManager and MM, should we bundle one, both, or none?
-edit: there's a repo now, feel free to peruse, comment and make ye olde pulle requestes.
-
Wow.
I'm so disappointed with this.You want to keep things simple. That's fine, but can I suggest that for your next project you make a community tech tree that's actually a whole new community technology tree, and not a forced progression tree?
Dude. You are the most antagonistic, passive-aggressive poster on this forum, and I'm kinda sick of it. If you want to make your own thing, go... over there and do it yourself. No need to come badmouthing other people's things. I stated my goal precisely in the first post of this thread (which you didn't read obviously).
Nertea,The tree that I downloaded earlier (from the front page of this thread) doesn't have the node "Nanolathing". Is there an equivalent where the stocl parts that live there would end up?
It does appear that I snipped it by accident. I will re-add it.
This is looking great, and it looks like we're adopting it for RP-0.I'm now going to be the packaging and standards dude who wants us all to agree on naming and conventions. I know some folks will be bundling the CTT, and I know others will require that it be downloaded. So the important question for us to answer now is: where in GameData will this sit?
I recommend GameData/CommunityTechTree/tree.cfg. That means we don't end up with multiple mods putting it in different places and us ending up with duplicates. It means that ModuleManager will produce a pass for CommunityTechTree, so parts can :REQUIRE or run :AFTER that. It means that CKAN packaging will run out of the box.
In terms of updates, we've got a few options. New versions can release with the same path, but then players run the risk of ending up with an old version of the CTT if a mod bundles an older version of it. If we're targeting TechManager (which I hope we are), then the tree should be ModuleManager friendly¹. One possible solution then would to then have tree.cfg be invariant across new versions, and changes be made by having update files (tree-update-1.1.cfg, tree-update-1.2.cfg). Those update files will run after the original tree.cfg and can update it appropriately. This means someone installing an older bundled CTT won't be changing any files, and the player won't end up with a surprise backgrade to their tech tree.
CKAN installs are of course immune to all of this, because the CKAN will always install the most recent compatible version of the CTT. I'm happy to do the CKAN packaging, although having releases on Github or Kerbalstuff will help a lot there, as our bots are then able to detect new releases automatically.
Thanks again for all your hard work on this, Nertea, I very much appreciate it!
~ Paul
¹ Anonish, I'd love your confirmation that my beliefs on the awesomeness of TechManager and ModuleManager are correct here.
This is pretty much what I though we'd do. That also seems like a clever way of handling the update situation.
-
It's like I want this to be stock, but I also don't, because then I'd have to redo all my things to a higher standard
. -
I've been really busy recently, and playing too much Civ:BE, but I'm still working on this...
Playing with it, it's horrifically unstable. I think the CoM is off-center from the aircraft, but I need to do some investigating. Also, could it be possible to have some alternate variants of the cockpit based off of the current formfactor? There is a metric butt-ton of space beneath the flight deck you could play with, and I can think of several variants that could be put into practice.The C of M looks fine to me. Suggest you look at your design, I found that I need to change things around from my usual methods due to how much lift the body pieces create (that might need some work).
I plan on a nice two-deck arrangement for the interior. We'll see after that.
I made a thing:Excuse the GUI being too much to the right, it seems KSP doesn't like too small a resolution on fullscreen. But the pics and GUIs go from left to right, pretty simple.
Cargo bays and adapters can now hold a variety of fuels, with various weights of initial tanks and stuff and things.. available setups are Structural, LF, LFO and MP. You'll need Firespitter and this patch won't fire if you don't have it. It's probably a little unbalanced, but I got the numbers from both stock and Nerts initial amounts, with a bit of fiddling. Feel free to change the amounts/cost/weights as you see fit, it's probably a bit unbalanced.. I've no idea, I'm a little drunk. Was debating about using FStextureSwitch for the fuselage but it seemed like too much work for just one less part in the part list.. Though, I have to hand it to Snjo, FS is very well documented, no wonder it's so widely used. ANYWAY!
Was contemplating putting it on more parts, but those already have other uses/functions and I didn't want to encroach on Nerts already marvellous models (like the MP slice - that's why the MP setup has only slightly more MP despite the much larger size)
Anyway, yeah, go have fun!
Gonna build a Shuttle with this now, brb.Pretty sure you can't use TextureSwitch for that last one, as both share the same textures (just moved UVs). ModelSwitch would work. Anyways, nice work. Possibly a MM patch that could be included.
I always like these.
-
These are very nice, I like your clean texture work. Looking forward to seeing that engine, it is pretty unique and we could always use more non-nuclear orbital engines.
-
Glad you like it. I'll probably wordsmith some of the descriptions some more before release too. I plan to support NFT, SSPX and the Mk4 parts as soon as it's official released.
I was wondering what it would cost
. I had to click the "add science" button a lot of times, I'll say that. -
I think it'd be fine to still have the "None" option available and selected by default, but possibly move it out of the tree selection box (greyed out trees in the box). Having it outside the box ( another radio button above the tree field?) would create the correct logical disconnect between it and the ability to select trees.
Of course, just greying out the others would work too...
-
Those nodes are intended for MKS/OKS and life support mods.
-
And you are positive the default wasn't 'None (disable TechManager)'? Because that starts selected, and while selected, the other trees are not displayed.
The trees are loaded at the main menu, and the selection dialog is populated once, before it is shown. I won't rule anything out, I just don't know how it could be doing what you describe. Screenshot if you get a chance?
That's what it was. Didn't know that was intended behavior, it is a bit counterintuitive. If I wasn't a "click everything" person I might have assumed that something was wrong and the trees weren't loading.
-
It asks me to select trees, and shows only the default one in the list of radio buttons (I can't remember the name offhand). Click the radio button/name of the tree and it loads the rest.
-
Minor bug - sometimes the tree list doesn't load naturally at start. You have to click on the blank tree in the list window to force the list to load.
-
I think I found another issue. I think TED needs another field in the node info for the techID field. It currently only has name, which is used to link tree components. It generates... odd values for techID (such as nanolathing over and over again). This breaks TreeManager. techID is also the name that's used for part assignment, I believe.
Also a tree starting with a TECHNOLOGY_TREE_DEFINITION node enclosing the entire tree (as TreeManager 1.2 supports) won't load.
-
The stock nodes are all defined, I'm not sure what you mean. I hadn't tested with the new version of TechManager, which I had not noticed, which seems to be the problem... it was working totally fine before I updated it.
I'll take the download down, because something's not right, even if I remove those two problems you mention.
-edit: Restored, found the problem. Seems to work ok with TechManager 1.2 now.
-
This is all very informal at the moment. I will git a project (ha... ha...) when I actually have some time.
License is CC-BY-NC-SA 4.0.
A question - I've enabled all the nodes to be shown even if empty here. If they are set to hide when empty, the tree could cut off access to later tech and for this skeletal test, it's best that the entire tree be visible. If we decide to, I'll ensure all CTT nodes are marked as hide when empty at actual release time.
Known issues: tree is not centered on the r&d field, I accidentally deleted nanolathing
-
A quick question: I note the tree seems somewhat skimpy on crewed-space nodes. Where do you plan to put capsules? I noticed there's now a landing subtree, does that mean landing legs get put there and the Space Exploration subtree is for capsules?
There's always been a landing subtree, hasn't there? Squad puts capsules in control nodes, which makes sense to me, but I added two nodes since that last update. So there's now Heavy Control, Enhanced Survivability, Long Term Habitation and Short Term Habitation that are new candidates for pod-makers to use.
-
I haven't actually tried putting parts in new nodes yet so I can't confirm.
I can confirm that the last version does fix the arrows though.
-
I think that's more of a question for the people running the tech loading plugins than me - I have no control over that.
Anyways, I finished laying out the tech tree. I could use a couple of testers, I suppose.
-
Re: the icons, it might be a good idea to play to combine the icon with letters somehow. We only have a limited number of icons to work with and unless there's a good way to add more, any tree with new nodes will have to reuse. In that case, the letters are actually *less* confusing!
-
It ends up being somewhat similar, but because ctt's has some changes to the stock section, it's a little different from my goal.
-
I had a test! It works really nicely even in this form, nodes are easy to create and move around. I only found one bug so far!
Bugs noted:
- A tree created by the tool (loaded by techmanager) shows no link arrows. Thought this might be TechManager's fault, but when I load older trees with it, arrows show fine
- You can't seem to expand the work area for the tree, which is a problem when you want to make the tree wider/taller.
UI/Features:
- I like the single-letter for showing tech names, it's elegant, but there can be so many similar names that I might suggest the first two letters instead
- Grid snapping feature would be great.
- Direction of links is quite hard to determine.
- A tree created by the tool (loaded by techmanager) shows no link arrows. Thought this might be TechManager's fault, but when I load older trees with it, arrows show fine
-
As soon as I saw this I knew what I had to build!
http://upload.wikimedia.org/wikipedia/en/a/a3/Thunderbird2.jpg
Was TB2 inspiration for the cockpit?
So far tricky and I have had to increase the wing span, when I get something that I am happy with and works I will post a few pics.
Have you thought about giving the cockpit and hull pieces lift?
The tail ramp piece yet to be textured is absolutely awesome.
Could I also suggest VTOL hull sections with engines built into the sides.
Awesome project keep up the good work!
Yes, of course it was TB2
. All the wide parts have live already, actually. Considering some surface attachable VTOL engines for that.
Today I tried working the Mk4 fuselage parts into a heavy rover, but it didn't quite work out.http://cloud-4.steampowered.com/ugc/49864638435051219/7B5904E6FDD81B957727F195E5B30A3E84563EB4/
Heh, well, hopefully the newer version of that piece works better
The Drag issue is being caused by the unused nodes on the cargo bays. Here is the cargo bays with the node removed.This can't be the entire answer, because the SP+ bays use the same 4-node method with no FAR issues.
So here's an idea for the cockpit piece. Essentially the idea is to allow the mounting of inline air intakes on either side of the cockpit, at the ends of those protrusions on the side. No idea what the technical term is, sorry. The way I see it working is two flat surfaces that could fit either sloped caps (creating the cockpit shape that's present now), or an extender (creating the shape of the 2x1.25m + 1x2.5m tail segment). What this could do is allow for both of the tail segments (the version with and without the 2x1.25m nodes) to be merged, and for the player to be able to create either one by using either the extender or the cap on the 1.25m nodes on the side.Sorry for the muddy explanation. I could try and whip up a drawing to show what I mean if you're interested in considering the idea.
I think I addressed this at one point - those bulges are too small for this, and I don't like it anyways.
-
@Nertea not sure how it would be a nightmare cause the suggestion I made just references the parts it doesn't define them so the only updating that would need to be done would be if someone wanted to add or remove a part from the tree. I get where you are coming from though considering you have your own mods to maintain.
@RoverDude it just seems like what you are suggesting requires more work for modders than mine, while I can see the thorny problem of overcluttering of a couple of nodes or parts going into nodes that aren't connected to others we will still need a CTT download to have the proper tree, I keep mentioning this cause your mods and nertea's mods may share many of the same nodes but there will be nodes nertea has that you don't and nodes you have that nertea doesn't. It just seems like it would be easier to have one person do a small bit of work with the ocassional need for update instead of having every modder having to update their mods to use this and all the players needing to redownload all of their mods that are using this just so that they can take advantage of it.
now I may be over complicating my explination or may knowledge of how the tree and such are handled may be too lacking for me to see some of the more complicated problems but it just seems like there would be an easier way to do a CTT than just having everyone use the nodes that are set out and include that into their mod.
Now a question for me own curiosity, but could actually be a problem later, is how would you get two different tree files to play nice when they use different nodes of the same tree without the ability to merge them together and then attach the needed nodes to the stock tree? Because in all the posts I don't remember if anyone answered this question.
That's exactly the nightmare though. What you are describing means that every time a mod adds a part, I need to update the tree. Thats not an infrequent thing, there's a lot of part mods out there. That modder has to communicate with me, the location needs to be defined etc. You could end up with needing several updates in a single day, even. That's not fair to me, and its not fair to modders either, waiting on an update for a third party. I'd hate it, if I was the modders waiting for a tree update and having to deal with support requests for something out of my control.
.
Gonna build a Shuttle with this now, brb.
[Planning] Community Tech Tree
in KSP1 Mods Discussions
Posted
Huh, that is indeed a critical thing that I hadn't considered.