Garek

I'm excited about the new UI and the work that's being put into UX, and I'm interested how that (and the whole game) will develop with community feedback. Also, things like warping through burns and multiple assemblies in the VAB seem to imply a lot better foundations both for the roadmap features and possibly mods.

Awesome! Don't worry, this is "just" a hobby for all of us Yeah, I expected that to be a bit more complicated, thank you for considering it for the future!

So... this is all awesome. But may I ask what happened to the ProbeCore you showed earlier? Still WIP? What would also be awesome would be larger diameter cores (there are some 3.75m capsules in Near Future Spacecraft for example, also think avionics/RCS/Power package for larger boosters) and adapter fairings for the remaining size transitions, but I understand that would be a lot of modelling work away, even if you want to do that

So I'm trying to extend the PartVariant Sytem to IVAs via EXTRA_INFO and my own PartModule. So far I managed to grab that EXTRA_INFO when changing variants in the editor and persisting it to flight. I also manged to get rid of the regular IVA when spawning in flight by doing: part.internalModel.gameObject.DestroyGameObject(); part.internalModel = null; What I'm still stuck on is how to set the new IVA? part.internalModelName seems to be ignored, regardless of when I set it part.AddInternalPart(<ConfigNode>)... even if that were the right option, what kind of ConfigNode would I feed it? how to make that IVA then appear. I tried some combinations of CreateInternalModel, SpawnIVA and internalModel.Initialize, but that didn't seem to do anything. Might be related to 1., but I don't see KSP complaining about not finding the IVA in the log. Anyone got any ideas?

Something I just realised, you can actually do OOP in kerboscript: set foo_a to list(). set foo_index to -1. function foo_new { parameter a. foo_a:add(a). set foo_index to foo_index + 1. return foo_index. } function foo_geta { parameter this. return foo_a[this]. } function foo_seta { parameter this. parameter a. set foo_a[this] to a. } This is a script implementing a class foo which has a single field a and access methods for it. Of course, compared to languages actually designed for OOP it looks horrible, but the semantics are there! EDIT: fixed stuff. Still, this is off the top of my head, without actual testing.

You are wrong there. Yes, CKAN is the most accepted mod managing tool. But not every mod author actually manages the CKAN entry for his/her mod. This leads to CKAN not installing the mod how it's supposed to be installed and messing things up. Which doesn't exactly increase it's popularity with people like Ferram who understandably would prefer other people to not mess up their work and cause unnessecary error reports. Yes, manually managing 50-200 mods is a PITA, but it is the most reliable method of modding KSP, since there actually is no universally accepted mod manager. Also, most of the time, you just need to copy the mod directory to KSP/GameData and maybe delete the old one if you're updating, which is not that hard. I personally have made my GameData a git repository, with a lot of branches and a bit of scripting. I don't recommend this unless you have experience with git and shell scripting, but if you do, it's pretty nice for mod management.

If you stack a lot of structural panels on alternating edges like /\/\/\/\/\/\/\/, they could propably act as a spring. I think I saw this in some ksp video and it worked surprisingly well. Of course, that's a lot of parts per spring, you need TweakScale to get springs with other diameters than 1 and 2 m. Also it won't stop at fully compressed because there is no self-collision, and instead compress further through itself until the connections break.

I also had KSP crash on me, output_log.txt said it crashed while 'compiling' the 1.25m heatshield. But after I removed DRC, it crashed on another Part, somthing from HGR, so I'm still investigating. Oh, with HGR removed and DRC 5.2, it crashes on the .625m heatshield. Hmm. I will continue removing/adding mods until I'm reasonably sure which causes the crashes and post my findings. EDIT: should propably have mentioned, I'm running the windows x64 build with a ton of other mods. EDIT2: It appears to be this: http://forum.kerbalspaceprogram.com/threads/87049-x64-crashing-due-to-access-violation-error

Yesterday I installed KSP again (after a break because of...stuff) and started reinstalling Mods. Then 24.2 hit and broke some stuff _again_. So I went to sleep and when I got up this morning, I had e-mail updates from Kerbal Stuff that FAR had updated and DebRefund is compatible. Thank you so much just for that feature! EDIT: "You must spread some Reputation around before giving it to SirCmpwn again."

If you actually would manage to install all dependencies for your mods, and their dependencies, IN THE CORRECT VERSIONS, IN THE CORRECT FOLDERS, I think you are equally capable to open the downloaded archive, and look at it's content to determine which dependencies are packed in. Also: Module manager can't be overwritten by older versions because the dlls have the version in their filename. If by accident, multiple versions are present, the newest one is used. KSPAPIExtensions has a similar mechanism afaik the whole point of mm cfgs is that one mod may modify another, and there was a lot of work invested to make them as compatible as possible with each other Keep in mind, a Mod is not a regular application. In fact, if it were, it would always bring it's dependencies with it in some form or another. A Mod is a MODIFICATION of the game created by a community member. This always implies: It's a free piece of difficult work. Critisism may be necessary, but don't demand a technicality to be implemented in a certain way just for your convienience It may break things. KSP's API is insufficiently documented, it has bugs, and most Mods have no proper Q&A (again, because they are free). Stacking mods is even more likely to break things. Software even has bugs if all people working on it work within 20m of each other. With multiple mods, you have Squad providing the base and every modder building a bit on top of that - and often, on other mods. If you don't understand what modding actually does to your game, you have equally little right to demand stuff from modders, who offer a piece of hard work for free. And the more you understand, the more reasonable suggestions you are able to make - and you are also more likely to just fix stuff yourself. Also, about bug reports. About every author wants the output_log.txt alongside a bug report, and yet, people have to be always reminded of that. It's not like professional, sold software were there is first level support paid to walk everyone through the basics again. You are talking directly to developers here, and they can fix a bug a lot faster, if you find out as much as possible about it, and provide all the information. I work as a software developer, it was a long day, I'm sorry if this became a bit of a rant.

I wrote two rebutals of this, but they rapidly devolved into rants. Now I will just say that I would like to understand how you got that opinion, if you would care to explain? (As long as this doesn't get us into trouble because it would be too political)

I think this could use some kind of car jack to make the wheel deployment less...wobbly-springy?

I knew that thread, but as I read only the first few posts I thought it was meant for the RftS mission reports, and not RftS mod discussion. All the info I wanted and even more For future reference (and new guys) it would maybe be helpful to add this link, and the one for the real engines stats, to the OP. That's exactly my point, so I will use RftS in the future. Interesting concept, I might implement that with some scripting. (No, not kOS, at least not until it gets proper functions. Maybe kRPC or something like that.) Good to know. Thank you both for your helpful replies!

I'm reposting this since it apparently got buried in people arguing over MechJeb data (I'm sorry if this isn't okay): So with Real Engines, the LMDE is the only engine good for landers bigger than probes, and if one wants to have a greater variety of lander engines, RftS is recommended? e.g. for bigger stuff/higher gravity, atmospheric landings, ... (is Mars atmosphere relevant for ISP?). Or would that be the point where it's recommended to do a little research and 'build' (-> create .cfg) appropriate engines myself? By the way, is there a engine list for RftS similar to the one for RE you posted there? That would be helpful for deciding which pack to use.

files and directories starting with a dot are hidden per default on linux. Just copy "~/.config/unity3d/Squad/Kerbal Space Program" into whatever explorer-analogue you use. Or a shell. In the latter case, you will want to include the quotation marks, or it will break on the spaces.

Another thing which came to my mind: what about savegame compatibility? If one starts a savegame now, with the regular patched conics, and later, when this mod is ready installs it, what would happen to crafts already in space? I'm especially interested in a) craft that is meant to stay in a certain orbit over an extended period of time, e.g. stations, communictation satelites. So 'closed' orbits around a primary body, clear of any orbiting moons etc. a savegame using RSS instead of the stock System, if that makes a difference (I'm really not a astrophysicist )

(Emphasis mine) You actually want to do ~116 builds? I mean, automation helps, but the sheer amount of binaries would be...impressive. I use manjaro and personally would be okay with building myself from a Makefile (which would propably be the same at least for everyone using the gcc toolset).

This is my most wanted feature from a mod repository ever (yes, I'm a mod user only). As for the design, it may not be impressive, but it doesn't need to be. The site primarily needs to be functional, and that seems to be the case. Just one thing: the full-picture background is nice, but it gets annoying when you want to read a mods description. You could maybe put all the text parts in boxes like the mods on the 'browse' page, that helps with reading and still allows a screenshot-based background.

Fun fact: in german, it's 10^3 = Tausend 10^6 = Million 10^9 = Milliarde 10^12 = Billion 10^15 = Billiarde So actually, pre-1975's British system was more similar to the German than the current one, just missing the "Milliarde" etc. Also, it's a bit confusing to switch between German and English while speaking/reading/... about big numbers

Well, the basic launcher system is just a really small mass drive. I've seen at least one mod trying to implement a mass driver somewhere around here. You could dig that up and use it as a basis for a ship-based 'linear canon' (afair that's how they called the mass driver). That would be quite interesting, you could build orbital mass drivers with that. The in-flight assembly on the other hand...it propably would be a PITA to implement, the existing autopilot mods weren't that good at atmospheric flight OR docking, the last time I looked (ok, that was like .21 ). And it just doesn't fit right with KSP, I have to agree to the others there. But well, I also think weapon mods don't fit right with KSP, and there is still a considerable amount of people who happily use them. So if you think it has potential, you might as well try it. Just don't expect it to be highly praised by the regular KSP community. The only Gundam series I watched ("Gundam Seed" without the Destiny) of course wasn't realistic either, but they at least had the common sense to finalise assembly inside the carrier.

Are you sure MechJeb is holding surface prograde? If it's holding orbital prograde, the difference between the two could be large enaugh to cause problems. Also, when using FAR (and assuming that probe is aerodynamically stable shield-first) you shouldn't need to have MechJeb holding heat shield orientation. Just make sure you come in heat-shield first, then it should hold orientation by itself once the aerodynamic forces kick in.

I'm running 64-Bit KSP on manjaro (Linux), using a lot of mods (including RSS/RO, most recommended Part Mods and a bunch of utility stuff). KSP reliably hangs the second time I go into the VAB, especially when reverting from flight. Since KSP in this configuration takes like 8 Minutes to load, this is a giant PITA. I suspect memory usage, because it hangs not only KSP but the whole system, and I know that having to do too much swapping because of high memory usage can do that. relevant hardware configuration: Manjaro 64Bit (openbox distribution) AMD Athlon 2 x4 630 (4 cores @ 3 GHz) 12 GB RAM (2x 2GB, 2x 4GB) Club 3D R9 270X 10GB Swap on a regular Harddrive (so slooow) So my questions are as follows: 1) How can I find out how much memory KSP uses? According to top, KSP uses a bit above 10 GB (RES column), but also less then 50% (MEM column). Does the MEM column count swap? 2) Is memory actually the problem here, or are there other issues with KSP that could make it hang the whole System? Keep in mind, everything worked before RSS/RO and associated Mods. 3) Are there any tricks to make KSP run more reliable with my current setup? I don't want to remove mods, and I would like to avoid downgrades of visual quality (i.e. ATM). Sadly, LOD works on windows only. 4) Has anyone experience with throwing memory at KSP to make it work? I would specifically like to know if 16GB would be sufficient (changing the 2GB modules for 4GB ones) or if I would more likely need 24GB (changing the 2GB modules for 8GB ones)?

Okay, so I may take another look at kOS and wait for integration there. About the API, it is correct that it will be documented in the manual linked in your sig at some point in the future? That would be helpful for kRPC integration, especially since it may be possible to do as a 'service', that is an optional module for kRPC which could be developed by someone else than the original kRPC dev. E.g. me, provided I manage to find time somewhere

So, what about autopilot scripting? I mean the ability to execute a script with kOS or kRPC 'on the probe' so it gets around signal delay. I vaguely remember that kOS integration was in the works for RT2, but I lost track of development. I personally would prefer kRPC, if possible.