Internal classes makes modding unreasonably hard


Nightinggale
  • Branch: Live Branch Version: Windows Fixed

Whenever a class in the sourcecode is set to be internal, access for modders becomes problematic. It doesn't even serve the purpose because it's still reachable with reflection, it just makes it a whole lot harder to mod and more prone to bugs.

The specific issue I ran into was when I added a 1x1 door. I figured I would start easy by copy pasting the config for the pressure door, but no, there is the following line:

go.AddOrGet<ZoneTile>();

ZoneTile is internal, meaning I can't compile the copy pasted code. This time I could work around the issue by inherit PressureDoorConfig and then call base.DoPostConfigureComplete, but that was more luck in this specific case than a general solution.

I fully get the thinking behind using internal, but it's just not having the intended effect for modders and it creates artificial restrictions in what can be modded.

The easy solution for everybody is to replace all internal keywords with public in vanilla.


Steps to Reproduce
Try to mod code, which makes use of an internal class.

Status: Fixed

This issue has been fixed in either a future version or updated in a previous version.


  Report Bug


User Feedback


A developer has marked this issue as fixed. This means that the issue has been addressed in the current development build and will likely be in the next update.
....

Changed Status to Fixed

Fixed for ZoneTile and a large number of GameStateMachine sub-classes. I think internal classes result almost exclusively from simply forgetting the 'public' keyword as opposed to architectural decisions.

  • Thanks 1

Share this comment


Link to comment
Share on other sites


Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now