Mission Administration Terms of Service

[nbohr1more]

Now that we have a rather large mission database, it's probably a good idea to spell out some rules and iron out some details.

Once this is agreed on, we can update this wiki with the results:

https://wiki.thedarkmod.com/index.php?title=How_to_pack_your_Mission

Missions eligible for hosting in the mission database:

1) No malware or malicious data

2) No illegal content ( CSAM or Exploitive Images, Classified documents, PII or doxxing details, revenge porn, pirated game ISO's, PDF of commercially published books, login credentials to bank accounts, etc.)  If it's illegal to distribute the file or information then it doesn't belong in your mission package.

3) No intellectual property or assets owned by Embracer Group ( the current owners of the Thief Series Games )

4) No unauthorized commercial game assets

5) No unauthorized commercial music

6) Missions must start and must be possible to complete

7) Missions that are poorly optimized and are unplayable for 90% of players may be rejected

8  ) Missions intentionally designed to give players a bad TDM experience ( trolling, etc) may be rejected

9) Missions designed to promote Racism, Sexism, Homophobia, or other inflammatory viewpoints may be rejected

10) Missions that are very low quality ( broken visuals, broken audio, filled with navigation bugs for the AI or player, broken readables, etc) may be rejected

 

Possible controversial TOS options:

In the past, it was mooted that the TDM Team would have the executive authority to add language translations to missions but that was met with understandable push-back. The main problem was that these translations required the map files and other assets in the mission to be altered rather than existing independently. The new "system" for language packs leaves the mission along and instead uses an override pk4 to display translations so users can always access the original un-translated mission. A secondary problem with the old system was that the translator may misinterpret the details of story and thus relay the wrong meaning to non-English speakers. Since the language pack is kept separate, any translation issues can be easily attributed to the translator rather than the mission author and the author can clearly state that they had no involvement with the translation so they bear no responsibility for it's shortcomings.

With that situation in mind, I am proposing the following TOS additions:

1) If not supplied, the TDM Team can create screen-shots for the mission database at 800x600 resolution ( the resolution compatible with our GUI's) ( we already do this so it's not very controversial )

2) Missions without an animated or customized loading screen will be given the default loading page GUI by the TDM Team so that players won't think TDM has crashed \ froze when they are awaiting a mission to load

2) Subtitles can be added to missions with cut-scenes or videos by the TDM Team

4) Language packs can be added to the mission database by the TDM Team

 

Please let me know your thoughts, objections, etc and we will solidify whatever is most agreeable to mission authors and team members.

 

Regarding Mission Updates:

The new mission database uses an SVN system so that we have the ability to do SVN rollback if anything gets broken during an update.

With this change, missions are now stored unpacked so we can update them in granular fashion.

Rather than providing the full mission package, please provide only the changed files in a zip archive along with a list of any files you removed ( if any ). If you are unsure what you added or removed simply provide the full package and we will compare and update it.

[thebigh]

These all sound pretty reasonable. I don't think any mission released to date would fail any of the criteria, except that Builder's Blocks and the Training Mission cannot be completed. Has there really been any issue with people trying to submit utter garbage, or malicious content?

[datiswous]

9 hours ago, nbohr1more said:

2) Subtitles can be added to missions with cut-scenes or videos by the TDM Team

I think you have to add that this needs the consent of the mission-author, except if it's impossible to give that consent (person not available) maybe then tdm team can give that consent instead.

 

9 hours ago, nbohr1more said:

In the past, it was mooted that the TDM Team would have the executive authority to add language translations to missions but that was met with understandable push-back. The main problem was that these translations required the map files and other assets in the mission to be altered rather than existing independently. The new "system" for language packs leaves the mission along and instead uses an override pk4 to display translations so users can always access the original un-translated mission. A secondary problem with the old system was that the translator may misinterpret the details of story and thus relay the wrong meaning to non-English speakers. Since the language pack is kept separate, any translation issues can be easily attributed to the translator rather than the mission author and the author can clearly state that they had no involvement with the translation so they bear no responsibility for it's shortcomings.

I think depending on the type of translation the translation might still need specific consent from the mission-author. Some translations have for example changed images etc.

Also having to change map files for translations is i.m.o. still kind of dubious. At least for the objectives that is still needed afaik.

Also maybe there should be a standard of what minimally should be in a translation file to be an official translation?

 

9 hours ago, nbohr1more said:

The new mission database uses an SVN system so that we have the ability to do SVN rollback if anything gets broken during an update.

To remove confusion, the mission update should have the same update number, or the svn update number should not be listed anywhere online or in the game and mission updates should require a version, otherwise get denied. Currently I think this is not the case, because tdm has it's own versioning, while the version of the mission info might not get updating. Also I think an update should require a description of what's get updated to inform players.

Mission authors often don't care about such things while players do.

[datiswous]

9 hours ago, nbohr1more said:

With this change, missions are now stored unpacked so we can update them in granular fashion.

Rather than providing the full mission package, please provide only the changed files in a zip archive along with a list of any files you removed ( if any ). If you are unsure what you added or removed simply provide the full package and we will compare and update it.

I have never seen this feature being used. For every update it's always the size of the full mission that I have to download afaik.

Edited December 5, 2024 by datiswous

[jaxa]

The NPCs themselves (or readables) should be allowed to be racist and sexist.

Edited December 5, 2024 by jaxa

[nbohr1more]

7 hours ago, datiswous said:

I have never seen this feature being used. For every update it's always the size of the full mission that I have to download afaik.

This only impacts database side updates.

Would be cool if we did zipsync stuff to missions too. @stgatilov ?

[chakkman]

4 hours ago, jaxa said:

The NPCs themselves (or readables) should be allowed to be racist and sexist.

Some would probably even consider the depiction of the Moors as racist. And, considering the standing of women in the middle age...

I frankly would scratch that rule. I'm very doubtful that anyone would create a mission with the purpose of propagating white supremacy, or the dominance of alpha males. Or whatever.

Edited December 5, 2024 by chakkman

[datiswous]

5 hours ago, jaxa said:

The NPCs themselves (or readables) should be allowed to be racist and sexist.

Why?

[jaxa]

1 hour ago, datiswous said:

Why?

Because it could be important for the plot or more likely the characterization/world-building.

[nbohr1more]

4 hours ago, chakkman said:

Some would probably even consider the depiction of the Moors as racist. And, considering the standing of women in the middle age...

I frankly would scratch that rule. I'm very doubtful that anyone would create a mission with the purpose of propagating white supremacy, or the dominance of alpha males. Or whatever.

 

The rule would mostly just keep us out of the political sphere.

That said, it also has the side benefit of being an easy excuse to reject any missions that are overtly racist

for the purpose of astro-turfing or trolling.

Of course authors can create missions that contain characters that reflect the historical racism, sexism, etc of the 16th century.

[nbohr1more]

16 hours ago, datiswous said:

I think you have to add that this needs the consent of the mission-author, except if it's impossible to give that consent (person not available) maybe then tdm team can give that consent instead.

I think of translations as an accessibility feature. We should be able to offer them just as projects like the Dolphin emulator do.

We now use a system that ensures that the original mission is distinct from the translation so it should be no different than if someone posted a translation pack to moddb or any other social media site.

I am not really gung-ho about this topic but ( on the other hand ) I just rescued over 40 translation packs from obscurity to be included in the mission database. Lots of people worked very hard on those and it felt wrong to let them go to waste.

16 hours ago, datiswous said:

I think depending on the type of translation the translation might still need specific consent from the mission-author. Some translations have for example changed images etc.

Also having to change map files for translations is i.m.o. still kind of dubious. At least for the objectives that is still needed afaik.

Also maybe there should be a standard of what minimally should be in a translation file to be an official translation?

The map file does need to be changed but the changed map file exists inside the language pack override pk4. Thus the original mission is not altered at all. Yes we should probably specify that translation packs must contain at least objectives and readables.

 

16 hours ago, datiswous said:

To remove confusion, the mission update should have the same update number, or the svn update number should not be listed anywhere online or in the game and mission updates should require a version, otherwise get denied. Currently I think this is not the case, because tdm has it's own versioning, while the version of the mission info might not get updating. Also I think an update should require a description of what's get updated to inform players.

Mission authors often don't care about such things while players do.

This is a widely discussed feature. The current mission database must increment by 1 integer every time you want to notify players that the mission has been updated. This leads to mission versions that are very high when authors keep fixing things and want those fixes to be known. I think we will make this more sensible someday ( maybe add a public_version attribute to the mission xml in the database so that the integer changes are invisible ? ) .

Do we really need to force mission authors to explain what they fixed or changed?

It's a good thing if they do so but I'm not sure about making authors admit to embarrassing mistakes they made and then secretly fixed? The readme file is where that data should be added though.

[boissiere]

My comments

On 12/5/2024 at 1:22 AM, nbohr1more said:

2) Subtitles can be added to missions with cut-scenes or videos by the TDM Team

Maybe clarify to include in-game conversations and sotto-voce comments by the protagonist.

Also, what about FMs that rely (intentionally or (most likely) otherwise) on a TDM bug that's fixed in a later release but that breaks the FM? I am not (yet) a mission author but if I was I would prefer that my mission would be fixed to still run.

[datiswous]

7 hours ago, nbohr1more said:

The current mission database must increment by 1 integer every time you want to notify players that the mission has been updated.

Is it not possible to change this to a float number instead?

 

7 hours ago, nbohr1more said:

Do we really need to force mission authors to explain what they fixed or changed?

It's a good thing if they do so but I'm not sure about making authors admit to embarrassing mistakes they made and then secretly fixed? The readme file is where that data should be added though.

Players need to know what the update consists of before doing an 800mb update (missions getting quite large lately) just to add some tweaks. I mean I think it's nice that the mission gets such an update, but it should be clear what kind of update it is.

If the author doesn't supply the info, the person that uploads the update to the database should add some info.

 

What you could (at least) do is add generic (categorised) info on what kind of update it is. Like

Update:

• Added features (including subtitles)
• Fixed game-breaking bugs
• fixed small bugs

 

Then author can still decide to add more info to the readme.

Edited December 6, 2024 by datiswous

[OrbWeaver]

This seems like a solution in search of a problem.

Where are all these mission authors submitting deliberately broken missions, missions containing child porn or missions promoting Nazism?

Why do we need a list of rules stating the blindingly obvious, such as "illegal content won't be hosted by TDM"? Why do we need to tell people that we won't host their revenge porn or pirated game ISOs?

And why do we need to standard tedious litany of virtue-signalling about vague, subjective concepts like "sexism" and "inflammatory viewpoints"? I understand why corporations need to do this to keep their HR departments and "diversity consultants" happy, but this is a volunteer project.

I don't see any need for any of this. All missions in the TDM archive are hosted at the discretion of TDM administrators. This has always been the case. We don't need to spell things out with an explicit (but inevitably incomplete) list of rules which are all either obvious, vague and meaningless, or completely irrelevant in practice.

[ChronA]

2 hours ago, OrbWeaver said:

Where are all these mission authors submitting deliberately broken missions, missions containing child porn or missions promoting Nazism?

It's never a problem, until when one day it is a problem. That said, maybe this is a disease where continuous preventative treatment is worse than a targeted remedy after infection.

I'm reminded of an incident I saw in the 0AD RTS project's community where someone (possibly as a troll, but maybe genuinely) complained about "immodest outfits" worn by female villagers and hero units for some of the civilizations being in breach of the project's content and exclusivity guidelines. The tremendous irony was that the bikini tops on those character models were already a concession to modesty, considering the historical reference art they were modeled from were even less covered up.

Any rule set is going to contain oversights and ambiguities that trolls can exploit.

[nbohr1more]

11 hours ago, OrbWeaver said:

This seems like a solution in search of a problem.

Where are all these mission authors submitting deliberately broken missions, missions containing child porn or missions promoting Nazism?

Why do we need a list of rules stating the blindingly obvious, such as "illegal content won't be hosted by TDM"? Why do we need to tell people that we won't host their revenge porn or pirated game ISOs?

And why do we need to standard tedious litany of virtue-signalling about vague, subjective concepts like "sexism" and "inflammatory viewpoints"? I understand why corporations need to do this to keep their HR departments and "diversity consultants" happy, but this is a volunteer project.

I don't see any need for any of this. All missions in the TDM archive are hosted at the discretion of TDM administrators. This has always been the case. We don't need to spell things out with an explicit (but inevitably incomplete) list of rules which are all either obvious, vague and meaningless, or completely irrelevant in practice.

This is a CYA thing. We tell them that we don't permit this stuff and if they hide it somewhere in a sub-folder of the pack then we accidentally distribute it we have our TOS setup to ensure we have plausible deniability.

Perhaps @demagogue can speak to whether such a thing would keep us out of hot water ( DMCA, etc)?

[demagogue]

Yeah the reason you'd mention no illegal or infringing material is for us to be able to say we're acting in good faith, if somebody finds their IP in an FM, they can't or it's not as straightforward to want to sue us for it. In practice I think it's more of a formality.

As for FMs that don't finish or have buggy elements, there are demo-like or novelty FMs that might have both of those. Somebody mentioned the Tutorial itself. I wouldn't want to discourage somebody being creative, and I'd probably word it differently. Something like FMs should be "complete" before being submitted, but leaving it technically open what "complete" means. I guess it might give some examples "... including but not necessarily in special cases ..." that it starts and ends, is not egregiously buggy, does not consistently crash, etc. But I think even here it should be an encouragement instead of a hard rule, like we encourage mappers to get their FMs beta-tested, confirm that it starts and finishes, doesn't consistently crash, before submitting, and we may ask that you work on an FM more before uploading it if it is manifestly broken "without justification" (to leave open the possibility of "broken" FMs with a justification, like a novelty FM).

Some of you might remember that TTLG ran a "buggy FM" contest once where broken FMs was actually the theme, and it was an amazing contest. Some of those FMs were broken in very creating, fun, and interesting ways, and it might be good to have FMs like that sometimes. The intentionality part was important though; you could have something broken if that's part of the artistic intention, so language that could leave something like that open may be good, or again encouraging people to always betatest and avoid unintentional crashing or broken FMs, etc.

Because of past experience, we might also have language to give expectations regarding possible changes after they submit. Like an alert that while we make every effort to make sure future changes to the game are backwards compatible, it's possible a change breaks an FM. Also other people may want to take assets or things from the FM for their own FM, so we should say that technically, when you submit, you agree to the license we have for our assets (I forget exactly, CC-nc something something). So under that license people can use those assets. If you don't want that, you might make a personal appeal in the readme... The other worry is when people just take big chunks of the map itself, or make their own levels in the same maps... I wonder if we could have people make explicit what they consent to having done to their maps post release, if they allow the translation file, other people to use their map work, etc. But make it clear that the map is under the CC license, which allows people to use anything from it, and they can make a personal appeal that isn't binding, but people may be moved by it. And then we might have our own internal standards what seems egregious enough not to allow, like if someone completely takes another person's map and basically tries to recycle it under their own name, or when it's a team made map and the team disagrees what happens to it. Anyway, whatever we think, it's good to have language about it here to help manage expectations about what might happen, so it's good to think about what we should say to minimize conflict later on.

[peter_spy]

4 hours ago, demagogue said:

Because of past experience, we might also have language to give expectations regarding possible changes after they submit. Like an alert that while we make every effort to make sure future changes to the game are backwards compatible, it's possible a change breaks an FM.

That actually makes me wonder. Since TDM installer gives you access to previous versions, why ensure backwards compatibility of every FM in existence, when people can copy their latest TDM pk4s, and perform a downgrade to e.g. a version required upon release? Sure, that requires some hassle, user-side, but keeping track of every FM a big strain on developers. Maybe that would take some of that pressure off.

[stgatilov]

I think we should first decide what do we want TOS for:

1. To protect TDM from legal issues?
2. To protect TDM team from angry mappers in case of conflicts?
3. To guide mission authors in their work?

In my opinion TOS should only cover legal issues, and wiki articles about making/releasing missions should cover author guidance.

On 12/5/2024 at 1:22 AM, nbohr1more said:

1) No malware or malicious data

The chance of getting malware in a mission only increases after we write this publicly.
Better don't even mention it, we are completely unprotected against this case.

By the way, isn't it covered by "illegal" clause?

Quote

2) No illegal content ( CSAM or Exploitive Images, Classified documents, PII or doxxing details, revenge porn, pirated game ISO's, PDF of commercially published books, login credentials to bank accounts, etc.)  If it's illegal to distribute the file or information then it doesn't belong in your mission package.

I'm not sure this is worth mentioning, but I guess @demagogue knows better.
By the way, which jurisdiction defines what is legal and what is not?

4 hours ago, demagogue said:

Yeah the reason you'd mention no illegal or infringing material is for us to be able to say we're acting in good faith, if somebody finds their IP in an FM, they can't or it's not as straightforward to want to sue us for it. In practice I think it's more of a formality.

Isn't it enough to mention that we will remove a mission from the database if legal issues are discovered?

Quote

3) No intellectual property or assets owned by Embracer Group ( the current owners of the Thief Series Games )
4) No unauthorized commercial game assets
5) No unauthorized commercial music

I think this is worth mentioning simply because mappers can easily do it without any malicious intent. We already had cases of problematic assets, so better include a point on license compatibility.

It is a good idea to remind every mapper that this is a serious issue.

Quote

6) Missions must start and must be possible to complete
7) Missions that are poorly optimized and are unplayable for 90% of players may be rejected
8| Missions intentionally designed to give players a bad TDM experience ( trolling, etc) may be rejected
10) Missions that are very low quality ( broken visuals, broken audio, filled with navigation bugs for the AI or player, broken readables, etc) may be rejected

I also recall some rule like "a mission of too low quality might be rejected". In my opinion, it is enough.
You will never be able to pinpoint all possible cases why you might consider a mission too bad in terms of quality. And even the specifics mentioned here already raise questions.

Quote

9) Missions designed to promote Racism, Sexism, Homophobia, or other inflammatory viewpoints may be rejected

Having such a rule is already politics.
I feel it does not save us from political issues but entangles us into them.

If there is a mission which contains something really nasty, it will cause outrage among the community (I believe our most of active forum members are good people). If people are angry, they will tell the mission author all they think about it. And if the author won't change his mind, he will eventually leave TDM community.
Then the mission can be removed from the database, perhaps with a poll about the removal. But it sounds like an exceptional case, it is hard to predict exceptional cases in advance.

Quote

1) If not supplied, the TDM Team can create screen-shots for the mission database at 800x600 resolution ( the resolution compatible with our GUI's) ( we already do this so it's not very controversial )

This is not even terms of service, but a technical detail about submissions.
The mission should be accompanied by 800 x 600 screenshots. Or we can make them ourselves if you are OK with it.

Quote

2) Missions without an animated or customized loading screen will be given the default loading page GUI by the TDM Team so that players won't think TDM has crashed \ froze when they are awaiting a mission to load

This is again purely technical, and I'm not even sure why it is needed.

Isn't it how TDM works? If mapper does not override loading gui file, then default one is taken from core?
Is it even worth mentioning?

Quote

2) Subtitles can be added to missions with cut-scenes or videos by the TDM Team
4) Language packs can be added to the mission database by the TDM Team

I think we should discuss mission updates by other people in general.
This is worth mentioning so that mappers don't feel deceived.

The generic rule is that we don't change missions without author's consent.
But it is unclear how exactly we should try to reach the author if we need his consent. PM on TDM forums? Some email address?

However, sometimes I do technical changes to ensure compatibility of missions with new versions of TDM. Especially since the new missions database has made it rather easy to do.
Luckily, I'm not a mapper/artist, so I never fell an urge to replace model/texture or remap something. But still, it is gray zone.

On the other hand, I think the truth is: we can remove a mission from database without anyone's consent. I hope it has never happened and will not happen, but I think this is the ultimate truth, and mentioning this sad fact might cover a lot of the other points automatically.

[demagogue]

7 hours ago, peter_spy said:

That actually makes me wonder. Since TDM installer gives you access to previous versions, why ensure backwards compatibility of every FM in existence, when people can copy their latest TDM pk4s, and perform a downgrade to e.g. a version required upon release? Sure, that requires some hassle, user-side, but keeping track of every FM a big strain on developers. Maybe that would take some of that pressure off.

I meant it's not the team's responsibility to ensure backwards compatibility, at least if it's some special case (they use a deprecated system in a weird way that breaks, which is how it usually if very rarely happens). It's just managing mapper expectations that there's a small chance their FM may become broken in the indefinite future if they do that. But I basically agree with stgatilov that this, and the other things he mentioned, aren't really the job of the TOS but some "Read this before you submit an FM" note.

Edit: Oh one thing about disgruntled mappers though, in my own org we'd have some term that if there is a dispute between the mapper and the organization, they agree to good faith private negotiations and failing that arbitration instead of going to court. But we've never had any dispute to that level.
 

By the way, I don't do IP law professionally (although I took the class). I work in a different area. So I don't necessarily know anything anybody couldn't learn with a few hours online research. But it makes sense to have a statement that our terms disallow illegal or infringing material so there can't be any claim that the forum / team condones or invites it, mostly as a formality.

If I were tasked with making a TOS, the first thing I'd do is find a number of other TOS's out there for similar projects and use them as a template or starting point. The bigger the org, the more likely it was vetted by their lawyers. If there are terms they almost all share, that's a sign they're the important ones. There's also the part about creating or modifying a TOS mid-stream, after 100s of FMs were released under whatever terms they were at the time (I haven't looked at it recently).

[OrbWeaver]

On 12/6/2024 at 10:57 PM, nbohr1more said:

This is a CYA thing. We tell them that we don't permit this stuff and if they hide it somewhere in a sub-folder of the pack then we accidentally distribute it we have our TOS setup to ensure we have plausible deniability.

Perhaps @demagogue can speak to whether such a thing would keep us out of hot water ( DMCA, etc)?

Ah, so the concern is that if we don't explicitly forbid illegal content, a mapper might include it, then argue in court that the TDM team was complicit because we didn't tell them up front that such content was forbidden?

Maybe that's a valid concern; it's certainly not one I can dismiss out of hand without legal advice. But in that case, I still don't think there is any benefit in listing specific types of illegal content. The relevant ToS could be made much simpler, e.g.

Quote

All missions on the TDM server are hosted at the discretion of the TDM team. Missions must not contain content illegal in <specific jurisdiction>, content which infringes third party copyrights, or content that is of exceptionally low quality. Any mission found to contain such content may be removed without warning.

Similarly, we don't need separate items for "unauthorised copyrighted music", "unauthorised copyrighted game assets" etc. These are all covered by "content which infringes third party copyrights".

[OrbWeaver]

Things that would be worth including are things that are non-obvious, for example:

• What license are individual missions released under? Are mappers required to use the same Creative Commons license as the mod itself, or can they choose a different, possibly more restrictive license (up to and including "All rights reserved")? If it's a restrictive license, they at least need to grant TDM the right to store and distribute the mission for download, but they don't necessarily need to grant rights to end users to edit the content or re-use it for other purposes. How should the license be communicated? Is there a need for a mandatory LICENSE file in the mission package?
• Can a mission author revoke their mission, and ask the team to remove it from the server, or is the right to publish irrevocable?
• Are there any restrictions on mission sizes?
• Do foreign language missions have to include an English version as well, or can they be foreign-language only?
• If a third party believes their copyright has been infringed by a mission, what is the process for making a complaint? Who should they contact and how?

[peter_spy]

All very good points^

AFAIR, when it comes to copyright restrictions for mission content, FM authors can do all rights reserved to anything but new code? This would require an explicit notice in a mission txt file, I guess.

Also, this would might need additional point in TOS, like: TDM Team, at their sole discretion, may host such mission on a server, but TDM Team cannot be held responsible for copyright infringement by other users.