Booots

Here we go! A patch for KSP 1.1.2 finally! Get it here: https://github.com/DBooots/ESLDBeacons/releases/tag/v0.7-alpha This is my first time using github so please let me know if I broke something putting it into a zip. Also, this is my first time releasing something on these forums so let me know if I've accidentally broken any rules. Of course, credit goes to those who worked on this mod before me: @TMarkos and @Kerbas_ad_astra. Known bugs: Jump orbit predictions do not appear (disabled until I figure out how to use the new orbit renderer). Beacon emissives and animations do not work (because I'm new to Unity). Some NREs in the log to do with animations (because the aforementioned animations are broken). Changelog: Should I make a new thread while I'm maintaining this?

Since Luxord52 hasn't been on the forums in a while I tried my hand at fixing the collision meshes and it went... marginally well. I did succeed in getting the .mu file exported with a new collision mesh, and it does load into KSP. But my noob-ness with Unity is showing in that there are a few new bugs to fix. But progress is being made! Thanks for hanging in there, we'll have a release soon(tm)!

UPDATE 2: It works! Thanks to the brilliant modding community I got the UI sorted out. Mostly. The AppLauncher button creates a new copy of itself on every flight scene load, but as far as problems go, that seems to be minor. I'll get that fixed by the time the colliders get fixed (thanks for looking at those @Luxord52!) and we'll be on our feet again!

I just noticed from this thread the following that might affect the LandertronBox for certain new engines. I mean, it will only be a factor when the thrustTransformMultipliers are not all equal, which probably won't bite us for a while but it should get fixed at some point. Unfortunately I broke my IDE by updating it (figures...) so I can't look into doing that yet myself. It should be an easy fix to just change a line or two in LandertronBox.engineThrust.

Sorry guys, I broke my dev environment doing an update. The struggles of compiling for .NET on a Mac... I downloaded Visual Studio for my Windows computer at the office so I'll try compiling there during my break tomorrow. UPDATE: I've got it compiling again, and it throws no errors on loading into KSP. Unfortunately, it seems Unity 5 has broken the entire user interface. This might take me a while to sort out while I learn how UIs work. The internal workings shouldn't have any problems, so once I get the UI sorted out we'll be good to go. I did have to cut out the part of the post-jump orbit prediction that indicates direction because of changes to the orbit renderer, though. But AMUs are really the way to go...

That looks great! Is it possible to get a MM patch to make the stock lights use this system so their lenses change colour too?

I installed Mono 3.12.1 (which, according to the release notes, is the last supporting .NET 3.5), but now Xamarin won't start, saying "This application requires a newer version of the Mono framework." I emailed the makers of Xamarin asking for a download link to an earlier version that might support Mono 3, but who knows how far that'll go. What IDEs do other Mac-based developers use? All the guides here talk about Monodevelop, but that's become Xamarin and can't be gotten anymore.

Hey, I've taken over maintaining the ESLD beacons mod and had my build environment working fine for KSP 1.0.5. This was my first time using C# and setting this sort of environment, but it compiled and worked. Unfortunately, since updating to 1.1 I can get anything to load into the game. Compiling works fine, but I keep getting "System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded." errors in the log from AssemblyLoader related to my dll. I've noticed that UnityEngine.dll has moved from KSP/Data/Managed to KSP/Resources/Data/Managed and there's a second copy of Assembly-CSharp there too. Compounding the problem, I think my version of Mono updated so that could be at play too. I saw this error once before when I was referencing the wrong .Net version, but I haven't changed that setting in Xamarin since fixing that. Can anyone tell me what I'm doing wrong? Are there any experienced Mac developers? I'm referencing the new UnityEngine.dll in /Resources/Data/Managed and the usual Assembly-CSharp in /Data/Managed. I'm compiling in Xamarin studio with the profile "PCL 4.0 - Profile5" which targets .NET 4 or later. I have the newest version of Mono.

I recently did a landing on Ike using RemoteTech where I scheduled a manoeuver to cancel my horizontal and all but 50m/s or so of my vertical and let the Landertron Box take care of the final touchdown. Landing on Duna was actually harder because I couldn't plan a manoeuver like that in the atmosphere but my drogue wasn't big enough to cancel my horizontal velocity and the Landertrons kept firing either too soon or way too late. They're not magical, but they can be very useful, especially with RemoteTech.

So after thinking about this more, the only way to get perfect landings every time for every craft would necessitate implementing an ODE solver. Fortunately, I think the guys over at the Trajectories mod do something like that for calculating atmospheric trajectories. I wonder if we could make their system work for us without adding too much lag to the game. Although I could handle the maths for that sort of ODE, actually implementing it in-game is beyond my modding abilities. As a halfway solution, we could partially fix the drag estimation by using an average drag value (which turns out to be just a_drag_I/3) instead of the initial value. A time-averaged value would be better, but that too would need an ODE solved, I think. We would have to split the outside acceleration term in the code into gravity and drag components, but that shouldn't be too hard because gravity is nicely predictable.

That looks good! I like it! Are you coming in really fast on an atmospheric planet, like terminal velocity or higher? The current model for when to fire does have a problem with high approach speeds on atmospheric planets because it assumes that the outside acceleration on the craft is constant from start of fire to finish which causes it to overestimate the effect from drag as that will decrease as the craft slows down. Once I'm through the end of the semester I'm going to try to write a new dynamic model that will estimate the craft's ballistic coefficient to better account for that.

What's against the rules: the over-keen request for an update or the cringeworthy pluralization of the already plural word 'craft'? "One spacecraft, two spacecraft, many spacecraft." "Using paint and popsicles I made an artsy craft, with even more I made two crafts." (Sorry, pet peeve of mine.)

I know, right? I'd be tempted to bite the bullet and do it this weekend without those mods but I have a paper I need to start writing...

Oh cool! Apparently 1.1 actual is out! Once a few of my 'must-have' mods get updated I'll download it and try compiling this for 1.1.

I'm no texturer and I'm kind of a fan of the old design so I'd be happy with just fixing the collision mesh.

Quick question: Do the converter modules in this mod run only while the vessel is in focus or is there some background processing mechanism for when the vessel is unfocused?

That looks great! I kinda like the hacked-together look of it. Could I recommend rescaling it down so it can fit on small 0.625m landers without looking like they're about to fall over?

I'm getting an NRE and freeze on load while trying to create a new part based on a different one and then re-texturing it using something like this: $[originalPart]{ @name = myPart @MODEL{ %texture = originalTexture, myFolder/myTexture } //other stuff... } It loads up until this part, then gives "NullReferenceException: Object reference not set to an instance of an object" The relevant log entry is enclosed: The original part uses MODEL{} to define its mesh so that shouldn't be a problem (although it doesn't have a 'texture' line). Am I doing this right? Could it be because my .cfg is in a different folder than the original part/model/texture? Thanks for any help you can give!

Is there an easy way of tapping into the heat drawing mechanism of the active radiators? I'm thinking about making a geothermal cooling mod that would allow for much more powerful and efficient cooling while landed by using the surface as a heat sink. I'd rather not re-invent the wheel and code cooling logic from scratch if I could just make a child class of the active radiators and call some sort of draw heat method if that's possible instead.

Is there any chance you're working on a way to see the expandable parts deploy in the VAB? Or even a way to start them deployed? I think that would be great to have. Fantastic mod, by the way! It's completely replaced LLL for my base building needs! EDIT: Also, what do most people do as far as landing legs for surface bases? Do you just spam legs everywhere to keep the base off the ground or are the collision meshes solid enough that I can trust it to sit there steadily without any legs at all?

Here's a link to the GitHub repository I opened with my fork of the ESLD beacons for those of you who are interested in downloading the updated DLL. I don't guarantee anything about it working, but it works for me so far on 1.0.5. The models are broken, however, so I still need someone to fix them. Their collision mesh is broken, I think, because I can't right click on them. Anyone interested in defining a new beacon type should look at the source file ESLDBeacon.cs for the equation used as well as a description of the parameters and coefficients used.

That could be done, with one catch. I'd somehow have to figure out which celestial bodies are stars (or system parent bodies in the case of black holes) so that players can't just install one of these on every beacon and suddenly have super cheap jumps in-system (which is something I'd totally do as a player ). Do you use multiple star systems? Do you know how the mods demarcate which bodies are stars?

The 'virtual' keyword just allows for derived classes to override that method with an identically-named one in their instance. Basically, it lets me create something that, in the eyes of the landertron controller module, behaves exactly like any other landertron but has different underlying logic (ie. for calculating available thrust since I can't just look at the engine on the same part). I'm submitting a PR now, so you can see what I mean in the code. The SmartParts pack has a handy altimeter part that I've appropriated through a MM file to be my stand-in. Maybe just get permission and retexture?

I mean, with the source code you can change anything about it, but doing that would be going way outside of the tiny section I looked at changing and into the base functionality of the mod. So yeah, that could be done, but it's beyond me.

Turns out it was pretty easy to do! I created a child class of Landertron and created new methods to override the fire, shutdown, and thrust calculation methods. Then the old ModeHandler logic takes care of everything like when to fire and accounting for other Landertrons because the child class is still an instance of the Landertron partModule. I just added the new module to a dummy part, and now my LF/O rockets can land with their own engines and the Landertron logic! I could upload the new file here or add a pull request if anyone else is interested in this feature.