Reverse engineering (was:Temporary modding) thread

[seebs]

Yes, it's ok to distribute level files you have written yourselves. We're infact planning to document the api and create a tool that will compile level files into a single dat file.

Very cool.

Idle question: Why is the party's facing (as found in the values of the nodeToEntity map) recorded as ".level"?

(I'm running with the assumption that the member of nodeToEntity with a .champions member is the party, and certainly, that field reflects facing and passing those values to the teleport function seems to control facing...)

[xdeath]

Websites like adfly are annoying and even dangerous to use.

There have been at least a few ads on adfly that hijacked the browser and/or installed malware, while they are quickly reported that doesn't help you much if you happened upon one of them before they're reported.

I would not only go as far as forbidding adfly and other such sites, I would put op a whitelist for allowed file hosts:

Dropbox and mediafire for files and pastebin for code snippets.

Maybe if we pester Robin he will host a nexus site for Grimrock. He has sites for the Morrowind, Oblivion, Skyrim, fallout 3, New Vegas, the witcher, Dragon Age, Dungeon Defenders, Mount and Blade, World of Tanks, and Neverwinter Nights. Adds are minimal, and the service is good.

[askjosh]

Maybe if we pester Robin he will host a nexus site for Grimrock. He has sites for the Morrowind, Oblivion, Skyrim, fallout 3, New Vegas, the witcher, Dragon Age, Dungeon Defenders, Mount and Blade, World of Tanks, and Neverwinter Nights. Adds are minimal, and the service is good.

I would like to second this suggestion

[kavika]

Hmmm, I see.

So let's say, for example:
If a modder would want to make a level that features retextured version of the game's tiles, or a monster that has the same model as the monsters in the game but slightly altered, he'll have to wait for something that's released by the devteam, yeah?
...

I'm no authority, but I'm trying to logic my way through this

I think you can do these type of mods, but you'd need the right tools.

Sol_HSA says you can use a patcher, and you can use an extractor. This means there is absolutely no reason you couldn't make a program that:

1) Extracts the data
2) *Copies* it to a different file on your HD, renames it, etc
3) Modifies that copy

This would effectively give you the exact same results on the user's computer as if they downloaded your directly modified *copy* of the Grimrock files. You wouldn't have to replace their existing files, either, since you could do a copy/rename after extracting the file.

You'd have to be careful about what type of patch files you use, tho. If you're modding source code or text files, you can't use standard unix patches as those contain a copy of the lines to be removed/modified. You'd have to use a patch that *only* contains your new code, and only has references (like line numbers) to the old code.

The tool would also be complicated if you wanted it to support patching against multiple versions of the game.

I wouldn't be surprised if there were already tools to do this sort of patching. It would be applicable to any game that allowed you to modify files, but not distribute original game content.

A question for the Grimrock Devs:
To make a tool like this easier to write and easier to verify the results, would you be allowed to distribute one-way hashes of files/lines so you can at least verify that you're modding the right files/lines? This seems reasonable to me and potentially within the rules, but it also seems a like a grey area.

[Sol_HSA]

A question for the Grimrock Devs:
To make a tool like this easier to write and easier to verify the results, would you be allowed to distribute one-way hashes of files/lines so you can at least verify that you're modding the right files/lines? This seems reasonable to me and potentially within the rules, but it also seems a like a grey area.

Since there's no way to convert a hash into the original data, this can't possibly be a problem.

[petri]

Sorry, I haven't had time to follow the discussion closely but there is no problem if you want to swap a monster or wallset texture with another texture created by you. In this case you are not distributing an asset created by us (in original or modified form). Does this help?

However, I would very much advice not to make a patcher that modifies the Grimrock dat file. It can lead to conflicts with official patches and other fan made mods. Also, uninstalling the patch is messy.

[Sol_HSA]

However, I would very much advice not to make a patcher that modifies the Grimrock dat file. It can lead to conflicts with official patches and other fan made mods. Also, uninstalling the patch is messy.

My point with the patcher is that if you're making a mod that needs to modify the original data, you still can't just take the original data, change it and distribute it. Instead, you'd have to make a patcher that does all that on the player's machine so that all you distribute is your own data.

If 100% of the data you wish to distribute is your own (with no parts taken from the game), then no patcher is needed.

[petri]

My point with the patcher is that if you're making a mod that needs to modify the original data, you still can't just take the original data, change it and distribute it. Instead, you'd have to make a patcher that does all that on the player's machine so that all you distribute is your own data.

Modifying an asset only partially (e.g. a diff) sounds fragile & hacky to me. For example, a patch that modifies an original Lua file without containing anything about the original Lua file is pretty error prone and every official Grimrock update potentially breaks the patch/mod.

For integrity I think it's best if mods would be restricted to only be allowed to override existing assets such as sounds, textures, models and so on and also add new assets to the game. As for Lua code, a mod could contain code that adds new items, dungeons, monsters (through a Lua file that is executed when a mod dungeon is selected from the New Game menu), but not make changes to the core engine which has a life of its own wrt. game updates, is hard to patch and is a grey area because it requires major reverse engineering.

[Sol_HSA]

I haven't done any reverse engineering of grimrock myself - I based the patcher idea on the discussion of how people are planning to distribute modified levels.

For instance, a mod that changes the spiders to blobs but leaves the rest of the game unchanged, would require a patcher.

Writing completely new levels and assets are a different matter. I don't know how modular the game engine is, and how easy it is to add more content without having to muck around with existing data.

Mu point however is, everything that the modders want to do IS possible, but might require more trickery (fragile as it is).

[petri]

I haven't done any reverse engineering of grimrock myself - I based the patcher idea on the discussion of how people are planning to distribute modified levels.

For instance, a mod that changes the spiders to blobs but leaves the rest of the game unchanged, would require a patcher.

Creating a patcher that does simple string replace operation on existing levels is probably safe and doable. But then again, this requires changes to the grimrock.dat file (direct patch to dat file or for the loose file hack to work), so the patch would be gone when the game is updated. How about unintalling the patch then - would you supply an unpatcher for each patch?