Suggestion: Use protected variables

Zaddo

Member
I try to avoid changing the base Opsive code for obvious reasons, but primarily, so upgrades are easier. But I do subclass the Opsive classes quite a lot to meet my projects needs.

The default preference for variable access modifiers is 'private', which makes them inaccessible to code in the subclass. It would be very helpful if the access modifers were instead made 'protected'. This would allow greater local customisation of the classes without having to change the base code.

For example, In AnimationMonitor.cs, the SetForwardMovementParameter will return true way too much. There is no tolerance on a change. I find that just constant movement in one direction will result in fluctuations of 0.0000001, which doesn't require a change and generates too many packets in a networked game. If I try to create my own version of this function in a subclass, many of the fields are protected, eg: m_ForwardMovement, etc. If these were changed from private to protected, I could implement a custom solution without modifying the base code. I recognise this might be something you want to change in a future release, but if I could fix this straight away, without modifying base Opsive code, that would be awesome :)

EDIT: PS, Being able to override more methods. e.g. Decorate Damage method with virtual in Health.cs. The need for these type of changes may not be immediately obvious, but for me, in this example, I have implemented my own Network solution and I have the PUN multiplayer addon installed. The conditional compiler directive in this method does not behave how I need the Damage method to work, it blocks the OnDamage call.

I recognise you can't possibly create a system that is infinitely flexible. But, by relaxing how we can override the core classes, it opens up a lot more possibilities for everyone.
 
Last edited:

Justin

Administrator
Staff member
Thanks for the suggestion! Overall I like the idea, but I also don't want to make private some variables that really should be private because it would then change the functionality.
 
Top