-
Notifications
You must be signed in to change notification settings - Fork 120
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
Support for 3rd party robot plug-ins with OBJ models #138
Comments
I think an even better solution could be to remove the saved folders altogether. It's a common cause of annoyance when people switch from packaged to manually installed ARGoS or viceversa. If the storage folder is anyway under the installation path, I see no reason to save it because it can be detected. I think this would solve your problem, right? |
Yes, good point :) these folders for built-in ARGoS assets are stored under the installation path anyway, so not sure why they need to be recorded separately - looks like this feature was added for icons/textures 8 years ago (b9c310a), and then copied recently for models (886037b). What would the best solution be for 3rd party plug-ins with OBJ models that the user does not wish to |
We could add a new environment variable called |
I have deleted the code that saves/restores the folders, check 167cda1. |
Great thanks, that should fix it! The corresponding part of the README will need to be updated too, but perhaps not until the next tagged release. An |
I have one 'clean' version of ARGoS installed system-wide under
/usr/local/
, as well as multiple 'experimental' versions installed in local directories by specifyingCMAKE_INSTALL_PREFIX
. This is so that I canmake install
experimental 3rd party plug-ins into a locally installed version of ARGoS without interfering with anything else. To select which installation of ARGoS I'd like to be active, I use shell scripts to set the following environment variables:This worked fine until I started experimenting with robot plug-ins that use custom OBJ models, as
CQTOpenGLMainWindow::ReadSettingsPreCreation()
checks to see whethermodel_dir
already exists in your settings (on macOS, these are stored in~/Library/Preferences/info.argos-sim.ARGoS.plist
): https://github.com/ilpincy/argos3/blob/master/src/plugins/simulator/visualizations/qt-opengl/qtopengl_main_window.cpp#L211As my system-wide installation of ARGoS is the first one that I ever ran (before
model_dir
was defined), it createdinfo.argos-sim.ARGoS.plist
with paths pointing to/usr/local/
as returned byCSimulator::GetInstance().GetInstallationDirectory()
(and thereforeARGOS_INSTALL_PREFIX
, which is set fromCMAKE_INSTALL_PREFIX
) in this else-clause: https://github.com/ilpincy/argos3/blob/master/src/plugins/simulator/visualizations/qt-opengl/qtopengl_main_window.cpp#L218Any other installation of ARGoS that is run thereafter will not update the
model_dir
path because it has already been defined, which can result in a fatal error if a custom OBJ file is not found: https://github.com/ilpincy/argos3/blob/master/src/plugins/simulator/visualizations/qt-opengl/qtopengl_obj_model.cpp#L27This is easily fixed by deleting
~/Library/Preferences/info.argos-sim.ARGoS.plist
so that previous paths are ignored, or by explicitly setting them as described in the README:This is fine if you're willing to
make install
your plug-in into an ARGoS installation, but my understanding was that setting theARGOS_PLUGIN_PATH
environment variable should allow you to run ARGoS with a plug-in that resides somewhere else (including any custom OBJ files that are separate from your ARGoS installation).Is it possible to set
model_dir
to a colon-separated path, so that it can include both OBJ models that come installed with ARGoS and those packaged with separate plug-ins? Alternatively, is there a better place to store these settings (e.g. in another environment variable)? The fileinfo.argos-sim.ARGoS.plist
seems like a strange place to keep these settings, as the rest of the fields are things like:These settings frequently change between executions of ARGoS as the user alters the GUI. Although the following path fields are related to visualisation, they are unlikely to change in the same way:
I'm not sure if this is an issue or a design choice, but I just got tripped up by it!
The text was updated successfully, but these errors were encountered: