Hello everyone there!
Few months ago, when we were officially nominated developers, someone whom I don't remember the name, was also asked to make a video trailer for RoR. But sadly that never happened.
Today, we decided to hold a contest and ask you, players, to be part of the trailer.
Read more: Trailer-contest-RoR-Promo-Contest-Trailer-0-4-5-0
The blog post is a bit late but well.
We are getting closer and closer to the release of RoR 0.4.5 with each TestBuild released.
RoR 0.4.5's release is aimed for the 11th of August, but who knows? It might come a bit later.
Today, Test Build 4 got released!
Test Build 4:
Added ability to select skidmarks quality.Added flexbody_lods & flexbody_cache_system configs to the ingame options.Added some main menu music. (can be disabled via ingame options)Improved overall performances.Improved Aircraft's GUIImproved managed materials. (the ones you use on a truck file, are now just a part of it, wiki page to come)Improved reflections (thanks to derbymutt)Improved the parser, more fault toleranceRemoved current PSSM shadows technique, currently not working correctly.Fixed TB3's cache bug.Fixed nodes2 with flexbodies.Fixed crash 'back to menu' on Linux. (Well, doesn't apply here)Fixed Hydrax under OpenGL .Fixed triggers not extending with commands/commands2.Fixed fixes (Nodes who don't move at all)Fixed flashing flares.Fixed Pause Menu bug where mouse don't move when using free camera.Fixed unlimited sight range.Fixed wallpapers resolution ratio.Fixed meshwheels/meshwheels2 parser bug. (Where the comma wasn't working as intended in the mesh file's name)Fixed Waves being rendered at wrong height.Fixed soundscripts duplicated name makes archive not load.Feature: More realistic turbo simulation. Truck_Description_File#EngturboFeature: AI now can be scripted using Angelscript, wiki page to come.Feature: Mods are now sorted by alphabetic order.
A car that uses the new turbo code: Lotus-76-1-for-current-and-future-ror-versions-(Updated-for-test-build-4)
Have fun and don't forget to report bugs.
Say hello to the official Skype group. Approved and watched over by the dev team. Honestly!
No GTA V discussions or useless spam please.
Click to join.
Updated 2 Weeks Ago at 02:13 AM by skybon
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.
Site authors have always wanted to author and publish content without much hassle.
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.
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.
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.
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.
The look of 2015
This home page actually stands out and catches the visitor's eye.
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).
Да. 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.
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
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
Hello all RoR fans.
Late as usual, I bring you an overview of development done during May.
I'm happy to state RoR has a healthy pulse. The GitHub repository is greatly helping our development. The issue tracker is receiving a lot of submissions from users testing our latest builds, and the dev team does their best to attend to and resolve them. We're also receiving stars and attracting new contributors.
Hiradur worked hard to set up Travis CI for RoR. It's a continuous integration service - it builts RoR regularily under linux to see if build passes OK. This is very important for us since we maintain both windows and linux compatibility, and from time to time, some windows contributions (ahem, mine...) break linux build.
Max98 had a great idea to set up Gitter discussion board for RoR. Gitter is a browser based chat service directly linked to our repository. Great place for developers to meet each other and other community members to talk about technical aspects of RoR. And, it's already attracting new people who may contribute important knowledge to the project.
It's still in development, there's still no release date and the purpose has slowly and silently changed. Original plan was to only make RoR stable, content-compatible and crash-free while ignoring performance and not adding any features. However, volunteer-based development progresses slowly and players are equally concerned about performance, stability, graphics, performance and gameplay experience as a whole. And yes, I know I wrote "performance" twice. So, the new motto of 0.4.5 is "All kinds of improvements, as long as nothing gets broken and it runs at least a little faster than before".
The fix of the month are definitely FlexBodies. Somewhere between 0.39 and 0.4.0x they became malformed, as reported in this issue. In test build 3, they are corrrect again and faster than before, thanks to Max98.
Another improvement is speed of vehicle loading. During testing, I got angry about vehicles taking too long to load, so I incorporated a tiny profiler into the codebase and started investigating. The major bottleneck were verbose logs I added to the spawn process. I added config options for them and made them disabled by default. Next, it got interesting - the bottleneck were FlexBodies, but curiously, not their generation, but finding LOD files in OGRE's resource system (which is super slow and targeted for elimination by OGRE team, btw). Since nobody seems to use the feature, I added config option to disable it by default. Next bottleneck was flexbody generation itself and I found a way to bypass even that - I added a cache support to flexbodies, so they are only generated once and saved as binary file to cache, subseqent spawns load it from the cache. Right now the feature is disabled by default, see file /resources/skeleton/conf/README.txt for instructions how to enable and test it. I have to say I'm quite proud of this improvement and I'm planning to use it in more areas of RoR to speed up loading even further.
I've done enough dreaming in the last devblog post. Now I'm back to the boring but necessary fixing of vehicle/map compatibility. Current work: fixed objects on maps. But I can't resist the urge to slowly enhance the rig editor as well. Current work: flares. And finally, I also began attending to performance issues. Current work: adding a performance graph window to help pinpoint the bottleneck on various player hardware. This makes the development somewhat fuzzy and unfocused, but it's the best answer to the requests from the community.
Have fun playing RoR!
Hello RoR fans.
Another 2 months have passed and 1 new progress report is here. It turned out everyone (including me) was so busy in march that barely any development happenned and I had no time to write a blog post (plus, nothing new to write about, really ). Fortunately, April has been much more relaxed and I've been able to do some very important progress. All of my latest changes are incorportated in 0.4.5.0-dev test build 2 - I encourage everyone to test!
Vehicle compatibility status
... has improved! I tested with many more vehicles and I re-thought my approach to parser design. For one thing, I began loosening the very strict syntax checking which was causing vehicles to spawn crippled and littered the "spawner report" window with loads of warning messages. Very common mistakes, such as extra commas at the ends of lines, trailing comments (yes, they weren't legit), invalid flags and bad lettercase of keywords is now tolerated, often silently without warning message. Further, I began adding "fallback" method of parsing for lines which don't make it through the syntax check - in this case, parser will emit a warning and process the line by means of RoR v0.38/v0.4.0.7 - unsafe, but mostly workable. So far, "nodes/nodes2" were augumented this way.
But most importantly, I changed my philosophical approach to processing the .truck format. From the very start, I knew that the parsing process used in 0.4.0.7 has to change, both to clear the way for further development of RoR's physics (the old parser was seriously blocking it), and also because I wanted to equip RoR with a built-in rig editor. However, at the same time, I needed to maintain compatibility with existing content. Until now, I've been trying to write a parser which would satisfy both requirements. It didn't really work, most vehicles got broken and I wasted a lot of words rambling about how bad was both the code and the truckfiles. But about a week ago, I finally concluded the parser I wrote suits my needs, but it will never fit together with existing content. After realizing this, it was obvious what I have to do: Declare a new fileformatversion for future content, and write an importer component for content with lower fileformatversion. For the new fileformatversion number, I chose "450", to resemble version number 0.4.5.0 and also to signify it works differently than older numbers (1,2,3) - those were just informational and the parser ignored them. My fileformatversion actually makes a big difference.
Nonetheless, I began bumping into prevailing v0.38 -> v0.4.0.7 incompatibilities, such as this one. Those will be harder to tackle because the code of version 0.38 is 4 years old and uses outdated dependencies, so it'll take some time to create a working dev version for testing and investigation. I'll try my best, but no promises at this point.
Again, I encourage everyone to download a test build and check his favourite vehicles. They should work a lot better now.
Rig editor status
The editor is still not usable, but it's progressing steadily. This time, I added support for wheels (meshwheels2 + flexbodywheels so far). There's a selection menu in the top menubar and panels which can alter wheel parameters. Changes to wheel size or number of rays are displayed immediately and you can select + edit multiple wheels at the same time. There's also an option to create a new rig from scratch and the "engine" panel was equipped with [add engine]/[remove engine] buttons which were missing before. The N/B editing controls are still not complete (you can delete beams, but you can't add them yet), but work is being done. Further, the wheel-subsystem components (selection menu, highlight boxes, panels) were created as generic, so there will soon be similarly implemented support for flares, props, wings and more features.
Anyway, at this point, some of you may legitimately question my efforts to create the rig editor. Although it's a nice thing to have, it doesn't seem to be really needed, modders have been happily creating content using existing methods and without any apparent issues, as this forum thread shows. So, do I have good reason to burn a lot of time working on the editor when there are much more serious flaws to tackle? I believe so, and you deserve to know it.
Physics of the future
Currently, RoR can handle roughly 500 nodes + 3000 beams per vehicle. With so few elements, it's reasonable to do this work manually. However, this system leaves a lot to be desired - the soft body physics model (with weighted nodes acting like joints + weightless beams + stability requirements) is very hard and unnatural for a human to work with. Also, the RoR handles only enough N/B to create a grid-like chassis where 3d models can be attached (props, flexbodies).
Now imagine I created a completely new physics engine which could handle roughly 10x more N/B than the current engine (think 5,000 nodes and 30,000 beams). These numbers must sound insane to RoR veterans, but I have good technical reasons to believe such performance can be archieved. Further details aside, you'll agree with me that creating so detailed N/B by hand (or in Blender, or Editorizer, or any other similar method) will become humanly impossible. Further, such performance increase will deserve new approach to N/B architecture - instead of modelling a vehicle as a whole, it will be possible to model individual components (rigid frame, soft interior, heavy rigid engine, outer chassis components, possibly a rollcage) and then join them to create more reallistic deformation behavior.
There is only one way to deal with such a modding challenge - using a CAD-like editor where the vehicle can be modelled the way technical engineers do - by defining real-world shapes of components, materials and means of joining components together. The editor would then compute the best fit N/B to simulate such vehicle. And THAT is precisely where I'm headed in my rig-editor efforts. Currently, the editor has only partial support for hand-editing the N/B, but that's just something to start with and an utility for current modders + current content. But I'm really looking into the future, and the future is CAD.
Naturally, this is only an enthusiast project done in people's free time. It may not succeed. But I'll incorporate enough scripting support to spread the implementation complexity among members of the comunnity, so everything will be archievable. I'm optimistic.
Until then, please bear with me.
Updated 05-02-15 at 10:51 PM by only_a_ptr
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.
Updated 03-08-15 at 12:15 AM by only_a_ptr