[Eldorado.Railroad]

?

[Lindsayts]

A good point, as I understand it the "optimised" items are provided with the src when its built by the developers an example of this I believe is the star map, which certainly does not appear to be in "user" changeable format, blast!!!. The problem will be there may be nothing stopping anyone from as you say locking up external content by using the same tools. A way out of this may be to make the main OR excutable not load such encoded items from an externally provided item, that is any item such as a route or rolling stock MUST be in an open format.

For users creating items they wish ALWAYS to be freely availble they may wish to create a GPL (Gnu Public Licence) style licence. The GPL is used by Linux and is writen from the outset to prevent anyone from restricting the distribution of the item or its src code in any way. So if one creates this style of licence to apply to there content this will (legaly anyway) short circuit this type of theft.

[Genma Saotome]

I'm not familiar with the thinking behind the architectural statement (even tho I am part if the Open Rails team) so what follows is speculative opinion and not a well informed understanding.

Assume for a moment that all content used in a route that is being viewed by Open Rails comes in the .s format and textures as .ace. Because .s has a number issues tied to MSTS ca. 2001 an optimization "translator" would be provided that reads the .s file and turns it into, oh, I dunno, let's call it the .xyz format and for textures .jack -- which fixes certain problems. I'm being vague here because I don't know what is wrong with MSTS files except to say I recall numerous people who know more than I do saying they have problems.

First issue: Should the translator store the .xyz file on disk or should it be only memory resident? Obviously if all the conversions were to occur at run time it would take quite a while to get started... so the preference would have to be to do the work well beforehand and store the .xyz format as a file on disk. Second issue: Does that infringe upon the rights of the person who created the .s file -- payware or freeware? Ahhh... well... maybe. Quite likely to have a variety of opinions on the matter, some of which may well be inflamed. Third issue: How do you "calm down" those folks who don't like this optimization step? Well... you could introduce another layer of DRM that assures the converted file is useless on any other PC. Last issue: But if what you run is locked to a specific machine, how is anything distributed? Same way it is today -- the .s format and the .ace format... or any other format that can be read and processed by the optimizer. Maybe that is collada plus .tga, or something else, I dunno.

Point is it is easier for the OR program to read in one format for shapes, one format for textures... but that means everything has to be .s and .ace, or, it you want shapes with more shaders, textures with bump maps, who knows what -- call it The Future -- you need a program that can read many formats and output one.

Again, I dunno if that was the thinking that is reflected in the architecture document... but it is what I think are real issues in getting around the limitations of the old MSTS formats w/o throwing everything away. FWIW, I think it is a fine idea that will run straight into unmovable opposition from some content producers.

[cjakeman]

Eldorado.Railroad, on 17 June 2012 - 01:18 PM, said:

This proposal: - to drive this, and prevent possible copyright bypass issues, ORTS will attempt to recreate optimized content that was not generated by the current version on the local machine as enforced by CPU serialization. reads as DRM (digital rights management). What is implied here is that if I make an object available that has been pre-compiled by "ORCC - Content Compiler" it can be re-distributed in this format.

Pleased to see the Architecture document is getting an airing.

I think you have this backwards. If you take an object that has been compiled by the Open Rails Content Compiler, it cannot be re-distributed as other OR systems will reject it.

That's how I read it and so most (all?) of your concerns do not apply.

[wacampbell]

I also appreciate your comments.

First, hopefully to resolve your concerns, the feature you described is in no way a DRM mechanism. The document doesn't as yet speak to the distribution format for the files, nor whether that format will be editable by the end user. It merely indicates that its the intent that the internal 'compiled and optimized' data does not become the distribution format. There are several ways to enforce this - ie by burying the data in a monolithic database with no means to extract it, or by ( as the document mentions ) utilizing CPU serialization to ensure that it hasn't been moved.

[wacampbell]

Further, on the subject of DRM, I would say in general I support the principle that content builders should have the option to protect their material from further editing. And I emphasize the work 'option'.

However, in practice, I cannot think of a way that an open program could provide any kind of an effective mechanism for this. Having visibility of the code, someone would always be able to write a 'converter' to an editable format. Even burying the code in a closed .DLL wouldn't work since the output of that DLL could again be used as a basis for a converter.

So, it may be some reassurance to you, and a consternation for others ( like me ), that OR is very unlikely to have any type of secure DRM enforcement. As we have done so far with MSTS, we'll have to rely on the goodwill of the community to self-police this.

[James Ross]

Eldorado.Railroad, on 19 June 2012 - 08:06 AM, said:

The ambiguity in the original language used such as copyright and CPU serialization (BTW, this term has several meanings in the world we live in!) would lead an educated reader to outline exactly the concerns indicated. If it is explicit that the Open Rails Content Compiler will never be used as a vehicule for DRM then yes, all of my concerns would not apply, but it has not been written that way.

Eldorado.Railroad, on 19 June 2012 - 08:06 AM, said:

Is the proposal here that a cypher be used, as provided for by using "CPU serialization", to encrypt all of the data contained within that file? This is de-facto DRM.

I think we're arguing for the same thing here, perhaps from different angles and certaily with different language. Let me try rephrasing the whole of 1.8 in the document.

Quote

1.8 Optimized Content

• Original Content for the game will be standard/publically-defined and easily editable formats.
  
• Optimised Content for the game will be internal formats, designed for the fastest possible loading and processing.
  
• The game will compile the Original Content into Optimised Content automatically, when either
  
  • the Optimised Content does not exist for the Original Content being loaded, or,
    
  • the Optimised Content was compiled on a different computer.
• The game will only load Optimised Content.

(If others are happy with my interpretations and phrasings, I'll update the document itself.)

Eldorado.Railroad, on 19 June 2012 - 08:06 AM, said:

If the inputs to the content compiler are known, what would stop somebody from supplying distributed content in that "locked up" format? If you are not intending to use some form of DRM, what would stop an "enterprising individual" from changing the CPU serialization stored in the compiled binary to match the current platform.

Nothing, I suspect; the purpose of the re-compiling / "CPU serialization" is to thoroughly discourage anyone from distributing the compiled files - since they won't load without being edited. I doubt we could make this secure without blowing the loading times (you could cryptographically sign or encrypt the files using the computer's identification as the key - so failing to decrypt means you need to re-compile - but cryptography is really slow).

[longiron]

i have been following this thread and would like to make the following comments:

• The architecture doc is a WIP and designed to identify potential issues, design objectives, coding concepts, etc that may arise, need to be considered, or otherwise addressed ... IF the OR team believes the code should be restructured
• It's not a build list of features
• Every word or item in the document should not be taken as a "fait accompli"
• The OR team has not agreed, if or when, this effort should be undertaken

As the project comes closer to reality, we will certainly solicite community input on any significant architecture or content decisions. IMHO, this is waaaaay to early to be having this detailed a discussion.

[cjakeman]

James Ross, on 19 June 2012 - 09:05 AM, said:

(If others are happy with my interpretations and phrasings, I'll update the document itself.)

Thanks, James - very clear.

I'm happy :-)

[Noisemaker]

I'm sticking my toe into waters I shouldn't even be near. But out of curiosity, could or will something like Route Riter be made for Open Rails? As I know from past with ALL MSTS routes I install, free and payware - I usually have to adjust the Terrain Error Bias after installing them. Whether they were all released as '1' I'm not sure. But thank goodness for RR's feature to fix this. And as well, dealing with mostly MLT routes myself, and experienced on other freeware/payware items - things aren't always 'perfect'. Be it nitpicky about scenery, sound. To a minor error in route and/or rolling stock. At first I used to wait for a good Samaritan or company to quickly come out with a update to fix this irks. But I think after 12 years now, we've ALL become savvy enough to open RE, or a Eng file or use Route Riter et al to fix it for ourselves.

So though it's nice to have this 'protectionism' in OR - a developer would have to be darn cocky to actually use it, and/or have 24/7 support if and more so WHEN something goes wrong with their product.
But I certainly look forward to any tools and utilities that could analyze, if not totally override to allow a daring individual to fix and/or modify any encountered problems. At worst, if a complete failure - let it void the warranty with the proprietors. Which is still going to give them a bad name down the road anyways. Minor to major faults and assumed patience to correct them does not make for a happy end user.

Okay, I'm out of the pool now! :D