Subset Games Forum

Greetings.

I have a suggestion for modding. As we know now, Subset Games' official position is that mods may not distribute game assets. If they are talking only about not distributing the whole .res file, or that distributing any derivative of that (like a repainted projectile sprite) is forbidden, is not sure, and it is hard to draw a line. Thus, valid concerns were raised in this thread:
viewtopic.php?f=11&t=3165

Concern is - what if my mod makes player ship into an enemy ship? What if my mod uses enemy sprite as playable ship texture? Is this not allowed (since i'm distributing something that is inside game's res file, or is made by altering something inside game's res file), or can this be done. This is naturally an important question because a lot of people would often mod by changing game resouces, not making one from scratch (like, its easier to make a new gun sprite by altering an existing one rather than draw a new one by hand, since it will be hard to fit it into game's general theme, etc etc).

So here's my suggestion!

You can actually encode the mod file using a file from the .res file. Effectively this means using simple method of cryptography (xor), where the key is a randomly or by-hand chosen file from among the game assets. Then, mod is distributed in this encoded form and with a file name that should be used to decode it. Effectively, then only someone who owns the original game assets can decrypt such mod (because only he will have all the original game's files, and he doesnt know in advance which one would be required). If both random choice of a file and transparent decryption is added into the mod manager, the process will be absolutely transparent to the end user and modmaker.

Mod maker just needs to encode his mod before putting it online, at this point a random asset is chosen to act as key, and mod file is encoded. End user must just run the mod manager, and it automatically tries to find the file and decode the mod, and does a checksum so that it can be sure everything went fine.

The code to do this work (encode or decode the mod using xor) is very simple and fast so that it wouldnt be a problem to implement it.

This would allow modmakers to distribute mods that contain base game assets without violating Subset Games's demand that base game assets should not be distributed, because noone can unpack the mod without already owning the base game assets.

But where's the point of distributing Kestrel files XORed with part of original .res containing Kestrel?
Just use the Kestrel Cruiser that's already in the original .res

If you want to take the Kestrel and repaint it to, let's say, pink with blue stripes - then you can just make a diff between original art and derived work. By definition, the diff will not contain anything original. XOR is not a creative process and thus it's doubtful it creates intellectual property you own the right to distribute.

Its not always just a repaint, and its not easy to keep track of what is a diff of what. Having some random file as a crypto key is a universal solution.

Hissatsu wrote:Its not always just a repaint

Of course it's not always a repaint. It was just an example.

Hissatsu wrote:and its not easy to keep track of what is a diff of what.

We're talking about taking original files and modyfing them, right? So it's very easy to tell what came from where.

Hissatsu wrote:Having some random file as a crypto key is a universal solution.

It's not a solution at all (at least from the legal point of view). You're distributing intellectual property you own no rights to.

You would need a kind of "mod description file" that says "file ENEMY89 is a repaint of PLAYER01A, file ENEMY90 is a repaint of PLAYER03B" etc. My idea avoids the need of that housekeeping

I think the solution is perfectly viable in terms of legality, because in order to decode game assets from the file you distribute, you need to either:
- own original assets (in this case no violation happens, unless you pirated the assets in which case violation already happened)
- decrypt them, break the encryption (in which case violation happens, since you acquire the assets, but then you can just dl the game from TPB if you want ALL the assets together, it takes several seconds to do so, unlike probably lots of time it'd take you to decrypt a XOR with a key length of several megabytes)

Btw, distributing diff file is also mathematically the same as distributing a game asset encrypted by a game asset (we have A, B = f1(A) we want to distribute B, we distribute C which can produce B by using B=f2(A,C), just the f2 in my case is XOR function and in your case a DIFF function). It just calls for extra housekeeping (remember what is a repaint of what) which can be avoided.

Or we could write a tool which generates an SHA1 for each game resource ... then ship collections of diffs for changed base files. For mods, an instruction file would be awesome ... but we'd want to make it small/nice/neat/clean/simple.

I don't use GMM because it doesn't fulfill most of what I'd like ... but at the same time, until I can get the Mac here back online and find a few hours to play with it, I can't start on the SHA1 + substitution stuff either. And with Overdrive's rate of progression it's really hard to justify bothering.

Yes we could, but again, mathematically it will be the same. Plus, in case you are adding new files that are rework of older files (make playable ship into enemy ship, for example, or add a new projectile sprite which is a recolor of original one), you need to make housekeeping - remember which file is a mod of which file.

Hissatsu wrote:Yes we could, but again, mathematically it will be the same. Plus, in case you are adding new files that are rework of older files (make playable ship into enemy ship, for example, or add a new projectile sprite which is a recolor of original one), you need to make housekeeping - remember which file is a mod of which file.

[code]
# Python?
from filecmp import cmp
cmp(f1, f2) # Ship it if this is false...
[code]

The idea behind the SHA1 is that you ship your SHA1 with your diff. You only ship checksums with diffed files. It's dead simple. Besides, difflib is built into Python if people intend to expand on it. As is hashlib. As for "making housekeeping" ... you need it anyway unless you take the whole archive.

Anyway, "mathematically it will be the same"? What on earth are you talking about? Diffs lack information. They may take some as points of reference (depending on the impl; some use points in the file), but they're not a complete file XORed. If you don't like the implementation, that's fine. The 'append' format works for plain text, but, equally, so would working on a proper modding tool which parsed the existing subset data into 'chunks', read in by unique event ID (incremental, md5 or sha1 would be fine here) and push/popped based on ID. Checksums would be ideal, and smaller than a XORed copy. I'm still at a loss as to how this is mathematically the same, unless you're looking at the 'cracking' angle, in which case if your system takes the same processing power to reinvent/rewrite voids in files, I'm happy to pay postage to inspect this quantum machine ...

Its not always just a repaint, and its not easy to keep track of what is a diff of what. Having some random file as a crypto key is a universal solution.

Recolours aren't exactly something we should be shipping anyway. Now a tool which recolours shade by shade and we use bitmap indexing to compare and generate scripts for? Sure. Actual assets with new colours? No. XORing this doesn't make it significantly different, because you're using the original format -- you're just format shifting (think CDs to MP3s ... while this may be legal for music, is it for works of art? it isn't where I am).

And having a random file as a crypto key isn't universal, because someone with the game could give the crypto key to someone without it without violating the licence -- a hash isn't IP protected in the least.

SHA1 on a per-diffed file instance makes this easy. If you ship the base SHA1 with the new SHA1 you can compare transformations and report on failures/successes. Same would apply to repainting ... you'd only attempt the repaint on files with matching SHA1 unless the user chose to override.





tl;dr: You are promoting the distribution of Subset assets with weak protection.

I'm not promoting, i'm offering a solution to a problem that has no other solution that I can think of: how to allow delivery of modified game assets from modmaker to enduser, wihout actually distributing the assets themselves.

What i mean by mathematically equal is this:
We have asset A. We changed it to asset B. We want to give asset B to end user.

In your case you take C = f1(B,A) and transfer C. Receiver computes f2(C,A) and gets B.
In your case f1 is "create diff" functon and f2 is "apply diff" function.

In my case i again take C = f(B,A) and transfer C. Receiver computes f(B,A) and gets B.
In my case f is XOR function, and you dont have to use A, you can use any random asset.

For all purposes, except purpose of cryptoanalysis and breaking the cypher, those cases are identical, and noone in sane mind is going to decypher this, so we can disregard this case.
In both cases C does not contain enough information in itself to recreate an asset.

Above all, I do not insist. I just offered my idea. If it is unappropriate so be it.

Hissatsu wrote:In your case you take C = f1(B,A) and transfer C. Receiver computes f2(C,A) and gets B.
In your case f1 is "create diff" functon and f2 is "apply diff" function.

Diff doesn't push all of the data ... unless you're suggesting a XORed diff of some kind. The "value" of the original (in your case A) can be injected. Again, the 'value' itself isn't IP protected; it's better to send only what's required.

Hissatsu wrote:In my case i again take C = f(B,A) and transfer C. Receiver computes f(B,A) and gets B.
In my case f is XOR function, and you dont have to use A, you can use any random asset.

So why not just apply diffs to SHA1 checksumed files?

Hissatsu wrote:For all purposes, except purpose of cryptoanalysis and breaking the cypher, those cases are identical, and noone in sane mind is going to decypher this, so we can disregard this case.
In both cases C does not contain enough information in itself to recreate an asset.

In your case you still appear to be promoting C contain all of the information, including original asset information. Now, maybe, there's enough of a change that you can't really consider it the original ... but in that case, the asset isn't the old one. If it's close, then overlay it (surely we can merge PNG files?).

If it's data files? The "append" style fits that. Adding/removing old things shouldn't even be considered: just use hashes/IDs/whatever, and pass along "remove" commands.

Hissatsu wrote:Above all, I do not insist. I just offered my idea. If it is unappropriate so be it.

I believe that's all either of us were trying to say. The diff doesn't ship the asset data beyond points of reference, the XORed method would appear to.



Final thought on this: Are you suggesting this for the entire res file, or for individual files within it? I'm saying this should be done on the smallest possible units: XML rootnodes (as files seem to contain many of these), individual images, etc..