rditto48801

It's nice to see this surface again after the forum implosion. On a side note, I don't know if I am just not looking in the right place, but I cannot seem to locate the short RCS tanks that were in previous versions. (the one that is a little shorter than the RCS nosecone) I do have nuke mod R3.

Well, based on what I know of the subject... More CPU = less lag for bigger/more complex craft. More RAM = more parts. The main problem being that KSP can only handle/use so much RAM. On a 32 bit OS, KSP can only handle a max of 2GB (32 bit OS limitation). Being that KSP itself is a 32 bit application, it can only use a max of 3-3.5GB on a 64 bit OS. Once KSP hits that limit, it more than likely will crash. Chances are, no amount of CPU power is going to help with that. Isn't overclocking risky, and likely to cause issues like system instability or otherwise increasing chances something else can go wrong? Or at the very least reduce the effective CPU lifespan?

Ah, yes, Spore. I have the full thing on Steam... took me a little while to figure out that I had to start up each expansion separately to get all the stuff working in game... I never got far in the space phase, just a few colonies, maybe a half dozen races... been a while since I played it though, but I had a lot of fun when I did play it. *bashes 'bookmark' button for video page* In a dusty cabinet sits the late model SNES, and the Utopia SNES cartridge... a pain in the butt to find years ago (I originally rented it a lot back during the SNES years, took forever to find a copy to buy when I replaced my SNES a few years back)... Good old times... been a while since I broke out either my old SNES or Genesis. I think I had Star Control 1 on Genesis, now that I think about it.

To heck with the F-35... Where does it fail? Close Air Support (CAS). The nice, new, expensive F-35B variant, expected to replace the A-10... is said by some to be 'giant leap backwards', as it cannot handle the amount of sorties the A-10 can handle. The A-10 is cost effective (under $12 million), reliable (can literally loose an engine or all hydraulics and still fly), durable (can loose a chunk of a wing and still fly, or fly through 200mph hailstorms based on stuff of using an A-10 for weather research), hard to shoot down (easier just to shoot down a half dozen modern jets in terms of how much punishment it can take), and has one heck of a loiter time with an impressive 16,000 pounds of ordnance/equipment, or the big GAU-8/A Avenger 7 barrel 30mm gatling cannon. And if they could have an option to 'turn off' the system that throws the GAU-8/A 'off balance', the thing could unload those 30mm rounds into a very small radius (and make it a lethal air to air combatant... I would like to see a modern jet handle a few 30mm explosive rounds in the tail pipe) Yes, I am an A-10 fan... and a fan of the good old F-14 and its Phoenix missiles (100+ mile engagement range? Yes, please.) Maybe someone should cobble together a jet with parts from an F-18 and Mig-29... see what the result is... I hope they aren't working 'to hard' on the flexibility of the F-35... to not try to make the base design be able to handle to many things at once with the same basic airframe... If it is made to be too flexible of a design, could it end up falling short in ways other than not effectively competing with a 40 year old jet in the CAS role? Reminds me of the F-4 Phantom all of a sudden... back during the Vietnam war... the 'inferior' North Vietnamese Migs flew circles around the F-4 (perhaps quite literally). A few US airmen had to resort to a 'borrowed' Russian gun pod to prove the F-4 needed a gun for air combat... (several hundred k+ for a missile, or a few hundred bucks for for big bullets... geez, I wonder what is more cost effective for shooting down aircraft...) The rest of the world at the time apparently didn't get or otherwise ignored the US's memo that missiles were the way to go and to stop using highly maneuverable gun equipped airplanes in air to air combat... Sometimes, the 'whiz kids' and 'experts' don't quite live up to those names... I will not be surprised if some other nation decides to throw out the whole 'air superiority' thing and go strait to 'air domination' and come up with some cheaper aircraft that will make the F-35 not so useful in air to air combat... Less gimmicks, more improving what is known to work... and hoping the F-35 is not being made mainly as a source of income for defense contractors, and not as the next best thing in jet designs...

One thing I forgot to mention is that I also loved Homeworld. I bought the Yes: The Ladder soundtrack CD simply because of the one song at the Homeworld end credits. I also have Homeworld Cataclysm, Homeworld 2, and for a time played Homeworld 2 with the Complex mod (up until I heard they went with a 'ships need to have a power 'resource' generated by a separate special ship to fully function' angle on things.) I also liked Galactic Civilizations 2, I got both the one with the Dread Lords expansion, and the later pack that had it with all the expansions. Along a similar lines, it makes me think about Master of Orion 1 and 2 (and to some extent, 3, but that didn't hold my interest to well) MoO2 being my favorite. (Doom Star fleets for the win.) I might as well toss in Sins of a Solar Empire while I am at it. And Space Empires... (4, 5 and Star Fury) And Star Control 2... (and the game most Star Control fans will refuse to acknowledge is the third game in the series. Good game, not so much as Star Control) Oh, and an old game called Utopia, which is more of another 'colonize alien worlds, meet aliens and possibly blow them up with off screen battles' type of game. It was on SNES, and I think also computers of the time. Ah, the times I locked up the system due to building to many buildings... Stars! A turn based space based game with colonizing planets, space battles, research, the ability to customize a race to your liking, the ablility to customize designs for ships/stations, 'mystery traders' that can give rare 'advanced' (and often multi-purpose) tech items or flexible hull designs or even flat out large amounts of research points (if you can catch them with a fleet you are willing to 'loose' along with their cargo as part of the 'trade'...), use station mass drivers to send resources to other worlds in place of cargo ships (be it to actually transfer resources, or ruin the day of a world that didn't have a station with a mass driver equipped capable of catching the high speed mineral packets). There was also terraforming. There was not to much for graphics, but it had some deep gameplay potential, multi-player (PBEM, or via other options, like with an 'auto host' program). The AI was reported to never cheat... it was to efficient and effective to need to cheat.

A few 'space' games come to mind for me. First, good old Outpost, by Sierra. (not so much for Outpost 2) An oldie but goodie... I have both the CD and 3.5in diskette versions... Sending out probes to several systems, choosing one and outfitting a 'colony ship' with supplies/equipment, and heading off to a new world... of creating colonies on another world, feeding the people, keeping them breathing (and reproducing, and not rebelling), building up industry,recycling, handling colonist morale and education, and of course doing research. In the end, working toward an ultimate goal like remaking a space program, terraforming, or even going into the 'risky of beneficial' path of research, nanotechnology. (some of which have not so much effect in the game... plans to expand the game apparently never got fulfilled...) Due to this, Shackleton Crater is definitely of interest to me. ---- Second, Space Station Sim. Managing and assembling a space station, keeping the station supplied, doing research, and dealing with the occasional 'disaster' called the space tourist... Things along the lines of "What does this do?" is a phrase to fear... (at least stuff is fool resistant... more of a hassle to turn important things on/off after the space tourist has fiddled with it) Last I checked, there is still a demo available for it. ---- Third, one I just recently found out about, and which I really like so far. Mars Colony Challenger The player (either single player, or up to 3 others, via online play that is a bit tricky to setup as IP address of the host is apparently required for others to join) have to help setup a base on Mars. There are three different areas to choose from, the three areas being the effective difficulty. The base is basically the same for each area, but have rougher and more hilly terrain, which makes it more difficult to get around and do some tasks. It is broken down into multiple phases, with each phase having specific goals to be done. After the 'work orders' for the phase are done, the player(s) can go to the next phase, or continue playing to try and increase their % rating. After a phase is ended, the next phase is started after a brief 'loading screen'. The next phase has the base being expanded with more things in place, and with new work orders to do. In earlier phases, supplies are limited do a slower pace won't work well in the long run, but at around Phase 4, things are in place to start making the base more and more self sufficient, starting off with being able to produce food, as food (and medicine) are the main finite supplies at first. All sorts of factors need to be kept track of, such as oxygen, power, food, water, radiation, air pressure of the base, etc. Rovers allow for getting around, but fuel needs to be made for them, and caution needs to be had on hilly terrain, as they have trouble with steep includes and can take damage going to fast or otherwise sliding down a hill. In later phases, mining can be done to allow for making replacement parts for things, and even acquiring minerals needed for other aspects, such as for creating fertilizer for the farm/greenhouse area. Plants can be grown, and a bio lab allows for raising of fish, frogs, worms, mushrooms and several types of algae. Stuff grown is not always for food, some types of algae and plants can be used to make plastics, some fertilizers and fish materials can be made into algae nutrients, another type of algae can be used to make medicines, and so on. The overall goal being to eventually make the base self sufficient and producing resources faster than it uses. There is a demo for it also, taking place in Phase 6 (one of the later phases, where mining first takes place and food production stuff is all in place already), and has some limitations. It is on Steam Greenlight. The only down point might be the fact it is $30, but so far I feel it could be well worth the money. ---- Another one I want to mention. Space Station Manager (and the 'followup' Short Hike, which I did not get a chance to play). It was about building and maintaining space stations in Earth orbit, dealing with things like expenses, crew numbers (some modules requiring so many crew to work), life support (habitation is useless without life support), power (solar, RTGs), heat (need radiator panels and such), and making money (research modules, communications modules, 'industrial' modules that also lessen module costs). Having service modules and spare crew helps lessen maintenance costs (only so many parts, larger stations needing more of each to help keep maintenance costs in check). It is basically a dead project now, I have not seen anything about it in some time.

Other info that could help figure out the problem. Your system specs (OS, CPU, RAM, Video Card, etc) Do you have any other mods/plugins installed?

I would like to add in a few thoughts to this (in no particular order). 1: KSP is a 32 bit application, it can only handle about 3.5GB tops before it will hit its limit on a 64 bit OS (with a 32 bit OS having its own limit of 2GB for any single program, at least on Windows). 2: mumech_MechJeb1m is #2 of 10 parts in MechJeb, so 8 other MechJeb parts would follow if loading in alphabetical order. Next up in line would be likely mumech_MechJebAR202. I can't help but think that sticks out for me for some reason. 3: Number of parts probably is not as much of an impact as the complexity and details of the parts. Nova Punch has around 185 parts, and takes up around 242 MB (235 MB parts alone) of HDD space. That's actually not that much... KW Rocketry (0.2.2) has 67 parts, but takes up 409 MB (and 0.5 MB not of parts) of HDD space. Kosmos_SSPP_R4.2 has only 38 parts, and takes up 329 MB (304 MB parts alone) of HDD space. Toss in the present version of KSP having troubles properly clearing stuff from memory during scene changes... I wonder if KSP is still loading 'everything' on startup, just to 'unload' unneeded stuff when loading the 'main menu' scene. If so, it might mean the 'crash on startup due too having to many parts' is still possible. 4: @ spacebison Are graphics settings set differently on the Windows and Linux versions of KSP? Like if the Windows version is running with lower settings for Texture resolution than the Linux version? Just how many parts do you have? How much HDD space does your Parts folder take up? About the laggy legs. Something I am going to try the next time I start up KSP (if I remember to try it anyways). Setup the lander in question in the VAB. Remove the stuff attached to the bottom of the lander command module and drop it off to the side. Click the lander command module to pick it up, then click again to drop it. What I am looking for to see if the lander command module 'sticks' to the cursor. Why? It is a sign the issue might be related to something clipping into something else. Edit: I started up KSP and did a little testing. Thor Lander test Major lag the moment the lander loaded. Tried the test, the issue I was looking for did not pop up. However, I could not re-attach the lower part of the lander back to the lander command pod. Second test. Scratch built design. Default command pod (3 man version), parachute on top, 2.5m decoupler on bottom, 'tuna can' fuel tank. Minor lag with Thor lander leg selected. More lag with 4 in place. Removed and dumped them, lag went away. Placed another set, lag returned. Dropped it off to the side, lag remained. Reattached in 4 symmetry, then attached another group of 4, and lag increased even more. Removed and dumped one set. First set detached, symmetry reset to single, reattached. Removed 'tuna can'. Picked up command pod (decoupler still attached to it), 'command pod stuck to cursor' glitch hits. Third test, same as second. Command pod didn't stick to cursor, but at one point the fuel tank/legs bit went red when I tried to reattach and it would not reattach, and that bit stuck to the cursor, and I could not drop it, but I was was able to dump it on the parts menu. So, my guess is there is some serious clipping issue going on within the Thor lander legs themselves. I had some 'null' errors, but figured out those are caused by something else (even placing stock parts caused the null errors, probably plugin based)

Would it be possible to slow down the movement/turn speed of control surfaces and gimbling engines? To make it so that it takes maybe up to full second (or a half second?) for a control surface or gimbling engine to turn to its maximum angle. And also have them smoothly go back to the strait position instead of snapping back strait when there is no control input. It could allow for more smooth control of a rocket and space plane, yet still be a few times faster/more responsive than the precise control toggle. It could also make it so the ASAS (and perhaps MechJeb also?) is much less likely/capable of shaking/wobbling larger/more complex rockets to bits by flapping control surfaces and turning gimbled engines back and forth rapidly like a whip wielding space squid high on caffeine was at the controls.

@ Tiberion I was doing some testing with the NP chutes (well, more trouble shooting with extreme prejudice out of boredom) , checking to see the effects of adding/removing the "minAirPressureToOpen" line to the stock and NP chutes, and using MecJeb for altitude info. After a lot of testing, I noticed the NP radial and nosecone chutes were not working right. According to MechJeb details, I noticed they were opening at 500m (ASL) not 500m (True). That spells trouble if the ground is close to or above 500m high itself. The NP stack chutes were opening normally, like the stock chutes, at 500m (True). I don't know how I missed it at first when editing config files to add/remove "minAirPressureToOpen" during my testing, or when I first noticed the NP chutes lacked that line, but the key is both radial and nosecone chutes are missing the parachute parameter "useAGL = True" used by the stock and NP stack chutes. I guess AGL means Above Ground Level. Adding that line to the radial and nosecone chute config files causes them to open normally like the other chutes, at 500m above the ground, not 500m above sea level. I don't know if it matters or not, but both the NP radial and nosecone chute are also missing the standard part parameter "stageOffset = -1" Also of note that I noticed. (no clue if it matters or not). The module names. NP chutes: module = Parachutes Stock chutes: module = HParachutes Side Note 1: During testing, it looked as if the 2m stack chute looked almost 'invisible' when first deployed, until I zoomed in and saw that it appears to be super thin at first, barely thicker than the parachute lines of other chutes. It looks normal once fully opened. Side Note 2: I am curious if the "fullyDeployedDrag" for the NP chutes might need to be increased. As it stands, the stock chutes are sitting at 500 now, making the NP chutes seem a bit less effective in comparison. Maybe also make the 2m stack chute have a parachute on par with the stock 2m chute in terms of open parachute size.

I had the same issue with the radial RCS tanks being drained early on, so it is nice to know the bug exists and how to prevent it from happening again. I always wondered why it stopped happening to one of my rocket designs after I revised the lander section of said rocket design. For the parachute issue, I have an idea what the problem might be. I have some basic modding experience so I took a curious peak at the parachute config files, and I noticed the stock parachutes have a line apparently not listed in the the NovaPunch parachutes config files I looked at. Under "// --- parachute parameters ---" minAirPressureToOpen = 0.01 I am guessing this is the problem with the NP parachutes, and I can only assume the 'default' is 1 (Kerbin's air atmosphere), which would likely cause problems with parachutes opening in thinner atmospheres. I can't really test it myself, as I am fairly new to KSP and have not yet made it to Minmus, so stuff like Duna and the new planets is a bit out of my league still.