Andrei, I hope I can tab your expertise about this. I asked a Debian Games team member some time ago to implement the most recent version of Debian into the next release, but he then came back to me with the following feedback. Can you help with this?:
Unfortunately while I could play locally at the game, I wasn't able to make it suitable for Debian. Let me explain, there is a trigger-rally package and a trigger-rally-data that has just the data files (huge package).
Now, I can see the trigger-rally package trying to load the images/sounds and other stuff locally
cd bin
./trigger-rally
fine
./bin/trigger-rally
Application base directory "trigger-rally-0.6.4/bin/"
Loading game configuration
Failed to add PhysFS search directory "../data"
because this package isn't looking for the correct directory
and the game with autoconf was able to force the directory in the code something like
#ifndef DATADIR#define DATADIR "../data"#endif)
now, with the missing variable, I don't know how to solve the path issue, and moreover, upstream seems to be messy with the data package, I tried to extract the data directory from the same tarball, but it seems to be like this:
ls data/
data.md5 data.zip defplayers icon plugins
how is one supposed to unzip the zip file? do we need it?
sorry, but without further upstream help or a readme I can't really understand
what/where/why everything changed in the packaging.
Hope you will be able to ask upstream to clarify the packaging issues!
Last edit: Onsemeliot 2016-07-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since version 0.6.3, the game's executable no longer uses a hardcoded DATADIR variable for the path to the data. Instead the path is read from the configuration file trigger-rally.config in the user's /home/UserName/.trigger-rally/ directory.
The path can be set in said configuration file by editing the datadirectory entry:
<!-- The possible paths of the data directory, ordered by decreasing priority. If the first directory cannot be found, the next one is tried, and so on. If none of the paths is valid then the game will fail to run. Linux distro packagers: feel free to set the paths in accordance to the installation directory you choose for the trigger-rally data package.--><datadirectory><datapath="../data"/><datapath="C:\Program Files\Trigger Rally\data"/><datapath="/usr/share/games/trigger-rally"/><datapath="/usr/local/share/games/trigger-rally"/></datadirectory>
An important detail about the trigger-rally.config file: if it doesn't already exist in /home/UserName/.trigger-rally/ then it is copied by the game from the default configuration file trigger-rally.config.defs which is searched for in the directory of the game executable, e.g. /usr/bin/. Failure to distribute the default configuration file in the binary directory may result in the game not being able to copy the user configuration, and in turn, failure to find the game data.
how is one supposed to unzip the zip file? do we need it?
The file data.zip is a zero-compression archive containing the games data files. Keeping them zipped improves the loading times (on my computer, at least). That ZIP archive should be distributed as-is in the trigger-rally-data package, however if that is not acceptable it may be extracted and deleted.
Hope you will be able to ask upstream to clarify the packaging issues!
I find that a bit insulting, because these "packaging issues" could have been clarified simply by reading the build documentation and the heavily commented default configuration (doc/BUILDING.txt and bin/trigger-rally.config.defs respectively).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your fast reply, Andrei. I can imagine you getting frustrated by explaining the same thing you documented carefully already. Unfortunately I didn't really understand what the problem was and thought you might be able to fully grasp what Gianfranco was talking about. Next time I will try harder to consult the documentation before disturbing you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can imagine you getting frustrated by explaining the same thing you documented carefully already.
No, having to explain technicalities is the least frustrating thing for me when it comes to this project. I am far more frustrated by the lack of testers, players and packagers of 0.6.3 and 0.6.4.
Also...
sorry, but without further upstream help or a readme I can't really understand
what/where/why everything changed in the packaging.
I suggest that Gianfranco join this forum for further discussion, if there are other things to be clarified.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suggest that Gianfranco join this forum for further discussion, if there are other things to be clarified.
Indeed, I'm here now :)
For some reasons, we had to split the package into two different git repositories, and I have no time to split the orig tarball and see what happened now, the packaging needs to be redone from scratch, and when I imported the new tarball on git I had to revert the change because it contained the -data files.
that said, I extracted the tarball in another place, but... bad me... I read the documentation from the old git repo. so I didn't find the above docs. Now that I see this, I'll try to give it another spin in a week or two probably, I'm too busy with other things right now.
BTW Having a conf file in bin is a no-go, so I'll have to patch that bit, I presume around this line
std::string cfgdefaults = "trigger-rally.config.defs";
thanks so far,
G.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BTW Having a conf file in bin is a no-go, so I'll have to patch that bit, I presume around this line
std::string cfgdefaults = "trigger-rally.config.defs";
I don't believe the patch will be as simple as modifying that line, unfortunately. Surely you are welcome to try, and if you run into problems I'll try to help.
That filename in cfgdefaults is provided to PhysFS in platform-independent notation, meaning that the file is searched for in the search paths set with the PHYSFS_addToSearchPath() function.
So doing the natural looking change below is probably not going to work (can't say for sure because I'm using Windows and can't test it myself right now):
Great, thank you so much for taking over this work. Since I am not capable of programming anything I am wondering how things are concerning versions. I have collected the additions since the release of 0.6.4 and I wanted to ask if it would be easy to add those changes to the Debian version since they do not concern the code after all.
Concerning the copyright things should have bocome much better since the last time a version of Trigger Rally was added to Debian. We clarified and updated the licencing information in our DATA_AUTHORS file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have collected the additions since the release of 0.6.4 and I wanted to ask if it would be easy to add those changes to the Debian version since they do not concern the code after all.
Not wanting to ruin the party, but I believe those new maps belong to 0.6.5. Otherwise we would have data inconsistencies between releases, with Debian packagers basically offering an unofficial version 0.6.4-and-a-quarter.
Besides, all game data has to go through the optimization process before being released (PNG to JPEG, and PNG crushing). This includes the new maps.
so, I think I can just help him in copyright review, and testing, and we should be good :)
Thanks, I am particularly interested in feedback regarding the codriver voice. I have some concerns about its threaded implementation, with which I had problems on some Windows x64 systems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
True. I should have expressed this clearer. Since it will be a long time before the next Debian release and since I can not expect any code changes to happen in the forseable future it would be possible to just release a new version before the Debian freeze and to implement it right away without much hazzle. As I understand it - the hardest implementation work for Debian has happened already. Therefore adding new maps (and events) shouldn't have the potential of breaking anything and it shouldn't be a burden for our Debian helpers to do that as late as possible. This way we could actually get in everything we can come up with until the release candidate of the next version of Debian will be frozen.
I think this would be a great opportunity because many other distros use the Debian repository too and this way we might have the chance to attract more potential players than in any other way. (I actually did find the game this way in the first place.)
Last edit: Onsemeliot 2016-09-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am inclined to oppose a rushed release which would only differ from 0.6.4 by a handful of new maps, and done with the intent of meeting the "freeze" deadline of a certain Linux distribution.
Having said that, if you are absolutely sure about doing this, and the Debian packagers express willingness to package this new 0.6.5 version instead of 0.6.4, and we have enough time before the "freeze", then I will help with the following tasks:
optimize game data (the new maps)
create Win32 binaries and setup
create Win64 binaries and setup
Your task Onsemeliot will be to update the DATA_AUTHORS.txt file to document the additions, if you haven't already.
Last edit: Andrei 2016-09-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am inclined to oppose a rushed release which would only differ from 0.6.4 by a handful of new maps, and done with the intent of meeting the "freeze" deadline of a certain Linux distribution.
Well, it's probably the most important distribution and you claimed that the lack of players/testers is the thing bothering you most about this project. Making more new content easily available to a big group of people might be a good way to at least make an attempt to get more people interested in actually playing the game.
And I don't see any reason to call this a rushed release since there are no plans for something specific in a new release at all. There have been new releases for years without any breathtaking code improvements, before you came along. Just because there was nobody around who could actually have done anything like that.
Thank you for offeriung your help again. The authors file in 0.6.5 should be up do date. But let us wait for the feedback from Gianfranco!
If I find the time I'm sure polishing the project's web page won't hurt in regard to pubic relations either ...
Last edit: Onsemeliot 2016-09-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Andrei, I hope I can tab your expertise about this. I asked a Debian Games team member some time ago to implement the most recent version of Debian into the next release, but he then came back to me with the following feedback. Can you help with this?:
Unfortunately while I could play locally at the game, I wasn't able to make it suitable for Debian. Let me explain, there is a trigger-rally package and a trigger-rally-data that has just the data files (huge package).
Now, I can see the trigger-rally package trying to load the images/sounds and other stuff locally
because this package isn't looking for the correct directory
before we were doing
and the game with autoconf was able to force the directory in the code something like
now, with the missing variable, I don't know how to solve the path issue, and moreover, upstream seems to be messy with the data package, I tried to extract the data directory from the same tarball, but it seems to be like this:
how is one supposed to unzip the zip file? do we need it?
sorry, but without further upstream help or a readme I can't really understand
what/where/why everything changed in the packaging.
Hope you will be able to ask upstream to clarify the packaging issues!
Last edit: Onsemeliot 2016-07-22
Since version 0.6.3, the game's executable no longer uses a hardcoded
DATADIRvariable for the path to the data. Instead the path is read from the configuration file trigger-rally.config in the user's /home/UserName/.trigger-rally/ directory.The path can be set in said configuration file by editing the
datadirectoryentry:An important detail about the trigger-rally.config file: if it doesn't already exist in /home/UserName/.trigger-rally/ then it is copied by the game from the default configuration file trigger-rally.config.defs which is searched for in the directory of the game executable, e.g. /usr/bin/. Failure to distribute the default configuration file in the binary directory may result in the game not being able to copy the user configuration, and in turn, failure to find the game data.
The file data.zip is a zero-compression archive containing the games data files. Keeping them zipped improves the loading times (on my computer, at least). That ZIP archive should be distributed as-is in the trigger-rally-data package, however if that is not acceptable it may be extracted and deleted.
I find that a bit insulting, because these "packaging issues" could have been clarified simply by reading the build documentation and the heavily commented default configuration (doc/BUILDING.txt and bin/trigger-rally.config.defs respectively).
Thank you for your fast reply, Andrei. I can imagine you getting frustrated by explaining the same thing you documented carefully already. Unfortunately I didn't really understand what the problem was and thought you might be able to fully grasp what Gianfranco was talking about. Next time I will try harder to consult the documentation before disturbing you.
No, having to explain technicalities is the least frustrating thing for me when it comes to this project. I am far more frustrated by the lack of testers, players and packagers of 0.6.3 and 0.6.4.
Also...
I suggest that Gianfranco join this forum for further discussion, if there are other things to be clarified.
Indeed, I'm here now :)
For some reasons, we had to split the package into two different git repositories, and I have no time to split the orig tarball and see what happened now, the packaging needs to be redone from scratch, and when I imported the new tarball on git I had to revert the change because it contained the -data files.
that said, I extracted the tarball in another place, but... bad me... I read the documentation from the old git repo. so I didn't find the above docs. Now that I see this, I'll try to give it another spin in a week or two probably, I'm too busy with other things right now.
BTW Having a conf file in bin is a no-go, so I'll have to patch that bit, I presume around this line
std::string cfgdefaults = "trigger-rally.config.defs";
thanks so far,
G.
I don't believe the patch will be as simple as modifying that line, unfortunately. Surely you are welcome to try, and if you run into problems I'll try to help.
That filename in
cfgdefaultsis provided to PhysFS in platform-independent notation, meaning that the file is searched for in the search paths set with thePHYSFS_addToSearchPath()function.So doing the natural looking change below is probably not going to work (can't say for sure because I'm using Windows and can't test it myself right now):
Hi Gianfranco, do you need any further assistance?
Hi, seems that the Debian maintainer (Marc) did a great job on the package, including the fix for the cfg file.
https://anonscm.debian.org/cgit/pkg-games/trigger-rally.git/commit/?id=9068baaa097950965cffee13452a3b3d0da9b9f5
so, I think I can just help him in copyright review, and testing, and we should be good :)
thanks!
Great, thank you so much for taking over this work. Since I am not capable of programming anything I am wondering how things are concerning versions. I have collected the additions since the release of 0.6.4 and I wanted to ask if it would be easy to add those changes to the Debian version since they do not concern the code after all.
Concerning the copyright things should have bocome much better since the last time a version of Trigger Rally was added to Debian. We clarified and updated the licencing information in our DATA_AUTHORS file.
Not wanting to ruin the party, but I believe those new maps belong to 0.6.5. Otherwise we would have data inconsistencies between releases, with Debian packagers basically offering an unofficial version 0.6.4-and-a-quarter.
Besides, all game data has to go through the optimization process before being released (PNG to JPEG, and PNG crushing). This includes the new maps.
Thanks, I am particularly interested in feedback regarding the codriver voice. I have some concerns about its threaded implementation, with which I had problems on some Windows x64 systems.
True. I should have expressed this clearer. Since it will be a long time before the next Debian release and since I can not expect any code changes to happen in the forseable future it would be possible to just release a new version before the Debian freeze and to implement it right away without much hazzle. As I understand it - the hardest implementation work for Debian has happened already. Therefore adding new maps (and events) shouldn't have the potential of breaking anything and it shouldn't be a burden for our Debian helpers to do that as late as possible. This way we could actually get in everything we can come up with until the release candidate of the next version of Debian will be frozen.
I think this would be a great opportunity because many other distros use the Debian repository too and this way we might have the chance to attract more potential players than in any other way. (I actually did find the game this way in the first place.)
Last edit: Onsemeliot 2016-09-01
I am inclined to oppose a rushed release which would only differ from 0.6.4 by a handful of new maps, and done with the intent of meeting the "freeze" deadline of a certain Linux distribution.
Having said that, if you are absolutely sure about doing this, and the Debian packagers express willingness to package this new 0.6.5 version instead of 0.6.4, and we have enough time before the "freeze", then I will help with the following tasks:
Your task Onsemeliot will be to update the DATA_AUTHORS.txt file to document the additions, if you haven't already.
Last edit: Andrei 2016-09-01
Well, it's probably the most important distribution and you claimed that the lack of players/testers is the thing bothering you most about this project. Making more new content easily available to a big group of people might be a good way to at least make an attempt to get more people interested in actually playing the game.
And I don't see any reason to call this a rushed release since there are no plans for something specific in a new release at all. There have been new releases for years without any breathtaking code improvements, before you came along. Just because there was nobody around who could actually have done anything like that.
Thank you for offeriung your help again. The authors file in 0.6.5 should be up do date. But let us wait for the feedback from Gianfranco!
If I find the time I'm sure polishing the project's web page won't hurt in regard to pubic relations either ...
Last edit: Onsemeliot 2016-09-01