mcortez

Members
  • Content Count

    141
  • Joined

  • Last visited

Community Reputation

77 Excellent

1 Follower

About mcortez

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I haven't played KSP in ages, and I miss your streams! Hopefully my schedule will line up so I can catch this! And all I could think of when I saw the 2.0 announcement was, I hope RD got to work on it, I hope RD got to work on it, I hope RD got to work on it -- because that would mean it would be awesome
  2. Yes. A great many of the MKS parts don't have IVAs, as they can take a lot of time to build. Rather then spend time on them, RD concentrates on adding new parts and functionality in is limited free time.
  3. Yes, steam specifically supports pinning KSP to certain specific milestone versions. For example I belive I have mine pinned to 1.4.5 Right click on KSP in your Steam Library, select properties and then I think Betas tab. There should be a drop-down menu that normally has something like "NONE - Opt out of all beta programs" If you click on that drop down you should be presented with various milestone versions of KSP to pick from. Doing so will lock down your version nof KSP to that version. Make sure that you then install matching versions of any mods you use.
  4. One common cause of this can be a combination of insufficient power generation and storage, and the way the game's catch up mechanics work. A vessel (or base) is not simulated when not within focus distance of the current vessel. When you return ti the vessel, the game does accelerated simulation of the vessel in, I believe, 6hr chunks until it is current. Again I believe, it does this using the current conditions of the vessel when you return to it. If you rely heavily on solar power, and have insufficient battery storage, then its possible if you return to the vessel at night or while the sun is occluded, then when the game does its catch up it will be doing so with minimal power generation. That could lead to the parts running out of power and turning off.
  5. A Constellation release, is a bundle of all of Roverdude's mods packaged together for a single easier install. There is nothing different from the standard MKS, USI-LS, Sounding Rockets, Malemute, etc, etc -- other then instead of shipping as separate awesome stars they're made available as a single Constellation bundle. The individual mods will also be available. Thr constellation bundle is not updated as frequently, as the individuals as its extra work.
  6. It's possibly out of date, but you might want to start here: https://github.com/UmbraSpaceIndustries/MKS/wiki/Supporting-MKS-in-your-mod I know there also used to be a Google Spreadsheet floating around for this, but a quick search through my bookmarks failed to find it.
  7. You're trying way too hard. All of the Kontainers should also work, just make sure they're properly configured for the right type of storage in the VAB. There are also some EVA explosives available for taking out whole ships in a single go - you'll need KIS & KAS, so that you can pack the explosives in your ship and then attach them during EVA. https://github.com/UmbraSpaceIndustries/USI_Core/blob/master/FOR_RELEASE/GameData/UmbraSpaceIndustries/Kontainers/Kontainer_01.cfg
  8. I haven't done any comprehensive testing, but my re-implementation today worked on the first test - which is a lot better than I had yesterday. For anyone else trying to accomplish the same thing, here's my current code: // Create a note for the Active Vessel, which currently has an inclination of 0, to match the inclination of target body // // Adapted from G_Space's code at https://www.reddit.com/r/Kos/comments/3r5pbj/set_inclination_from_orbit_script/cwnhg5f/ // Also using System.Numerics.Vector3 var vessel = ksc.ActiveVessel; var orb = vessel.Orbit; var targetBody = ksc.TargetBody; Vector3 Va = new Vector3((float)(Math.Sin(orb.Inclination) * Math.Cos(orb.LongitudeOfAscendingNode + (Math.PI / 2))), (float)(Math.Sin(orb.Inclination) * Math.Sin(orb.LongitudeOfAscendingNode + (Math.PI / 2))), (float)(Math.Cos(orb.Inclination))); Vector3 Vb = new Vector3((float)(Math.Sin(targetBody.Orbit.Inclination) * Math.Cos(targetBody.Orbit.LongitudeOfAscendingNode + (Math.PI / 2))), (float)(Math.Sin(targetBody.Orbit.Inclination) * Math.Sin(targetBody.Orbit.LongitudeOfAscendingNode + (Math.PI / 2))), (float)(Math.Cos(targetBody.Orbit.Inclination))); Vector3 Vc = Vector3.Cross(Vb, Va); double node_lng = (Math.Atan2(Vc.Y, Vc.X) + (2 * Math.PI)) % (2 * Math.PI); double node_true_anom = (2 * Math.PI) - (((4 * Math.PI) + (orb.LongitudeOfAscendingNode + orb.ArgumentOfPeriapsis) - node_lng) % (2 * Math.PI)); double incChange = targetBody.Orbit.Inclination; // Calculate node values double eta = orb.UTAtTrueAnomaly(burnTA); double dv = burnDirection * ((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);
  9. 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.
  10. 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.
  11. 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!!
  12. 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 :-/
  13. 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...
  14. 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.
  15. I missed today's stream, but I skimmed the recording and I'm really looking forward to the Kerbal Juicer.