-
Posts
478 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by noonespecial
-
Ejectable Engine Fairings
noonespecial replied to noonespecial's topic in KSP1 Modelling and Texturing Discussion
Thanks for the information. I'll take a peak at KW's and see how they are set up. EDIT: Unfortunately, that didn't provide any additional information. Other than jettisonName, all the engine fairing entries in KW are identical to the one posted above (from a stock engine). The none engine fairings are set up like a decoupler. MODULE { name = ModuleAnchoredDecoupler anchorName = anchor ejectionForce = -300 explosiveNodeID = bottom } So if ModuleJettison{} is not flexible enough (will give it a try), would it be better to make the fairing as a separate part instead of automatic engine fairings? -
For ease of creation, I make my models with as many separate parts as possible. I'm sure this is common practice. For example, the service module I'm working on has 12 different meshes. Here is an example of but a few My question is: Should I leave them as separate or should I join them before exporting to Unity? Or... does it not make a difference at all?
-
Essentially, I want to create this: I've read about adding Icon_Hidden as a tag in Unity. In this picture, the fairings are broken into 3rds. Additionally, should it be modeled on the engine itself or onto the adapter? I can't really seem to find documentation on this. In the stock part.cfg there is this: MODULE { name = ModuleJettison jettisonName = fairing bottomNodeName = bottom isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 5 jettisonDirection = 0 0 1 } Name, jettisonName, bottonNodeName, are all obvious. But, what exactly is the jettisonedObjectMass? Is that the weight of the ejected fairing as debris? JettisonForce is also obvious. jettisonDirection, I'm assuming this 0 0 1 is x y z? So if I understand this bit, it seems that the fairing in this example has very low debris mass, barely ejects at all (low force) and ejects down? Also, are the variables for jettisonDirection only 1 and 0 (yes/no)? For the three fairings, would I create three fairing models, assign each one a different name, and give them each a different MODULE{} entry in the part.cfg? Since it is in 1/3rds, assuming N, SE, SW... would that be N (1 0 0), SE (-1 1 0), SW (-1 -1 0)? This is my first time (obviously) making an engine (or engine fairing). Any help for my ranted barely comprehensible questions will be highly appreciated
-
Yeah, the scaling is matched to real life scale, not KSP scale. I will adjust it to be more in line with KSP once I fully finish it. The Mk2-3 Pod is 2.5m, the Orion is 5m. So bigger, but not as big as the picture suggests (at least, after I scale it properly). Yes, I'm going to do most of the SLS, not just the MPCV. If one of your pictures made it into that album, it wasn't intentional. Those are just pictures I found on google that have at least some details I like, some I just thought were cool. ChakaMonkey's aim is a little different than mine. It's goal is to combine many current mods into a cohesive launch system and only creating additional parts as needed. Either way, it doesn't approach the scale of the SLS. The rational is this: Other "SLS" projects include sumgai's SDHI, blackheart612's Aerospace Kerbodyne Taurus SDHI, and ChakaMonkey's. SDHI is a 2.5m stockalike system. Taurus is a larger SDHI. ChakaMonkey actually has an Orion, but the rest of the launch system is still in the 5m range. The NASA SLS is a 8m system. The idea is this: With a realistic launch system (not overbuilt or asparagus, etc.) the SDHI is really an orbital vessel. The Taurus is fit for use within the Kerbin system (mun/mimnus). The SLS is a deep space and planetary exploration system. Also, as far as joining Yanfret and ChakaMonkey? Let's look at the names of people working on ChakaMonkey. Yanfret, Bobcat, Sumgai, etc and containing mods from KW, Nova, Fuztek, KOSMOS, ALCOR, etc. In other words, ChakaMonkey reads like the "Who's Who" and "Must have mods" for KSP. I've barely learned how to use blender and my textures need a great deal of work. I'm not of the caliber of modeler or modder that these guys are. First and fore most, doing this is a learning experience for me. I'm the kind of guy who needs a project to motivate me to learn something. I can't learn something just for the sake of learning. So that's my primary goal. So, in essence: Do we already have SLS-like systems? Yup, but I need the experience and I think it'd be cool to have a GIANT rocket in the game. Why don't I join Yanfret on ChakaMonkey? I'm not good enough.
-
I agree! Hopefully someone will post some. I'll throw something together, but my designs tend to be straight forward and functional. Nothing elaborate. Q1: The dimensions are roughly the same as the original octo parts. Roughly 4m wide, 2m deep, and 7m high. Q2: Will they fit into non-procedural fairings? Highly unlikely. Q3: They have prices, but I wouldn't say they are balanced with .24. I'm currently playing .24 to get a feel for what the prices should be. The trusses prices will pretty much be the same as comparable stock truss prices. The other parts, I have to figure out. As far as a Tri-Hex docking port. I'm looking into HOW to make a docking port, and once I figure it out, there will be a docking port. Currently, I'm trying to get solar panels and a storage bay with open/close doors working first.
-
THST is my take on the concept of Tri-Hexagonal Trusses. It was inspired by the original THSS by Semni, but I have taken it in a new direction. My concept revolves around the idea of modularity. This release only has a few modular components, but those will be expanded in the future. Parts included in this release: Tri-Hexagonal Components Tri-Hexagonal Trusses in Four sizes (Large, Medium, Small, and Mini). TweakScale is used to expand the default 1.25m to 0.62 (probe) sizes as well as 2.5m sizes. So a possibility of 12 different configurable sizes. Tri-Hexagonal Fuel Modules in Three Sizes (Large, Medium, Small). Radially attached fuel modules that work with the Truss system. Don't expect too much fuel, they're small. TweakScale enabled. Tri-Hexagonal Battery Modules in Three sizes (Large, Medium, Small). Radially attached battery modules that work with the Truss system. If a truss is equipped with three fuel modules and three battery modules, it will be equal in size and appearance to a standard 1.25m fuel tank Various Adapters to meet various construction needs. TriHex to 1.25m adapter. TriHex to 2.5m adapter. 5 Directional TriHex Hub. 6 Directional 1.25/TriHex Hub. 2.5m to Dual TriHex Adapter. Tri-Hexagonal RCS and LFO Trusses. OctoSeries Components OctoSeries Large LFO Tank. OctoSeries to 1.25m Adapter. OcotSeries 1.25m x 5 Engine Block. The OctoSeries uses Starwaster's Reflection Plugin Continued. If you don't like, or you find it bothers your machine. Simply delete the plugin from the SpecialTechnologies directory. Download (Curses) Source (GitHub) If you prefer the more classic version of THSS, SpeedyB has released a version that is more faithful to the original. Check it out. License Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International
-
I'm pretty much ready for release, except when I was play testing, I noticed something that may delay the release for a day or two. I'm having some horrible inconsistencies with scaling. Firstly, the trusses and attachable modules were actually made from a single model, which I then cut up and saved as three separate models. The truss, the fuel module, and the battery module. After importing them into Unity and into KSP, the scaling on both is different (and both different than the scaling I used in blender). I played around with importing, rescaling, etc for a few days with little success, then just settled for rescaleFactor in part.cfg. The REALLY strange thing about that is.... I'll rescale it, reload from debug, rescale, and so until I get a perfect fit then.... the scaling will spontaneously change. Take a look at this image. Notice the two different size modules? They are actually the exactly same part. Two of them decide to rescale themselves somewhere between the VAB and the LaunchPad. Has anyone experienced this before?
-
I sent a PM to the author of the previous mod about 10 days ago. He hasn't logged in since so obviously I haven't gotten a reply. So I'll be starting on this project this coming weekend as soon as I finish my THST mod. I'll be starting with the Orion MPCV and just do a part.cfg rescale of the existing NASA fuel tanks and engines. After that, I will finish the other SLS payloads. I'll save doing the real SLS tanks and engines for the last, as simply rescaling the existing tanks and engines should be suffient in the short term. Here are some more reference pictures (mostly for my own reference)
-
Thanks Speedy, that worked perfectly. Another problem I had, which I found the solution for, is that parts in the VAB wouldn't connect. It would snap to, but the part wouldn't turn "green". Apparently, there is a bug where Top and Bottom nodes have to last. Strange bug, but easily fixed. I'm finishing up the details in the part.cfg (part descriptions, weight, etc) and have to do a little scale refining. Everything is functioning as expected. Hopefully I can have it finished within the next day or two. I do have to say though... unexpectedly, I haven't actually played KSP since I started this project. I miss playing, haha. Can't wait for 0.24 (and I hope it doesn't break anything in THST).
-
[1.0.5] Reflection Plugin Continued 2.0
noonespecial replied to Starwaster's topic in KSP1 Mod Releases
Thanks for the information. So photoshop doesn't handle PNG correctly? That would explain why I've had no luck with changing the alpha channels. So both PS and Gimp have trouble with alpha with PNG? I'll give that plugin a try or switch to TGA. -
[1.0.5] Reflection Plugin Continued 2.0
noonespecial replied to Starwaster's topic in KSP1 Mod Releases
You have in your initial posts that Alpha Channel controls the reflective strength, with an accompanying screenshot that shows a cube with non-reflective portions. Is the alpha channel from the texture, the shader, or the normal? Also, is it dependent on the image format. I believe I read somewhere in this thread that you need TGA, PNG doesn't work properly? Also, is it more transparency in the alpha channel that equals more reflection or less transparency?