Luxord52

Are you far enough out that the gravity well has no impact? If so, can you try and replicate the situation in a new save with hyperedit to confirm that the problem persists?

To the CKAN issue, turn around time from mod up to on CKAN has always been terrible. To the Karborundum issue, according to the forum post: "Karborundum. Valuable and incredibly fuel efficient, but also very hard to get. It can be harvested on the surfaces of Eeloo and Eve, or by a solar collector within approximately 2000 meters of the sun's surface..." Note, the post I got that from was a year old, so that may have changed recently. It appears that you may have luck at Dres as well. Mostly just keep searching.

Hang on, boots, should this be (!activated) {which I read as not activated}, or (activated)? I might just be mistaking state checks for what it will be when that action goes off. // Startup sequence for beacon. [KSPEvent(name="BeaconInitialize", active = true, guiActive = true, guiName = "Initialize Beacon")] public void BeaconInitialize() { if (!activated) { [KSPEvent(name = "BeaconShutdown", active = false, guiActive = true, guiName = "Shutdown")] public void BeaconShutdown() { if (activated) { I think I found the log spammer though: [KSPAction("Initialize Beacon")] public void BeaconInitializeAction(KSPActionParam param) { if (!activated) BeaconInitialize(); else log.warning("Can only initialize when shut down!"); } [KSPAction("Shutdown Beacon")] public void BeaconShutdownAction(KSPActionParam param) { if (activated) BeaconShutdown(); else log.warning("Can only shut down when activated!"); }

Any other mods? Autostaging, smartparts?

I'll have a look at the cfgs, see if those might be causing it. Which beacon is on the vessel in question?

Yes, maintenance thread. The good stuff. In other news, I'll be working on a model/cfg for an extra-solar beacon, for those who use mods that enable multiple star systems and don't want to spend obscene amounts of fuel and electricity just to get to your base in the next system over. If you have any ideas for the design/costs, post away.

Yea, go make a maintenance thread, and leave a post here about it. Sorry for disappearing, been finishing out high school and things piled up on me. I'm really glad you guys got the models working, I could load them into Unity, but PartsTools just would not work for me. I'll try and muck around with creating a star to star beacon model/cfg. If anyone has any input for stylistic choices/warp costs, drop it in the new thread and I'll keep you guys posted.

I am happy to announce that I've been able to get the old models/textures running in blender, now to see about fixing our collider issue.

Well, that's the sign for me to take a kick in the ass and get those models out. I'll do my best for this next weekend, but it is the end of the college semester, so I may not quite have enough time.

We have a couple of options for the models, I can go with basically replicating the old ones, or trying to go a completely new direction. I'd prefer to go with the old models, because I'm pretty sure the problem lies in the collision mesh (haven't had a chance to look at the old models/collisions yet). Opinions? If we go a new route, someone is going to need to texture these guys.

I've looked at Galaxy and Kop's cfgs, and they (and presumably the planetary system in general) calls bodies, and then gives them a referend body for their orbit. It's not something that explicitly calls a sun a sun, but it should let us make a patch for compatibility, using the new system's sun's reference body. The call Kopernicus makes goes something like so: Body { name = BodyName Orbit { referenceBody = ReferenceBodyName } } Should be easy enough to use. I hope.

It is under GPL2, so as long as we give TMarkos credit, we should be good maintaining it. I'll try and get some time this weekend to go make at the very least preliminary models so that we can try and get people up and warping again.

You'd have to pull out the models and drastically reduce ther face count, the issue was that the old models had basically too many faces, and so for whatever reason, 1.0.5 hated them. I might actually look into making a new set of models for this if someone chooses to maintain this.

Bless you JPL. Bless. That soundfix is a fantastic benefit to my RemoteTech nodes' engineering crews. The beeping was forcing them to only allow one frozen crew member a ship. Bad news when that one kerbal goes floating off into oblivion on accident.

Well, it seems I may have found part of the problem: KSP is tossing a Too many Polygons error on the beacon parts. Perhaps a slightly poly cheaper collision mesh would work.

Anybody got a solution for the issues in 1.0.5? I would love to bring my network back up with RemoteTech, but until this is working again, my plan goes a little bit down the drain.

Hey all, seem to be running into an issue with the Extendable Common Berthing Port, we seem to be missing a node with which to latch on to. We only have the one node, and without it, it's basically just a piston. Anyone got a fix?

It stays harbored in LEO so that they have easier access to modify, repair, and overhaul the Hermes while it's there, before they move it to Lagrange 1 and send a probe to refuel it, so that it is at one of the easiest points to escape Earth orbit, while still having full fuel. It's an efficiency thing, one that isn't demonstrable in Kerbal due to the fact that the physics system we use doesn't simulate Lagrange points. Basically, they do it so that they can save some fuel in case of emergencies on the trip, and the crew hops up after it's done moving to L1 over the course of a couple weeks. This then allows them to escape Earth gravity with minimum dV usage.

Upon further review, the section of the container where the radial attachment tries to latch onto the door goes further back around the piece, about to where the doors presumably end up when retracted.

Seems that attaching parts at the very edge of the doors (where one might place, say, solar panels, or extra glykerol tanks in a double symmetry mode) results in it acting as if it where the doors, instead of the body of the part, demonstrated here: http://imgur.com/TvtpCm1

Interesting error I'm running into. When trying to radially attach items to the CR-0300 model (single size model), it tries to attach it as if the top of the part where the side rotationally (More accurately, instead of curving around the sides of the part, it curves around the piece top to bottom). Anybody else running into this?

How did you do the part grouping? I've been poking around and haven't been able to see what you did.