Page 10 of 11

Re: Reverse engineering (was:Temporary modding) thread

Posted: Tue Apr 17, 2012 4:20 pm
by Sol_HSA
petri wrote:Why not first create mods that add new dungeons, monsters, items and puzzles and then worry about advanced/hacky stuff later?
That is the easy approach for you, but not the modders. People tend to learn by changing the existing data, and most mods at start will likely be stuff like the spider mod or "real fighters challenge" or whatnot. Assuming its possible somehow.

Of course you can state that the original dungeon is off limits, period, which would simplify things..

EDIT: the more I think about it, the more likely I see people wanting to do "grimrock remix" dungeons, editing the current set. Inevitable bits include "cool weapons early" mods, true "remixes" with altered layouts to make things feel fresh (for the "random dungeons plz" crowd), etc. You could of course say that remixes are not allowed at this time and will be considered in the future.

Re: Reverse engineering (was:Temporary modding) thread

Posted: Tue Apr 17, 2012 6:02 pm
by Dark0ne
Naturally the harder you make it for modders, the less likely it is that the modding community will take off. That's in terms of both the tools you release (and the timing of that release) and the rules and stipulations you place on the modding community. I'd advise you don't try to limit the modding community too much or try to subtlety direct them in certain directions; directions you'd rather they focused their attention, as you risk alienating the modders who like to start small, or in certain areas, before working on the bigger, better and greater mods.

Re: Reverse engineering (was:Temporary modding) thread

Posted: Tue Apr 17, 2012 11:05 pm
by naim
I think what you guys are talking about here are two separate topics:

1. Mods, modification of the game files, replace spiders with green slime or add new classes, change parts of the user interface etc.
Like the name suggests you need to modify the original game files, which may be a bit tricky and unstable, depending on how open the engine is.

2. New Maps/Dungeons;
It uses the original game files, just with a different map grid that is provided by the user in a format the engine understands.
Since a good dungeon needs scripted events, mappers must have access to some lua api to script these events and specify items etc.

I don't know how close these two are tied together, but I feel like point 2. should be first priority...

Another suggestion: can we from now on refer to them as 1. Mod and 2. DLC (Dungeon Level Content)?

Re: Reverse engineering (was:Temporary modding) thread

Posted: Wed Apr 18, 2012 11:35 am
by kavika
Crashbanito wrote:...The problem is that you do need to modify the .dat to load stuff off disk.
I'm pretty sure earlier in this thread it was shown that Grimrock can load replacement files outside the dat, so you don't need to modify the dat itself.
naim wrote:I think what you guys are talking about here are two separate topics:

1. Mods, modification of the game files, replace spiders with green slime or add new classes, change parts of the user interface etc.
Like the name suggests you need to modify the original game files, which may be a bit tricky and unstable, depending on how open the engine is.

2. New Maps/Dungeons;
It uses the original game files, just with a different map grid that is provided by the user in a format the engine understands.
Since a good dungeon needs scripted events, mappers must have access to some lua api to script these events and specify items etc.

Another suggestion: can we from now on refer to them as 1. Mod and 2. DLC (Dungeon Level Content)?
Anything that is unofficial that adds or changes content is considered a mod by the gaming community at large. Don't bother trying to correct common usage of words - it ain't gonna work.

The DLC acronym is already taken by "Downloadable content", which is commonly used to describe official game patches that don't just fix bugs, but also add new content. Either that, or paid (small) expansion packs. See: http://en.wikipedia.org/wiki/Downloadable_content

> I don't know how close these two are tied together, but I feel like point 2. should be first priority...

To who should it be a priority? If you're talking about the AH devs, then you're absolutely right. If you're talking about the modding community then I think your advice is misguided. I think there is room for both, the community will make its own tools for both anyhow, and AH is already working on #2.

Re: Reverse engineering (was:Temporary modding) thread

Posted: Wed Apr 18, 2012 12:13 pm
by kavika
I thought a bit more about this and I think you'd be hard pressed to prove a completely clean delta if the concept is taken to the extreme.

Here's a trivial example:

Code: Select all

someFunction(1, 2, "test");
Now add a line of code that is similar, but modified:

Code: Select all

someFunction(1, 2, "test");
someFunction(1, 2, "test-two");
What delta can you create that won't distribute some modified form of their original bits? Even if you include just this line, you're still including some form of their code:

Code: Select all

someFunction(1, 2, "test-two");
If you say "well, this doesn't count", then what is to keep someone from extracting their code, running an obfuscator on it (to change the function names, variables, actual code paths but not logical code arcs, etc), and redistributing the result?

The code might end up looking like this:

Code: Select all

var a = decryptNumber(lookupConstant["a"]);
var b = decryptNumber(lookupConstant["b"]);
var c = decrypt("fj209fjkldasfjklds"); // turns into "test"
f(a, b, c); // note that someFunction is renamed "f"
...But it would still do the exact same thing as their original code (albeit slower).

Maybe this is paranoia speaking, and maybe there's a spirit to the law that is hard to codify, but I think there are problems with any literal interpretation of their current rules with respect to modifying existing content, or even to coding anything while being able to view existing source code (rather than simply having a white-listed API that they publish).

I guess they'd have to delta against an existing (probably empty) file to get this to work and be considered a "delta", which is pretty much logically identical to redistributing a modified existing file. Maybe this can be hunted down and stopped the same way they'd stop piracy, and is only relevant when taken to this logical extreme.

Blizzard (World of Warcraft modding) might have cleverly side-stepped this issue by explicitly forbidding the distribution of any work that has been run through an obfuscator.

Re: Reverse engineering (was:Temporary modding) thread

Posted: Wed Apr 18, 2012 12:33 pm
by UncleSporky
kavika wrote:
Crashbanito wrote:...The problem is that you do need to modify the .dat to load stuff off disk.
I'm pretty sure earlier in this thread it was shown that Grimrock can load replacement files outside the dat, so you don't need to modify the dat itself.
As far as I can tell, currently you must modify the dat file in order to make it load loose files. You have to know the hash names of the level lua file and go in and zero out the name so the program can't find it, and will look in asset folders instead.

Re: Reverse engineering (was:Temporary modding) thread

Posted: Wed Apr 18, 2012 1:56 pm
by naim
kavika wrote:
naim wrote:I think what you guys are talking about here are two separate topics:

1. Mods, modification of the game files, replace spiders with green slime or add new classes, change parts of the user interface etc.
Like the name suggests you need to modify the original game files, which may be a bit tricky and unstable, depending on how open the engine is.

2. New Maps/Dungeons;
It uses the original game files, just with a different map grid that is provided by the user in a format the engine understands.
Since a good dungeon needs scripted events, mappers must have access to some lua api to script these events and specify items etc.

Another suggestion: can we from now on refer to them as 1. Mod and 2. DLC (Dungeon Level Content)?
Anything that is unofficial that adds or changes content is considered a mod by the gaming community at large. Don't bother trying to correct common usage of words - it ain't gonna work.

The DLC acronym is already taken by "Downloadable content", which is commonly used to describe official game patches that don't just fix bugs, but also add new content. Either that, or paid (small) expansion packs. See: http://en.wikipedia.org/wiki/Downloadable_content

> I don't know how close these two are tied together, but I feel like point 2. should be first priority...

To who should it be a priority? If you're talking about the AH devs, then you're absolutely right. If you're talking about the modding community then I think your advice is misguided. I think there is room for both, the community will make its own tools for both anyhow, and AH is already working on #2.
Petri already mentioned that there will be a tool that compiles level files into a single .dat file.
That will add new content, call it a mod if you want, but more precisely it is just a level, a map.

And thank you for pointing out that DLC acronym, I was totally unaware of that. I was just thinking about how I could possibly name level files for LoG and came up with Dungeon Level Content. What a coincidence. ;)

Re: Reverse engineering (was:Temporary modding) thread

Posted: Wed Apr 18, 2012 2:25 pm
by Sol_HSA
naim wrote:And thank you for pointing out that DLC acronym, I was totally unaware of that. I was just thinking about how I could possibly name level files for LoG and came up with Dungeon Level Content. What a coincidence. ;)
It's amazing how much FPS(1) affects the FPS(2) when I play an FPS(3), especially when moving several FPS(4), whilst trying to use FPS(5) I paid with FPS(6), FPS(7)!

1) Four Point Surround
2) Frames Per Second
3) First Person Shooter
4) Feet Per Second
5) Fingerprint Scanner
6) Flexible Payment Service
7) For Pete's Sake

Re: Reverse engineering (was:Temporary modding) thread

Posted: Wed Apr 18, 2012 6:00 pm
by Crise
kavika wrote:I thought a bit more about this and I think you'd be hard pressed to prove a completely clean delta if the concept is taken to the extreme.

Here's a trivial example:

Code: Select all

someFunction(1, 2, "test");
Now add a line of code that is similar, but modified:

Code: Select all

someFunction(1, 2, "test");
someFunction(1, 2, "test-two");
What delta can you create that won't distribute some modified form of their original bits? Even if you include just this line, you're still including some form of their code:

Code: Select all

someFunction(1, 2, "test-two");
<snip>
Not an expert on the subject, however, function declarations (prototypes) are outside of a scope of "ownership", you can't make a copyright claim based on a function call even if it was exactly the same as a call you made in your code (not even if the two lines calling that function were exactly the same, for the sake of clarity let's assume the line only contains the function call like above).

If you, however, copy the definition of said function into your code and then use it... this is where the concept of copied or derived work applies.

Consider this as a counter example to yours: I have written a plugin api (not widely used, but that's irrelevant), where the header file that defines the prototypes for the API is licensed under GPL, however, nothing stops a person wanting to write a plugin from defining those prototypes himself and licensing his code under whatever license he desires. Of course, I could have been kind and made the header file licensing LGPL instead (but that once again is not the point here).

Re: Reverse engineering (was:Temporary modding) thread

Posted: Fri Apr 20, 2012 3:18 pm
by windebieste
Thank you for opening the modding area of the forum well before the release of any official SDK. It is VERY encouraging and exciting to see such interest in customising this game.

Thank you very much. Now we just need the tools and some tutorials; and we'll start seeing what kinds of dark catacombs a Community like this will really take us. Oh, this is going to be fun.