Clarifying Legal Boundaries

[Booots]

I'm gearing up to take a crack at the continuous thrust under timewarp problem by re-implementing the Orbit class in certain situations. The methods I see myself needing to override are currently public methods, but they are not declared as virtual. So to override them, I would need to use an IL-editing tool like LinFu.AOP. The add-on rules say under 'Legal Boundaries' that "For assemblies, you may only use exposed public or protected members of classes, and you may not examine the code within any member." and so I wanted to check if inserting hooks at runtime to override a non-virtual method would break the 'exposed' part of that. Note that at no time would I be decompiling the source or otherwise breaking the EULA. All that I would be doing would be intercepting calls to the base method when called on a derived object.

I just want to check if it's okay for me to go down this road before I inadvertently run afoul of the community rules or other legal-ness. I really think that an elegant, near-native solution exists by deriving Orbit objects, but it would be impossible without actually overriding methods. Input from staff and moderators would be very appreciated. If this way falls too far in the grey zone, I'll try to figure out alternative methods.

[Kerbal01]

Think this would be better in Addon Discussion.

[Dman979]

We've notified @Badie and @UomoCapra about this, so they can give an official word. Until then, it's best to hold off so you don't get in trouble if they decide against it.

[Booots]

Thanks @Dman979. Yup, I'm holding off. I really hope there's no problem with it. I think I can make a really elegant continuous thrust solution that even has stock maneuver node support for easy flight planning.

If they'd like, I can keep the code on a private repository and share it with them before any public release so they can see what I'm doing.

Edited August 23, 2017 by Booots

[tomf]

KSP interstellar extended has a thrust while warping feature so you might want to look at how it does it.

[xEvilReeperx]

Last time a similar question was asked, the answer was no because making any changes to the game files outside of GameData is a no-no, and a double no because you would need to distribute the patched assembly afterwards. Patch the method itself at runtime instead without making modifications to the file on disk. Of course, I'm not 100% sure that's technically allowed either...

Quote

8. Legal boundaries

You may not decompile, modify or distribute any of the .dll files or other files KSP comes with beyond content of the GameData folder. Follow the EULA. For assemblies, you may only use exposed public or protected members of classes, and you may not examine the code within any member.

 

[Booots]

36 minutes ago, xEvilReeperx said:

Last time a similar question was asked, the answer was no because making any changes to the game files outside of GameData is a no-no, and a double no because you would need to distribute the patched assembly afterwards. Patch the method itself at runtime instead without making modifications to the file on disk. Of course, I'm not 100% sure that's technically allowed either...

I am looking to do it with Reflection and Emit hooks at runtime - no modification of assemblies or files. Your last line is why I'm asking.  

[Darth Badie]

23 hours ago, Booots said:

I'm gearing up to take a crack at the continuous thrust under timewarp problem by re-implementing the Orbit class in certain situations. The methods I see myself needing to override are currently public methods, but they are not declared as virtual. So to override them, I would need to use an IL-editing tool like LinFu.AOP. The add-on rules say under 'Legal Boundaries' that "For assemblies, you may only use exposed public or protected members of classes, and you may not examine the code within any member." and so I wanted to check if inserting hooks at runtime to override a non-virtual method would break the 'exposed' part of that. Note that at no time would I be decompiling the source or otherwise breaking the EULA. All that I would be doing would be intercepting calls to the base method when called on a derived object.

I just want to check if it's okay for me to go down this road before I inadvertently run afoul of the community rules or other legal-ness. I really think that an elegant, near-native solution exists by deriving Orbit objects, but it would be impossible without actually overriding methods. Input from staff and moderators would be very appreciated. If this way falls too far in the grey zone, I'll try to figure out alternative methods.

Hi! YAs said here: 

Legal boundaries

You may not decompile, modify or distribute any of the .dll files or other files KSP comes with beyond content of the GameData folder. Follow the EULA. For assemblies, you may only use exposed public or protected members of classes, and you may not examine the code within any member.

IL injection is modifying the .dlll, also you can not touch the content outside the GameData folder, so that´s why this is not possible. 

 

 

[Booots]

38 minutes ago, Badie said:

IL injection is modifying the .dlll, also you can not touch the content outside the GameData folder, so that´s why this is not possible.

Thanks for getting back to me, @Badie. Do you mind if we have some dialog around this? Because my understanding was that IL injection doesn't modify the .dll or any file content. As far as I know, it only changes the runtime Type definition at, and only during, runtime. This is why injection and Emit are part of the .Net framework. Just like Reflection, it's used for meta-programming without changing distributed assemblies.

Anyway, feel free to tell me hard no at any point. I'd just like to make sure there's no misunderstanding of what I'd be doing before I'm told no.

[Darth Badie]

of course PM