Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 7 8 [9] 10 11 ... 22

Author Topic: Proposal: a standard format for mods in a diff/patch Mod Starter Pack  (Read 42457 times)

thistleknot

  • Bay Watcher
  • Escaped Normalized Spreadsheet Berserker
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #120 on: August 18, 2014, 08:31:28 pm »

I tried

sed -r "s/(.*?)(\[[^][]+\])/\1\r\n\2\r/g" testfile.txt > testfile.out

and it didn't work on sample input data.

The solution posted 2-3 posts back above actually works better because it doesn't try to split the [[ and ]]'s into new lines, therefore reserving lines for just tokens and saying screw the rest if they aren't token's and leave them on their own lines and not bother inserting carriage returns in them.

I could make a cleaner version that just deals with the actual tokens and reinject the filename on top... however... there are files in the ..\text folder that seem to have non token data that may actually be used by the program.
« Last Edit: August 18, 2014, 08:33:13 pm by thistleknot »
Logged

PeridexisErrant

  • Bay Watcher
  • Dai stihó, Hrasht.
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #121 on: August 18, 2014, 08:41:12 pm »

Modders still have to pack responsibly or you must include a manifest.  ... either way there is an onus on the modder to conform to the raw folder structure, which they currently do not do at all. 

Creating a catch-all formatter that would magically pull out all the relevant files is impossible.  The Wanderer's Friend mod dumps everything within the raw structure, but the user has to select which features they want to install by selectively copying files across.  Only way you can do this properly is to have a sentient/English speaking AI that doesn't mind spending its life reading mod readme.txt files.

Point is, somewhere in the chain a human has to check it over and understand if the mod is compatible with the loader.  This line...
Quote
The problem with relying on a manifest is that it massively cuts down on your potential input.  At the moment, that's every mod out there - if it can work installed on vanilla DF (without graphics or dfhack), that install can be fed into the tool / converted to our format / stupidly merged.
... is false.  Some mods, by chance, will work.  Many/most of them won't or will be incorrectly installed and produce unwanted/unintended behaviour.

If I was going to future proof this, I'd bite the bullet and put a manifest in from the start.  Make another program or a webform or something that can generate the manifest easily, or just some guidelines.  Set up some mods yourself this way and then encourage others to use it.  Make sure the manifest has version control, then later you can make it work with DFHack scripts and other things.

You're right, most mods as distributed will be a steaming mess and completely broken.  That's not what I was talking about though - I was referring to mods after they're installed with DF (by either the sensible modder or the end user).  At this stage, they have to include a valid raw structure, and that we can process and use. 

It's the responsibility of whoever is adding the mod to the launcher to ensure that it's either:
 a) a full, working installation of raw-only mods; or
 b) a raw folder that can be overwritten over a vanilla install and have that become a working install of the mod

If someone wants a loader-compatible Wanderer's Friend option, they have to set up a working install of it themselves.  Or <checks DFFD> if they want something distributed as a "replace your options folder with this" mod like Eevee Fortress, they'd better do that.  I imagine some modders will conform to the format, some will be set up by pack distributors, and some will have to be done by the user.

I do plan to include manifest use from an early version, both reading if present and writing a default if not, but still not requiring one to be included for basic use.  Good idea on the version number.  We can certainly encourage modders to include a manifest and users to add to the generated default, but we have to be functional without it. 
Logged
I maintain the DF Starter Pack - over a million downloads and still counting!
 Donations here.

thistleknot

  • Bay Watcher
  • Escaped Normalized Spreadsheet Berserker
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #122 on: August 18, 2014, 09:11:26 pm »

this is a "cleaner" version that removes all comments and injects the filename at the top of the file.

interestingly enough, this guy was trying to solve exactly the issue I wanted with filename injections
http://www.computing.net/answers/programming/how-do-i-insert-a-filename-into-a-text-file/24247.htm

Either this method, or the one described in this post should do the trick:
http://www.bay12forums.com/smf/index.php?topic=142295.msg5584437#msg5584437

Code: [Select]
@ECHO OFF
SETLOCAL EnableDelayedExpansion

FOR /f "tokens=*" %%a IN ('DIR /b /a-d "*.txt"') DO (
SET Var=%%a
ECHO !Var:~0,-4!>>TempFile.txt
ECHO.>>TempFile.txt
grep -oE "\[[^][]+\]" %%a >>"TempFile.txt"
sed -e "s/\[[^][]*\]/\n&\n/g" "TempFile.txt" >> "TempFile2.txt"
sed -e "s/^ *//; s/ *$//; /^$/d; s/\r//; /^\s*$/d" "TempFile2.txt" > "TempFile3.txt"
DEL "%%a"
REN "TempFile3.txt" "%%a"
DEL "TempFile3.txt"
DEL "TempFile2.txt"
DEL "TempFile1.txt"
)
PAUSE

input:

Spoiler (click to show/hide)

output (it's called test because that was the file name... it's not an error, it's just because I set the filename is all)
Code: [Select]
test
[OBJECT:ITEM]
[ITEM_GLOVES:ITEM_GLOVES_GAUNTLETS]
[NAME:gauntlet:gauntlets]
[ARMORLEVEL:2]
[UPSTEP:1]
[SHAPED]
[LAYER:ARMOR]
[COVERAGE:100]
[LAYER_SIZE:20]
[LAYER_PERMIT:15]
[MATERIAL_SIZE:2]
[SCALED]
[BARRED]
[METAL]
[LEATHER]
[HARD]
« Last Edit: August 18, 2014, 09:16:25 pm by thistleknot »
Logged

King Mir

  • Bay Watcher
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #123 on: August 18, 2014, 09:39:16 pm »

- transform all mod folders into our format, permanently (once ever per mod)
 - create (temporary) flattened raws for vanilla and all mods (once per run)
 - create a diff between flat vanilla and each flat mod (once per run)
 - select mods to load and load order, and each time this changes:
 * analyse diffs in order; if changed areas overlap reject merge and return first overlapping mod
 - attempt merges in order; if any fail reject the merge and return first non-merging mod
 - if merge was rejected inform the user which mod caused failure, otherwise offer new raws
Regarding steps one and two, I still don't get why you want to transform mods into our format. Mods should work with the tool out of the box. You can do some caching as an optimization, so that you don't have to do the same work per mod, each time you merge mods, but this is a performance optimization, and it does not make sense to try to make the process faster at the cost of ease of use. If you do want caching like that, it would be better to use a system that looks at modification time instead of manually asking the user to pre-process the Mod.
« Last Edit: August 18, 2014, 09:46:32 pm by King Mir »
Logged

King Mir

  • Bay Watcher
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #124 on: August 18, 2014, 09:58:53 pm »

Regarding a manifest file, I agree with PeridexisErrant that we don't want to have any special requirements on the format of a Mod. A mod, capable of being installed by copying over vanilla should be all that is needed for a Mod to work.

salithus

  • Bay Watcher
  • gottagofast
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #125 on: August 18, 2014, 10:04:56 pm »

Do you guys have any specific mods you're using as a test bed? I've got some (crazy) ideas, but not sure what to best test with.
Logged

thistleknot

  • Bay Watcher
  • Escaped Normalized Spreadsheet Berserker
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #126 on: August 18, 2014, 10:17:31 pm »

Regarding a manifest file, I agree with PeridexisErrant that we don't want to have any special requirements on the format of a Mod. A mod, capable of being installed by copying over vanilla should be all that is needed for a Mod to work.

all this stuff about a "manifest"... I've been saying can be updated from the patch files/raws themselves.  There is absolutely NO NEED to make anything OTHER than a patch file.  If a v2 or v3 or whatever comes along.  The objects can be parsed in place from raws and patches.  Since patches are ALWAYS editing a base vanilla branch.  This branch can be defaulted back to to figure out the exact line #'s that were to be edited, and what object it was to be applied to.  Then... return back to that location using the token-id (of course in a hypothetical future version).
« Last Edit: August 18, 2014, 10:26:44 pm by thistleknot »
Logged

King Mir

  • Bay Watcher
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #127 on: August 18, 2014, 10:31:51 pm »

I started working on a script to
A)Identify conflicting mod files based on a diff
B)Merge non-conflicting files.

The intent is to be two function that work on multiple versions of the same file.

A simple implementation of this would be to implement A as assuming any two non identical files are conflicting ant B as moving the mod file to the generated mod. My script would be a drop in replacement for that.
Do you guys have any specific mods you're using as a test bed? I've got some (crazy) ideas, but not sure what to best test with.
No, but creating a testbed would be useful. Thistleknot suggested testing merging DF0.40.x raws and accelerated mod raws over DF0.34.11, but that's an ambitious goal. Another obvious goal is any particular mini-Mod on top of any graphics pad.

thistleknot

  • Bay Watcher
  • Escaped Normalized Spreadsheet Berserker
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #128 on: August 18, 2014, 10:59:24 pm »

I'll get you 3 diff mods by nights end that is based on diff's from 40_09.

Maybe you'll have some luck with merging them :)

I'll host the files on github, the commits will show I flattened them.  I'll probably use the script that keeps comments in.

PeridexisErrant

  • Bay Watcher
  • Dai stihó, Hrasht.
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #129 on: August 18, 2014, 11:05:48 pm »

OK, here's where I leave this for while:  input format, folder structure, and a code skeleton that works... for everything except the actual merge bit.  You may want to expand the information passed through the functions to the merge logic, I kept it minimal so it doesn't seem to even hold folder variables.

Download link.

Spoiler: code (click to show/hide)

I started working on a script to
A)Identify conflicting mod files based on a diff
B)Merge non-conflicting files.

The intent is to be two function that work on multiple versions of the same file.

A simple implementation of this would be to implement A as assuming any two non identical files are conflicting and B as moving the mod file to the generated mod. My script would be a drop in replacement for that.

If you start with the code above, you can just fill out the function "def mod_merge_logic(mod, mods_merged):" - which was the idea of posting it :)  However I think that passing arguments to these functions may actually be counterproductive, as you lose all the other variables that have been set up (like, eg, paths and number of mods already merged). 

I plan on (sometime soonish I hope) fixing that, adding useful comments before that function explaining the variables you can use, and adding a flatten_raws function somewhere. 

Quote
testbed mods
I just visited DFFD for a couple of mods, I think Rise of the Mushroom Kingdom as a major mod, Accelerated Modest Mod in the middle, and Eevee Fortress which just adds them as a playable civ.  As noted above some mods require installation over vanilla before they're usable, but that's not much of a challenge. 

Quote
manifest
Reading everything relevant to merge logic from the content is the plan, but an optional manifest is still nice for stuff like displaying the author and an update link, maybe a one-sentence summary of the mod, that kind of thing.  Some fields can be autofilled from the raws / folder names / etc, but others need a human to write them. 
Logged
I maintain the DF Starter Pack - over a million downloads and still counting!
 Donations here.

King Mir

  • Bay Watcher
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #130 on: August 18, 2014, 11:12:12 pm »

Code: (just the mod merging functions) [Select]
def merge_next_mod(next_mod, mod_load_order, mods_merged):
    if not next_mod == '':
        mod_merge_logic(next_mod, mods_merged)
    if not mod_load_order == []:
        next_mod = mod_load_order.pop(0)
        mods_merged += 1
        merge_next_mod(next_mod, mod_load_order, mods_merged)
I should have caught this earlier. This is a horribly wasteful way to loop, and may cause a stack overflow. Just write a for loop that loops over each mod. No need for recursion.

thistleknot

  • Bay Watcher
  • Escaped Normalized Spreadsheet Berserker
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #131 on: August 18, 2014, 11:17:47 pm »

I think there are some files that may "break" if flattened the way we do.

this is taken from vanilla.
seek out [CONTEXT:HIST_FIG:TRANS_NAME] at [CONTEXT:ABSTRACT_BUILDING:TRANS_NAME] over in [CONTEXT:SITE:TRANS_NAME]

if dwarf fortress reads this as oneline... then my parse breaks it

that's in data\speech

King Mir

  • Bay Watcher
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #132 on: August 18, 2014, 11:18:11 pm »

OK, here's where I leave this for while:  input format, folder structure, and a code skeleton that works... for everything except the actual merge bit.  You may want to expand the information passed through the functions to the merge logic, I kept it minimal so it doesn't seem to even hold folder variables.

Download link.

Spoiler: code (click to show/hide)

I started working on a script to
A)Identify conflicting mod files based on a diff
B)Merge non-conflicting files.

The intent is to be two function that work on multiple versions of the same file.

A simple implementation of this would be to implement A as assuming any two non identical files are conflicting and B as moving the mod file to the generated mod. My script would be a drop in replacement for that.

If you start with the code above, you can just fill out the function "def mod_merge_logic(mod, mods_merged):" - which was the idea of posting it :)  However I think that passing arguments to these functions may actually be counterproductive, as you lose all the other variables that have been set up (like, eg, paths and number of mods already merged). 

I plan on (sometime soonish I hope) fixing that, adding useful comments before that function explaining the variables you can use, and adding a flatten_raws function somewhere. 
Yeah that's one of the functions I'm basically working on. The other is to see if merging is safe in the first place.

EDIT: except mod_merge_logic takes a mod, I'm working on single files.

Quote
Quote
manifest
Reading everything relevant to merge logic from the content is the plan, but an optional manifest is still nice for stuff like displaying the author and an update link, maybe a one-sentence summary of the mod, that kind of thing.  Some fields can be autofilled from the raws / folder names / etc, but others need a human to write them.
As long as it's optional.
« Last Edit: August 18, 2014, 11:35:21 pm by King Mir »
Logged

King Mir

  • Bay Watcher
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #133 on: August 18, 2014, 11:20:41 pm »

I think there are some files that may "break" if flattened the way we do.

this is taken from vanilla.
seek out [CONTEXT:HIST_FIG:TRANS_NAME] at [CONTEXT:ABSTRACT_BUILDING:TRANS_NAME] over in [CONTEXT:SITE:TRANS_NAME]

if dwarf fortress reads this as oneline... then my parse breaks it

that's in data\speech
Yeah, it seems some files can be flattened, others cannot. You'd have to just keep track of which files cannot, based on their name and directory.

thistleknot

  • Bay Watcher
  • Escaped Normalized Spreadsheet Berserker
    • View Profile
Re: Proposal: a standard format for mods in a diff/patch Mod Starter Pack
« Reply #134 on: August 18, 2014, 11:46:53 pm »

Okay.

Here's the testbed:

Based on: 40_09 flattened
zip can be dl'd from here (look for zip link in bottom right):
https://github.com/thistleknot/df_40_09_Flattened/tree/f18f2555afb309ced4fdeac5f2644f028939a2e6

I picked the first 3 mods that were compatible with 40_09 that had active development

Advanced Civilizations
Dire Forged (most changes)
Plant Fixes

https://github.com/thistleknot/df_40_09_Flattened/commits/master
I only flattened raw\objects\*.* (no subfolders)

Patch files
http://dffd.wimbli.com/file.php?id=9439

Spoiler: SCRIPTUSEDTOPARSE.BAT (click to show/hide)

UPDATE
I was able to merge the plant and advciv one's fairly easily.  However, the direforge and plantfix modified the same area of permitted reactions of some types of drinks.

I used tortoisegitmerge.

oh yeah, I had to delete the diff part for the additive pdf file, it was causing tortoisegitmerge headaches

well gnight guys

Update 2
Apparently, if one creates the patch file using diff -r -u dir1 dir2, one gets a patch:)

in cygwin, one can take two patches based on the same sourced if patches are UNIFIED.  And create an interdiff.  Which is basically a merge of the two!

conflicts will be flagged upon merge... but... this gives one the opportunity to address n way merges on the patch level!
« Last Edit: August 19, 2014, 12:27:41 am by thistleknot »
Logged
Pages: 1 ... 7 8 [9] 10 11 ... 22