Dunbaratu

- Procedural is a prerequisite for randomness. You can't have random manually generated content. - SQUAD *themselves* use the term "procedural" when describing what they don't want to do, which is their OWN misnowmer because a lot of their current unchanging constant fixed content is procedurally made already. So complain to them about the difference, not me. I'm just using terminology that people who play KSP will understand because it's what the KSP makers themselves used to describe the idea of having different solar system for different campaigns and different players. It's no different than calling a crater on the Mun a "biome". I know perfectly well that it's not a biome because of the "bio" part of the word, but I also know that because SQUAD made the error of calling them that, that I have to continue that error if I want to communicate to other players of the game. So don't blame me, and your entire point was irrelevant to the comment I made anyway because whether you call it 'random' or 'procedural' it doesn't change the meat of what I said, which is that having the exact same solar system every time you play, for every player and for every campaign by the same player, reduces the value of discovery and science measurements, and greatly reduces the replay value of the game.

Yes, and I agree that if there is procedural planet generation that it makes sense to use an algorithm for which sharing one random number seed with another player would allow that other player (provided they have the exact same software version) to generate the same solar system as you by plugging it in. This is vital for more than just 'showing off'. It's also vital because of the stated intentions of supporting multiplayer some day. There needs to be a good way for the server to ensure that all the clients have the same picture of the solar system in their heads.

Ah yes you're right. I forgot that ORBIT is abbreviated OBT.

Intake spam is *already* limited by a rather artificial unfair game mechanic - the incorrect way oxygen is delivered to the engines unevenly so that if you have, say 2 engines with 2 intakes each, for a total of 4 intakes, and each intake is operating at only 1/3 capacity because the air is getting thin, such that there's a total of of enough air for 1 1/3 fully functional engines, then the air capacity is not distributed evenly as giving 2/3 air to each engine. Instead you end up giving 100% to one engine and only 1/3 to the other, making the aircraft spin out of control from the uneven thrust. This is true regardless of how you've arranged the air intakes and how symmetrical you make the craft. All the air intakes add air to a common pool that all the engines pull air from, satisfying one engine entirely before seeing how much is left for the next engine. The correct behavior for that sort of "air pool" algorithm would be to sum the total air all the engines are trying to use, sum the total air available in the pool, and if the total air available is only X percent of the total amount needed, for any X less than 100, then give *all* the engines only X percent of the air they are requesting, evenly. If you're going to use the 'air pool' method, then do it that way. The even better solution is not to have an air pool at all and instead let the airplane designer designate which air intake is connected to which engine when building. That would be more realistic and get rid of the problem. But if you *are* going to do it with the common air pool, then at least make the engines pull from that pool evenly as described earlier in this paragraph. This misfeature in the game *already* makes spamming intakes pointless. Until that problem is fixed the issue of spamming intakes doesn't matter because it just doesn't really *work* to try to do so anyway.

I'd like SQUAD to take a serious look at their position that procedurally generated planets is bad. I think it would be the best thing ever because it *would* make all the other science stuff feel more real. Currently, if you want to know the best angle from which to transfer to Eve, you look it up online, because everyone has the same "Eve". If you want to know the density of Laythe's atmosphere, you look it up online because everyone has the same "Laythe". That makes the science instruments a bit pointless other than as a way to mine tech tree points. But if this time around I might have different moons around Jool than in my last campaign, and different moons than other people have around Jool, then I have to send my own probes with my own instruments to learn what my solar system is like. It makes the instruments really mean something and feel like you're roleplaying a science program a lot more. The info from the map view would be vague - just barely accurate enough to be able to plan your first probes to the body, until you take the actual measurement and then the map view info would get more accurate. But right now, since the solar system is identical every campaign you play, and identical for all players around the world who own the game, the feeling of discovery at learning that information is nonexistent and there's little point in bothering playing the game that way. Also, it would increase replay value a LOT to have a slightly different solar system when you restart a campaign. These days I'm starting to think "oh a trip to Duna. Big deal. I know exactly what that's like and exactly what I'll find when I get there." I can understand the arguments against procedural content being that people can't share anything with each other that way, but how about a compromise: About half the planets being constant for all campaigns and the other half that are varying? You use the constant planets to show each other stuff online and share plans, and the varying ones to experience the thrill of discovery yourself.

It was phrased confusingly. I *suspect* that "the part" was meant to refer to the CX-481 part. The word "the" here was ambiguous and makes it unclear. "If that doesn't work then use the part" probably meant "if that doesn't work use the part that comes with the kOS mod instead of trying to modify a command core."

There's no need for an exponential function because there already exists the caret for "to the power of". What you need to perform e^x is not a function but rather a constant - you need the constant "e". Like this: set e to 2.718281828. set y to e^x. There exists a constant 'e' in the system already, but the syntax for accessing it is weird. You have to say: consts():e. The place where you *do* need support from the system giving you a function is when going the other way around, and getting the natural log. Doing that on your own is a mess because you'd have to calculate it from a series sum and that's too slow in kosscript. For that you have ln(): set y to ln(x). Try ORBIT:SEMIMAJORAXIS. Or for getting it about a different ship than yourself, try: TARGET:ORBIT:SEMIMAJORAXIS.

The difficulty with diagnosing this is that many DIFFERENT unrelated problems can cause that same effect because it's not what the mod is doing, but what KSP is doing in reaction to the mod confusing it by leaving data in a 'wrong' state. What you are seeing is KSP's behavior when the mod causes unhandled exceptions to occur. KSP is a bit fragile in that it doesn't protect itself very well from mods that raise exceptions. If the mod triggers errors, then all of KSP gets broken, and the broken behavior is similar for lots of different unrelated problems mods cause. So that makes it very hard to work your way backward from "this is the symptom" to "this is the thing the mod did that caused it" when many many different errors all cause the same symptom. It would probably help more to find the part of the KSP log where the problem first occurred and post that.

Okay, I narrowed down the conditions and verified it was not being caused by any other mods and it still happens when kOS is the only mod. I also used a far smaller simpler craft and verified that it happens with that craft. I put the code on google drive so you can give it a try. It's here: https://drive.google.com/#folders/0Bxkeai7oN35fTkJQUnJRLUN2QjA Along with the craft file of the test vessel, and a README showing the commands to run to kick it off. I've tried this a number of times and verified that it reliably causes the problem every time. Here's some screenshots of the steps leading up to the problem: The problem always happens at about T+2 seconds - just a moment after liftoff.

Now I went through and changed all my 'sets' that were triggering the variable-with-asterisk message into locks instead, to get the code to continue running, and now I have this new problem: Shortly after liftoff, within about a second or so, the KSP black screen of death triggers. (I'm sure people have seen it before - the 3-D view goes black, the altimiter starts showing all the same digit (i.e. 9999999 or 8888888 or 7777777 and so on, and execution seems to be continuing but very slowly, and you can't tell what's going on.) This is a program that previously DID work on 0.9 that I've been trying to update to work in 0.11. I don't know what changed, but here's the KSP log of the point where the problem appears: [LOG 11:46:50.285] activating stage 17 - current stage: 18 [LOG 11:46:50.286] [liquidEngine1-2]: Activated [LOG 11:46:50.298] [launchClamp1]: Activated [LOG 11:46:50.299] [liquidEngine1-2]: Activated [LOG 11:46:50.308] [launchClamp1]: Activated [LOG 11:46:50.309] [liquidEngine1-2]: Activated [LOG 11:46:50.310] [liquidEngine1-2]: Activated [LOG 11:46:50.319] [launchClamp1]: Activated [LOG 11:46:50.320] [liquidEngine1-2]: Activated [LOG 11:46:50.329] [launchClamp1]: Activated [LOG 11:46:50.330] [liquidEngine1-2]: Activated [LOG 11:46:50.338] [launchClamp1]: Activated [LOG 11:46:50.340] [solidBooster]: Activated [LOG 11:46:50.341] [liquidEngine1-2]: Activated [LOG 11:46:50.349] [launchClamp1]: Activated [LOG 11:46:50.351] [solidBooster]: Activated [LOG 11:46:50.352] [00:00:00]: Liftoff!! [ERR 11:46:50.357] Vessel Being Flagged Under Disabled Plugin [LOG 11:46:52.045] Look rotation viewing vector is zero [EXC 11:46:52.067] ArithmeticException: NAN [LOG 11:46:52.101] recalculating orbit for mk1pod: Kerbin rPos: [NaN, NaN, NaN] rVel: [NaN, NaN, NaN] |NaN| [LOG 11:46:52.106] recalculated orbit for mk1pod: the Sun rPos: [NaN, NaN, NaN] rVel: [NaN, NaN, NaN] |NaN| [LOG 11:46:52.108] setting new dominant body: the Sun FlightGlobals.mainBody: Kerbin [LOG 11:46:52.109] Vessel mk1pod velocity resumed. Reference body: Sun vel: [NaN, NaN, NaN] [LOG 11:46:52.109] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1165.70850896705, 2.20600485801697, -9341.86065115751] [LOG 11:46:52.110] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1165.58655488284, -5.00523233413696, -9342.08744510042] [LOG 11:46:52.111] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1165.74433173733, 0.496987462043762, -9341.68154542168] [LOG 11:46:52.112] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1164.91580614203, -3.33820581436157, -9342.69322806142] [LOG 11:46:52.112] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1165.73379065088, -3.51643514633179, -9341.67233485518] [LOG 11:46:52.113] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1165.62684249123, 0.407076090574265, -9341.83273940671] [LOG 11:46:52.155] Look rotation viewing vector is zero [LOG 11:46:52.156] Look rotation viewing vector is zero [LOG 11:46:52.157] Look rotation viewing vector is zero [LOG 11:46:52.157] Look rotation viewing vector is zero [LOG 11:46:52.157] Look rotation viewing vector is zero [LOG 11:46:52.158] Look rotation viewing vector is zero [ERR 11:46:52.222] Invalid parameter because it was infinity or nan. [ERR 11:46:52.222] dest.radius>=0.0f [ERR 11:46:52.223] Invalid parameter because it was infinity or nan. [ERR 11:46:52.223] dest.radius>=0.0f [ERR 11:46:52.223] dest.radius>=0.0f [ERR 11:46:52.223] Invalid parameter because it was infinity or nan. [ERR 11:46:52.224] dest.radius>=0.0f [ERR 11:46:52.224] dest.radius>=0.0f [ERR 11:46:52.224] dest.radius>=0.0f [ERR 11:46:52.225] Invalid parameter because it was infinity or nan. [ERR 11:46:52.225] dest.radius>=0.0f [ERR 11:46:52.225] dest.radius>=0.0f [ERR 11:46:52.225] dest.radius>=0.0f [ERR 11:46:52.226] dest.radius>=0.0f [ERR 11:46:52.226] Invalid parameter because it was infinity or nan. [ERR 11:46:52.226] dest.radius>=0.0f [ERR 11:46:52.226] dest.radius>=0.0f [ERR 11:46:52.227] dest.radius>=0.0f The log gets spammed with more of those 'dest.radius' messages from there on until I kill KSP.

What you've done there is confuse "SI" with "Metric". SI is a subset of metric. In metric there's many many terms for force, all related to each other by powers of 10. In SI, the standards pick just one of them and stick with it so that all your figures will be in the same scale - and the one that SI picks is newtons, not kilonewtons. Then, also the international standards groups pick the SI unit as the one for which there will be a physical standard derived from something materially existent, and then all the other metric units will be derived by multiplying that unit or dividing that unit by powers of 10. So for example, the international standards for SI mass has a kilogram bar stored in a lab in France as the basis for all the other mass measures that are derived from it. Oh, and a litre is very much like a kilonewton. It's not the SI unit but it is a metric unit derivable from the SI units. Specifically it's the volume that, if filled with water, would have a mass of 1 kilogram. Much like a kilonewton is the unit of force you'd get if you took the SI unit and multiplied it by 1000. It's not the SI unit, but is easily derivable from it. Another way in which metric and SI differ is in where the 'base' unit sits on the powers of 10 scaling. In metric masses, the naming convention is to start from the gram and derive all the other mass units from that, so a kilogram is derived from the gram by multiplying by 1000. This is where the naming conventions come from and why 'gram' is the mass term that has no prefix. But in SI it's the other way around, and despite borrowing the same terminology as in metric, in SI the gram isn't in fact the base measure - it's derived. The kilogram is the base SI unit, and the gram is derived backward from that, by dividing the official kilogram definition by 1000. But at any rate, this is all parenthetical to the point I made originally, which is that the claim that the units in the game don't need to be specified because they're metric is a false claim. They do need to be specified. You can't work out your TWR when mass, thrust, and gravity, are all unitless numbers, unless you know they are in the same exact scale from each other (and they aren't). When the gravioli detector tells you the gravity is 9.8, and you start to assume that means standard SI units, you'll be wrong when you come to the thrust and assume it's standard SI units (newtons) when it isn't. The only reason I worked out that thrust was in kilonewtons was that I saw that mass was in tons, that gravity was 9.8 "thingies", assumed that 9.8 was m/s^2, and experimentally made several rockets until I got one that hovered in place at max thrust, knowing that would be a TWR of 1.0, then working backward from that to find out that the thrust was given in kilonewtons. That's a silly amount of extra work to ask the user to do when you could just put a label on the unit in the display instead.

You can definitely lock the throttle to a value greater than 1. If you lock it to a value > 1, it just behaves as if you'd locked it to 1. I exploit this feature all the time by writing math expressions designed to make the throttle slow down when getting close to the cutoff condition. Rather than putting the extra code in place to to cap the value of the expression at 1.0, I just go ahead and let it be larger than 1. As for the 'stage', 'stage' is an unreliable command. Depending on timing it sometimes works and sometimes doesn't. Whenever I stage, I do it like this: set prevmass to 9999999. while prevmass - minStageMass < ship:mass { set prevmass to ship:mass. stage. wait 0.2. }. (minStageMass is the minimum hypothetical mass for a stage in my designs. It's the threshold of the check to ensure that the small mass change that comes from burning fuel for a fraction of a second won't trigger the condition. When the change in mass is larger than that, I assume the 'stage' worked and I've dropped off something significant from the craft.) I don't think this is kOS's fault. When playing the game manually, have you noticed that its impossible to hit spacebar quickly to drop two stages back-to-back? If you mash the spacebar quickly some of those key presses result in the game just going "click" and nothing happening. I think it takes a bit of time for a stage command to perform its function. So the stage command probably started doing its work but the script ended before it finished and it was aborted before it did its job.

Then how about this simple solution to fix the problem: Every time you see this in the script code: set var to (expression). and 'var' is defined as a lock function elsewhere rather than as a simple variable, then replace: set var to (expression). with the risc instructions that would do this instead: Evaluate (expression) into a final value now. Create a function that will return that constant value. Use that function as the lock expression. That way 'var' is still a function, still a lock. It's just now a lock who's expression just returns a constant - the value of which is the value of the expression as it was at the time the 'set' command was run. So if it was this: set x to 7. set var to x + 5. And var was a lock expression elsewhere, then executing the above lines of code would cause var to become a function that returns the constant 12 rather than a variable who's value is 12. As far as the script programmer cares the result would be the same either way. (At this point the discussion probably belongs over in the development thread instead of this thread.) I made a tracking issue for this: https://github.com/KSP-KOS/KOS/issues/13

While it's true that there exist SOME negative claims that can be proven, its important not to lose sight of the fact that there exist a lot more that cannot. To make a negative claim provable you have to narrow down the 'search space' a LOT (in your example it's the phrase "in your dishwasher" that makes it possible), or make the search space so uniform and consistent that it's possible to 'search' the space by logical induction from a small subset of it (i.e. like in math where if you prove that for any integer N, a thing is true about its neighbor N+1, you've indirectly proven that to be true of N+2, N+3, and all other integers). But most negative claims aren't going to have that sort of narrowing down of the search space or uniformity of the type of search space that makes those proof methods possible. The claims of these blatant frauds are designed to make the method of disproof by exhausting the search space impossible because the search space is too large and non-uniform. It's not "prove there's no flying saucer in your backyard". It's "prove there's no flying saucer somewhere."

Does it parse through the entire script first and therefore decide that mysteer is used in a lock somewhere, then go back and actually run the script? I ask because while it's true that I do also lock mysteer, I don't do it until later, further down, after the line where the error is coming. FIRST I use 'set' with mysteer and then don't change to using 'lock' until later. Hm.. Well, I just ran the following test script and it seems to prove that yeah if there is a lock anywhere in the script, even in the "future", then it retroactively messes up "sets" that occur on the same variable earlier. (So I presume there must be some sort of pre-parsing going on or that would be impossible). print "Before setting.". set thingy to "some set val". print "After setting.". print "Before locking.". lock thingy to "some locked val". print "After locking.". Output: Before setting. Variable thingy* is not defined Instruction 10. At least now that I know what's causing it I can go through and fix it by essentially making sure that if a variable ever gets used with 'lock', that it always gets used with "lock" everywhere even in places where the value is an unchanging constant.

Why would I get the ouput AAA Variable mysteer* is not defined Instruction 588 From this part of my code: print "AAA". set mysteer to up. print "BBB". I put the print statements in there to try to narrow down where the error message was being produced. It prints AAA but not BBB, thus making me think it's coming from the statement "set mysteer to up." But... of *course* mysteer isn't set. That's why I'm trying to set it. Also, weirdly, I don't know where the asterisk is coming from in the error message. It doesn't seem to be there in the line of source code in github that builds the exception message, making me think it's actually trying to look up a variable name that includes an asterisk in the variable name, for some reason, even though that's not in my script code anywhere. I could provide the entire script for you to run if it would help, but it's a lot of pieces to post and so I'd prefer to put it on pastebin or google drive than paste it in the forum.

Three problems: 1 : @Cortek56: The title of the suggestion is wrong. Anemometers are just things that measure airspeed. The fact that our culture tends to measure it in knots is not part of the difference between anemometers and speedometers. Basically we already HAVE an anemometer in the game - it's called "putting the navball in 'surface' mode" which gives you your speed relative to the volume of atmosphere that's 'attached' to the surface, since KSP has no wind. 2: @vexx32: You implied "knots" is an SI term. (Saying m/s is the SI term except in atmospheric flight where it's knots). It isn't. Knots is part of the culture of the air travel industry, where the tendency in the early days to borrow naval terms for airplanes, combined with the need to make an international standard because you cross national borders so readily in an airplane, meant that the naval international standard ended up becoming the airplane international standard, in use even in those countries where the country had been metric for a long time. This is analogous to the fact that anyone who wants to become a pilot or a traffic controller must learn English so that all communication is internationally done in the same language no matter what airport you're at. 3: @vexx32 : While there isn't need for multiple different units, there *is* a need to label the units that do exist, since the claim that all the units are in SI standards in KSP is provably false when you see how the numbers interact with each other There's scaling factors in the game that prove that some measures are 1000 times out of scale from other measures. The interaction between volume, mass, and thrust listed for parts and how the math works out when you try using them proves they can't all be SI units. One possibility that does work is if mass is in megagrams, thrust is in kilonewtons, and volume is in liters. (SI units would be kilograms, newtons, and liters).

"nodes" are now structures containing many 'suffix' components. To steer in the direction of the node you need to "lock steering to node:deltav". Node:deltav is the vector of the total delta V that comes from summing together the prograde, radial out, and normal components of the node.

Are there plans of a new development release soon? The fix for the bug with ship:solidfuel is done according to github but I don't have the development environment set up to compile the source myself. I'm waiting on ship:solidfuel before I continue the work on the mission I'm trying to tweak. (I'm trying to make my generic do-everything ascent script handle asparagus staging even when the ship has a combination of liquid and solid fuel. Because it's doing asparagus staging, using stage:solidfuel (which does work) isn't good enough for my needs, as asparagus staging tends to confuse the mod's calculation of what qualifies as being "part of this stage". Because there's decouplers connecting to parts of the ship that are currently active it's not clear what the "right" answer is about that, so I just want to use the ship's total fuel to calculate the fuel loss rate. (The key to my asparagus algorithm is that if I haven't changed the throttle setting and yet I notice a sudden drop in how fast the fuel is disappearing, I assume that must be because one or more engines have run dry, so that's what means its time to hit the next stage button. When I wanted to add support for solid boosters I realized that essentially, strapping solid boosters on the side of a liquid rocket is so similar to asparagus staging that I should be able to use the same algorithm for both. The key to the staging activator on asparagus staging is the need to support the idea that you shouldn't wait for all the engines to run dry to hit "stage", but instead just hit strange when at least some engines have stopped. And that's basically also what you're doing when you peel off solid boosters from the side of a liquid engine stage.)

Which is currently useless. The first EVA report you bring back to Kerbin from a biome 100% mines out the science for EVAs in that biome. The remaining two reports will be worth zero. Unless they do what I suggested about making crew reports and EVA reports return science from different pools depending on the type of kerbal who took the report.

This is good news. I'm cynical enough given the past actions of certain software companies to have presumed that nVidia would have every incentive to make the CPU-only implementation of PhysX deliberately worse than it needs to be, as incentive to get more people to buy their cards. I'm glad they're not going that route.

No. It's saying give it a unique filename suffix because of how many programs there are out there that use the filename suffix to identify what type of file it is. Programmer's text editors tend to do that to decide what syntax to expect in the file for color highlighting purposes. Calling them .txt tends to make them just generic ascii text, which makes it hard to define special syntax highlights for them without those rules also ending up being applied to all other ascii text files too.

Not with what you've proposed. I'm sorry if I came off that way. You can design it however you like. My motivation was less to tell you how to implement it and more to get you to stop spreading misinformation about some other programming languages that I really like. The claim that the for loop in C, C++ and Java is incapable of doing things beyond the simple counter mechanism that for loops tend to be used for in other languages is very false. And it matters because the for loop in C/C++/java tends to be a bit less structured and formal and therefore can be a bit sloppy and error-prone. It would look like bad language design if it was made that sloppy with no benefit. Therefore hand-waving away that benefit and pretending it doesn't exist is unfair. I wasn't telling you how to write your language. I was defending other languages I like from false claims.

I think all you'd need to make multi-crew missions give better science is more than one kind of "crew report" and "eva report" per biome, depending on what type of crew member took the report. So you send a kerbal tagged with the "geologist" skill to Duna and take an EVA report from the surface and you'll get science points from a different "mineable" science pool than if you have a "chemist" do so. Thus sending a 3-person crew lets you take 3 different reports in the same biome if you sent three different types of kerbal. This has the advantage of dovetailing well with other stuff the SQUAD has said they plan to do later, like having different kerbals with different skills, and it seems like it would be easier to implement on top of the current code already there. You just make a few more mineable science pools per biome and tag them with the type of skill required to get them.

It's much harder to change something after it's already been finished. If the designer has a major misunderstanding about something rather important, for example thinking that this type of for loop covers 100% of all the same cases that for loops in any other language do, the time to clear that up is not *after* the implementation is done. Woodywood has made it clear in the most recent post now that he does in fact understand that this loop is not as versitile as the loops in the languages he mentioned, but that this is okay and it's an intentional design goal. That was NOT what it looked like in the earlier post, where he claimed this style of loop does all the same stuff that the for loops in other languages do. That would have been a pretty big design error if that's what his actual intention was. If that's not really his intention after all then it's less of a problem. And no, the right time to hash this stuff out is NOT later on after it's already been decided.