• Content Count

  • Joined

  • Last visited

Community Reputation

3,464 Excellent

About DMagic

  • Rank
    Capsule Communicator

Recent Profile Visitors

14,324 profile views
  1. Have you tried running the engines at different throttle levels? There seems to be a massive impact of running engines at very low throttle vs full throttle, both in terms of garbage allocation and overall performance. For a real fun time set the engines's throttle limiters down to about 5%, then throttle up just a tiny amount... If you have MemGraph open you can see the garbage allocation go through the roof.
  2. @CanOmer Yes, but the difference is fairly small unless you have the screen covered with KER readouts.
  3. So now we just need to feed the disabled VesselDeltaV object the correct values from a better calculator. Then the stock burn time indicator (which is very nice) could still work as indented.
  4. From what I can tell it updates the values for all stages in a coroutine about every 4 seconds, and I think the active stage every 0.2 seconds (and tossing out a big garbage dump for each stage ). There are multiple dv related items in the settings file (look under DELTAV*), I'm not sure if they are available to change in-game. All of this seems fairly pitiful given that both MJ and KER can do this without bogging down the main thread or generating garbage (I assume, for KER), and while keeping the values more up-to-date. I can't imagine either dev/maintainer switching to the stock method, which means most people will experience the stock dV calculations as nothing but unneeded overhead. Has anyone figured out if they can be turned off easily (turning off the burn time setting doesn't change anything about the dV calculations)?
  5. It's only the "extended burn time" indicator that is off by default (you can also turn it on from the in-game settings menu). As far as I can tell this is just the thing that allows you to set the burn time split (50% of the burn before the node, 50% after, by default). The dV calculations and the little indicators on the maneuver node bar will show up regardless of whether that settings is turned on or not. This is without extended mode, you can see the little "0" indicator to show that the burn can be finished with only the current stage: This is with extended mode: I don't know how much of an effect that "start burn" time has on performance, it obviously shouldn't have any in the VAB. But the dV calculations are always running. I don't know how it runs on potato computers, but it does seem like there could be a noticeable impact on vessels with lots of stages.
  6. @Gordon Dry Do you know if the same message appeared in KSP 1.4? That might just be a Linux problem, since I don't see the same issue in Windows using 1.5. In any event it would only affect the little anomaly viewer window shown when using the BTDT. Maybe. But I'm waiting for KSP 1.5.2 before I bother to update.
  7. KER by itself isn't generally that bad for memory allocation. It's only when you cover the whole screen with readouts that things can get out of hand. The new deltaV calculator does, disappointingly, seem to be generating a fair amount of garbage. It doesn't run every frame, but it adds up, and it gets worse with larger vessels.
  8. There's no particular reason to use a top-left anchor. If you set the anchor and pivot center to top-left (pivot x = 0, y = 1) then I suppose it's a little easier to position elements; x pixels to the right of the parent's left side, and -y pixels down from the top. If you have a completely static UI, no option to resize the window, no dynamically changing elements or window size, then you can set the anchors to whatever you want. Top-left (or bottom-left) does make some sense for the top level of the UI window, since it makes it a little easier to position the window on screen (though you do run into potential problems with the UI loading off the screen on the right or the bottom, having some code to clamp the window position to the screen helps with this). But for a dynamic UI there are lots of cases where you want other anchors. You might want elements that stick to different corners of your UI when you resize it. Or you want elements to expand to fill the window (using the blue anchor preset options). And there are other more complicated situations, like you want a label to be 1/3 of the way along a resizable bar, then you would need to manually set the anchors. As I think I mentioned somewhere in the tutorial, the rect transform anchors are confusing and the best way to get a handle on them is just to fiddle around with them. This is also a situation where having your code run in the Unity editor is helpful. You could run all of the code needed to add a re-size handle to a window, then just play the scene in the editor and see how the different rect transform anchors behave, instead of having to run KSP every time you need to change something.
  9. To be clear, the Unity Assembly is one that can be imported into a Unity project and used by assets within that project. It only required references to the UnityEngine.dll and (probably) the UnityEngine.UI.dll. This is imported into Unity as a compiled dll, not as un-compiled .cs files, then all of its classes are accessible by Game Objects within Unity. Whenever you create a Unity project it also generates an Assembly-CSharp.dll (and several others). This is not related to KSP's Assembly-CSharp.dll (well, technically this is how KSP's .dll is generated, through Squad's original KSP Unity Project). The new Assembly-CSharp.dll is the default assembly file where any code added through Unity is compiled. This happens when you create a new .cs script somewhere in your project's Asset folder. That code will be compiled into the Assembly-CSharp.dll. In general you should never have to do anything or worry about the Assembly-CSharp.dll generated by your Unity project. The Unity Assembly that you create is an already compiled .dll file that you import directly into Unity. So the answer is no, you should not reference the Assembly-CSharp.dll generated by the Unity project, and you should not include that file with your mod. When you make the KSP Assembly you do so basically the same way as you would for any other mod. You add references to the UnityEngine.dll and UnityEngine.UI.dll, and to KSP's Assembly-CSharp.dll. Then, in this case, you would also add a reference to your Unity Assembly .dll, so that it can be accessed directly from the KSP Assembly. UnityUIAssembly.dll -> this is the Unity Assembly that is imported into Unity | | ---> UnityEngine.dll ---> UnityEngine.UI.dll KSPAssembly.dll -> this is the KSP Assembly | | ---> Assembly-CSharp.dll -> this is from the KSP folder, not from your Unity project folder ---> UnityEngine.dll ---> UnityEngine.UI.dll ---> UnityUIAssembly.dll -> this is your Unity Assembly file Both the UnityUIAssembly.dll and the KSPAssembly.dll files are placed in a folder in KSP's GameData folder and loaded into KSP. The basic problem, and the reason for this whole run-around method, is that you can't import an assembly into Unity that has a reference to KSP's Assembly-CSharp.dll. Unity gets confused, or thinks there is some loop of references, or something, and it will fail to import. So if you want code that you can access from within the Unity Editor, then you have to make a separate assembly and go through some indirect method of tying that back into KSP's code. It isn't absolutely necessary to do this, Fengist has a great tutorial for how to make a UI with a single, standard KSP Assembly. It works well for simpler UI's, but I would have a hard time doing many of the things that I have in my UI's without having code that is directly accessible from within Unity. You can also use this same method for doing other interesting things, like adding custom behavior into KSPedia entries.
  10. DMagic

    Universal Storage II

    OK, I see it now. I will see if it can be worked around.
  11. DMagic

    Universal Storage II

    I'm not seeing this, either by reverting or using undo. What version of KSP is this in?
  12. There are at least 3 bug reports on this issue, some of which have been around since about the time MH was released. Both for the tubes to occlude parts within them, and to fix the trivially simple drag cubes (the problems associated with drag cubes for hollow parts are well known and easy to work around) that make these parts terrible for drag. So it's not like they aren't aware of the issue.
  13. DMagic

    KSP Weekly: The Falcon

    I think it's a bit of a semantic argument, whether "closing" the attach node vs attaching a part reduces drag. Drag is reduced on a part when it is shielded or occluded in some way by another part. The most obvious way to do this is by attaching another part to, you can see it in the drag cube section of the part windows on that screen shot. The faces of the part that are "open" have a higher drag surface area, ~3, while the faces that are "closed" have around 1.8; having a lower surface area (even on faces that aren't directly in line with the thrust) will reduce drag on the part (you can see the same thing on a simple cylindrical part with an open bottom end vs a closed bottom end). I suppose what could help clarify is to know what happens when you attach the same part in the same location, once by attaching to the node, and once by using only surface attach. I don't know how KSP handles surface attach parts for drag calculation. Does KSP only care about the physical arrangement of parts and which is the parent of which? Or does being stack attach make a difference vs being surface attached?
  14. @Kitspace Yes, they basically become SCANsat parts. There is a section in the KSPedia entry that goes over SCANsat resource scanning. @Tacombel Seems unlikely. The only contracts this offers are for conducting scans (ie Conduct a biome/multispectral scan of the Mun).
  15. DMagic

    Harvester AMA on Reddit

    I haven't seen it mentioned elsewhere. So here is a link to HarversteR's (KSP's creator, for anyone who doesn't know) AMA, up on Reddit now: