rFactor 2 Developer Q&A

Why not - let them hold their breath until rF2 is released.... We could make bets who will last longer

In the meantime I suggest we don't discuss other sites marketing tricks in "rFactor 2 Developer Q&A" thread.

 

Tim will be in rf2 implemented some physics details such as the vibration of the wings when you attack curbs?

 

I couldn't find anything on the JSON export format that was talked about before, so apologies if this has been discussed before.

What is the reasoning behind using JSON instead of XML for the data export? Isn't it just another way to represent the same thing? (data) Or are there things you can achieve with JSON which you can't with XML?

Oh, and when will all the new questions in this thread be answered?

 

XML is hugely inflated. It's like using Frontpage to make a Web site and not tidying it up afterwards. Filesize should be smaller and that should allow much greater data, eventually.

 

Will it be possible to modify pit speed limit from ingame options?

 

XML is OK for me even if it is bigger. If you want smaller file, use .ini format.
JSON has also additional data overhead and still isn't considered as production standard. Main problem with JSON is, that it is practicaly uneditable without special editor. rF1 has some issues forcing to edit files manualy. I'm quite sure rF2 will have a few also. So posibility of modyfying result files manulay using simple text editor (for example notepad, or editors build in ftp clients) is a must. JSON doesn't meet this requirement.

Please, don't make admins life more complicated.

 

By the way, will rFactor 2 support stuff like 3+ wide starts and the new double-file restarts with an option to change the type of restart used? Will there also be wave-arounds and an option to pick how many times a race can be extended?

EDIT:
One more question. Will there be an option for qualifying to be done one-by-one exactly like NASCAR does?

 

The syntax isn't that much harder to get right. Even with notepad. XML still seams more widely supported but I am willing to take anything over what we have right now. I hope we have a better plugin API and or live JSON output. Maybe the fact that they are concerned about file size overhead is a good sign that we truly will see a lot more data then we ever had before.

 

There are 2 areas: result files and live data.
Rf1 result files are contain greatest ammoung of information comparing to other sims. Excluding some missing small additions, those are enough. And in this case file size realy doesn't matter.
Second one - live data - should be realized in different way. There should be possible to connect to game server (or better to some proxy) and read stream of live data. But it may be also static files with JSON data - Such files are not intended to be edited by admins.

There is a place for some additional data, for example car position tracking data. But those data should be saved to separate file for further processing if needed. In that case format is not so important.

Finally there is no problem to write a plugin which will save data in any format. Question is why use JSON by default which is less human readable

 

Binary formats are more compact than text formats. Here's an example.

In a 3D model, a single vertex has around 8 arguments (3 position, 3 normal, and 2 UV mapping). Some formats have more and some have less. In a text format, each argument can take up about 16 bytes, which when multiplied by 8, is 128 bytes per vertex, plus 9 bytes for the spaces between arguments and the newline characters. If that same vertex structure is in binary format, then each argument will always take up 4 bytes and there is no need for spaces between arguments and no need for newline characters. Therefore, instead of a total of 137 bytes per vertex, you only use 32 bytes per vertex. If more precision is required, then it'll still only use 64 bytes per vertex, which is less than half of what the text format would use. Multiply that by about 20,000 vertices per file and you can see why one would use binary format.

Same with other structures. They'll potentially take 1/2 to 1/4 of the space in binary format than they will in text format. Plus, there are other things that make a text format more of a deterrent for developers as structure declaration in a text file can take up around 8 to 16 bytes to describe what is being declared, then another 4 to 8 bytes to describe the size whereas in binary files, the application knows what is being declared when, and only requires a total of 4 bytes to know the size of what's being declared. That further optimizes binary files.

Did that make any sense?

 

No one says it isn't true. So why do not encode rf result files into some binary format?
Moreover: JSON is not binary format.

Yes, until you need to edit data manually. In that case binary format is unusable.
Moreover, binary formats, usually custom ones, are not standards and therefore has no support in programming frameworks. It means any programmer must write own loader/saver for this format. It makes a lot additional work done by multiple independent programmers.
If file size does matter for you, better way is to compress structured file. Believe me or not, XML files may be compressed with very good ratio.

 

That's what HEX editors are for.

Which makes them more secure because they are harder to decode. It prevents cheating.

 

But JSON isn't binary. I'm not sure why binary was even mentioned.

http://www.json.org/

As for switching to JSON, maybe it just provides an easier and more efficient means for expansion on ISI's side. It doesn't look to me like it'll be any harder to work with manually than XML, certainly no harder to code for, and while the actual output may undergo further processing (compression, for example) you could do the same with XML. (and therefore add an extra step for manual editing in either format... but presumably any extra processing will be in a standard format, much like GZIPping XML is pretty standard)

If there wasn't a reason to switch, they wouldn't.

 

Will mods remain in a zipped up format for easy organization and space savings? Most extract in 3-4 seconds and take up three times the space. If all the mods just sat compressed until needed it would be very nice.

 

Binary is superior, until you want to decode it. Provided you have the Interface Control Doc, then writing software to interpret it is not so difficult. Without the ICD, impossible.

 

Good luck finding and editing float values then

 

We have that now via the internals interface. Really we need improvements made to the internals interface. Things like giving drivers a unique ID when they join the server so that they can leave and rejoin and you can still identify them. Then we can do what ever we want.

 

Mod management, packaging, etc has been completely overhauled. COMPLETELY.

 

For Tim Wheatley,

Was rFactor2 written to support Nvidia's FXAA functionality (http://developer.download.nvidia.com/assets/gamedev/files/sdk/11/FXAA_WhitePaper.pdf).

Thanks