Crzyrndm

I might be missing something here, but is there something specific you're asking about? It's somewhat difficult to advise with no topic/examples . I somewhat understand this is about UI, but after that... A few questions also. I assume you want to make UI elements with the new Unity UI (create in the editor and just link up in code)? Do you have an example window you want to recreate (something relatively simple with just text, buttons, etc) we can start with?

This^^. If I could modify a stock part I'd be making a whole lot more noise about it . The B9 editor UI is an integral part of this plugin, it's just being rebuilt using the new Unity UI system which should end up making it easier to modify and extend Possible? No, it's going to happen . That, save upgrading, and a few other things (*cough* procedural panels *cough*) will be immediate public v2 priorities methinks

The project continues. Almost to the point where I can focus on bug fixing for a release. Have been making some investigations into how the upgrade scripts work to support current vehicles but it is likely the first public versions will require building craft from scratch. The shift from the original plugins to the merged version will not happen perfectly smoothly. There is very little remaining of the original plugins so there will be a slew of new bugs to start with. I have yet to work out how the UI will support unlmited sizes, suggestions are welcomed on this topic. The cursor drag based modification is so far unlimited so it is not a barrier on implementing original functionality. I also have plans for how I will add a text input box for sliders, but again its not a core feature so it remains in the planning stages I haven't used @01010101lzy's fork yet (but I plan to) to see how the extra options he added work. Which features of that fork were most useful?

Remove the '@' in "@MODULE". You're not editing an existing module, you're adding a brand new one so you dont want to use any modifiers ":AFTER" what? After has a parameter if you need to use it. If this mod doesn't depend on any other mod, you would use FOR[<myModFolderName>] as well (before/after are for compatibility, FOR is to add it to your mods pass. PS dont combine FOR and BEFORE/AFTER in the same definition as that would put it in two different passes at once...)

part.Modules.GetModule<ModuleDockingPort>(); // each part module has a reference to the part it is attached to. from the part we can look for modules of other types

Or rather once that's functional it will be the new thread

Might want to try a non-const value (readonly). Const is normally used to imply that it wont change ever => compiler can do special things with it, which could be having an impact (or compare against _version which appears to be working as expected)

Something completely new this time

First flight achieved , some pictures to commemorate the event (probably not all that exciting for anyone other than me >.>) First Flight: (still need to fix the stock lift position being in the wrong place...) WIP Editor UI (before you ask about how much is missing, the UI is procedurally generated from 4 template objects so I can very quickly add more editable properties now that the basics are working) Next on the list, making it work for the other three wing types (original models and control surface variants x2)

Start/Update/FixedUpdate/OnDestroy are all safe, it's just Awake that you need to steer clear of AFAIK. It's also worth bearing in mind that The On<*>Update methods are only called when a part is activated (staged in most cases) while Update/FixedUpdate are always functional

Stable PWings downloads are available here So the story goes, here I am maintaining two different Procedural Wing mods and porting features in both directions. The level of duplicated effort was getting annoyingly high so I started a new plugin with a common core. Then life happened and something like 4-5 months later (now) I realise I still haven't finished even a prototype. Long story short, I'm getting reasonably close to having a working implementation that can be used by someone other than me. Initial Feature List All existing functionality from my fork of B9PW, and the fork of the original including Support for existing parts Editing via mouse movement (orginal editing method) Editing via GUI (B9 editing method) Fuel switching B9PW will retain all colour/material editing capabilities A new editing GUI (that will look very similar to the B9PW one) built on Unity 4.6 UI that works with any procedural wing model (obviously somewhat stripped down when the appearance cant be modified...) The new UI in particular presents a few opportunities for some new features, so don't expect the list to stay that uninspiring >.> (only once that's all ticked off though) Source on Github like always DO NOT USE WITH EITHER EXISTING PLUGIN INSTALLED

It works (or atleast, the one from my signature does, can't remember if the OP linked one does), therefore logs plz...

nada, it was a caching issue which sarbian has provided a permanent fix for (and a note on an upgrade that should be used following 1.2)

That is way too obvious... (and the todo is even better...)

Version increment worked (), caching.clearcache doesn't. As for the method, it was originally copied from the IR github when I had issues with the KSP asset loader. I couldn't get the Unity Assetloader example to work and that one did, so I never really stopped to think about it at the time

or it's just not allowing more than 1 object to load from each AssetBundle. Do I really have to put each prefab in a seperate bundle...

1/3)It has no issues finding the shader in that bundle using this version so file location is not an issue. It's only the prefabs (things of type GameObject) that it wont load 2) www.error is null Whats really irritating is that I have the exact same piece of code (with a different address) working for a single prefab in different mod I'm thinking it has to be something about using multiple objects/types in a bundle or I've got a setting wrong while building the bundle...

Trying to create a U4.6 UI for B9PW, I can't get the prefabs out of the asset bundle I'm loading. The bundle loader is here, the bundle xml is here. Everything has definitely been copied into the ksp testing directory Relevant log entries on hitting the main menu do not log any objects [LOG 07:46:33.316] [B9PW] Aquiring bundle data [LOG 07:46:33.379] [UIApp] Adding MessageSystem to Application Launcher [LOG 07:46:33.382] [ApplicationLauncher] SetHidden: [LOG 07:46:33.384] [B9PW] unloading bundle I can't for the life of me work out what I'm not doing

Probably because its all on the wiki currently

So I just had the bright idea of actually checking the logs to see which opengl version was being used, and it does appear this is the cause (From the original logs: SM: 40 (OpenGL 3.3 (Core Profile) Mesa 11.2.2), also: Args: KSP.x86_64 -force-glcore33 ). The shiny black with proper tip sections is also exactly what I was seeing I'm guessing either the reason the forced version switches dont help is that either hardware or drivers dont currently support anything higher than 3.3

I haven't been able to replicate the shader compiling issue, but I can make thing wings black by running with an older version of opengl (launch options: -popupwindow -force-glcore32). Possibly related?

Dedicated fuel tanks section => resources tab? If you can identify which parts aren't visible where they should be, I can also fix that. I not seeing any particular reason they wont show in the generic categories though (cant test right now)

One step forward, one step back... (it found the bundle, but the bundle wont load...). Next possible fix committed @Van Disaster I wouldnt have changed any settings, so w/e the defaults are. Should I be setting something else in the package?

Well atleast it didnt fail silently that time. Based on the log this might work (and has extra logging incase it doesn't)

That log is proving to be about as useful as you suspected it would be (ie. not very -.-). Can you try with the GameData folder from here.