Jump to content

[v0.19] Damned Robotics Version 1.3

DYJ

By DYJ
in KSP1 Mod Releases

 Share

Recommended Posts

astronutkhillips

astronutkhillips

Posted
Posted
Looks like I got beaten to the punch. Did you reach the same conclusion regarding the source of the problem?

Jeepers... that is creepy! The thing has been broken forever and we both fix it with in 20min of each other. Nice job!

Mine is more or less the same fix. It's easy once you spend hours debugging it. LOL.

I also had found a problem with undefined keys that I needed to fix. Maybe because I split out the MJ crap same as you (90% of the code went bye-bye). Did you check the log to see if you are getting any spam about undefined keys?

Link to comment
Share on other sites
Devo

Devo

Posted
Posted
To anyone interested: I have fixed the issue with the plugin.

Essentially the MuMechToggle class, in its onPartAwake() and onPartLoad() methods, calls a method colliderizeChilds(Transform obj). It then calls the method obj.GetComponent<MeshFilter>(), which returns the MeshFilter object if attached, or null if there is not an instance attached. The problem is that a some point (probably in onPartAwake(), where I understand the object may not actually be built when this method is called) the colliderizeChilds(Transform obj) tries to tell Unity to instantiate the 'mesh' variable contained within the attached MeshFilter, but there is no MeshFilter attached at that time (the reference is null). Modifying the code to check if the MeshFilter reference is null first fixes the problem:

In Toggle.cs (http://svn.mumech.com/KSP/trunk/MuMechLib/):


    protected void colliderizeChilds(Transform obj)
    {
        if (obj.name.StartsWith("node_collider") || obj.name.StartsWith("fixed_node_collider") || obj.name.StartsWith("mobile_node_collider"))
        {
            print("Toggle: converting collider " + obj.name);

            if (!obj.GetComponent<MeshFilter>())
            {
                print("Collider has no MeshFilter (yet?): skipping Colliderize");
            }
            else
            {
                Mesh sharedMesh = UnityEngine.Object.Instantiate(obj.GetComponent<MeshFilter>().mesh) as Mesh;
                UnityEngine.Object.Destroy(obj.GetComponent<MeshFilter>());
                UnityEngine.Object.Destroy(obj.GetComponent<MeshRenderer>());
                MeshCollider meshCollider = obj.gameObject.AddComponent<MeshCollider>();
                meshCollider.sharedMesh = sharedMesh;
                meshCollider.convex = true;
                obj.parent = transform;

                if (obj.name.StartsWith("mobile_node_collider"))
                {
                    mobileColliders.Add(obj);
                }
            }
        }
        for (int i = 0; i < obj.childCount; i++)
        {
            colliderizeChilds(obj.GetChild(i));
        }
    }

I recompiled the plugin (note; you only need Toggle.cs, Part.cs, MuUtils.cs and Servo.cs for DamnedRobotics), and tested in KSP 0.20.2.186 (latest Steam build); everything seems to work fine. I will message the author with this fix and ask for permission to distribute a patched plugin.

Very much appreciated!!! Could you test the Servo controls with your fix before releasing also please?

I don't use the mu mech engines much these days, but the servos, my god... I need them depserately! :)

Link to comment
Share on other sites
sirkut

sirkut

Posted
Posted
To anyone interested: I have fixed the issue with the plugin.

Essentially the MuMechToggle class, in its onPartAwake() and onPartLoad() methods, calls a method colliderizeChilds(Transform obj). It then calls the method obj.GetComponent<MeshFilter>(), which returns the MeshFilter object if attached, or null if there is not an instance attached. The problem is that a some point (probably in onPartAwake(), where I understand the object may not actually be built when this method is called) the colliderizeChilds(Transform obj) tries to tell Unity to instantiate the 'mesh' variable contained within the attached MeshFilter, but there is no MeshFilter attached at that time (the reference is null). Modifying the code to check if the MeshFilter reference is null first fixes the problem:

In Toggle.cs (http://svn.mumech.com/KSP/trunk/MuMechLib/):


    protected void colliderizeChilds(Transform obj)
    {
        if (obj.name.StartsWith("node_collider") || obj.name.StartsWith("fixed_node_collider") || obj.name.StartsWith("mobile_node_collider"))
        {
            print("Toggle: converting collider " + obj.name);

            if (!obj.GetComponent<MeshFilter>())
            {
                print("Collider has no MeshFilter (yet?): skipping Colliderize");
            }
            else
            {
                Mesh sharedMesh = UnityEngine.Object.Instantiate(obj.GetComponent<MeshFilter>().mesh) as Mesh;
                UnityEngine.Object.Destroy(obj.GetComponent<MeshFilter>());
                UnityEngine.Object.Destroy(obj.GetComponent<MeshRenderer>());
                MeshCollider meshCollider = obj.gameObject.AddComponent<MeshCollider>();
                meshCollider.sharedMesh = sharedMesh;
                meshCollider.convex = true;
                obj.parent = transform;

                if (obj.name.StartsWith("mobile_node_collider"))
                {
                    mobileColliders.Add(obj);
                }
            }
        }
        for (int i = 0; i < obj.childCount; i++)
        {
            colliderizeChilds(obj.GetChild(i));
        }
    }

I recompiled the plugin (note; you only need Toggle.cs, Part.cs, MuUtils.cs and Servo.cs for DamnedRobotics), and tested in KSP 0.20.2.186 (latest Steam build); everything seems to work fine. I will message the author with this fix and ask for permission to distribute a patched plugin.

Nice find! I compiled it myself and it is indeed working correctly. Good find and thanks!

Link to comment
Share on other sites
giltirn

giltirn

Posted
Posted
Jeepers... that is creepy! The thing has been broken forever and we both fix it with in 20min of each other. Nice job!

Mine is more or less the same fix. It's easy once you spend hours debugging it. LOL.

I also had found a problem with undefined keys that I needed to fix. Maybe because I split out the MJ crap same as you (90% of the code went bye-bye). Did you check the log to see if you are getting any spam about undefined keys?

I saw the undefined keys problem too, but I figured that it was probably an existing bug. Being very new to KSP modding I could not immediately see a way to tell the user that keys need to be bound before going to the launch pad - I would be interested in seeing your solution.

Link to comment
Share on other sites
giltirn

giltirn

Posted
Posted
How did you do that?

To compile the source you need a C# compiler to compile and link the source into a .dll. I just followed the instructions to set up Visual Studio and then played around with a simple module in the tutorial. In order to compile DamnedRobotics, just download the 4 source files I mentioned from the link in the OP, import them into a Visual Studio project, make the changes from my post, add the 2 .dll files as references that are discussed in the tutorial, then run build. You will also need to add PART { } around the contents of the .cfg files in order for them to be read in 0.20+.

Link to comment
Share on other sites
viperwolf

viperwolf

Posted
Posted
To compile the source you need a C# compiler to compile and link the source into a .dll. I just followed the instructions to set up Visual Studio and then played around with a simple module in the tutorial. In order to compile DamnedRobotics, just download the 4 source files I mentioned from the link in the OP, import them into a Visual Studio project, make the changes from my post, add the 2 .dll files as references that are discussed in the tutorial, then run build. You will also need to add PART { } around the contents of the .cfg files in order for them to be read in 0.20+.

:confused: Ill wait for someone to post the new plugin lol. But thank you for the explanation. Im going to mess around with the information you have provided to see how far i can go.

Link to comment
Share on other sites
GavinZac

GavinZac

Posted
Posted

If we are stripping back to just what DR needs, is that going to affect other mods that use mumech.dll? Or can two versions be loaded?

Also, if mumech.dll is already distributed widely, is there any proprietary reason why sharing a bug fixed version of it would concern the DR modders? If the same buggy code is being distributed by other mods, but just not being executed to cause errors, I don't see a reason the bug fixes can't be distributed as part of those mods. The part files specific to this mod would need to be cleared, obviously, but then again those are rather easily fixed by hand without me having to install Visual Studio (Netbeans will be very upset if I cheat on her again)...

Link to comment
Share on other sites
KhaosCorp

KhaosCorp

Posted
Posted
If we are stripping back to just what DR needs, is that going to affect other mods that use mumech.dll? Or can two versions be loaded?

Also, if mumech.dll is already distributed widely, is there any proprietary reason why sharing a bug fixed version of it would concern the DR modders? If the same buggy code is being distributed by other mods, but just not being executed to cause errors, I don't see a reason the bug fixes can't be distributed as part of those mods. The part files specific to this mod would need to be cleared, obviously, but then again those are rather easily fixed by hand without me having to install Visual Studio (Netbeans will be very upset if I cheat on her again)...

- All addons released on the KSP network require a license, the license is to make it clear what other people are allowed to do with your mod.

And as such a proper juridically valid license works just as well as just writing "No distribution" or something along those lines , as long as it leaves no room for personal interpretation.

^^^that's why its a problem.....theres a sticky post at the top of the add-on forum with these details....good idea to read it so you know whats allowed

Link to comment
Share on other sites
GavinZac

GavinZac

Posted
Posted
...theres a sticky post at the top of the add-on forum with these details....good idea to read it so you know whats allowed

Yes, but who does mumech.dll belong to? If they've already given some other people license to distribute their own versions of the mod, surely those people are then within rights to fix buggy code within the dll?

I would check who the original creator was myself but I'm on a GPRS connection off the coast of Malaysia in the South China Sea.

Link to comment
Share on other sites
sirkut

sirkut

Posted
Posted
To compile the source you need a C# compiler to compile and link the source into a .dll. I just followed the instructions to set up Visual Studio and then played around with a simple module in the tutorial. In order to compile DamnedRobotics, just download the 4 source files I mentioned from the link in the OP, import them into a Visual Studio project, make the changes from my post, add the 2 .dll files as references that are discussed in the tutorial, then run build. You will also need to add PART { } around the contents of the .cfg files in order for them to be read in 0.20+.

The part requirement for the cfg is only necessary if you want to use the new directories. You can however place them in the old legacy folders and it will work just fine.

Link to comment
Share on other sites
giltirn

giltirn

Posted
Posted
If we are stripping back to just what DR needs, is that going to affect other mods that use mumech.dll? Or can two versions be loaded?

Also, if mumech.dll is already distributed widely, is there any proprietary reason why sharing a bug fixed version of it would concern the DR modders? If the same buggy code is being distributed by other mods, but just not being executed to cause errors, I don't see a reason the bug fixes can't be distributed as part of those mods. The part files specific to this mod would need to be cleared, obviously, but then again those are rather easily fixed by hand without me having to install Visual Studio (Netbeans will be very upset if I cheat on her again)...

If you strip back the code then other mods that use mumechlib.dll would probably break, depending on how smart the linker is; either you install only the stripped-back library, in which case most of the mumechlib methods will not be defined that are used by other mods, or else you install the old mumechlib.dll alongside the stripped-back version, in which case there will be multiple and differing definitions of some of the methods - this will either cause the linker to fail or it will load one and not the other with no idea a priori which one to use.

Considering mumechlib seems to be no longer supported, it makes sense for the DR author to strip out all the extraneous stuff from the library and to rename the methods to prevent conflicts with mumech.dll. Then the mod becomes independent of mumechlib and changes can be made without the possibility of breaking other mods.

Link to comment
Share on other sites
giltirn

giltirn

Posted
Posted

It appears that DR is a collaboration between r4mon and DYJ. r4mon wrote the mumechlib library, and it is available under the GPL license, meaning that we in the community can modify and redistribute it. The parts were created by DYJ, who has asked for permissions before redistributing. It seems that we can release a fixed .dll and source code, but not the parts.

Link to comment
Share on other sites
GavinZac

GavinZac

Posted
Posted

That's very useful then. That's why I love Free software - it makes for sane distribution. Kudos to Ramon for doing so.

So the fixed dll can be distributed then? I would offer to host it but again, I'm not in a convenient location, and as geektastic as I would feel uploading a dll to my web server from my phone, I wouldn't like to disappoint people of it doesn't work.

Link to comment
Share on other sites
giltirn

giltirn

Posted
Posted
Sounds like the parts do not need redistribution, only the fixed .dll

If we wanted to change the class names in the fixed library to prevent the .dll from conflicting with another installation of mumechlib (which is used by other mods), we would have to modify the part.cfg files. Of course the required changes could just be written down to be applied by the end-user, but this may turn people off.

Link to comment
Share on other sites
GavinZac

GavinZac

Posted
Posted

If mumech.dll development has ceased, the fix could be distributed (for the moment) as drop in replacement for it, with it including the all the non DR stuff? It would fix several other mods, such as Modular Multi wheels which is choking on a DR function. It could then be adopted wholesale as the new 'canonical' mumech.dll version.

Link to comment
Share on other sites
Capt.Joseph Kerbertson

Capt.Joseph Kerbertson

Posted
Posted

I would like to publicly apologize to KhaosCorp for my tirade which ultimately has nothing to do with him. I would also like to apologize to DYJ for sullying up his mod page and most of all to those frequent the boards. This is not how we behave as community and I forgot that for one brief second. I hope that in the future my posts will be meaningful and helpful to all and that we can all enjoy this great community without the need to delve into the ugliness of insults.

Capt.Joseph Kerbertson

Link to comment
Share on other sites
astronutkhillips

astronutkhillips

Posted
Posted
I saw the undefined keys problem too, but I figured that it was probably an existing bug. Being very new to KSP modding I could not immediately see a way to tell the user that keys need to be bound before going to the launch pad - I would be interested in seeing your solution.

It looks to me like the empty strings are intended by the plugin but the engine now reports it as an error. I just wrapped Input.GetKey() thus:

    public bool wrapGetKey(string n)
    {
        if (n != "")
            return Input.GetKey(n);
        else
            return false;
    }

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...