johnsonwax

Question for the experts. If I want to keep a part from loading, and the part has a .cfg, a .mu, and a .tga or .png I can compress the .cfg and it'll disappear from the editor, but is KSP still loading the .mu and/or the .tga/.png? My assumption was no, that KSP parses .cfg files and then loads assets referenced by the .cfg, but I'm wondering if that's accurate - do I also need to compress the .mu/.tga/.png?

Oh, that's what that red dot is. (This forum needs a derp tag more than any other ever)

Ok, this is working ridiculously well so far. Much faster and my RAM usage has remained in check. The only problem I can report is that the thumbnails in the VAB that are shown when you rollover sometimes stick - if I rollover one part, it'll pick up the thumbnail properly, but show the same one on the next part, etc. until I move the mouse away from the part picker and then it resets. It's possible it was doing that before and I upgraded to 4.0 just didn't notice, however. And it only does it in a few places, not everywhere. But KSP is playable again. Thank you a million times.

I was being snarky. I can usually only keep KSP running for about an hour before it runs out of RAM and crashes. If it takes 90 minutes to compress the textures, it could be the longest KSP session I've had in a while, and that alone is something to be happy about, even if I'm just playing the slow progress bar mini-game. But between this and the new MM release which caches patches, my frequent reboots might be much more tolerable.

Here's the ATM 4.0 game: Does it take longer to convert your textures in 4.0 first pass than the game previously ran without crashing due to hitting memory cap? I'm going out on a limb and say that even on my quad i7/SSD machine, that KSP will run longer in the first pass without crashing than it has in the last week.

So, do I understand correctly that this makes DDSLoader effectively redundant because it's converting all textures to DXT, caching them, and then using them natively?

Procedural RTGs should be fairly simple to do.

If I may make a request. I had created a MM rescale pack for the old THSS trusses to address the problem that the truss lengths were not consistent. That is, two short trusses were not the same length as a medium truss, and none were any sort of standard length, which made creating modular structures effectively impossible. We have standard diameters (1.25m and multiples/fractions thereof) but not lengths. I had modified these such that the standard length was 1.25m and then welded those together to form longer trusses, reusing the same model to reduce model/texture counts to save RAM. It made them far more flexible. One option if you don't want to rescale parts already deployed would be to turn the short, atomic length parts into procedural parts, so that you could iterate through 1.25m/2.5m/3.75m (or 1, 2, 3m), etc. creating as long a truss as you needed from a single part. I'm sure you could get the code for doing that from one of the procedural modders. Since procedural tanks already specify such lengths, you could easily pair up parts from different mods to put together stations and such like legos.

Shame. That'd be damn handy. Thanks.

So, a problem many of us face is that we hit memory limits on parts under 32bit. Until that whole 64bit mess is sorted out, many of us have to resort to selectively removing parts from mods, which is a pain when it comes to updating modules. Would it be possible to specify in MM that a part should not load at all? Or, that a part should be unloaded, since I believe MM runs after parts are loaded. In my case, I can get the parts loaded, but once I start playing I run over on RAM, so even just unloading those parts and textures would help. Doing this via MM would make it sustainable - I could just have a master unload file that I update and not have to worry about parts being re-added when I update.

That's how I interpret it as well. I think if I make sure I don't add the SPU to manned capsules, or make sure to set their minimum crew to 0 in that case, that'll also solve the problem.

alexustas, Is there any chance you can address the transparent cockpit lag? It's almost unbearable to have to disable that because it's so unbelievably cool. Roverdude has a transparent cockpit in his USI Exploration Pack that doesn't seem to lag, so I think there's a technique out there which avoids it. Not sure if it'd meet your requirements, but it might be worth an ask. It uses USI_ClearIVA module to get a transparent cockpit on the EVA Pod.

Ok, almost solved. Got the rover (root part) manned and the Flight Computer spam ended, so that was clearly the source of the problem even though it wasn't the unit in control. I'm guessing I have ModuleSPU getting added to the manned command modules and that's what freaked it out. I've been away from this a while - gotten a bit rusty.

I've added the MJ module via MM. I'll go through those and try and narrow the problem down a bit. It's a complex craft at this stage - a transfer stage with a probe core so that it can be re-entered (I need the money - hard career), there's the manned lander, there's my Mun mapping probe, there's a skycrane/rover combo that has both a manned capsule and probe core on the skycrane (the capsule is currently unmanned) and the rover is currently unmanned. There's a separator between the transfer stage and the various landers/probes, but the rest are all connected via docking ports, as some will return. What's probably the issue is that the whole mess was constructed around the rover as the root part, but it's unmanned (and therefore doesn't have the minimum crew) and I'm controlling it from the lander. Let me poke at it a bit, iterating through which parts are in control and maybe enable/disabling some things. I think you've got me pointed in the right direction, thank you. I may have my MM configs a bit hosed, so I'll look at those as well.

I'm stuck on a strange problem, and I'm not sure if it's RT or some other mod causing it. I'm getting this message spammed to the screen: [Flight Computer]: Out of power, cannot run 'Target Mun' on schedule. I'm running MechJeb on a manned ship with a probe and a few landers attached and trying to to a Mun transfer. Everything else is working fine, the ship is maneuverable, MJ seems to be happily doing it's thing, but if I try to warp I get the following message mixed in: [Flight Computer]: Throttling back time warp... And it won't allow me to warp to the next maneuver node. The ship has loads of power (4000 in the batteries) and two solar panels deployed collecting 24 units/sec. There's nothing in the logs or anywhere else that I can point to. Does this look like a RT message? Just trying to figure out where to start on this one.

I once depleted 1/3 of Minmus's Kethane with a single fueling ship (two full deposits plus part of a third). Took about 3 days in-game time to do it, including moving from deposit to deposit. Not very realistic. What would make more sense (though I still wouldn't advocate for it) is to be able to exhaust hotspots while leaving a residual concentration behind. Even there it's not worth doing because even with things like TAC, there's no cost to sitting there mining stuff for hours on end, so it becomes an exercise in warp control. If I'm reading Rover properly, his EL integration will mean you need to get a diversity of resources, possible from different places but certainly in different concentrations in order to accomplish things. And the mechanic for Karborundum where it's quite scarce to find at all is intriguing as well. The scarcity angle can actually also be solved by adding drills in the tech tree that are increasingly efficient for geometrically higher cost and mass, and/or limiting access to low concentration resources until you get those bigger drills. And that kind of stuff can be easily modded in by the player using MM.

Looking at this for the first time. For a skycrane an extremely handy option would be for it to be able to hold altitude but match a specified target's lat/long. That way you could have it easily come in and hover over a vessel to be lifted. Since you're checking ground height, you basically have a terrain following craft that could track to a given target. If you can hook into the gimbal that alone might give you the horizontal acceleration you need, then it's just doing the coordinate translation to home in on the target.

Right. You can launch manned with no problem. If you're failing, that shouldn't be a problem with RT. If you launch unmanned, you'll want the Reflectron DP-10 which has a range of 500km. It'll get you to orbit if you take a pretty vertical approach. If you do a nice efficient gravity turn, you'll possibly go out of range of KSC before you can circularize. Add on any longer range one and you'll definitely be fine, but you'll need to activate it before it'll work, and you'll want to do that via action group around the time you punch out of the atmosphere. RT requires a layered communication approach. For anything more permanent or more distant, you'll also want to add a suitable length dish and activate + target it before you leave range of your shorter antennas. I typically have 2 antenna and 1 dish minimum on my craft - the Reflectron which is always on, the Communotron 32 which is the longest antenna, and then a dish that has roughly double the maximum range to Kerbin so it can reach sats on the far side if need be. Since dishes can only interact with one target, if you are setting up a network, the craft that form the network will likely need multiple dishes - one active craft target, one KSC or relay target, and then one or more to target outbound craft and/or other relays for redundancy. And the probe cores do come with a 3km built-in antenna, but you need to manually unlock it under the advanced unmanned tech science tree node if you're paying for parts. Handy for rendezvous and station runabouts.

I'd like to see a way to add contracts of the following sorts: * Establish a continuous connection from Jool to KSC for 1 month [RemoteTech] * Deliver x amount of Kerbonite or Kethane to orbital station y [resource mods] * Exchange the crew of orbital station y * Build a self-sustaining orbiting station (keep food, water, oxygen above 90% capacity for 1 month) [OKS/MKS, TAC] Would these require hooks from the mods themselves to support? Would we need some kind of indicator on an orbital or ground station - e.g. a part that says 'this is a permanent station that should be a target of contracts'? Looking for some way to shim in logistical simulations now that we can do fairly interesting things. It's cool that we can lasso a class E asteroid and mine it, but in a career game that's largely a volunteer effort, where a resource contract might justify the effort.

LLL has (had?) a cargo bay with a hydraulic floor. You could put a collider and solid wall on the rear of the bay (connected to the floor so it also lowers - maybe a grid or some such) to attach docking ports to attach the rover, then lower the bay when landed and drive off. Could also use it for air-launched cruise missiles.

I have a feature request that I think would open up some new use cases. I like to put up properly spaced geostationary comm networks (Remotetech) that are stable over time. Ideally, that means parking a satellite directly over KSC but I realized that the easiest way to do that is a launch aiming for 2868.75 km and using the Kerbal Engineer HUD to keep horizontal surface velocity at 0. So, what I'd like is a button in the launch profile or some such suitable location to launch directly into a geosync orbit directly over the current location (keep horizontal surface velocity at 0), and a button to land at the current lat/long. MJ already has harmonic orbits to assist with satellite spacing. Beyond the benefit of doing this for my case, it would be extremely handy for simplified station/ground station transfers - you can launch directly to rendezvous, then dock, and you can undock and land directly at your launch site. It's a bit of a haul at Kerbin and requires an extra 1000 dV compared to a 70km orbit, but there's no transfer windows, no hohmann transfer, phasing, etc. It's a straight shot up and back, reliable 24/7.

KSP is very crashy for me under Yosemite. I skipped the last few versions of KSP, and didn't play .25 under Mavericks, so I can't tell whether it's .25 or Yosemite, but nothing seems to help. Lots of beachballs and quit to desktop all at random times. Doesn't matter if mods or no mods are installed.

I've added an LLL RT2 file. I started with the one Lack posted above but made a number of changes: 1) I procedurally added RT2 and command station support to all LLL command pods. This should also catch the ones in extras as it looks for 'manufacturer = Lack Luster Labs'. All of the LLL command pods seem large enough to warrant command station support. This wasn't working right, so I changed it to modifying individual command pods. Adds station support only to the 2x1 and 4x2 probes. 2) I added support for the Omni Radar, which was missing in the above file. It has very high science transmission rates and pretty long range for an omnidirectional antenna. 3) I removed the atmospheric damage from all of the parts. That's more suitable for deployable items, not fixed ones. 4) I kept the ranges and power levels more-or-less as is but mostly differentiated the dishes by science utility.

Yeah, I have that file. I approached AIES as an engineer that already had the stock parts and was trying to fill in gaps and specialized needs - particularly around the constraints that RT2 imposes. So there's a dedicated ascent antenna, there's a few that are light/low power (seemingly overpowered) to serve as fallback comm links, but can't transmit science. There's a small moderate power deployable omni antenna that has exceptionally long range (can do Mun-Kerbin) but shows up very late in the tech tree, so when you're building your big geostationary nets and doing more interesting things, you don't need to put quite so much effort into same-SOI communications. It's too late to make Mun missions easier, because they'll already be easy, but it makes setting up that Jool relay easier. I'll be looking at the LLL parts with the same eye. They're typically better suited for ground use or large manned craft, so I'll probably look more at high power consumption/high science throughput. We'll see what .23 does to that part of the game next week. I know some players choose their antenna more for aesthetics, but I think it's good to have a variety of functionality to choose across as well. I don't want that big ground station at the north pole limited to science transfer at the same rate as some ship sending data back from Pol that presumably is very sensitive to power throughput. They're very different applications and would have very different design trade-offs.

I don't use FAR, so I'd at least need some direction on that one. The stock model is pretty straightforward so I was going to do that, and then on top of that add a model for RealChute. It's not worth firing up Windows to use the exe stupid_chris created, but I'll see about getting his algorithm and putting it into MATLAB. At least the code will be visible and can then easily be ported. I was also considering a delta-v calculator. It's easy to do as a table, but more fun to crank through the calculation. It gives you a nice library of functions for Hohmann transfers and ascent/decent, etc. Lots of little fiddly bits to hammer out. We can use this as a MATLAB thread to get things going. I've done a lot of programming but I've just started picking up MATLAB in the last few days and it's, well, it's a mess. Some really useful stuff in there, but some real nightmares as well. I may port some of this stuff to NumPy. I fixed that AIES link. It should all be working now.