Since I don't have a windows system available for testing, could you please write the compiler error so I can try to work it out? Do you think is my commit to cause the issue?
No: the problem is with my tools and the libraries and not with your changes (I should have been specific in my previous post). Still trying to build it right now.
Regarding PhysFS, for the Win release version I prefer to use the latest version of libraries (with some exceptions such as FMOD). Thus I tried using PhysFS 3.0.1 and I got a lot of deprecation warnings. Just curious, what version of libphysfs-dev or physfs-devel do you have installed in your Linux?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I am embarrassingly stuck at building the SDL2 and SDL2_image libraries. I cannot build them by using their included configure script due to lack of support for MSYS2. While SDL2 can be built (correctly?) using CMake, SDL2_image does not have CMake files and its own configure script is incompatible with the CMake output (including library filenames apparently).
I've started a thread on the official "forum" of SDL about this, so far no replies. Unless I get help, I'll have to write my own CMake file(s) for SDL2_image tomorrow.
Finally, I managed to build it after tinkering the configure.in and configure scripts of SDL2 and SDL2_image. The problems are that:
SDL2 fails to correctly detect the mingw32 library thereby adding an -lcygwin dependency, causing SDL2_image to fail build, and once that's fixed...
SDL2_image fails to correctly detect the jpeg library, the game being unable to load JPEG files.
@Emanuele: do you have experience working with GNU Autoconf and Automake? I would need some guidance how to cleanly fix the scripts in the SDL2 libraries as opposed to butchering them with commented-out lines of code.
Also what are the plans for 0.6.6: Emanuele do you have ideas for new features? Should we wait for new cars to be made?
As for me I'm willing to look into the PhyFS deprecated code messages, however if I fix them you may not be able to build the game anymore Emanuele. Are you ready to use the new version of the PhyFS library?
Last edit: Andrei 2017-11-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also what are the plans for 0.6.6: Emanuele do you have ideas for new features? Should we wait for new cars to be made?
As listed there are some new maps, events and vegetation textures that could be nice in a new version but I would love to have new vehicles in the game very much. Unfortunately I still didn't manage to get things done with Blender to create them myself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Onsemeliot: thank you for your new maps but I think other features are needed before 0.6.6 is release-worthy. Have you tried contacting Joshua Pagnola for guidance using Blender?
The main "problem" with this game is its outdated graphics. If we could have year 2000-2005 level graphics it would be a huge boost. I am envious of other projects such as Stunt Rally that look beautiful compared to ours. This is a failure that words alone cannot fix so I will stop lamenting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Andrei. I am happy that you got to solve your compiling issues. Sadly I have no experience at all with Autoconf and Autotools.
About phyfs, for me it's not a problem, you can update it.
About new features I was experimenting with multi-car races, and this is what I found:
It's possible to successfully spawn any number of different cars at the start of the race, the game proceed without problems. Each vehicle has its own time counters (after [r873]) but the race will use the ones of the user car. Each car has also its own correct physic, stats...
Using the current implemented impact detection code is not possible to compute impacts between vehicles (or any object such as trees or whatever) without major tweaks or a whole rewrite. At the moment the various vehicles will pass throught each others.
So I think the way to start working on some multi vehicle race with the least possible work is implement mirror races. What is needed as new code is a logger which saves position of the car K times each seconds, a car updater which moves the car following that path, optionally some graphic stuff to make things clear (Maybe a text above the car specifying what is each car) and probably some glue code. That's it. I think would be great racing against your past self, or racing against other players records.
What do you think of this idea?
@Onsemeliot: thank you for your new maps but I think other features are needed before 0.6.6.
All right. I don't argue against that.
Have you tried contacting Joshua Pagnola for guidance using Blender?
If I remember correctly some months ago I asked Joshua for a little guide, but I still can't do it. Time is the limiting factor for me so far. I think I should be able get to a point where I actually can create new cars but I just can't find enough time to get into it enough.
[Race against a ghost best time ...] What do you think of this idea?
I expect many people would like to use such a feature. Nevertheless, I have to admit I never was a fan of this feature in other games.
The main "problem" with this game is its outdated graphics.
I guess this is nothing we can change right now. If we would like to have a game that works (and looks) like other recent games it probably needs to be written from scratch. Trigger Rally may look outdated but in my opinion it looks surprisingly well for what technologies it uses. After all the basic code is rather old. And the advantage is that it still works on very old systems. We can't compete with games developed for newer hardware but it is probably interesting for those about 10 years old computers still around and working.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Emanuele: I am in favor of your ghost car idea. The ghost data files will be saved in the player's directory and the entire feature must be disableable from the game configuration trigger-rally-0.6.6.config in case the players don't want it (e.g. for performance reasons).
@Onsemeliot:
I guess this is nothing we can change right now. If we would like to have a game that works (and looks) like other recent games it probably needs to be written from scratch.
Yes, it would need to be written from scratch, especially because other components/engines would be used. It would be nice to know on what computers Trigger Rally is most often installed (old or new).
EDIT: fixed formatting mistake.
Last edit: Andrei 2017-11-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I created an alternative paintjob for the Delta but ran into some issues because on the roof and in the back the textures get in some areas rather distorted when projected on the mesh. I tried to compensate for that and basically avoided to much detail in those areas.
My main reasoning was that with the plain white sides the odd triangle shadows where rather explicit. The darker blue with some dirt and other detail distract from those weird shadows.
Maybe the longer loading time for the delta comes not only from the additional surfaces but from the fact that the texture is much bigger than those from the other cars. (A 4096 pixel square instead of only 1024 pixel. I didn't alter this resolution since then probably all positions of the projection would get messed up.)
Is there a desire to release 0.6.6 this year instead of 2018?
@Onsemeliot: I suppose you wish the Delta car to be added to the official distribution (unlockable? unlocked?) instead of being made a plugin? (I haven't tested it yet.) Is it really worth it using a 4096x4096 resolution texture for it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would love to include the Delta in the regular game files but I think it would be possible to get the file size much smaller by altering the mesh and shrinking the texture image without loosing any visible details. I suspect it would even improve the shadowing if we would use less vertices ... at least in some areas. Unfortunately I still don't know how to export changes properly to end up with .obj files we can actually use in Trigger Rally.
If I was able to create usable meshes we would certainly have at least some new cars by now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Emanuele: I've played the "Jumpy" map on the latest revision and I have seen that the car still behaves erratically after landing a big jump.
Can you look into this physics (?) problem and say if you can fix it or not, please? I suggest you play "Jumpy" because it's the map that best shows the problem, which appears to be a combination of: (1) exaggerated springing effect after rough landing and (2) full grip of tires at any angle of roll.
@Onsemeliot: I have noticed that some maps have codriver note mistakes. For example "Keeper" misspells "right" as "rigt", and another map which I cannot remember has the codriver mix up left and right in a turn.
Instead of asking you to spend (possibly a lot of) time verifying and correcting the codriver notes for these new maps, I'll ask you something else: would it be worth it to code a dedicated map creator utility? Because you would probably be the only person on this planet using it, while programming it would be a monumental yet worthless task for me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Andrei
Yes, I haven't modified much the physics engine code yet. I have documented it to be able to understand it and modify it in the future, and I have reorganized it. But I haven't actually make any big change yet. But I isolated two problems that cause in my opinion many of the most discussed physic problems:
Wheels: the contact point of the wheel with the ground is positioned just straight down the center of the wheel, actually the lowest point of the wheel depends on the inclination of the car. This cause that you see the wheel touching the ground in one point, the physic engine actually considers the contact point another point. In the worst possible situation (car rolled of 180 degrees) the distance between the real and the assumed contact point is equal to 1.41 times the radius of the wheel (very much imo!).
What I have done to solve this issue: I wrapped in a function the engine calculation of the contact point of a wheel (there were some spread in the sources), so we can fix that there once. But actually I haven't got to fix that yet because to compute the inclination of the car I need to deal with quaternions and matrices, and it's hard.
This issue causes:
1) when the car start flipping or only two wheels are touching the ground, thus accuracy in handling the car is very important, this bug causes imprecisions and not realistic physic.
2) when the car enters an inclinated turn, or even more in a half-pipe road the car gets very unstable
3) The dust trail doesn't start in the right point
Clutch: looking at the code, I see no explicit refer to any clutch. In the symbolic model of the car engine, the engine torque output is directly connected to the gearbox which is directly connected to the wheels. No clutch. I have no idea how other games handle clutch, how could be a good solution to implement a clutch, or if other games have a clutch at all. I think that might be a cause for severe irrealistic behaviour of the car, and fixing that can make the simulation more realistic. What do yous think about it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Emanuele: I would very much like 0.6.6 to have improved physics with your help, and fortunately we're not under pressure to hurry with it (such as with 0.6.5 to meet the Debian freeze deadline).
Clutch: looking at the code, I see no explicit refer to any clutch. In the symbolic model of the car engine, the engine torque output is directly connected to the gearbox which is directly connected to the wheels. No clutch.
From what I remember there is no reference to Neutral gear either.
My personal reasons for wanting these fixed (clutch, neutral) has less to do with realism and more with gameplay: too many other racing games start the car automatically after the 3...2...1...go countdown, making the countdown completely pointless.
By contrast other games (such as Network Q Rally Championship from 1996) let the player put the car into first gear manually during the countdown: if the player "cheats" he will be punished for a false start with a time penalty. This makes things more exciting than merely waiting for the countdown to end. Of course if the time penalty is too high the player will just be annoyed and restart the race, so that must be avoided.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Keeper" misspells "right" as "rigt"
Thanks. I corrected that.
another map which I cannot remember has the codriver mix up left and right in a turn.
Was ist one of the newer maps?
would it be worth it to code a dedicated map creator utility?
Sorry for my occational erros. I don't feel the need for an editor. Of course that depends on how it would work. But my process of creating maps is rather complicated and variies quite a lot. I use different filters and edit many parts of the maps by hand very often in GIMP at different stages. Creating an editor giving only remotely similar liberties might be a daunting task. Jareiko created a map editor for the Javascript version of Trigger Rally. This resulted in many very bad maps because lots of people tried what they could do with it but obviously didn't want to spend much time with it.
I expect your valuable time would be of greater benefit for more people if you work on features for players like an improved menu (getting rid of the code you find very confusing and unnecessarily limiting). I will start a new discussion for a small proposal that might work with the old menu code but is possibly much easier to do with a new menu ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I corrected some cars that were available in the game, and I also noticed that they were reduced in the scale by about 1/3, which made very poor handling of car. By increasing the scale to 1:1 cars began to work more adequately, I was also able to achieve that rear-wheel drive cars begin to drive more adequately. Back drive I made Evolution because in reality, only this car can have a rear drive, not a small focus. I added some other old models to the model range and made them more adequate in characteristics. I added to custom cars and the car from this forum, realistic scale, and gearboxes, as in real cars. I have show all cars what i have in this short video: https://youtu.be/atZb8RRMHYs
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you so much for working on these optimisations. Originally we just made different versions of cars (with only different textures) because we didn't have other models available. Of course it would be more fun and interesting to actually have different cars that naturally would have different behaviour and attributes. We would only need to group them sensibly into our three categories.
But I fear you are working with very old code. Didn't you pull our newest development version from the git instance as a base for your much appreciated work? In your video I see that you are still using the version without a collision model for our vegetation sprites. Would it be easy for you to migrate your improvements to our most recent code base without running into trouble there? We even do have a new version of core components. Therefore, I fear your alterations might not be easily reproducible in our most recent development version. And since I am not a developer myself, I can't resolve this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have installed newer code game, but i dislike that in game removed the hood camera view. That make useless my work around a camera position from cockpit. It would be better to move cameras from mass center a little more, as example hood camera need to move up and back on old code version, side camera need to move a little more to right, periscope camera move a lot to back to make it as helicopter camera on back of a car. I have found how to fix problems with mass center in old version and can use big truck with hood camera inside cabin. In new version changing of position parameter is useless, because no car in hood camera view.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry to read that. If I remember correctly, I think Andrei changed the camera positioning to overcome an other issue. I can vaguely remember it had something to do with the physics that depended on the camera positioning, probably because the mass centre of the vehicles is actually attached to the same point. But unfortunately I can't quite remember if that really was the problem. The discussion is for sure somewhere here in the board. Is it hard to just add an other camera as hood view again? I think we didn't mind removing it because nobody of us did use it anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes! Camera position attached to mass center. I can solve this problem in old version by this parameters:
ctrlparams
drag="20.0, 20.0, 20.0"
lift="0"
fineffect="100"
but they decrease car characteristics. Next problem is gearboxes. I'm really not understand how to simulate them? In real car gear box have such parameter:
Main gear: 4.103
1 gear: 4.148
2 gear: 2.369
3 gear: 1.556
4 gear: 1.155
5 gear: 0.859
6 gear: 0.686
R gear: 3.394
As I understand in Trigger Rally 1 gear = R gear, OK. But next problem is that gearbox in Trigger Rally have max gear is 1.0 (if last gear value >1 it switch to next gear) and lower values will never switch. And I don't understand non-sense parameter absolute=0.025 or near.
So I take such formula: (gear+maingear)/(maxgear+maingear)
Last edit: Eugene MC 2024-02-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I fear I can't help with interpreting the code. But has the code changed so much that you can't figure out how you could get a hood cam in it? Maybe we should reach out to Andrei and ask him. I think he is still involved in other projects here on Source Forge. Did you already check out the readme file and the commit history for hints what his changes were?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No: the problem is with my tools and the libraries and not with your changes (I should have been specific in my previous post). Still trying to build it right now.
Regarding PhysFS, for the Win release version I prefer to use the latest version of libraries (with some exceptions such as FMOD). Thus I tried using PhysFS 3.0.1 and I got a lot of deprecation warnings. Just curious, what version of libphysfs-dev or physfs-devel do you have installed in your Linux?
Makes sense, I still have libphysfs 2.0.3. The 3.0.1 version is not in the stable repos yet.
Well, I am embarrassingly stuck at building the SDL2 and SDL2_image libraries. I cannot build them by using their included configure script due to lack of support for MSYS2. While SDL2 can be built (correctly?) using CMake, SDL2_image does not have CMake files and its own configure script is incompatible with the CMake output (including library filenames apparently).
I've started a thread on the official "forum" of SDL about this, so far no replies. Unless I get help, I'll have to write my own CMake file(s) for SDL2_image tomorrow.
https://discourse.libsdl.org/t/sdl2-and-sdl2-image-build-incorrectly-when-using-msys2/23365
Finally, I managed to build it after tinkering the configure.in and configure scripts of SDL2 and SDL2_image. The problems are that:
-lcygwindependency, causing SDL2_image to fail build, and once that's fixed...@Emanuele: do you have experience working with GNU Autoconf and Automake? I would need some guidance how to cleanly fix the scripts in the SDL2 libraries as opposed to butchering them with commented-out lines of code.
Also what are the plans for 0.6.6: Emanuele do you have ideas for new features? Should we wait for new cars to be made?
As for me I'm willing to look into the PhyFS deprecated code messages, however if I fix them you may not be able to build the game anymore Emanuele. Are you ready to use the new version of the PhyFS library?
Last edit: Andrei 2017-11-10
As listed there are some new maps, events and vegetation textures that could be nice in a new version but I would love to have new vehicles in the game very much. Unfortunately I still didn't manage to get things done with Blender to create them myself.
@Onsemeliot: thank you for your new maps but I think other features are needed before 0.6.6 is release-worthy. Have you tried contacting Joshua Pagnola for guidance using Blender?
The main "problem" with this game is its outdated graphics. If we could have year 2000-2005 level graphics it would be a huge boost. I am envious of other projects such as Stunt Rally that look beautiful compared to ours. This is a failure that words alone cannot fix so I will stop lamenting.
@Andrei. I am happy that you got to solve your compiling issues. Sadly I have no experience at all with Autoconf and Autotools.
About phyfs, for me it's not a problem, you can update it.
About new features I was experimenting with multi-car races, and this is what I found:
It's possible to successfully spawn any number of different cars at the start of the race, the game proceed without problems. Each vehicle has its own time counters (after [r873]) but the race will use the ones of the user car. Each car has also its own correct physic, stats...
Using the current implemented impact detection code is not possible to compute impacts between vehicles (or any object such as trees or whatever) without major tweaks or a whole rewrite. At the moment the various vehicles will pass throught each others.
So I think the way to start working on some multi vehicle race with the least possible work is implement mirror races. What is needed as new code is a logger which saves position of the car K times each seconds, a car updater which moves the car following that path, optionally some graphic stuff to make things clear (Maybe a text above the car specifying what is each car) and probably some glue code. That's it. I think would be great racing against your past self, or racing against other players records.
What do you think of this idea?
Related
Commit: [r873]
Just to be clear, if it turns out to be a valid idea I will work on it
All right. I don't argue against that.
If I remember correctly some months ago I asked Joshua for a little guide, but I still can't do it. Time is the limiting factor for me so far. I think I should be able get to a point where I actually can create new cars but I just can't find enough time to get into it enough.
I expect many people would like to use such a feature. Nevertheless, I have to admit I never was a fan of this feature in other games.
I guess this is nothing we can change right now. If we would like to have a game that works (and looks) like other recent games it probably needs to be written from scratch. Trigger Rally may look outdated but in my opinion it looks surprisingly well for what technologies it uses. After all the basic code is rather old. And the advantage is that it still works on very old systems. We can't compete with games developed for newer hardware but it is probably interesting for those about 10 years old computers still around and working.
@Emanuele: I am in favor of your ghost car idea. The ghost data files will be saved in the player's directory and the entire feature must be disableable from the game configuration trigger-rally-0.6.6.config in case the players don't want it (e.g. for performance reasons).
@Onsemeliot:
Yes, it would need to be written from scratch, especially because other components/engines would be used. It would be nice to know on what computers Trigger Rally is most often installed (old or new).
EDIT: fixed formatting mistake.
Last edit: Andrei 2017-11-10
I created an alternative paintjob for the Delta but ran into some issues because on the roof and in the back the textures get in some areas rather distorted when projected on the mesh. I tried to compensate for that and basically avoided to much detail in those areas.
My main reasoning was that with the plain white sides the odd triangle shadows where rather explicit. The darker blue with some dirt and other detail distract from those weird shadows.
Maybe the longer loading time for the delta comes not only from the additional surfaces but from the fact that the texture is much bigger than those from the other cars. (A 4096 pixel square instead of only 1024 pixel. I didn't alter this resolution since then probably all positions of the projection would get messed up.)
Last edit: Onsemeliot 2017-12-03
Is there a desire to release 0.6.6 this year instead of 2018?
@Onsemeliot: I suppose you wish the Delta car to be added to the official distribution (unlockable? unlocked?) instead of being made a plugin? (I haven't tested it yet.) Is it really worth it using a 4096x4096 resolution texture for it?
I am in no rush for the next release.
I would love to include the Delta in the regular game files but I think it would be possible to get the file size much smaller by altering the mesh and shrinking the texture image without loosing any visible details. I suspect it would even improve the shadowing if we would use less vertices ... at least in some areas. Unfortunately I still don't know how to export changes properly to end up with .obj files we can actually use in Trigger Rally.
If I was able to create usable meshes we would certainly have at least some new cars by now.
Sadly I have no experience and knowledge at all about 3D modelling, so in this field I can't help.
@Emanuele: I've played the "Jumpy" map on the latest revision and I have seen that the car still behaves erratically after landing a big jump.
Can you look into this physics (?) problem and say if you can fix it or not, please? I suggest you play "Jumpy" because it's the map that best shows the problem, which appears to be a combination of: (1) exaggerated springing effect after rough landing and (2) full grip of tires at any angle of roll.
@Onsemeliot: I have noticed that some maps have codriver note mistakes. For example "Keeper" misspells "right" as "rigt", and another map which I cannot remember has the codriver mix up left and right in a turn.
Instead of asking you to spend (possibly a lot of) time verifying and correcting the codriver notes for these new maps, I'll ask you something else: would it be worth it to code a dedicated map creator utility? Because you would probably be the only person on this planet using it, while programming it would be a monumental yet worthless task for me.
@Andrei
Yes, I haven't modified much the physics engine code yet. I have documented it to be able to understand it and modify it in the future, and I have reorganized it. But I haven't actually make any big change yet. But I isolated two problems that cause in my opinion many of the most discussed physic problems:
Wheels: the contact point of the wheel with the ground is positioned just straight down the center of the wheel, actually the lowest point of the wheel depends on the inclination of the car. This cause that you see the wheel touching the ground in one point, the physic engine actually considers the contact point another point. In the worst possible situation (car rolled of 180 degrees) the distance between the real and the assumed contact point is equal to 1.41 times the radius of the wheel (very much imo!).
What I have done to solve this issue: I wrapped in a function the engine calculation of the contact point of a wheel (there were some spread in the sources), so we can fix that there once. But actually I haven't got to fix that yet because to compute the inclination of the car I need to deal with quaternions and matrices, and it's hard.
This issue causes:
1) when the car start flipping or only two wheels are touching the ground, thus accuracy in handling the car is very important, this bug causes imprecisions and not realistic physic.
2) when the car enters an inclinated turn, or even more in a half-pipe road the car gets very unstable
3) The dust trail doesn't start in the right point
Clutch: looking at the code, I see no explicit refer to any clutch. In the symbolic model of the car engine, the engine torque output is directly connected to the gearbox which is directly connected to the wheels. No clutch. I have no idea how other games handle clutch, how could be a good solution to implement a clutch, or if other games have a clutch at all. I think that might be a cause for severe irrealistic behaviour of the car, and fixing that can make the simulation more realistic. What do yous think about it?
@Emanuele: I would very much like 0.6.6 to have improved physics with your help, and fortunately we're not under pressure to hurry with it (such as with 0.6.5 to meet the Debian freeze deadline).
From what I remember there is no reference to Neutral gear either.
My personal reasons for wanting these fixed (clutch, neutral) has less to do with realism and more with gameplay: too many other racing games start the car automatically after the 3...2...1...go countdown, making the countdown completely pointless.
By contrast other games (such as Network Q Rally Championship from 1996) let the player put the car into first gear manually during the countdown: if the player "cheats" he will be punished for a false start with a time penalty. This makes things more exciting than merely waiting for the countdown to end. Of course if the time penalty is too high the player will just be annoyed and restart the race, so that must be avoided.
@Andrei:
I expect your valuable time would be of greater benefit for more people if you work on features for players like an improved menu (getting rid of the code you find very confusing and unnecessarily limiting). I will start a new discussion for a small proposal that might work with the old menu code but is possibly much easier to do with a new menu ...
I corrected some cars that were available in the game, and I also noticed that they were reduced in the scale by about 1/3, which made very poor handling of car. By increasing the scale to 1:1 cars began to work more adequately, I was also able to achieve that rear-wheel drive cars begin to drive more adequately. Back drive I made Evolution because in reality, only this car can have a rear drive, not a small focus. I added some other old models to the model range and made them more adequate in characteristics. I added to custom cars and the car from this forum, realistic scale, and gearboxes, as in real cars. I have show all cars what i have in this short video: https://youtu.be/atZb8RRMHYs
Thank you so much for working on these optimisations. Originally we just made different versions of cars (with only different textures) because we didn't have other models available. Of course it would be more fun and interesting to actually have different cars that naturally would have different behaviour and attributes. We would only need to group them sensibly into our three categories.
But I fear you are working with very old code. Didn't you pull our newest development version from the git instance as a base for your much appreciated work? In your video I see that you are still using the version without a collision model for our vegetation sprites. Would it be easy for you to migrate your improvements to our most recent code base without running into trouble there? We even do have a new version of core components. Therefore, I fear your alterations might not be easily reproducible in our most recent development version. And since I am not a developer myself, I can't resolve this.
I have installed newer code game, but i dislike that in game removed the hood camera view. That make useless my work around a camera position from cockpit. It would be better to move cameras from mass center a little more, as example hood camera need to move up and back on old code version, side camera need to move a little more to right, periscope camera move a lot to back to make it as helicopter camera on back of a car. I have found how to fix problems with mass center in old version and can use big truck with hood camera inside cabin. In new version changing of position parameter is useless, because no car in hood camera view.
I'm sorry to read that. If I remember correctly, I think Andrei changed the camera positioning to overcome an other issue. I can vaguely remember it had something to do with the physics that depended on the camera positioning, probably because the mass centre of the vehicles is actually attached to the same point. But unfortunately I can't quite remember if that really was the problem. The discussion is for sure somewhere here in the board. Is it hard to just add an other camera as hood view again? I think we didn't mind removing it because nobody of us did use it anyway.
Yes! Camera position attached to mass center. I can solve this problem in old version by this parameters:
ctrlparams
drag="20.0, 20.0, 20.0"
lift="0"
fineffect="100"
but they decrease car characteristics. Next problem is gearboxes. I'm really not understand how to simulate them? In real car gear box have such parameter:
Main gear: 4.103
1 gear: 4.148
2 gear: 2.369
3 gear: 1.556
4 gear: 1.155
5 gear: 0.859
6 gear: 0.686
R gear: 3.394
As I understand in Trigger Rally 1 gear = R gear, OK. But next problem is that gearbox in Trigger Rally have max gear is 1.0 (if last gear value >1 it switch to next gear) and lower values will never switch. And I don't understand non-sense parameter absolute=0.025 or near.
So I take such formula: (gear+maingear)/(maxgear+maingear)
Last edit: Eugene MC 2024-02-06
I fear I can't help with interpreting the code. But has the code changed so much that you can't figure out how you could get a hood cam in it? Maybe we should reach out to Andrei and ask him. I think he is still involved in other projects here on Source Forge. Did you already check out the readme file and the commit history for hints what his changes were?
Oh, thanks, I found this patch: https://sourceforge.net/p/trigger-rally/patches/33/
It turns on render of car on hoot camera. Now think about how to fix mass center to make cars controllable