As the title says, I have a public class inheriting from AIPath with its own public variables. However, none of them will show in the inspector, even with the Serializable or SerializeField/Reference tags. I couldn’t find an AIPath editor script, and I can’t figure out how on earth to get my subclass’s public variables to show in the inspector as well as the values from the base class that are shown.
Please advise on how to do this.
Thanks!
Edit: I can disable the AIBase editor from being used by subclasses by changing line 5 to [CustomEditor(typeof(AIBase))] (editorForChildClasses defaults to false). However this also has the effect of not letting the editor script work on the normal AIPath class. Plus I really dislike editing any third part library I’m using myself. There’s got to be a better way to do it, I’m just not sure what it is.
Generally I discourage inheriting from the AIPath class. It is designed so that most things can be accomplished by separate scripts that interact with it without any inheritance.
You can also create a custom editor script (which inherits from AIBaseEditor) and exposes your custom properties.
@aron_granberg Dang it, I just finished a refactor from a separate script + AIPath to a subclass of AIPath yesterday. For some reason I always thought subclassing was supposed to be a main usage.
Why do you discourage subclassing AIPath? Is there an intended better way of creating an AI agent script for users who want more control over the implementation (e.g. access to the path value)? My other thought was to use AIPath as a template, and implement my own version of the class from AIBase and IAstarAI, just like AIPath. Is this the better way? Or are users supposed to only ever use the AIPath script as is? Having an extra Monobehavior seems wasteful when you start having large quantities of agents, and just using the existing path value after its calculation seems a lot more performant than having a second script that creates its own interpolator and observes.
You can of course subclass AIPath if you really need it (e.g. to access the path field). The recommendation stems mostly from people adding a ton of game logic to the AIPath script, which usually makes things more brittle than if they had interfaced with the AIPath component from a separate script.
In your case I’d probably recommend subclassing AIPath and adding a few simple methods that you need, e.g. Vector3 EstimatedPositionAtFutureTime (float t) or something.