Activity for TORCS - The Open Racing Car Simulator
-
Bernhard Wymann committed [837ee7] on Code
Fix for track normal calculations in pathological cases with broken geometry, specific for track ole-dirt
-
Avoid wheels clipping the wheel housing
-
Adjusted weight distribution, there are conflicting sources about it, but the 60:40 and 58:42 were the front wheel TS version
-
Suspension adjustment
-
Merge branch 'r1-3-1' of ssh://git.code.sf.net/p/torcs/code into r1-3-1
-
Updated texture, added all source files (xcf, blend)
-
Updated texture, added all source files (xcf, blend)
-
Everything is included, if I compile here in a freshly cloned git-repo, everything is there, see also https://sourceforge.net/p/torcs/code/ci/r1-3-1/tree/torcs/torcs/src/windows/lib64/ The compiler output could help to find the cause. Probable not the problem, but did you create the "runtime" directory (see README, you should run 2 scripts before the build)? Bernhard
-
Kaz Pli posted a comment on discussion Help
Hi, I'm Gear5. Here is something to tell you, compiled with Visual Studio 2022, on Windows 11, has sustained minor errors on two project sources, tgf and client because libpng16.dll or libpng16.lib is neither missing. Are they included or missing? These included on lib and lib64 folder onto windows from src folder. Something I had copy and paste the missing dlls like “zlib.dll” or “libpng16.dll” into runtime folder to run wtorcs.exe but always crashed to desktop. As somebody who summerize this problem,...
-
Adjusted parameters, updated windows installer and setup bat file
-
Updated mass centering 53:47
-
Complete rework of 155-DTM, inital commit, WIP
-
john mcnamara posted a comment on discussion Help
Thanks Bernhard - user error of course :) I was installing the patch against 1.3.8 rather than the competition version (which was stated clearly in the doc - i just missed it). I now see the bot cars in the race car lineup
-
Hi there Bernhard - apologies for the questions. Im super happy to have gotten the bots to appear in the game - which is great. Although ive been attempting to run the pyclient - without much success. Just seems to continually wait - although when i do start the python client i see an additional !identified message from TORCS - but the race itself doesnt start i know that the 3001 port is critical - so ive checked and i dont see a PID against it (which suggests that nothing is listening on 3001 -...
-
Hi John The sparkle case is easy, this module just does not get compiled in Windows, but there is a directory with the configuration, so the dll missing is sport on, but can be ignored. Now, from "can't open dll drivers/scr_server/scr_server.dll" I would suspect, that the scr_server.dll is either missing or not binary compatible somehow (e.g. built/linked with different name mangling or so). According to the SCR manual it was compiled against 1.3.4: "It is possible to compile TORCS on Windows from...
-
HI Bernhard, Hope you are well! Thought id post my question in here so that anyone who may be finding the same dll messages can get a jumpstart. Im running TORCS on a Windows platform and have installed the base game along with the scr-win-patch.zip to enable the AI server functionality. However, when I launch TORCS, I encounter the following messages: windowsModInfoDir: ... can't open dll drivers/./..dll windowsModInfoDir: ... can't open dll drivers/../...dll windowsModInfoDir: ... can't open dll...
-
Hi John The sparkle case is easy, this module just does not get compiled in Windows, but there is a directory with the configuration, so the dll missing is sport on, but can be ignored. Now, from "can't open dll drivers/scr_server/scr_server.dll" I would suspect, that the scr_server.dll is either missing or not binary compatible somehow (e.g. built/linked with different name mangling or so). Did you copy the whole scr patch over the torcs installation, I guess this might be required (because the...
-
Hi John The sparkle case is easy, this module just does not get compiled in Windows, but there is a directory with the configuration, so the dll missing is sport on, but can be ignored. Now, from "can't open dll drivers/scr_server/scr_server.dll" I would suspect, that the scr_server.dll is either missing or not binary compatible somehow (e.g. built/linked with different name mangling or so). Did you copy the whole scr patch over the torcs installation, I guess this might be required (because the...
-
Hi John The sparkle case is easy, this module just does not get compiled in Windows, but there is a directory with the configuration, so the dll missing is sport on, but can be ignored. Now, from "can't open dll drivers/scr_server/scr_server.dll" I would suspect, that the scr_server.dll is missing. Did you copy the whole scr patch over the torcs installation, I guess this might be required (because the patch also contains the wtorcs.exe etc.), or just the driver dll? Kind regards Bernhard
-
Added initial 64 bit builds for Windows
-
Built and added 64 bit version of FreeALut
-
Updated OpenAL with open-soft 1.24.3, including libraries and headers for 32 bit, replaced ALut with FreeAlut
-
Added OpenAL soft to compile freealut
-
Added freealut sources for windows build
-
Prepared 64 bit libraries and dll's, except ALut and OpenAL, coming next
-
Rebuilt plib without debug info
-
Added missing libs and dll's, forgot to add those
-
Commited some more changes, use the TORCS_VS2022.sln. TORCS runs now for me, although I did not yet do any extensive testing. I did also not yet check the debug build and the tools. These changes probably break the VS 2008 build, because of the updated libraries with different headers. I am not sure if I will fix it, or get rid of it, but I will definitively going to remove the VS 6.0 stuff.
-
Added Directory.Build.props to define $(TorcsRuntimeDir) depending on the build type, either runtime (Release) or runtimed (Debug), adopted post build steps.
-
Changed naming of precompiled libraries for Windows build, in preparation for having 64 bit libraries in a different folder, but with the same names. Renamed TORCS_VS2022.sln to TORCS.sln (because of removal of other VS builds)
-
Removed VS 2008 projects and libraries
-
Bernardo de Albuquerque Alvim posted a comment on discussion Help
Hi Bernhard, Thank you so much for putting in the effort to update the source code to compile with VS 2022! I will let you know the results of the build as soon as possible!
-
Added manifest to wtorcs.exe with "Per Monitor High DPI Aware", this should fix full screen scaling issues with multi monitor systems and other than 100% dpi settings
-
Updated ogg and vorbis
-
Added libogg and vorbis sources
-
Added change to freeglut to behave the same like GLUT on the F10 key. Freeglut does respect
-
Removed vs 6.0 projects and libraries
-
Commited some more changes, use the TORCS_VS2022.sln. TORCS runs now for me, although I did not yet do any extensive testing. I did also not yet check the debug build and the tools. These changes probably break the VS 2008 build, because of the updated libraries with different headers. I am not sure if I will fix it, or get rid of it, but I will definitively going the remove the VS 6.0 stuff.
-
VS 2022 compatibility, project files and dependencies
-
VS 2022 compatibility, project files and dependencies, replaced glut with freeglut
-
Commited some more changes, use the TORCS_VS2022.sln. TORCS runs now for me, although I did not yet do any extensive testing. I did laso not yet check the debug build and the tools. This changes probably break the VS 2008 build, because of the updated libraries with different headers. I am not sure if I will fix it, or get rid of it, but I will definitively going the remove the VS 6.0 stuff.
-
VS 2022 compatibility, project files and dependencies
-
VS 2022 compatibility, project files and dependencies. Beware, this will break the VS 2008 build for now, because of the updated libpng headers.
-
So, I commited a version to r1-3-1 which compiles for me with VS 2022. I did not yet have the time to see if it works, build at least the release build goes through here. Let me know if it works for you. I will continue working on it later this week.
-
So, I commited a version to r1-3-1 which compiles for me with VS 2022. I did not yet have the time to see if it works, build at least the release build goes through here. Let me know if it works for you.
-
VS 2022 compatibility, project files and dependencies
-
VS 2022 compatibility, project files and dependencies
-
VS 2022 compatibility, project files and dependencies
-
VS 2022 compatibility, project files and dependencies
-
VS 2022 compatibility, project files and dependencies
-
Little update: For fun i tried to build it with vs 2022, it will not be so trivial, we need to rebuild some dependencies. I managed to compile plib with vs 2022, check out the r1-3-1 branch, you find the project in https://sourceforge.net/p/torcs/code/ci/r1-3-1/tree/torcs/torcs/src/windows/dependencies/vs2022_win32/. I did not integrate it tough, I guess it will need a few hours of work more to get it up and running.
-
Merge branch 'r1-3-1' of ssh://git.code.sf.net/p/torcs/code into r1-3-1
-
Added plib vs 2022 port to torcs sources to not lose the project files
-
Bernhard Wymann committed [00cf91] on Code
Added changelogs to doxygen
-
Hi Bernhard, Thank you so much for the detailed and response, that clarified a lot of questions about TORCS modding! But regarding the compilation process, i have just one final question based in your response, since the project uses 32-bit precompiled libraries , should I specifically ensure that the 32-bit (x86) architecture is selected in the VS 2022 Solution Configuration before compiling? I want to avoid errors related to mixing 32-bit libraries with a potential 64-bit output.
-
Hi "should I specifically ensure that the 32-bit (x86) architecture is selected in the VS 2022 Solution Configuration": Yes, that is exactly the point for now.
-
TORCS - The Open Racing Car Simulator released /all-in-one/1.3.8/linuxspec-cpp-race-exit-crash-fix.diff
-
Bernhard Wymann committed [96bfb4] on Code
Merge branch 'r1-3-1' of ssh://git.code.sf.net/p/torcs/code into r1-3-1
-
Bernhard Wymann committed [0c9098] on Code
Removed legacy module shutdown code
-
Bernhard Wymann committed [f789f4] on Code
Removed legacy module shutdown code
-
Hi Bernardo No, the wheels are separate, see trb1 cars as example, and the data/cars/wheels directory in the torcs sources Performance will probably suck, but it should technically work. See e.g. the p406 car to learn how to define multiple level of details (keyword for googling: LOD) There is a tutoral playlist on youtube, see https://youtube.com/playlist?list=PLq-L0hhLuRI04BLdNW0QrSxhvuyPml8zp&si=Wlxm5jbpOvJvjO30 No, not as far as I know, but they should still work Not yet, but I plan to update...
-
Hello! I am interested in creating mods for TORCS, but i have several of questions about it that i haven't seen answers online. I have the models, high quality models, but they already have the wheels, and as seen at the tutorial for Car Modelling for TORCS, the models that TORCS uses don't have wheels. Do i need to remove the wheels and create a separate file for it, or can i do some modifications in the XML file to use the wheel ALREADY in the model? Does TORCS support high-poly models? I got models...
-
Bernhard Wymann committed [ab8918] on Code
Revert "Needed for windows build."
-
Bernhard Wymann committed [c50ff8] on Code
Merge branch 'r1-3-1' of ssh://git.code.sf.net/p/torcs/code into r1-3-1
-
Bernhard Wymann committed [523258] on Code
Updated .gitignore and described using vscode
-
Bernhard Wymann committed [05b772] on Code
Moved 1.3.8 changelog
-
Gwyn Ciesla posted a comment on ticket #18
This fixes the crash on Fedora, thank you!
-
David Bears posted a comment on ticket #18
Note: the first 12 extra 0-s actually don't cause problems, only when the OS or the lib checks for buffer overflows, because you don't use the lastSlash painter anymore and you set i to 0 anyway. and after that there is empty space on the stack so maybe it is never a problem, only when checked? I'm not 100% sure abut the last statement. On many systems, the stack grows downward, so overflowing the buffer could corrupt previous stack frames. How much damage this actually does depends on how the compiler/optimizer...
-
Here is another crash: torcs-bin: CarSoundData.cpp:103: void CarSoundData::update(tCarElt*): Assertion `car->index == eng_pri.id' failed. Thread 1 "torcs-bin" received signal SIGABRT, Aborted. 0x00007ffff6c9894c in ?? () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff6c9894c in ?? () from /usr/lib/libc.so.6 #1 0x00007ffff6c3e410 in raise () from /usr/lib/libc.so.6 #2 0x00007ffff6c2557a in abort () from /usr/lib/libc.so.6 #3 0x00007ffff6c254e3 in ?? () from /usr/lib/libc.so.6 #4 0x00007fffdb84c062...
-
This might be related: I got this assertion error, which was followed by a segfault in openal. torcs-bin: ssg.h:309: void ssgBase::deRef(): Assertion `refc > 0' failed. double free or corruption (out)
-
It seems random to me as it happens on maybe one out of five races. I always do the same race with car4-trb1 in a non-championship race on CG Track 3 with all trb1 opponents, so I wouldn't really be able to say whether it is dependent on the car or track. (Sorry for the lack of diversity.) But it doesn't seem to matter how far into the race I am or where on the track I am. Though IIRC, I also got a crash from a SIGABRT, but I wasn't able to get the stack trace at that time, so potentially there are...
-
Interesting, I will have a look when I rework this. The code was more of an experiment to discourage driving around with pending penalties, but I guess it is too confusing, I might revert this to something closer to the original.
-
Hmm, never seen that before, which plib version are you using? Is it really random, or is it reproducible somehow (e.g just on certain tracks with certain cars)? Does it happen always? Did you compile plib with -fPIC, and -O2, or did you go higher? Just thinking loud, I think it cannot be a GPU driver problem, because the frustum culling is probably completely done in plib using bounding spheres or so.
-
Segfault during race
-
Penalty application does not account for running out of fuel
-
Lino Banfi posted a comment on ticket #18
hi, sorry for barging in your discussion. just wanted to say that i have the same problem, bur it shows only when compiling in release mode (eg: using "-O3" and "-g0" parameters when configuring with ./configure). if compiled in debug mode (-O0 -g3) the problem doesn't show. i will try both your solutions.
-
Cool. Btw. I think this is a funny one, because I guess the code is actually not needed at all, I wonder if it is some legacy thing. I checked if there is any symbol which could be resolved by this in my torcs installation: find . -name .so; do nm -D $f | grep Shut; done I get this (not a single match): 00000000000043c0 T _Z10ReShutdownv U _Z13GfScrShutdownv 0000000000008ce0 T _Z14ReHookShutdownv 0000000000007890 T _Z15ReEventShutdownv 0000000000008a30 T _Z16ReScreenShutdownv U _Z23RmShutdownLoadingScreenv...
-
Botond István Horváth modified a comment on ticket #18
The easyest way is maybe if I write the change down here than. In the file torcs/src/linux/linuxspec.cpp at line 461 change from strncpy(&dname[strlen(dname) - 3], "Shut", soNameSize); /* cut .so */ to strncpy(&dname[strlen(dname) - 3], "Shut", soNameSize-(strlen(dname) - 3)); /* cut .so */ This is needed because strncpy wants to fill the rest of the space with binary zeros, and seence we started at the(strlen(dname) - 3) th index we don't have soNameSize memory allocated after that. I don't know...
-
The easyest way is maybe if I write the change down here than. In the file torcs/src/linux/linuxspec.cpp at line 461 change from strncpy(&dname[strlen(dname) - 3], "Shut", soNameSize); /* cut .so */ to strncpy(&dname[strlen(dname) - 3], "Shut", soNameSize-(strlen(dname) - 3)); /* cut .so */ This is needed because strncpy wants to fill the rest of the space with binary zeros, and seence we started at the(strlen(dname) - 3) th index we don't have soNameSize memory allocated after that. I don't know...
-
The easyest way is maybe if I write the change down here than. In the file torcs/src/linux/linuxspec.cpp at line 461 change from strncpy(&dname[strlen(dname) - 3], "Shut", soNameSize); /* cut .so */ to strncpy(&dname[strlen(dname) - 3], "Shut", soNameSize-(strlen(dname) - 3)); /* cut .so */ This is needed because strncpy wants to fill the rest of the space with binary zeros, and seence we started at the(strlen(dname) - 3) th index we don't have soNameSize memory allocated after that. I don't know...
-
Hi. I did not receive it. Wonder was this was, becuase I cannot reproduce it on my SuSE 15.6. Kind regards, Bernhard.
-
Crash when leaving race
-
Crash when leaving race
-
Moved 1.3.8 changelog
-
-
Bernhard Wymann committed [6cf3ec] on Code
emoved outdated links
-
-
-
Updated installer for 1.3.8 release
-
Updated 21:9 resolutions (which are not 21:9...)
-
Bernhard Wymann committed [12aa65] on Code
Updated build system and doxygen configuration, version set to 1.3.8
-
Fixed compiler warnings
-
Bernhard Wymann committed [28cd61] on Code
Fixed compiler warning
-
Bernhard Wymann committed [82e910] on Code
Fixed compiler warning
-
Bernhard Wymann committed [60eb82] on Code
Fixed compiler warning
-
Bernhard Wymann committed [9f7690] on Code
Fixed gcc warnings regarding _BSD_SOURCE and _SVID_SOURCE
-
Unification of similar right/left code
-
Removed duplicated code
-
Athozus posted a comment on merge request #3
Looks like I've bugged this branch and mixed with the MR #2. I think you should cherry-pick 848fcb and bf05b1