rynak

I tend to do something similiar than the OP, for planes where the CoM shifts a lot.... especially for transporters that are designed to carry stuff piggyback. Basically, what i do is have one set of engines on a hinge via robotics.... then use the hing to emulate minor VTOL ability. The engines don't have to be overly strong compared to the main ones (so, no actual need for outright hover capability). EDIT: This also helps a lot with getting very heavy loads off the runway.

I do not run vanilla - at all. Hand optimized squad textures, modified part stats, a whole bunch of outrightly removed stock parts, removed interiors, modified techtree... then for the mods i use, the same procedure again, plus in some cases modified plugins.... to make them all fit each other and have the playstyle i want. The result? 1GB mem usage instead of 2GB, 60fps instead of 15, all the different mod parts nicely fit each other..... however, the deepest level of hell obviously is what all this implies for upgrading. Basically, whenever a new KSP version comes out, i have to spend 20 hours just on one file at a time merging/updating my changes.... and of course exchanging ships with others is entirely out of the realm of possibility.... it's a compatibility nightmare. Oh right, and i do regularily use part clipping - not so much to put things into each other, but more because i don't want to fight the editor all the time about attaching parts properly.

There was a mod that did this called fusebox. I'm not sure if it was updated for the current version. EDIT: damn, ninja'd

Same problem here. Running XP if that helps (so yes, 32bit ver)

It's been a while since i last gave this a try - does it support mk2 part shapes at this point? I didn't find an unambigious answer to that in the description or changelog.

I think harvester should do a second update, to clarify the clarification (pun intended). One of the major points he brings up in the update, is having a "control" and "reference". He then goes on to mention an example of getting the initial lift values right, by using a stock craft as reference. That is perfectly reasonable. When replacing something as fundamental as aerodynamics with a new model, then of course you need a reference to bring values "into the ballpark" at first. However, using stock crafts to achieve a good starting point, and then from there on tweaking further, OR using stockcrafts as the final GOAL... those are two entirely different things. Surely almost no one here would have a problem, with them using stock crafts to merely achieve a "first guess", and then from there on tweak further while allowing stock breakage. What people instead consider (rightfully) bollo***, is the implication, that in the final model will have to support every/most stock crafts that have been built. This is like rewriting a story, while tying your hands to your back, so you have to keep the pen between your teeth, and write that way.

Besides of the effect on gameplay, there is performance. FAR takes a major chunk out of the FPS. That does not neccessarily imply that FAR is unoptimized - it might very well operate close to optimal efficiency for what it does - but it still is expensive. On the other hand, SQUAD does not exactly have a track record of optimized implementations. Even with people crashing because of RAM/VRAM shortages, SQUAD happily continues to load duplicates of textures into memory, and adds more duplicates with each new version (though, to be fair, there are some modders that are even worse offenders in this regard - how some of them waste dozens of megabytes for really ridiculous things, is bat**** insane. Nevertheless, the point here is that SQUAD is no saint in terms of optimization either). So, even a simplified aerodynamic model might end up as CPU-heavy as FAR, despite of doing less. - - - Updated - - - It's not just about what to simulate, but also how strongly. Effects that are simulated realistically - i.e. supersonic effects - tend to make plane design much more unstable and fiddly, unless you're familiar with the details and/or constantly check graphs - as opposed to going by common sense. The more of such effects you simulate to a realistic degree, the more this becomes guesswork and feels unpredictable to a "rookie". However, say you for example do simulate supersonic effects, but make them much less pronounced, then to the less knowledgeable they would become less of an obstacle... you could say it would be more "forgiving" - while at the same time, an optimized plane for supersonic flight still would have benefits compared to an unoptimized one - just less pronounced.

I don't really see what's wrong with the aerodynamic simulation of parachutes. Yes, it's simplified, but it is cpu-efficient, intuitive and "realistic enough" even for an aerodynamic model that strikes a balance between action-gamey and FAR (which is to say, i'd expect something less realistic than NEAR, but not much less). Most things that are wrong with chutes gameplay-wise, aren't aerodynamics.... they are simple parameters of the parts and modules. The high mass for example, as well as deployment method. Those are things which i'd like to see fixed, and they are important, but they're not really about the aerodynamic model. Instead, the only aerodynamic aspect relevant to chutes, is that right now deacceleration in atmosphere seems way too easy.... so easy, that often a drogue or airbrake is just dead weight, since you might as well simply throttle down.

How did people come to the conclusion, that it is physics position checks that cause the lag? I mean, there must have been some kind of smoking gun? EDIT: Also - i'm not familiar with how this is handled in unity - but how are collision checks handled in general? I.e., if the merged objects still contain the same amount of collision boxes, then nothing is gained - and if it doesn't even use collision-boxes as a pre-filter, then matters are even worse. Basically, to do collision checks efficiently in such a case, there would need to be multiple levels of collision boxes: First you check large areas, then gradually smaller ones - powers of two, you know the drill. Question is: Is Unity/KSP even capable of this? EDIT2: If unity only allows one level of collision boxes, the both extremes attempted thus far would be inefficient: If you put a collision box around every individual thing, there will be too many boxes. But if you put too many things into a single box, then exact geometry collision checks must happen for too many things (which might actually end up even slower).

For Kerbin, i would propose to keep long range survey missions up to a range of 400km.... BUT turning them into a seperate mission type (appropriately called "Long-range survey"), and making them pay much better than a normal survey. They finally give fuel efficient long range aircrafts a purpose. Not surveys should favour such crafts, but i would like there to be some survey that need long range atmospheric crafts, AND oneself being paid really well for executing them.

Arsonide: How about not only imposing a chance, but also a maximum limit? That is, if there are already N missions of a given type, don't add more? The cap might not even be missiontype specific.... say, no more than 4 unaccepted extra missions of the same type?

Umm, you're playing kerbal space program - the game where anything and everything might randomly be eaten by the space kraken, and where people crash into planets by merely walking on their surface. Your save is at risk anyways, regardless of if/which mods you're playing, so unless you about every two hours or so zip up your current saves dir, and name it saves###.zip, you will loose dozens of hours of gameplay eventually. What you should instead be asking is, if this mod might cause you to invest a lot of effort into something you can't feasibly finish anyways. For kerbin-related missions, i'd say no. For anything interplanetary, i would say "why? but OF COURSE!"... after all, interplanetary missions aren't something you can do in a few kerbin days. Until this mod is stable, i'd say: Don't take a specific interplanetary mission, until you're about to go there anyways. This way, even if it turns out you can't finish the contract, you don't end up empty handed.

First, if this is only delivers half of what it claims and the screenshot implies - holy *****! This could become just as gamechanging, as passenger transport and multiple landing sites. Careful about this, please. Some people including me like to tweak the game and the techtree to their taste. It would be nice, if you would not hardcode specific parts or techfields into the source, but rather have a configfile, where we can specify criteria for conditions to be met. Something like: // Rover tech is assumed to be available, if at least one of the following techfields are researched rover_techfields = foo, bar, baz // Rover tech is assumed available, if one of the following parts are researched rover_parts = blub, blah Even better would be, if the above were in a format that can be changed via modulemanager. This way, other mods can for example add their parts to the list.

It looks like despite of the "made for high detail settings"-talk in the original post, you're actually trying to keep polycounts way down. Thanks! That means i might actually be able to play this (i can always reduce textures if needed, but polycounts are something i cannot fix myself).

Every page except of the DL page has more or less glitches. Just try it with older browsers. ROFLMAO - thats awesome: It does have search functionality - the user just cannot see it. What could be the problem? >.> I did read the first post. That it is built from scratch, explains none of the issues i mentioned, because the site does already have technically much more difficult features, than the ones i mentioned. Of course, that is unless the site is NOT built from scratch, and you're using existing software? Riiight. E-Mail alerts are a more useful feature than a plaintext search field that works. Mkay. People are currently not using the site for X, because it cannot do X, so that makes it okay. Mkay! -snip-

It's nice to see an alternative to curse, but as it is now, to me as a player, it isn't really anymore useful yet: - Apparently uses all kinds of recent HTML or CSS standards stuff, which makes page layout and design break in places. - Doesn't offer a search function. On the upside, this means we won't waste our time with a search that doesn't work, and right away ask blekko or google (so in a way, it's superior to all those sites with a search-func, that couldn't find its own nose, if its life depended on it) - The layout for listing mods is..... umm....no one designed this for listing mods, correct? This has to be stock of whatever webapp you're using? - On the upside, the download-pages of mods are working just fine. So right now, it basically is a well working download mirror, to which other sites can link. Anyways, those are the three immediate concerns i can think of: a plaintext search that actually works, plus categories. List pages that work and are easy to navigate. Alert by email? Who the heck cares, when the most basic stuff is still missing. Forget web 2.0 or 3.0 crap.... just make sure that web 1.0 features are in place (that's an issue i have with many websites nowadays: All kinds of fluff toys, but the most basic things no longer work or are unavailable.

If it doesn't yet, perhaps it could simply take the define mass in the partfile as the base, which then is scaled based on size? Then again, this still only gives us half of the calculation (assuming x*y).

Possible regression: When a target is selected, and the redevouz info windows is enabled, it will at first have only the neccessary height (no space wasted). If one enables extended info, the window becomes taller to accomodate the extra info. However, it then will keep this height - disabling ext info, hiding/showing the rendevouz info window, or even unsetting the target, will not get the window back to its original compact size. I don't remember this happening before, but i also didn't pay close attention to this in the past. I'd wager a guess though, that this was recently introduced.

For those who want to get rid of the unneccessary rightclick-menu stuff, and who know how to edit C# and compile it - here's how to do it: 1. There's a file called lightweightuinew.cs or similarily named. It contains all the rightclick stuff. Find the initialize function in it. From there, tell your IDE to find references: You'll find that it is initialized in ActionGroupManager.cs: Three consecutive codelines. This is the ONLY reference to lightweightuinew.cs. Otherwise, it is entirely selfcontained. 2. This means that once you deleted the init call from AGM, you can simply delete the entire lightweightuinew.cs file, since nothing references it anymore. 3. Go ahead and compile. There's nothing else to do.

I'm in exactly the same situation - don't really care about all the grabbing stuff in KAS - just about the pipes. My recommendation would be to look at the quantumstrut codebase, then look at how KAS implements the fuel pipes. I'm 99% certain that KAS pipes, struts and so on all use the same mechanic (struts), "just" with different attributes and behaviors. In the long run, probably i'm going to look into this for personal use, because i don't want to continue relying on KAS for something this basic. It's like killing a fly with an LGB. Anyways - as i said, modifying quantumstruts might be your best bet.

Thanks for the info, sirkut - didn't know this. That's a quite annoying limitation, because it basically guarantees version hell: Even if the user wanted to, he couldn't maintain a single up-to-date central version - and maintaining a dozen versions is bound to go wrong. Naive question: Why can a lib then without issue access the unity and KSP functions? After all, they're just references too, and way outside the library's directory?

What is it with kspapiextensions specifically, that makes modders embed it non-locally and this way enforce multiple redundant copies of it? It was the case for IR, and recently was fixed. It was the case for smartparts, and recently got fixed. It still is the case for procedural fairings - had to recompile it from source, to get rid of the pointless hardlinking. I'm not aware of any other common library, where this problem happens frequently? And yet, its just a compiling flag, so how come?

It sounds like a stock contract to me. (To be fair, the system for generating those contract descriptions is really well done - i was going to do something exactly like this, for another game. Though, as should be painfully obvious now, the idea only works as well as the patterns it is fed are.)

Both were set to 0. Well, i guess i can just ignore it for some days. EDIT: While on that topic - i can understand that squad wants a simpler toolbar, but they really ought to support some basic functionality - starting with the ability to hide unneeded buttons, and the ability to create folders (cause otherwise, its only a matter of time until space runs out, since the stock toolbar uses larger buttons).

Well, i don't get multiple buttons with the current version. I still get one dummy button, when the CB UI is disabled in the config, though.