evilC

Just been thinking about how things might work in an ideal situation... I think in order to get the most from your code, I think what we need is to be able to set some engines as "RCS Only". Any engine that is set to "RCS only" ignores throttle setting and can be used for attitude control no matter what the current throttle setting is. This would also allow us to work around the current lack of gimbal support by placing extra small engines for attitude control, allowing us to mount the main VTOL engines centrally and perpendicular, which would make normal non-VTOL mode work properly (Which was one thing hampering my attempts to land a VTOL craft on Duna).

I had a play with this today but unfortunately it seems fairly useless for a space-faring VTOL. As I mentioned before, without a top-facing control point (Which basically makes it a rocket not a VTOL anyway), you cannot accurately perform de-orbit burns or other maneuvers requiring you to burn retrograde because you cannot see the retrograde indicator and thus cannot "pickle the olive" (keep your -w- indicator inside the retrograde indicator). Also, I tended to encounter quite a lot of "Infeasible State" and "Internal error" issues when trying - in this case the engines cut out completely. For these tests, I used the sample craft but edited the craft file to use rocket versions of the B9 parts. I Hyperedited to Duna and attempted to land from a 60km orbit. The engine cut out seems to happen when your thrust vector is not in line with pro/retrograde - I guess the code is mainly trying to keep you hovering? When you pitch right up I guess it is thinking that thrusting at this angle is not helping keep you up, so it cuts out? It's hard to comment on what is going wrong when I do not really know the rules the system is meant to be obeying.

Hmm, you may well not be doing anything wrong - that bit of code isn't really needed anyway, it just allows you to assign a texture to the resize button. I commented out those two lines and replaced it with resizeContent = new GUIContent("R", "Drag to resize the window."); Does that compile for you?

I have made an important bugfix to the library. At some point (probably after sirkut grabbed it), I broke it such that trying to add or load a part with the partmodule whilst in the Editor would hang KSP. The window is also now passed the whole partmodule instance, so it can access info about the associated craft. I also updated the sample module so that it lists all available resources as a demonstration of the above feature, and puts it in a toggleable scroller, as a demonstration of UI techniques.

Added as an issue. Until then, I suggest you install TAC Fuel balancer. AFAIK with new version you do not need it as a part, so it does not to be on the design you are building.

If I get some time (Which may be a while, I have a backlog of work with EL and OC to do) I may see if I can help you out with the UI. Or it may be worth looking at a library I have been working on - I have everything you need in there to save and load settings between flights on a per-ship and global basis, so whatever settings the window were on get saved to global (So new ships can use last settings) but each ship has it's own settings saved in the savegame.

Great release - I just had a play with your sample craft it is certainly the best handling VTOL mod around I suppose we will have to mount engines at angles until gimabling support is in? A couple of suggestions: The sensitivity sliders need to be the same length (as each other), probably longer, and ideally with a text readout and/or edit box to manually set vars. How about save / load of profiles in the config file? That way, you could configure a setup, name it and then recall it at flight start rather than having to set up each time.

Any chance you could maybe tweak this to work with regular engines - ie for use when designing VTOL planes. With decent VTOL control coming soon, this would be rather handy.

The new mod template I have been working on demonstrates per-ship settings (in a save) - feel free to nick code to enable that feature Also, this seems to partly duplicate another project, but I am not sure if that one has been abandoned or not. If it is still going, you could probably learn from this guy - he really sounds like he knows his stuff (Well the maths side at least).

This thread seems scarily dead. Please tell me it ain't so.

Loving the new pad Sky!

Either edit a part to be full of the resource you require (even the launch pad), or use HyperEdit to fill up an empty one.

Lots more updates, I think it may be approaching usability. Added a no-brainer set of instructions on getting up and going: https://github.com/evilC/TacLib/blob/master/Readme.txt

Never mind, issue #2 solved. New feature added: You can now limit the window to only be resizable in one direction.

Starting to get somewhere with this. New version up, "Show on Startup" option added, context menu toggle added to part to show/hide window. Taranis - do you know how to solve issue #2?

I am pretty sure the latest version is in the OP, not buried mid-thread.

No to partial fills in that version, however you could use custom fuel tanks to launch with a partial fill - the build should be less expensive then.

Hmm, as a first step I was just looking to package what KSP offers into a more manageable starting point for newcomers. I agree the UI is a bit quirky, but given a simple example, it should be easy enough to pick up. Personally, something like a proper framework is way beyond me.

I have currently ceased all development on EL itself - I am working on a new framework for mods. Once this is at a decent stage, I will merge EL and OC into that. Interfect has recently expressed a desire to merge OC into EL, so either I will merge into skykooler's branch or create my own.

Absolutely delighted to have Taranis on board, he dropped into IRC a while ago and gave me a few pointers, so I have modified the code to remove reliance on PluginConfiguration nodes (ie config.xml in Resources) and instead use ConfigNodes (eg a .cfg file in the plugin folder). This seemed to be the consensus as "the smart way" in #kspmodders, and an excellent example of why I feel this project holds value. The latest version also supports a "global" setting in the .cfg file, which can be overridden by a "per-ship" setting saved in the persistence file.

Personally, am not hugely concerned about the glory, I just think it's worth trying to do. Besides, if for example we use Taranis' code and host on GitHub, the relevant people get credit that way. Finally, I would imagine comments could get put in the source to credit contributors. What do you mean by "file saving"? Does it need to be files or could it not just be a node in the XML or something? Whatever, I think you have a valid idea: flesh out storage options available to modders from within the code. I also thought that a premade block for all the events with comments and when they fire would be nice, or at least a list of the main ones. Check out my fork for the beginnings of a usable template. Window position now saved on a global basis.

So I have been tinkering with KSP coding for a while now, contributing where I can, but as a newcomer to unity and c# in general, I am finding that UI coding is fraught with some annoying pitfalls. Simply having a window that behaves as one expects (Remember position, close when ship change etc) and with the niceties that a windows generation has grown accustom to is not trivial. I have a lot of these sorted in my mod, but to be honest the code probably isn't that great, and only supports per-mod not per-ship settings etc. Taranis (Tac) was kind enough to release a window manager library that hopefully will be the first step to a decent solution. Unfortunately, he did not include a fully working sample, so I am currently wrestling with that. Rather than just integrate his code into my mod though, I thought it would be nice to feed something back and try to create a nice framework with a sample "Hello World" implementation to allow budding modders to dive right in with a fully working UI they just have to modify to suit their needs. So, any opinions on the best way to implement such an idea? At a minimum, I think the framework should provide the following functionality: Remember window position As you [] through ships, the window shows and hides as appropriate A basic example UI logic and storing of state variables An open/close option in the part's context menu with code to toggle label I would also like to see: Two levels of persistent data storage: global and per-ship A "Show on Start" option To that end, I would encourage anyone to fork either Tac's original library or my fork and add or suggest any improvements or fixes they deem suitable. One question that crossed my mind also was how this would apply to part-less mods. Could one example be made that would work in both situations, or would it require two?

My fix to the lag should be included with the latest version. If it has more UI than a build button, it should include my lag fix.

Yeah, I know you can control a vertical pod, but then that kind of ruins the experience - you are using rocket style controls not plane style

@ Patupi Yeah, I have been pondering something like this, one idea I had was to base the cost of building a part on it's category / attributes. So we should be able to detect if something is an engine, a structural part, a fuel tank, a bit of electronics (control category), a wing etc. Then apply different resource costs to these things. So as you say, an engine needs lots of titanium (Or maybe steel if it is a low power engine), structural is steel, fuel tanks steel and plastics, wings are plastic and a little steel, etc etc.