Answering some questions from the IRC channel #lipsofsuna

[xenodora]

Someone came into the IRC channel and asked some questions, but I managed to miss them by a few days. On the off chance they stumble across here, or someone else has these questions too, I'll give the answers here:

<uzername> Hello. how to change savefile location?

If you're running under Linux you should be able to change "XDG_DATA_HOME" to change where it stores data (or maybe "XDG_CONFIG_HOME"). If you're using Windows, I'm not sure what you can do to easily change it.

The source files "src/lipsofsuna/system/system-paths.c" and "src/lipsofsuna/paths/paths.c" might be of interest

<uzername> The last version is 0.8.0?

That is latest formal release, but if you want the latest source code go here: https://gitlab.com/xenodora/lipsofsuna. I've been adding bug fixes, and also making improvements to the game and source documentation.

<uzername> Where can I get the API description for lua scripts in data folder?

Documentation for the Lua scripts in the data folder is sparse at the moment. Using "./waf html" to build the HTML documentation might be helpful (output is in "docs/html").

<uzername> Hello. I'd like to get a LMDL model exporter for blender. It is mentioned here: lipsofsuna.org/wiki/Graphics/Blender%20exporter but website is non-available

Fortunately I was able to salvage a copy of that page from my browser cache:

Overview

• Installation:
  
  • Copy the "lipsofsuna_export" directory from "tool/" to Blender's "scripts/addons/" directory.
    
  • Enable "Import-Export: Export Lips of Suna (.lmdl)" in Blender's user preferences view.
    
  • Save your user preferences in Blender.
• The exporter can be found from "File->Export->Lips of Suna" in Blender.
  
• You need to explicitly enable exporting of objects with "Properties->Object->Lips of Suna->Export Settings".

Requirements
You need to have a recent copy of Blender 2.6x installed and have a recent copy of the exporter. Blender 2.6x still gets changed a lot so the exporter may stop to work. The one in the Git repository is often adapted quickly to the changes. You can download the newest version of Blender from their website.

Installation

• Download the game and extract the archive.
  
• Open the "tool" directory located inside the extracted game directory.
  
• Copy the "lipsofsuna_export" directory inside it.
  
• Paste the copied directory into the "2.63/scripts/addons/" directory of your Blender installation.
  
  • Ubuntu package users: Paste into "/.blender/2.63/scripts/addons/" instead.
  
  
• Launch Blender.
  
• Open the "File" menu and select "User Preferences..."
  
• Open the "Addons" tab.
  
• Find "Import-Export: Export Lips of Suna (.lmdl)" from the list.
  
• Click the check box of the exporter box to enable it.
  
• Press the "Save As Default" button to enable automatically at Blender startup.

Using the exporter
The exporter can be found from "File->Export->Lips of Suna (.lmdl)" in Blender. There's also an extra panel at the bottom of the Object tab of the Properties view that helps you control what objects are imported and exported.

The exporter writes the .lmdl files to the same directory with the original .blend file. To make the models accessible to the game, you need to copy them to the data directory of the game.

Exporting needs to be explicitly enabled for each object with the "Export Settings" button in the "Lips of Suna" object properties panel. By default, nothing is exported, and the exporter will notify you of this.

<uzername> What was your point to introduce your format?

I don't know what Amuzen's motivation was behind the LMDL file format, as he disappeared before I picked up this project. I can only speculate that other formats didn't have the features or didn't have the documentation to implement.

[LiamM32]

Someone came into the IRC channel and asked some questions, but I managed to miss them by a few days. On the off chance they stumble across here, or someone else has these questions too, I'll give the answers here:

<uzername> What was your point to introduce [the LMDL format]?

I don't know what Amuzen's motivation was behind the LMDL file format, as he disappeared before I picked up this project. I can only speculate that other formats didn't have the features or didn't have the documentation to implement.

What are some alternative file formats that are commonly used?

It's nice to see that you are still reachable to discuss Lips of Suna. I have used IRC a little bit to talk to devs of other open-source projects (SuperTuxKart, Kicad), but I could only use it for real-time communication. I didn't think that you could receive messages like email, as I could only see messages that were posted since connecting to the channel.

[xenodora]

Someone came into the IRC channel and asked some questions, but I managed to miss them by a few days. On the off chance they stumble across here, or someone else has these questions too, I'll give the answers here:

<uzername> What was your point to introduce [the LMDL format]?

I don't know what Amuzen's motivation was behind the LMDL file format, as he disappeared before I picked up this project. I can only speculate that other formats didn't have the features or didn't have the documentation to implement.

What are some alternative file formats that are commonly used?

I don't have enough experience in this field to give a good answer. I would imagine looking at what model formats are commonly used in libraries like Ogre, or what exporters are popular and well maintained with Blender would give you a decent idea.

It's nice to see that you are still reachable to discuss Lips of Suna. I have used IRC a little bit to talk to devs of other open-source projects (SuperTuxKart, Kicad), but I could only use it for real-time communication. I didn't think that you could receive messages like email, as I could only see messages that were posted since connecting to the channel.

I'm logged into IRC 24/7 so, I'll usually see someone's message, even if I'm not around to reply.

Speaking of which, I saw you asked a question on IRC and wasn't around to reply, so I'm going to reply here:

How does the C/C++ code in Lips of Suna's "src" directory know where the Lua scripts are located? I tried using grep, but I couldn't find any references to the root directory of the Lua scripts.

Code for accessing directories and finding files is located in: "src/lipsofsuna/paths/paths.c" "src/lipsofsuna/paths/paths.h". By default the path it looks for files/scripts is "data" and "data/<module_name>", where <module_name> is the name of the module being run.

If you're looking for how to change which module is run, look at "data/default". This is a bare bones module which is run as the default, and queues which module to launch next and immediately exiting. This decides between running the "lipsofsuna" module and "unittest" module based on the program's arguments.

[LiamM32]

Code for accessing directories and finding files is located in: "src/lipsofsuna/paths/paths.c" "src/lipsofsuna/paths/paths.h". By default the path it looks for files/scripts is "data" and "data/<module_name>", where <module_name> is the name of the module being run.

Thank you, Xenodora. I was actually wondering that for a long time. I had tried and failed to get Lua IDE's to understand the paths that the Lua scripts were including. I'll look into this when I want to try working with the Lua codebase again.

But recently, I've been trying to work on the C++ side. Lips of Suna doesn't compile anymore on my computer. I think this is because I have OGRE 1.10 and Bullet 2.86 installed from the Manjaro repositories, while the latest Lips of Suna is written for 1.9 and 2.85.

I know I could just download those and manually install them. But I feel like I should get Lips of Suna to work with Ogre 1.10 to improve performance.

When I do "python3 waf build", it gives errors for "invalid use of incomplete type" for the classes "Ogre::Technique", "Ogre::Mesh", "Ogre::SkeletonInstance", and "Ogre::Bone". It also warns me about the use of deprecated OGRE functions. When I try to compile it in NetBeans, it instead stops with the output "error while loading shared libraries: libBulletSoftBody.so.2.85: cannot open shared object file: No such file or directory", as I have libBulletSoftBody.so.2.86.

I don't know what to do about those "incomplete type" errors. It looks like they're trying to call functions that don't exist in the Ogre header files.
But there is a list of deprecated Ogre functions here, with suggested replacement functions. So I tried doing that.
On that page it says "Ogre::SharedPtr< T >::isNull" should be replaced with "SharedPtr::operator unspecified_bool_type()". I'm inexperienced with C/C++, but it doesn't look right to me. I didn't think function names had spaces in them.
So I went to 'src/lipsofsuna/render/internal' and replaced "lisys_assert (!model->mesh.isNull ());" with "lisys_assert(!model->mesh.operator unspecified_bool_type());" and as I feared, it didn't work. I know I'm doing it wrong, but don't know how to do it right.

As for Bullet physics, I have no idea how to even start with that.

[xenodora]

Code for accessing directories and finding files is located in: "src/lipsofsuna/paths/paths.c" "src/lipsofsuna/paths/paths.h". By default the path it looks for files/scripts is "data" and "data/<module_name>", where <module_name> is the name of the module being run.

Thank you, Xenodora. I was actually wondering that for a long time. I had tried and failed to get Lua IDE's to understand the paths that the Lua scripts were including. I'll look into this when I want to try working with the Lua codebase again.

For 'system' Lua files it uses the base directory of "data". For all other Lua files it uses "data/lipsofsuna" as the base. If your IDE doesn't like two different base directories, or base directories that overlap, you could try using symbolic links next time you try.

But recently, I've been trying to work on the C++ side. Lips of Suna doesn't compile anymore on my computer. I think this is because I have OGRE 1.10 and Bullet 2.86 installed from the Manjaro repositories, while the latest Lips of Suna is written for 1.9 and 2.85.

I know I could just download those and manually install them. But I feel like I should get Lips of Suna to work with Ogre 1.10 to improve performance.

I don't have those libraries installed, and don't have time to try at the moment, so my advice is based off of experience and online documentation.

When I do "python3 waf build", it gives errors for "invalid use of incomplete type" for the classes "Ogre::Technique", "Ogre::Mesh", "Ogre::SkeletonInstance", and "Ogre::Bone".

The "invalid use of incomplete type" means that class has been declared with that name, but none of the details. Incomplete types are useful when you only need to deal with a pointer or reference, and not bloat up compile times with more and more references.

To fix the errors you found, add #includes for the corresponding class. For the ones you listed, in order:

{l Code}: {l Select All Code}

#include <OgreTechnique.h>

{l Code}: {l Select All Code}

#include <OgreMesh.h>

{l Code}: {l Select All Code}

#include <OgreSkeletonInstance.h>

{l Code}: {l Select All Code}

#include <OgreBone.h>

Other class headers should follow a similar naming convention, and if not, check the Ogre documentation.

It also warns me about the use of deprecated OGRE functions.

I don't know what to do about those "incomplete type" errors. It looks like they're trying to call functions that don't exist in the Ogre header files.
But there is a list of deprecated Ogre functions here, with suggested replacement functions. So I tried doing that.
On that page it says "Ogre::SharedPtr< T >::isNull" should be replaced with "SharedPtr::operator unspecified_bool_type()". I'm inexperienced with C/C++, but it doesn't look right to me. I didn't think function names had spaces in them.
So I went to 'src/lipsofsuna/render/internal' and replaced "lisys_assert (!model->mesh.isNull ());" with "lisys_assert(!model->mesh.operator unspecified_bool_type());" and as I feared, it didn't work. I know I'm doing it wrong, but don't know how to do it right.

Deprecated functions can probably be left alone for the moment. The "unspecified_bool_type()" is a obfuscated way of saying it can be used as is in a statement or expression that expects a bool, so

{l Code}: {l Select All Code}

lisys_assert (!model->mesh.isNull ());

becomes

{l Code}: {l Select All Code}

lisys_assert (model->mesh);

When I try to compile it in NetBeans, it instead stops with the output "error while loading shared libraries: libBulletSoftBody.so.2.85: cannot open shared object file: No such file or directory", as I have libBulletSoftBody.so.2.86.

As for Bullet physics, I have no idea how to even start with that.

Given that it's choking with library version numbers, that suggests to me that there are stale object files its trying to link to together, or stale references to the old library. Try doing a clean and complete rebuild to see if that clears this error, or failing that run "./waf configure" again.

From a cursory search, I wasn't able to find any major changes in Bullet's API between 2.85 and 2.86, so you might be okay once you solve the library issue.

[farrer]

When I do "python3 waf build", it gives errors for "invalid use of incomplete type" for the classes "Ogre::Technique", "Ogre::Mesh", "Ogre::SkeletonInstance", and "Ogre::Bone".
(...)
I don't know what to do about those "incomplete type" errors. It looks like they're trying to call functions that don't exist in the Ogre header files.

Those incomplete type are because Ogre define at OgrePrerequisites.h all its classes as forward declarations to speed up compilation when just resolving pointers on headers (at the .cpp, where it uses them, they do a include of the proper files). Thus you are trying to compile with the 'incomplete type' (aka: the forward delcaration of the class, not themselves), where you are effectively using some of the class members (or functions), and should include the proper files where those compilation errors happens (ie: OgreTechnique.h, OgreMesh.h, OgreSkeletonInstance.h, etc).

[LiamM32]

Given that it's choking with library version numbers, that suggests to me that there are stale object files its trying to link to together, or stale references to the old library. Try doing a clean and complete rebuild to see if that clears this error, or failing that run "./waf configure" again

I tried doing "./waf clean" & "./waf configure", but now a new problem has showed up. In the output for "./waf configure", the last line says "Your systems ships with a broken OGRE pkg-config file".
Here is my /usr/lib/pkgconfig/OGRE.pc:

{l Code}: {l Select All Code}

prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
plugindir=${libdir}/OGRE

Name: OGRE
Description: Object-Oriented Graphics Rendering Engine
Version: 1.10.4
URL: http://www.ogre3d.org
Libs: -L${libdir} -lOgreMain  -lpthread -lboost_system
Cflags: -I${includedir} -I${includedir}/OGRE -pthread

The "-lboost_system" was manually added by me, as this topic suggests adding it as a solution to problem I have always had without it. I tried removing it, but same thing happens with "./waf configure". I even reinstalled OGRE, and the same thing still happened.

The "invalid use of incomplete type" means that class has been declared with that name, but none of the details. Incomplete types are useful when you only need to deal with a pointer or reference, and not bloat up compile times with more and more references.

To fix the errors you found, add #includes for the corresponding class.

Well, some functions being called don't even appear to be in those header files.

By the way, having OGRE installed I have the header files. But how does the program compile without the OGRE source files?

[xenodora]

I tried doing "./waf clean" & "./waf configure", but now a new problem has showed up. In the output for "./waf configure", the last line says "Your systems ships with a broken OGRE pkg-config file".
Here is my /usr/lib/pkgconfig/OGRE.pc:

{l Code}: {l Select All Code}

prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
plugindir=${libdir}/OGRE

Name: OGRE
Description: Object-Oriented Graphics Rendering Engine
Version: 1.10.4
URL: http://www.ogre3d.org
Libs: -L${libdir} -lOgreMain  -lpthread -lboost_system
Cflags: -I${includedir} -I${includedir}/OGRE -pthread

The "-lboost_system" was manually added by me, as this topic suggests adding it as a solution to problem I have always had without it. I tried removing it, but same thing happens with "./waf configure". I even reinstalled OGRE, and the same thing still happened.

The latest version of LoS has the "-lboost_system" fix in the configuration, so you shouldn't need to add that.

Given the information I have so far, I can't explain why the configuration is failing. I suspect I might need to install OGRE 1.10.x to diagnose this.

Can you post the output log ".build/config.log"? The part of interest is from the line "Checking for package OGRE" to the end of the file.

The "invalid use of incomplete type" means that class has been declared with that name, but none of the details. Incomplete types are useful when you only need to deal with a pointer or reference, and not bloat up compile times with more and more references.

To fix the errors you found, add #includes for the corresponding class.

Well, some functions being called don't even appear to be in those header files.

By the way, having OGRE installed I have the header files. But how does the program compile without the OGRE source files?

OGRE has already been compiled into binary libraries, so applications dependant on it don't need to recompile it. The header files are used to describe how functions in those binary libraries are called, and how the classes and structures are laid out.

[LiamM32]

I tried doing "./waf clean" & "./waf configure", but now a new problem has showed up. In the output for "./waf configure", the last line says "Your systems ships with a broken OGRE pkg-config file".

The latest version of LoS has the "-lboost_system" fix in the configuration, so you shouldn't need to add that.

Given the information I have so far, I can't explain why the configuration is failing. I suspect I might need to install OGRE 1.10.x to diagnose this.

Can you post the output log ".build/config.log"? The part of interest is from the line "Checking for package OGRE" to the end of the file.

I should mention that I have had that "broken OGRE pkg-config file" problem a long time ago, but I don't remember what I did about it.

Here is my output log file, as you suggested.

[LiamM32]

Nevermind that OGRE pkg-config problem. The problem is that I had messed up my "/usr/include/boost/predef/os/bsd.h" because Netbeans was giving me warnings about it having a recursion with it's included "bsd/free.h". I had attempted to fix that but it ended up causing a problem with "./waf configure", as is reported in that config.log file.

I reinstalled boost to reset that file. Now the "./waf configure" command succeeds. Now I just have to deal with those src problems to make the "./waf build" stage work.

[LiamM32]

The latest problem I have had to deal with doesn't seem to be with OGRE, but with Bullet. It's in src/lipsofsuna/extension/physics/physics-collision-configuration.cpp in the class LIPhyCollisionConfiguration. It doesn't recognize the identifier m_simplexSolver. I have tried to track down the cause, but have not succeeded.

I wonder why this codebase used to work, but is only now failing to compile.

[xenodora]

The latest problem I have had to deal with doesn't seem to be with OGRE, but with Bullet. It's in src/lipsofsuna/extension/physics/physics-collision-configuration.cpp in the class LIPhyCollisionConfiguration. It doesn't recognize the identifier m_simplexSolver. I have tried to track down the cause, but have not succeeded.

At a glance I think the member m_simplexSolver was made private or protected, and it can't be accessed directly like before. The fix is to just use the new getSimplexSolver() function instead, like so:

{l Code}: {l Select All Code}

   create_func = new(mem) LIPhyCollisionAlgorithmCreateFunc (this, this->getSimplexSolver(), this->m_pdSolver);

I wonder why this codebase used to work, but is only now failing to compile.

It's probably mainly due to minor changes library headers and APIs that expose instance where the proper way wasn't followed.

[LiamM32]

At a glance I think the member m_simplexSolver was made private or protected, and it can't be accessed directly like before. The fix is to just use the new getSimplexSolver() function instead, like so:

Actually, it appears that getSimplexSolver was removed at the same time as m_simplexSolver from btDefaultCollisionConfiguration.h. In the same commit, I notice a change to btConvexConvexAlgorithm that removes simplexSolver from a parameter. It seems like many simplexSolver-related things were removed in that commit. I don't know what SimplexSolver is, so I'm just going by the identifiers.

Before you posted yesterday, what I did was simply remove the m_simplexSolver parameter from the function. I don't know what it does. Is it still needed?
After dealing with other build errors in other files, I got the program to build successfully, but it had a segmentation fault immediately after starting it.

Here is the output when attempting to start Lips of Suna:

{l Code}: {l Select All Code}

[liam@liam-desktop-Manjaro lipsofsuna-xenodora]$ ./lipsofsuna
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
Segmentation fault (core dumped)


Is this JACK? The audio server? I didn't think that Lips of Suna would use JACK.

Maybe it's time that I upload my codebase via git. If you have time, it would be nice if you could review my changes and give me some pointers.
I haven't replaced the deprecated functions yet, as I want to get it working before I do that.

[xenodora]

At a glance I think the member m_simplexSolver was made private or protected, and it can't be accessed directly like before. The fix is to just use the new getSimplexSolver() function instead, like so:

Actually, it appears that getSimplexSolver was removed at the same time as m_simplexSolver from btDefaultCollisionConfiguration.h. In the same commit, I notice a change to btConvexConvexAlgorithm that removes simplexSolver from a parameter. It seems like many simplexSolver-related things were removed in that commit. I don't know what SimplexSolver is, so I'm just going by the identifiers.

Before you posted yesterday, what I did was simply remove the m_simplexSolver parameter from the function. I don't know what it does. Is it still needed?

It looks like it is still needed for older versions version of Bullet, but newer ones needs to be removed.

After dealing with other build errors in other files, I got the program to build successfully, but it had a segmentation fault immediately after starting it.

Here is the output when attempting to start Lips of Suna:

{l Code}: {l Select All Code}

[liam@liam-desktop-Manjaro lipsofsuna-xenodora]$ ./lipsofsuna
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
Segmentation fault (core dumped)


Is this JACK? The audio server? I didn't think that Lips of Suna would use JACK.

Lips of Suna uses OpenAL library for audio, so it's likely that the library is trying to access JACK when opening a sound device. You might want to look at misconfiguration of OpenAL, or consider form of OSS emulation like "aoss" or "osspd" as a fallback.

Can you provide a back trace of this segmentation fault? Use these instructions for GDB if you don't know how:

{l Code}: {l Select All Code}

gdb ./lipsofsuna
run
bt
quit

It seems likely that the failure to initialise a sound device is the culprit behind the crash, but it's also possible that the error message is a red herring and the crash lies elsewhere. Having the back trace will help clear that up, and will also help to pin point the exact point of failure.

Maybe it's time that I upload my codebase via git. If you have time, it would be nice if you could review my changes and give me some pointers.
I haven't replaced the deprecated functions yet, as I want to get it working before I do that.

I'll go through your changes from your other thread later, when I have time, and merge them in. Some changes I'll have wrap in #if/#else/#endif to account for different library versions.

[LiamM32]

It looks like it is still needed for older versions version of Bullet, but newer ones needs to be removed.

You're on MINT, aren't you? Doesn't MINT get it's packages from Ubuntu? Looking at Ubuntu's packages, both OGRE and Bullet are surprisingly outdated, even in the upcoming Ubuntu versions.

I have tried downloading and compiling bullet myself. It took more effort than most programs take to compile, but I got it working. I had no such success for Ogre.

The OGRE website's instructions to get the SDK on Linux are outdated. Maybe I should go talk to the Ogre devs to point this out. But I don't know who typically makes the Ubuntu/MINT packages.

Can you provide a back trace of this segmentation fault? Use these instructions for GDB if you don't know how:

Thank you for posting these GDB instructions. I remember the website used to have instructions like this, but it's now offline.

I have the terminal output from waf and gdb in the file attached.

Even though I configured with input grabs disabled, it froze and I had to open a new session and use "pkill gdb" to end it. Line 358 in that file (all of the last 5 lines) didn't get output until I killed it. So it's probably everything above this line that's relevant to you.

{l Code}: {l Select All Code}

(gdb) Exception ignored in: <gdb.GdbOutputFile object at 0x7f5c2d9b61d0>

By the way, I think it would be better if Lips of Suna only grabbed the mouse when the cursor disappears.

[LiamM32]

I can't believe it, but I actually managed to figure out how to stop gdb from freezing on my own. I just had to edit src/lipsofsuna/extension/input/input-system.cpp and made this change to stop mouse grabbing. (Lines 32-37)

{l Code}: {l Select All Code}

LIInpSystem::LIInpSystem (LIInpInput* input, bool grab) :
   grab (false),
   input (input),
   input_manager (NULL),
   keyboard (NULL),
   mouse (NULL)

I was surprised by how easy it was to stop the mouse input from being grabbed. Now I can move the mouse outside the Lips of Suna window, and enter more commands into gdb.

Here is the output of "bt" in gdb:

{l Code}: {l Select All Code}

(gdb) bt
#0  0x00007ffff6c18b09 in btClock::getTimeMicroseconds() ()
   from /usr/lib/libLinearMath.so.2.86
#1  0x00007ffff6c18e08 in CProfileNode::Call() ()
   from /usr/lib/libLinearMath.so.2.86
#2  0x00007ffff6c19426 in CProfileManager::Reset() ()
   from /usr/lib/libLinearMath.so.2.86
#3  0x00007ffff71a840a in btDiscreteDynamicsWorld::stepSimulation(float, int, float) () from /usr/lib/libBulletDynamics.so.2.86
#4  0x00000000004fcc21 in liphy_physics_update (self=0x83fec0,
    secs=0.00144600868)
    at ../src/lipsofsuna/extension/physics/physics.cpp:416
#5  0x00000000004e353f in private_physics_main (thread=0x15d38a0,
    data=0x7fffffffd6e0)
    at ../src/lipsofsuna/extension/parallel/ext-module.c:140
#6  0x0000000000469f25 in private_thread (data=0x15d38a0)
    at ../src/lipsofsuna/system/system-thread.c:91
#7  0x00007ffff5e86297 in start_thread () from /usr/lib/libpthread.so.0
#8  0x00007ffff301e25f in clone () from /usr/lib/libc.so.6

I'll attach the file of everything that happened in the terminal from "./waf configure" to the end of gdb.

I'm still getting the segfault though.

[charlie]

One step at a time, one foot in front of the other.

[LiamM32]

I'm trying to track down the cause of this Bullet-related segmentation fault.

So I installed a Ubuntu 16.10 partition on my computer because it has an older version of Bullet (2.83). I wanted to try to get the Xenodora's latest version of Lips of Suna running, and then go to Netbeans IDE and try to figure out why that function doesn't segfault with the older Bullet.

But strangely, I'm having problems with "./waf configure". It isn't detecting Bullet.

{l Code}: {l Select All Code}

liam@liam-secondary:~/source/lipsofsuna$ ./waf configure
Setting top to                           : /home/liam/source/lipsofsuna
Setting out to                           : /home/liam/source/lipsofsuna/.build
Checking for 'gcc' (c compiler)          : /usr/bin/gcc
Checking for 'g++' (c++ compiler)        : /usr/bin/g++
Checking for header dlfcn.h              : yes
Checking for header fcntl.h              : yes
Checking for header inotifytools/inotify.h : yes
Checking for header inttypes.h             : yes
Checking for header poll.h                 : yes
Checking for header stdint.h               : yes
Checking for header sys/inotify.h          : yes
Checking for header sys/mman.h             : yes
Checking for header sys/stat.h             : yes
Checking for header sys/time.h             : yes
Checking for header sys/wait.h             : yes
Checking for header time.h                 : yes
Checking for header unistd.h               : yes
Checking for header windows.h              : not found
Checking for header iconv.h                : yes
Checking for function fork                 : yes
Checking for function usleep               : yes
Checking for library dl                    : yes
Checking for library m                     : yes
Checking for library pthread               : yes
Checking for library iconv                 : not found
Checking for package zlib                  : library z
Checking for package sqlite                : library sqlite3
Checking for package bullet                : not found
Could not find bullet
(complete log in /home/liam/source/lipsofsuna/.build/config.log)

I have libbullet-dev and libbullet-extras-dev installed, so it shouldn't be doing this.

But then I decided to download Bullet 2.81 and compile it myself. Bullet 2.81 is installed in my /usr/local/ folder, but waf still isn't detecting it. I'm still having the same problem.

[LiamM32]

But strangely, I'm having problems with "./waf configure". It isn't detecting Bullet.
...
I have libbullet-dev and libbullet-extras-dev installed, so it shouldn't be doing this.

Nevermind. I just needed to install pkg-config.

[LiamM32]

I would probably be having less trouble if I knew how to set a custom directory for Bullet. Then I could use the source files (*.cpp) for debugging.

A Bullet developer suggested that I use the override keyword to catch the problem. But I need to enable C++11 for it to work, and I don't know how to do that with waf.

[TiborBuzási]

Just edit this line in the wscript file from:

{l Code}: {l Select All Code}

conf.env.CFLAGS_CORE.extend(['-g', '-Wall', '-DHAVE_CONFIG_H'])

to:

{l Code}: {l Select All Code}

conf.env.CFLAGS_CORE.extend(['-g', '-Wall', '-DHAVE_CONFIG_H', '-std=c++11'])

I'm trying to track down the cause of this Bullet-related segmentation fault.

If you compile Bullet 2.86.1 with no built-in profiling (can be set in "src/LinearMath/btQuickprof.h"), then it runs fine (using Ogre 1.9.0, Bullet 2.86.1 and Lua 5.1 on Ubuntu 17.04). Not sure if LoS is passing a bad value or Bullet is bugging.

[LiamM32]

Just edit this line in the wscript file from:
...
If you compile Bullet 2.86.1 with no built-in profiling (can be set in "src/LinearMath/btQuickprof.h"), then it runs fine (using Ogre 1.9.0, Bullet 2.86.1 and Lua 5.1 on Ubuntu 17.04). Not sure if LoS is passing a bad value or Bullet is bugging.

Thank you. Did you download and compile Lips of Suna from my repository?

I actually have it working with Bullet 2.86.1, but it didn't work for me with Bullet 2.86 (from Manjaro repositories).

Thank you for the help with C++11 in waf.

[TiborBuzási]

Thank you. Did you download and compile Lips of Suna from my repository?

I cloned xenodora's repository and I only changed the Bullet and the mouse-grab related stuff from commit 2443f89d.

I'm having thread related segfault issues, because the Bullet built-in profiler supports only 64 threads, and it tries to access more than that. Probably it is a Bullet bug. Still, it works without compiling the Bullet profiler.