steedcrugeon

This is my error, and will only be temporary. I had setup the 0.4.6 release but then had to immediately pull it as I had the previous 1.3 release of RetractableLiftingSurface (which has since been updated) and also a couple of the parts had corrupted on export from unity (it was a normal texture issue) but I had not spotted it until after I had updated the KSP-AVC thing. I plan to fix all this evening (next opportunity to get onto my Unity machine).

Yippee! Thanks LinuxGuruGamer, I've been waiting on this one. I know you've lot on your plate but I really appreciate the effort you're going to.

I suspect this is a result of a collider error. The square walkway (HE-50) is very easy to make a hollow collider for but the round one is a bit more tricky. It requires slightly more careful collider placement and is a little bit more difficult when using only Blender tools to re-do. needs to be run through Unity again but that does require re-aligning the UV map again. Quite a few little issue, just time consuming. it may well be fixed when this gets its next 'update'.

fantastic work @bcink and as this is your first mod I can't wait to see what comes next!

Fret not, it is in fact an error in the OTAV's internal Config. Unlike it's sibling REKT pods the OTAV does not feature a 'porthole' so this is a simple case of "copy and paste" problems, It will be corrected in the 0.4.6 release.

After the success of the Minmus Explorer a follow up vessel was built The Minmus Venture. it featured advanced equipment for extended stays like a centrifuge an array of sensors and unlike the previous mission this one had a carefully designed multistage two man lander for surface excursions. I learnt from Minmus Explorer than not having enough snacks can affect mission duration so a plentiful supply was added. the orbital insertion went well despite a less then ideal launch window, an minmus injection path was achieved with help from a quick trajectory altering pass by Mun. During Mun departure the Minmus injection stage was jettisoned and much to the chagrin of the engineers it was found that the Minmus Venture's main engine (which was selected for its hi ISP) is also tremendously powerful for its purpose. Minmus insertion was achieved with very fuss, the crew set themselves up ready for the descent vehicle's departure for the Minmus surface. This is where things start to go awry. The crew for the surface transferred over to the descent vehicle, bid their farewells and "c u L8r" to the Minmus Venture's commander, who stayed behind. Usig the OMS to get clear of the Minmus Venture the Descent crew fired the craft's engines and a staging failre occurred. This resulted in the separation of the descent stage, the main engines and the landing gear. The separation was clean, which was the only saving grace. The descent craft made its may back to the Minmus Venture using the OMS and docked, with a very disappointed atmosphere. Provisions were dutifully transferred back into the main hold and the team made preparations to setup the descent craft as an extension of the Minmus Venture's habitation and labs. At this point one of the crew who had done some very rough calculations decided that even with only the ascent stage and OMS the lander still had enough Delta-V to land and return (admittedly that would preclude the planned docking on return). Without permission he closed the hatch with enough supplies and sample return vials for a short excursion and forced an undocking procedure. He was determined to get to the Minmus surface, he had not come all this way for a fly-by! Appalled, the crew of the Minmus Venture and mission control supported as best they could from afar but the scenario played out as they had anticipated. The landing site that had been chosen was a flat peak of a mountain around the equator but without the descent stage the approach angle was not as steep as needed. the lander scuffed the side of the mountain, clipping the surface before tumbling away. Excited shouting of "I made it!" was heard briefly before the comm-link cut out and the telemetry was lost. with the next orbit the remaining crew of the Minmus Venture could just see the remnants of the lander's hab section, like egg shell, surrounded by a wide area of debris. They called it in and now await a mission update.

The dev version I last saw was for 1.3 there is nothing (as far as I know) in between the version listed on this thread and the 1.3 dev which I have been made aware of.

Glad your enjoying it. Alas the .dll file you are referring to needs to be recompiled for 1.3 but if you are running 1.2 then it should work without issue.

@wile1411 The rationale behind using dockPoint was only to have a unique identifier for the model and commonality with the other OTAV parts. I had not anticipated that it would cause issues with other mods (I never though that anything would have code which specifies a variable [KSPfield] have a fixed value. Which Is how CLS works I guess, it's reliant on mods using the stock identifier for the docking node (dockingNode). I feel that CLS should make it clear somewhere in its thread about this dependency. What I can endeavour to do I. The next release is rename the dockingNode transform in the model itself. Hopefully this won't break it but should appear as no change to the user while making the OTAV CLS Compatible.

Sort of. Unfortunately Fendrin appears to have left the KSP scene, The SpaceDock Beta Models I put out on Spacedock (the hosting site) in the Development thread. The MidiDock has been shelved for a short while, the modelling is almost done apart from the deployment of the inflatable crew tube to the control station (the IVA has not ben done yet). If the Parts for SpaceDock are of use by themselves I will consider releasing them under their own parts mod. I have a couple of other mods I am working on which have taken precedence at present but rest assured, the parts have not been abandoned.

Whilst this is probably true of the interstellar mod? there are/were quite a few mods which bundled IFS to use its clever resource switching capability, but they were not trying to buy into having the previously free resource of ElectricCharge suddenly cost. In my previous games I would have IFS for the very purpose of resource switching, but only IFS as I was playing some fairly basic games with a little Life Support thrown in. Adding ElectricCharge costs to users would greatly impact their gameplay. I would suggest that this particular part of the patch should remain in the main Interstellar mod rather than IFS?

The way that @Errol did the configs all the 'model' should be up-scaled so the docking parts should still mate together as anticipated. I have not carried out out any testing on PicoPort4All parts but theoretically they should work fine. have you tested the normal PicoPorts to see if you get the same issue?

Were these two part of the same vessel before you docked them together? (did they go up in the same launch?). Or were they previously docked? As they may not have gotten sufficiently far enough away from each other to trigger the 'acquisition' for the docking process.

just download the mod and delete the parts you don't want?

Yes, yes. IT is still very slowly in development. @pizzaoverhead has been working on this but there are multiple other projects of his and of course IRL stuff too. There does exist a Dev version of this somewhere (I believe it's on his github repo but could be wrong) but there has not been a release so you are correct that you will not find anything for 1.0 KSP.

so are you looking for something like the helios prototype:

the current LLL version works with 1.3

From what have seen you've come along with Blender more in the past week than I have since I started modding!

For one of my mods I have ditched the idea of going with a custom resource and plan to use a slightly different in game mechanic (pseudo-ISRU/harvesting) but it relies partly on the Koncrete resource found in @Angel-125's WBITools. I moved over to it after a little more playing around with the mod I'm working on but to avoid any issues can we add this Resource to the CRP? Resource details from the config file: RESOURCE_DEFINITION { name = Konkrete density = 0.0024 unitCost = 1.5 flowMode = ALL_VESSEL transfer = PUMP isTweakable = true isVisible = true } And here is a link to the original source: https://github.com/Angel-125/WildBlueTools/blob/master/GameData/WildBlueIndustries/000WildBlueTools/Resources/WBIResources.cfg

Unfortunately if you follow UK naming convention then that would actually be MoCR,because the of is not dropped, just lower case. I proposed to Beale that it could be called Commonwealth Rocketry Establishment (which harks back to the original Royal Aircraft Establishment).

In your GameData folder do you have any parts/folders with an empty .cfg file? I had a similar problem after I installed and earlier version of the Community Resource Pack as I think the asteroids .cfg used to be empty and this stopped unity from being able to spawn anything or even load my part tools correctly. Its worth checking to see if this might be the cause.

I have been mostly modeling Props But had a little bit of time to launch this "abhorrent" BDB Kane CSM to the Vangaurd-1 space station, another aberration of international co-operations. prior to this the Americans were hitching a ride into orbit on the Trusty Koyuz-2K and its derivatives. We did have a slight staging issue when it came time to release the second stage: No matter, deploy the solar panels and prepare for an emergency EVA by the engineer, Jadin. Here's some of the station approach, there aren't; the best so I've tucked them away, it was done on the dark side of Kerbin. And so the sun rises on the Vangaurd-1 station and the Russian/European residents have some new guests to host:

I love the use of the BBC font for the CR lettering! That's a very nice touch @Beale

oh that's pretty impressive looking, very cool!

There are a couple of ways to attack the multiple billboards, one would be to have individual parts for each or another would be to use a texture switcher, like B9 or FireSpitter or the very tidy PartSwitcher (I believe B9 is the current flavour of the month with regard to that?) they all go about the actual swapping of textures in different ways. but by using one of those plugin you can have you your part/or parts use the same model but have the advert displayed selected in the VAB. If you wanted to go down a non-plugin route then you are limited to creating a fresh model and texture for each separate billboard design and size you want. From my current understanding of how KSP works, the .mu file will search for the texture file its mapped to and will use the first one it finds in that folder. so without a plugin if you used one folder with all the textures and the one .mu file you would only ever see one picture on your billboard, irrespective of how many .cfg files there were. However if each part had its own subfolder, for instance: GameData[folder] ->YourBillBoardMod[folder] ->Agency[folder] ->Parts[folder] ->Billboard1[folder] ->billboard1.cfg ->model.mu ->texture.dds ->Billboard2[folder] ->billboard2.cfg ->model.mu texture.dds I hope that gets the vague idea across and that's just one way of doing it without plugins. Although I feel that it probably wouldn't take you long to learn to drive blender and unity than you could build the model you actually want?