Dunbaratu

The navball already gives you this information, indirectly. The point at which the yellow prograde mark is farthest off from the equator (90 or 270 degrees) will be the point at which you are crossing the equator, because your path drawn on the surface of the planet is a sine wave who's slope is greatest when crossing the zero line, so the point of crossing the equator will be the point where the deflection of prograde from equator on the navball is at its peak. In other words, imagine if you take your compass heading from the navball and over a period of several minutes you see it doing this: heading 90 heading 91 heading 93 heading 96 heading 100 heading 115 heading 117 <-- Max deflection away from 90 degrees. Because it's a deflection in the southerly direction, it's is the descending node. The inclination is about 27 degrees (117-90=27). heading 112 heading 98 heading 95 heading 92 heading 90 heading 89 heading 86 ..

Except that I'd tried that solution many times before and it never works. The kerbalnaut just refuses to move onto a ladder facing 90 degrees off from the one he's currently on.

I am assuming there must be other changes I don't know about since I stopped when I hit that first problem and wasn't able to see what else may be wrong without changing my code which I'm not willing to do because it requires a re-write. There are a lot of pull requests on github that are still the matter of debate, and I didn't want to use a version that might have them in it. What is missing that would be required to make this a generic solution is the ability to iterate over all the variable names. You can't do a thing like: For each variable that exists do a thing with that variable. You instead have to hardcode the name of each and every variable you want to check, at which point there is no point in checking them - you just hardcode to zero out the ones you know will hold big values or strings. I don't consider this a viable solution either because of the pointless extra lines of code it requries. Because you have to name each variable you're going to zero out individually there is no generic terse solution.

This is NOT a working version. It fixes one problem and introduces others. It broke the ability to make comparison tests against literal strings, requiring the addition of pointless extra lines of code to replace all such instances with comparisons against string variables. Since my code happened to be near the 10k limit already, and has a lot of comparisons to literals, this is a nontrivial change to make, and its a rather bad idea to make that change for a thing that is clearly a bug introduced by somebody's recent edit of the code.

I think the suggestion needs to go even further. Not only should you be able to do this with a dead battery but it shouldn't even require any command core at all. The naming of space objects is a thing people on the ground are doing. We name asteroids and comets sll the time. They don't have commmand cores

I think you misunderstood what I meant. It would be stupid to have to wipe a seismograph to reuse it. I didn't mean I want consistency in what needs wiping. I meant I want consistency in the lab's ability to act as a storage of the data so the device can be reused without losing the science. Right now a lab lets you use one material bay to do many experiments and carry back the data from all of them in the lab. But it won't carry back data from a thermometer or seismograph. Those science points are still stored in the measurement device itself and can't be moved into the lab. If you want to score the full points by returning instead of just transmitting you have to use the measuring device just once and then bring it back rathrr than storing it in the lab and bringing the lab back. And that's the inconsistency I meant. the lab stores data only from material bays and goo cans and not from anything else.

Are you sure that's the fault of incompable mods? I got that exact behavior from the kos terminal as soon as my Ksp got updated to 0.23 but I hadn't tried updating kos yet.,

With the idea of a small boot script embedded inside the description text field, What is the intended behavior when there exists more than one computer part on the vessel? Do all of them get the BOOT file and run it? Does just the first one? How does the player determine which is going to end up being the first one?

You're right, now that I re-read the post by erendrake. It wasn't clear to me what was meant by that the first time I read it. For some reason the meaning didn't click until Razark's post, so I thought his was the first suggestion of it.

Well, I don't consider a number the mod is communicating to the user to be "inner workings". If it's being told to the user the presumption is that the user is supposed to know what it represents and I assumed people who'd been users of it all along would know, especially if it's being used to judge the contest, thus the question. Wanting to know the algorithm used to calculate it would be "inner workings", but just wanting to know what it actually means isn't. (EDIT: ninja post by tavert while I was composing, rendering most of what I said after this moot). Thank you for the relevant answers, tavert. The only remaining question is whether it just ignores the gravity well altogether when making the calculation. (When climbing from a gravity well into orbit you can't get nearly as much dV as you could when already in orbit, because when already in orbit you can treat the burn as if it occurred at a single instant in time, but when climbing that assumption breaks down and the fact that you spent a lot of that burn fighting against gravity as you slowly got up to speed causes "wasted" dV, and in effect this challenge is all about trying to minimize that as much as possible.) So is it saying if we pretended there was no wastage from slowly fighting a gravity well and the craft was just floating freely in interstellar space all by itself, this would be the dV it could achieve, or is it saying its the dV it would get from an optimal gravity turn, which is less than that?

That's a good point if the boot process looked at the description every time the vessel loads from on rails, but I was picturing it being a thing that only occurs during initial deployment, like so: During initial loading to the launchpad or runway: - If there is a BOOTSTART/BOOTEND section in the description, make a local file called BOOT on the local drive (*) and fill it with the contents of the BOOTSTART/BOOTEND section. - run BOOT. During any other time the SCS module is booted besides that initial load: - just run BOOT - don't rewrite it from the description. Basically the description would just be a way to get around the "local volume always starts empty" problem, as a means to pre-populate a small BOOT program onto it.

Case 2, which you were promoting, would only be fewer steps if there was a way to pre-populate volume 1 with a boot program. But since local volumes always start off empty until you copy things onto them, by the time you copy a boot file onto the drive, the time during which the boot would have executed (at least on the launchpad) has already passed. The local drive will always be empty when the vehicle is first put on the pad. So you still have to copy the file to the drive manually, and you still have to kick it off manually (since the boot already happened), so it's complication that adds literally no additional functionality and still has just as many manual steps. Then why promote the version that requires the file to be local? That's exactly what you'd have to do if the boot loader only runs off the local drive. I hadn't thought of that idea until razark made that small post suggesting it, which happened after the post by me that you were responding to.

But there's also the 3D mesh description. That's copyrightable content as well but the license terms aren't mentioned.

I always thought that the easter eggs would be best reserved for use with the as-yet unimplemented money system. The idea would be that they generate massive public interest and therefore funding.

This is by far the most elegant and flexible solution anyone has proposed. Make use of the description field in the VAB to create your boot loader. Embed some syntax in it that marks "start of boot loader" and "end of boot loader" and have the mod read the description and copy that bit to your local drive as BOOT.txt and run it. If you sentinel the kOS code with a start/stop keyword around the code section, you can still use the description for the human readable text too. For example, your description field might look like this for a craft with a custom boot for just that craft: This is a craft that I'll use for the Mun and Minmus. It is kOS capable and has the following action groups: 1=atmosphere stuff (panels, chutes) 2=emergency escape tower BOOTSTART. print "press AG9 to give control to kOS". wait until AG9. copy loadMunMission from archive. run loadMunMission. run doMunMission. BOOTEND. Other notes: If you fly manually instead of using kOS, beware that using full throttle during early ascent tends to waste fuel as the design is a bit overpowered and exceeds terminal velocity. Or it might look like this if you don't have a custom boot and instead use some generic one for all your craft: This is a craft that I'll use for the Mun and Minmus. It is kOS capable and has the following action groups: 1=atmosphere stuff (panels, chutes) 2=emergency escape tower BOOTSTART. copy genericboot from 0. run genericboot. BOOTEND. Other notes: If you fly manually instead of using kOS, beware that using full throttle during early ascent tends to waste fuel as the design is a bit overpowered and exceeds terminal velocity. Remember that if you change just a few things about a craft and then save it under a new name, like if you have "myMoonLander1", "myMoonLander2", "myMoonLander3", and so on, that the description field is part of what you inherit from the earlier version of the craft, so you would inherit the boot loader behavior when you make a bunch of slightly different craft this way, solving both my and Camacha's needs with the same solution. Also, people wouldn't be surprised by accidentally triggering unexpected behaviors by happening to choose program names used by the boot loading process. This VAB description technique makes it so that the only way you get boot loader behavior is if you know the feature exists, and deliberately type in the right stuff into the description field to use it. It also has the advantage that when sharing files with others for the sake of showing how you ran a challenge mission, you don't need to have manual instructions for exactly what to run to get it started - that would be something that's embedded inside the vehicle's craft file. This is a very good solution all around. Do you know if the c# code in kOS can query the vessel description field and read its contents?

This is no fewer steps than just not even having a boot program and copying some arbitrary program manually. Then why are you promoting one that is more complex? With what you're suggesting doing, its more complex than what I suggested.

While it is possible to reverse engineer something to work it out the meaning of a number, by trying again and again and again using lots of trials with slightly different setups and recording the results until a pattern emerges, it's also an utter waste of time if it's already known. In this case it must be already known to at least some people, since the number is the result of humans making software. Take your own advice and think instead of being condescending.

If you're bringing the lab back to Kerbin you still have the advantage that it can store the data of experiments from one reusable lander. One lander with one material bay and one goo container can't run 4 different experiments with them in 4 different locations. But one such lander combined with a lab in orbit to dock with CAN, because the lab will store the science results each time you dock with it, and then allow the lander's experiment pods to be wiped and re-used without losing the science points. I just wish it was consistent about that. It works with goo pods and material bays but not with gravioli detectors, seismographs, and so on. (the fact that those are normally re-usable anyway does not mean there's no value to storing their data in the lab so you can re-use them without losing it.)

One potential legal hurdle to doing a fork is that while the licensing terms of the C# code are explicitly mentioned, there are also the part definition files to worry about (the SCS module's texture and mesh files and config file) and they're not in the github. Their licensing terms are unmentioned (and when it's not mentioned the default is that you can't do anything with it).

Trying to optimize a thing requires knowing how it's being measured. Otherwise it's just guesswork. Knowing how to count the score doesn't mean knowing what tactics would work to make the score better. That requires knowing how those numbers are being derived.

But that has the opposite problem. If you have one start script appropriate to one kind of craft and another appropriate to another kind of craft you can't separate the two in your archive because they have the same name. There seems to be code attempting to do this already in kOS but it doesn't seem to work. At the moment it's hard to tell whether or not this is just because of the variable context loading bug or if there's other reasons it doesn't work. But it does seem to be trying to pick up where it left off when the craft reloads.

I suspect it will work if you make a string variable first: set str to "Mun". if encounter = str {print "Mun encounter".}. It's only comparing to a literal string that broke.

"Mechanics" is entirely too vague of a term to be meaningful. It covers pretty much everything. Besides when you recently locked a thread for suggesting rotating docking rings you cited the word "robotics' not the word "mechanics" as the reason.

The original creator and admin of the kOS mod has utterly stopped communicating with the user community for over a month and after a while when asked if there was anything causing the absence, he only gave one rather cryptic response that he's dealing with some personal issues right now, but he didn't answer the question about what his plans for the future of the mod might be and whether he wants to take a break and come back to it later or give it over to someone else to admin it. The mod's code is released under GPL so legally anyone could take it and fork a new version of the mod. Normally, though, I'd rather give the original writer more chance to deal with personal issues and take more time before trying to hijack a project like this. Just waiting 1 month is a bit short and impatient. But what has forced the issue is the fact that the release of KSP 0.23 requires changes to the mod's code. At the moment any new users trying to pick up the mod can't. Unless they have a version of KSP 0.22 around they're out of luck. The inability to ask the author if he'd like to come back to it later, combined with the fact that the 0.23 update broke the mod, means people in the user community are starting to provide their own splintered forked compilations of the plugin DLL, not on Spaceport, but on their own personal shared cloud drives. There are a number of personal forks of the project on Github and a number of pull requests for getting some bug fixes back into the main release of the code, but with the original project admin gone, they're going unanswered and nobody else has the authority on github to bring the pull requests into the master branch. So it's looking like the time may have come for the user community to fork a new "official" branch of the code, put it under someone else's control, and release a sort of "community-made" release of the project. Legally, given the open source license that was used, this should all be just fine. But I'm also concerned about politeness to the original author, and proper respect. Hijacking a project feels a bit rude. Have there been other mods that have had the user community take this step, and if so, what is the mechanical process involved? In order to get releases onto Spaceport, does the forked mod need a new name because the existing Spaceport page for it is owned by the original author?

The other reason for me suggesting a name change like DR-kOS is so that releases can end up on Spaceport. As it is, I don't think anyone other than Kevin can change what's on the Spaceport page for kOS, but if this was a second project with a new name, it could have its own new Spaceport page.