MaxPeck

I have a suggestion/request for you. I've been playing with the Lackluster Mod that has a bunch of antennas included in it, and so I had to go and write a MM cfg to include all the additional antennas. It was kind of painful, and I was left trying to come up with nominal ranges for a bunch of antennas using the stock values that are hard-coded as a baseline. In order to come up with something reasonable that wasn't a bunch of arbitrary values, I developed a method for calculating signal quality based on power and bandwidth. What I did was look at the bandwidth and packet size to figure out how many packets per second could be transmitted, and then looked at the power requirements per packet to figure out the power/second being transmitted, which I decided was the signal strength of the transmitter. I then ranked the antenna according to signal strength, graphed the stock ones and then figured out where on the graph the others fit in. Then I just overlaid that graph on another chart of ranges and used that to determine the nominal range for each antenna. I'm sure someone better than me at math could do that part, but the signal strength calculation is pretty consistent. For example: in Lack's antennas, you have the Communitron 32 and the Omni Radar, both of which have similar values: Name Bandwidth (mits/sec) Packet Size (mits) Packet xmit time (secs) Packets/sec Packet Power (amps) Signal Strength (amps/sec) Communitron 16 6.6 2 .30 3.3 15 49.5 Omni Radar 6.6 1 .15 6.6 7.5 49.5 So while they both have the same signal strength, and thus the same range, the Omni transmits data at twice the rate, so it's a higher speed connection over the same range. So in this model, the bandwidth essentially dictates the gain of the antenna - low bandwidth will require more power/packet (low gain) to achieve the same signal strength as a higher bandwidth, but lower per-packet power requirement (high gain). So the high gain antenna would utilize the same amount of power per second as the low gain, but transmit more data over the same range. Bringing this full circle, I guess my suggestion/request would be to code this method into the antenna range mod, so that instead of needing a cfg or MM config for each antenna, your mod could just read the bandwidth, packet size and packet power values and calculate the signal strength, and then apply a nominal range based on whatever scale you think appropriate. Did that all make sense?

xfrankie - that did the trick, thanks!

So I installed this, and the jump beacons are showing up in the VAB, but not the Jump Drive. I have my tech tree maxed out, I've watched the log and it seems to load okay, and the jump drive shows up in the part database. I'm not sure why I'm only getting the beacon and not the drive?

I've been thinking about this too... something akin to moving the two assemblies close to each other and then "welding" them together. Not welding in the reduce-part-count type of weld mod that exists, but something to the effect that if you can make two things touch, a Kerbal should be able to join them. Maybe make a "welding torch" tool that can do this? I don't know the programmatic gymnastics this would require, but from the standpoint of balance, it would make sense to be able to join things, regardless of how many other things are attached to them (i.e. command pods with parachutes attached to a rocket assembly).

Sorry if this has already been brought up, but I didn't see a thread for it. If there's already a thread for this, feel free to merge this. I've been experiencing an issue intermittently where I get a vessel into orbit, and try to warp to the circularization burn. After a few seconds of warping, the vessel is suddenly sailing out of orbit, but with no change in velocity, it just starts gaining altitude like crazy. Throttling up increases velocity, but does not alter the rate of ascent. The vessel becomes unmaneuverable like it's still on rails, and it won't let me re enter warp because it claims the vessel is under acceleration, even with all engines deactivated and/or the batteries dead. Trying to switch to another vessel or the KSC gives a revert warning. I didn't post logs because there's no crash, the vessel just goes rogue. Running on a MacBook Pro mid-2014. Running several mods, but appears to happen most often during a mechjeb auto-warp. Any thoughts?

Yeah, the OS X version is half-baked. Try this, it's worked for most of us, it seems.... http://forum.kerbalspaceprogram.com/threads/125288 Hopefully Squad will get their act together with the U5 update and actually give us a playable game. For my own part, crashes are fairly infrequent after using the steps described in that post, but when they do happen, that's usually my cue to take an intermission.

Hey, can we sticky this? There seems to be an influx of new mac users hitting the usual bumps in the road. Be a lot easier if this was at the top of the forum, instead of all these folks putting up new threads for an old (and well known) problem. Thanks!

I'm assuming your iMac has a retina display? If so... Two things... for some reason, Retina displays freak out when you use textures above 1/4... you should dial that back. Also, make sure you're running in low res mode. Right click on the KSP application in your KSP_osx folder and choose "show info". Under options, make sure "Open in Low Resolution" is checked. I was having this same issue on my brand-spankin' new macbook, and dialing back the textures to 1/4 or 1/8 solved a lot of problems for me. Might not be cinema quality, but it's playable.

Okay... first question about killing the KSP process... I've only noticed the phantom KSP process when I have to force quit the game after it hangs. So that's when you'll want to do that. If I quit normally, it looks like everything goes back to normal. As far as running in low res- as I understand it, all that does is disable Retina for that window and allows it to run in normal resolution. As I understand the way that retina works, basically it's a super high resolution screen that scales down to normal resolutions to proceed really high-fidelity graphics. Basically, the pixels on the screen are smaller, so you can use more of them to draw and create finer resolution images. Running in low res basically disables that and allows KSP to run under a normal resolution. A conflict appears to be occurring for retina users because of the way OS X packs graphics in a retina display. As far as ATM - there is some debate if it's worth using right now. I think it is. What it does, in a nutshell, is take standard graphics formats (jpg, bmp, png) and compresses them on the fly into more a more efficient format - DDS - that eats less memory. Think of it this way, if you have a jpg image that's 128x128 - and jpg's store data at 24 bits per pixel (8bits for red, 8 for green, 8 for blue), that's 128 * 128 * 24, that's 393,216 bits per image. At 8 bits/byte, that comes to 49k per texture file. In comparison, DDS only uses 5 bits per color channel, so you get 128 * 128 * 15 = 245,760 bits per image, or 30k per texture file. The real benefit comes when your jpg files are 512x512 or 1024x1024 and you use aggressive ATM to reduce them to 128x128. A 512x512 jpg would be 6,291,456 bits, or 786k per texture file. Compare that to 30k per texture file. There's quite a bit of savings there. This doesn't even begin to touch on DXT compression. For your eyes, you won't see hardly any difference between jpg texture maps and DDS texture maps. In fact, most mod designers are already using DDS, which is why ATM might be a moot point. For those who aren't, however, there is some memory savings to be gained from using it.

Tom, Try the tweaks listed in this thread. They really do help. I'm pretty much able to play without crashing, unless I do something really stupid like have a bunch of windows open and then try to change scenes. I play with about 20 mods, including KIS, KAS and a bunch of parts packs, and while my graphics res isn't ideal, I can at least play for several hours without disruption. ///on another note/// I noticed something new this morning. I have a memory monitor app installed, so I can keep an eye on my system memory. I generally hover around ~6gb free space when I'm not doing anything, but after a KSP hang yesterday that required a force kill, I noticed my free memory never recovered. It was hovering around 1.5gb with nothing open. I force killed everything and didn't see any improvement. So I started nosing around in activity monitor and there was nothing in the memory usage tab, but under the CPU tab were two instances of KSP, one of which was running at about 55% CPU usage. I forced them to die, and immediately recovered the missing memory. So thought for the day - if you have a KSP hangup and force kill the app, go into activity monitor and look for lingering processes and kill them too. Otherwise, it seems like you get into a spiral of diminishing returns that leads to eventually running out of memory.

If I were going to describe it, it's like a big outer space hot dog roll. I think I see what you're getting at, but you really have to tweakscale it up a few notches to be useable.

Okay, maybe it's just me, but for the life of me I can't figure out what the radial dock is for.

Actually, that's on me. I just realized I'm on 1.0.3 and the current version of firespitter says it's for 1.0.4, so it's actually me that's behind, not the plugin. D'oh.

On Kerbalstuff it says that 7.1.4 is 1.0.4 compatible, but in AVC and the load screen it's still flagging it as incompatible. What's the deal?

What I usually do is take a pylon with me, stick that to the ground, and the stick the part to the pylon. I've found that certain parts become rather... explosive... if you let them touch the ground. And whatever you do, don't try to move an Infernal Robotics part. They're apparently made of solid rocket fuel wrapped in TNT. I actually got a Kerbal almost into Mun orbit trying to remove an extendatron.

You know what? I'm actually starting to enjoy the game for what it is. I've added some mods, tweaked the graphics settings, added ATM. I can play for anywhere from 20 minutes to several hours depending on what I'm working on. I've actually worked the crashes into my gameplay... they're like little intermissions so I can use the latrine and grab a sandwich, or do a reality check as to how long I've been playing. I complain a lot about the fact that the game is crashtastic, but at the end of the day, it's still the most fun game I've ever played. I think that's why the crashes are so frustrating, I get so engrossed, it's like literally being slapped awake from a deep sleep. Ah well, back to my munbase.

Hey guys... It's a known issue.. there are threads on here devoted to this here: http://forum.kerbalspaceprogram.com/threads/125288-The-Mac-OS-X-Thread and here: http://forum.kerbalspaceprogram.com/threads/116985-1-0-Constant-crashing-on-OS-X One of the mods has set up a couple of polls to gather data on what's going on.. please come participate in those threads and help out!

So I have a Macbook Pro Retina 13"... according to my tech specs, I have an "Intel Iris 6100", so I chose "no discrete video card". Hope that's right..

I did skip a step. After right clicking on KSP, you have to choose the "show info" option. The low res option is in there. The game has become much more playable, albeit some of the flags and such got borked by ATM. Still crashes pretty consistently during scene changes... Although that's not totally accurate. It doesn't crash per se, it hangs. I let it hang for a while yesterday and it never unhung, and activity manager showed a steadily increasing number of errors. I was closely monitoring the app's memory usage and it was under 3gb, so I don't think it was a malloc issue, it looked like a bad call inside the program. Like it was trying to call a non-existent memory address, and then hung because nothing was returned.

You are a Titan among men for addressing this. Thanks.

Welcome to KSP on OS X, where crashing and rebooting is actually part of the game. You may enjoy this thread: http://forum.kerbalspaceprogram.com/threads/116985-1-0-Constant-crashing-on-OS-X/page14 The lack of support for (or even acknowledgement of) constant OS X crashes is beyond frustrating.

I think I found a combination that makes the game more playable, although not perfect. I added Active Texture Management, the aggressive version. Then, for those of us with Retina machines, go to your KSP folder and right click on the KSP icon. Check the box that says "Open in Low Resolution". The game seems to crash less in-scene, although it still tanks when changing scenes. Memory usage is WAY down, and the whole game just feels much more responsive. I was able to play for a solid hour today, and only had to reload when doing scene changes (orbit to space center, VAB reverts and such). Hope that helps out someone...

Wait... they "pushed" a game that's broken, gladly cashed our checks and then went on a much-needed vacation. 1/3 (or more) of their customer base is screaming that the product doesn't work as advertised, and the best we can hope for is a fix maybe in time for Halloween? So until then, we just get to have a broken release? Who cares about 1.0.3? What's the point of pushing out another update if it *doesn't fix the major issues in the game*? Isn't that kind of like putting new tires on a car with a broken transmission? If it takes a transition to U5 to make the game work (and there are boundless issues on all platforms from what I can see) then I think they need to make that a top priority. It seems to me that "push a mostly working update, and fix the issues a few months later" has already happened with 1.0.X It would be one thing if it were a minor bug and people were just being nitpicky, but having to reload the game every few minutes because it melts down due to known defects shouldn't be acceptable under any circumstances. I would like to see some acknowledgement in the devnotes, some kind of proactive steps that make me, as a paying customer, feel like this product is worth my money. And for what it's worth, I bought it because it's a helluva lot of fun when it works. I've recommended it to my colleagues, and for the record, I'm a college aviation professor who has given serious thought to ways to use the EDU version of the game. But not like this, I'm embarrassed enough to have recommended that my friends and colleagues buy what amounts to a broken game, I'm not about to bring this into my classroom until it's fixed.

You know what would be awesome, since many of us are having this issue? Any acknowledgment from Squad whatsoever that they're aware of it and working on a fix, instead of just letting us twist in the wind. I don't often buy computer games, but this game was so compelling to me that I just had to plunk down my money. I absolutely feel like I got sold something that should be a release candidate, not a production game. This is a major issue affecting a large segment of your user base. At least address it, let us know you're working on it, something. It's called customer service, and it's not exactly a new concept.

I agree with fluxx above. This isn't a new or isolated problem, it's a well-known one. Fix this. So here's one from last night. I had just shot a rocket at my orbiting station and was on final approach to dock, I selected a docking port to attach to, and as soon as I moused over the docking port - blamo. The whole works froze up and I got the spinning beachball. I haven't been able to find "player.log", so here is the tail end of my KSP.log. It's thousands and thousands of lines of [LOG 13:57:26.551] Look rotation viewing vector is zero Followed by: [LOG 13:57:36.609] Look rotation viewing vector is zero[LOG 13:57:36.751] Look rotation viewing vector is zero [LOG 13:57:36.891] Look rotation viewing vector is zero [LOG 13:57:44.644] Unpacking Reach Station [LOG 13:58:47.645] [Orbit Targeter]: Target is probeCoreOcto (Reach Station) [LOG 13:58:59.294] [CurrencyConverter for Outsourced R&D]: 0 Funds taken, yields 0 Science [LOG 13:58:59.294] [CurrencyConverter for Unpaid Research Program]: 0 Reputation taken, yields 0 Science [ERR 13:59:08.963] Could not allocate memory: System out of memory! Trying to allocate: 26272B with 32 alignment. MemoryLabel: VertexData Allocation happend at: Line:122 in Memory overview [ ALLOC_DEFAULT ] used: 397077722B | peak: 0B | reserved: 441696388B [ ALLOC_GFX ] used: 288787364B | peak: 0B | reserved: 337004496B [ ALLOC_CACHEOBJECTS ] used: 90088B | peak: 0B | reserved: 12582912B [ ALLOC_TYPETREE ] used: 5703B | peak: 0B | reserved: 4194304B [ ALLOC_PROFILER ] used: 71604B | peak: 0B | reserved: 4194304B