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.