Orum

Anyone else having issues getting the M27 cockpit to work? When I try to use it, the kerbals inside seem to disappear on launch (no portraits in the lower right, can't enter IVA, ship is uncontrollable). They appear to be there though, because when I recover the vessel, it recovers the two kerbals that were inside! I am using RPM, and also using DDS4KSP, but I don't think either is directly causing issues. I looked at the configs and noticed something interesting in the B9_Aerospace/RPM/Patches directory. "b9-m27-remade-internal.cfg" refers to a model that doesn't exist in the pack, with the "model = B9_Aerospace/Spaces/B9_Cockpit_M27_Internal/model". Is this supposed to refer to the same model that's normally used for this cockpit, which is "B9_Aerospace/Spaces/m27model"? Edit: Just tested it, and that fix seems to resolve the problem. Edit2: Looks like some other configs in that patch dir may need to be updated as well.

Ah, yeah, that looks like the problem. It was reading the environment's PATH variable and assuming that's where KSP was installed to. Strange. Thanks.

I have 3 (sometimes 4) copies of KSP installed on my system: The àla carte install (in steam's directory, which I use to verify KSP itself is working and avoid issues related to auto-updating for my other installs), a development install, a modded install, and sometimes a fourth install if I just want to isolate one mod for testing if I suspect problems. The problem is, for my modded install (which is what I'm playing 99.9% of the time I'm not in my development install), it seems KSPUtil.ApplicationRootPath is returning the path to the Steam install, and not the path to the currently running KSP. Is there any workaround or fix to this, other than editing every instance of every mod that makes use of it? RSS won't even load when this path isn't what it expects.

Just wanted to stop by and say thanks for all the effort you've put into this mod. I've had a lot of fun trying to pack as much weaponry as I can inside cargo compartments as I can. So far this is my best result: Above, in a single Mk2 Cargo Bay CRG-08 I've fit (can't see all of them in the screen shot): 4x AGM-114 Hellfire 2x Mk82 2x Mk82 SnakeEye (on top, not visible) 2x Cluster Bomb 2x AIM-9 Sidewinder To fit them all in, I had to use a docking and a "free" washer from IR (to rotate the chosen ordinance to the bottom if necessary), a couple Jr docking ports, an 'I' beam, and TweakScale to get its length just right so it would self dock (to support it on both ends). Anyway, thanks again for the mod, and keep up the good work.

I previously used the TGT+, but I would keep missing it as that doesn't consider your velocity relative to the target. The "closest approach" is in MJ as well, but the issue was always rounding errors that sometimes were induced while warping or even just rotating or waiting. After some more experimenting, I found that the best thing was just to establish a higher orbit where the pull of gravity was less, and that made hitting things easier. Still not ideal as I miss every now and then, but it's enough that I can test things. Thanks.

I'm trying to do some high speed impacts on one of my space stations to test my faux whipple shielding, and I came across a problem--trying to hit another object in orbit at high velocity is actually fairly difficult. Trying to do these by hand has proven to be a complete disaster, and when I looked to MechJeb, specifically Smart A.S.S., I realized there's no way that I can see of accomplishing aligning the two. It doesn't seem to have any context that considers both your own orbital velocity as well as the target's position (yes there's RVEL, but RVEL+ aligns you with your current relative velocity and does not attempt to maximize it by aligning prograde with the target). I've also tried a counter rotating orbit (same orbital params but going around the other way), but the rounding errors make this nearly impossible with the sort of precision I need. I'd prefer some way to do this while under constant thrust--from lift off to eventual impact, or stopping just a second or so before impact. I also looked at some of the "warfare" mods (namely BDArmory), but my concern here is I think most of the missiles in that also contain some sort of "explosive" payload (like a fuel tank blowing up), and I want a pure kinetic impact. I know what you're saying, "But if you crash your own rocket into it under thrust, you'd have some fuel left in your tank too!" While this is true, I was hoping I could dump the fuel just before impact with TAC Fuel Balancer and avoid that problem. So, what's the best way to go about something like this? Is there a mod I should be looking at, or is there some way to accomplish this with MechJeb that I've overlooked?

I have a similar fog bug with the mod installed, though it's not as severe as Bla123's screenshot.

Anyway, this is what I came up with for distance & surface normal at an angle (with respect to the ocean--the intent being to take to compare with a raycast, take the min() of the distances, and then decide the correct normal based on that): I originally thought I could solve this relatively easily with the law of cosines, until I realized that that's intended for finding the angle between two known sides, and not when you have an angle next to only one known side. I still think it's applicable, just I have to derive exactly what I need correctly. p.s. - In case it wasn't apparent, ignore the tangential line for the side of the triangle labeled "r+a", as that is the length of the full side, not just to where it intersects the tangent.

Yeah, I can get it to use the "new" setting over the "old" one, but I can't figure out how to force the GUI to reflect my internal changes to the variables. So, I think I'm going to abandon it (as the state it's in right now is, in some respects, worse than having nothing) unless I can figure out how to force a refresh. Edit: Ah, I see, if I just disable the actions I can get what I ultimately wanted. Thanks!

Found this thread when looking for a way to make rays collide with the ocean, and decided to try out raycasting with all 32 possible individual masks. Unfortunately, none of them collide with the ocean. However, there are other ways around this, of course, if you remember your trig. Obviously, this only matters if you need distance at an angle other than straight down, as pqs gives you that. Unfortunately, I had trig many years ago and have had extremely little use for it (until now!) and so I've forgotten much of it. I'm in the process of relearning it, but if someone else beats me to a solution, feel free to post it.

Well, I've been working on this for a bit now, and I've simplified/corrected some things, but I still have an issue. Here's what I have now: public void Update() { BaseAction toggle = Actions["actTg"], enable = Actions["actEn"], disable = Actions["actDs"]; BaseAction gToggle = Actions["actTgGm"], gEnable = Actions["actEnGm"], gDisable = Actions["actDsGm"]; enable.actionGroup &= ~toggle.actionGroup; disable.actionGroup &= ~toggle.actionGroup; disable.actionGroup &= ~enable.actionGroup; gEnable.actionGroup &= ~gToggle.actionGroup; gDisable.actionGroup &= ~gToggle.actionGroup; gDisable.actionGroup &= ~gEnable.actionGroup; } As the actionGroups are bit fields, it makes more sense to treat them as masks. There a still a few issues though, as "Enable" takes precedence over "Disable", and "Toggle" trumps both of them (I'd rather just take the most recent item the user chose). Also, the GUI 'lags' behind the actual settings, e.g. if I pick "Toggle" and then "Enable", both will show up in the current action group, unless I force the GUI to refresh by clicking on another action group and then clicking back on the one I was just at. Ideally I'd love to not even show the other two options once one of them is picked, but I don't see a way to do that. Let me know if you guy have any other ideas. Thanks. Edit: I think I can get the most recent to take precedence easily enough (by saving the previous state and comparing the current one to that), but ideally I wouldn't have to, assuming I could hide the other choices.

I'm trying to create several KSPActions for my current plugin, to give end-users a lot of flexibility when assigning groups, like so: Internally there are just two booleans, one for if the part is "enabled" and the other is the same, except for the gimbals. It looks like this: [KSPAction("Toggle")] public void actTg(KSPActionParam kap) { isActive = !isActive; } [KSPAction("Enable")] public void actEn(KSPActionParam kap) { isActive = true; } [KSPAction("Disable")] public void actDs(KSPActionParam kap) { isActive = false; } [KSPAction("Toggle Gimbals")] public void actTgGm(KSPActionParam kap) { isVectored = !isVectored; } [KSPAction("Enable Gimbals")] public void actEnGm(KSPActionParam kap) { isVectored = true; } [KSPAction("Disable Gimbals")] public void actDsGm(KSPActionParam kap) { isVectored = false; } The problem is, you can assign multiple actions to the same group, so you can get nonsensical action groups (e.g. a group that both "Enables" and "Disables" the part). What I want is to make "Toggle", "Enable", and "Disable" mutually exclusive within any given action group (make the other options disappear for that action group once one of them is selected), and then the same for the equivalent "Gimbal" triplet. This would make things a little more idiot-proof/misclick-proof. Anyone know a good way of doing this?

Ah, I had forgotten about the context menu after configuring almost everything in the editor window. Thanks!

I installed this today (as you know from IRC), and overall I love it. The only thing I don't like is that it doesn't have a "active but not predeployed" state similar to what the stock chutes had in KSP (I think they were a blue color in the staging bar) when you were outside the atmosphere. Because RealChutes doesn't have this, it can mess up staging. Any chance we could see something like this in a future release? Basically it would be a state where you could activate (but not deploy) the chute at any altitude, and then when the chute got to its maximum predeployment altitude, it would automatically predeploy, instead of what it does now, which is just bump the chutes to the next stage without any triggering at altitude.

First off, I'm not sure if we're supposed to use FAR for this or not, but I can't stand going back to the default drag model. Also, I assume we're supposed to do this at as close to sea level as possible, so I was at < 31m above sea level for the entire run (until the vehicle lifted off and/or exploded). So for this, I used FAR, and a few parts collections; KW, B9, and MechJeb are used on the vehicle itself, and KJR was used (as I use that by default as well). I did it at the south pole as it's flat and has more flat area than the north pole, making it easier to land there while still having plenty of room to test. Getting it there was harder than actually doing the runs themselves, especially with deadly reentry installed. the actual ground speed vehicle is a 2 stage / 4 wheeled "rocket" with the first stage being an air-breathing jet engine, which gets me up to about mach 0.9. "This isn't even my final form!" Then I decouple the jet engine and its liquid tank and let the rocket take over. This invariably ends in disaster as the planet is far from perfectly smooth when traveling at these speeds. Here's a shot just prior to one of those disasters: Then after I've blown up, I take a look at my speed. The highest I've gotten so far? 838 m/s (mach 2.44)!

Ask and ye shall receive. Added another one of an electrically powered helicopter (though it behaves more like a balloon) I made today, which I later used as a propeller for some planes while streaming.

It's in the picture--it's the core of the satellite. Unfortunately it's low res, as I was originally going to put it on Kerbal Space Port until I read their TOS. I'll grab another screenshot in a bit and put it up. Edit: Now up, it should be easier to see.

SatBatts is a collection of batteries of various diameters, lengths, and capacities, designed for satellite, space station, and electrically powered helicopter use (see images below). It's useful primarily if you use mods that cause large energy use and require satellites to be in a planet's/moon's shadow, such as RemoteTech 2. A total of 15 batteries are included, 5 of each of the stock KSP diameters, at different lengths (by powers of 2) and capacities (directly related to the mass of the battery). Each battery is twice as dense as the stock battery--that is, twice the electric charge per cubic meter and twice the mass per cubic meter of their KSP counterparts. Therefore, they have the same charge per metric ton as the stock batteries, for balance reasons. All parts begin with the prefix "OI-" and are found under the "Utilities" category within KSP. To install, either use [thread=100067]CKAN[/thread], or perform a manual install by extracting the contents of the zip archive into your GameData folder. To remove, simply delete your "GameData\Okram" folder (this will delete all Okram Industries parts/mods), or use CKAN. If you like, or dislike, the parts, please let me know in this thread. Thanks! Download v2: KerbalStuff | DropboxAlso available via [thread=100067]CKAN[/thread] - Last tested on KSP 0.90 License You may not: - Claim the work as your own or misrepresent the source of any files included in the distribution. Part configs, textures, models, etc., are the copyright of Orum on the KSP forums. - Repack, mirror, redistribute, or bundle the mod without prior permission from Orum on the KSP forums. - Use any part config, texture, or model for a derivative work without first receiving permission from Orum on the KSP forums. You may: - Use the mod in videos, screenshots, or when streaming, even when said videos or streams are monetized. - Use the mod in advertisements as long as all other terms of the license are met. - List, fetch, and [un]install the mod via a "mod manager" (e.g. CKAN), as long as all other terms of the license are met. If you have any questions about the license or would like to ask permission for one of the above, please post here in the forums. If you don't receive a reply to a query about the license within a week, please private message me on the forums. Lastly, please note that this mod is deliberately not available on Curse. If you see it listed there, it was put there illegally by someone other than me. Changelog v2 - Fixed issues with the colliders not being flagged as convex (parts will no longer clip through terrain) - Added agency so parts can be sorted by manufacturer - Adjust license to again clarify what's allowed (and allow CKAN explicitly) v1 - Updated scaling for 0.25 compatibility - Minor change to license for clarity v0 - Initial release

Just wanted to say that this worked for me. Thanks! Edit: Now if we could just get shock diamonds in our exhaust...

I did remove the old MM DLLs, but the problem still persists. Trying without DRE now, stay tuned... Update: Seems this mod and Deadly Reentry Continued are mutually exclusive, if you want either to work correctly. If anyone knows a solution, let us know.

First off, I love the effects! Makes me drool every time I take off from the pad. My only problem is, I get much higher heat on all the engines that have effects from this mod. Engines without the nice effects behave normally. I assume this is unintentional--despite the mod being called HotRockets--so I'm trying to figure out what is causing it. While talking on IRC with you earlier, you mentioned needing to udpate to the latest Deadly Reentry, which I did (now running DeadlyReentryCont_v4.3) and I also updated FAR (now at FerramAerospaceResearch_v0.12.5.2). While this fixed the other problem I was having with your mod installed (engines exploding under even low G loads), they still heat up much faster than expected. I have 3 versions of ModManager installed simultaneously; 1.5 for RemoteTech 2, 1.5.5 for Deadly Reentry Continued, and 1.5.6 for FAR and your mod, which I'm sure isn't helping. But, all the other mods appear to play together correctly if I just remove the MP_Nazari directory. Any ideas?

I would start looking at this page on the wiki. The links at the bottom of the page link to the "in-depth" guides.

IRL they have heat shields. But yes, it can be difficult to brake, but try several aerobrakes if your apoapsis is high on reentry. Also, oversize or multiple heat shields provide more drag (and in theory, more heat dissipation, though I'm not sure if this is modeled) and can help with reentry under RSS. Reentry angle and speed are the most critical factors though, so always start with that.

I am using KWR and 3.75m tanks. The problem is the joints are too weak to make anything really big with KWR. I'm trying to find Kerbal Joint Reinforcement 1.4.2 (for 0.22) but no luck yet. I want to go to 0.23 but it's still lacking some mods I really like. And yes, I'm using FAR. While the overall drag is less, it causes some problems when I try to use additional beams/strut connectors to reinforce joints. Overall though I feel like FAR should be default in the game. My objectives right now are to experiment with RSS + FAR + KWR + Deadly Reentry and see what atmospheric reentry angles work from the edge of Kerbin's (or Earth's at this point) SoI. I just modified the Isp of the engines for now, but I'll look into adding some other mods soon. I also need to start getting rid of some mods I have installed to free up memory for others. Kethane will probably be the first to go.

Ahh, good to know, thanks! I may give it a test. Right now I'm still trying to get to 0.23 and keep many of my mods.