Gaalidas

Well, as far as loading the settings and accessing them, I can revert my changes pretty easily and get it working. As far as modification goes, as long as we make sure that the other modules are updating their local instances of that variable from the config manager, then everything will stay in sync. The variables in the config manager were never meant to be updated from the outside modules. if we needed to update a global variable from another module, I'd likely have the config manager periodically check for changes in a separate variable in the module we needed to update from and simply set the value to be equal to that. In this way, the variables being loaded for global access are only being set from within the class that they are managed from. However, I don't see any situations where an outside module would ever need to change the value of one of these global variables we've set up. The modules should be using local variables which are set from the global variables first. We don't need to persist data from the flight scene backwards into the editors, so it's pretty easy to keep track of what is setting what value and keep collisions from happening between saved data. I'm starting to feel like I'm typing in circles and making little sense... but it makes sense in my head. I do remember data binding from my ASP.NET class last quarter. It actually isn't all that complicated, but in ASP you have prefabricated methods for handling all of that, and prefabricated controls for the web-GUI which are already configured to receive the data. You also have access to the database structure from the beginning so you can predict how the code will interact with it. In KSP, we know there's a database of stuff in there somewhere, and we have methods to access it, but we really don't know exactly what it looks like or how it's structured until we start asking for information and it starts telling us to "stuff it where the sun don't shine."

If you set up mechjeb with the ascent profile you want and all that but leave activation until later, you could likely activate the autopilot once you've separated the rocket from from rest of the craft and be good to go from there.

Someone needs to build a mod that will allow you to define certain marked parts to use a simpler aero calculation to allow for the creation of sci-fi nonsense while still enabling other parts and crafts to behave realistically. That could be a real pain to code. - - - Updated - - - It'll all work, except for the TweakScale stuff... which won't work very well until everything gets updated for this mod. Complain to the TweakScale devs for not keeping legacy support for the old scaletype configs. The new scaletype configs I made are tweaked for the new code we've been working on for the parts and simply won't work right with the old parts. EDIT: I just looked at my last log from my last failed attempt on the GUI, and for some reason it thinks I'm trying to call a GUI element from outside of the OnGUI method, which means it's not even loading the settings from the config file now, so that's broken too now.

Alright, I'll put it up. On the plus side, the config loader works even in the different way I've done it, and might be capable of saving the information back without issue if we could ever get it to toggle in-game. The GUI stuff is kinda messy right now since I've been commenting out broken stuff and adding in new stuff that I've seen working in other mods. If this doesn't pan out, then we'll have to comment out anything having to do with the GUI before moving on, since it spams NullRefs constantly right now. To test, you'll need the two icons I made which I'm gonna put into the Assets folder in the non-source repo as well.

Alright, I've reached the end of my sanity with this GUI stuff. I have everything configured identical to another mod that I know works without any issues, but when used in the exact same way here I am presented with null exceptions spammed to the log. There's absolutely no difference in how I'm calling anything, but the result is completely different. We're just going to have to live with no in-game configuration for the time being. Lots of mods have global toggles that are only modifiable in their configs, so it shouldn't be a real problem overall. I've simply had enough of this complete bovine excrement of a GUI system where 15 mods can define the controls, the style, and the way of activating it in completely different ways that all work perfectly fine in their mod, and have no trouble using an "OnGUI()" method to tie them all together but, when I try to use it, failure ensues. Heck, there's no error being produced from the part of the code which is supposed to even add the stupid button to the launcher, and still I get no icon in the launcher even! I've even tried copying over a complete GUI system from another mod (disabling the incompatible variables and such of course, since KF won't have them) and it still fails. I simply cannot waste my time with something that I am doomed to fail at over and over!

Holy wall of expletives! I've been trying to recompile this for myself for a long time with no success. I look forward to having this available again.

Well, I finally just did a huge copy/paste of what BDArmory uses, which I know works. The only thing I'm choking on now is how to save the settings. BD uses a config file without a parent node. It simply just lists the variables and their values in order. I'm using a parent config node and putting the values inside that, so saving the values from the GUI isn't going to be as straight forward as his mod has. Going to dig around in the DustFX stuff and see if the default file generator will be of any use to me. I haven't tried compiling again yet, but it looks almost identical to the other mod I'm using as a template and that mod did compile a few minutes ago when I tried. His mod doesn't do anything with OnDestroy, or anything that references something being destroyed, nor does it use an "Awake" state or anything, and from my experience there's never been any problem with it sticking around after scene changes, or duplicating itself for any reason, so I'm calling it good for the time being. UPDATE: So, it looks like the current way I load the config is not going to be compatible with the way I want to save the settings, after a user changes them in the GUI, in order to allow the settings to persist between KSP launches. Once that's handled, I'll do a little testing to make sure the settings are loaded and saves from the GUI. This conversion of load and save methods will also make it easier to set up default values and have it create a new file if the old one is deleted. I made a copy of KSP this morning with nearly-zero parts in it and Holy Jebediah did that baby load up fast. Time to do some heavy culling of my main install to hopefully regain some of that speed when I return to my mod-laden game.

Might have to do that because, while I've used overrides successfully before, apparently there isn't a method available, which can be overridden, with a name of "OnDestroy" or "Awake." That still doesn't explain why I can't draw a GUI. Also, I've never heard of this KSPPluginFramework... I'm very close to jsut doing a complete copy/paste from BDArmory and then customizing it for my needs from there. I'd rather be able to build it specifically with KF in mind, but if it's going to be that complicated, then copy/paste will have to do. EDIT: I haven't actually looked at your latest post with examples, which I'm going to do now. I was in Costco with my mother when I responded to that message.

We're trying to avoid external dependencies like KSPAPIExtensions. Anyway, I removed the override part and still had issues with it not being able to find the GUI methods, or rather unable to do what I witnessed in BDArmory exactly where he called up a custom method from the call for a new GUI window. Very irritating. Whatever you do, don't claim that it can't get worse, cause it probably will now that you've said it.

If you manage adjustable width, you might as well also make adjustable scale and we can just scrap TweakScale for an in-house implementation. Besides, I'm unsure how we would make adjustable stuff play friendly with the other mod. I'm so going to start using "omnishambles" in my daily life now. That's awesome. EDIT: The stuff Aqua posted isn't going to work quite right. The compiler can't find the methods to override for several of the methods that were tagged as overrides (the Awake and OnDestroy methods) and the GUI calls for spawning the GUI aren't accepting my methods that have the GUI builders in them because it's looking for something called a "method group" instead. So, we're back to the drawing board... again!

I must add that I too find these babies to be quite beautiful. I wouldn't mind having some of these for my own uses.

No no no, what Aqua posted was easy, it's the actual GUI that's screwing with me. However, I'm making progress again. I discovered the perfect example in BahamutoD's BDArmory mod. It's turning out to be an amazing resource for stock toolbar goodness. One thing I've discovered which is kinda screwy is that it looks like every time you want to show a GUI in KSP you practically need to rebuild it from scratch in the code. I was looking at it in the way you display forms in Windows based UI forms, where you create the form first, then call it up from the code. The form stays as it is like a template for what the code works with. In KSP, when you display your GUI the code is the actual code that builds it. You're not just telling KSP to make your GUI visible, you're telling KSP to rebuild it on-demand every single time you need it. This makes it difficult for me to wrap my head around, but I'm slowing making my way there. Later today I'm going to create my dev install of KSP stripped of all the parts and other useless assets so I can test the GUI layer and start making this thing work.

No, that won't be necessary. I'm making slow progress. I don't have time to devote whole days to the project, but it's coming along. I'm just trying to figure out what parts of the AffinityUI package I'll need so I don't end up importing the entire library into KF. It's going to make constructing the GUI a lot easier though. I'm going to try and strip down my install of KSP for an extremely lightweight testing platform and work on that over the next few days. I figure if I back up nearly everything related to "parts" and force KSP to load without them, then it will simply be a matter of loading the bundled assets and spitting me out to the main menu. I can start a new save for the sole purpose of testing the GUI and simply get it to output any changes done to the config state to a log to make sure it's working properly. We can worry about testing if it actually works on the parts or not after I get it looking presentable. My trouble with doing stuff like this is that my brain doesn't make all the connections as to how things are supposed to go together in the code until I'm able to see a working example or the code and the output. this is why I've often wished for a KSP console-only mode for loading configs and testing interactivity with those configs without the rest of the game getting in the way. Along those lines, an ability to load KSP into a GUI-testing mode where it would load everything it needs to display a dummy scene with the app launcher and any settings screens that KSP comes with, along with a fully functional config database. This way I could even test GUI additions without having to manually purge my gamedata folder of parts to test this stuff. Fortunately, though many other GUI-using mod authors would disagree about it, when KSP goes to Unity 5, we'll have access to a GUI designer in Unity (I've read this anyway, not confirmed) which will ease the issues with designing and coding interactions and visuals for a GUI addition. On the down side, it will also screw over any form of GUI mods currently use because it will require the use of the Unity 5 GUI rendering system. I for one am looking forward to it though. EDIT: Never mind that progress report above... I'm back to the drawing board. AffinityUI is a lot easier to create a GUI with, but the examples it provides don't include how I'm suppose to call it from the stock toolbar or anything. Even the example plugin, which supposedly will load into KSP and let you bring up an example of what can be done, doesn't even contain any code to actually put the GUI button on the app launcher! How am I expected to view the example if all it does it create the GUI and doesn't actually have a way of displaying it? This is getting really stupid! I just need some working example code to learn from and I'm good to go, but everything I look at either only has parts of what I need, or claims to have what I need and then doesn't deliver in the end!

Hmm... which parts exactly are having trouble? (no, wait... I think I know what's going on...) Last I checked, using the latest release of TweakScale, all the wheels, tracks, and repulsors were functioning with TweakScale. i would first check that you're using the latest release of TweakScale, however... Now that I think about it, we haven't released any updates for this mod yet and if you're using that latest release, none of the old configs will work anymore. Once we release an update, that shouldn't be an issue for anyone. As it is, I may have to go grab the latest release we made and hack together a new config for the scaling. Unfortunately the people maintaining TweakScale didn't have the good sense to code their new stuff in such a way that legacy configs could still function. How annoying indeed. - - - Updated - - - Just a few simple toggles my arse! This GUI stuff is anything but simple.

That and it's likely that having the heat being released from that nozzle pointed away from the rest of the hull would be beneficial to keeping things cool.

Funky. That's all I've got I'm afraid. If it was equipped with a JSI transparent pod setup, with a fully functional cockpit and all, well... that would be another story altogether. Not bad as it is though.

That's some sweet looking stuff there lo-fi. Was that over water or something? It you had some sort of light-blueish tone in them. Also, it could have been my imagination, but it looked at the end like there were RCS flares coming from within the repulsor spheres. I agree though, the dust objects need to be toned down a bunch. The parameters for handling all that are rather sensitive at the small scales we're running these parts in. The game was built to handle these types of effects on rockets and such, which tend to be a lot larger at their smallest scale. I am unsure what the smallest values possible are, but I was thinking that what you have there would be for the strongest force, likely reached only when impacting the surface, rather than just repulsing off of it.

Indeed that is helpful. For the GUI itself, I've rediscovered an old download that included an entire library useful for generation and managing GUI elements which I'm using as a base for my own attempts at a GUI. It really simplifies things a lot. Of course, when KSP goes Unity 5, we'll have access to visual GUI designers similar to the form designers in modern programming environments. What would be really awesome would be for someone to make an easily-imported project that did all the hard work of getting something like this set up and provided an easy way for someone to then simply define what the button should do when pressed. Something along the lines of the Blizzy toolbar's set of methods that I see imported into just about every mod that supports the toolbar mod. I may have to export whatever I end up with here for such a purpose. It just seems to me that we shouldn't all be reinventing the wheel every time we make a new button. As for throttle control... I did actually think about that a while back too. It would definitely save on having to hold buttons down while driving. To emulate that, I've often used mechjeb's rover controller to maintain a certain speed, along with subtle stability control. EDIT: Okay, I have this now to work with: [COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]SetupAppButton[/B][/COLOR]() { [COLOR=#0000ff][B]if[/B][/COLOR] ([COLOR=#191970][B]Equals[/B][/COLOR]([I]appButton[/I], [B]null[/B])) { [I]appButton[/I] = [COLOR=#004085]ApplicationLauncher[/COLOR].Instance.[COLOR=#191970][B]AddModApplication[/B][/COLOR]([COLOR=#191970][B]onTrue[/B][/COLOR], [COLOR=#191970][B]onFalse[/B][/COLOR], [COLOR=#191970][B]onHover[/B][/COLOR], [COLOR=#191970][B]onNotHover[/B][/COLOR], [B]null[/B], [B]null[/B], [COLOR=#004085]ApplicationLauncher[/COLOR].[COLOR=#004085][B]AppScenes[/B][/COLOR].[I]ALWAYS[/I], [I]appTextureGrey[/I]); } } And this to modify the texture based on hover status: [COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]onHover[/B][/COLOR]() { [COLOR=#008000]// To-Do: Swap the icon with the colored one.[/COLOR] [I]appButton[/I].[COLOR=#191970][B]SetTexture[/B][/COLOR]([I]appTextureColor[/I]); } [COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]onNotHover[/B][/COLOR]() { [COLOR=#008000]// To-Do: Swap back to the grey version of the icon.[/COLOR] [I]appButton[/I].[COLOR=#191970][B]SetTexture[/B][/COLOR]([I]appTextureGrey[/I]); } The programming environment seems to think everything will function correctly as far as the code itself, so I'm going to call this a success at the moment. Next, i'm going to use elements from AffinityGUI to create a GUI for toggling our global variables. For the icons, I'm using an icon I made for FilterExtensions which is basically just the letters "KF" in the middle of an Icon, but with an enabled state that colors the letters with a golden hue, which I'm using for the onHover state. One thing I noticed was that some mods have been using 40x40 images for the app icon, but the code documentation specifies a 38x38 texture. Does the texture size really matter that much?

Indeed, stock toolbar was my aim. I'm just having problems figuring out how to use it properly since all the examples I've seen are either for a single toggle on button press, or a complicated stock/blizzy combo with GUI that's way more complicated than what we need. It seems every mod I look at which has a GUI decided to support both toolbars and also decided not to name their methods in a way that makes it easy to figure out what is doing what. It's all driving me absolutely nuts.

I wasn't aware it was dual-sided. I thought it was just set on a gimbal so it would always face down. So, I've been looking at GUI options for a few hours now and I'm frustrated. Everyone adds the button to the app-launcher in a completely different way it seems, and if they support Blizzy as well, then it becomes down right impossible to figure out which way is up. why can't it be as simple as "icon=icon_name" and "onToggle=this_action" instead of all these undocumented method arguments that mean absolutely nothing to the ordinary human being!

The dust effects, in their original implementation (aka. "hacked out of CollisionFX by me many months ago") it would work on all objects that scrape over the terrain with an emphasis on wheels. What the implementation in KF is meant to be is an addon not only to the KF-specific wheels, but to all the KF conversions of other wheels. Eventually I could see us being able to easily expand the new module to work with other wheels built on top of the stock module with a set of default values combined with some auto-detected values. When/if that is possible, then the KFDustFX module will work on those wheels without any modification or legacy modules applied. I would like to, before any major release of the KF mod, include a module that would be applicable to any non-KF wheels. Once lo-fi is done messing around with the various stuff having to do with the dust, I'll work on creating a legacy version of the module which makes use of all the new color control stuff, but takes input from the stock module. My goal in the end is to makes the wheel modules able to be put on any other wheel (stock or modded) with a modular approach to any of the special KF features so that, if an end user wanted to, a non-KF wheel could be told to use the KF module to handle its collisions (both for dust and for basic wheel control) and not make use of anything other than the very basic wheel control features of the KF module which would include the ability to then activate the other features, including dust, if they so wished. You'd still have to do a lot of modification to make the wheel fully capable of using the KF modules to the greatest extent, but it could work in a pinch. Already we have configs for the stock wheels (either by copying them into new parts, or a MM patch to modify them in-place) and it's becoming easier and easier to convert new wheels to use the KF modules with every rewrite/refactor of the code. So, in short... yes, there will be a way to add these effects to non-KF wheels eventually but also, eventually, there won't BE any non-KF wheels when KF is installed. By the way, these ideas and plans are all independent of lo-fi's plans and dreams, but I think he would agree with many of my ideas as good long-term goals. Feel free to correct me on anything, oh fearless leader. I simply have this vision of all these things being as modular as possible and easy to apply to any old parts that don't already make use of these advanced features in much the same way that an old engine without the advanced gimbal actions, included in mods like KM_Gimbal.dll, can be converted simply by replacing the gimbal module definition. We're not even close to that yet, but there's light at the end of the tunnel. It's not in the visible spectrum yet, but it is there. Okay, so that was anything but short... - - - Updated - - - I love it. I won't be entering it of course, mainly because I have to be very careful with my memory management which means no air-race assets, and I'm too busy developing while trying to take a summer math class to finally end all my math requirements, FOREVER!!! But I look forward to seeing if anyone else enters. Keep us updated here too. I think you need some of those super-efficient radiators from some of the radiator mods out there. One thing to note of course is that air friction and slope-gravity friction is all you're getting to slow you down so, once you reach a top safe velocity over the water, and are going in a straight line, you can actually cut your throttle way down and save yourself the extra heat generated by the engine. I love the use of the air brakes to help control turning. I remember trying to build an anti-grav speeder back in the day before we had any of the heat and aero stuff to work with, and it was pretty tough. - - - Updated - - - I'd love to see it in the future, even considering I really really hate broken wheels... especially on probe rovers since we don't have anything like a maintenance arm capable of repairing wheels like you can with a kerbal, but I can see it eventually being possible. Especially if the damaged state could include partially-functioning states. I have a few ideas for controlling appearance using a hidden resource that is depleted with every over-rough collision which could contain a texture and/or model swap for certain objects in the part which would simulate the visual damage. Introduce a little random slippage or occasional brake-application to the damaged part (and maybe an occasional failure to respond to steering) at certain ranges of the tracked resource, and you've got a great setup for damage stuff. easy maintenance too, since internally you'd simply be "refueling" the part with the invisible and weightless fuel source and forcing the part to refresh it's state based on that resource. I believe heat-shields (before stock implementation) used a similar system to decide how protected the craft was. However, the modelling/texturing needed to make this happen is quite extensive. - - - Updated - - - Keep the lights implemented though, even if we end up disabling them by default. If the end user can use them, we can provide a way to activate them. Better to have a way of producing that repulsor glow in-house than forcing them to make use of extra light parts on the craft to produce the same effect.

I'll look at GUI stuff later today. I was just thinking there was a less intensive lighting option. I remember planet shine had two modes for lights, and considering pixel lighting has limits per user config of KSP overall, you'd run into that limit pretty quick.

I see you've been hard at work lo-fi from looking at the github updates. Awesome stuff. we better implement some more global toggles for those lights and such, since lighting can definitely create an issue with performance, especially if the user can run shadows (I can't, really bogs me down). I always figured the repulsors would have emissives instead of lights. Also, did you mean to disable the orientation markers by default in the global config? I'd think the default action would be to have them enabled. I'm going to start looking into porting over a basic configuration menu from one of the other mods I use (probably use smokescreen as a template) so we can get these modifiable from the space center scene (I don't want to have to deal with toggling this stuff in-flight just yet, as that adds a new dimension of complexity.)

And I thought my posts could make people's heads hurt. I'm gonna need drugs to get over this one.

When you put it that way, you've basically got a stock wheel like that ruggedized wheel... what's it called? has little to no suspension room, massive tire, only plus side on it is the nice steering range. On another topic entirely, lo-fi... I was reading another forum that had a picture posted which features your last public release of the long track. Someone there was complaining (well, not really, just warning other users) that sudden stops could ruin a craft with only a single set of those tracks on it. My suspicion is that the effect of suddenly stopping and then flipping over when using single sets of tracks will only get worse with the changes made recently, which I experienced first-hand, where an extremely light craft on a pair of medium tracks could over-power the emergency-break and cause the entire craft to do a complete flip end-over-end just by tapping the W key once. I understand what's doing that I believe... it's that part where the heavier the craft, and the less overall support the craft has, the lower the performance of the parts... however, it seems that the parts can become too responsive when the craft is lighter than expected. I'm thinking the calculation that heads up all the other changes to the responsiveness of the part needs a limiter so it doesn't become too-responsive on lighter crafts. - - - Updated - - - When I saw you going down those inclines at an angle and saw how it was basically suspending the same way, but the movement was at the connection to the body, not at the end of the axle... I got really excited. I haven't been that excited since I saw lo-fi's first video. Just needs a KF-style steering overhaul and it would make an awesome addition.