Themohawkninja

Sweet, now I can see stuff past 10km. However this has created the new issue of said targets destroying themselves once I get ~>15 km away. Not sure if that one is fixable or not.

Is there a way of keeping things rendered/loaded out past 10 km? I'd be nice to exploit the claimed >10km ranges that many of the missiles have.

I don't. I have a pretty limited knowledge of computer science at the moment, which is why I asked what this would ACTUALLY test. - - - Updated - - - The program was meant to do the exact opposite of what it does (run for a given period of time, and count the number of times it called the function), but I was having issues with it either breaking a 64-bit integer, or calculating for such a short period of time that I couldn't get any real data from it. The code would look nicer if it wasn't for the fact that this isn't so much of a serious program that I would put in a portfolio for a job, so much so as it is a little experiment in mathematics and computer science. It gave me quite the eye-opener as to just how fast current processors are when I had to tell the computer to run 100 million iterations to get a decent number of milliseconds to go off of. Also, what is the "stack" with reference to computer science here? Is that the order/speed in which instructions are carried out, or something completely different?

Hello, In addition to my interests in all manner of computers, I also am quite interested in mathematics, and I recently discovered a highly recursive mathematical function called the Ackermann function. As you can see in the article, there is a brief mention of this function being a useful tool for benchmarking computer performance, however when I looked up Ackermann-based benchmarks, only academic papers about the subject seemed to show up in Google. As a result, I ended up programming my own in C++. Once it was up-and-running, I tested in on both my computer (i7-2600k w/ GTX 580), and my roommate's (i7-4790k w/ ASUS Hero VII on-board graphics), and my roommate's computer scored about 25% higher. I'm not really sure if that accurately displays the difference in performance, because I can't seem to find consistent information on the GFLOP count of my roommate's processor. Is this function an accurate way of measuring either CPU, GPU, or total computer performance? In-case anyone wants to try this on their own computer, the .exe application and the source code in .h format are linked below. Ignore the broken "how it works" function. I have yet to get it to properly display the message that you can read in the source code, so if any programmers want to tell me how to fix it, that would be nice. Application (EXE): https://www.dropbox.com/s/bh5c72j395xz1m7/A44.exe?dl=0 Source (H): https://www.dropbox.com/s/guavn0c364w97hz/Form1.h?dl=0

SpaceEngine Story Maker Collaboration Project. Introduction: So, a couple of weeks ago, I had this dream whereby I was going around in a game very similar to SpaceEngine clicking on planets and reading the randomly generated stories, imports, exports, and so forth as if the planet itself was home to a space-fairing civilization. I woke up inspired and decided to go about making a program to do just that for SpaceEngine! However, I'm going to need everyone's help developing story pieces for it. How it all works: The program will take user inputted information about the planet (sadly, I have no idea how to just mod SpaceEngine to have all of that done for me), like its' temperature class , its' type, whether or not it has life (and what kind of life that is), along with the magnitude of gravity and the atmospheric pressure, amongst a few others. The program will then pull mad-lib-esque stories that match those criteria from a text file, fill in the variables with randomly generated values, and output the modular story to a textbox. What you can do: I'm here to basically ask for story snippets (it's all in Star Wars and Star Wars: Legends continuity). They don't have to be (and aren't really supposed to be, but it's alright if you want to add plenty of detail) particularly long, but basically all I ask is that they have as many variables as possible to allow as many permutations (or is it combinations, I keep forgetting XP) as possible. Then tell me what aspects of the planet the story is restricted to (e.g. only gas planets, only planets with thin atmospheres, any planet with gravity similar to Earth's, etc). I personally think it will be a lot more interesting if there are plenty of story snippets to choose from, so that we can have as many possibilities (and therefore the fewest number of repeated statements) as possible. The variables must be inside percent signs, as that is how the program distinguishes between text to read, and variables to generate random information from, therefore if you want to refer to percentages of something in your story section, use the word "percent" instead. Example sentence: In %Rnd2500-3000% BBY, the Sith Lord %SithLord% bombarded the planet with %Rnd1-10% Star Destroyers, leaving most of the planet turned to slag with the exception of the majority of the city, %City%, which became a symbol of hope, and the new capital for the planet after the Star Destroyers were finally fought off by the %Faction%. The above would be restricted to any planet that isn't scorching, hot, frozen, an asteroid, a gas giant, or has a gravity of < 0.75. I haven't yet specified actual names for the variables (outside of the random numbers), so you can name them anything you want as long as I can understand what it means. I'll edit all the variables myself once I decide on actual variable names, after I start getting some story snippets in. Release: Once I finish the coding, get a decent number of story snippets, and make sure everything works properly, I'll release the program to you guys. Since most of the variables are drawn from .txt files, you can add new story snippets any time you want.

Could some Russian version of SpaceX get the blueprints for the program and make a usable version: Sure, I don't see why not. Could said Russian SpaceX pull it off in a way that is economically worth it as opposed to just using the Soyuz, or building their own system like the the Falcon 9 w/ Dragon: No... probably not. Even though the Buran was more economical than the Shuttle, I doubt either are anywhere close to being as useful as Soyuz or the Falcon 9 w/ Dragon.

As I said, I needed some lower limit. I wasn't the one that asserted that 1 in 10^50 claim.

So... the other day, I was having an interesting conversation with my dad, whereby he proclaimed that some mathematicians proved that any odds less than 1 in 10^50 are impossible. My dad figured this had to do with the number of possible things that could have happened in the Universe. I hardly believed this, and soon discovered that there wasn't much basis to the claim, with no actual mathematicians being named or a paper about the topic being published. That being said, it did make me wonder just how many things could have happened since the Universe was created, and so I decided to give it my best (and probably very inaccurate) attempt. There are a few important assumptions/exemptions being done here due to their inability to be quantified for the math. These are (A) The whole of the Universe is the Observable Universe. Since we can't measure what we can't detect, there's no point in trying to guess the true size of the Universe. ( Excluding quantum entanglement, since AFAIK, there is no defined likely hood of two particles being entangled at any given time. © Nothing can happen in an area smaller than a Planck length, or within the time frame of a Planck time, as these give me quantifiable lower limits to calculate from. So, how am I to define what this overall number is? Well, since we have an assumed lower limit of space and time, you can look at the total number of possible things as the total number of Planck times that have passed since the beginning of the Universe for ever single Planck distance in the Universe. Also, before we get started, I'm just going to put it out there that I am in no way a mathematician... I'm just playing with numbers and concepts to see if I can come up with a reasonable result. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- When one does the math, it looks like this: (Number of seconds in one year) * (number of years since Big Bang) * (number of Planck times in one second) * (((diameter of Universe in light years * number of meters in a light year) * (number of Planck lengths in one meter)^3) Plug in everything, and you get: (31536000) * (13.8 billion) * (10^43) * (((93.2 billion * 9460730472580800) * 10^35)^3) Which equals... 2.9833722131840529387713610213106904832991331368301368442... × 10^246 So... now the question is... how completely wrong is my way of looking at the problem?

Maybe I was misinterpreting what you meant by 'downside'. I was thinking by 'downside' you meant that there would be a downside to using the parts altogether. Either way, as you mentioned, it was to imply that there would be some unknown factor that would affect the results, and as it turns out, I have noticed one factor. While I didn't state it in my post, when I did my experiment with the new parts, I found that the increased TWR of the new engines means that they reach a given velocity faster, which means that they reach sub-orbital speeds at a lower altitude. This in-turn means that the player has to burn more fuel (or at least, burn longer) to keep their apoapsis at where they want it. Granted, you still get a noticeable difference in remaining dV by the way I did the experiment, but it does show that untested numbers aren't always the most accurate.

I wasn't too sure about which ISP to use, because while yes the vacuum ISP would be more logical for remaining dV, it would also seem more logical to both (A) use the same ISP for both dV calculations, and ( use the ISP value that will be "used" the most (longest burn time), hence I decided to go with the ground ISP.

That's not implying that there will be a downside to the parts, but rather implying that the parts may not appear to be as overpowered (if overpowered at all) when one actually plays with the parts in-game. - - - Updated - - - You're joking right? We aren't allowed to use rhetorical statements in a lively debate for the betterment of a game? Like... really? Wow...

Introduction: So, as many of you have heard, the new parts have a much higher ISP, TWR ratio, and other such stats as compared to the 2.5 meter parts. While this has caused many people to jump to the conclusion that the parts are OP, I have decided to conduct experiments in-game with the parts to see just how these numbers compare to the actual results of a flight. This is due in part to the fact that I only view "overpoweredness" by the results of an object's application. This experiment tests the balancing of the parts by making what is essentially the same craft in a 2.5 meter and 3.75 meter scale. This should become better explained when the parts list for each craft is stated. Method: Each craft was flown with SAS on and on full throttle so long as the engines wouldn't overheat. If the engines would appear to overheat, the engines would be throttled down as little as possible. All craft were flown eastward as follows: 10 degrees at 2 km 45 degrees at 6 km 90 degrees when apoapsis reached 40 km Stop burning when apoapsis is at 80 km except for small burns to maintain 80 km apoapsis due to atmospheric effects Burn at apoapsis until in a roughly 80 km circular orbit. Circularization burns are omitted to keep the fuel usage as consistent as possible. Record fuel remaining Results: It should be noted here that the ISP used to calculate dV is always the ground ISP. Ship A1: Mk7 Nosecone, RC-L01 Guidance Unit, 2x Z-100 Rechargable Battery Pack, Rockomax Jumbo-64, Rockomax Skipper. dV (300 ISP)=4488.31 Result: 2.8% liquid fuel remaining Remaining dV (300 ISP)=282.301 Ship A2: Mk7 Nosecone, RC-L01 Guidance Unit, 2x Z-100 Rechargable Battery Pack, Kerbodyne S3-14400, Kerbodyne KR-2L. dV (280 ISP)=4495.55 Result: 6.2% liquid fuel remaining Remaining dV (280 ISP)=627.290 Ship B1: Mk7 Nosecone, RC-L01 Guidance Unit, 2x Z-100 Rechargable Battery Pack, 2x Rockomax Jumbo-64, Rockomax Mainsail. dV (280 ISP)=4578.42 Result: 3.7% liquid fuel remaining Remaining dV (280 ISP)=405.136 Ship B2: Nosecone, RC-L01 Guidance Unit, 2x Z-100 Rechargable Battery Pack, 2x Kerbodyne S3-14400, Kerbodyne S3 KS-25x4 Engine Cluster. dV (320 ISP)=5462.68 Result: 9.4% liquid fuel remaining Remaining dV (320 ISP)=626.331 Conclusion: While there was only one trial per craft, the results show that while the 2.5 meter parts gave the craft a remaining dV budget of approximately 280 and 400 m/s, the 3.75 meter parts gave the craft nearly 630 m/s dV after it entered orbit. It is now up to the reader's own interpretation of the data to determine whether he or she believes that these new parts require balancing.

No, it's based on the fact that everybody points to numbers on graphs and not numbers in game. Secondly, I never asserted a downside, so you strawmanned me there.

The issue behind it (from what I can tell) is that people are only looking at the numbers and not actually playing with the parts. They look at the numbers, plot it on a graph and go "WOW, this is way imbalanced" without actually building a rocket with it.

Actually, yes they can. There is a video of a single stage to Laythe on YouTube using nothing more than a turbojet and some Ion engines. EDIT: Okay, that was an SSTO to Eve that didn't use rocket engines. Still, it is possible. Just look up "SSTO to Laythe" on YouTube, and have fun.

Exactly, you can do the same task with both old and new parts, hence showing that they are in-fact similar. Just as a 2.5 meter rocket can hide 1.25 parts in a fairing and put it into orbit, so to can a 3.75 meter rocket hide 2.5 meter parts and put them into orbit with the same general design, and probably get the same (scaled) performance in practice. Who ever said it had to have a lower firing rate? It could very well be equal in all other aspects except for damage, but when put into practice, the gun ends up giving players little to no benefit to their K/D ratio. This may be because the higher damage makes them feel like they can be more aggressive, but in the end are just shot to pieces. In theory, the gun should be OP, but in practice it works just fine. If, in practice, such ease of exploitation ends up coming to fruition, then I'll concede. Until then, one must keep in mind that there were testers before us that clearly thought nothing was OP about the engines, and therefore felt that nothing should be changed.

You have conceded my point, thank you. I disagree. To me, something is overpowered if and only if the application of it shows a clear advantage over other like parts. Think of it like a gun in an FPS game. Just because a gun does 5 times as much damage as every other gun doesn't prompt a nerf if everyone using it has approximately the same K/D rato. You're missing my point. In my opinion, when it comes to video games, the numbers don't really matter. Look at Dungeons and Dragons for example. That game attempts to be as balanced as possible, but people still find builds that break it. In StarCraft II, a game that has professional level gameplay, people keep finding ways to break it even though the numbers might not show it. This goes for just about every game that is stat heavy, including KSP. No matter how clear the data is, if at the end of the day, nobody can utilize them, then the numbers are meaningless.

Well bolding the thrust, and only the thrust is quite misleading.

The funny thing is though, at least with me, is that the new engines are the only ones that feel like real good engines. Now you can build a rocket, that looks like it could work in reality, not be 6 huge boosters around a single core, and actually get something into orbit. You couldn't do that before unless said payload was only a couple tonnes. These new engines allow players to put decent sized things into orbit with rockets that aren't absurdly huge, all while still requiring the need for good orbital mechanics skills. You can throw numbers around all you want, but in the end, more powerful != overpowered. If we are going to talk about the engines being overpowered to the point that they need to be nerfed, we need to see some proof-of-concepts that show that there is something obviously overpowered to the point that it detracts from the gameplay. EDIT: Think of it this way: A realistic (few SRB's, one main core, and one insertion stage) 0.5 meter rocket can get nothing into orbit. A realistic (few SRB's, one main core, and one insertion stage) 1.25 meter rocket can get a 0.5 meter contraption into orbit. A realistic (few SRB's, one main core, and one insertion stage) 2.5 meter rocket can get a 1.25 meter contraption into into orbit. A realistic (few SRB's, one main core, and one insertion stage) 3.75 meter rocket can get a 2.5 meter contraption into orbit. P.S. This goes for any game, you can mathematically make something that wins everytime, but that doesn't mean it will work in practice.

I am well aware that a ratio of thrust is not thrust. The OP explicitly (in bold) stated that the engines used more thrust as a point that the new engines are OP, which I am disagreeing with. - - - Updated - - - The OP complained (in bold at that).

^^This. You people need to remember that KSP is a pseudo-simulator. It uses all the fun equations of rocket science, along with having many IRL engines, but all programmed to work for the benefit of gameplay. Nobody likes doing hour-long burns when you are on 4x time warp, and ion probes have never really been all that applicable for anything aside from landing on Gilly and recreating real-life space craft.

Why do people keep bringing up the increased thrust? It's a 3.75 meter engine, designed to lift 3.75 meter tanks, which are going to be much heavier. The increased ISP is fairly minimal seeing as what you can do with a Skipper engine with the 2.5 meter parts (and nobody thinks that it's OP), and the tech tree is irrelevant, because Squad just decided to compress the tree, instead of adding on to it. That's not imbalanced, it just means you get the parts a bit faster. In the end, the largest parts in the game are still found at he same place in the tree.

Derivatives in terms of mathematics is the slope of the tangent line (i.e. what the slope of the curve at a given point on the curve appears to be). When applied, this becomes the rate of change of something. Here's the example I like to use. Let's say we have a graph that shows an objects' position over a period of time: The first derivative is velocity (the rate of change of position over time) The second derivative is acceleration (the rate of change of velocity over time) There are applications for derivatives above two, but they get much more abstract and less applicable as I understand it.

~75 tons. It was a refueling craft that had two full orange tanks plus some struts, RCS, solar panels, and a Sr. docking port. Made fueling my huge constructed craft much quicker.

Not really, no. While they have a lot of thrust, they are also meant to lift heavier loads. I've already had to add engines to the engine cluster to get more thrust out of my rocket to lift itself up, and the amount I can lift with the new engines is the same that I can lift with the old engines with the same general rocket design. It's all well balanced, with the added bonus that the rockets now look quite real IMO with the 3.75 m parts when you aren't actually trying to lift any cargo into orbit (that is to say, you can make a rocket that looks like it could work in reality, and gets into orbit in-game, but it doesn't actually get any real cargo into orbit).