The attached patch adds a feature that enables the player to compete against a ghost car. The ghost car is a replay of the fastest completion of a track by the player himself. This way the player is able to improve his or her times while having a direct visual at his or her fastest lap. The ghost runs are stored in separate files in the settings directory of Trigger Rally. Right now the feature must be activated through a new option in the configuration file (enableghost). Maybe this option can be removed later once the ghost car feature is proven in use or further integrated into the game.
Next steps to further improve the feature could be to display the ghost times in the upper left corner or the position of the ghost car on the map. One more point is to integrate the feature into the game menu, e.g. the time of the ghost could be highlighted in the highscore list or the feature could be directly enabled through the menu.
Oh, I didn't expect that. Doesn't this feature need much more performance and seriously increase the needed storage space?
Anyway, when I tested it I didn't notice any performance problem at all. And it worked perfectly on the map "Alingster" instantly. But when I tested it on "Duned" there are no ghost car.
After re-booting the game I however could generate a ghost car for "Duned" but not the second map I tried. Therefore, I suspect something in your code hinders the recording of new ghost cars for more than one map in each session. Can you confirm that?
Last edit: Onsemeliot 2020-10-22
I can confirm that issue. The attached patch contains a fix. The patch also contains a completely separate feature that enables support for joystick or gamepad vibrations when the vehicle hits an obstacle or drives through grass or bushes. I tested it with my XBOX 360 gamepad as this the only device I have. Would be interesting to know how it behaves with other devices. I worked on that feature in parallel and it was difficult to keep it apart as I do not have SVN access.
I set the sampling of the ghost car data to 100ms to limit the disk space and RAM required for the storage files. Right now, one minute of recording should take a little more than 200kB. I also did not notice any impact on performance. I can still run the game at up to 60 fps even with my Intel graphics card.
I tried to reverse your last patch by using "svn patch --reverse-diff ghost.patch" and it seemed to work. Then I ran your new patch and built the game again. Afterwards I couldn't load any map since the game crashed each time I selected a car. Then I pulled a fresh r994 from the server and applied your patch again. After applying your most recent patch building failed each time with:
I needed to return to r994 in order to build the game again.
I guess could somehow give you SVN access. But so far I didn't have the impression I slow you down. And I suspect to have at least an other testing system before we commit something isn't all that bad. Or do you feel it is very annoying to not have commit rights yet?
One reason for the compile issue could be, that the "bin" directory in the "trigger-rally-code" directory is missing. Maybe you deleted it accidently. Another reason could be, that your user does not have access to the "bin" directory or the files inside. Maybe the ownership was changed to "root". That can hapen, if you run "make" as "root" at least once.
You are absolutely not slowing me down :-). I totally value you as a source of feedback and a tester of my implementation changes. You did a very good job by detecting a couple of issues. I want to thank you for all the valuable (and very quick) feedback and support.
No, the directory is definitely there and my user has all rights too. And the problem only occured after I applied your last patch. Returned to r994 everything works fine again. So I see no other option: Somehow the patch must cause the issue.
Now I tested it once more. Everything worked fine with r994 and after applying your last patch I get the same error again:
And after returning to the unpatched "src" directory and "bin/trigger-rally.config.defs" file once more everything works fine again.
I can see, that from your compile log, that the "Trigger/ghost.o" file is not generated. It looks like the "Trigger/ghost.cpp" file is not compiled.
Did you perform "make clean" before "make"? Did you manually delete the files "Trigger/ghost.o" and "Trigger/ghost.d", if they are still present after "make clean"? Can you check whether the file "Trigger/ghost.cpp" is existing after applying the patch?
The messages below are also quite strange. They do not occur in my case. Are these relative directories present from the view of your "src" directory?
/bin/sh: 1: cd: can't cd to ../data
/bin/sh: 1: cd: can't cd to ../doc
This is my compile output:
I definitely do use "make clean" before attempting any new build. And "Trigger/ghost.cpp" is definitely present after applying your patch. But I did not check if "ghost.o" was created (or deleted). And I definitely have the "data" and "doc" directories (on the same level als the "src" folder).
Now I applied your patch to a (fresh and working) r994 once more and unfortunately I came to the exact same result as before. When I try to build the game with the error quoted below it creates no ".o" files at all. Therefore, in this case I also get no "Trigger/ghost.o" or "Trigger/ghost.d".
If I build the game (successfully) before applying your most recent patch then I get the following output:
I attached another version of the patch that fixes a crash, if a joystick is activated in the config file, but no joystick is actually connected to the computer. However, I assume this will not fix your compile issue.
I also checked out another copy of the repository and applied the patch. I could compile and play the game. Can you please send the output of "svn status" before and after applying the patch? Maybe there are some leftover files in your local directory that influence the patching process. Can you also share the output of the "svn patch" command?
The command "svn status" didn't produce any output with the clean r994.
The output of the patch command:
"svn status" after applying the patch:
The output of the "make" command directly afterwards:
Building the game finally worked again. And the ghost cars did behave like intended as long as I tested it.
Are you aware of the role of the player files and what happens if one system has different payer files? Get new ghosting races stored for each player profile?
It is great that the new patch is working!
The ghost files are completely independent of the player files. First I thought of having separate ghost files for each player, but then I thought, that it would be fun to race against the ghosts of other players. If you switch the player, you will race against the same ghost files as with the previous player. In theory you could even copy the ghost files between different systems and OS users. I think the player switching is hardly ever used by anyone, as this option is not offered in game and the user has to to modify the config file for this purpose.
I agree with the impression that using different player files is probably not very common. And I also consider features only accessible via adjustments in the config files without being exposed in an in-game menu rather unlikely to be used by the majority of the (probably not so many) players of Trigger Rally.
Last edit: Onsemeliot 2020-10-28
Thanks Martin for your work lately! Ghost races and advanced collisions are both feature I wanted to implement and done some preparatory fix but never got skill and time to complete them.
Great!
You are welcome! :-)
Right now I am trying to improve the vehicle physics, especially the way the various forces are applied to the wheels. My primary goal is to get rid of the magic values used in the calculations (e.g. FRICTION_MAGIC_COEFF_WHEEL or WHEEL_SPIN_VEL_UPDATE_RATIO). However, it looks like this one will finally blow my mind. Each attempt to replace the values by some proper physical calculations leads to kind of odd driving behavior. If you have some experience to share with this part of the code, please let me know. Maybe this can help me a little bit.
Yes, further improvng the physics would be great. On my new map I encountered the problem of odd side gliding at higher speeds on tarmac again. This might be possible to solve with the fin pressure attribute but I am uncertain since all my tewaking didn't lead to something very good with the Fox car yet.