While this PR adds a whole new tab for "Skills" and tries to make them fully parametrizable, unfortunatelly, due to certain limitations, even when the MethodHandle reflection-way of using 'reflection without utilizing the java.lang.reflection.* stuff' (which is blocked by the game's SecurityManager) is utilized to strip some public static final members of their final modifier - the fields are still not changable.
At this point, it's less about my potentially wrong use of MethodHandles and a bit more about the SecurityManager just not letting me change them; which sortof makes the whole "lets make all skills' attributes parametrizable" idea somewhat moot.
BUT - as long as the header dividers in LunaSetting's CSV mention that "Changing these values currently does nothing" and actually invoking reflection that tries to change them methods are commented out, it can still function as a mod... that half-works and half doesn't work.
Out of all the implemented skills, (currently) only the Field Repairs skill has 6 unchangable parameters. The number will surely rise as more skills are covered though, but as long as the header/divider mentions that they don't work - it should be fine i think.
Of course, further refactoring and breaking the method into updateWorkingParts() and //updateNonWorkingParts() would be greatly appreciated where the WorkingParts thing will actually perform work that I know works fine, and the commented-out NonWorkingParts will perform work that I know doesn't work fine - namely the reflection thing I've spent time developing.
While this PR adds a whole new tab for "Skills" and tries to make them fully parametrizable, unfortunatelly, due to certain limitations, even when the MethodHandle reflection-way of using 'reflection without utilizing the
java.lang.reflection.*stuff' (which is blocked by the game's SecurityManager) is utilized to strip somepublic static finalmembers of theirfinalmodifier - the fields are still not changable.At this point, it's less about my potentially wrong use of MethodHandles and a bit more about the SecurityManager just not letting me change them; which sortof makes the whole "lets make all skills' attributes parametrizable" idea somewhat moot.
BUT - as long as the header dividers in LunaSetting's CSV mention that "Changing these values currently does nothing" and actually invoking reflection that tries to change them methods are commented out, it can still function as a mod... that half-works and half doesn't work.
Out of all the implemented skills, (currently) only the Field Repairs skill has 6 unchangable parameters. The number will surely rise as more skills are covered though, but as long as the header/divider mentions that they don't work - it should be fine i think.
Of course, further refactoring and breaking the method into
updateWorkingParts()and//updateNonWorkingParts()would be greatly appreciated where the WorkingParts thing will actually perform work that I know works fine, and the commented-out NonWorkingParts will perform work that I know doesn't work fine - namely the reflection thing I've spent time developing.