View RSS Feed

Recent Blogs Posts

  1. Coming Soon: New Home page and Wiki

    by
    skybon
    , 2 Weeks Ago at 12:16 AM
    Dear friends

    My name is Artem Vorotnikov, and as some of you know, I have recently joined the RoR development team. Today I am going to talk about the RoR website goodies we have prepared for you this summer.

    About current website

    rigsofrods.com is a dynamic website that uses a content management system and several other software packages.

    The primary part is of course vBulletin forum CMS. MediaWiki with numerous extensions is used for /wiki subpart. Both of these components share PHP installation and MySQL database, such setup provides account integration between the former two.

    In this blog post I am going to describe how CMS work and why we should move away from it.

    Dynamic past

    Site authors have always wanted to author and publish content without much hassle.

    Back in 2000s we had no swiss army knife browsers with JavaScript, modern CSS, web frameworks et al. So Content Management Systems were conceived. Based on PHP and MySQL, these monsters provide owner with a database engine. All content is stored internally; web page is generated on every single request.

    It did its job then, and does today. Adding and modifying content is very easy for both owner and end user. Deployment does not require significant expertise. Simply put, you don't have to fire up an IDE or text editor because all configuration and authoring is done online with neat interface. This is how CMS became dominant in the wild.

    Yet they have their own pitfalls. Sometimes nightmares. Read on.

    Security

    The vast majority of content management systems (incl. vBulletin) require a database engine, usually MySQL for data storage. It is faster than plain text files and allows for more end user interactivity.

    The latter part comes with a very hefty price. Ever heard of 'SQL injection'? Say, access a specially crafted link and you make the database engine execute the wrong code. It is one of the top online vulnerabilities today. And do you know how this became known to the public? You guessed it. Wordpress. Drupal. In short, content management systems.

    There're other exploits: Joomla. vBulletin. CMS are just too bloated, complex to maintain and therefore buggy.

    Speaking of our software, right now I am aware of several 0-day vulnerabilities that could break website database instantly. Pop. Nothing. Error 403 or 404 instead of years of RoR history.

    Upkeep

    As I have already mentioned dynamic websites require a database engine, usually MySQL. Not every hosting service can provide you with that.

    And even if they do, you need to do maintenance work regularly, update. This consumes our precious time we could spend on improving the game itself.

    Flexibility

    Clothes make the man. If you manage to catch the eye of a potential user, you have the following, if you don't then my condolences.

    To do that on the Internet one must have a modern, nice looking, professionally done and informative home page. It is that very thing tells the players basic 80% about the game. And unless it stands out from the crowd of thousands of such 'home's your average web surfer will skip it to never return.

    What do we have today? A wall of text that really looks like a long forum post. A huge paragraph. Then another one. And another. Then a video. Afterwards a bullet list. And... that's it.

    Nothing strange as the whole website is based on forum software. It may be robust and flexible as a forum, true, but really, really not as anything else. Not as home, not even as a blog.

    Home page is almost always custom made, hand-crafted by web designer. This is exactly what CMS are not able to provide.

    ------

    This is unacceptable so it's time to move on. Here's what awaits you.

    Everything old is new again

    Back in 1990s all websites were coded by hand. Yes, fire up the text editor and type, type, type.

    Handcrafted website creation has never been easier than today, in 2015. Now we have rapid templating, light markup and website generators. There is no need for huge databases for most of the tasks anymore.

    So, behold, the new home page.

    100% static

    No databases, no CMS. All content is created once at build time. Hence the site is fast, secure and flexible. JavaScript and browser features are used where we need interactivity.

    The look of 2015

    This home page actually stands out and catches the visitor's eye.

    New Wiki

    And yes, we have a new wiki (called docs).

    No more MediaWiki, no more databases. Pages are stored in plain text and may be easily edited in Notepad (although I recommend Atom, hehe ;-) ).

    Docs use AsciiDoc for markup now. The preferred image formats are PNG and WebP (it's open and has better compression than JPEG and PNG).

    First-class localization

    Да. Ja. Oui.

    The new website is multilingual. Just try visiting the root of the site. If your browser language matches one of available locales, you'll be redirected. Otherwise you can choose the language yourself.

    Most importantly, all content is kept in sync. All translations are directly based on English source articles. Even if some parts are added, foreign visitors will still be able to read them untranslated.

    Feel free to help with translation, you can find instructions here.

    The new documentation is also fully localizable, just see the Russian example here.

    Streamlined workflow

    The new website is developed with git software and hosted on GitHub. This corresponds with Rigs of Rods main development which also occurs on GitHub. Therefore if you wish to report bugs or fix stuff yourself - you can do it the same way as for RoR itself.

    Free and open source

    In line with the project spirit the new website code is open source under the GNU Affero General Public License v3. You can always tinker with it, see how it works for yourself.

    About the forums

    vBulletin forum has served us well so far and there're no immediate deprecation plans. It will eventually be moved to forum.rigsofrods.com, however.

    All hands on deck

    What you see is a developer preview right now. We need all the help we can get for porting content, weeding out bugs. Please visit our GitHub repository page for more information

    Thank you for reading, I hope you enjoy our work.

    Updated 2 Weeks Ago at 05:59 PM by skybon

    Categories
    Development
  2. Quick note

    by
    skybon
    , 3 Weeks Ago at 11:30 PM
    Working on some good stuff for RoR community. Big surprise and new devblog by this weekend.

    Updated 3 Weeks Ago at 10:39 AM by skybon

    Categories
    Development
  3. DevBlog: Progress report 02/2015

    by
    only_a_ptr
    , 03-08-15 at 12:00 AM
    Hi all RoR fans!

    Another month has passed and it's time for me to write a progress report. In fact, the report is already slightly overdue because I've been really busy lately and I could only hardly follow RoR development. However, there are several other active developers and a growing number of testers and bug-reporters, so the project is steadily improving.

    To shortly iterate what's been hapenning:
    • I've been working on rig editor, specifically adding panels to edit properties of nodes/beams and other beam types. Currently I'm adding support for all types of wheels, including the possibility to add/edit/delete wheels. I've also started several experimental dev branches oriented on performance and more maintainable code.
    • Hiradur continues to improve linux compatibility and maintains the multitude of RoR dependencies.
    • Aperion has returned to what he's good at - improving the very core of the gameplay, the physics simulation. So far, he's only been doing careful cleanups not to disrupt the upcoming stable release, but there seems to be a lot to look forward to.
    • Max98 is simultaneously improving many player-oriented aspects of the game, ranging from UI and HUD through enviromental improvements like skies and water to signifficant gameplay fixes.


    Status of planned 0.4.5 release

    Current development effort aims towards a stable release with version number 0.4.5. This long-awaited release will fix many long-standing bugs, bring UI improvements and generally enhance player experience.

    The major development problem regarding this project is vehicle support. In the past, version 0.4.0.x broke compatibility with older vehicles and forced modders to double-release their new content. Then I came and broke things further, despite I claimed to improve it. Up to now I wasn't able to completely restore all broken features, although situation is improving. Recently, RoR got a new window which displays all errors and warnings about about loaded vehicles. Thanks to Max98, the messages are also colored. This window will inform players what's wrong with their favorite vehicles and also help modders to avoid risky or unsupported practices.

    I'd like to explain the cause of the current situation. When I analyzed RoR's vehicle loading code back in 2013, I discovered that the problem is in the design of the format - modders can define various parts of the vehicle (beams, nodes, wheels, cinecam, rotators, triggers, more wheels, more beams) in an arbitrary order, possibly interleaving things, and the parser will process all of it in the exact order. A software like this is a programmer's inferno because it's impossible to tell how exactly things are going depend on each other, how they will interact and what side effects may arise. Since RoR's vehicles were quite feature rich and features were built on top of one another, the amout of possible scenarios was astronomic. To name a few cases, I've seen vehicles defining some nodes, then defining wheels (which generate nodes) and then define more nodes. But hey, nodes have numbers, and if you auto-generate nodes in between, are you sure your numbering will continue correctly? Further, some modders attached beams to nodes before those were defined, or to nodes which were auto-generated by different sections (or possibly never generated). How is a programmer supposed to check if the connection is correct? To make things worse, there's the half-baked 'named nodes' feature (nodes2). More than half of truckfile sections don't support them, but at the same time, named nodes can still be reffered to with numbers, so modders did it that way. As a result, a programmer sees code trying to look for node 123 and he has no idea where that node will come from. Impossible to work with. Despite all these alarming facts, RoR vehicles have been working happily... until original authors left, along with the knowledge of all quirks and obscure mechanisms of the vehicle support. Un-involved coder didn't stand a chance. That's why 0.4.0x became incompatible with 0.38, and only problems followed.

    My solution to this issue was developing new vehicle parser: one that would read all data first and only then process them, in a given order, to avoid all unexpected results. From software design standpoint, this is an only plausible solution. Unfortunately, this approach broke all vehicles which relied on the quirky nature of the old parser. In addition of that, many bugs were introducted in the process, because RoR's vehicle format is very feature-rich and I was a new coder to the project. So far, I've been able to track and fix many of those bugs and also detect and work-around many legacy requirements of older vehicles. I had been hoping to work around everything, however, I've arrived to a point where some vehicles directly conflict with my parser's architecture. And even thoug I'd really love to make everything work, I'm not willing to compromise future development by making compatibility hacks into my code. Some content will just have to go.

    In a near future, I'll publish a new test build of NextStable, along with all latest fixes and compatibility enhancements, and I'll begin to sort out supported vs. unsupported content. I'll be in touch with modders, discussing the do's and dont's which 0.4.5 will impose.

    Stay tuned.

    Updated 03-08-15 at 12:15 AM by only_a_ptr

    Categories
    Development , Official News
  4. [Image heavy] Some pictures. :3

    by
    max98
    , 02-20-15 at 09:57 PM
    I was just bored, decided to post few little screenshots of what's upcoming with RoR 0.4.5 (Aka 0.4.0.7 NextStable)
    The change log is being updated but it is visible here: Changelog

    Something new here, the Main menu!


    The rig editor:
    (loading a vehicle)


    (vehicle loaded)


    (few options)


    Ingame settings:



    (ingame key mapping)


    Game informations:


    Tuned selector:


    Hydrax:



    Pause menu: (And possibility to change maps/go back to menu without exiting the game)


    Edit:
    Bonus picture:

    Updated 02-21-15 at 12:05 AM by max98

    Categories
    Development
  5. DevBlog: Progress report 01/2015

    by
    only_a_ptr
    , 02-03-15 at 10:17 PM
    Hello all RoR fans!

    My name is Petr Ohlidal (a.k.a only_a_ptr) and I'd like to give you an update on RoR development in the past month. I'll also sum up all activity which has been going on since I joined the project - and there is a lot to sum up, RoR has changed signifficantly since then.

    I joined the project in fall of 2013. At the time, RoR was a dying project - the original authors left to develop a commercial BeamNG project and community had been inactive for more than 6 months or so. The last stable release was 2 years old and the new version was half-baked. I evaluated the state of the project, decided my priorities and started coding. For the first months, my effort had no visible outcome as I decided to rewrite some very internal logic, but finally I released several test builds and today, they're consolidated into a single development version which aspires for a new stable release.

    To my great cheer, my enthusiasm has sparkled a new wave of collaborative development, and today, RoR has 4 active developers:
    • Me ~ Self-invited lead coder, a code greasemonkey focused on internals and software architecture.
    • Max98 ~ Cheerful enthusiast with focus on GUI and graphics. Fixed some long standing graphic bugs.
    • Hiradur ~ Valuable compiler specialist and analyst. Keeps RoR running on Linux and inspects it with Valgrind for memory issues.
    • Aperion ~ Old community member and contributor who came back to help.


    At the moment, the development is aimed towards delivering a new stable release. This is very important to shake off the "dead project" feeling. RoR hasn't had a stable release in years and with new similarily-themed projects, BeamNG and SpinTires, it seemed that RoR will become history. That is, however, not going to happen. Not only RoR lives on, but it also stays unique among all competition. The planned release is dubbed NextStable and has a version number 0.4.5, which displays the signifficant leap from last available build 0.4.0.7. This leap is well deserved, RoR has undergone a signifficant facelift and got rid of some long standing bugs which annoyed and discouraged players for too long. Also, major refactoring was done on the inside, to serve as groundwork for future enhancements and stability. This is a list of the most important archievements:
    • RoR got main menu! Until now, RoR worked in a straightforward scenario "start - select track - select vehicle - play - exit game", which wasn't really player-friendly. Also, the internal startup logic was over-complicated and slow, so it received a lot of fixes. Courtesy of Max98
    • RoR got new GUI skin. The previous "orange with bright orange" was really lame. New one comes in orange+black and really feels like a vehicle-driving game. Kudos to Max98
    • RoR got in-game configuration panels. Previously, all the configuration had to be done in external configurator, which works, but it's not very appealing to players. Thanks goes to Max98
    • RoR got a built-in editor for vehicles. Until now, modding had to be done with variety of external tools and a lot of hand-writing. However, this approach will soon be history. The editor is not fully featured yet, but it's architecture allows it to fully load/save the vehicle format and perform any modifications, with mouse and hotkeys, in an interactive environment. A primary inspiration for controls and workflow is Blender.
    • Rig definition file format (.truck) was completely re-coded. The old logic was flawed, bloated and effectively blocked any future enhancements. The new one is a separate component designed for stability and extensibility. It also allowed creating the rig editor. However, a lot of content stopped working in the process, sometimes due to bugs in new code, but often because of syntax flaws or inconsistencies and bad practices in .truck files themselves. Work is being done to fix the situation.
    • Max98 fixed two inflamous graphics bugs - shadows and skidmarks. He's also putting a lot of attention into sky, water and environment in general.


    Following is a list of things to definitely expect in NextStable:
    • It will provide a list of errors and warnings every time a vehicle spawned. This is mainly to help modders, but also to inform players of possible incompatibility of older content.
    • It will support most of the vehicles which are currently broken. Sadly, some of them will not be compatible due to legacy flaws or bad practices of mod authors.
    • Not much else to change. This is actually a good feature, because more changes would mean more waiting and I know everyone is already tired of waiting.


    Actually, if you feel like NextStable is coming out pretty slowly, it's not just you. I've been putting off the work for a long time because, honestly, bugfixing is boring and there is a lot of juicy redesign waiting to be done in the simulation code. So, instead of delivering what everybody is waiting for, I've been fiddling with the internals in my private development branches. Sorry guys. However, no more slacking off, I've published my experiments in my GitHub forks, consolidated my changes and I'm back to bugfixing.

    From now on, I'll be publishing a progress report blog post every month. This idea came from Max98, big thanks to him, a dev blog is a big step forward in presenting the project. Expect future posts to be a lot more detailed and to the point, this post is somewhat bland because it just has too much to sum up.

    Cheers
    Categories
    Official News , Development
  6. My personal vision for Rigs of Rods

    by
    Hiradur
    , 01-15-15 at 02:30 PM
    With the blog section now being back alive I though I'd give it a shot and write about my personal goals for Rigs of Rods. Every developer working on an open source project usually has his own vision for what the project could become and works on things that bring it closer to that vision.

    So here it is, my vision of Rigs of Rods:
    I would like to see RoR going much faster than it currently does. RoR is usually limited by the CPU as it has to do a lot of floating point math to simulate the behaviour of beams and nodes. Other limiting factors probably are memory latency and bandwidth since structures for beams and nodes are quite large in size and there are hundreds of them per vehicle. Besides the fact that the whole phsyics core could use a cleanup it is also required that we increase accuracy (discussion: Discussion-Moving-to-double-precision-for-physics) to improve the quality of the simulation. When we do that a major overhaul of the physics core is needed which would be a great chance to improve performance as well. I believe that there is more room for parallelization and that we should use it whenever possible. In the best case RoR should be able to max out any number of CPU cores while still running significantly faster on a single core than it does now.

    Besides a speedup in performance I would also like to see the physics calculations being moved to the server. The details are unclear yet because it would suddenly increase server hardware requirements a lot. Maybe we will have an option to toggle serverside physics on and off.
    The major benefit of serverside physics calculation is that multiplayer collisions are possible, something that many have asked for and I want to see happening myself. It would also lead to a clear separation between client and server, potentially putting less stress on the client than before. We will have to see how much that could be since some calculations will probably still be needed clientside for movement predicition to reduce perceived lag. It would certainly seperate rendering and physics though, already increasing performance.

    I got access to an 80-core cluster computer. My ultimate goal is that the RoR server (with physics calculations being serverside) is able to take advantage of such a system. I would like to see it being able to make use of all cluster nodes using OpenMPI to spread physics calculations across all cores so we can potentially have many people spawning many vehicles in one multiplayer session. In case this becomes possible I may host a community event, hosting a RoR server on said cluster for an evening to have a big wreck fest. It's still uncertain if this is possible at all. The possible degree of parallelization for the physics core has yet to be determined. When working with clusters additional problems arise like latency and bandwidth for communication between nodes. The latency could be large enough to make this whole project fail but since a similar project probably has never been done before we can't know for certain until we tried.

    So, to summarize:
    - large performance increase
    - ability to make use of any number of CPU cores, if possible
    - serverside physics calculations
    - OpenMPI support for use on clusters

    Keep in mind though that this is just a vision of mine yet. Work hasn't even started and it will probably take a while until it does since we would like to provide a solid new stable build first. Some of these things may not even possible or won't ever come to life. We'll have to see what the future holds.
    Categories
    Development
  7. Step one complete, now for step two

    by
    Aperion
    , 02-08-13 at 05:26 AM
    This is a follow up post to my previous one about refactoring and my plan forward.

    I have completed the first item in my list
    Way Forward (aka the plan)
    1. Replace slidenode code with outside drive-train code - Completed
    2. Refactor current wheel calculation - in progress
    3. Rewrite current drive-train to make use of new code
    4. Add new drive train features


    Here is what I wrote about the next step here:
    Refactor current wheel calculation
    Current wheels aren't very reliable, we average the speed of each node to calculate the rotation of the wheel, this is subject to fluctuation. Instead I will have one object that represents the wheel as a whole, it acts more like a traditional tire model in a game where it's simply a cylinder. This is very similar to slidenodes is that there is an ideal state, and a state the wheels actually are at.

    I'm expecting this to help solve a few issues RoR currently faces such as vehicles slipping down a slop when they should be braked. Also under this approach folding wheels should be a thing of the past.
    I am kind of gathering my thoughts on how to approach this step, and how to explain it. There are essentially two "worlds" I'll be dealing with, a beam world and a drive-train world. the beam world is the one we are familiar with, point masses held together by springs in a 3D space. The drive-train world is made of point masses held together by springs in a 1D space. So where nodes have an [x,y,z] coordinates drive-train components simply have an angle. Essentially the drive-train world is the beam world with different dimensions and units.

    So what the next step needs is translating from 1D to 3D and back. The angle in the drivetrain world will correspond to the angle offset each node is from it's original position, the hard part is how do you account for the wheel being at any odd angle? Possibly even upside down. Come to think of it, I remember now what my solution was, this is actually why I write these posts, to help me think.

    What we know is each nodes initial starting position and the current position of the axle nodes and each wheel node. If we find the rotation required to translate the axle to it's original postion we can then apply that transformation to the current wheel node position. Then use the translated current wheel node position, the center axle and the initial node position we can calculate the current angle difference from the initial position. This can then be used to calculate difference between where the node is supposed to be based on the drive-train world, and where it actually is.

    I did write a tiny program just to test this out:
    Code:
    #include <iostream>
    #include <OGRE/Ogre.h>
    
    int main()
    {
    
    	Ogre::Vector3 pn1(1, 0, 0);
    	Ogre::Vector3 pn3(1, 0, 1);
    	
    	Ogre::Vector3 n2(0, 0, 0);
    	Ogre::Vector3 n1(0, 1, 0);
    	Ogre::Vector3 n3(-1, 1, 1);
    	Ogre::Quaternion rot;
    
    	 // move nodes to origin...
    	n1 -= n2;
    	n3 -= n2;
    	
    	// get rotation
    	rot = n1.getRotationTo(pn1.normalisedCopy());
    	
    	// move spoke to origin for rotation
    	n3 -= n1;
    	n3 = rot * n3;
    	
    	std::cout << Ogre::Degree((pn3 - pn1).angleBetween(n3));
    	return 0;
    }
    We'll see how logn this takes to get done. night night.
    Categories
    Development
  8. Refactoring slidenodes, drivetrain, and framework

    by
    Aperion
    , 01-28-13 at 10:53 PM
    Since I've been doing some coding I thought I'd share what I'm working on. First and foremost my goal right now is to rework the drive-train code, this includes the tires. But I am sort of taking a round about approach to this which includes some pretty heavy refactoring. I've written a lot of concept code in the past for a new drive-train but never put it to use. I also wrote it in a reusable manner and am expanding this design.

    History
    The drive-train code I did write works on it's own, it just needed to be integrated into RoR. The new drive train code is built on the same principle as RoR, nodes and beams. Instead of nodes and beam in a 3 dimensional space we have nodes and beams in a 1 dimensional space. replace position with angle, velocity with moment, and force with torque and you have the same equations. This is where I started.

    So I am basically building a parallel "world" for the drive train that works similar to nodes and beams. My starting point was going to be the wheels, since they essentially act like the gate way between the node/beam world and the drive-train world. My approach here is to simulate a drive-train wheel object which is nothing more than an an angle, then calculate where the nodes should be positioned based on that angle. While I was working on this, I realized that this is drive-train same concept I'm using for slide nodes: calculate where a node should be, calculate beam-like forces from where the node is, and where the node should be and distribute forces appropriately. So I started hacking away at some concept that I could use for both when I dawned on me that I had already written this code a long time ago for the drive train.

    Theory
    So here is a bit about my theory behind the drive-train code, and what will most likely be used in many many more places than the drive-train. As I've worked in the BeamForcesEuler routine I've realized that it boils down to two actions, updating the forces that act on a node, and updating the nodes position. I call them sources, and sinks; sources generate/calculate the forces based on the environment and are applied to the sinks, the sinks take the forces and decide what to do with them. In RoR terms sources are beams, engine, wings, commands, collisions, etc, etc, and sinks are nodes.

    One of the cool ideas I will be able to introduce with this new idea is per-node integrators, I feel this will be handy because some weight/spring combinations are not stable but would be if a different integration method is used.

    Way Forward (aka the plan)
    1. Replace slidenode code with outside drive-train code
    2. Refactor current wheel calculation
    3. Rewrite current drive-train to make use of new code
    4. Add new drive train features


    Replace slidenode code with outside drive-train code
    I'm doing this first because it's an existing system so I will be able to just test out the new code against existing slide node behavior to tell if it is working. This will be the biggest change all other items will make use of the concepts implemented here.

    Refactoring this code will also have the added benefit of slide node damping since it's already built into the code I will be integrating.

    Refactor current wheel calculation
    Current wheels aren't very reliable, we average the speed of each node to calculate the rotation of the wheel, this is subject to fluctuation. Instead I will have one object that represents the wheel as a whole, it acts more like a traditional tire model in a game where it's simply a cylinder. This is very similar to slidenodes is that there is an ideal state, and a state the wheels actually are at.

    I'm expecting this to help solve a few issues RoR currently faces such as vehicles slipping down a slop when they should be braked. Also under this approach folding wheels should be a thing of the past.

    Rewrite current drive-train to make use of new code
    Make sure the current drive train code works and behaves as is with the new wheel model, and make use of new code to perform drive train calculations. The current code is a bit of a mess and there is a bug where the first two axles are locked together but none others, this should solve that problem.

    Add new drive train features
    Multiple engines, torque converters, clutches, lockers, limited slip, multiple gear boxes, transfer-case, brakes, etc

    My goal here is to model any and all kinds of different power, be it a traditional engine and 4 wheels, a parallel hybrid with two different engine types, or a helicopter with one engine powering two different rotors. Or who knows what. I want to flip over a car, spin one wheel with the mouse and watch the other wheel spin in the opposite direction when using an open diff. the best part IMO is that I've already got some of this working. I've test locked, open, and LS diffs. I've tested with one power source, and I've tested with two power sources.

    And Beyond!
    I plan on using this framework throughout RoR, hoping to achieve better performance, multiprocessor support, more organized, and easier to alter.

    I'm excited

    My work and progress is viewable here: http://sourceforge.net/u/aperion/rig...0fd7a443/tree/
    What I will be using for much of my refactoring is here: http://sourceforge.net/u/aperion/rig...ics/framework/
    Categories
    Development
Page 1 of 8 123 ... LastLast


About Rigs of Rods

    Rigs of Rods is a unique soft body physics simulator.


Some Tools


Partners


Follow us

Twitter youtube Facebook RSS Feed


impressum