New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Load model during runtime: how to run model plugins? #39
Comments
Original comment by Diego Ferigo (Bitbucket: dgferigo).
|
Original comment by Diego Ferigo (Bitbucket: dgferigo). I found that due to a problem in the SDF generation from C++ code, the plugin SDF element was not correctly inserted in the DOM of the object I was sending. The responsible of processing the What’s still missing, instead, is the plugin unloading when the model is removed from the world. The object exposing the |
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina). Diego Ferigo (dgferigo) , glad to hear you figured out how to load plugins at runtime.
That's correct. I don't think there's an issue ticketed for this yet, and I didn't find a |
Original comment by Diego Ferigo (Bitbucket: dgferigo). @chapulina Thanks for the feedback. Right now the plugin unload during model removal is not a blocking feature for us, though on the long run it would be a nice addition. |
Original comment by Diego Ferigo (Bitbucket: dgferigo).
Closing the issue since it has been solved |
Original report (archived issue) by Diego Ferigo (Bitbucket: dgferigo).
The support of loading models during runtime was implemented months ago in PR143.
It doesn’t seem that the UserCommands system has the support to load a plugin if its element is included in the SDF file passed to the protobuf message. In fact, it seems being ignored. Is there any way to do it? In other words, is there any way to load a system defined in a plugin during runtime?
Btw: I know that there is
Server::AddSystem
, that it only requires the server not being in running state. Using this call, though, is not optimal because the system would be added in the world SDF context and it would require manually loading the plugin library. Even more relevant, it would be impossible to pass any configuration to the plugin like the one that could be passed with custom XML properties listed in the plugin SDF element.The text was updated successfully, but these errors were encountered: