DMagic

Members
  • Content count

    3361
  • Joined

  • Last visited

Community Reputation

2560 Excellent

About DMagic

  • Rank
    Capsule Communicator

Recent Profile Visitors

7162 profile views
  1. I like the idea of providing a Delta V readout in the editor. It simplifies some issues and allows you to work around problems with weird designs by measuring dV separately for the different components of a vessel, like an Apollo-type orbiter and moon lander situation. I also like keeping it simple and not cluttering up the UI with another window full of buttons and labels. I like the idea so much I went ahead and did it.
  2. @Rodger That's a good idea. The simplest way to handle it would be a to re-order the list so that the current planet is always at the top. I need to re-order the list anyway to make it show the planets in order from inner to outer and to group moons together with their parent planet. A separate button might also work, too.
  3. This sounds vaguely similar to something I started working on during the long gap between KSP 1.0 and 1.1. I got to the point where it needed a UI to start getting things working in-game and I stopped because I was waiting to see what kind of support 1.1 would have for the new UI system. https://github.com/DMagic1/KSP_Vessel_Manager It started out as just a new mod for making in-game notes (hence the internal name, BetterNotes) to attach to each vessel. But then it expanded based on some of the requests people had for Contracts Window +. You would be able to assign contracts to each vessel, monitor their progress, and keep a record of any assigned contracts that were completed by that vessel (I think all of the contract related code was converted to work with Contract_Parser, the same dependency used for CW+ and CapCom). I expanded it to cover something similar for science: tracking which instruments you had on board, the science results on board, the results that had been transmitted from that vessel, and allowing you to transfer data to different science containers. There were also modules for monitoring and transferring crew, some basic vessel stats, and notes. I also added a sort-of mission check list module. There are a number of pre-defined parameters, things like land, take-off, rendezvous, collect science, etc.... And all of the code for actually monitoring such events is there in some capacity (without taking into account any changes made since 1.1 or 1.2), including things like making sure that you actually pass some altitude threshold when taking off from another planet (to avoid mixing up a proper take-off with a little hop, or the kind of jumps you get while driving around). Everything was written with the intent of being used with the new UI system, though I wasn't as familiar with it as I am now. In any event, I never got around to actually doing anything with it and am unlikely to do so in the future.
  4. It looks like a duplicate experiment error, though I'm not sure where it's coming from, I didn't see any obvious duplicates during the loading process (look for Config(EXPERIMENT_DEFINITION)... during the loading stage of the log file). This one showed up at the end of loading though, it's actually from Orbital Science, but it's triggered by the presence of a duplicate experiment definition. This error looks to be fixed for KSP 1.3, but for now this breaks all subsequent experiments from being loaded. [ERR 00:39:01.711] [DM] Whoops. Something really wrong happened here, a duplicate science experiment definition may be present somewhere; stopping this contract experiment from loading...System.ArgumentException: An element with the same key already exists in the dictionary. at System.Collections.Generic.Dictionary`2[System.String,ScienceExperiment].Add (System.String key, .ScienceExperiment value) [0x00000] in <filename unknown>:0 at ResearchAndDevelopment.loadExperiments () [0x00000] in <filename unknown>:0 at ResearchAndDevelopment.GetExperiment (System.String experimentID) [0x00000] in <filename unknown>:0 at DMagic.DMConfigLoader.configLoad () [0x00000] in <filename unknown>:0
  5. Missing experiment definitions are usually a sign of duplicate experiments somewhere in the GameData folder.
  6. SCANsat does not measure altitude above the atmosphere. It measures from the surface, the same value as what you would see on the altimeter.
  7. Any GameParameters.CustomParameterUI, or any of its derivatives requires that you set a tooltip string, even for the StringParameter, which doesn't display its tooltip. There is a bug reported in the tracker (on the QA branch) so hopefully someone will get to it.
  8. @Rodger It looks like it's wrapping the map around the bottom so that the North Pole shows up there. What happens if you change the map projection type? Or if you change the map size? The anomaly scanner from DMOS doesn't pick up the new types of anomalies (Mohole, Kerbin ground stations). @vardicd Use the latest version:
  9. I think it's worth re-emphasizing this. There are a lot of really wasteful part textures in the Squad folder. Many fuel tanks that use similar, or nearly identical textures each have their own copy; compare the old fuel tanks to the Mk2 and Mk3 folders, where a single large texture is across 2-8 parts. If you are at all worried about the amount of RAM used by stock KSP then you should support overhauling the oldest parts (even if parts only account for a relatively small part of the overall RAM usage). But, in my opinion, by far the worst offenders are the regular and small docking ports. Just open those two folders and look at what's inside, it get's only worse when you realize those 1024*256 textures (which resemble nothing but grey smudges) are only used for that little ring that gets pushed into the docking ports' parent part. Most of the improvements people are discussing regarding the old rocket parts entail only minor changes to the part geometry, maybe adding round end-caps to the fuel tanks, and some other small details, even engines (probably the most visually complex parts in the game) don't use all that many triangles. It's the textures that are really in need of improvement.
  10. This thread will help if you are interested in the order of events and which methods are called for a PartModule.
  11. Dev notes from that time suggest that C7 and HarvesteR were primarily responsible for 0.23.5, though I didn't see anything specific about parts. http://kerbaldevteam.tumblr.com/post/79311516702/devnote-tuesdays-the-forward-progress-edition
  12. I think it was C7 who made those parts. All I remember from Hugo were some spaceplane parts that I don't think were used. Personal attacks aside, this has always been a poor argument. Being able to criticize something does not require being able to create that same thing yourself.
  13. Could whoever write these try, in the future, to more clearly separate discussion of the various development branches? Right now there are three separate things being discussed (localization and its pre-release, expansion, and console), sometimes all in the same paragraph. I don't remember any explicit confirmation of which version the console release is targeting, but even if it's the same as one of the two PC versions it should still be discussed separately. The same goes for the localization and expansion discussions. Just in this post the basic structure, in regards to the different development branches, goes: Expansion -> Localization -> Console -> Expansion -> Console -> Expansion -> Localization -> Expansion This is not a recipe for clarity.