Activity for Andrei
-
Andrei posted a comment on ticket #361
I am hesitating to implementing this I wish you would implement this feature, considering the following guidelines: 1. Trust the user If the user selects -j2 in the Expert menu, then trust that they know what they want. 2. Do not lie to the user If the user selected -j2, then the action for -j2 must not be silently skipped. 3. Use sane defaults If you have concerns that -j2 will bring problems in restoreparts mode, simply disable it by default so the user must select it manually. Anyway, whatever...
-
-p choose restoredisk This bug does not affect "full disk" restoration, only the "restore partitions" (restoreparts) mode in which the user manually chooses the partitions to be restored. (If you can now easily reproduce and fix this bug, could you backport the fix to a new CZ 2.6 release? I do not want to upgrade to CZ 2.7 due to poor hardware performance.)
-
CZ 2.6.7: "-j2" does not restore saved the 1 MB hidden data after MBR
-
update all remaining files for release 1.0.2.2
-
update nodist files for 1.0.2.2
-
updated projects to Pelles C 10.00
-
updated docs for release 1.0.2.1
-
switched to using Optparse instead of my own command-line parsing
-
updated help screens for version 1.0.2.1
-
separated version information to its own file
-
improved Linux friendliness of makefile and build scripts
-
updated files for release 1.0.2.0
-
updated files for release 1.0.1.9
-
Hello Janusz. Please provide a run log for the crash: in the Trigger Rally bin folder there should exist a batch file named trigger-rally-x64.RUNLOG.cmd, please run it and attach the resulting text file in a reply.
-
fixed compatibility with TinyXML-2 2.2.0
-
fixed compatibility with PhysFS 2.0.3
-
Nice. You can now play TR natively and test future experimental versions at will. One last thing: please confirm that changing settings in the config works, for example try to disable auto video (TR should then start in a 800x600 window). This is just to make absolutely sure the config is not being ignored. Thanks.
-
I think we're close to the solution. Please apply this third patch and rebuild. Unpack a new trigger-rally-0.6.6.1.tar.gz Apply compat_fixes1.patch Apply compat_fixes2.patch Apply compat_fixes3.patch Run make This patch is supposed to properly create the ".trigger-rally" directory. I'm awaiting confirmation that it does so, and of course the latest tr.log output. I want to commit these compatibility fixes to the SVN as soon as everything works properly for you. They'll probably be in place for the...
-
The patches must be applied in the correct order, otherwise patch2 will be cancelled out. Please try again from scratch: Unpack a new trigger-rally-0.6.6.1.tar.gz Apply compat_fixes1.patch Apply compat_fixes2.patch Run make clean; make
-
Apply the attached patch. It ensures that the writeable directory is set correctly to: /home/UserName/.trigger-rally instead of /home/UserName Please provide a new tr.log as done before so I can see the TR path is set as intended. If everything is OK there will now exist a .trigger-rally dir and a new configuration file trigger-rally-0.6.6.1.config in it (please confirm this, also). The old .CONFIG, which is up one level, which you've edited in the previous step, will be ignored by TR and you should...
-
In likely case the above suggestion doesn't help (I've noticed that auto resolution is already detected as 1366x768 in tr.log) I have another idea for editing the .CONFIG file: disable default player copying. Default player copying was an idea only used in 0.6.4: we would distribute additional players recording best times for maps so that the player would have something to compete against. We since deleted the def players but left in the functionality. <?xml version="1.0" ?> <config> <player copydefplayers="no"...
-
TR may hang while trying to set automatic video mode. "Automatic video mode" is the default since release 0.6.4 and it means that TR attempts to run fullscreen in native resolution. In your case it may fail to deduce the native resolution. Please edit your .CONFIG file trigger-rally-0.6.6.1.config to disable auto video mode: <?xml version="1.0" ?> <config> <video automatic="no" No rebuild is required. Run TR again and if it can run successfully in a window, try next to set up your preferred resolution...
-
More details are needed: start TR by redirecting its output to a file and press Ctrl+C after 1 minute of waiting. Then attach that log file to your post. $ ./trigger-rally 1> tr.log 2>&1 What version of g++ are you using? Early versions are missing certain features that TR needs, meaning TR might be trying to use stubs, hence the hang. Finally, attach your TR configuration file. Normally it should exist as: /home/UserName/.trigger-rally/trigger-rally-0.6.6.1.config
-
This time it's TinyXML-2: assuming you use Debian Stretch, your version of libtinyxml2-dev is 4.0.1 whereas TR currently uses 7.0.1+. Fortunately this too is fixable. I will be providing .PATCH files from now on: instead of manually copying and overwriting files, which is annoying and prone to error, we will use the patch utility to update the files. First, please restore your "src" directory to the original 0.6.6.1 condition, for cleanliness. Then download the attached .PATCH file, copy it inside...
-
@phion: sorry, I missed a few spots in the previous file, please try this new one (hopefully this fixes all problems). So do I need to install the later version of PhysFS as well? That would be one way to solve the problems but if the current physfs_rw.cpp works for you, then you won't need to update PhysFS. Additionally I'll commit these changes to SVN because you're basically testing TR compatibility with PhysFS 2.0.3 for us -- thank you.
-
@phil: it looks like your version of PhysFS is outdated: current Trigger Rally requires PhysFS version 3.0+ and you probably have 2.0.3 or earlier. This isn't your fault of course, PhysFS 3.0.2 is the latest version and "stable" distros don't have it yet. Please replace your physfs_rw.cpp file with the one attached here and try again.
-
wine inside linux to run .exe files. That seems pointlessly inefficient, considering that TR is open-source. Also, by learning how to build it, you will be able to test experimental versions. Anyway, if you ever decide to build TR, refer to the BUILDING.txt file in the "doc" folder.
-
Hello phil. You may safely extract the data.zip archive then delete it, such that the directory structure is similar to: +---bin +---data | +---maps | +---textures | +---defplayers | +---plugins | +---icon | +---sounds | +---vehicles | \---events +---doc \---src +---PEngine +---Trigger +---include \---PSim Remember to delete the .ZIP otherwise its contents will have priority. Otherwise rename its extension, for example data.unused: all .ZIP files inside the Trigger Rally data directory are automatically...
-
Desktop and AppData setup was finalized in [r960]. Note that I didn't test this, so let me know if there are problems. the .DESKTOP file gets copied to /usr/share/applications the .APPDATA.XML file gets copied to /usr/share/metainfo See [r960], [r959], [r958]. Closing this ticket as it was superseded by Ticket 15. Further discussion should happen there.
-
Linux .desktop file
-
Desktop and AppData setup was finalized in [r960]. Note that I didn't test this, so let me know if there are problems. the .DESKTOP file gets copied to /usr/share/applications the .APPDATA.XML file gets copied to /usr/share/metainfo See [r960], [r959], [r958]. Closing this ticket as it was superseded by https://sourceforge.net/p/trigger-rally/patches/15/. Further discussion should happen there.
-
Desktop and AppData setup was finalized in [r960]. Note that I didn't test this, so let me know if there are problems. the .DESKTOP file gets copied to /usr/share/applications the .APPDATA.XML file gets copied to /usr/share/metainfo See [r960], [r959], [r958].
-
added DESTDIR to AppData and Desktop file setup
-
added install/uninstall rules for AppData/Desktop files to Linux makefile
-
added AppData and Desktop files for Linux
-
removed stripping from makefiles
-
.desktop and .appdata To me (a Windows user) it seems that adding and maintaining these files is the responsibility of the Linux packagers because it only affects Linux users. That said, I'll be in favor of adding them, if the other members of this project (Linux users) are also in favor. Remove strip I'm in favor of this. I noticed that the Debian people also patch out the stripping. Apparently it's a hassle for everybody and admittedly it belongs in a target such as install-strip. Use CMake I'm...
-
.desktop and .appdata To me (a Windows user) it seems that adding and maintaining these files is the responsibility of the Linux packagers because they only affect Linux users. That said, I'll be in favor of adding them, if the other members of this project (Linux users) are also in favor. Remove strip I'm in favor of this. I noticed that the Debian people also patch out the stripping. Apparently it's a hassle for everybody and admittedly it belongs in a target such as install-strip. Use CMake I'm...
-
Can you elaborate on that? @Onsemeliot: if this was a public chat could you link to it, in case Kevin doesn't return to post here?
-
physfs_seek: minor improvement to code understandability
-
fixed PhysFS/SDL RWops code in accordance to the official docs
-
@Emanuele: no worries, every C++ programmer makes this mistake at least once in life, I did too.
-
fixed compilation errors in debug build
-
@Onsemeliot: I actually think I never hear the upshifting but often the downshiftig. This is a combination of two problems: The gear shift sounds are too low volume compared to the rest of the sounds. A code bug causes the gear shift be lost. Problem #1 is fixed by editing your trigger-rally-0.6.7.config file and changing audio volumes: <audio enginevolume="0.1" sfxvolume="1.0" codrivervolume="1.0" /> Problem #2 was circumverted in [r951]. I couldn't see why the engine changes gears without updating...
-
added shiftup sound effect for all gear shifts
-
Wouldn't it have been easier to just fix the data types? It was easier to "fix" the commit by reverting it entirely.
-
I have reverted these changes in [r950] considering 6 days without a response.
-
reverted r949: do not pass built-in types such as float and int by reference
-
Emanuele, regarding your commit [r949]: in some places you have passed float by const reference instead of value, as in: void function(float arg); void function(const float &arg); Unless you have measured performance benefits, please undo these changes: it is agreed[1][2][3] that there is no benefit in passing built in types (such as int, float, double) by reference instead of by value. The code merely becomes uglier to read and potentially more annoying to modify (what if we'd like to be able to...
-
Emanuele, regarding your commit [r949]: in some places you have passed float by const reference instead of value, as in: void function(float arg); void function(const float &arg); Unless you have measured performance benefits, please undo these changes: it is agreed[1][2] that there is no benefit in passing built in types (such as int, float, double) by reference instead of by value. The code merely becomes uglier to read and potentially more annoying to modify (what if we'd like to be able to modify...
-
I actually didn't notice any difference. When the gears are changed there is a random chance shiftup.wav or shitdown.wav will be played. The problem is the engine sound is loud while the shift sounds are quiet so it's hard to hear them. Perhaps they should be normalized? EDIT: looked at the code again and it's not a randomized event, yet for some reason sometimes it's completely inaudible.
-
I actually didn't notice any difference. When the gears are changed there is a random chance shiftup.wav or shitdown.wav will be played. The problem is the engine sound is loud while the shift sounds are quiet so it's hard to hear them. Perhaps they should be normalized?
-
[Patch] Upshift/downshift sounds
-
Patch applied in [r946], thanks.
-
I decided to apply Bruno's patch as-is, in [r946].
-
applied the gear shift sfx patch by Bruno
-
I will test the shifting sounds as soon as possible. The Upshift/downshift patch requires the following data changes: Add shiftup.wav and shiftdown.wav Remove gear.wav Update DATA_AUTHORS.txt The two new .WAV files are released under CC0: Files: shiftup.wav shiftdown.wav Copyright: 2019, Bruno Kleinert <fuddl@debian.org> Comment: Edited bang_05.ogg, © 2019 rubberduck Downloaded from https://opengameart.org/content/25-cc0-bang-firework-sfx License: CC0/Public Domain I would consider the weedwhacker...
-
Onsemeliot could you look into the Upshift/downshift sounds patch and confirm that credits and licenses used would be OK for Trigger Rally? I've tried it out and it sounds good enough, though the effects could be made a bit louder. Other than this I'd like to simplify the code, if possible. I believe I've made this list once before but here goes: Remove FMOD and OpenAL/ALUT dependencies. Reimplement codriver to not use C++11 threads. Unify makefiles into one. I could think of a couple of other things...
-
Please allow the user to add LDFLAGS
-
PhysFS 2.0.3 build on Windows 64-bit error
-
TR 0.6.4: GCC 5+ can't compile "hiscore1.h"
-
[patch] FTBFS with recent glew
-
Add a swatch to choose tinyxml2 version
-
updated files for release 1.0.1.8
-
I don't know if the feedback of the first command is a seroius problem No, it's not a serious problem. I'm a bit surprised g++ 7.4.0 didn't report it to me. So on my system reading the zipped file seems to be faster too: Looking good. Could you run the tests three times each please (3 data.zip then 3 uncompressed)? The results shouldn't change a lot but I'd like to see. Also, out of curiosity, what filesystem are you using? Ext4?
-
Ever since TR 0.6.4, the game data has been distributed in a zero-compression .ZIP archive because I "felt" it improved loading performance. This was not an original idea of mine: I have seen other games using this technique before: concatenating all files into a big file for a performance benefit. That said, I never liked that this idea wasn't properly verified. So today I wrote a utility to actually do that, DataPerfTest. Attached to this post is the source code (C++) and its build scripts. You...
-
Less than a minute to check all maps isn't so bad from my point of view. One minute? I am amazed. On my system (Windows+MSYS2) it takes 30 minutes to check all maps. With the less refined version it took 35 minutes. Maybe it's because I use an emulator instead of true Linux...
-
@Onsemeliot: nice, the fact that only 4 maps had to be corrected shows how diligent you are. The scripts are available in their devkit folder. I made small changes to improve code quality (for example input files are now sorted to make following progress easier) but the scripts still run as slow as snails. That said, the performance is not really a problem. From now on you won't need to run them for all data, just specifically for new maps you add, like so: $ checktex data/events/newevent/ data/maps/newmap/newmap.level...
-
@Onsemeliot: nice, the fact that only 4 maps had to be corrected shows how diligent you are. The scripts are available in their devkit folder. I made small changes to improve code quality (for example input files are now sorted to make following progress easier) but the scripts still run as slow as snails. That said, the performance is not really a problem. From now on you won't need to run them for all data, just specifically for new maps you add, like so: $ checktex data/events/newevent/ data/maps/newmap/newmap.level...
-
I've completed the codriver notes checking script. It will check the notes for unknown tokens. Just like CheckTex, this script it will scan for .LEVEL files in the current directory where it's run, or you can feed it directories/files by hand. Options: Option Effect -v enable verbosity Example usage (outputs omitted): $ ls bin checkcdnotes.sh data doc src $ ./checkcdnotes.sh $ ./checkcdnotes.sh data/maps/alignster/alignster.level $ ./checkcdnotes.sh data/events/01-triggercup/ --verbose I have not...
-
bumped version to 0.6.7
-
@Onsemeliot: yes, I'll do it. @Emanuele: 0.6.6.1 was a very minor release, let's look forward to 0.6.7. There are already some interesting things to investigate: fix camera code such that Fox center of mass can be moved back (add camerapos to .VEHICLE's?) apply the engine misfire sound patch
-
This way I discovered I used a wrong extension for the sky texture in the leaves map. You may need to update the screenshot "ss.png" for it as well, if the new sky is different. (I corrected that in r943.) Formatting reminder: if you want to link to a revision, simply put it in square brackets: writing [r943] turns into [r943] automatically. Would it be easy to check if all codriver commands are covered by samples and icons also? Easy probably not, but I'll try it. Checking codriver notes is more...
-
This way I discovered I used a wrong extension for the sky texture in the leaves map. You may need to update the screenshot "ss.png" for it as well, if the new sky is different. (I corrected that in r943.) Formatting reminder: if you want to link to a revision, simply put it in square brackets: writing [r943] turns into [r943] automatically. Would it be easy to check if all codriver commands are covered by samples and icons also? Easy probably not, but I'll try it. Checking codriver notes is more...
-
Version 4 is available and this one can handle spaces in file paths. It fixes a couple of mistakes and removes some bashisms from the previous version: changed $(pwd) to $PWD added double-quotes to certain variables, such as #@ bashism removed: local variables bashism avoided: printf -v VAR bashism avoided: <<< "HereString" There may still be "bashisms" that I missed. Bashisms, (as they are described here), need to be avoided to keep the script compatible with Unix-like systems that don't use BASH....
-
or by using quotes (in scripts) for strings that should be path names The problem is that adding quotes doesn't work in this case. After I searched SO again I've seen two interesting possible solutions: Use the IFS variable to ensure the separator is newline instead of space. link Use the read program. link Of course if there is a better way, I'd like to know. I don't want to give the impression that I'm overestimating the worth of the CheckTex utility. This is more a case of wanting to perfect it...
-
@Simone: thanks. I didn't realize line endings could be a problem. I'll make sure my other scripts have LF line endings as well. A new problem I found (it is annoying but not critical) is that the script fails to process file paths with spaces in them. For example if "data/maps/race 1/race 1.level" exists it will be processed as: grep: ./data/maps/race: No such file or directory grep: 1/race: No such file or directory grep: 1.level: No such file or directory I tried looking for solutions on StackOverflow...
-
For clarity, what I refer to as a "Release Candidate" is a file that, if all tests are OK, will be released officially as-is, without modification. The relevant 0.6.6.1 files have been uploaded to FileConvoy, listed below are the download links and checksums. Download link: http://www.fileconvoy.com/dfl.php?id=g6779b14261ebcf461000153055a55620077d71e3f0 NOTE: FileConvoy renamed ".EXE" extensions to ".EX_" probably as a security measure. SHA-256 checksums: 7f086e13d142b8bb07e808ab9111e5553309c1413532f56c754ce3cfa060cb04...
-
updated docs for 0.6.6.1 release (again)
-
Version "2" is available with minor code quality improvements. Changes: renamed --rootdir to --datadir to make its meaning more obvious: this option is used to specify where to look for textures (which aren't local to the map) removed --scandir and added ability to scan any number of given directories (see examples) Example usage: $ ls bin checktex.sh data doc src $ ./checktex.sh --verbose data/maps/old/ data/maps/alignster/alignster.level DataDir=/c/WORKDIR/trigger-rally-0.6.6.1/data data/maps/old/oldbis.level...
-
Considering the recent problem of missing textures fixed by [r937] and [r938], I decided to write a texture checking script. It can be used simply by copying it next to the /data/ folder and running it, in which case it checks all .LEVEL files, but it also has finer options for specifying .LEVEL files individually and the data root directory (called "root directory" in script). Options: Option Effect -v enable verbosity (default is silent except problems) -r set data root directory (default is "./data")...
-
removed TinyXML source from the game code
-
@Emanuele: good to hear. The Debian packagers will be happy about this change, they've been patching out the included TinyXML since forever.
-
There's another possibility: perhaps g++ prefers to link against dynamic libraries. What this means is that it can see /usr/local/lib/libtinyxml2.a (which is static) but then when it sees e.g. /usr/lib/i386-linux-gnu/libtinyxml2.so (which is shared) it prefers the shared version, which is version 4, and tries to use it, and fails. The possible solution to this is rebuilding and reinstalling your downloaded TinyXML 7 as a shared library instead of the default static type. For this you will need to...
-
@Onsemeliot: your problem now looks like a linker error. Meaning that g++ is trying to use the wrong tinyxml library, in particular it may try to use either of: /usr/lib/i386-linux-gnu/libtinyxml2.so /usr/lib/x86_64-linux-gnu/libtinyxml2.so instead of the new /usr/local/lib/libtinyxml2.a According to this help topic on SF you could try a couple of possible fixes: Update the LD_LIBRARY_PATH variable before running make. Use LD_RUN_PATH instead of #1 because setting that path is bad practice. Edit...
-
@Onsemeliot: your problem now looks like a linker error. Meaning that g++ is trying to use the wrong tinyxml library, in particular it may try to use either of: /usr/lib/i386-linux-gnu/libtinyxml2.so /usr/lib/x86_64-linux-gnu/libtinyxml2.so instead of the new /usr/local/lib/libtinyxml2.a According to this help topic on SF you could try a couple of possible fixes: Update the LD_LIBRARY_PATH variable before running make. Use LD_RUN_PATH instead of #1 because setting that path is bad practice. Edit...
-
@Onsemeliot there's another option for installing TinyXML-2 version 7: build it from code. Download latest version from https://github.com/leethomason/tinyxml2/releases Unpack and run make; make install. According to its Makefile, by default, it install itself in /usr/local/ and therefore shouldn't conflict with libtinyxml2-dev packages. And if I remember correctly, /usr/local/ should take precedence. /usr/local/bin/xmltest /usr/local/lib/libtinyxml2.a /usr/local/include/tinyxml2.h This way you don't...
-
@Onsemeliot there's another option for installing TinyXML-2 version 7: build it from code. Download latest version from https://github.com/leethomason/tinyxml2/releases Unpack and run make; make install. According to its Makefile, by default, it install itself in /usr/local/ and therefore shouldn't conflict with libtinyxml2-dev packages. And if I remember correctly, /usr/local/ should take precedence. /usr/local/bin/xmltest /usr/local/lib/libtinyxml2.a /usr/local/include/tinyxml2.h This way you don't...
-
@Onsemeliot there's another option for installing TinyXML-2 version 7: build it from code. Download latest version from https://github.com/leethomason/tinyxml2/releases. Unpack and run make; make install. According to its Makefile, by default, it install itself in /usr/local/ and therefore shouldn't conflict with libtinyxml2-dev packages. And if I remember correctly, /usr/local/ should take precedence. /usr/local/bin/xmltest /usr/local/lib/libtinyxml2.a /usr/local/include/tinyxml2.h This way you...
-
@Onsemeliot: if your build error above persists it probably means you have libtinyxml2-dev version 4, meaning you're still running Debian Stretch. In that case, I'm sorry but you have to upgrade to Debian Buster or otherwise somehow get libtinyxml2-dev version 7.
-
@Onsemeliot: sorry for not giving more detail in my previous post. For future reference, full instructions about how the patch is applied (if one doesn't want to use the attached .ZIP): $ # $ # the .PATCH file must be inside your trigger-rally [r939] folder $ # $ basename `pwd` trigger-rally $ ls bin data doc remove_tinyxml.patch src $ patch -p0 -i remove_tinyxml.patch patching file src/GNUmakefile patching file src/GNUmakefile.MSYS patching file src/GNUmakefile.MSYS64 patching file src/include/pengine.h...
-
@ Simone and other Linux users: please try building the attached code. It removes TinyXML from the Trigger Rally tree and links the library dynamically on both Windows and Linux. I am interested to read if there are problems with it on Linux. I have provided a .PATCH file to be applied to [r939] but also a .ZIP of the resulting src folder. If you are applying the patch make sure to delete: src/TinyXML2/ folder src/include/tinyxml2.h file This patch also modifies the GNUmakefile's, because I've run...
-
@ Simone and other Linux users: please try building the attached code. It removes TinyXML from the Trigger Rally tree and links the library dynamically on both Windows and Linux. I am interested to read if there are problems with it on Linux. I have provided a .PATCH file to be applied to [r939] but also a .ZIP of the resulting src folder. If you are applying the patch make sure to delete: src/TinyXML2/ folder src/include/tinyxml2.h file This patch also modifies the GNUmakefile's, because I've run...
-
This is a nice improvement. The sounds probably should be made a bit louder. I think this patch can be added to release 0.6.7. I'm currently preparing 0.6.6.1 but this release is meant only as a refurbishing of 0.6.6, with optimized data and Windows binaries.
-
I don't think fixing this problem by moving the center of mass forward again is the best one. Agreed. However, until the camera code is fixed, I rather have worse handling in cars than broken camera. (Additionally I noticed the Fox view was broken in the car selection screen as well.)
-
What is the current motivation to have a separate copy of tinyxml2 instead of make it a requirement for the user to have it installed, like it is required for example for SDL2? There isn't a strong motivation: TinyXML invites using tinyxml2.cpp and tinyxml2.h directly: "Simply compile and run." and this is how it was done in previous versions of Trigger Rally so far. Maybe the most important benefit of using TinyXML code directly is that we don't have to worry about breakage from different TinyXML...
-
Foxcar: graphic error
1 >
