BruceKnowles

Are you running 32bit linux. If not how do you get full 64 bit services and memory addressing when you only link the 32 bit dlls from KSP_Data? - - - Updated - - - That is exactly what I am thinking... the last source code update was mid December which agrees with the release of your 0.90 patch, yet only two days later you update a patch to enable transfers between Kerbals. Yesterday you release 1.1.1 but no changes recorded where you have updated AssemblyInfo.cs. This makes it impossible to verify which version you are running at any given instant and also to confirm that the version in use when a diagnostic error is returned from an end user.

Hi, I quite agree with your sentiment and intentions, especially since CITUtil.dll is used by a number of your products. All I have done is detail my experience and the solution that worked for me. While we are talking.... please check in your sources into GITHub, neither this product nor CIT_KERT sources agree with your releases. For those people building their mods for linux etc... this is a bit of a problem. Thanks in advance.

HI, I have had the same problem but managed to resolve this issue. The fault (for unknown reasons) is that the ActiveStruts.dll is dependant on a support dll CIT_Util.dll. For some reason if this support dll is not located in the same directory as ActiveStruts.dll then it fails to load. Placing the matching versions of both dlls in the same directory resolved the issue for me. Try this out for yourself and see if this works for you. P.S. I now realise that an unintentional ambiguity exists. The fault does not lie in the fact that a dependancy exists, but rather that the load routines would fail except under the condition where the CITUtil.dll file co-existed in the same directory.

Hi MeCripp, The installation path is indeed correct as you will note if you look back at original extracts from the log file. For the record though, (in case it may be of value) my ASET tree contains the sub-directories ALCOR_IVA_patch, ALCOR_LanderCapsule, ASET_Props, ExtCamRadialVert, PRC.

Hi, Source download for version 7.2 does not include the source for reconstruction of the included RoverPilot.dll. Please point me in the right direction Thanks in advance.

OS is way too far down the food chain for this type of issue to be the culprit. There is no way it will know to ask for these files by name... It has to be much earlier in the request chain than that. For the record though I am running Win 7 Ultimate 64 bit. Anyway leave this until next year... go enjoy the party

Hi MeCripp, I don't know how to answer your assertion that you do not see the error in your logs other than I can only discuss what I see in mine. I do find a reference inside the MU file to these assets. Could this be the source of the request?

Oh yes, I have been looking for a set of vanilla EVA suits for a project I am doing the initial workups on... I would be most grateful for a copy. Thanks in advance

Hi are you sure about this file name? I have a file named CelestialBodies.cfg in directory GameData/PlanetShine/Config which comes as part of the default installation. I have had a look at the code and after a lot of squeezing the fault location I narrowed it down to this call in Config.LoadSettings(); [COLOR=#4EC9B0][FONT=Consolas]CelestialBody[/FONT][/COLOR][FONT=Consolas] body [/FONT][FONT=Consolas]= [/FONT][COLOR=#4EC9B0][FONT=Consolas]FlightGlobals[/FONT][/COLOR][FONT=Consolas].[/FONT][FONT=Consolas]Bodies[/FONT][FONT=Consolas].[/FONT][FONT=Consolas]Find(n [/FONT][FONT=Consolas]=>[/FONT][FONT=Consolas] n[/FONT][FONT=Consolas].[/FONT][FONT=Consolas]name [/FONT][FONT=Consolas]==[/FONT][FONT=Consolas] bodySettings[/FONT][FONT=Consolas].[/FONT][FONT=Consolas]GetValue([/FONT][COLOR=#D69D85][FONT=Consolas]"name"[/FONT][/COLOR])); This was my conclusion for the Start() routine in Config.cs: [COLOR=#569CD6][FONT=Consolas]public [/FONT][/COLOR][COLOR=#569CD6][FONT=Consolas]void[/FONT][/COLOR][FONT=Consolas] Start() { [/FONT] [COLOR=#569cd6]if[/COLOR] (Instance != [COLOR=#569cd6]null[/COLOR]) { Destroy(Instance.gameObject); } Instance = [COLOR=#569cd6]this[/COLOR]; LoadSettings(); [COLOR=#57a64a]// I think this needs to be delayed until we are sure some solar system info is loaded [/COLOR] [COLOR=#DCDCDC][FONT=Consolas]}[/FONT][/COLOR] This remark is a result of my determination that FlightGlobals.Bodies was a null pointer at the instant the routine was called. The release implementation has the ConfigManager started 'EveryScene' which includes the startup/load phase. Since it is possible to insert an entirely new Planetary system in place of the default one, it made sense to me that the variable would indeed not be initialised until the very last moment, which would allow third party plugins to populate this part of the data structure suite by some means. Given also that we cannot predict with absolute certainty the order of loading modules other than by arranging the order of directories in the GameData sub tree structure by external means, I think it necessary that a different checkpoint is used to trigger the initialisation cycle. Examples of an external means are the names of the Toolbar and USITools directories which attempt (but not guarantee) that they are loaded as early in the load cycle as possible. I have thus altered my version of the code as follows: Old [KSPAddon(KSPAddon.Startup.EveryScene, false)] public class ConfigManager : MonoBehaviour { New [KSPAddon(KSPAddon.Startup.MainMenu, false)] public class ConfigManager : MonoBehaviour { This change has resolved the immediate problem, however, due to my lack of experience both with C# and this game, I am not yet convinced that this is a complete solution. For the moment though, all does appear satisfactory.

I have not done that much bar install the product as required. This is an extract from my current KSP.log file: [LOG 16:52:11.693] Load(Model): ASET/ASET_Props/Instruments/GPWS/model[ERR 16:52:11.715] Texture 'ASET/ASET_Props/Instruments/GPWS/model000' not found! [ERR 16:52:11.716] Texture 'ASET/ASET_Props/Instruments/GPWS/model001' not found! [LOG 16:52:11.727] Load(Model): ASET/ASET_Props/Instruments/IndicatoCircular/IndicatorCircular This is an image from the current zip file which clearly demonstrates that the items are indeed absent.

It has been some months now since this topic was raised... sadly without any acknowledgement by the developer let alone any ideas from the community. It is now the last day of 2014, what are the odds of a resolution to this problem occurring this year? I know that I still see this error, there must be many others who use this product with this event in their logs. If not, please be kind enough to indicate how you resolved this 'undocumented feature'.

Hi Nereid, An Exception is being thrown when starting up KSP by the FinalFronter DLL version 0.5.16-317. The stack trace indicated an ambiguity error within FARAdapter.plugin() when using the GetMethod() call. On investigation this was narrowed down to the statement: methodGetMachNumber = type.GetMethod("GetMachNumber", BindingFlags.Public | BindingFlags.Static); On investigation it turns out that there are indeed two methods named GetMachNumber which satisfy the BindingFlags specification whose signature differ only in the third parameter. A quick and dirty fix, but probably not an efficient solution is: [COLOR=#569cd6]if[/COLOR] (type [COLOR=#b4b4b4]!=[/COLOR] [COLOR=#569cd6]null[/COLOR]) { [COLOR=#4ec9b0]Type[/COLOR][] _params [COLOR=#b4b4b4]=[/COLOR] [COLOR=#569cd6]new[/COLOR] [COLOR=#4ec9b0]Type[/COLOR][[COLOR=#b5cea8]3[/COLOR]]; _params[[COLOR=#b5cea8]0[/COLOR]] [COLOR=#b4b4b4]=[/COLOR] [COLOR=#569cd6]typeof[/COLOR]([COLOR=#4ec9b0]CelestialBody[/COLOR]); _params[[COLOR=#b5cea8]1[/COLOR]] [COLOR=#b4b4b4]=[/COLOR] [COLOR=#569cd6]typeof[/COLOR]([COLOR=#569cd6]double[/COLOR]); _params[[COLOR=#b5cea8]2[/COLOR]] [COLOR=#b4b4b4]=[/COLOR] [COLOR=#569cd6]typeof[/COLOR]([COLOR=#4ec9b0]Vector3[/COLOR]); [COLOR=#57a64a]// methodGetMachNumber = type.GetMethod("GetMachNumber", BindingFlags.Public | BindingFlags.Static);[/COLOR] methodGetMachNumber [COLOR=#b4b4b4]=[/COLOR] type[COLOR=#b4b4b4].[/COLOR]GetMethod([COLOR=#d69d85]"GetMachNumber"[/COLOR], _params); [COLOR=#569cd6]if[/COLOR] (methodGetMachNumber [COLOR=#b4b4b4]!=[/COLOR] [COLOR=#569cd6]null[/COLOR]) { SetInstalled([COLOR=#569cd6]true[/COLOR]); } } Good luck! P.S. This is for a version 0.90 implementation.

Hi, Firstly, compliments of the season to all readers. Secondly, I need some pointers on how to go about determining the cause and then hopefully the means to resolve this error message detailed below: [EXC 16:00:20.477] NullReferenceException: Object reference not set to an instance of an object FlightGlobals.get_Bodies () PlanetShine.ConfigManager.LoadSettings () PlanetShine.ConfigManager.Start () Thanks in advance. P.S. Running KSP 0.90.

Thank you indeed...

er wot! Please translate...

Seeking Source for 1.3.5! Last version checked in Github is 1.3.1. Has the repository been moved? I would like to build a 64bit version for myself. Thanks in advance

Hi, Actually this is not a difficult process to follow once it is explained (I have never used Blender, so I thought I would take a look at the software today .. My installation path is: "E:\Multimedia Applications\Blender3D", yours will be similar. Currently I have version 2.72b installed. All that is required is to open up the zip file with your favourite utility and then drag the directory named io_object_mu-master from the zip file directly into the path "E:\Multimedia Applications\Blender3D\2.72\scripts\addons". After that start Blender; bring up the Addon tab in the User Preferences pane, scroll down till you see the text "Import-Export: Mu model format (KSP)" click the check box on the extreme right, save your settings and the job is done. The next time you choose to use the file import/export options you will now see a new choice for importing KSP .mu files.

Yup, I am in the process of rebuilding my module/plugins to full 64 bit and also to generate full release versions instead of the default debug versions that are generally released. For that I need the code. As I progress through each product I take the time out to read the code and get an idea of what is happening... sort of... This is also a crash course for me in .NET based programming. Its one hell of a learning curve I can tell you... but it sure is a lot of fun...

Hello XanderTek, I am uncertain how you have managed to build a 0.90 compliant release. Based upon the source contained in the zip file linked in the posting above (http://forum.kerbalspaceprogram.com/threads/61294-0-25-XT-Landertron-Smart-Retrorockets-for-Landers-and-Spaceplanes-v0-08-Oct-10?p=1617698&viewfull=1#post1617698) it is clear that something is wrong. In particular, two code locations are in error as they are using enum values that are no longer defined: Landertron.cs line 092 if (HighLogic.LoadedScene == GameScenes.SPH && mode == 0) Landertron.cs line 352 Vector3 fwd = HighLogic.LoadedScene == GameScenes.EDITOR ? Vector3d.up : (HighLogic.LoadedScene == GameScenes.SPH ? Vector3d.forward : (Vector3d)engine.part.vessel.GetTransform().up); For reference please refer to this post: http://forum.kerbalspaceprogram.com/threads/103152-What-s-new-in-0-90?p=1603640&viewfull=1#post1603640 Based on the recommendations in this post your code should probably now be: Landertron.cs line 092 if (EditorLogic.fetch.ship.shipFacility == EditorFacility.SPH) Landertron.cs line 352 Vector3 fwd = HighLogic.LoadedScene == GameScenes.EDITOR ? Vector3d.up : (EditorLogic.fetch.ship.shipFacility == EditorFacility.SPH ? Vector3d.forward : (Vector3d)engine.part.vessel.GetTransform().up); I have reason to believe that you may be using out of date versions of Assembly-CSharp.dll and UnityEngine.dll in your build process. Good luck!

Is this mod still alive and well? I see the basic LaunchCountDown mod has been updated for 0.90, but this version has seen no activity since the beginning of November 2013!

Hi codepoet, Just a bit of info for you that I hope will save you a bit of time. With the release of 0.90 some changes in the assembly Assembly-CSharp have predictably occurred. In your case you are affected by the following: 1. In module CLSPart.cs you make use of the call SetHighlight(bool). This method has been refined with the current release. A second Boolean parameter has been added to enable recursion. 2. In module CLSAddon.cs you make use of the static Part field EditorLogic.startPod. This field has been removed. Presumably as part of the addition of the ability to change the root node. This in turn implies that it will be possible to construct 'ships' that contain neither a Pod nor a probe module. I think you may find that a useful alternative is to apply your tests to the field EditorLogic.RootPart instead. Good luck!

Hi, I am not entirely certain if this is the correct location to post this question. It does sort of fit though. I am a new users of KSP. I have just acquired this product via the Steam interface. If I were to download and install either the free or paid version of the Kerbalizer :- 1. Would this add-on work in the Steam version? 2. Would this add-on negatively impact the Steam version in some way? 3. Is there a significant difference to install either of the two versions (in the event that it is indeed safe to do so)? Thanks in advance Bruce Knowles