Bug#407193: [Fwd: Re: Bug#407193: xmoto: should not read config.dat in current directory]

2007-03-03 Thread Nicolas Adenis-Lamarre

hum, he nice bug isn't it ?
This is because xmoto.exe is next to config.dat on windows.
Rasmus,
any idea to not break the windows behavior ? (nicer than a IFDEF WINDOWS...)

Nicolas

--- Begin Message ---
Salut Brice,

Merci, pour le patch, je transmets aux autorités compétentes.

++

Sam.


Brice Goglin wrote:
> Package: xmoto
> Version: 0.2.4-2
> Severity: normal
> 
> Hi,
> 
> I spent a couple days wondering why my xmoto was losing its config.
> It was not running in windowed mode anymore, while the config file was
> ok and modifying the config and saving was working.
> It was actually caused by a file named 'config.dat' in my home directory.
> This file has absolutely nothing to do with xmoto, and I never thought
> such a common filename could cause a problem to any program.
> xmoto actually reads config.dat in the current dir. If not found, it
> reads $HOME/.xmoto/. If not found, it reads the common file (that I
> apparently don't have in my system, btw).
> 
> I would recommend one of the following change:
> 1) read $PWD/.xmoto/config.dat instead on $PWD/config.dat. A simple
> patch is attached to do so. It would be enough to avoid conflicts
> with other programs using config.dat as a filename.
> 2) don't read anything in $PWD. But, add an command line option
> -config to specify a config file to try before $HOME/.xmoto/config.dat
> This solution is probably better, but harder to code for somebody
> with no clue about xmoto source code.
> 
> By the way, the manpage does not say all what it should about where
> config.dat is read from.
> 
> thanks,
> Brice
> 
> 
> 
> --- xmoto-0.2.4.orig/src/VFileIO.cpp
> +++ xmoto-0.2.4/src/VFileIO.cpp
> @@ -424,7 +424,7 @@
>  }
>  else {
>/* Try current working dir */
> -  pfh->fp = fopen(Path.c_str(),"rb");
> +  pfh->fp = fopen((m_CurrentDir + std::string("/") + Path).c_str(),"rb");
>if(pfh->fp == NULL) {
>  /* No luck. Try the user-dir then */
>  pfh->fp = fopen((m_UserDir + std::string("/") + Path).c_str(),"rb"); 
>
> @@ -977,7 +977,7 @@
>
> /*===
>Initialize file system fun
>
> ===*/
> -  std::string FS::m_UserDir="",FS::m_DataDir; /* Globals */
> +  std::string FS::m_CurrentDir="",FS::m_UserDir="",FS::m_DataDir; /* Globals 
> */
>bool FS::m_bGotDataDir;
>std::string FS::m_BinDataFile = "";
>int FS::m_nNumPackFiles = 0;
> @@ -985,6 +985,7 @@
>  
>void FS::init(std::string AppDir) {
>  m_bGotDataDir = false;
> +m_CurrentDir = "";
>  m_UserDir = "";
>  m_DataDir = "";
>
> @@ -1003,6 +1004,7 @@
>/* Valid path? */
>if(isDir(cModulePath)) {
>  /* Alright, use this dir */
> +m_CurrentDir = cModulePath;
>  m_UserDir = cModulePath;
>  m_DataDir = cModulePath; 
>  
> @@ -1011,6 +1013,9 @@
>else throw Exception("invalid process directory");
> 
>  #else /* Assume unix-like */
> +  /* Store current dir */
> +  m_CurrentDir = std::string(".") + AppDir;
> +
>/* Determine users home dir, so we can find out where to get/save user 
>  files */
>m_UserDir = getenv("HOME");
> --- xmoto-0.2.4.orig/src/VFileIO.h
> +++ xmoto-0.2.4/src/VFileIO.h
> @@ -184,7 +184,7 @@
>static void _FindFilesRecursive(const std::string &Dir,const 
> std::string &Wildcard,std::vector &List);
>
>/* Data */
> -  static std::string m_UserDir,m_DataDir;
> +  static std::string m_CurrentDir,m_UserDir,m_DataDir;
>static bool m_bGotDataDir;
>
>static std::string m_BinDataFile;  
> 
> 
> 
> 
> -- System Information:
> Debian Release: 4.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.20-rc4=panpancucul
> Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
> 
> Versions of packages xmoto depends on:
> ii  libbz2-1.01.0.3-6high-quality block-sorting file 
> co
> ii  libc6 2.3.6.ds1-8GNU C Library: Shared libraries
> ii  libcurl3  7.15.5-1   Multi-protocol file transfer 
> libra
> ii  libgcc1   1:4.1.1-21 GCC support library
> ii  libgl1-mesa-glx [libgl1]  6.5.1-0.5  A free implementation of the 
> OpenG
> ii  libjpeg62 6b-13  The Independent JPEG Group's 
> JPEG 
> ii  liblua5.1-0   5.1.1-2Simple, extensible, embeddable 
> pro
> ii  libode0c2 1:0.5-5Open Dynamics Engine - runtime 
> lib
> ii  libpng12-01.2.15~beta5-1 PNG library - runtime
> ii  libsdl-mixer1.2   1.2.6-1.1+b2   mixer library for Simple 
> DirectMed
> ii  libsdl1.2debian   

Bug#661340: Debian Bug report logs - #661340

2012-05-12 Thread Nicolas Adenis-Lamarre
in this case,
the bug was already reported some years ago by an other debian people ;-)

we added 2 parameters to the xmoto binary to be able to create/extract the
xmoto.bin file
and the man said it was ok. I hope it is still ok for you.

--pack [BIN] [DIR]
Build the BIN package from directory DIR.
--unpack [BIN] [DIR] [no_list]
Unpack the BIN package into the dir DIR.

Nicolas

2012/5/12 Stephen Kitt 

> Hi Nicolas,
>
> On Sat, May 12, 2012 at 01:45:58PM +0200, Nicolas Adenis-Lamarre wrote:
> > The xmoto.bin file is in the tar.gz.
> > However it's not in the svn repository because it is generated at
> > compilation time when building from svn.
>
> That's not the issue here - the problem from our point of view is that
> xmoto.bin is shipped in the tarballs without the corresponding source
> files used to generate it. From our point of view the source isn't
> complete if the tarballs don't include the full contents of the bin
> folder (as available in svn).
>
> C'est peut-être plus simple en français : le souci ne vient pas de
> l'absence de xmoto.bin dans svn, mais plutôt du fait que puisque le
> fichier est généré à partir d'autres fichiers (les contenus du dossier
> bin), ceux-ci devraient être présents dans l'archive .tar.gz. Un
> utilisateur qui récupère juste l'archive devrait disposer de tout ce
> qui est nécessaire pour pouvoir modifier les sources et reconstruire
> un livrable - et puisqu'on ne modifie pas xmoto.bin directement, mais
> plutôt les fichiers dans bin/, il faut fournir ces derniers (en plus
> de xmoto.bin).
>
> Regards,
>
> Stephen
>


Bug#430790: xmoto: No bike or landscape when gameplay begins

2007-06-28 Thread Nicolas Adenis-Lamarre

About this bug:

i don't know wether i must or not consider it as a bug.
It appears when you have played xmoto a long time ago and that you 
installed 0.3.0 and play it.

Why ?

Because of the theme updates (a theme is a list of sprites).
Here is the scenari :

- play xmoto 0.2.7 ; with 0.2.7 comes a theme file.
- update your theme (or update last levels) ; when xmoto see that you 
have updated your theme, it will prefer to use the one updated than the 
one delivered with xmoto

...
during this time, new levels are out. And for example, a new sprite 
appears : sprite999.

...
- install a recent version of xmoto  (coming with new levels, sprites, ...)
- play a recent levels with sprite 999 inside. Xmoto will not find it 
because it will look in the old theme update, not the one delivered with 
your last version.


What is the game unplayable ? because when xmoto don't find some sprites 
it doesn't like it. This is what i can fix.


How to solve the problem ?
Just update your theme (or get last levels)

Nicolas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#492414: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492414

2008-07-28 Thread Nicolas Adenis-Lamarre
i can reproduce the bug with 0.4.2
the bug dissappear with svn version.
A lot of bugs have been fixed in the svn version. I won't loose time to find
which bug it was. We should make next xmoto version out soon to solve the
problem.

Nicolas


Bug#492414: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492414

2008-08-30 Thread Nicolas Adenis-Lamarre
for information,
on the svn version (future 0.5.0), the bug where fixed like that :

http://svn.tuxfamily.org/viewvc.cgi/trunk/src/states/StateMainMenu.cpp?root=xmoto_xmoto&view=diff&r1=2408&r2=2409

Nicolas

2008/8/25 Julien Cristau <[EMAIL PROTECTED]>

> On Mon, Aug 25, 2008 at 17:10:25 +0200, Julien Cristau wrote:
>
> > Looking at frame 3:
> > #3  0x080f83a5 in StateMainMenu::updateStats (this=0x8872d10)
> > at states/StateMainMenu.cpp:700
> > 700   v_totalPlayedTime = atoi(pDb->getResult(v_result, 8, 0, 2));
> >
> > (gdb) p pDb->getResult(v_result, 8, 0, 2)
> > $3 = 0x0
> >
> The attached patch was enough to make xmoto start without segfaulting
> here.
>
> Cheers,
> Julien
>