Absolution

There are a lot of variable that go into the behavior of the fairings. How long did you make them? Do you see this behavior with both 3 and 4 meter versions? Anvil I through III were made obsolete by the introduction of the "light" versions of Anvil IV and V so I don't think I'll have a reason to bring them back (Anvil II and V are almost identical). As it stands the active Anvil rockets fall into a nice envelop to deploy a very wide range of payloads. The only thing I could imagine doing is developing bigger SRBs for even larger payloads and maybe a 6m fairing diameter but that's all hypothetical. My attention is other projects right now.

ding, ding, ding! We have a winner! One of my many modules combined into this one single part is a solar panel which contains its own animation. I deleted the solar panel code from the config thinking it may be interfering but I never considered removing the asset out of Unity. Once I did the light started working perfectly. I would really prefer to combine these two functions together so I tried combining the solar panel and light under the same animation. The solar panel doesn't actually animate but needs an animation it its hierarchy to work so I thought I could away with it. Turns out I can't. I just need to bite the bullet and make two separate parts. Thanks all for the help!

More and more its looking like my animation is the problem. I tried Nazari's suggestion and set the intensity to 0 in its initial state and 2 to its final state. The result was that the light intensity did in fact start at 0 in game but it would not go to intensity 2 after turning the light "on" (it was drawing power but not shining). When I preview my animation in Unity it behaves the way I think it should and goes from intensity 0 to 2 over the course of the animation. As an experiment I checked the "always animate" box in the animation inspector just to see what would happen. Despite having the initial intensity state still set to 0 as above the light was shining in game. Therefor the animation must be partially working because it did animate the light intensity from 0 to 2 automatically. That implies that the trigger that tells the light to animate manually is not working. When I set the light to "on" it doesn't fire the animation. Okay, so as another experiment I changed the name of my animation to what squad uses for theirs "LightAnimation" because perhaps the KSP coding specifically looks for that name. No change in results. My light is part of a bigger assembly and the config file incorporates multiple modules so maybe they are not playing nice together. To test that theory I removed all of the other modules that I thought would possibly interfere. No change in result. My config file appears to be identical to that of squad's with the obvious exceptions to the entries to account for my unique naming. What the heck am I missing? MODULE { name = ModuleLight lightName = headlight useAnimationDim = true lightBrightenSpeed = 2.5 lightDimSpeed = 2.5 resourceAmount = 0.04 animationName = LightAnimation useResources = true } I am starting to pull my hair out...

Can you expand on that? I tried turning it off three different ways and none of them worked so I must misunderstand. First unchecked the box next to "headlight" at the top. Second unchecked the box next to "Light" in the middle. Lastly, for giggles, I tried unchecking the box next to "animation" at the bottom. Each time I exported my model and reloaded it into KSP and there were no observed differences. Could my Hierarchy be part of the problem? My light object resides in an otherwise empty game object titled "headlight". The animation is attached to that same game object. Could that be it? Do I need to tag the object or set it to a certain layer?

I'm making my own spotlights and run across an issue: My light is always on. This should be a simple fix for someone who has done this before because I can turn the light "on" and "off" in the menu and it draws electricity when "on" and does not draw it when "off". So I am 90% on track. The problem is that regardless of what state its in it is always shining and illuminating the world around it. I suspect that my animation is not set properly and I admit that I did not set any of the animation properties under the assumption that the "on/off" action would do the hard work. I checked to make sure that "play automatically" is disabled, and it is disabled, so that probably is not related to the problem. I can only assume, then, that there is a property in the animation itself that should be set. I tried playing around with "enabled" and "intensity" under the light feature of the animation window but neither had an effect. I also tried the "enabled" entry under animation without success. How do I get the light beam to animate on and off? Can anyone shed some light on my problem? *edit* Had a brainwave and tried to animate the "range" of the spotlight to go from 0 to 20 over one second of time. It animates the way I want it to in Unity but did not fix anything inside of KSP. I wonder if I am on to something but missed a step? SOLUTION: There can only be one animation on the given part which controls the lights. If there are multiple animations doing multiple functions then the light breaks and wont animate.

What kind of objects can be used as the "suncatcher"? I have a very unusual shape for a solar panel and I would like to create a simple, invisible, panel to act as the "suncatcher". How can I do that?

The next steps in my incremental improvements is to tweaks the models add emmisives to Anvil V. After that I will be taking another look at the SRBs. That will also include emmisives and possibly a remodel. As for the high survival rates of the upper stage decoupler and booster that may be an artifact of early part developments. My early flights kept exploding under launch loads so I made their breaking forces very high. I never bothered to locate the debris to notice they were surviving reentry. I will look into that.

1.7.0 is released! ---1.7.0--- (10AUG13) -Revised Anvil IV and IV-L part properties. Upper stages now have higher Isp than lower stages (among other things). -Completely re-modeled Anvil IV and IV-L. -Removed SRB-065A-1. Rendered obsolete by Anvil IV revamp. Also not mentioned in the change log are that I fixed the folder name to "parts" and I fixed the text in the 3m nosecone. I think that's all the bugs and typos but if you see anything you know where you can find me. I also got around to making a better brand image for an intro and outro. It's my first animated render using Blender so it's far from good but it's a heck of a lot better than the last one I tried. As always I suggest deleting previous CORE content before installing new content, including .craft files. Good luck and have fun!

Small Update: I am probably a week away from releasing Anvil 1.7.0. I've got all the parts modeled up and most of the textures done. Next tasks are to finish up the new video intro, balance and test the rockets. I'm really happy with the results so far and I am glad I've taken the time to make it happen. One problem is that I can not log into my spaceport account so I might have to release 1.7 via dropbox. I've submitted a tech support email but who knows if they will be able to fix the problem by release time.

I believe he is referring to the following: http://forum.kerbalspaceprogram.com/showthread.php/938-Part-Modeling-in-Maya-how-to-guide As in he suggests that you have a basic understanding of how to model and export to KSP before trying intermediate level techniques like Emmisives. ----- Also not stated in the tutorial above (unless I missed it) is that when setting up the animation you should disable the check box titled "play automatically" in the inspector window of the gameobject you added the animation to. You can read more about it here: http://forum.kerbalspaceprogram.com/showthread.php/27450?p=346176&viewfull=1#post346176

I've read through the patch notes for KSP 0.21 and it does not appear that Anvil was affected in anyway so we are good to go. However, I didn't actually test anything yet so if you see anything, of course, you know where to find me. I'll be adding a small bit of mono-propellant to any CSBs that do not have it yet just in case. I am also thinking about adding reaction wheels to some of the parts to aid in maneuvering. However, realistically that's not a practical solution for objects so big and heavy... we'll see. I've learned a lot since originally doing Anvil IV eight months ago so this face-lift is going quick. CSB-412 is already modeled and the texturing shouldn't take more than an hour or three. That would only leave CSB-406 and their config files. Easy-peasy.

Okay if I understand correctly there are two things I need to fix. One is that I need unique names for each docking node. Check. The other is that my code needs to read like the following; yes? MODULE { name = ModuleDockingNode deployAnimationController = 1 nodeType = size1 nodeTransformName = DockingNode }

Time for an update: I've limited my time for the last week to rest and research and what I've come up with isn't encouraging. Docking nodes are an underdeveloped feature at this time and although there are options for me to work around the system to get the First Light to work right it won't function the way I want it to. Plus, with the game still undergoing regular, save breaking, updates I think it's too soon to focus on a mod that relies so heavily on persistent saves. I've decided to shelve the First Light for now and let KSP develop further. I'll still play around with it from time to time but for now it's back to Anvil. I want to give Anvil IV its long planned face-lift as well as develop parts to create universality with stock parts. There's also some fine tuning I want to do with the part properties and experiments I want to run on other part types. Expect to see some preliminary results in a week or two.

I know a lot of people like to mix and match so in the future I am considering adding some specific transition parts to allow for a seamless matching with stock parts. It was never my intent to be a rebel and develop parts with unique diameters but KSP is a little confusing when it comes to dimensions. The whole KSP universe is scaled by 125%... or was it 80%... or... whatever. So a 1m diameter part isn't exactly 1m in game. Plenty of people figured it all out and I can too but I was too lazy to care back in the day (I started Anvil a year ago). My assumption was that my parts were not meant to be mixed and matched. I've softened to the idea lately so I will make an effort... someday. One of my parts did have two nodes inside of it so I took out the second one and it still didn't work. I guess there is more than one problem with my parts which makes everything so much more painful to figure out. I've tried several different things to get this thing to work and nothing is panning out yet. My current two options are to, first, develop a dedicated docking part to eliminate any other variables and, second, to incorporate stock docking parts into my design. Both of those will require some research and development time so my release window just got blown out of the water. However, it's unfair to keep teasing so without further fanfare here is my, less than exciting, project reveal: The "First Light" interplanetary spaceship. Project intent is to build the ship using unmanned drones (not shown) and launch a crew of 8 on a separate rocket. The First Light will be capable of delivering that crew and a mission payload to any planet in the system with an on-board capacity of 8000 m/s Delta-V (subject to change). I would have shown textured pictures but my problems prevented me from finishing the last two so I just left them all plain for now. The only things missing at this point are those last few textures and a working docking mechanism. Everything else is ready for full scale testing. The large craft set off to the side is the resupply ship which is meant to deliver crew and supplies for a full mission. It turned out a little bigger than I imagined it so that may get redesigned later. Also, my supply section turned out a little smaller so that too will need some work. The First Light modules are based on a 5m diameter payload capability which is why I developed a 5m standard for the Anvil IV. There are 5 separate modules (Command, Habitation, Docking Hub, Supply, Engines) which will require 4 different configurations of Anvil IV to launch. In an effort to keep the numbers reasonable I needed to keep the ship as light as possible. Despite that when fully fueled and mission capable the First Light weighs a whopping 173 tonnes; 100 of which is just fuel. The three engines produce approximately 1500kN of thrust which is sufficient to accelerate the First Light to transit speeds in under 5 minutes. I did that intentionally to limit the amount of time you had to sit there and manage the burns. The engines have an Isp rating of 950s which is well in science fiction territory for a chemical rocket but if I had kept it realistic (~350s) the fuel requirements would have been staggering requiring three refueling trips, at least, by the supply ship. I found that unreasonable so the compromise was made. I did investigate alternative, realistic, propulsion methods and I strongly considered a VASIMIR type system. It's got more than enough Isp to do the job but, like all electric engines, produces very little thrust. I don't want to make people sit there for several hours while such a system nudges the spacecraft to the desired velocity. Maybe I can revisit that when a smart auto-pilot system is developed for KSP but not before. I could of scaled the system up to meet my needs but the power requirements were comical. I needed to find a way of producing ~60MW for a sustained 5 minute burn. That requires a large nuclear reactor or some scary large batteries. So considering all that I went with a more believable chemical rocket.

That first suggestion didn't seem to work and I will try your revised suggestion to see if that does it. Someone suggested there can only be one dockingnode per part and one of mine had two so I took out the second one and that did not work either. I am wondering if it IS working but something went wrong with the coordinates and the nodes are not loading in the locations I want them to. Therefor when I try to dock I never get the nodes close enough to "magnetize". I don't know how to test for that though. Is my DockingNode located correctly in the part hierarchy?

Maybe this is a case of being unable to see the forest through the trees but I've proof-read the document again and can only find one error. That being the titles on the last two pages. On page 11 it should be titled "ASSEMBLY ANVIL V" and on page 12 it should say "ASSEMBLY ANVIL IV". Anvil V is my 2m, lighter payload, rocket and the IV is my 4m, heavier payload, rocket. Can anyone give me a hand and point to a specific instance where you think I erred? I feel like the document is just too confusing or poorly arranged and people are seeing something I do not intend them to see that way. Nothing will happen over night but I've worked too hard on this not to do a good job and I want to do better if I can. --- Update on my current project: I've run across a significant problem. All of the proof of concept tests I did weeks ago are now invalid and my docking parts are no longer working. I can't figure out what's wrong. This is so frustrating because I was just about to cross the finish line. I will continue to bang my head against the desk for a few more days but if nothing happens I will just post a few pictures of "what could have been" and move on.

I do. Recent bug hunting and tweaking resulted in failure and here are things I've tried: -renamed the nodes to "top" -installed part tools version 20 and exported the parts in question -reinstalled KSP 20.2 and the parts in question I am trying to create a combination part that's one half command module and one half docking port to allow for pain free assemblies in space. Maybe I don't have the modules and CFG hierarchy set right. However, this was working just fine circa KSP 0.19 so unless something changed that dramatically in 20.2 I am at a loss. More details: Part 1 Unity hierarchy and node location/placement Part 2 Unity hierarchy and node location/placement (these two parts are meant to meet up and dock in space) Part 1 CFG (complete) PART { // Kerbal Space Program - Part Config // CORE_FL-CMU-01 // // --- general parameters --- name = CORE_FL-CMU-01 module = CommandPod author = Absolution // --- asset parameters --- mesh = model.mu scale = 1 // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z, SIZE node_stack_top = 0.0, -2.5, 0.0, 0.0, 1.0, 0.0 // --- FX definitions --- fx_gasBurst_white = -2.5, 0.0, 0.0, 0.0, 1.0, 0.0, activate sound_vent_large = activate // --- editor parameters --- cost = 1200 category = Pods subcategory = 0 title = FL-CMU-01 manufacturer = C.O.R.E. Concept Rocket Engineering description = description. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,1 mass = 7.6 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.15 angularDrag = 1.5 crashTolerance = 30 breakingForce = 15000 breakingTorque = 15000 maxTemp = 3100 vesselType = Ship CrewCapacity = 3 MODULE { name = ModuleCommand minimumCrew = 0 } RESOURCE { name = ElectricCharge amount = 50 maxAmount = 50 } RESOURCE { name = MonoPropellant amount = 100 maxAmount = 100 } MODULE { name = ModuleDockingNode referenceAttachNode = top nodeType = size1 } MODULE { name = ModuleRCS thrusterTransformName = RCSthruster thrusterPower = 1 resourceName = MonoPropellant atmosphereCurve { key = 0 260 key = 1 100 } } } Part 2 CFG (complete) PART { // Kerbal Space Program - Part Config // CORE_FL-HAB-01 // // --- general parameters --- name = CORE_FL-HAB-01 module = Part author = Absolution // --- asset parameters --- mesh = model.mu scale = 1 // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z node_stack_top = 0.0, 2.5, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -2.5, 0.0, 0.0, 1.0, 0.0 // --- FX definitions --- fx_gasBurst_white = 0.0, 2.0, 0.0, 0.0, 1.0, 0.0, activate sound_vent_large = activate // --- editor parameters --- cost = 1200 category = Utility subcategory = 0 title = FL-HAB-01 manufacturer = C.O.R.E. Concept Rocket Engineering description = description. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,1,1 // --- standard part parameters --- mass = 7.6 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 160 breakingForce = 15000 breakingTorque = 15000 maxTemp = 3400 fuelCrossFeed = True CrewCapacity = 4 RESOURCE { name = ElectricCharge amount = 200 maxAmount = 200 } RESOURCE { name = MonoPropellant amount = 100 maxAmount = 100 } MODULE { name = ModuleDockingNode referenceAttachNode = top nodeType = size1 } MODULE { name = ModuleDockingNode referenceAttachNode = bottom nodeType = size1 } MODULE { name = ModuleRCS thrusterTransformName = RCSthruster thrusterPower = 1 resourceName = MonoPropellant atmosphereCurve { key = 0 260 key = 1 100 } } } Any and all help is, borderline, desperately wanted. I've sunk about 50 hours into this project and unless I can get this to work I fear all that time was utterly wasted. I suppose I can try separating the docking ports and the craft and attach them in the VAB but one of the main goals of the project is to reduce the wobbliness of large space constructions and reducing the number of joints is critical to that. The problem with that is there is no guarantee that I can get the docking ports to work that way either.

Are you upgrading from the older part tools or are you starting fresh?

Short story: my docking ports no longer work. Do I need to use the latest version of the part tools (20.0) to get the docking nodes to work in KSP 20.0+? I am still bug hunting but everything looks okay to me based on what I've read on the forums (assuming that data is not out of date as of the recent patches): -An empty named "DockingNode" in Unity with the blue Axis pointing away from the ship (or towards the incoming ship) -Module configured in CFG: node_stack_bottom = 0.0, -2.5, 0.0, 0.0, 1.0, 0.0 *snip* MODULE { name = ModuleDockingNode referenceAttachNode = bottom nodeType = size1 } Is there anything else I should look for or any other new details as of the recent patches?

Informal survey time: What are your thoughts on the latest SRB designs? I was trying to make them stand out from the crowd by not doing the classic "cone on top of a cylinder" shape and thus came up with the sci-fi inspired "nacelle" shape. I know they are a little bland at the moment so I plan on putting more effort into them but then I began to doubt the direction I have taken. So... should I stick with the current design and improve it or should I just go back to a classic SRB shape? Regardless of feedback, which I always value, I may go against public opinion. I am not sure how I want to proceed overall and wanted to see where the community was at and maybe you can help influence the direction I take.

The sample ships V-L+4 and V-L+2 were removed in the last update so it seems you are using an outdated ship file. I updated the fairings recently which breaks old ship files. Sorry for the inconvenience. As for FAR I've done some more investigation and it's not as simple as adding the word "fairing" to the configs. I have to add in the FAR module and maybe configure the drag profile as well (I hadn't researched it that far). That isn't a big deal but I need to make sure that by adding FAR functionality I wont be compromising the vanilla experience. It theoretically shouldn't since the vanilla game should ignore any code that it does not understand. However, you can never be sure without tests. The other problem is that I resist supporting other mods. If that mod changes that may force me to change my mod. That can turn into a full time job all by itself. FAR sounds like a really useful mod so I haven't dismissed the idea. I will play around with this more after I release the next project. We can try some experimental builds on the side and see if a solution can be reached.

*edit* after rereading the post above I came to realize my first response didn't make sense. Ignore.

Only the CSBs will be reviewed during the Anvil IV revamp since they are in the most dire need of a face-lift. If you have any specific feedback about the Anvil Guide I will be happy to make an effort to resolve the issues. I will need to revise the document during the revamp anyway. Of course, all of that will wait until I get the beta release of the new project out the door. I just spent the last three hours working feverishly to re-build one of my parts and managed to complete the modeling and UV unwrap of it (3000 faces so it's not exactly a simple part). The only thing remaining on that particular part is the paint job. If I can mange to keep up that pace I should have all parts modeled by the weekend. The texturing will go faster since my artistic skills are quite limited and the resulting effort will be rudimentary at best.

I think it's about time for an update and this time I have something more substantial to offer... a "release" window. I prefer to run these projects under the age old "it's done when it's done" mentality because you can never predict when something will go wrong. Say, for example, the guys at Squad completely rewrite the way certain features of the game are handled. That's entirely unpredictable (and realistic given the state of the game) which may force me to lose weeks of development time. However, I feel like I've fallen into the Engineer's conundrum where a project falls into an endless cycle of revision. Yes, it can be better but at some point in time you need to put your foot down and release it. So I am putting my foot down and giving myself a due date: Mid July I still offer no guarantees. There is always the chance something will come up but I am going to put an honest effort to get SOMETHING out by then. I recently had an epiphany on this project which really boosted my confidence in the overall design. I've been obsessed with a particular design feature and all other features were being shoe-horned into the project to make them work with it. Well, on a whim I deleted that feature out of the part I was working on and it just came alive. The SRB in my head was lit off and all systems were go. Unfortunately that also means I have to go back and tweak the other parts to match. It's another set-back but its a good one. Other future plans (in no particular order): -Revamp the Anvil IV (model, textures and config) taking into account all the feedback I've gotten on it. -Revamp my properties spreadsheets. Nobody has ever seen them and nobody cares but it's going to really help me quickly assess design properties for the Anvil IV revamp. -Revamp the SRB models and textures. -Complete new logo. I've got a concept drawn up and I have some neat ideas I want to try to make it pop. We'll see how successful I am at it. Good luck and have fun!

I was originally going to make a new post but figured that would be a waste of forum space. Instead, I will post the new project under this existing thread. Any other projects of mine would also show up here. "CORE" is my "Company" and anything I do would be a CORE project regardless of how I choose to display it. I also appreciate the patience on my progress. It's usually not a good idea to post previews on stuff like this because the project could always fail but at least this way people know I am still here and working on it. I could, theoretically, post pictures and what-not of what I have so far but I've got something more grand in mind for the reveal. I am still tinkering with the models and I have decided to leave them somewhat boring for the initial release and work on their aesthetics later. A lot of nights I sit and look at what I've got and go "BAH!" in disgust. Maybe I am over-working the problem so I am trying to push and get something out there. Maybe it will grow on me in time. The good news is that I have completed the first of seven planned parts. I still have some tweaking to do but that involves a trivial amount of effort compared to the rest of the SOW. The other 6 parts are in various states of completion and they are getting closer and closer every day. Barring any hiccups or bouts of self-disappointment I think I can mange to complete number 2 tomorrow and maybe even 3 if I get on a roll. I offer no promises and I offer no hints at a completion date. Sorry.