Dunbaratu

Oh I know, but I was pointing out a possible alternative. Either approach would still mean people script it themselves. I was picturing having script commands for "open a window that looks like this" and "put a button here with this word on it", and "WHEN clicked(mybutton1) THEN { do stuff }." I'm not entirely sure it's a good idea. I'm waffling on it. The con is that it doesn't *feel* right to have guis for an old clunky 10,000 byte computer. The pro is that if you look at the thread for the toolbar mod, you see that the rest of the modding community uses it extensively so it would make kOS scripts look more similar to other mod's interfaces. As for what's easier to implement, it's probably easier to implement a simple text keyboard catcher like: IF keypress:queued > 0 { print "you pressed " + keypress:getnext:name. }. with "keypress" being a special identifier that has these properties: keypress:queued, Integer, is the number of queued key presses that haven't been consumed yet. keypress:peeknext, keyType, is the bottom of the queue of keypresses. It is the oldest keypress not yet processed. keypress:getnext, keyType, is exactly the same as peeknext, except that it consumes the keypress from the queue as well. keypress:peeknew, keyType, allows the script writer to "cheat" and break the queue model, instead peeking at the most recent keypress without processing the older ones under it. *for the purpose of processing important aborting keys.* There is no getnew. You're allowed to peek at the newest key to see whether or not to abort something but still have to consume the keys from the oldest-first, like a real queue. keypress:consume, INTEGER, causes the queue to consume N items from the queue when SET to any positive N. Note that setting N to be equal to keypress:queued clears all the queue. keypress:trapping, BOOLEAN, is set to true by the script when it's time to begin trapping keys, false, when it's time to release control of them. kOS should automatically invoke "set keypress:trapping to False." on program exit or abort. keyType, is the type that contains a single key, which in turn contains these parts: keypress:next:name, String, is the text name of the key, one char for letters like "K" but also can store things like "[Home]" or [F7]" keypress:next:type, Integer, is a code for the kind of key: 0 = printable ascii char, 1 = special like home, F7, arrow, etc That's just an idea. What do people think of this? As a totally separate interface, for just line-at-a-time input where the program is blocked doing nothing until you press return to make something happen rather than key-at-a-time input, a much simpler method like this could be used: print -n "What is your Name? " at (0,0). readline myName. // script is stopped until ENTER is pressed. The "-n" idea is borrowed from lots of unix scripting languages. It means "don't start a new line afterward". It leaves the cursor where it was at the end of the print statement instead of going to the next line. I don't quite know what a good equivalent kosscript syntax might be for the same idea, if it was to be implemented. What do people think of that as another way to do input?

I would prefer the more raw information needed to calculate it: "What are the bounding box dimensions of my vessel and where is my current COM within that?" Because there's other places besides landing where you need that - like docking. The core problem is not the inability to read altitude from the bottom of the craft, but the inability to even know where the bottom of the craft is in the first place. Solve that more raw problem and you effectively solve more than one problem at the same time. Imagine being able to access this information: "Your current craft's dimensions are bounded by this box: FORE: [-22 to +5], STARBOARD: [-8 to +8], TOP: [-5 to +5]." Then you can use the "-22" of the FORE dimension to get the distance from your COM to the bottom of the craft, and your true altitude would then be reported altitude minus 22. But you'd also have all the rest of that information at your disposal too. And of course you could re-query it after doing a stage (which of course changes the numbers as parts of your craft fall off).

Why are you choosing to deliberately design a fragile packaging scheme that mandates such caution when it's completely unnecessary if done right? Done properly, you make an archive which never extracts files directly into the directory it is being run from, and always makes subdirectories instead. Maybe I'm spoiled coming from the UNIX world where Tar.gz and bzip packages are almost never, ever, designed to put files directly into the current directory, and while possible its considered very poor form to design them that way.

It is correct that the most efficient way is to keep burning retrograde. It is false that this can always be conducted from any low altitude. Depending on your thrust you do need a minimum distance to stop, and you need to make sure that distance doesn't involve you intersecting the surface of the planet before getting to the stopping point. A proper suicide burn involves knowing how low you can risk starting the burn from. Too low and it becomes a more literal suicide.

Well people are agreeing with that. Me too. I was just disagreeing with the claim that it's due to the speed being slower when you're low, which is the opposite of true.

You are adding things to the argument that weren't there. The experimentation that discovered how weak the attachment can be showed that the attachment (and therefore the entire paradox-defeating argument) was not relevant, which is my point. Do the experiment. Drop two objects that aren't even attached. The paradox goes away by only by the experimentation that disproves the premise, NOT by raw logic. By raw logic the paradox wasn't even really a paradox in the first place.

No. The most straightforward resolution is to realize that whatever the effect is that makes them fall, even if it might make them fall differently if they were apart, it might not be strong enough to overcome the fact that A and B are stuck together. That's why the argument defeating the paradox is insufficient to explain why A and B fall together, because the paradox isn't even a paradox in need of defeating in the first place unless you start from the quite incorrect assumption that both pheonemna - that on the one hand something is making A and B stay together, and on the other hand something is making A and B want to fall at different speeds, are somehow both of equal importance and one can't override the other. My wind tunnel example was illustrating that the paradox isn't even a paradox in need of solving the first place. I shifted to the example of objects in a wind tunnel to illustrate an example where, unlike with gravity, A and B really in fact DO move differently if they're apart from each other, and yet they can still be glued together and the glue can be stronger than the forces trying to pull them apart - thus no paradox - the glue strength beats the wind strength and overrides it. Just like had Newtonian gravity been incorrect and objects in fact really did try to fall at different speeds when apart, they could still have remained glued together anyway if the glue effect was stronger. That's why the paradox isn't even a paradox in the first place, and therefore the fact that all objects falling at the same speed "solves" the paradox is utterly irrelevant. That's not a good explanation why it happens. The F=ma explanation works much much better, which is why, getting back to what started this in the thread, it's NOT true to say that it's better not to give the F=ma explanation and instead give the Aristotle paradox-defeating explanation.

Please pay attention to the thread. I was arguing AGAINST people who claimed it was "too complicated" to give the Newtonian reason, and instead wanted to explain it using the more primitive explanation that in fact doesn't work - the argument that Galileo used to defeat the Aristotelian paradox is itself also NOT right and is as flawed as the paradox itself was. Galileo just has the advantage of being humble enough to actually experiment a little and give it a try, and in so doing behave like a proper scientist. Based on experimentation he was correct that things fall at the same rate, but he had the wrong explanation as to why.

I agree about keeping the lights but cannot agree with the claim that it "only affects a very few amount of cases". Planes that have to run off the end of the runway to takeoff are actually very common for new players because to make that not happen requires placing the main landing gear dangerously close to the center of gravity, where loss of fuel can shift them to being in front of the CG and thus make a safe landing impossible. Putting the landing gear far enough behind CG that the plane won't tip up later on, while also putting them far enough forward that the plane can do a takeoff roll is a rather touchy finicky thing.

Drop all talk of doing it automatically based on being landed or not and I drop all objection. Manually switching the mode shouldn't be an afterthought or a band-aid add-on. It should be the primary method of picking the mode - the game does exactly what the player TOLD it to. Automation is what makes it matter to me because that's what makes other people's preferences affect my gameplay.

That is a good suggestion but is NOT the suggestion this thread gave because the suggestion in the thread is to automate it by default and make people have to override that behavior manually to get it to flip back to the correct units. If people drop the idiotic notion that the units should flip automatically, and instead just let the player pick and the game sticks with what the player picks until the player chooses to change it, then it wouldn't matter to me if this is implemented or not.

And so would I. Any talk of having to mess about to outsmart the games automatic behavior is a bad design. It shouldn't be automatically altering the setting at all, period. What makes this a bad suggestion is that. If all talk of ANY automated switching was dropped, then and only then would the user interface for the idea have a chance of being intuitive. Auto-switching without being told to is not intuitve. The user does not expect control over a setting to be taken away like that.

As opposed to the sane idea of it not needing to switch "back" because it never auto-switched in the first place and instead just stuck with whatever you picked. You are perfectly aware that this is incorrect. Stop trolling.

There's a toolbar mod toolbar mod that's a sort of mod for mods. It doesn't do anything by itself but it presents a system for other modders to use to create popup windows with icons and guis, and it's commonly used by many different mods. Perhaps a bridge between kosscript and that might be handy, so someone can call kosscript functions that make things happen in the toolbar mod. I'm of a mixed mind about it though because it does sort of break the "make it feel like an old computer" feeling of kOS to have your flight computer be able to open dialog boxes and let you click buttons with a mouse.

The point is that the explanation, while simpler, is a fallacy. The classic argument that the reason gravity must make all things fall the same is because of the contradiction that two objects attached together would simultaneously fall at the same speed and yet at different speeds if it was any other way is utterly false. It happens to arrive at the right conclusion but for all the wrong reasons. It's a bit like saying "cars are animals that like the taste of gasoline. You have to feed it to them or they get ornery and refuse to move". While it might teach someone that they need to put fuel in the car to make it go, it's still a faulty explanation that it's a bad idea to use. The crux of the "fall at the same speed but different speeds at the same time" argument is the incorrect notion that movement based on gravity happens in a sort of "on rails" way. If it's properly expressed as a force that pulls on things rather than a magical forced deterministic path that things follow, then it's easy to see that objects attached together could still remain at the same speed if the force trying to pull them apart wasn't strong enough to break the attachment. What matters is the experimentation. The fact that when you try to drop the two objects they don't in fact show any signs of being pulled apart (i.e. a string between them remains slack) is the reason. Not the mere thought experiment based on the false notion that objects can't remain stuck together if gravity pulled them differently. Of course they could remain stuck together, but then it would be like a tug-of-war between them.

I said it was obvious because you don't need to know one bit of orbital mechanics. Just the basic geometric picture shows it. If you imagine a hoop of of weak bendy metal in the shape of an ellipse, and you grab it by the short axis and pull it apart to make it stretch the other way, clearly it's going to pass through circular on the way there.

False. Yes it does, and not just in angular terms, but in linear terms as well. In a circular orbit, the speed is sqrt( GM / r ). The bigger the 'r', the smaller the result.

There is one case where you need to de-orbit to land from a higher orbit and that's if your thrust capacity isn't very good. For example, if you currently have 500 m/s speed, and it's going to take you 2 minutes of constant burn to get rid of all of it, but in those two minutes you hit the surface because you started very low, then that's not very good. You need to be able to kill your horizontal speed in the time it takes to fall the vertical distance to the ground as you are no longer going fast enough to orbit but still not going slow enough to land. If you assume infinite ability to thrust, then lowest is most efficient, yes. But if you have a weak wimpy engine as is often the case for a thing like a Mun lander, then starting your burn as low as possible might not be safe.

I agree with this. The part I don't agree with is where regex is insisting on putting readme, license, and changelog flat into the folder above gamedata, which is your KSP's main folder. If I install a mod, I want that mod's files in a folder NAMED FOR that mod, not in the root KSP folder where they'll get clobbered by the next mod I install. If you insist on having none of those files in GameData, then the alternative proposed should not make them all name clash with each other and clobber each other like what regex showed would do. If there's some reason you don't want them under GameData/mod-name, then this would be a better suggestion - to still keep them under SOMETHING named 'mod-name' to keep all the readme's and so on separate from each other: gamedata `-- mod's name `-- Plugin `-- PluginData etc… modfiles `-- mod's name `-- readme.txt `-- changelog.txt `-- license.txt `-- source (if present) Putting them in the directory one step up from gamedata, like regex suggested, means you only have the readme.txt of the most recently installed mod, it having clobbered the previously installed mod's readme.txt

If I lived in this imaginary universe you're referring to where those files don't matter I'd agree with you. Meanwhile over here in the real world where they do, deliberately designing a scheme that MANDATES that to match the standard you have to put them in a location that will get overwritten the next time someone installs a mod is a bad idea. I want the readme's from all the currently installed mods to be stored somewhere, not just the ones from the most recently installed mod.

I dislike the idea of making it be a slider. Individual checkboxes per feature? sure. A slider? no. This is because in every game I've ever played with a difficulty slider that turns options on and off it's always been the case that the options I want on don't fit with how the game makers designed the slider settings. For example, in Fallout New Vegas, I wanted a mode that was as hardcore for ME as possible, but not hardcore for the dumb NPC followers who kept choosing to kill themselves through no fault of my own because the AI made them dumb as rocks. "I'm an NPC. The game doesn't allow me to take anti-venom doses. Oh look its a few stinging insects in the distance that we're trying to skirt around. I'm going to run directly toward that nest of giant stinging insects all by myself even though I was told to stay put. Oh look, I died from venom, how did that happen? Now all the quests involving me have failed because I'm dead." So in that game I'd have liked to cherry pick which realism options I wanted (basically everything except dead NPC's stay dead - which kills plot lines when the AI runs at poison insects, or walks off a cliff). But the slider didn't have that as an option. Once I added the need to deal with hunger, thirst, and rest, for myself, I was also activating the perma-death for NPCs which I didn't want. Difficulty sliders almost always end up making options into 'package deals' in which I don't care for how things have been packaged together.

Of course not. Knock it off. Nothing you quoted amounts to me saying that. Knock it off. This is not the suggestion given in the post. This was a correction to the suggestion to stop it from being a bad idea. And the realization of the need for that adjustment was why the argument we're having matters. As long as people are acting like that's no big deal, there remains the danger that the original suggestion gets implemented, which did not have the fix to stop the bad idea. that does affect my gameplay. The fix of allowing a user to, essentially, opt out of this, is not a minor extra suggestion as far as I'm concerned. It's 100% essential to preventing this from being a bad idea. Until the main suggestion gets edited to fix this bad idea, it's important to diffuse this bogus claim that flipping between m/s and km/h depending on whether or not you're landed is some how intuitive. I'm reminded of how "target mode" works, where the game insists on flipping the navball mode from orbit to target when you get what *it* thinks is near enough that you want to use it that way, even if you're not planning on using it that way. And I have to continually remind myself to correct it's "helpful" behavior so I don't end up burning at the wrong "prograde" marker that it flipped on me. It would be more helpful for it to have never implemented that behavior in the first place and just let me pick it manually all the time. There is only one way this idea would be remotely okay - and that's to drop all this talk of it automatically flipping modes based on being landed or not. Even for those of you who want to drive with per-hour units, as I've already alluded to, the game's idea of "landed" is such that if you hit a bump and go airborne for a moment then you're not "landed" for a second or two. It would be annoying for the measurement method to keep changing from one moment to the next as you drive across bumpy terrain. What's wrong with just dropping the "auto" switching entirely? Why can't you deal with manual flipping the mode only? That's a much better suggestion than anything that's already been mentioned about having to flip a setting in order to get it to stop doing an annoying automated thing. Why not just NOT automate it at all? If you want kp/h, then put it in that mode and it stays there. If you want m/s, then put it in that mode and it stays there. If you want different modes depending on context, then just flip it yourself.

All the current science readings work while standing still. The way to make rovers more useful is to just to invent a form of science that requires movement - and thus has to be measured from a rover.

Of course I'm not. I'm arguing against it because I find the way it works now to be more useful and it's a request to take that away and to CHANGE it to something less useful. All the talk about pretending it would be more intuitive to use the less useful time measurements on a per-hour basis rather than the useful per-second measure is tied to the proposal that the current method be changed. If nobody was trying to use that argument as a reason to destroy something I like about the game, then it wouldn't matter that they're misusing the word "intuitive". The misuse of that word is being done in service of an argument to get rid of a feature I want to see kept - the consistent speed measurement that stays with the proper MKS system regardless of whether you're landed or not. Note the suggestion isn't to let you pick the method of showing the speed and just stick with what you picked. It's to CHANGE the speed measurement when on the ground - introducing an unnecessary difference between measurements used on the ground versus measurements used by vessels in flight. When a rover goes over a jump should it change to m/s while in air for a few seconds then shift back the km/h when it comes back down? I'm not arguing against adding a feature to placate the people who can't think in m/s. I'm arguing against those who would try to REMOVE a feature for those of us who do think in m/s.

That's a horrible way to do it. The source, readme, license, and changelog should be somewhere under <mod name> directory, so you can have a different set of them per mod. What you've described there would cause each mod installed to clobber the files from the previous one. That's a wrong design. Not just a difference of opinion, but actually factually wrong as it makes it impossible to store the mods' files from more than one mod.