mcortez

lol, I called it quits and decided to post for help when I started playing with the idea of trying to brute force a solution -- basically creating a node with the correct Dv (which I can calculate knowing just the inclination change needed), and then moving the UT of the node until the Node's orbit had the correct Longitudinal Ascending Node... I figured dragons, demons and all manor of bad things were hiding along that path. The old kOS code that I copied from someone else, somehow takes the LAN and Inclination of the target, and the LAN and inclination of the active vessel and "converts it from spherical to cubic coordinates", throws in a vector cross-product, sprinkles a little arctan2()'s on top, and finishes it off with the active vessel's LAN and Argument of Periapsis to somehow come up with the appropriate True Anomaly of the appropriate place to do the inclination burn. But when I tried to convert the code from kOS, it didn't work. I'm not sure if it's because I messed up somewhere, or if it's a "right handed vs left handed coordinate issue" or what. Seeing as the last time I used sin/cos/tan and radians to solve a problem was more than two decades ago, I'm not really even sure what the Va, Vb and Vc are doing in this code snippet: // incl_i & lan_i - are the current inclination & LAN of the active vessel // incl_t & lan_t - are the desired, new inclination & LAN, which can be taken from Target's Orbit information // setup the vectors to highest latitude; Transform spherical to cubic coordinates. local Va to V(sin(incl_i)*cos(lan_i+90),sin(incl_i)*sin(lan_i+90),cos(incl_i)). local Vb to V(sin(incl_t)*cos(lan_t+90),sin(incl_t)*sin(lan_t+90),cos(incl_t)). // important to use the reverse order local Vc to VCRS(Vb,Va). //compute burn_point and set to the range of [0,360] local node_lng to mod(arctan2(Vc:Y,Vc:X)+360,360). local node_true_anom to 360- mod(720 + (obt:lan + obt:argumentofperiapsis) - node_lng , 360 ). I'll try and do another conversion tomorrow. I *think* all I should have to do is replace the 90's with (Math.PI/2), the 360's with (Math.PI*2), and the one 720 with (Math.PI*4). I couldn't remember how to do the Vector Cross-Product, and one google result said to use the following: double x, y, z; x = v1.Y * v2.Z - v2.Y * v1.Z; y = (v1.X * v2.Z - v2.X * v1.Z) * -1; z = v1.X * v2.Y - v2.X * v1.Y; Which honestly, I have no idea if that's correct and if it matters if it's supposed to be a "right handed" or "left handed" coordinate set.

I know this isn't strictly kRPC related, but more orbital mechanics - but was hoping someone would take pity on someone that hasn't dealt with spherical math in 22 years. I'm using kRPC, C# client, and am working on a program to change my LAN and Inclination to match that of a Targeted Celestial Body that's orbiting the same Celestial Body as my Active Vessel. As a warm up, I worked on zero'ing out my ships inclination in preparation for changing my orbit to match my target's. And I was able to get that working with something along the lines of: var ksc = conn.SpaceCenter(); var vessel = ksc.ActiveVessel; var orb = vessel.Orbit; // Calculate the True Anomoly of AN and DN double taAN = (2*Math.PI) - orb.ArgumentOfPeriapsis; // Inclination change needed double incChange = -orb.Inclination; // Calculate node values double eta = orb.UTAtTrueAnomaly(taAN); double dv = (2 * orb.OrbitalSpeedAt(eta)) * Math.Sin(incChange / 2); // Split the DV change across normal and prograde double normalDV = Math.Cos(incChange / 2) * dv; double progradDV = -Math.Abs((Math.Sin(incChange / 2) * dv)); vessel.Control.AddNode(eta, (float)progradDV, (float)normalDV, 0); My problem now is that I need to know the True Anomaly along my orbit for the Ascending Node for my Target (or more specifically, just the UT of when I'll reach the AN.) If my target was a vessel, I could just use the following and call it a day: taAN = orb.TrueAnomalyAtAN(targetVessel); incChange = orb.RelativeInclination(targetVessel); But after several hours banging my head against the kRPC API docs for Orbit, and Robert Braeunig's orbital mechanics pages, and trying to convert some old kOS code I had that did the same thing ( originally based on the code from here ) - I've found a very large number of ways to not find my the needed values. At this point I suspect I'm missing something simple.

Thanks for the link drilling down into the repo. I had gone to the releases page of the constellation, here: https://github.com/BobPalmer/USI_Constellation/releases/tag/2107.12.10 Where for some reason I thought the change logs we're automagically brought together by RD's deployment scripts. For anyone else that comes across this post, - the change logs are individual files, inside the mod folders in the constellation source - rather than gathered up on the release page. Cheers and rock on!!

I seem to be completely failing to find the changelog for the Warp Drive. I see a lot of discussion of Helaeon working on it back over at https://forum.kerbalspaceprogram.com/index.php?/topic/90899-13-alcubierre-warp-drive-stand-alone/&page=52 but I didn't see a changelog -- it's possible I just scrolled past it though :-/

There it is, turn on Juicer, insert Kebal on top, get supplies as output ... Wasn't there a little yellow triangle sign with those instructions on there somewhere.. Oh, what?, you say that's a warning sign of what not to do? Bah...

Just my 1/2 cent thoughts on possible wear/failure mechanic. I liked the half-life concept, especially if there was a way to know that half-life value prior to launch. As each half-life expires, you have a chance of failure - this chance perhaps doubles at each half-life. Half-life would be no less then 3 months (similar to Spirit & Opportunity, designed to last at least 3mo ended up lasting much longer.). Also, if possible, there should be a disabled (powered down) option. This renders the part in-operable and freezes the threshold timer. This allows you to take built-in a spare or backup, in case your primary fails. If you're feeling particularly sadistic, you have a chance of failure on initial power-up. Chance of failure would start at something like 1/2 to 2 percent. I like a doubling scale at each interval since things can get rapidly bad for parts well beyond their designed lifetime. Doing maintenance, which consumes a resource, resets the part back to "launch" state. So chance of failure at the next half-life goes back to original value, and the half-life timer resets to zero/Now(). Maintenance could be automated via a crewed part. Optional: future pack of robotic parts that let's you send out a maintenance robot/probe/ROV that is uncrewed but has manipulator arms/claws that can do maintenance. You could even ship out such a ROV already attached to a deep space exploration vessel, so you can do maintenance during transit - vs having backup parts attached and powered down. Failures would come in multiple varieties, with players able to enable and disable all possibilities via MKS config screen. 1. Catastrophic failure. Part explodes. 2. Critical Permanent failure. Part ceases to function and cannot be repaired, must be replaced. 3. Critical Repairable Failure. Part ceases to function, can be repaired via maintenance, requires a large amount of resource. 4. Partial Failure. Part's efficiency is reduced by a percentage. If implemented for parts without an efficiency, their function is reduced in some other way - for example storage parts could either have their input/output rates reduced (not sure if the resource system allows for this) or their storage capability reduced (like batteries that have had too many charge cycles.). Depending on how this is implemented, it could be a fixed rate of reduction (50% each failure) or random. If the failure possibilities are configurable, people can play without them, or if they like to live on the edge they can risk explosions. Default might just be the efficiency and repairable options. I can't decide if I like a flat/fixed chance of each failure type or if I like stacked. Flat: at each half-life, check to see if the part has a failure. If it does, then check against a fixed chance 75% efficiency failure, 15% critical repairable, 9% critical unrepairable, 1% explodes. Stacked: each failure type has an initial percentage at launch. At each threshold a test occurs against each active failure type, and then all the percentages increase for next half-life. Lastly I would suggest a new resource "Quality", available only at launch and not adjustable in flight. If possible this resource is used to modify the initial values "at launch." They could either (whichever is easiest) change the half-life rate, or the initial chance of failure at half-life percentages. This way you can make a design choice at launch to pay for a high quality part that either has a longer "designed for" / "warranty" period (larger half-life) or has a lower chance of failure at the first threshold point. Optional: In Situ upgrade between quality levels, or perhaps ability to repair/maintain with lower quality or jury-rigged parts (uses less maintenance resource) Why do I suggest this system: 1. Configurable failure types let's players decide how they want to play. 2. Very well known, easily predictable wear/failure mechanic at launch until first half-life. IE: no chance of failure during warranty period. That way you know exactly what the output rate is until X months, and that you know you have that long to get someone on site to do maintenance. 3. If implemented, the partial Failure with fixed efficiency loss, allows for you to do statistical modeling. You might know for example, that a part has a 50% chance of failure at it's half-life, so include two and then make contingency plans for having 200%, 150%, 100% depending on if they both keep working, one fails or both.

I missed today's stream, but I skimmed the recording and I'm really looking forward to the Kerbal Juicer.

The future is domes, monorails, and either railguns or space elevators (depends on whether or not we can make something like carbon nanotubes work.) From a game perspective, I'd love to see some stupendously large modules that are domes that can only be built in-situ. Basically 5 or 10m parts, possibly with 6 or 8 connection points. These would also probably need some kind of built in clamp functionality otherwise they'll be kraken bait. Space elevator / railguns would all be about moving things from surface to orbit. I could see a space elevator being implemented as a pair of parts, one that goes into geo-synchronized orbit and one that goes on the surface. As long as the geo-synchronized part is within a few degrees of being "above" the ground station then you allow transfers. Railguns I'd see as requiring you to dock a rail canister, which is a configurable resource container - you then specify an orbit height, and it calculates an EC cost. The cargo container then goes *poof*, EC is consumed and the container is placed in orbit waiting for another ship to come along and pick it up. Landing pads could possibly be used in the reverse. You get into orbit, and if you have sufficient fuel you can select a landing pad and the vessel is teleported there (or disappears to reappear there after an appropriate period of time.) Landing pad also functions as a specialized docking clamp and vessel is oriented so that it's "landing pad clamp part" matches up with the landing pad. These transportation parts would be about shifting the game from the adventure if nail-biting precision landings while base building, to making logistics transport "mundane and routine" and shifting play to orbital construction and "truck or bus driving" resources or colonists between locals. I could easily see myself spending hundreds of hours bootstrapping a colony on Minmus to make it easier to build an Ark ship in Minmus orbit to go to Duna, which upon arrival I would have the harrowing experience of landing enough equipment to keep my Ark ship alive while also building a colony on the surface.

Just describing my play style as someone that's used USI & EL/Workshop for a while now :: When I land (or crash) supply or expansion missions at an existing base, I often spend quite some real-life time (anywhere from 5 minutes to 30+) going around my recently landed vessel to disassemble various bits into Material Kits and using KIS/KAS to reconfigure things for use on site. In many cases the fact that I'm getting material kits from the stuff I remove is actually a bonus -- I'm usually not relying on it to actually provide enough materials to build anything specific. This process is fun and part of my play style, but can be a bit tedious on occasion -- especially when for whatever reason my physics tick slows down and I'm eager to "get on with" whatever I was actually trying to do. This is particularly true when dealing with Space Station or Exploration Vessel construction in orbit, where the recently arrived vessel may not have the option of docking until I take care of these house keeping efforts -- all the while, it's slowly drifting away from from my station or construction site. Adding in some kind of time delay to these processes would probably not really add to the play value -- for *me* -- and could make those times that it has become tedious to be even worse. -==- Now occasionally I do have an entire vessel that is no longer needed - and I specifically do want to recover every bit of it I can to work on a new vessel or expansion. In these cases, I usually manually tear the vessel apart with KIS/KAS and store each part I know I'll need later, then demolish the rest back to material kits. If I somehow had the option to auto-magically start a process that scans through the parts tree of a vessel and automatically recovered all the parts that could be used as-is in some new construction, for example -- if I started construction of new Vessel A, and while that vessel is being constructed I did a "Recover parts for use in new vessel" command. And that command not only reduced the materials cost of the new construction, but sped it up -- *that* would be awesome. But if all it did was spit out material kits at a slower rate, but with a higher return -- I suspect I'd just make sure my construction crew had enough supplies and would time warp through it -- even if that might awaken the Kraken and other annoying bugs due to time warp catch up.

I suspect there's a difference of opinion on "have to" or "need to" and can safely ignore. Like goldenpsp, many of us have used the USI mods without issues by simply downloading the latest constellation zip, and installing AVC. Then when prompted by AVC, or when we see a new update posted we simply overlay the updated mod over our existing install and then it generally "just works." It's great that you've documented a bunch of the errors going to the log file, and the appropriate place to report them so that RD will see them would be in the various git repository bug trackers. As for the module dependency bits, it's generally safe to use MM without them -- but if you know how to correctly add them, you can do a pull request against the develop branch of the appropriate repository and RD will likely include them in a future release.

I'm at work at the mom with limited access, but if there isn't already a "tips" page on the wiki -- it might be helpful to document this terrain detail tip, and the rescue pod validator mods in there.

I've experienced this in the past but it was believed fixed in a recent version of USI-LS. If your save is just stock plus USI mods, posting a copy so RD can dig into it would be very helpful.

I'll leave the why / why not out of it. To answer your question, it would be fairly trivial to make a converter part. You could simply copy the part config for an existing part that converts one resource into another and edit the input and output resources.

Thanks to you both for the quick reply. I've always found the KSP community to be particularly mature and generally civil when communicating with members or asking Mod creators for new features or support. The occasional member that posts what might be a considered a rude note either due to English not being their first language, or because they are trying to be particularly vehement in their their post is usually quickly steered by the other members in a thread to a more polite, constructive feedback path. I feel in some part that is due to the diligenent and mostly thankless job of the moderators. I thank you for all you do to keep things running smoothly. But last night seeing both a very rude post and seeing that it was made by a moderator, brought me cause to look for the report mechanism for the first time. I kept looking for something with the word "report" in the interface and I completely missed the little Flag link. Thank you again, and have a happy New Year!!!

Is there someplace where unacceptable posts by users can be reported? Same question, but for when moderators themselves make posts that violate forum rules?

You could submit the feature suggestions to the github bug tracker. It's possible to comment on there, and it keeps it out of the way of the main forum thread.

Needing a bit of help with what "Multi-Weld" is used for. I had thought it was to be used when you had multiple docking ports that needed welding at the same time, for example when using multiple docking ports to attach too vessels together. But it doesn't seem to do what I was trying to do -- and perhaps what I'm trying to do just isn't supported. As they say, a picture is worth a thousand words, so: Basically I flew in a second vessel and got two sets of Construction Ports to kinda sorta dual dock. Basically of the pair on the left, the top one is giving me an "Undock" option -- implying that pair is docked, and of the pair on the right the bottom one is giving me an Undock option -- again, implying that they're docked. If I try to Multi-Weld or Compress Parts and align -- what happens is the two ports on the right go poof, and a hard connection is made there. Of the two on the left, usually one port seems to go poof, but the other port stays and jams up the process, resulting in just one docking port remaining and being stuck between the crew module and the Tundra Hub. Sometimes it's partly embedded into the Tundra hub. If I go over with an Engineer and remove the extra port, I'm then left with a sizable gap the side of the one port. This is rather similar to the situation I saw on the KSP-TV stream about a month ago, with trying to assemble the ring in space using multiple docking ports. -- What I'll likely end up having to do, is split the vessel on the bottom in half at the RCS tank and then dock/compress the two halves separately -- unless anyone here has any good suggestions?

I had something similar happen to me. I had a station in Kerbin orbit with 3 crew members on board that I de-crewed and abandoned while focusing on sending a couple of probes out to Duna for science. After my probe science missions were complete, I went to recrew the station. As soon as my shuttle with a full 2.5m supplies tank on board docked with the station, it instantly emptied all of the supplies in my shuttle and all my mulch was maxed out. I also had a nom-o-matic 25000 and a 79% recycler on the station. My shuttle had no recyclers or agro since it was only intended for short hops up to the station. When all the supplies were consumed everyone went grumpy (tourist). I just ended up sending up a second shuttle with more supplies to top off the station. Then things returned to normal.

I can also confirm this happening, quite a bit of log spam.

Everyone else gives boring commerce sales this weekend, we get exciting patches !!! Goooo RoverDude !

At the top of this page, there is a link to the Wiki for USI-LS. There is also the MKS github page, which has a more extensive wiki that attempts to cover all things MKS including life support. https://github.com/BobPalmer/MKS Note: Much of the wiki is now out of date with the release of 0.50 of MKS when KSP 1.2 was released. You can use the documentation to get a feel for what is happening, but the specific numbers may be off. If you see something that you know is wrong, and you know what the right value is -- please, Please, edit the page. Anyone with a github account can edit these pages and contribute. Don't worry about feeling like you might be stepping on someone's toes -- it's a group effort.

That seems to have fixed it for me.

I am getting similar results with my docking port cams -- black screens on activate. Also Windows 7/64bit -- although I run KSP as 32.

Which that was the only problem, after enabling the Roll slider, my parts spun around multiple times -- so whatever rotation point they were looking for was passed more than once. It was just a high level of frustration - I haven't yet had the opportunity to retest. Still stands that something broke at some point, where I lost all attractive forces and wouldn't even draw ports together anymore. In your persistent.sfs file you can search for parts where it has name = ConstructionPort1 and change it to something else, like dockingPort1 -- although you do this at significant risk to your save file. Changing the file in the wrong place and one or more vessels will fail to load and be removed from your save completely. Make sure you have backups of all relevant files before messing with them.

Compress with rotation is there, although since they never docked that didn't help. Behavior basically went like this: approached fine, got magnetic pull as normal, but they just bumped but wouldn't latch. Moving the sliders around appeared to put some torque on one or both halves, too much slider and things would spin/twist or otherwise move with enough force to cause collisions. At one point I did try and change snap to 90 or 180, but that didn't help. Interestingly enough, I'm not sure at what point this happened -- I think it was after hitting the "Reset Acquire" or a button labelled similar to that, all docking ports on both vessels seemed to lose their magnetism -- even if I backed away 10m and re-approached.. That's when I gave up and edited the save file to switch to dockingPort1 -- which worked without issues. I'll experiment more over the weekend, as station building is one of my "fun" activities Thanks for everything you build RoverDude, I don't play KSP without USI.