Aniruddh

I'm not sure exactly what the problem is, but I'm guessing you've not added references to the relevant .dll 's. If you're on visual studio, right click on references on the solution explorer tab on the right; click add reference, then add a reference to Assembly-CSharp, and Assembly-CSharp-firstpass. Then you should also do the same to BDArmory.dll (or whatever the .dll found in the mod's folder is called).

I think I'm almost there in getting this working, one final question, what does it mean by invRotation? I haven't seen that listed anywhere under the Vessel or CelestialBody classes. How would I get this value? EDIT: I'm guessing it's this one: invRotation = FlightGlobals.Bodies[x].transform.rotation.Inverse();

Looks like I did find a full solution, it's fairly complicated however, it's probably the first time I've experimented with quaternions. I'll have to see how this goes, but this is quite promising!

For my beamed power mod, I was working on getting planetary occlusion data from CommNet. I was wondering how to get a list of all celestial bodies in the game. Is it necessary for me to loop through each celestial body to get it's transform and input that into the constructor OccluderHorizonCulling. Also, what does it mean by radiusX? Reading the website they give a link to in the API, they discuss ellipsoids, aren't planets in ksp spherical? Here is my code so far: public class BPOcclusion : OccluderHorizonCulling { public BPOcclusion() : base() { } public string CheckIfOccluded(Vessel Source, Vessel Dest, string state, out bool occluded) { OccluderHorizonCulling horizonCulling = new OccluderHorizonCulling(transform, radiusXRecip, radiusYRecip, radiusZRecip); QuaternionD invrot = invRotation; Vector3d source = Source.GetTransform().localPosition; Vector3d dest = Dest.GetTransform().localPosition; occluded = horizonCulling.Raycast(source, dest); if (occluded) { state = "Occluded by" + body.GetDisplayName(); } return state; } } There are no parameters for the base class constructor for now, until I can understand what the parameters mean. I'm currently getting a nullref exception in the log, likely due to transform not being assigned to anything yet. Any help on this is much appreciated, I might've misunderstood all of this.

The ideal altitude I have found is 300-400 km, here the spacecraft in 75 km orbit can catch up in ~30 min, and the transfer to the higher orbit to intercept is only ~45 min. So not that long that your Kerbals would run out of life support supplies.

Thanks for pointing this out, I didn't realise it at first. I have found a partial solution to it- it only works if the photon-sail is pointing in the same direction as the root-part of the vessel it's on. I'll experiment with this to see if this can be improved. But, anyways, a framework for the photon-sail part module has been added to v0.4.1. Don't use it in game, but feel free to look at the source code and OP, and see how it will function, once fully released.

You don't have to, if you place your vessel (rendezvous target) in as high of an orbit as possible, then you launch your other spacecraft in a low orbit, the orbital altitude difference means you don't have to wait such a long time. This is what I do.

Probably not.

I would say yes, from what I saw of it earlier.

There is no minimum, you can just build one module if you want. You can build up to 3 as well, it's completely your choice.

Jool orbit. If you want to take your module to it's moons, you are free to. You can also place your modules on the surface of any of its moon (to construct a base). If your modules add to the main station in Jool orbit, try keep part count as low as you can. You can go now, as long as no one else has said they want to go now. Best to do so, as you say your computer isn't very good.

That is correct. After doing that you would pass on the save file to the next person, who would load the save and add their module to the station. You can also just pass on a craft file or just leave your module in orbit, and pass on the save, and let someone else dock it to the station for you.

From reading page 10, it was @catloaf.

Has @epicfailure2020 already sent their module to Jool? Sorry, I've not been keeping up. If yes, I'll transfer @eee's module to Jool and dock it to that. If not, someone else dock them together in lko, and I'll transfer the whole thing to Jool.

My first version was 0.90 (~March 2015) and I'm sure you wouldn't call it 'old-school', but I have memories of first learning the controls, the ui and orbital mechanics in this version. My first ever mission was just a mk-1 pod, a hammer booster (because the flea didn't exist back then), and a mk-16 parachute, just to get to know the controls (I used to think rotating a craft was done by clicking and dragging the navball). I unfortunately don't have screenshots of that since I didn't know how to take them till at least 1.1 came out. The oldest screenshot I still have: This was just after 1.2 released, when I flew the KerbalX to test the new version.

Not really the vessel itself, but you would have to load the save file, which I guess could affect performance?

Unless you have to have the vessel actively steer to the correct orientation based on autopilot mode when unloaded, here is an idea I though of (unless you've already tried this): You could create a custom field in the save file under the right vessel's name, that stores the autopilot mode. You could do this using a KSPField while the vessel is loaded. When the vessel becomes unloaded, you could retrieve the value by loading the save file as a config node, and finding the right vessel using for loops and then retrieve the value.

EDIT: Problem with if statement solved. Also for those who were asking for beamed power propulsion, I've figured out ModuleEngines, so the next release will also have an optional photon sail and thermal rocket part module. I initially though I wouldn't do this, but I'm bored in partial lockdown, so might as well, it'll be a fun addition to this project.

For both receiver modules, I figured out how to load transmitter data directly from save file, so, by definition, multiple save file support will come in the next release. Currently working on resolving a few nullref errors, but should be done by tomorrow.

I know that, but I don't want to have to save/load data when a game save/load happens, I'd rather do it independently of that, so that save/loads are more frequent. Thank you! I will implement this right away. It is indeed not good to not support multiple save files. HighLogic.SaveFolder returns the name of the save right? I'd rather stick to saving the config nodes to a separate file in my mod's folder, so when the user deletes the mod folder, the data about the transmitters is also removed, and there is no residual data in the persistent.sfs.

I added a bit of code that removes vessels in the file that no longer exist in the save. Since, craft in other saves don't exist in this one, their config node in the file will indeed be deleted. Your actual crafts won't be deleted, you will just have to switch to your transmitter spacecraft and back, and the configs will be reloaded.

A Mun Power Station:

v0.3.5 is out and fixes the issue with receivers not working when the transmitter was beyond 2.3 km. This release was 4 days in the making! I pretty much gave up on making KSPFields work beyond the load distance, and instead went for the brute force approach of using config nodes and saving them to a custom file on disk. This means there is a new file in the mod folder under PluginData called save.cfg, if you delete this, the mod won't work! This method means multiple save files are currently not supported, as I don't know how to get the save file's name and id, and how to get the active vessel's save file. Anyways, hope you enjoy this release, it's no longer marked as pre-release on GitHub anymore!

Oh also forgot to mention offset center of mass with RCS, that also confuses mechjeb.

Yeah, sometimes mechjeb's docking autopilot freaks out when you're dealing with huge crafts and haven't put enough reaction wheels and RCS. I can remember how nightmarishly hard it was to try counteract mechjeb's incorrect steering.