Dunbaratu

Weissel, stop trolling. Pretending that you "won" because others are sick of putting up with you is a common trolling tactic. Pretending that your questions haven't already been answered just so you can keep asking them again when they've already been addressed is another common trolling tactic. Just please stop derailing the topic with a pointless terminology claim. Be an adult and just let it drop.

The main reason that old low "resolution" encryption methods aren't good enough today is that modern computers can brute force their way through solutions quicker. But if you're trying to talk to something with a lightspeed delay involved the speed of your computer isn't the limiting factor. You're not going to be making 1,000,000 attempts per second to hack into a device with a round-trip time of 8 minutes, or even one of just 0.1 seconds. The other problem is that you can't hide your break-in attempts inside massive internet traffic to camouflage what you're doing. Someone beaming data at your craft from a different location on Earth is more out of the ordinary than someone trying to log in to your server. It would probably be easier to get to the craft indirectly by first breaking into the ground control system and then using it to direct the craft.

Ah. Another feature I didn't know existed. I understand that they don't want to write the tutorials until the changes are done but sometimes it gets a bit frustrating that a lot of the UI is a matter of trial and error.

Agreed. The constant use of the disingenuous technique is a clear sign that the goal is to lengthen the argument rather than have anything conclude. I'm willing to argue with someone who I think genuinely believes a contrarian thing. But I'm not willing to waste the time arguing with someone who I suspect might be pretending to believe a contrarian position just to be abrasive rather than genuinely believing it. And it doesn't matter anyway. kOS works exactly like it works regardless of what it's called. I'm glad to have learned from weissel that kOS behavior had changed since I last tested it, even though I do not agree that this behavior is what the word "multithreading" actually means.

Anyone arguing that time-based experimentation shouldn't be in the game would bolster their argument better if they also addressed those things that are causing a lot of people to want time-based experiments. The chief reason for wanting time-based experiments is that it seems to be the most obvious way to make satellites, space stations, and rovers actually meaningful. So to argue why there should never be time-based experiments, you do that best by coming up with other ways to reward the player for implementing a good satellite, space station, or rover. If the fact that those are currently useless without time-based experiments is ignored, then you're selfishly ignoring gameplay other people like and looking for a solution that only makes you and you alone happy. For one suggestion, some type of distance-travelled requirement for certain experiments would be handy. i.e. for mapping experiments, make it care more about how much ground is covered rather than how long it took to do it (i.e. a low orbit accomplishes it faster). For a rover experiment, require X number of kilometers of travel in Biome Y to obtain science, and so on. And make them have a max science cap like any other science biome return value does. In other words it's not "you get X science points per Y kilometers travelled, up to infinity if you warp long enough" but rather it's "There are a max of 100 science points obtainable via rover traveling in the "Mun Farside Crater" biome. Once you've mined them out you can't get any more in that location."

That's still a huge difference. Real multithreading doesn't guarantee anything about how nicely interleaved the threads will be. Maybe on one run you happen to switch between thread 1 and thread 2 letting each run one line before context switching, and maybe on the next one you get 2 instructions in a row from thread 1 before it goes over to thread 2. The guarantee of one line from 1 followed by one line from 2 followed by one line from 1 and so on is very unlike multithreading. In real multithreading if there's points where the threads must have their behavior synchronized in order to make the algorithm work, you have to work out a handshaking system between them to make it happen. You can't rely on a perfect line by line round-robin. In other words, with actual multithreading, not only do the threads run at the same time, but they run at *their own independent speeds* as well. The scheduler may use lots of strange esoteric criteria to pick which one runs faster, and you're not meant to write code that makes any assumptions about how that will work out. In actual threading, if one thread is running a statement that's time consuming and slow, the other thread might have executed several statements in the meantime. They don't nicely interleave one to one.

All science points should be made to be transferrable between craft so that this sort of thing works better. That's my opinion.

It could be implemented using a pseudo-compile pre-parse model like a lot of modern "interpreted" scripting languages use. In this model, it behaves like an interpreted language in the sense that a user directly "runs" the ASCII source code without making a binary code version first, but what the "interpreter" actually does when you run it is take a first pass through the entire source code of the program before it starts doing anything, and it pre-compiles it up front into some internal tighter representation that's not quite machine code and not quite source code but something halfway between. Then it runs that. The biggest advantage that model has in performance is that you don't pay the parsing cost repeatedly when running a loop, like you would when running a truly 100% interpreted language. If a 5-line loop runs 100 times, you pay the cost of parsing 5 lines of code, not the cost of parsing 500 lines of code. The second advantage isn't about performance but about exposing syntax errors in the infrequently run code. In a truly 100% interpreted language, if there's code that normally never runs and only runs when certain exceptional conditions become true, the syntax of those statements is never properly checked until that condition happens to occur at runtime. Code that, for example, checks for weird cases that "shouldn't happen", could have a secret hidden syntax error in it for years that never gets found because the code has to actually execute before the error is found. A pre-parse "interpreted" language engine reports syntax errors in code regardless of whether it ends up ever executing or not. On the topic of slow language challenges, while it's true that a slow language running slow code does sort of present a lot of fun challenges that it's been fun to work with in kOS, the brute force slow implementation of kOS has also created a problem of bogus simulation artifacts in the underlying KSP engine itself that are not meant to be part of that challenge. It's one thing for slow execution to cause your code to have poor reaction times. It's something else entirely for it to cause the entire universe itself to keep stuttering and halting because kOS is exceuting it's hooks slowly enough to clog up the KSP engine itself. The model used by KSP to have Mods run 'hook' routines sort of requires those hooks to finish their tasks quickly. It's sort of like the bad old days of cooperative multitasking on Macs before they switched to running on UNIX. One slow 'citizen' can ruin it for the rest of the system very easily. In that regard, to make Jebnix play nice with other mods sort of requires that it be made faster and more efficient than kOS was.

Do you imagine the game itself picks a camera position from which to generate the snapshot or do you imagine the user picking the camera position for the craft's "ID image"? I see issues with doing it either way. Something to think about anyway.

I suspect the real incentive behind this request is an annoyance at the fact that each menu screen takes time to load up, and therefore backing out properly through the menus takes a bit of time. If you are in an active vessel, and want to quit without losing your progress, you currently do it through the following menu path: Esc -> pick "space center" (___wait for space center to load___) -> pick exit button from space center (___wait for start campaign menu to load___) -> pick "back" -> (__wait for animation to slide over to the main menu__) -> pick "quit". I strongly suspect that it's those wait times that cause this request to show up from time to time in this forum. People aren't annoyed at having to back out through several menus to get out. They're annoyed that doing so is wasting time loading up stuff not related to what they're trying to do. There's no need to take the time to load up the KSC's 3D model and its executable code, and invoke its gui if all you want to do is pass through that menu to the one one step above it.

Dangerous surfaces are a cool idea, but just remember to request *deterministic* dangers. Nothing with random die rolls, or ablative hit point damage, or "chance of failure" or anything like that is allowed in the game, and that's for good reasons. Lava, for example, should be implemented as "any part that touches it melts and disappears, period, with the possible exception of specifically designed special lava probe parts - they dissappear after x seconds of touching it, which is enough time to learn some lava science first." Quicksand should just be treated as a very viscous water - works like regular water but with higher drag and higher density values. There could be low friction surfaces that affect rover tires. But what there shouldn't be is cases like "for each second exposed to this stuff there is a 0.01% chance of death. If you're fast you might be lucky enough to get in and out and survive." The key factor is the repeatability of play. If you give it all the exact same inputs with the exact same starting conditions, the same result should happen.

The only real time you need the position of the "opposite" marker to the marker you can see on your side of the ball (i.e. the prograde marker when you can see the retrograde marker) is when you actually CANT see either of the pair of markers on the ball because they're in the margin covered up by the user interface widgets on the side of the ball. As long as you can see one of the markers, the position of its opposite is known. It's always opposite of the one you can see, equidistant from the center of the ball but in the opposite direction from it. i.e if you have a marker you can see on the ball like this: C = center of navball. m = some sort of marker of any kind that you can see. r = the 180 degree 'ghost' retro version of that marker. 'r' is always in the opposite direction from the center, the same distance from the center, as the marker you can see: m \ \ C \ \ r The only reason that either ghosting or edge chevrons are really needed is due to the fact that you can't see the full hemisphere of the navball. There are cases where BOTH the retro and the pro versions of a marker are obscured by the UI widgets around the edge of the navball. If you could always be guaranteed to see ONE of them, then it takes very little brains to work out where the other one is. So maybe the fix is simply to widen the arc of the navball so that doesn't happen. Make it so you DO actually see a full 180 degrees of arc- a true hemisphere - of the ball. Then you are guaranteed to see at least one of the two paired markers of a given type. The only addition that would be needed then is to provide a retro version of the manuever node mark, which is the only marker that does not currently have a "retro" version.

The problem with solving this is that you shouldn't remove ALL oversight from a project like that. NASA, like any other government agency, shouldn't be independent enough to create its own self-contained political powerhouse. The oversight is necessary. The problem isn't that there's oversight, but that the people doing the oversight have nearly zero scientific knowledge and an utter lack of respect for those who do (which is what tends to make them ignore good advice). We've created a society in which being smart is a detriment to getting elected.

My landed items (rovers, bases) get counted into the "flights in progress" number. I don't see the behavior you claim.

The problem I have with this idea is that it's pointless unless the dev's first change their minds about procedurally generated solar systems and/or having alternate premade solar systems. As it stands right now, If I play a campaign in which I point a telescope at Duna to learn what it's like and pick up data about it, and then later start over with a second campaign and in that second run through I also point a telescope at Duna... I'll get the same exact data about Duna that I got from the first game. It will have the same mountains, the same terrain, the same atmosphere, the same mass, the same radius, the same position, etc. It's sort of like playing Civilization on the Earth-map instead of a random map. All of the terrain exploration and discovery aspects will be gone because you'll know exactly where all the terrain is before you explore it. If you start in Italy and there's a sea to the south of you, the map may be blank, but you know perfectly well that what you'll find on the other side of the sea is the Sahara Desert. The "fog" of exploration is largely fake in that situation and you know it as a player. The only players for whom your proposed data revealing in-game would matter are first-time players who don't already know the Kerbol system. For the idea of hidden system information that gets revealed in-game by exploration to matter, you have to have a non-hardcoded solar system so the discovery would actually feel like real discovery.

The author of sensor reporter has chosen to go with making a new kOS-like mod from the ground up. It looks like a very cool project, but as it's being made from scratch it will likely be a while before anything is released, I imagine.

I just tested it with my old Duna mission script again and it worked as far as I had time to test it for. I tested it up to the point of landing on Duna, then had to call it quits and go to bed. The rest of the Duna mission script after the landing on Duna just consists of calling the same programs again with different parameters so if it works up to the point of landing that means I've exercised all the software in the mission at least once already. So I'd say it seems to be working. It works great now. The DELTAV problem is fixed *AND* it's also running at full speed again. I don't know what changed but whatever it was it fixed the big lags that were in the previous 0.10 version (granted it still has the choppiness that kOS has always had, but it's now back to performing on par with how it used to run in 0.9.2). I haven't tested any of the new functionality in 0.9.2. This was just a regression test using old scripts. Some of that new content could trim down a lot of my scripts. For example I had my own private body database for all the planetary information which looks like it will be obsolete now with the new BODY: fields. Did anyone ever add the natural log function: ln(x) ? It's needed to answer the math problem: "Given the scale height and sea level pressure of the body's atmosphere, and a desired air pressure P, calculate A, the the altitude above sea level at which the air pressure will be P." My ascent script uses this to calculate the altitude at which to begin tipping over. At the moment it resorts to calculating it by approximating ln(x) by a series calculation in a loop prior to liftoff, which is a bit clunky but works.

Idea for a cool mission variables for use with exploration missions: AGLaltitude and DistanceFromTouchdown. The intent would be for this to be used to create missions in which you are meant to explore by driving a rover across a planet or moon. Since I know the game treats a rover as just another kind of vessel, and the rover bounces as it moves so it's not always "Landed", it would be impossible to implement this by saying the rover must maintain 'landed" status the whole time. But I figure it could work like this: You create a mission goal block with the condition that AGL altitude (not sea-level altitude) may not rise above a very low height, like 100 meters, during the duration of the block. Then you also add the condition "DistanceFromTouchdown" to the block, saying that you must get more than that many meters away from the point at which the first touchdown on the body happened. So a block that says, DistanceFromTouchdown is 10,000 and max AGLaltitude is 100 means you have to drive 10km from the point of the landing without rising about 100m.

It's technically incorrect though. It always tells you the distance in the vertical direction, even when you're rotated and aren't upright. An actual instrument would be directional such that it would tell you the distance to terrain along the direction it's pointed, not straight down. i.e. if you're angled at 45 degrees over perfectly flat ground then the distance to ground such an instrument would actually give you would be larger than the vertical distance (in fact it would be VertDist/sin(45 degrees). ) While this may seem like it would be a pain to use, there are times this behavior would be better. For one thing it would let you know if you're about to smash into a mountain, and therefore would allow you to fly a landing entirely in IVA mode without having to look down.

[ I edited this to remove weissel's unnecessary hubristic large font tags.] I always got the behavior I described already. Which does not interleave the outputs like this, but does what I already described. The "when" interrupted the main program and didn't give control back until it hit the end of its THEN block. If I'd gotten behavior like you describe I'd have agreed with you. But I admit that my experience testing this was several kOS revisions ago. Could this be behavior that changed with versions? Kevin had been fiddling with the execution contexts a lot when he increased the speed by 5x, so this may be behavior that changed then. I assure you, the interleaving of output is NOT what it did the last time I tried this. I tested it specifically because it was badly documented how it worked and therefore trying it was the only way to see how it worked. The only thing that I saw running concurrently was NOT the body of the THEN, but merely the conditional checks of the WHEN. The WHEN condition check was interleaved between every statement in the main program, but the body's statements weren't. So with the construct "WHEN foo THEN bar", the only things that could be really threaded were the things you could put in foo, not the things you put in bar. i.e. only the conditional boolean checks were behaving in a threaded way. Once they triggered, the body would run in serial. I believe you that the behavior has changed. But it wasn't like this the last time I experimented to learn how WHEN/THEN work. I explicitly tested for whether the THEN body ran concurrently by performing a test exactly like the one you demonstrate here and it didn't. At least, not about 5 months ago it didn't.

I don't think weissel was claiming that kOS is multithreaded ON the host computer (your PC) but that the fake virtual computer it presents is multithreaded. That just like a real computer with a single core handles the threads of processes by switching between them very fast in serial, that kOS also in its own single host OS's thread does the same thing - it switches between the threads of the fake virtual computer in serial. While this is perfectly plausible and kOS could have been written that way, I didn't see it behaving like this when I last tested how WHEN/THEN worked.

I'd really like to see that version hosted somewhere precompiled. I stopped testing because of that problem. It pretty much broke all my mission scripts.

You should be aware of these two things: 1. eerandrake is trying to make a version 0.10 for posting on spaceport. See this post: http://forum.kerbalspaceprogram.com/threads/47399-kOS-Scriptable-Autopilot-System-0-9?p=909908&viewfull=1#post909908 2. woodywood245 is starting over with a from-scratch project called Jebnix to make an entirely new archetecture for it that can support kosscript code, but also do more. That link is here: http://forum.kerbalspaceprogram.com/threads/65005-Jebnix-A-kOS-Alternative Jebnix looks very cool, but as a new project from scratch I expect it to take a long time before anything usable comes out of it, and in the meantime having a working 0.10 would be very nice.

It still has one instance of the problem: Missions 35 through 40 all require a mission called this: "20 - Mid Years Large Manned Mission Mun" But mission 20 is actually the Minmus mission, not the Mun mission. So that still causes a title mismatch and keeps those missions locked out. In my copy of it I made the following edit and it seems to have fixed the last of these issues: In missions 35 through 40, every time it says this: requiresMission = 20 - Mid Years Large Manned Mission Mun I changed it to this instead (changing the 20 into a 19): requiresMission = 19 - Mid Years Large Manned Mission Mun Would it be possible, when loading an mpkg file, to have a sanity check in the code that throws an error if a 'requiresMission' field contains a string that fails to match some mission title elsewhere in the package? That would ensure that in the future you'd discover any mismatch like this the instant you try to load the mpkg file. Mismatched requiresMission's would have the same effect as putting a syntax error in the file would have - you'd know immediately that it was a mistake the first time you try using it.

Hmm. It occurs to me that this should be doable easily when all objects are on rails (which they would be during a time warp), and when nothing has been done physically to the ship (no thrusting, no rotations, no commands at all) then it wouldn't constitute cheating at all. It would be cheating (and nearly impossible to implement) if you wanted to go backward in time after having done something - but if all you want to do is undo the fact that you time warped too far, and want to drop out of time warp earlier than right now, then with everything on time-parameterized equations that should be doable - just decrement T instead of incrementing it and watch how the objects's positions move. the only hard part would be making the UI work for it. Because the moment you decrease time warp to 1x, you've come off rails and violated the 'nothing physical happened' idea. It would require some way to back up through 50x, to 10x, to 5x, to 1x and then into -1x, -5x, -10x and so on without coming off from rails during the brief moment spent in 1x.