Jump to content

toadicus

Members
 View Profile  See their activity

  • Posts

    1,147

  • Joined

  • Last visited

 Content Type 

Everything posted by toadicus

  1. toadicus
    blizzy78, if it's something you're interested in, I've developed a wrapper class for late binding, which allows mods to optionally use your Toolbar without depending on any of its code. I've shared it with TriggerAU, who I knew was working on the same thing. If this is useful to you or any other developers using your Toolbar, it's free to use. Also, if you've any recommendations for how you think it would be done better or more in line with your ideas of things, feel free to let me know.
  2. toadicus
    Great, hope it helps! I've added the docstrings, and will offer to Blizzy as well.
  3. toadicus
    I've got a solution to late binding; you're free to use it if you'd like. I don't know if it's a particularly good or proper or conventional solution, but it does work.
  4. toadicus
    VOID has been updated to version 0.9.16! This version adds 100% optional support for Blizzy's toolbar. Use it or don't! If Blizzy's mod is present, VOID will detect it and use it if you configure it to do so. If you don't, it won't, whether it's there or not. I've also fixed a couple of bugs. FYI, I am still working on the scriptable panels! But... it's a time consuming endeavor, and I'm currently working two paying jobs at the same time, so productive contiguous coding sessions for VOID are hard to come by. So, not to fret, I'm still pushing forward towards that goal, but it's probably going to be into the new year before I get it done. v.0.9.16 [2013-12-14] * FEATURE: Optional support for Blizzy's Toolbar. * BUGFIX: Orbital pane: Fixed erroneous mislabeling of "Time to Apoapsis" to the correct "Time to Periapsis". * BUGFIX: Certain values will no longer display debug information inline. * BUGFIX: VOID will no longer spam seemingly-random integers into the log file. NOTICE: The zip file I uploaded originally contained the wrong .dll; I've fixed that for my mirror and spaceport. Enjoy!
  5. toadicus
    Thanks! I didn't know that, and will revise, whether FAR models that or not. If it helps any, this seems to happen to previously-placed airbrakes (or something) after placing any additional parts in the editor. As I continued to revise the design, I wound up needing to re-place the first two air brakes as the last two parts on the plane after I added any other parts. As long as the only two airbrake parts are the very last parts on the plane, it works. If they're not, it doesn't seem to.
  6. toadicus
    @ferram4 I'm working on a plane, and am having some weird asymmetric control issues. I am adding some standard control surfaces as spoilers, using surface attachment to stick them on the top of of some wings. When I add pair 1, which attach to some wing connectors, everything is fine. One pair of spoilers, works just fine. But, when I add the second pair, out a bit farther and attached to some delta wings, I get very significant asymmetric control. Pitching induces some roll, and braking induces very significant roll. Two pairs of spoilers, rolls like a crazy rolling thing. For example: .Removing all of the non-airbrake control surfaces from the brakes action group lessens the effect slightly, but it doesn't go away. Any ideas?
  7. toadicus
    The closest that I'm aware of is ModuleManager. That's not where the focus is, but there are at least similarities in that it offers a small scripting language in cfg-format files geared to a specific purpose.
  8. toadicus
    Here's a cleaner (looking) way to do that with LINQ. I don't know enough about LINQ to know if it's actually any better or faster. float maxThrust; float minThrust; foreach (ModuleEngines EngineModule in TWR1Vessel.Parts .SelectMany(p => p.Modules.Cast<PartModule>()) .Where(m => m.moduleName == "ModuleEngines") .Select(m => m as ModuleEngines) .Where(m => m.isOperational)) { maxThrust = EngineModule.maxThrust; if (EngineModule.throttleLocked) { // This is an SRB; its minThrust is the same as its maxThrust minThrust = EngineModule.maxThrust; } else { // This is not an SRB; get its minThrust minThrust = EngineModule.minThrust; } TWR1MaxThrust += maxThrust; //add engine thrust to MaxThrust TWR1MinThrust += minThrust; //add engine thrust to MinThrust, stock engines all have min thrust of zero, but mods may not be 0 } If you're really wanting to get at the config files, you will need to know their file path (or be willing to search for it), at which point you can get the ConfigNode through ConfigNode.Load() or GameDatabase.GetConfigNode(). If there's a better way to do that, I'm not sure; I've never dealt much with part classes. What do you want from the config file that the part object doesn't have?
  9. toadicus
    To my awareness, the config loader really isn't set up to have this sort of functionality added. It could be done by specifying some sort of custom scripting language for use in a particular field within a module, and then using a plugin to parse that field and take actions as appropriate, e.g.: MODULE { name = magicalCodeAndLogicThingy INPUT { name = IntakeAir rate = 1.0 } OUTPUT { contingency = if(mainBody==Kerbin) name = Oxygen rate = 0.21 } OUTPUT { contingency = if(mainBody==Laythe) name = Oxygen rate = 0.15 } } But, implementing something like that with broad re-usability is going to involve a lot of eval calls, or be very laborious on your part. If you have a specific application like this example in mind, it would be easier to do something like this: MODULE { name = magicalOxygenIntake INPUT { name = IntakeAir rate = 1.0 } OUTPUT { name = Oxygen PLANET { name = Kerbin rate = 0.15 } PLANET { name = Laythe rate = 0.15 } } } Then in your magicalOxygenIntake OnLoad override, you scan the PLANET nodes (using the existing ConfigNode tools in the KSP API) to define specific behavior based on those blocks. So, the real question to be asking is: what are you trying to do? If you're trying to write a scriptable language for cfg files that allows for broad reuse, you might start by researching what ModuleManager has done with loading its config files, and then start specifying a language. If you're looking to make a magical oxygen intake, what you really want to do is work inside the tools already in KSP's API to build a PartModule that does what you're looking for.
  10. toadicus
    Thanks to my pseudoreligious attention to FAR, I stumbled across blizzy's "standardized" toolbar button integration plugin thinger today (and noticed that diomedea suggested that VOID would benefit from it). Swapping VOID to the toolbar (or even allowing one to swap between the button and the toolbar) should be pretty easy. I'm all about helping the modding community clean up our screens, but before I got that route, any objections here?
  11. toadicus
    To follow up on this as well, the ScreenMessages system appears to be intended for use with a persistent message whose contents are updated; this is how the "bump" toggle is useful, for instance. Put another way, rather than building a new ScreenMessage object with new content and style each time you need a new message, one would re-use a single ScreenMessage object for each purpose. For example, the KSP code uses a single persistent ScreenMessage per antenna for all transmission updates with each antenna. Good to know about the HTML tags; I might have to make use of that.
  12. toadicus
    VOID has been updated to 0.9.15! Many thanks to diomedea for helping me to chase down a bug. CHANGELOG: v.0.9.15 [2013-12-02] * BUGFIX: VOID GUI skin preference will now play nicely with MechJeb. * BUGFIX: Saves to disk will now only take place when things actually need saving.
  13. toadicus
    Ah, the disconnect here is that you were testing on a clean VOID install and I wasn't; I actually broke the "load default" state when there is no config file to pull from. So! Here's a new DLL that fixes my brainfart.
  14. toadicus
    Hmm, let's try again. I'm guessing I copypasted the wrong file. This one's a debug build, so it will make more noise on the screen and in the log. If you get any sort of failure state, please upload another log. Thanks!
  15. toadicus
    OK, try this one. I've changed a few things about the way the skin choice is saved and loaded that should hopefully help. Thanks for helping to debug!
  16. toadicus
    So, does removing the config.XML fix it permanently, or does it fail again after the next timeyou reload the game? From the looks of the log, this is probably to do with a mismatch in the number of skins available; basically, your config had saved an index for a skin that is no longer available. My guess is you have or had a mod that added skins to the list of available skins in the game and caused the issue, perhaps when it was removed or updated. I'll tighten up the logic around saving the GUI skin selection and get back to you this evening.
  17. toadicus
    Wait, that .DLL fixed the skin issue but broke the config window? That doesn't make any sense, I added literally one line of code, nothing to do with the config, and it works fine for me. Can you follow these steps for me? If open, close KSP Open KSP Load up a flight Open the VOID config window If it is broken, close the game forcefully (the window "x", alt+f4) With KSP still closed, copy the KSP output log to pastebin and link it here. In Windows, the log lives in /path/to/KSP_win/KSP_Data/output_log.text, in Linux it's ~/.config/unity3d/Squad/Kerbal Space Program/Player.log. Thanks!
  18. toadicus
    Hmm. I can't duplicate that, so I'm going to suggest that it has to do with an interaction with another mod. First step: can you download this DLL into your GameData/VOID/Plugins folder (replace the old VOID.dll) and tell me if it fixes the problem for you? It assigns the GUI skin per module, instead of just in the core (and also, for some reason, in the HUD).
  19. toadicus
    VOID has been updated to version 0.9.14! This is another set of small changes to improve the usability of the configurable-precision values, and to spread them throughout a few more panes. As a teaser, know that I also have a specification and a scanner written for fully-configurable windows and HUDs. CHANGELOG: v.0.9.14 [2013-11-30] * TWEAK: Added rate limiting to Vessel and Surface & Atmosphere panes. * TWEAK: Values with configurable precision will now manipulate the unit prefix (e.g. Mm vs. km vs. m) instead of just adding a bunch of digits after the decimal. * TWEAK: Precision cycling is now toggled by clicking anywhere on the label or value of configurable values. Configurable values are now denoted by an "â±". * TWEAK: Precision cycling now limits itself within reasonable bounds. Right-clicking now cycles through precision values in reverse. * BUGFIX: Will no longer sometimes cause exceptions before the scene is fully loaded. * BUGFIX: Improved failsafes around VesselSimulator calls.
  20. toadicus
    That's something I've been chasing down; it's to do with a disconnect arising between KSP's idea of staging and VesselSimulator's, I think. My internal version at least fails a bit more gracefully, but I'm still working on it. ...Maybe? I'm not sure that's something Unity makes simple. I'll look in to it; if I can, I will (though in the next version that will be less necessary). In the editor, the VOID icon should move with the main setting panel; that is, if you move the main VOID window, the icon will move as well. Are you unable to drag the panel around?
  21. toadicus
    Stay tuned. I don't have an ETA yet, but something like that is definitely in the cards.
  22. toadicus
    diomedia, Tristavius, based on your feedback it sounds like the "absolute" option is out. Thanks! To clarify a bit: the change in mechanic in the "relative" option doesn't materially change the way VOID currently displays and configures precision. It just moves the decimal point around and changes the units, instead of adding a bunch of extra figures after the decimal point. I'll get a screenshot up soon. EDIT: Like'a so. Take a look at the Apoapsis line after two successive clicks. Also, the magnitude adjustment is relative to the actual magnitude, so as numbers get smaller, they'll automatically "unit down". So, if I had a "one click" adjustment on periapsis and then lowered it, at 1Mm it'd automatically switch from 1000.00km to 999999.99m.
  23. toadicus
    Glad it's working out! I had considered the same thing, and have a couple options for it. I just need to test them. Alright, this is working internally. I've got two options for how to present this. The first controls the magnitude relatively, i.e. "always show this value at 3n orders of magnitude less than the actual value". So if the value would be shown in kilometers, the first step more precise would show it in meters. If the value would be shown in gigameters, the same setting would show it in megameters. This gives continuity of presentation in that you value will always be about the same length. The second controls the magnitude absolutely, i.e. "always show this value in megameters". This gives continuity in the units presented: no matter where you go or what you do, that value will be shown in megameters (unless you change it). I don't like this option, because it requires users to reconfigure values as situations change: on your trip out to the Mun, your altitude is relevant in megameters. When you're orbiting, it's relevant in kilometers. When you're landing, it's relevant in meters. When you change ships to your Eeloo probe, it's relevant in gigameters. What do you think?
  24. toadicus
    Glad it's working out! I had considered the same thing, and have a couple options for it. I just need to test them. I've considered that as well, but it strains the limits of my Unity-Fu. In some quick research just now I've found a possible answer... I'll take a swipe at it and see if it sticks. If not, we'll probably stick with buttons for now.
  25. toadicus
    Oops. VOID has been updated to version 0.9.13! This update fixes that omission.
×
×
  • Create New...