Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[thistleknot]

hey... I just made my own class to handle tagToken's...

Code: [Select]

#ifndef TAGTOKEN_H
#define TAGTOKEN_H

#include <QtCore>

class tagToken
{
public:
    tagToken();

private:
    QString nameOftagToken;

    //line # of file token was on
    int rowNumber = 0;

    //colNumber token started at
    int colNumber = 0;

    //Either an identifier such as Object:
    //or What is specified after Object: such as creature
    QString objectInstance ="";

    //is tagToken "Object:" ?
    bool objectIdentifier = 0;

    struct tokenInfo
    {
        bool openBrace = 0;
        bool closingBrace = 0;
        bool whiteSpace = 0;

        //it's a comment if there is no nearby [ or ]
        bool comment = 0;

        //are there newLines in this token?
        bool newLines = 0;
    };
};

#endif // TAGTOKEN_H

this code I planned on doing more with, but as I parsed the file, I could backupdate new data structures since I keep track of the parent object.  I could do further matching on token names, and identify subclasses of tagToken's, such as Caste, and check dependencies.

Also tokens could hold information regarding their line position, but I don't think that's too important, but knowing whitespace can help preserve the same format when rewritten so as to avoid excessive contextual differences between two files.

I set it up, so I could load up a comment with new lines as a tagToken as well as regular tag's, so when outputted, it could reference the boolean flags in the object to see if it needs to rewrite brackets or not (or leave as a comment) and hopefully leave the correct whitespace and/or tab's...

remember, this is a primitive mockup.  I started thinking about it last night and coding it today, but I haven't implemented it yet beyond creating a qvector so I can keep track of each and every tag.

Then I would probably derive a patch file based on the ordinal differences between tag positions of two objects.

Yes, I am aware I have no accessor functions setup atm.  I just noted the private vars I think I would need.

Update:
So... made some good progress for a newb today.

I have my environment setup to start parsing the entire file, whatever it may be.

Step 2 is to read all the tokens in a qvector.

Step 3 is to create individual objects and their respective tokens.

Step 4 is to compare the differences between two objects from two different files

[Sean Mirrsen]

ModBase?

I'm not sure if I've heard of that tool.

You know, now that I think about it.  I may have glanced at it.  However, I don't think I ever really got into it.  It sounds almost exactly what I was hoping to derive with these types of patch files [I was going to combine the concept with git to achieve an overall version control system that would allow me to create my own custom mods].  However... I didn't/wasn't planning on the specific ability to deselect objects to be applied.  It was either an all or nothing, with the modder reserving the ability to manually edit the patch files after they are derived if they wish to achieve specific configurations of a mod.

Update:

It sounds like your tool is somewhat raw aware?

  You can change the order of the mods in the list (this influences mods that change the same things), and you can disable them entirely, or disable their individual parts from the Components list.

Yes, it used to be. It kept a list of mods that the user could reorder, and basically applied each mod in the list in sequence. Each mod had its own folder, and its own definition file stating what mods (and what mod versions) it is dependent on, so that dependencies are always sorted to be earlier in the list than the depending mods. What broke it way back then was the introduction of the caste system. It didn't really break it so much as it broke its ability to be accurate - since castes are not only individually contained with their own tags that can repeat in the overall definition, but also discontinuous with the order in which tags are added mattering, the program needed a whole another level or raw awareness that I just couldn't give it back then.

Not sure about now. It needs a full rewrite at least because it's in VB.NET, when I'm using C# now.

[PeridexisErrant]

If you rewrite, Python would allow integration with a number of other projects

[thistleknot]

well I always said if someone else writes something better, so be it.

I have about 1 more week before I start school.  Although, I was trying to pick this up as a hobby/resume project and hopefully continue to work on it for about 5-6 hours a night for the next week.  After that, I might get 10-12 hours a week in on it.  Hopefully it's fruitful.  If I port any classes over from these other projects, I'll try to incorporate them as best I can in their original structures so if someone else wants to continue with any codebase I do in QT.

Of course, I am a newb.  I might have made some horrible design flaw early on in my programming (pop up forms vs tabbed form being one example).  I have no idea how hard/long it would take me to do basic design changes... However... that's part of the fun.

Here's some of mod manager's original python code.  This is about where I'm at atm.  I'm about to start parsing objects in.

Code: [Select]

class DataSet(object):
    def __init__(self, objects, included_files=[]):
        self.objects = objects
        self.included_files = included_files
        self.objects_map = {}
        for object in self.objects:
            self.objects_map[object.root_type + object.type + object.name] = object
       
    def get_object(self, root_type, type, name):
        key = root_type + type + name
        if key not in self.objects_map:
            return None
        return self.objects_map[key]
       
    def add_object(self, object):
        self.objects.append(object)
        self.objects_map[object.root_type + object.type + object.name] = object
I was looking at modbase.  I don't have a vb app atm, but... I can start reading the Class definitions of the C Code.   I see where it parses at least.

[PeridexisErrant]

I actually see this and my proposal as almost entirely non-overlapping.  This is trying to intelligently parse raws and deal with merge conflicts.  Mine is aiming at a LNP-graphics-tab level interface, where anyone can use it but it just won't do conflicted merges - because the main point is to make the basics easier, not make more interesting stuff possible. 

[thistleknot]

well your concept is based on deriving diff's.  And you're discussing how to model those diffs.  I was just mentioning in this thread that I had started how my code base is starting to line up with the functions that are in these other projects (mainly to parse the tag's).  Which is the 1st step in understanding the differences in an objects tag structure.

And...

Update:
Finally got it to start counting my brackets properly.

FTW.  Onward!

[Sean Mirrsen]

I actually see this and my proposal as almost entirely non-overlapping.  This is trying to intelligently parse raws and deal with merge conflicts.  Mine is aiming at a LNP-graphics-tab level interface, where anyone can use it but it just won't do conflicted merges - because the main point is to make the basics easier, not make more interesting stuff possible. 

You mean like ModBase did?

[thistleknot]

how/who breaks up a mod into it's components like that.  Someone was asking about that earlier in this thread http://www.bay12forums.com/smf/index.php?topic=142188.msg5571264#msg5571264).  Only way (and I see you have it done) I figure is by manually splitting up the patch files into specific subsets.

[Sean Mirrsen]

Basically, the program already allows you to mix up mods themselves. Splitting mods up into mini-mods, then, is trivial, and requires only minimal effort on the part of the modmaker. Especially since you're not being bound to specific line offsets in raws.

In principle, yes, it splits the whole mod into sets of files that can be applied. Here's how the definition for the martial arts mod looks:

[MOD:MARTIAL]
[NAME:Martial Arts+]
[DIRECTORY:martmod]
[REQUIRES:Original DF]
[VERSION:1.88]
[DESCRIPTION:Creator; Sean Mirrsen.

This mod alters the melee attacks of most creatures in original DF, and alters their body structure.
WARNING; Megabeast entities are known to cause worldgen lockups!!!

Requires Original DF.

Optonal components;
-Playable main races- Makes Elves, Humans and Goblins playable in all modes. Also makes several changes to their preferences.
-Civilized ethics- Alters ethic and religious disposition of existing races to make a less chaotic world.
-New creatures- Adds Dark Elves, Kentaurs, Tigermen and Lizardmen as playable, also adds a lot of nonplayable creatures.
-New entities- Adds entities for the new playable creatures.
-New mundane items- Adds a selection of weapons, armors and trapcomponents.
-Meta-magic items- Adds 640 weapons, derived from 8 basic weapons using 8 prefixes and 8 suffixes.
-Meta-megamagic items- Adds weapons uncountable, derived from all existing weapons, with a number of prefixes and suffixes I don't remember.
-Megabeast entities- Adds entities to several megabeast creatures, allowing them to spread across the map.]
[MSECT:New bodies and attacks:MAIN][FILE:body_advanced][FILE:creature_default][FILE:descriptor_shape_martmod]
[MSECT:Playable main races][FILE:entity_stand_base]
[MSECT:Civilized ethics][FILE:entity_stand_ethic]
[MSECT:New creatures][FILE:body_martmod][FILE:creature_martmod]
[MSECT:New entities][FILE:entity_martmod_base]
[MSECT:New mundane items][FILE:item_martmod_ammo][FILE:item_martmod_weapon][FILE:item_martmod_armor][FILE:item_martmod_trapcomp][FILE:entity_stand_items][FILE:entity_martmod_items]
[MSECT:Meta-magic items:OPT][FILE:item_martmod_magweapon]
[MSECT:Meta-megamagic items:OPT][FILE:item_martmod_magmegaweapon]
[MSECT:Megabeast entities][FILE:entity_martmod_megabeast]

About its only limitation is one OPT block per mod. I think.

[Warmist]

Also i suggest having support for zips (i.e. no need to unzip just have everything in file).

[Dwimenor]

Idea: split mods into small and big.

There are two types of modes:
small - which are basically simple raw changes, like removing skill rust, display case for artifacts, MANY of the things from modest mod from 34.11 and so on
big - complete game rewrites - civ forge, fallout, homestuck, etc

Combining 2 big mods into one is a big no-no. It isn't going to work. But this can be done with smaller modes. On the other hand big mods often have many of smaller changes inside them.

Directory structure For Mod manager

Code: [Select]

/
/mods
/mods/vanilla/
/mods/vanilla/raw #Orginal raws
/mods/vanilla/modules #
/mods/vanilla/modules/display_case
/mods/vanilla/modules/display_case/some_file #file describing what ModManager have change in the vanilla files to apply dispay_case module
/mods/vanilla/modules/module2
/mods/vanilla/modules/module3
...
/mods/big_mod #a really big mod, that changes a lot of raws by itself
/mods/big_mod/raw #either this mods raws as a whole, or file describing what ModManager need to do to vanilla (/mods/vanilia/raw) to apply this mod.
/mods/big_mod/modules #optional modules for big_mod. Additional features, beta-functions etc.
...
mods/some_other_big_mod
Modules are not interchangeable between mods
Modules can't be installed before big_mod/raw is installed
New modules/mods can be added to starter pack, or manually installed by user (zip?). Or have entire /mods tree on github and just pull master branch.

I think this way it's easier to prevent merge conflicts.
 

[PeridexisErrant]

I actually see this and my proposal as almost entirely non-overlapping.  This is trying to intelligently parse raws and deal with merge conflicts.  Mine is aiming at a LNP-graphics-tab level interface, where anyone can use it but it just won't do conflicted merges - because the main point is to make the basics easier, not make more interesting stuff possible. 

You mean like ModBase did?

Yes.  Exactly like that, though 1.0 will be much less advanced. 

Also i suggest having support for zips (i.e. no need to unzip just have everything in file).

It would be nice to treat a folder and a zipped copy of that folder identically - saves space and discourages user fiddling. 

Idea: split mods into small and big.
Combining 2 big mods into one is a big no-no. It isn't going to work. But this can be done with smaller modes. On the other hand big mods often have many of smaller changes inside them.
I think this way it's easier to prevent merge conflicts.

I see a spectrum of major mods (including conversions) / minor mods / trivial mods, but I don't think they need to be explicitly classified - a merge program can make a more nuanced and accurate determination of the ability to be merged.  It seems likely that you would only be able to use one major mod, but potentially many minor or trivial mods together if they don't conflict. 

[King Mir]

This tool hopefully would allow people to merely derive patches between two versions of the game [raw's specifically], and then apply that patch to another mod, no matter what version of that mod is.  Lofty goal I know.

The mod's in question will be based on pre-derived patch files.  I could use patch files as is, but it would be far better to also log the object that is being modded ahead of time and put that in the patch file for easier patch application.

I'm confused here. What would it take to make a mod workable with your tool idea? would I be able to take a random mod and easily add it to your tool, or would the mod need to be specifically written to work with your tool. Are you going to invent a DSL for mod patching?

[thistleknot]

I'm hoping to read a raw file. Load all its values as either tokens (tags) or comments. Then compare tokens with another mod. Some tokens will be noticed missing and some added between two versions. That is what I hope yo achieve vs a standard diff file.

I got my classes setup for my tokens. I figure by tonight I'll have all the tokens at least loaded from a file

[milo christiansen]

I could play around with tag-wise diffs some when I get home, maybe I can come up with a nice algorithm and plain text representation

Maybe I can come up with something that gives you some nice ideas, I guess we'll see.

It seems that there is a lot of interest in a DF-centric diff format lately...