Loading Plugin from Route

I am attempting to achieve some effect using the technique described in https://bveworldwide.forumotion.com/t1929-animated-model-plugin-dynamic-texture-update.
As I want to update the texture programmatically, I have to load a plugin for that.
If I use a train plugin, that will do the job, but the texture would not be updated if I used the other train.

I have tried to use TranslateXScript of the animated object to load a plugin regardless of the train.
However, this method has apparent shortcomings:
Because only one OpenGL texture is stored for a file, the texture updating program must work in a singleton way. Otherwise, the texture is updated multiple times each frame and causes unnecessary work to be done.

1) Placing only one animated object model in the entire route
That would ensure the singleton. But the model will get unloaded as the train runs away, and the script will not be called after that.
So I will have to use the CSScript only as an entry point, and then use Harmony.Lib to patch LibRender2 and inject my code directly into the rendering procedure, to keep my code executing even after the model is unloaded.
That is, of course, a very, very dirty way.

2) Placing many many animated object models along the route to keep my code being called
That eliminates the need of patching LibRender2. But it needs a lot of unnecessary dummy models to be placed. And that causes way more unnecessary CSScript invoke. Also, since an assembly is loaded for each model placed, making sure of the singleton will be much more difficult.

As it seems, I need to load a single plugin dll when the route is loaded, and TranslateXScript of the animated object does not seem suitable for this purpose.
So I hope there can be a way to load a dll from the route.
It can also be an Ats dll, or of a different interface.

As Mr.S520 said, the function of loading multiple plugins for a train, just like using https://github.com/s520/DetailManager_For_OpenBVE/pull/1, is planned. Maybe that would suit this.

Hmm

My basic assesment of this is that it's using a sledgehammer to crack a nut, and probably the wrong approach.
Using a plugin to simulate the texture for an animated destination board (for example) is just sticking a fancy graphical plaster over the limitations of what we're currently working with.

Essentially speaking, my general preference is to implement features into the main program (or a shared extension library), rather than via plugin interfaces.
The current runtime plugin interface is OK, but far too many things get done via it which should be handled via the main program. 

If you want to submit a PR implementing this, feel free and I (and anyone else interested!) can take a closer look at what you're trying to do, but I'm not really intending on spending any personal development time on it.

leezer3 wrote:Hmm
My basic assesment of this is that it's using a sledgehammer to crack a nut, and probably the wrong approach.
Using a plugin to simulate the texture for an animated destination board (for example) is just sticking a fancy graphical plaster over the limitations of what we're currently working with.

I think you are right.
I can chunk the destination board into pieces, and use many many StateChange on each part to achieve this effect.
And if the GIF support is added that would enable more fancy effects.

I do not know much about performance. Take the destination board I am going to implement for example, If I use a plugin, there will be two OpenGLTextures being dynamically drawn and replaced. If I use the classical approach, there will be around 24 models with StateChange, 12 models with TextureShift, and 12 faces with GIF texture.
So I wonder which will be more efficent.

By the way, why don't we can have StateChangeScript?