AaronLS

With docking ports, you can specify a string for type, and ports can only attach to other ports with a matching type string. Is there anything similar for attachment nodes? Such that I can define nodes on my parts such that they can only attach to nodes of the same type in the editor.

QuickSearch is a great mod, and really a necessary feature anytime you have any list with more than a page of items. Usually it's really easy to implement too and I just want to scream when I see lists that dont support it.

Yes, I did notice that, but I wanted to mention that more than anything that list was the most valuable. Yes, there may be many example of each, but if you aren't even aware of the different mod types they are very hard to find. Any google of "ksp add on" turns up pages listing part modules. This is the first time I've seen the different types all listed together and distinguished as to what their purpose is. I had seen this post when you first posted it, and today I was wanting to mod the recovery process and was asking myself "Is this even possible? Is there a way to mod the entire game? I'm sure I saw someone mention that somewhere." I actually thought I remembered you refer to it as an "Add On" but every google of "ksp add on" turns up just generic pages dealing with any type of KSP mod, which are mostly PartModules. The entire first page of results are just pages that list mods. I began to question whether I was mistaken in what I had remembered, but I kept hunting around and googling and found this post again. Many of the getting started examples and tutorials jump right into things like "Let's make an engine" that is so specific that I found them of virtually no use. I got tired of trudging through that and I've been learning more from looking through code on github than anything else. I just thought I'd build upon that and expand slightly deeper to emphasize exactly what a KSP Add on is. I realize that wasn't the original purpose of the post. But the list was the only comprehensive list I've seen and thought I'd build upon that with just a little bit more concrete information. I find that kind of detailed information is helpful in selecting what approach to take in anything programming related. Conceptual descriptions help a little bit, but seeing just a couple examples helps make it more concrete and that decision process has alot more to go on.

Nice list, I was trying to figure out what type of mod I needed to modify recovery values, and this list really helped. It'd be nice to update with a short mention of how each is accomplished, i.e. inheriting from :PartModule or "a KSP Addon is simply a class marked with the attribute [KSPAddon(...)] and inherits from MonoBehavior. Note even though this doesn't inherit from anything KSP specific, there's static classes such as GameEvents that expose KSP specific hooks into the game. This is a good example of a KSPAddon: https://github.com/magico13/StageRecovery/blob/master/StageRecovery/StageRecovery.cs Note wiring functions up to events so that the Addon can hook and have an opportunity to modify game behaviors: //Fired when the mod loads each scene public void Start() { if (Settings.instance != null) Settings.instance.gui.hideAll(); //If we're in the MainMenu, don't do anything if (forbiddenScenes.Contains(HighLogic.LoadedScene)) return; //If the event hasn't been added yet, run this code (adds the event and the stock button) if (!eventAdded) { GameEvents.onGameSceneLoadRequested.Add(GameSceneLoadEvent); //Add the VesselDestroyEvent to the listeners GameEvents.onVesselDestroy.Add(VesselDestroyEvent); //Add the event that listens for unloads (for removing launch clamps) GameEvents.onVesselGoOnRails.Add(VesselUnloadEvent); //GameEvents..Add(DecoupleEvent); //If Blizzy's toolbar isn't available, use the stock one // if (!ToolbarManager.ToolbarAvailable) GameEvents.onGUIApplicationLauncherReady.Add(Settings.instance.gui.OnGUIAppLauncherReady); //Set the eventAdded flag to true so this code doesn't run again eventAdded = true; } .... GameEvents are a bit funky data structure for exposing events. Here's how you can determine what types you need in your event handler. Type this in Visual Studio: GameEvents.onVesselRecoveryProcessing.Add( And then mouse over .Add( or hit Ctrl+K+P to popup parameter info, you should see the parameter type of EventData<ProtoVessel,MissionRecoveryDialog,float>.OnEvent If you're familiar with Func<X,Y,Z> generic delegates, this is essentially the same thing. The above types in angle brackets `<ProtoVessel,MissionRecoveryDialog,float>` tells you that you need to declare a function with those three parameters: void OnVesselRecoveryProcessing(ProtoVessel vessel, MissionRecoveryDialog recoveryDialog, float unknown) { } The parameter types are self explanitory sometimes, but a primitive type like float is a bit of a mystery. If the documentation doesn't reveal anything useful, then probably just using `print(` to print to Debug window values as the event is triggered is best way to try and guess the meaning of the parameter. https://anatid.github.io/XML-Documentation-for-the-KSP-API/class_game_events.html#a17641c8a2f9a01e61eec763737eb7b89 Once you've declared your function, then pass the function name to .Add. When you reference a function by name without parenthesis then you are passing it as a delegate instead of executing it. If you are familiar with function pointers in other languages, this is a similar concept. RIGHT: GameEvents.onVesselRecoveryProcessing.Add( OnVesselRecoveryProcessing ); WRONG: GameEvents.onVesselRecoveryProcessing.Add( OnVesselRecoveryProcessing() );

I am making solid progress on adding some of the features I mentioned before. I rewrote all the code to apply some of the physics in a different way. By default mine isn't going to be as powerful, however I will have a field in the part config that you can multiply the power if you want to jack it way up. I just think it's a way overpowered to provide such as huge boost during launch for essentially zero cost, and I don't think even the world's most powerful magnets come close to being that powerful. Even conceptual designs of electromagnetic assisted launchers come in the form of very long tracks that slowly accelerate the payload (which would be a neat idea for a facility mod). But it can definitely be fun to play with such a powerful launcher, so I want to make sure you have that option to jack the power way up if you really want to. Once I have something workable I'll post source on github and a release. Probably within 2 weeks. If people try mine and feel they much preferred the old one, I can probably make compiling the old one an easy step and provide that as another release option.

Thanks, helped me at least know that I was on the right track. This was the culprit because somehow I accidentally called findLocalCenterOfMass instead of World: magnetCenter - attractedVessel.findLocalCenterOfMass()

I have two vessels nearby. Vessel A is moving towards Vessel B, but not directly at it. I want to decompose the velocity vector into two vectors, such that V = M + N where M is the vector pointing directly from A to B. I have a point on vessel B "magnetCenter" below and "attractedVessel" is the Vessel A. I get a vector pointing from A to B by subtracting locations "B - A" (magnetCenter - attractedVessel.findLocalCenterOfMass()).normalized I then project the velocity onto that vector to get the component of the velocity pointing from A to B. Vector3 velocityComponentTowardsMagnet = Vector3.Project(attractedVessel.rb_velocity, (magnetCenter - attractedVessel.findLocalCenterOfMass()).normalized ); printIntermittantFormatted("rel V: {0:#.00}, rb_V: {1:#.00}", velocityComponentTowardsMagnet.magnitude, attractedVessel.rb_velocity.magnitude); As expected the projected result's magnitude is smaller than original velocity, but when Vessel A is a good distance away and moving directly towards Vessel B, then I would expect the magnitude of the velocity and the magnitude of the projection to be very close. But I get a big difference such as "rel V: .74, rb_V: 4.36". Very similar result from using vessel.rigidBody.velocity instead of vessel.rb_velocity. The two are very close but are not identical(when referenced in the same fixedUpdate) Vector3 velocityComponentTowardsMagnet2 = Vector3.Project(attractedVessel.rigidbody.velocity, (magnetCenter - attractedVessel.findLocalCenterOfMass()).normalized ); printIntermittantFormatted("rel V: {0:#.00}, V: {1:#.00}", velocityComponentTowardsMagnet2.magnitude, attractedVessel.rigidbody.velocity.magnitude); I also tried this but it seemed to give me non-sense I think because it is not the relative velocity of the center of mass and it also incorporates angular velocity: var relativeVelocity = attractedVessel.rigidbody.GetRelativePointVelocity(magnetCenter); I have a feeling it's because I'm not accounting for the velocity of vessel B. I really need to get the true relative velocity and then do the projection on that. Such as the relative velocity when you've targeted one vessel.

That sounds like a good best practice. I did some test and it appears with physics warp, both values are identical, I.e. 1x .02, 4x .08 With regualr warp though, x5 has Time.fixedDelta .02, and TimeWarp.fixedDelta .10 So you are right about using TimeWarp.

Is there a reason one would use TimeWarp.fixedDeltaTime in their fixedUpdate for physics? I would hope if someone were doing a physics warp, then Time.fixedDeltaTime would reflect the appropriate delta so that it can be used regardless of warp.

Thanks! I must have had a syntax error somewhere cause now OnFixedUpdate is showing up. - - - Updated - - - Is there a reference to help with scaling measurements ingame versus code? I.e. a force vector magnitude of 100f equates to what? 100N? In-code distance of 50f == 50 meters ingame?

Trying to understand how to properly apply forces. 1) If I want to apply a constant force, do I need to call AddForce in every update? 2) Conceptually forces are applied over time. So if I call AddForce, how long is the force applied, until the next update? ( ~1/30th of a second) 3) I see lots of Unity discussions saying physics should be done in FixedUpdate, but I am not seeing an option to overload such a function, only OnUpdate. Am I just seeing old documentation, or has KSP exposed FixedUpdate as OnUpdate? For example, the below code attracts vessels to each other. ++updateNth; if ( updateNth % updateResolution == 0) { var centerTransform = this.part.FindModelTransform("MagneticDockingRing"); foreach (Vessel vessel in FlightGlobals.Vessels.Where(v => v.loaded)) { Vector3d vesselPosition = vessel.GetWorldPos3D(); if (Vector3.Distance(centerTransform.position, vesselPosition) < 800f) { Vector3d forceVector = (centerTransform.position - vesselPosition) * (float)updateResolution ; vessel.rigidbody.AddForce(forceVector); } } }

When using the Reload All button from Database, it scrolls lots of messages in the database, many of which scroll off screen. Is there a way to have it preserve these messages or increase number kept?

I added a docking port to the master part like so. I have to leave early tomorrow morning for a week long business trip, but when I get back I'll look at adding that to the firing process. Then I'll try and figure out if it's possible to add a GUI slider that can control how far the port is offset. Not sure where to begin with that or if it's possible. I'll probably hunt through other plugins to try and find one the does "design time" part manipulation as an example. Long term a proper implementation would probably be either an alternative master part, one with/without docking port, OR another slave like part to act as the loading chamber. It'd be nice if it could be left up to the player to place a regular docking port anywhere they wanted, and somehow flag it as the "pre-firing decloupler" but I don't know that there is anyway in the GUI to support this. If I can't solve the "slider" problem, then maybe a brand new docking port part with a different name, and just understand that when the mass driver fires, then our code will find ALL of your loading chamber ports and decouple all of them. This would solve the positioning problem and give the player alot of flexibility in where they put these special ports, or if they want multiple ports. More ambitiously, I was thinking about how to emulate a magnetic "capturer" such that instead of having a docking port offset way back, have another electromagnetic ring. It would implement docking port behavior, with a larger acquireRange setting, but would visually look like a another electromagnet ring, so the docking port capture node is in the space inside it, and appear that the craft is magnetically held inside this loading chamber/capturer ring. The craft would still need a docking port to be "captured" but our port, maybe a small "Ferrite Tracking Ring" could be a new part on craft that implements the craft side of the docking port so that it could be placed mid-craft. Either that, or not use docking ports at all and just implement capturing physics so that "anything" could be held in the capture ring, but that seems more ambitious. // *** BEGIN: Docking Port *** // add a docking port, the actual attach node is offset 0.2828832 to account for the size of the docking port node_stack_chamber = 0, -6.7171168, 0, 0, 1, 0, 1 MODEL { model = Squad/Parts/Utility/dockingPort/model position = 0, -7, 0 } MODULE { name = ModuleDockingNode referenceAttachNode = chamber nodeType = size1 } // *** END: Docking Port ***

So I tried to make a part that behaves like a docking port. This is almost identical to existing stock docking part, but I do not have a decouple option, only a "control from here" option. Does that behavior not come with the ModuleDockingNode? Do I need to make a plugin that inherits from the DockingPort class? Obviously plugins give you alot more control to implement custom code, but when you instead are trying to leverage existing stock behavior, what is the difference between using a module in a part config, versus inheriting from the part in a plugin? PART { name = testPort module = Part author = aaron mesh = model.mu scale = 1 rescaleFactor = 1 node_stack_top = 0.0, 1, 0.0, 0.0, 1.0, 0.0, 1 node_stack_bottom = 0.0, -1, 0.0, 0.0, -1.0, 0.0, 3 node_attach = 0.0, 0, 0.0, 0.0, 0, 1.0 TechRequired = advConstruction entryCost = 12500 cost = 12500 category = Utility subcategory = 0 title = Test manufacturer = Test description = Test attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 10 dragModelType = override maximum_drag = 0 minimum_drag = 0 angularDrag = 0 crashTolerance = 9 breakingForce = 600 breakingTorque = 600 maxTemp = 5000 MODULE { name = ModuleDockingNode referenceAttachNode = top nodeType = size1 } }

Northstar, I think these lines for both parts are missing a negative. I always have to invert the networked parts as I stack them. I looked at the same settings on fuel tanks, and they match this pattern instead. No clue other than just looking at the pattern stackable fuel tanks follow. I edited mine locally and can stack them without inverting now. Instead of: node_stack_bottom = 0.0, -1, 0.0, 0.0, 1.0, 0.0, 3 This: node_stack_bottom = 0.0, -1, 0.0, 0.0, -1.0, 0.0, 3 It'd be neat if there was some way to mount a docking port such that you could dock in the loading position of a rail gun in space, and have the firing automatically decouple the port just a moment before firing. Maybe something shaped kind of like 3MMM's model, so you RCS down the "barrel" of the mass driver to dock with the loading position docking port. It's hard to RCS into the loading position and remain stable long enough to switch to the driver and fire it. Anyhow, as it is it's really cool mod. I want to put one in orbit with a solar sail mod so that I can restore its orbit after each firing.

Yeh good point, worth checking. I've had this happen where I had side tanks that became uneven, between each other, but I only would lose control once I got to upper atmosphere(30k+) where control surfaces had less effect.

1) If you have any wings or control surfaces which are large enough to flex at all, then you can get roll or other anomalies. Perhaps if you have large wings or heavy objects mounted on them. Struts can sometimes help relieve that problem. 2) If you have angled control surfaces then yawing can cause roll and vice versa. This can make STS ineffective, and with STS off attempts to counter roll may make it worse. I used to have issues with yaw causing rolling and vice versa. Dedicated control surfaces that don't serve dual purposes helped. Essentially same thing you have on real planes: Ailerons: These are the controls on wings. Disable Yaw and Pitch, leaving only Roll. Elevators: These should be far back on the plane. Disable Yaw and Roll, leaving only Pitch. Rudder(s): These should be far back on the plane. Disable Roll and Pitch, leaving only Yaw. Elevators should not be angled, and rudders should be perfect 90 degree angle. You can probably find a way to work outside these guidelines, but you got to know what you're doing. If you try to put two rudders on top at 45 degree angles so they can double as roll/yaw, then a roll will generate some yaw, and yaw will generate some roll. In such a situation STS will fight itself, and with STS off you will be fighting yourself as you correct for yaw you will then have to correct roll, etc.

I thought yall were talking about Kerbal for a bit and was confused. They should have named it Kol instead of Kerbol.

Yeh I wondered about that to. 1x6ShroudSolarPanels.cfg has emissiveConstant = 0.95 heatConductivity = 0.04 // 1/3 the default If we consider the ladder's case to be a similar shielding, seems like it would be similar. I'll give that a try after I get some sleep.

Tried putting this ladder on a trailing edge thinking that might shield it from drag, but it still heats up much faster than other parts and eventually blows way before any other part is close to blowing, unless I limit speed. They are a 2000 degree part like most everything else. Flying at 18k-20k altitude at 1200m/s. Just wondering if there's anything that I can do to improve the situation.

Yeh, for molecules to behave this way, they'd have to be more like billiard balls, but they simply aren't. Even when two billiard balls that collide on opposing vectors and come to a stop, they still release that energy as soundwaves, deformation, structural integrity loss(breaking of intermolecular bonds), and heat. This is why such a collision is louder than other deflecting collisions. There might be some interesting things happen very very rarely on an atomic level. The energy level of molecules varies, imagine one might be bumped into in such a way enough times to get it going extremely fast. It could theoretically gain enough energy for a collisions to break it into hydrogen/oxygen, but it would be extremely rare. I've seen someone do the calculations and the odds of it are extraordinarily rare that a molecule reach that energy level. Usually once a molecule gets going extremely fast it quickly bumps into enough things that the energy is spread out before it can go faster. The distribution of energy among the molecules would be a bell curve because of this.

If a player who is doing mining for the first time encounters this, they are going to be misled to that huge polar area, and have a very frustrating time! My take away from this would be that an average player is going to look at this and think, wow, even though I know this is a rough map, surely I can hop around just about anywhere on the pole and find some good areas of ore. As bright and solid as the area is. Intuitively, one would think something that is inaccurate would mean edges and lightly colored area should be taken with a grain of salt, but a very large solid bright area would be a strong indication that ore can easily be found there. A purely GIS approach would solve the pinching problem by generating the density map separately for each pole using a polar specific projection, then patch each result on to each of the poles with a gradient mask at something around a 50 latitude that gives a good transition onto the original. There can be alignment issues at the transition though. This would probably triple the processing time but be less than an order of magnitude. Maybe that is not feasible within the engine though. Personally, if it were me I would keep it on the radar to revisit when bandwidth is available.

Ah, if I burn normal, and viewed my velocity as the sum of two vectors: the existing vector pointing prograde, and the vector pointing normal, then my new vector is the previous prograde vector (p), plus the normal vector (n). Of course in practice, as I burn locked normal then my angle is changing, but if assumed that I burned just for a moment normal. This would be a right angle and you would calculate the new vector as (p^2 + n^2)^.5, which means that very little of the burn goes towards increasing the magnitude. If p == 1000, and I perform the same burn norm(without tracking normal since that would make things complicated) that would be 500 m/s in the normal direction: (1000^2 + 500^2)^.5 == 1118 Delta Energy A == ( (1kg * 1118 m/s)2 - (1kg * 1000 m/s)2 ) /2 == 124632 J If instead initial p == 1100 (1100^2 + 500^2)^.5 == 1208 Delta Energy B == ( (1kg * 1208 m/s)2 - (1kg * 1100 m/s)2 ) /2 == 124632 J So yeh, the fact that only a small portion of the normal burn contributes to magnitude, completely cancels the oberth effect. If my initial prograde speed is higher, that means as per Pythagoran thereom, less of of my normal burn contributes to the magnitude. I imagine there's a way formula wise to substitude the pathagorem formula in for 1118 and 1208 and somehow show that they are always equal regardless of what the value of p is, the initial velocity. - - - Updated - - - Thanks to both for helping me understand.

So looking at a formula for calculating the resulting kinetic energy from a change in dV. Craft mass == m == 1kg Starting Velocity Scenario A == va == 1000 m/s Starting Velocity Scenario B == vb == 1100 m/s If I burn to add 500 m/s of velocity in both scenarios, I would calculate the change in energy as Delta Energy A == ( (1kg * 1500 m/s)2 - (1kg * 1000 m/s)2 ) /2 == 1250000 J Delta Energy B == ( (1kg * 1600 m/s)2 - (1kg * 1100 m/s)2 ) /2 == 1350000 J Assertions: 1) In both scenarios, the amount of fuel consumed to obtain a 500 m/s change in velocity is identical. 2) In the second scenario, I've gained more kinetic energy for the same amount of fuel consumption. 3) Conservation of energy is not violated. In the first scenario, 100 kJ more kinetic energy was imparted to exhaust than the second. So the same amount of kinetic energy was produced, just a different portion was divided among exhaust and ship. If I've misunderstood anything in my assertions, please let me know. Now how do I interpret extra kinetic energy? This looks like only a small difference, but it seems like the inverse square law of gravity to distance allows it to have a huge affect. As I move away from the planet, my kinetic energy is being converted to gravitational potential energy. So I can essentially I can go further. 1250 kJ takes me the same distance in both cases, but in the first that will be the apoapsis(assuming non-escape velocity, and a infinitely thin ellipsis such that I am 0 m/s at apoapsis) and in the second I have 100 kJ left over and will be able to go much further. Since gravity is inverse square to distance, that small 100 kj of extra kinetic energy will translate to a huge amount of extra distance, correct? My velocity would be much lower at that point, so I'd be covering less distance over time, but I would speculate that the inverse square of gravity means that it will take exponentially longer for that kinetic energy to be converted to gravitational potential energy. I could determine my velocity when 100 kJ is left by solving for velocity: 100000 J == (1kg * v)2 / 2 v = 447 meters/sec Without calculating exactly how far from the planet I am at that point, I know the influence of gravity is exponentially smaller(maybe wrong phrasing) due to inverse square law. Therefore it seems like with a big chunk of my velocity remaining, I will be able to go much much further. So in summary, while an extra 10% starting velocity only ended up with an extra 8% J kenetic energy (100 kJ / 1250 kJ), the effect in terms of distance would probably be amplified much more, maybe exponentially. It seems like in practice this is what happens, but not sure if my speculative "why" that happens is on the right track. Velocity Neutral Burns I understand why retrograde burns also benefit from this effect, since it is still a change in velocity and so energy change is governed by the formula. But what about a burn that doesn't change velocity such as a radial or normal burn? Mathematically it seems like the oberth affect wouldn't apply, since there is no change in velocity during the burn. (I thought these didn't change velocity, but it seems in practice they do, but I suspect that's only due to the radial/normal stability not keeping me perfectly aligned, correct? A perfectly aligned normal or radial burn should not change velocity?)

If anything, this is more evidence that what is happening now politically will just as easily be reversed in the near future, rather than an indication of a trend. The movement of political influence and the opinions of the public follow trends which are often short lived. Both should be viewed as chaotic systems. You could say that the brain and therefore emotions that govern such decisions are fully deterministic systems, but in the absence of being able to accurately model these extremely complex systems, one should consider emotions to be unpredictable. Therefore I wouldn't call what is happening now politically a trend, at least not in terms of anything long term. The rational that governs these decisions usually involves limited sampling of facts, very little modelling of how their decisions will impact the future, and the measures by which they determine the value of endeavors is not always the same. Often times they measure the value of funding based on strategic or "accomplishment" value, rather than scientific value. Whether or not this "trend" lasts long term, gets significantly worse, or gets significantly better, is up to the whim of people, which are usually very short lived trends.