curtquarquesso

Glad we could persuade you. In general, don't worry so much about poly counts. You're so stupidly good at texturing, I can't stand to watch yourself get limited by poly-counts. Some of your more complex parts really stands out. Ah! A good start. I would make the curvature and indentation more severe honestly. @hoojiwana's tiny LFO tanks are pretty much perfect in terms of curvature and AO. The best looking tanks you've ever made/helped make are in AB Launchers. The bulkhead on the 5m Energia tank is just flipping cool. I love it. For the large tanks, I would definitely up the curvature quite a bit.

You'll need to open up the Unity package that @Ledenko so kindly released. Didn't know he had released his source stuff to the public domain. Major kudos. RCS thrusters in KSP use ModuleRCS. This is the module in the stock RV-105 thruster block: MODULE { name = ModuleRCS thrusterTransformName = RCSthruster thrusterPower = 1 resourceName = MonoPropellant resourceFlowMode = STAGE_PRIORITY_FLOW atmosphereCurve { key = 0 240 key = 1 100 key = 4 0.001 } } The parameter thrusterTransformName references the name of an empty in Unity, with name RCSthruster. You can call the empty whatever you like. I personally use the name monoTransform. When you put your empty in Unity, know that the thruster will fire along the +Y axis of that empty. For my example, I put the empty on where the thruster is painted, and made it fire upwards a bit at a 30º angle. You can make as many of these as you like all around the capsule, pointing at various angles, but I would not over-do it. I would not have more than 2 monoTransforms pointing along the same axis. I believe that rather the two transforms firing at full thrust, the game tells them to reduce thrust to balance out. That's why single RCS parts with many nozzles facing in the same direction don't look right when they fire. Make your monoTransforms children of the main GameObject, or a child of another empty if you want for neatness and organization. It seems we have thrust! Now try it yourself, and post the results. Let me know if you get stuck. For simple questions, just PM me. Don't clog up this topic, and make sure you truncate when you quote me. No need to included full quotations.

Whatever the poly-count, it'll still be far less than anything present in stock. It's so worth the extra verts. The looks of some of the newer parts are starting to become a bit too homogenous. You visual cues to indicate the purpose of a part. I would be wary of holding your breath for PorkJet. Due to 1.1 lacking the standard shader. acking the standard shader, It's probably unlikely many/any revamped parts will make it into 1.1. I hope I'm wrong, but that's what's more likely. No the the one on the left, maybe to the one on the right. I wouldn't use them on anything larger than 0.625m though. It will look disproportionate if used on larger diameter parts. Resource images spoiledered for brevity: I tried something really simple to improve the appearance a bit of the Soyuz fairing base, so I just hollowed it out. If you put some structural truss inside it so people don't assume it's concave, and passable, I think that might be a good holdover solution perhaps. Joking aside, arrows, warning labels, model numbers, and other verbiage are really good at improving understanding of part function. For example, the red arrows on the TLV Decoupler are super helpful, and shouldn't be under-estimated. Not saying all decouplers now need arrows, certainly not, but the visual cues help. Another example would be the new TKS parts. The short monopropellant tank with the yellow tank insets is super handy, and visually clear on what its function is. The service module though, not so much. For a while, it had been driving me crazy, because it always seemed to be underperforming awfully when paired with a monopropellant main engine. Little did I know that it was mainly LFO, with some monopropellant. By looking at it, I couldn't tell that it was a combined resource part. I wrongly assumed that it was all monopropellant, because it didn't really visual indicate one way or another what its contents were. Ultimately, it was because I didn't read the resources in the tool-tip, but perhaps you see my point.

The new Gamma engine looks great! Can't wait to see how you figure the interstage for that out. Neat stuff. The tanks, I'm really not digging frankly. I really liked the rounded COPV-styled bulkheads that you used to do on your tanks. The copy/pasted stock structural part texture is rather dull, and ill-suited for usage on fuel tanks. Plus, it's lower-resolution than your textures. The rounded COPV-styled bulkhead on a fuel tank shouts very clearly, "I AM A FUEL TANK, USE ME AS SUCH." I know it's a bit more difficult to whip up, but it makes all the difference in the world, really. Maybe it'd be beneficial to make one or two common COPV bulkheads you could drop into models, without making them from scratch every time? Same goes for the fairing base. The model and texture doesn't really give any visual cues as to what it actually is. It might be a good idea to make some nice looking fairing bases in all the common sizes that support the stock fairings, and ProceduralFairings.

Make sure you have ModuleAblator included in the .cfg. This here, is copied right out of the .cfg for the Stock 2.5m heat shield. Should be close-ish. MODULE { name = ModuleAblator ablativeResource = Ablator lossExp = -7500 lossConst = 0.1 pyrolysisLossFactor = 6000 reentryConductivity = 0.01 ablationTempThresh = 500 } Charring is controlled by parameters called charMin, and charMax. Giving values charMin = 1.0, and charMax = 1.0, will disable charring completely. Giving values other than those control the amount of charring, but I don't know what does what. Just mess around with values close to zero and one, and see what they do. Here's a great post on the topic of charring and ablation. I think even the color of the charring can be controlled by putting a color code into a parameter called charAlpha. So, if you didn't want it to char to black, but perhaps a dirty brown-black, you could possibly achieve that. Not sure myself. Never tried it. And, then you need the Ablator Resource, which you already know. RESOURCE { name = Ablator amount = 800 maxAmount = 800 } On overheating, you need to check out parameters like maxTemp, thermalMassModifier, and skinMaxTemp. I would just find the values that the Stock 2.5m Crew Capsule uses, and use numbers close to that. For buoyancy, I would just define it if it hasn't been defined already. The buoyancy for the stock 2.5m capsule is 1.5 I believe.

Just dive into the .cfg, and add the ablator yourself. For simple stuff like this, it's faster to learn how to do it on your own, than it is to pester add-on authors to do it for you. Heck, that's basically how I got into modding myself.

Thanks Kasper! Worth mentioning, it's not just that phrase. It happens with some phrases, of two or more words. Can't find a reliable way to recreate it consistently. Also related to searching, did the bug where sorting search results by date in a topic get fixed? For the longest time, when you'd sort search results by date in a topic, it would forget you were searching in that topic, and instead show you results for all forum content sorted by date, but remembering your keyword search. I haven't had problems with it lately. It seems to be behaving as expected.

The original had that as well, but I think I found a way to make each panel into 6 faces, as opposed to 8. I guess the question is, are the verts/tris worth it? Is the 4 faced panel to jagged?

The edges you see there, I didn't intentionally create. They were just a result of the beveling, and how Wings handles that. When I did this the first time, I recall there being a reason I didn't do what you showed me, which is the obvious way to do it. With the way the model was at the time, I got some weird tangent planes and deformations. When I tried it on this pass, I didn't get any weirdness. It worked fine, so that's the way I'm going. Thanks for the help. I tried just separating the panels one time, and it did result in some z-fighting, shading weirdness, and ugliness. I didn't think it'd be a problem either, but it was. Lots of tiny little jagged edges. If the edges intersect, I see jagged edges. Plus, if their curvature doesn't match, there are gaps, and weirdness. Extruding the panels out of the cylinder mesh isn't hard anyways. I've got the process documented. Just inset 0.025m, inset again, move planes normal, and then harden edges and bevel. Not all that bad. You just have to know how to use inset in Wings properly. If you inset wrong, you'll inset EVERY face, not just the groups of 4. Any advice on how to bevel the panels here would be helpful, or if I even should. Perhaps you haven't unlocked EVA in career mode or something? Seems to be working fine for me. Also make sure you're clicking on the hatch. There are portholes on both sides of the capsule.

Did a third pass at Cygnus with reduced vert count, and less beveling. It's much neater, but the down side is that it's less round. Hardly noticeable to some I suppose, but I did prefer the roundedness of the previous version. I only have to model one section with each pass, as I just stack and bridge their faces. Still have to do the front paneling somehow. Old vs New: The old version looks nice, because the panels themselves look more smoothed and rounded. It has horrible plane tangents though when transitioning from the extruded panel to the 24 sided core cylinder. The newer one though will be simpler to work with, simpler to texture, and will have less performance hit. I'm still thinking of beveling the panels like I did before, but I need to do the edge transitions better somehow to avoid weird tangents. Oddly enough, the don't show at all when smooth shaded. An annoying problem spot for me is here: I think I might take this to modeling and texturing discussion, and ask how people would handle this. Can anyone think of a better way to model that edge? SketchFab WIP v3.0 Cygnus Segment with reduced verts. SketchFab WIP V2.0 Cygnus PCM

I'd be happy to. Give me a little bit here. OBJ, or just the Wings file?

Antares: On texel density, I agree. It could stand for a lot more detail. I'm just working on part layout, and integration. Gotta find a way for all the parts to go together conveniently. Not sure what you mean by relying on stock parts. Clarification needed. Manual: Holy crap, that's awesome. That's perfect. I love it. So many advantages over .craft files. In modern modeling, I agree. For KSP, and especially against Beale's work, where few parts are beyond 1500 verts though, it is a lot in comparison. I don't think my Cygnus model pushes too far into over-detailed as Beale mentioned. The base cylinder is still 24 sides. In a convenient segway, I can show you exactly how that model is pushing 3,000 verts. If you look below, every one of those stupid beveled MMOD panels has to be beveled at least twice, or it looks awful. If anyone has any ideas, let me know. I'm already planning on red-doing the front face of the model entirely. It's messy, and poorly done. See above. I'd like your input. What do you think? Is it too detailed? There's no way I could justify faking the bumps with just a normal maps. I've seen it done, and it's awful. The base cylinder is 24 verts. What's your opinion? Ugh. Another annoying stock bug. Wonder if we could get a status check on this one, and see if 1.1 fixes it... Hmmm. Yeah. I might start making this part of my convention. Have any screens of your unity setup showing how you do this? Sounds like a better workflow in some ways. @Beale, I think now might be a good time to develop another development road-map. There seems to be a lot of different projects in motion at the moment, certainly, through much fault of my own.

I'm working on it. Beale has yet to approve any changes made to Antares, Cygnus, or Castor. I haven't really sent him anything to work on, because I don't have all the correct solutions to all the problems quite yet, but I'm getting there. The reason it's currently 0.625m is because Beale's original Cygnus was 0.625m. There's a 1.875m now, but no Antares to match. There are probably more important things to tackle at the moment though. Edit: I haven't worked on Cygnus in a little while, but I still have to figure out with Beale what he wants to change, and is willing to change. Antares is a cozy 2.5m which makes the Castor 30XL 1 less-cozy 1.5m, which makes the Cygnus service module 1.7, but is basically irrelevant due to shrouds, and Cygnus is more or less 1.875m, with all the bumpy panels. 1.25m PCBM, of course. My current to-do list is: Lower poly-count on PCM. The Standard configuration is sitting at 2,400 verts, and the Enhanced is at 3,216 verts. I'd like to reduce this some, but given that a stock mainsail is around 2,500 or so, I don't feel too badly about it. Make a way to separate Castor's interstage in a way that's fun and interesting. I'd like to to be able to jettison from both ends, first from the Antares S1, then from Castor prior to its ignition. This requires some collider and ModuleJettison tricks. Figure out how to give players somewhere to put their payload fairing above the interstage. I've fooled around with trying to make floating ProceduralFairing nodes, at a predetermined position relative to the decoupler/procedural fairing base, but no matter where I define them, they always want to be located at the center y-coordinate of the part that they're defined for. Very weird. Make it so that the parts go together intuitively, and people aren't constantly asking for craft files. It's no fun fussing around with decouplers, interstages and tanks, trying to get things to work. Uni-tasking parts also suck, and aren't fun to play with except for anything other than replicas. Not shown is a rounded bulkhead that will be an "IconHidden" tagged mesh that will go on top of the Castor. It's kind of the inverse of what we were talking about a few pages back regarding the R7's "crown".

Nope. It's currently possible in the current TweakScale config. Besides it's default size, it can scale down to 0.9375m. It looks like a version or two ago, the parameter in the "ScaleExponents.cfg" that's part of TweakScale had a parameter removed that disables scaling for crewed pods, so I don't think you have to go in there and enable it anymore. There should be no more reason to have that in the instructions for installing the config. Should just be drag and drop. I could use some input here actually regarding scaling in the config. Should I just allow free scaling of all parts? I'v been reluctant to, because I didn't want to break career stuff. I'll still make size increments for the the popular scales, but do you all want to be able to adjust sizes down to one or two decimal places? I was just make sure players couldn't take advantage of sizing increases in the early-game... Thoughts?

Hmm. Ok. I'd still like to see Curse comment on this. Having two separate sites and two separate experiences is part of what I think has cause a lot of this confusion. Thanks for the background info all.

Ah. That's what I'm looking for. Still doesn't entirely answer the question. So, authors upload on Curseforge, and players download on Curse? Why the separate sites?

Correct. I did mention that. Squad is just one of their many clients to service. I don't think many players understand that, or care to understand that though. Regardless of the reasons though, it definitely makes it seem like add-ons are an afterthought to Squad, even though that's really clearly not the case. I remember the scathing response, but I don't remember how Curseforge came to be, or why. It was never really explained very well. If anyone has any links to Curse or Squad talking about the differences between Curse and Curseforge, that'd be great. That probably needs to be explained an reiterated if we're going to get people to stop dumping on Curse, and try improve the situation. Hmm. Then where did it come from? And why isn't their one experience for all users?

Huh. That's the first I've even seen a Curse representative around on the forums, though I admit, since I used to rarely use Curse, I wasn't looking all that hard. That particular thread was started only started last Wednesday though. Based on their posting history, they only regularly post about once a month, with this last week, and the initial introduction of Curse being the obvious exceptions. I still think the disconnect between Curse and Curseforge is the strangest part. That could use some explanation, and clarification if @Jadedcat is around to provide that.

I think I see part of the problem. This has confused me for a while, but I finally noticed something. People, myself included, have been missing it for a while. There are two distinct Curse experiences. I'm sure for many of you, this is a "duh, of course Curse and Curseforge are different sites, and different experiences." I didn't know this, and I'm sure there are plenty of people out there who don't either. The KSP main menu itself directs to Curse, not Curseforge, so the majority of people are having the first, ad-ridden experience, and the minority of players, mainly mod-authors, and people who are a bit more in touch, are having the latter, ad-free experience. That's why no one is seeing eye-to-eye on Curse, and that's why there's confusion. Why are there two experiences? Why are there two sites? On KerbalStuff, users were having identical experiences. If you were an author, you were on the same site as your users. Not so with Curse. What is the functionality difference between the two sites? Why are there two sites? Another problem I see, is no (seemingly no) interaction between the Curse people, and the forum people. They have no presence here. KSP is just one of their clients, and they have no ability to talk to players, and make changes, fix stuff, or provide support. They're just a faceless entity, with no personality, and that just works against them in terms of likability. Edit: @mcirish3 just pointed out what I pointed out in much fewer words.

Hey! I didn't know about this add-on until it got re-uploaded to SpaceDock. Can't believe this isn't more talked about. The "cannot activate while stowed" message drives me nuts. Makes hot-staging basically impossible. Going to give this a try. Have you talked to someone like @Claw about getting this worked into the Stock Bug Fix Modules, or at least getting mentioned in that topic? Might give it some more visibility.

Hmm. This is interesting. Ok... How many toggleable shrouds can a part have? How are they all defined in the .cfg and in Unity? I can't quite tell what the non-toggleable interstage looks like. Is it a truss structure or something? I ran into some of this while working on an interstage system to work between Antares and the Castor motor. When I have some time, I'll send you some screens. Tricky stuff... If Squad would just allow toggling between different meshes for fairings, shrouds, and interstages, and toggles on how they jettison, and from what end, things would be much easier.

YES. If you're going to normal map anything, normal map the capsule itself. Ven's revamp of the stock Mk1 pod is a good look to target, even though I know that it needs to somewhat match BDB's style.

These reference images should answer that question: The quad you have is simplified, but that's probably better for part counts, and useful for all kinds of things. Because the stock linear RCS ports suck, perhaps making a pretty, somewhat flush linear RCS port would be a good solution? Then people can lay out their RCS setup however they want. The other obvious part to make would be a dual-nozzled 45º RCS block, as seen on the very rear lip of the service module. As you have it currently, you have the main engines where the rear-facing RCS port should be, which is probably fine. I would make the FX for the main engines the white wispy hypergolic effect, and call it a "dual-mode" hypergolic motor. Take out all the LFO, and make it all MonoPropellant. It'll be much more efficient that way. Could you just put both thrustTransforms in the same place?

The thing that would be most helpful, would be some basic pre-fabbed configs on the front page for some common scales like 3.2x, 6.4x, 10x, and even RSS scale, that are known to work and play well. It's difficult to figure out how to balance the rest of the game when you scale things up. I'm using SMURFF, FAR, and DeadlyReentry to avoid having to drastically scale parts up, but it's still difficult to keep everything working well. I'm not sure if and how I should be adjusting those add-ons to make them behave as expected when everything is scaled up to 6.4x scale.

Heh. Very much like Russian nesting dolls. Rocket in a rocket in a rocket? Blue Streak would be best with a 1.875m first stage, and a 1.25m second stage. Black Arrow's first stage should be 1.25m, the second stage is closest to 0.9375m, and 0.625m is about as good as you'll get for Waxwing. Currently, Tantares doesn't have any truly tiny, early-game launchers, so that'd be really nice. There aren't too many problems with making the British rockets inaccurate. Because they don't have bunch of stuff to scale against, or vehicles to be compatible with, they're fun no matter what size really. Here's a quick mockup! The only issue, is that it's totally unflyable. The Blue Streak Warden rocket engine has no ability to gimbal at all, and the only torque present is on the Prospero payload itself, so there's no way to control it. Apparently, these engines didn't gimbal, so much as they swiveled, to vector thrust, but I don't know how to make that work in Unity, so it'd probably just be better to give them a few degrees of gimbal to make this motor actually usable. The scales here are 1.875m Blue Streak, 1.25m Black Arrow S1, 0.9375m Black Arrow S2, and inside the payload fairing is the RLA Stockalike SMAC Payload Assist motor scaled to 0.625m playing the part of the Waxwing kick stage, along with Prospero as the payload, scaled normally. @InsaneDruid is correct. Rescaling the LK and all its parts down to 0.9375m using the Tweakscale config makes it much easier to stack on the N-1. It's also less mass to take to the moon, or wherever you're going, and it's more practical. As far as the N1, and the lunar parts go, I could probably mock up some parts at the correct scales against an orthographic, and find convenient sizes for the stages. I would wait for a while before messing with N1 though. It's a lot of work, and there's so much else to do.