Aru

Ah, yeah, hosts file, that was it... I guess that answers the question of how I fixed it previously, hah. There must have been DNS issues at the time. My memory is bad. Thank you very much, I can now resume KSP. I never would have thought to check hosts. The fact that the tracert managed to get so close to the server before failing was throwing me off. Literally the only two entries I have in hosts: 87.117.251.9 kerbalspaceprogram.com 87.117.251.9 wiki.kerbalspaceprogram.com

I really want to get back into this game. No one else has this problem?

The same thing is still happening in 1.4.2. I lose several FPS every time I load or quick load, and I have to periodically go back to the main menu. It's certainly playable, but annoying when it creeps up on me and I'm playing at 8 FPS (or worse) before I realize why. It seems to subtract a flat amount of FPS each time, such that the first several have no effect except to increase CPU load, then it takes a few to drop noticeably, then a few more drops it extremely low. I would still like to see verification from someone other than me.

Thank you for your answer. I shall wait for 1.4.3, then, as it is day 7 since it was announced to be released within the next week. I can hold out for another day and deal with a few text placeholders. edit: Or not! It's been two weeks now. Misleading dev post. Post on update 1.4.3

First screen Second After running: KSPx64-Patch-1.3.0-To-1.3.1-1891.exe and KSPx64-Patch-1.3.1-To-1.4.2.exe This is present each time I run the game. I believe, the odd text is intended to be an advertisement for the new paid expansion. The game runs fine, otherwise. There is also similarly replaced text elsewhere in the game, such as the names of the new and replaced parts. edit: I'm doing some research and finding references to a dictionary.cfg file, which is absent from my game folder. I'm starting to think, that the updater was missing this file, or failed to unpack it. Probably the 1.3.0 to 1.3.1. If someone could give me the 1.4.2 dictionary.cfg, I'd appreciate it.

Hi. wiki.kerbalspaceprogram.com (and http://wiki.kerbalspaceprogram.com/wiki/Main_Page which the main page links to), and kerbalspaceprogram.com, and the wiki IP (87.117.251.9), get a time-out when I try to load them. I have the same problems with an alternate web browser (Firefox, Waterfox, Chrome), and with the browser started in safe mode. I have flushed the local DNS cache, and the browser cache, and cleared all kerbal-related cookies. ping fails, and tracert fails after 7 hops through zayo.com, the last being lhr15.uk.zip.zayo.com. Though www.kerbalspaceprogram.com works just fine, as does forum.kerbalspaceprogram.com, and the wiki does successfully load through a proxy, and on my phone (via the same router). Perplexing is that the tracert only fails (presumably) just before or after reaching the wiki. I'm having to manually insert "www" into official site links. Obviously this doesn't work for the wiki, it's the wrong subdomain. This official wiki is essential for how I play this game. I faintly recall having similar problems in the past, but I don't remember how it was fixed. I do remember, that the problem will not go away on it's own. I have no idea what's going on! I want to play KSP, but I cannot play it seriously without proper access to the wiki. If anyone has any ideas for diagnosing or fixing this, please let me know.

I want to do something similar, but without using any existing approaches, made from scratch, and for the game with vanilla physics, parts and massive bodies. But, I have vast amounts of information I still have to find in the game code, and I can't seem to find any of it. Some of it, I know what it's based on, and I have good approximations, some of it I do not, but I want the exact code for all of it, retrieved myself. Orbital stats of planets and moons, atmospheric density-altitude and pressure-altitude profiles (I think this depends on temperature too which depends on latitude and time of day), engine Isp-pressure profiles (each one has a unique curve, not linear, so I want the formula and constants behind those curves), the *full* drag system and code preferably (I have an idea for a simpler version, which assumes ship is always pointing prograde in the atmosphere, and assumes that cross-sectional area times drag coefficient is constant for each stage, and requires calculating that product experimentally for each stage in advance... it could, perhaps, save those constants along with a hash of the ship design for future reference.. I'd also have to verify that it really is mostly constant). So, pretty much everything that isn't already obvious. I think that's it. I doubt I could persuade myself to do such a thing, if I didn't have all the data I need to do it perfectly. Oh... it's also possible that I'll want to leverage the kind of computational power that's at my fingertips, which they didn't really have back in the early space shuttle days. kOS might not be fast enough for the precision I want, but I could probably interface it with Python and SciPy through a text file without too much hassle. I want to calculate truly optimal full ascents in the stock KSP universe, from scratch! This is the essential spirit of kOS after all, just taken to an extreme. I am okay at examining decompiled C# games, good with code, physics, control theory, numerical analysis, all that stuff, buuut I've never made a mod for anything before. That might help to explain why I can't get the information I would need first.

If you were versed in these things you'd know that asking how to "allocate more RAM" really just doesn't make any sense unless you're programming something. Memory is continuously allocated and deallocated by software as needed, it's a continuous process. The only possibly relevant limitation I can think of would be the addressing limit of a single 32-bit thread, which is on the order of gigabytes, but KSP is released with a 64-bit build so it's not relevant. If memory usage were going up and up continuously until you ran out, more than it should, that would be a memory leak, a lack of deallocation, which still wouldn't be a problem until you ran *out* of memory... that is, after all of it is already allocated. But you imply that you have memory to spare, room to allocate, so this isn't the case. The operating system imposes no arbitrary limitations on how much memory a program can allocate. Computer resources are there for the taking, for every single thing running on it. Maybe this will help you to understand why your question doesn't make sense? Only the program allocates memory, and by extension the programmer, it's not even a thing for end users.

Prioritizing aesthetics, creativity, time, ease, practicality or anything else over size and weight efficiency. It kind of makes the game boring and unsatisfying since I haven't found all the drag code, but that's the way many games go for me... it's a curse.

This is of course true, and is easy enough to do. But it's not something the average player would think to do on their first attempt, or their second... or their third. I know to add the new stage above the bottom one NOW, and I know that there is no real purpose to ever adding stages at the bottom. But the interface doesn't suggest this... and why does it allow us to put stages on the end when they can't do anything, and serve no purpose? It's just unnecessarily confusing for both experienced and inexperienced players alike. And, I never did fully understand the blinking light, thanks. It's not *directly* related to what I was talking about, though, it just adds an extra key press after the staging is changed.

I am talking about the graphical depiction of staging on the bottom left. After struggling with a mission to activate a radial decoupler (more than once) and realizing that in order to activate it at will (that is, when mission conditions are met), activating it manually doesn't work, and adding it to a stage at the bottom doesn't work. In fact, putting it in any stage, and staging all the way to the end, does not activate it, not even after attaching an ant motor (I thought, perhaps it does not stage with nothing attached, but that wasn't the problem). The solution is to add it to a new stage at the bottom, then add a second, empty stage below that one, before I can finish the mission. It took a surprisingly long time to figure this out, despite being experienced with the staging system! Then, I thought about the staging display for a while. It occurred to me, that for the system to work and display the way that it does, a displayed stage depicts the activation of both engines and decouplers (I know this is obvious, bear with me). When activated, previous stages disappear, the decouplers are extracted from the stage's graphic, and the engines turn on (but remain in the graphic). The next time the stage button is pressed, the stage *above* the bottom stage is activated, and the bottom graphic is dropped. I imagine that the motivation for basing the system this way, is that the disappearance of a stage in the GUI represents physically dropping the corresponding stage. This sounds okay to me, in principle. But, it does not directly depict fuel tanks, or any other parts which are physically dropped except for engines and parachutes (for the most part). The decouplers are not "dropped" per se, and in this paradigm they disappear prematurely anyway, as they are extracted from inside the bottom stage. Truly, the only consistent paradigm is one where each stage represents activation. Pressing the staging button can never interact directly with the bottom stage. It only activates the second-to-bottom stage. Then, the current moment in time is a line between the bottom stage and the second-to-bottom stage. (There is a single exception, which further works against intuitive consistency, in that before launch, there is an invisible bottom stage which represents idling. This is the only time that the apparent bottom stage can truly be activated.) This becomes more intuitive the more you play the game, but only as a matter of learning and practice, causing us to forget that there's anything wrong, but there is. ------------------------------ The suggestion and summary: Overall, the system is fine mechanically, but it's depiction is unintuitive, which is made especially apparent when you want to make quick changes after launch. It is lacking something. A simple improvement might be that, once the rocket is launched, the bottom stage changes it's border from orange to say, green. Or once launched, a literal line does in fact appear between the bottom and second-to-bottom stage. Anything to visually declare that activation of the bottom stage is now in the past, can never be activated again, and the second-to-bottom is the nearest stage in the future, and therefore the one which corresponds to the next press of the staging key. Anything to show that the bottom graphic is activated and cannot ever be activated again, unlike every stage in the group above it. It should be visually distinct, separate from the rest, one way or another (except before launch). And furthermore, it should be made impossible to add stages below the "green-bordered" stage, because as far as I'm aware it is literally impossible for the added stage to have any effect except to self-mislead. I know it's a very simple suggestion and a subtle change, I apologize for being verbose but it's hard to explain that there's even a definite problem or to identify it because we learn to work around it quickly enough, for most purposes. I think, the staging interface (and it is a critical interface, not just a display) will make more sense this way.

I'll quote another post of mine, "But of course the real Kerbin density changes rapidly, it doubles going from about 5300 km to 0 km. Some rough density "half lives": 5300, 9700, 13200, 16800, 20200, 24000, 27500, 32000. So that's about 1/256 of surface density at 32000 m. This also gives an idea of how quickly engines change from their ASL stats to their VAC stats, though that depends on pressure rather than density." Density and pressure are closely related. Drag depends on density, engine efficiency on pressure. Similar numbers for pressure: 4400, 8200, 11800, 15300, 21300, 22500, 28400, 30100. About 1/256 surface pressure at 30100 m. So at 30100 m, the Isp and thrust are 255/256 * VAC and 1/256 * ASL. Halfway from ASL to VAC at 4400 m, three quarters of the way at 8200 m, etc. The ASL stats really only matter for the lowest part of the ascent. But to be fair, you do spend a somewhat disproportionate amount of time in the lower atmosphere because you start at 0 speed and accelerate.

Game version: 1.3.0.1804 System: Ryzen 7, 16 GB of DDR4, GPU is RX 470 There's a CPU performance leak every time the same game is loaded. Make a quicksave in orbit, and load it. Eventually, frame rate will start getting worse after each load as CPU use goes up and up. Load 20 times in a row (this is what I did to verify the mechanism), and the game runs DRAMATICALLY slower. I'm not certain whether it's only quickloads, or if repeated normal loads cause this as well. Back out to the main menu, load the same game, load the same quicksave, and the leak is reset. Make a new quicksave and load it, load the main save, or return to space center, and it's still in full force. So, it can really build up over a long play session, as long as you don't go back to the main menu. I first noticed this quite some time ago, but I didn't report it because I assumed that such a thing would already be known. But I see now that I should have reported it. edit: I should add, that this is not really a support request, rather a bug report. The guide called this "The Stock Support & Bugs forum", but I guess it was renamed. There's nothing else to suggest that this is a bug report forum, but the quote makes this the closest thing I could find. edit: Can anyone else verify this? Is it a known bug?

Hello, I wanted to show my appreciation for this mod. I never would have guessed that one seemingly circumstantial graphical effect could raise the apparent tier of quality and realism in the rendering of the entire game! I'd think this was an entire graphics engine overhaul mod for the impact that it makes if I didn't know better. I think PlanetShine is a prime candidate for integrating into the base game. It makes the whole experience that much more beautiful.

Kerbalands 2 "But I wanted to be a BadS..."

That's quad core, it should perform very well.

I didn't think anyone still made single-core cell phones, let alone desktop computers...

It took me a moment to realize you weren't saying it uses a single-core CPU, hah.

Now you simply must learn the art of finding killer deals on upper-low-end parts. Newegg has the best search filters by far, and good selection, so I have a firefox addon called "hover hound" which compares prices with Amazon and NCIX, and shows price history.

1:25 with SSD, should get faster after I upgrade to Ryzen... I remember how painful it was before the SSD. I'm guessing CPU is the limiting factor now.

You tell me... The thing that's really holding me back is that I can't find all of the drag code. I have to fully simulate drag to advance.

The game wraps a whole bunch of different numbers together into a composite "coefficient of drag" for each presented part. The rest of the calculation is simple enough, though. I really, really want to get into the drag code, but I can't find anything in there that mentions drag cubes. I've looked... To really reach terminal velocity by falling, or more accurately to asymptotically approach it, you have to fall for an indefinite length of time, in the same orientation, through an endless atmosphere which has the same density at every altitude. But of course the real Kerbin density changes rapidly, it doubles going from about 5300 m to 0 m. (Some rough density "half lives": 5300, 9700, 13200, 16800, 20200, 24000, 27500, 32000. So that's about 1/256 of surface density at 32000 m. This also gives an idea of how quickly engines change from their ASL stats to their VAC stats, though that depends on pressure rather than density.) When a large, dense object comes in fast like the Chelyabinsk meteor or Tunguska event, neither one dropped to anywhere near terminal velocity before almost reaching the surface. Similarly, a dense rocket can easily come in and reach the surface going much faster than terminal velocity, and it can also ascend faster, or slower. So, terminal velocity is not as immediately useful or intuitive a number as many people think for large, dense objects like metal ships. Even more so because successfully reducing drag with nose cones and reduced profile area increases the terminal velocity, which is a good thing. I think terminal velocity on Kerbin is sqrt(m/A/p/C*9.81*2)/(1+altitude/6e5), where altitude is in km, m is ship mass in kg, A is the profile area in m^2 which is presented to direction of travel, p is atmospheric density in kg/m^3, C is drag coefficient weighted by profile area and has other things in it. Note that the "9.81" is for calculating Kerbin's mass, so it's constant with altitude. This is density as calculated at 232 data points from the USSA formulas, which are nearly entirely accurate with the exception that, I think, Kerbin temperature varies from standard temperature depending on latitude and time of day. Compared to the USSA, the altitudes are reduced to 80%. The graph to 40km is on the Kerbin wiki page. https://docs.google.com/spreadsheets/d/1MkjDjxzgPV9_FNodnoDsBUuI-dcXZmvifoD6KwK6nOI/edit?usp=sharing

Aaaand now I learn that temperature depends on more than just altitude, it varies by time of day and by latitude. Guess I'll have to try to figure that out too. The closest I could find to anything about mechanics, was DragCubeSystem.CalculateAerodynamics, which increments a variable "drag" by this.dragCurve.Evaluate. The only thing in the whole file that sounds promising. But, dragCurve is an instance of AnimationCurve, which is graphics stuff that comes straight from the Unity engine. Ugh. I'm having a hard time finding these things, so if anyone could tell me where to look for the code for 1] drag mechanics, 2] engine thrust-pressure profiles, or 3] how temperature varies by latitude and time of day, I would appreciate it, because I need all three. My objective is to fully simulate ascent from Kerbin (and also orbit and interplanetary travel, but that really doesn't need any additional information). I have trudged through an awful lot of compiled C# for other games, so all I really need is to know where to look, because it's not as obvious as I was hoping. Very late edit: I'm not really any closer to this simulation now, but just in case this matters for anyone, AnimationCurve is a cubic Hermite spline - a spline of cubic polynomials. Unity uses it for animation, KSP uses it for many different things, including evaluating atmospheric pressure and temperature, and probably engine profiles. An AnimationCurve contains many keys, which have 4 numbers each: time (altitude), value (pressure / temperature), and slope on each side of the point. The two slopes are usually identical, else it has a discontinuous first derivative (a jerky animation, if used for positions in an animation). Pressure is based on a single celestial-body-specific AnimationCurve (atmospherePressureCurve), temperature is far more complex as it is calculated from several factors: distance and angle to Kerbol, and two body-specific AnimationCurves (atmosphereTemperatureCurve and atmosphereTemperatureSunMultCurve). Density is then a function of pressure and temperature. The drag mechanics are as elusive as ever. Presumably, it is "extern" and calculated by something written outside of C# for better performance.

I made that altitude-density function, based on U.S. Standard Atmosphere and reduced altitudes to 80%, as it says in the wiki. It looks very similar to the shape of the pressure curve. And, I gathered that sea level is 600 km from center of mass everywhere (sphere, not ellipsoid), gravity is exactly 9.81 m/s^2 (instead of 9.80665), gravitational constant is the same, and from these things Kerbin mass is calculated as 9.81/G*(6e5)^2 ~= 5.29151337e22 kg. All that's left to simulate ascent, is to understand the drag system. I've been looking at DragCube, DragCubeList, DragCubeSystem, but it seems to only be about graphics. Could someone point me toward the code for the mechanics? edit: Oh, and I got sidereal velocity at equator as (6e5m + altitude)*2*pi*427 / (426*6*60*60s), which ~= 174.942627 m/s at altitude 0. edit: Now I learn that the engines have complex profiles for thrust, so I guess I will have to figure that out too if I want to properly simulate and optimize things. (Image taken from another post.)

Thank you, all three of you. I looked into the code, and I found DragCubeList, but nothing about how it translates to force, or atmospheric density.