rigsofrods / rigs-of-rods Goto Github PK
View Code? Open in Web Editor NEWMain development repository for Rigs of Rods soft-body physics simulator
Home Page: https://www.rigsofrods.org
License: GNU General Public License v3.0
Main development repository for Rigs of Rods soft-body physics simulator
Home Page: https://www.rigsofrods.org
License: GNU General Public License v3.0
Without the vehicle description, it's pretty hard to know which additional keys are used.
Yup, I've been looking at how to delete sounds and I've came up with this.
free_truck is simply acting weird. I've spawned a Vehicle ingame, free_truck = 1
Back to menu, the vehicle is destroyed, thus when loading an other map and an other truck it should be free_truck = 1 but no. It's free_truck = 2.
I tried to do free_truck--; on the code where the truck is deleted, then RoR goes weird (On second respawn, the vehicle is glitched).
P.S: Shouldn't free_truck mean the number of free slots?
I don't have a lot of time nor enough knowledge of RoR's spawning system for the moment to remake this but if anyone knows, would be great to fix it.
Wings section:
c = Right elevon (right aileron + elevator), useful for e.g. Concorde
d = Left elevon (left aileron + elevator), useful for e.g. Concorde
These aren't working using the nextstable project.
Testing: http://www.rigsofrods.com/threads/115606-Horten-Ho-229
The localization files from ror 0.4.0.7 doesn't work on ror next.
snippet from RoR.log:
== Validating vehicle: Bus RVI Agora S
== Validating done OK
== Spawning vehicle: Bus RVI Agora S
ResourceTrueTypeFont 'DefaultDashFont' using texture size 256 x 256
ResourceTrueTypeFont 'DefaultDashFont' using real height 19 pixels
Freetype returned nullptr for character 1025 in font DefaultDashFont
Freetype returned nullptr for character 1040 in font DefaultDashFont
Freetype returned nullptr for character 1041 in font DefaultDashFont
Freetype returned nullptr for character 1042 in font DefaultDashFont
Freetype returned nullptr for character 1043 in font DefaultDashFont
Freetype returned nullptr for character 1044 in font DefaultDashFont
Freetype returned nullptr for character 1101 in font DefaultDashFont
Freetype returned nullptr for character 1102 in font DefaultDashFont
Freetype returned nullptr for character 1103 in font DefaultDashFont
Freetype returned nullptr for character 1105 in font DefaultDashFont
Freetype returned nullptr for character 8470 in font DefaultDashFont
Segmentation fault (core dumped)
At least Submarine and Train.
http://www.rigsofrods.com/wiki/pages/Truck_Categories
Changing the gravity value in terrn2 has no effect.
http://www.rigsofrods.com/wiki/pages/0.4_Terrain_System#Terrain_2_.28.terrn2.29_file_format
In multiplayer, as users leave the server, their vehicles are teleported to 0,0,0 and deactivated, rather than being removed.
After a while on one server, this pile of vehicles can become massive and really hurt performance.
Forum thread: http://www.rigsofrods.com/threads/118133-Vehicles-Teleported-to-0-0-0?p=1368918&viewfull=1#post1368918
Choose a vehicle that uses a Skinzip.
Vehicle: http://www.rigsofrods.com/repository/view/4340
Skin: http://www.rigsofrods.com/repository/view/5296
Happens when entering a vehicle.
RoR console output:
LinuxForceFeedback(19) : Setting master gain to 1 => 65535
Texture: mv4speedo.dds: Loading 1 faces(PF_DXT1,256x256x1) with 8 custom mipmaps from Image. Internal format is PF_DXT1,256x256x1.
Texture: mv4tacho.dds: Loading 1 faces(PF_R8G8B8,256x256x1) with 8 custom mipmaps from Image. Internal format is PF_X8R8G8B8,256x256x1.
Texture: tractioncontrol-2.png: Loading 1 faces(PF_A8R8G8B8,64x64x1) with 0 generated mipmaps from Image. Internal format is PF_A8R8G8B8,64x64x1.
Texture: antilockbrake-2.png: Loading 1 faces(PF_A8R8G8B8,64x64x1) with 0 generated mipmaps from Image. Internal format is PF_A8R8G8B8,64x64x1.
terminate called after throwing an instance of 'OIS::Exception'
what(): Unknown error creating effect (may be the device is full)->..
Aborted (core dumped)
gdb:
Core was generated by `./RoR'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f4832552bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007f4832552bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f4832555fc8 in __GI_abort () at abort.c:89
#2 0x00007f4832e5e6b5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007f4832e5c836 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007f4832e5c863 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007f4832e5caa2 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f48342e1975 in OIS::LinuxForceFeedback::_upload(ff_effect*, OIS::Effect const*) () from /usr/lib/x86_64-linux-gnu/libOIS-1.3.0.so
#7 0x00007f48342e2002 in OIS::LinuxForceFeedback::_updateConstantEffect(OIS::Effect const*) () from /usr/lib/x86_64-linux-gnu/libOIS-1.3.0.so
#8 0x00000000006d1190 in ForceFeedback::setForces(float, float, float, float, float) ()
#9 0x00000000005284ec in RoRFrameListener::frameStarted(Ogre::FrameEvent const&) ()
#10 0x00007f4834f4bf2c in Ogre::Root::_fireFrameStarted(Ogre::FrameEvent&) () from /usr/local/lib/libOgreMain.so.1.8.1
#11 0x00007f4834f4d7d1 in Ogre::Root::_fireFrameStarted() () from /usr/local/lib/libOgreMain.so.1.8.1
#12 0x00007f4834f4d8d9 in Ogre::Root::renderOneFrame() () from /usr/local/lib/libOgreMain.so.1.8.1
#13 0x00000000007a3704 in RoR::MainThread::EnterGameplayLoop() ()
#14 0x00000000007a88a0 in RoR::MainThread::Go() ()
#15 0x00000000004fee7e in main ()
When you change from an exterior camera view to a cinecam, whatever sounds are playing restart from the beginning. This is particularly noticeable (and annoying) on vehicles with sirens.
The only camera change that doesn't restart sounds is switching from the "TV cam" view to the "chase cam".
I believe this bug was introduced in 0.39.0.
RoR had a benchmark mode, but currently the benchmark mode is broken or just removed.
http://www.rigsofrods.com/threads/63502-benchmark-mode
I think it would be a good idea to include all input maps from this thread:
http://www.rigsofrods.com/threads/96556-Joystick-specific-Input-maps
This way it's easier for beginners to use their controllers. Since they are only text files they don't increase download size very much.
This issue impacts many vehicles.
http://www.rigsofrods.com/threads/83964-Gavril-Bandit-Now-with-better-roofline-and-handling
The easiest way to test this is to use OpenGL, load simple2 terrain and spawn a Gavril MV4 and activate it.
Sometimes it breaks immediately, sometimes it requires some driving around, sometimes resetting it triggers it, sometimes time alone will trigger it. The higher the FPS the bigger the impact (I think).
Such as:
This is issue 1008 from the Wiki Bugtracker (http://www.rigsofrods.com/wiki/pages/Bugtracker), I haven't seen any mention of it being fixed, so here is a ticket.
http://www.rigsofrods.com/wiki/pages/Truck_Description_File#Soundsources3
In multiplayer, other players cannot ever see more than 2 of each user-defined flare.
Originally posted in the forum's improvised bugtracker: http://www.rigsofrods.com/threads/111967-Bugtracker-users-we-need-your-help-to-collect-all-bugs!?p=1344829&viewfull=1#post1344829
Again, just a low-priority flare issue.
Additionally, prop animations (add_animation) cannot be seen by others in multiplayer.
Check if they are still valid.
Old Bugtracker: http://www.rigsofrods.com/wiki/pages/Bugtracker
some additional bugs may be found here: http://www.rigsofrods.com/threads/111967-Improvised-bugtracker-users-we-need-your-help-to-collect-all-bugs!?p=1295079
This is a standalone feature request ticket for my ideas posted here: #21
As it stands, only "main lights" (flares with 'b', 'r/l', 'R', and 'f' tags) emit any kind of useable light and even then, the color and brightness is fixed.
User-defined flares with the 'u' tag only emit a dim white light, which isn't really useable at all.
My idea for flares is this:
Elaboration on point 1:
Keep in mind, user-defined flares often use Animated Textures to portray different flash patterns.
You can get creative with the animations, and in the past to I have been able to simulate warming up and fading of incandescent/halogen type bulbs, and even to have a flare strobe between different colors.
This means that the color light the flare emits would have to be assessed through every frame of the animation.
Elaboration on point 2:
My idea for this is that the brightness of the light should first be based on the alpha channel of the flare texture (this way the light coming from a simulated incandescent/halogen flare would also fade in/out with the animation).
I picture a multiplier-type value being used to adjust the brightness further.
Let's assume a solid color, no transparency flare texture is used. This would emit say 500 lumen (or whatever unit RoR would use) by default:
A default multiplier of 1 (or -1) would mean 500 lumen is emitted.
Let's say this flare is used just as an indicator light inside of the vehicle, and having it emit light would be a waste:
A multiplier of 0 would be entered, so the flare emits 0 lumen.
Now let's say this flare is a spotlight on an emergency vehicle, and needs to emit a bright light:
A multiplier of 4.5 would be entered and 2250 lumen would be emitted.
Etc.
I'm only into basic programming, so I've tried to break this down as detailed as I can for you guys who actually know what you're doing.
This is just an idea I've had for a while for how to make user-defined flares a bit more useful, and main lights a bit more customizable, so by no means do I expect this to be a priority since it would probably involve a lot of coding for a simple unimportant feature.
Before I wrap-up, I also mentioned Materialflares-- they emit no light at all.
Materialflares are limited to only two textures (on and off) and they usually don't use transparency or use a solid-color, so the flare's system for light color/brightness would not be very accurate if it was put in place here.
I don't know how materialflares could be made to emit light, but I just wanted to make mention of this fact.
Also, a feature called "Glow" used to exist which spiced up materialflares (http://www.rigsofrods.com/wiki/pages/Adding_Glow), but this broke at some point (loading a mesh with a glowing materialflare in 0.4.0.7 produces a black texture).
Even just bringing glow back would make materialflares a little more useful and take minimal effort.
Thanks for reading.
RoR: rigsofrods-next-stable/source/main/utils/Singleton.h:83: static T* RoRSingletonNoCreation::getSingletonPtr() [with T = GUI_MainMenu]: Assertion `_instance' failed.
The category "unsorted" disappears after first access to the loader.
Thanks to klink for the report:
http://www.rigsofrods.com/threads/105734-Version-0-4-0-7?p=1287832&viewfull=1#post1287832
if you use void setWaterHeight(float value);
the visible water will disappear.
One could say that INI config files (Or a Linux equivalent) are more organized, thus, we can organize graphics settings alone, physics settings alone, etc..
Edit: I didn't know that they actually were inis. What we should do here is use sections.
Posted by Aviar in the forum's improvised bug tracker thread:
http://www.rigsofrods.com/threads/111967-Bugtracker-users-we-need-your-help-to-collect-all-bugs!?p=1363187&viewfull=1#post1363187
I have also had this issue happen once in a blue moon when spawning using the drop-down spawner, but I can't reproduce it.
Unless you drive with a controller you probably haven't noticed this, but the brakes apply much too quickly.
Simply tapping the brake pedal on most vehicles will bring them to a stop, if not lurch them to a stop.
In contrast, fully depressing the brake pedal struggles to stop some vehicles.
Finding a brake force value that is a happy-medium is difficult when creating a vehicle:
Setting the value too high means the vehicle can stop quickly, but tapping the brake even lightly could lock up the wheels.
Setting the value too low makes the brakes apply smoothy, but good luck coming to a complete stop.
I would expect as the brake pedal is depressed, brake force at least increases proportionately, but this is not the case.
For some reason too much force is applied too early.
Not much of an issue but may leave a bad impression ;)
When hitting the Quit button in the main menu:
Core was generated by `./RoR'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fe91448913f in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
(gdb) bt
#0 0x00007fe91448913f in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#1 0x00007fe918682bb8 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007fe918682cfc in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007fe918682fcd in _XEventsQueued ()
from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007fe91867512d in XPending ()
from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007fe91b1685fc in OIS::LinuxMouse::_processXEvents() ()
from /usr/lib/x86_64-linux-gnu/libOIS-1.3.0.so
#6 0x00007fe91b168982 in OIS::LinuxMouse::capture() ()
from /usr/lib/x86_64-linux-gnu/libOIS-1.3.0.so
#7 0x0000000000749eb6 in InputEngine::Capture (this=0x340d780)
at /home/-/Desktop/copy of rigsofrods-next-stable/source/main/utils/InputEngine.cpp:2134
#8 0x0000000000781ef1 in RoR::MainThread::MainMenuLoopUpdate (
this=this@entry=0x7fffa1326ef0, seconds_since_last_frame=0,0500000007)
at /home/-/Desktop/copy of rigsofrods-next-stable/source/main/main_sim/MainThread.cpp:1031
#9 0x0000000000782186 in RoR::MainThread::EnterMainMenuLoop (
this=this@entry=0x7fffa1326ef0)
at /home/-/Desktop/copy of rigsofrods-next-stable/source/main/main_sim/MainThread.cpp:861
#10 0x0000000000786bfd in RoR::MainThread::Go (this=this@entry=0x7fffa1326ef0)
When hitting exit from the drop down menu ingame:
Program received signal SIGSEGV, Segmentation fault.
0x00007fffefb6913f in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
(gdb) bt
#0 0x00007fffefb6913f in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#1 0x00007ffff3d62bb8 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff3d62cfc in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff3d62fcd in _XEventsQueued ()
from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007ffff3d5512d in XPending ()
from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff68485fc in OIS::LinuxMouse::_processXEvents() ()
from /usr/lib/x86_64-linux-gnu/libOIS-1.3.0.so
#6 0x00007ffff6848982 in OIS::LinuxMouse::capture() ()
from /usr/lib/x86_64-linux-gnu/libOIS-1.3.0.so
#7 0x0000000000733bd0 in InputEngine::Capture() ()
#8 0x00000000005293ac in RoRFrameListener::frameStarted(Ogre::FrameEvent const&) ()
#9 0x00007ffff74aff2c in Ogre::Root::_fireFrameStarted(Ogre::FrameEvent&) ()
from /usr/local/lib/libOgreMain.so.1.8.1
#10 0x00007ffff74b17d1 in Ogre::Root::_fireFrameStarted() ()
from /usr/local/lib/libOgreMain.so.1.8.1
#11 0x00007ffff74b18d9 in Ogre::Root::renderOneFrame() ()
from /usr/local/lib/libOgreMain.so.1.8.1
#12 0x00000000007695c0 in RoR::MainThread::EnterGameplayLoop() ()
#13 0x000000000076e2e3 in RoR::MainThread::Go() ()
#14 0x00000000005040f7 in main ()
(gdb)
if you use void setCustomLightVisible(5, true);
the game will crash.
For the moment, all screenshots are saved at the root folder: My Documents/Rigs of rods 0.XX/
I believe that if we move them to: My Documents/Rigs of rods 0.XX/Screenshots/
It will be more organized and clearer.
So I've been testing with Hotrod55 few multiplayer stuffs and all we can say is that our cars are spawned and stays at the edge of the map. This bug happens only when using the upstream version. But you can still see other players (0.38 most) fine, they move around in the map and they're not at the edge of the map. Only me and Hotrod55 are at the edge of the map and even tho we have the same versions, we still can't see each others.
I believe this is caused by the new parser not sending correct packets.
Steps:
Requirements: A friend that also has the same version or you can just start 2 instances of RoR;
1/ Start RoR Config -> Select any server
2/ Start RoR1 -> Select a map if needed -> select any vehicle
3/ Start RoR2 -> Select the same map -> don't spawn a vehicle.
4/ On RoR2, you will find the vehicle on the edge of the map. Same applies if you spawn a vehicle on RoR2 and watch it from RoR1.
Posted by Craneman in the forum's improvised bug tracker: http://www.rigsofrods.com/threads/111967-Bugtracker-users-we-need-your-help-to-collect-all-bugs!?p=1361170&viewfull=1#post1361170
So I've been focusing on few multiplayer stuffs lately and I've noticed something. Each time a player loads a car, the game freezes. Each time I join a server that is heavily modded, the game freezes each time a new object is loaded on the map.
I thought that if we change all those loading to an other thread rather than the main one, it could improve things.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.