I have recently made an effort to rediscover Crystal Space. As part of that effort, I have compiled 'CS', 'CEL' and 'CSEditor' version 2.1 from a nightly snapshot.
Each compilation went well, and seemed to produce stable results. In fact, I have had no problems running 'walktest' on numerous demos, and was also well-able to get the exporter plug-in to work with 'Blender'. In fact, once my 'CRYSTAL' environment variable was set, I was even able to 'walktest' Blender exports directly.
But now when my testing continued to CSEditor, I ran into an unepxected problem.
I am based on a Debian / Jessie system, and when I run the naked command 'cseditor', I get:
WARNING: could not load plugin ‘crystalspace.editor.core’
The application closes after displaying a matching GUI message box.
OTOH, The command 'varedittest' seems to work fine, and displays an empty GUI window.
It is possible that I could just be making a naive mistake.
Could somebody please point me into the right direction?
BTW: The rest of the Crystal Space programs seem to run so well, that If the need arose to recompile those, I would rather just give up on CSEditor instead. Yet, there could be some special way in which CSEditor itself needs to be compiled? Or do .SO FIles need to be symlinked, from the CSEditor directories, pointing to crystalspace directories? I don't know.
Dirk
(Edit : ) This is most definitely some sort of naive error on my part. When I give the command 'cseditor' while my PWD is the project folder, '.../csediting' , from which it was compiled, Then the GUI opens up amazingly. So obviously, it seems to require some sort of specific sub-folder, that happens to be within its own project folder.
Can I correct this behavior, by adding some sub-folder to the '/usr/local' -prefixed, root folder, into which CSEditing installed itself?
(Further Observation : ) This package installed 7 .SO Files into
/usr/local/lib/CSEditing
If I have all 7 of those libraries in my PWD when I give the command, 'cseditor' launches just fine. Otherwise, it doesn't. Yet, Even if I put 7 symlinks into
/usr/local/lib
Each pointing to one of the .SO FIles in the subdirectory, I am still not able to launch 'cseditor' from just any directory. AND, setting LD_LIBRARY_PATH to /usr/local/lib/CSEditing does not do the trick.
A KDE .desktop File solves the problem.
Last edit: Dirk Mittler 2016-08-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I have understood my mistake. Of course, the purpose of this plug-in is only, to allow eventual recipients of our games to do some in-game editing. Therefore it becomes a deployment question, of how we get those .SO FIles to the players.
But I have a further question, since the usage of this GUI is not so obvious to me. So there is a 3D view panel, in which an object may be selected. Can that 3D view panel be changed in mode, so that the same object can be resized or repositioned?
And, are there more possible panels, than the ones the 'cseditor' demo-program shows? Would it be possible to use this plug-in, to harness the tremendous power of CEGUI, and to display 'spin-boxes' or 'sliders', for example, that reposition or scale objects?
( 05.08.2016 ) I have solved the original problem. Previously, my $CRYSTAL variable was only set, for one invocation of 'Blender' from the command-line, because to set it permanently required a reboot.
The 'cseditor' demo program will look for its .SO Files in whatever directory is specified, by the $CRYSTAL environment variable. It launches fine now, regardless of what my PWD is.
But this demo still does not make it clear, that the framework can be used to edit anything, only to inspect existing objects.
Sorry to bump,
Dirk
Last edit: Dirk Mittler 2016-08-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello.
I have recently made an effort to rediscover Crystal Space. As part of that effort, I have compiled 'CS', 'CEL' and 'CSEditor' version 2.1 from a nightly snapshot.
Each compilation went well, and seemed to produce stable results. In fact, I have had no problems running 'walktest' on numerous demos, and was also well-able to get the exporter plug-in to work with 'Blender'. In fact, once my 'CRYSTAL' environment variable was set, I was even able to 'walktest' Blender exports directly.
But now when my testing continued to CSEditor, I ran into an unepxected problem.
I am based on a Debian / Jessie system, and when I run the naked command 'cseditor', I get:
The application closes after displaying a matching GUI message box.
OTOH, The command 'varedittest' seems to work fine, and displays an empty GUI window.
It is possible that I could just be making a naive mistake.
Could somebody please point me into the right direction?
BTW: The rest of the Crystal Space programs seem to run so well, that If the need arose to recompile those, I would rather just give up on CSEditor instead. Yet, there could be some special way in which CSEditor itself needs to be compiled? Or do .SO FIles need to be symlinked, from the CSEditor directories, pointing to crystalspace directories? I don't know.
Dirk
(Edit : ) This is most definitely some sort of naive error on my part. When I give the command 'cseditor' while my PWD is the project folder, '.../csediting' , from which it was compiled, Then the GUI opens up amazingly. So obviously, it seems to require some sort of specific sub-folder, that happens to be within its own project folder.
Can I correct this behavior, by adding some sub-folder to the '/usr/local' -prefixed, root folder, into which CSEditing installed itself?
(Further Observation : ) This package installed 7 .SO Files into
/usr/local/lib/CSEditing
If I have all 7 of those libraries in my PWD when I give the command, 'cseditor' launches just fine. Otherwise, it doesn't. Yet, Even if I put 7 symlinks into
/usr/local/lib
Each pointing to one of the .SO FIles in the subdirectory, I am still not able to launch 'cseditor' from just any directory. AND, setting LD_LIBRARY_PATH to /usr/local/lib/CSEditing does not do the trick.
A KDE .desktop File solves the problem.
Last edit: Dirk Mittler 2016-08-05
I think I have understood my mistake. Of course, the purpose of this plug-in is only, to allow eventual recipients of our games to do some in-game editing. Therefore it becomes a deployment question, of how we get those .SO FIles to the players.
But I have a further question, since the usage of this GUI is not so obvious to me. So there is a 3D view panel, in which an object may be selected. Can that 3D view panel be changed in mode, so that the same object can be resized or repositioned?
And, are there more possible panels, than the ones the 'cseditor' demo-program shows? Would it be possible to use this plug-in, to harness the tremendous power of CEGUI, and to display 'spin-boxes' or 'sliders', for example, that reposition or scale objects?
( 05.08.2016 ) I have solved the original problem. Previously, my $CRYSTAL variable was only set, for one invocation of 'Blender' from the command-line, because to set it permanently required a reboot.
The 'cseditor' demo program will look for its .SO Files in whatever directory is specified, by the $CRYSTAL environment variable. It launches fine now, regardless of what my PWD is.
But this demo still does not make it clear, that the framework can be used to edit anything, only to inspect existing objects.
Sorry to bump,
Dirk
Last edit: Dirk Mittler 2016-08-05