Think of my example from before. Say I have a hundred cards and each one does various effects. Instead of hard-coding the effect in C++, I can let the script define the effect that’s done. So I could then call from C++:
// in pseudo-code
foreach(card in player.cards)
Have you checked the ScriptInstance documentation? I think it may fit your use case well. You should be able to define your base AngelScript class using empty interface ScriptObject then derived your Anglescript inherintance from this base class. I don’t think you need C++ abstract base class for that. You can then invoke the ScriptInstance’s method by using ScriptInstance::Execute() or ScriptInstance::DelayedExecute() methods from the C++ side.
Would it still receive events properly if I called SubscribeToEvent() from the Start() function? Or would I need to set it up a different way? Also, event data is read in AngelScript the same way it is read in C++, correct?
As I understand it, you only use SubscribeToEvent() when you know there is other Object sending a particular event that your object is interested (and want to become the event receiver). For your case, I don’t think you can easily find the preexisting events that are suitable for your two handlers to listen to. I believe it is easier to just invoke the PreDraw() and PostDraw() as normal Script Object’s methods via the ScriptInstance::Execute() method as I pointed out earlier.
Regarding your confusion, You can observe the differences in the Samples by comparing SubscribeToEvent() call in Ninja.as and SubscribeToEvent() call in 01_HelloWorld.as. HTH.
Due to the way events work, it’s trivial to add new events as needed. My game already has a few dozen custom events in use, same as the InputManager class that I released.
Completely forgot about the .as demos as I had previously deleted them from my build. I looked through them and found what I needed.
For a test, I created a Card class inherited from ScriptInstance. Luckily, it’s easy to tell Angelscript that one class inherits another. Therefore instead of traversing nodes looking for an attached ScriptInstance components which might or might not be a Card (could be something else scripted), it’s now easier to traverse the nodes looking for an attached Card component.
One thing I haven’t yet figured out (remember I’m fairly new to scripting) is how to access the current node within the script. I know I can call my globally registered class from the script. Does ScriptInstance give global variables to the underlying script to do this?
Yes, adding new events to suit your need works as well. I think it is all comes to the design decision whether you want to have loosely coupled or tightly coupled design. The Urho3D library cannot anticipate how all the components in the end application interacts with each other, so having the event subscription mechanism solves that problem by allowing the components to depend on each other loosely. While in your own application, you do have a choice between the two as you should already know how your components would interact with each other before hand.