September 21, 2017, 01:45:18 AM

Author Topic: ModCooker!  (Read 2656 times)

Merry76

  • Moderator
  • Hero Member
  • *****
  • Posts: 3448
    • View Profile
ModCooker!
« on: August 16, 2015, 11:56:50 AM »
Alright folks, the ModCooker works, sort of. You can get yourself the .EXE from here:

ModCooker.exe
ModCookerSettings.xml

Now, what actually _is_ ModCooker? To put it simple: its a very easy-to-use Tool that Merges the Gnomoria Mods in the order you want them to, creating the mod you want.

Too confusing? Let me make an example: You want to play the GlassWorks Mod, but want to dabble with the weapon values. Until now, you would have to take the GlassWorks Mod, and dabble with the items.xml, then play it. If there is a new version of Glassworks, you would have to do your re-dabbling again, most likely resulting in typing errors and whatnot. Also typing work you dont exactly enjoy, because staring at XML for a hour can feel like work (and it really is).

Now how does ModCooker handle this?
First, you drop the EXE into your Gnomoria Folder. Let your Virus scanner scan it - it should be found guiltless of being a virus, because I am not a good enough programmer to create a virus  8)
Now Create a folder for your items.xml (and whatever you want to change too) dabblings lets call it "MyChanges" - you can keep the original folder, or just place it in the "MyChanges" Folder - ModCooker will find it.
Play with the values. Now the important bit: to keep maximum effect from ModCooker, delete the XML of all objects you dont want to change! Indeed, if you want to just mod swords, create a XML with just the sword values. Dont forget to save.
Fire up ModCooker. That one was easy.
Give your new Mod a name: GlassWorksWithMyChanges for example. You can be more creative, we dont mind. Now add the Mods in the order you want them applied:

Mod Files (Vanilla Gnomoria)
Glassworks (The excellent Mod by gcook725)
MyChanges (The thing you dabbled with, making swords super).

Now press "Cook Mod". ModCooker will now get Vanilla Gnomoria, and add everything new from GlassWorks to it, overwriting everything from Vanilla what both GlassWorks and Vanilla share. It will then take your Mychanges, and do the same. Finally, it will create a Receipe named "ModCookerReceipe.xml" - In this Receipe it knows what you entered by hand. Should you want to re-cook the mod (lets say tone down those swords again, or apply the newest patch from GlassWorks), just load up GlassWorksWithMyChanges with "LoadModReceipe" - you can re-Cook it with 2 clicks. Sexy, eh?

Now, this is the first release, and I kind of wanted it to do more and be more useful. But then again, I kind of need input: does it work for you, etc. Also Ideas on how to do it better would be appreciated. Please dont de-compile it and tell me its written with bad style, I already know that (I am a database administrator by trade, I code for fun). It works, and you didnt do it so a bit of bad style is Ok - I think. Also, I re-learned coding in the last few days, and re-wrote the whole thing about three times in all.

What doesnt work yet:

Other merge instructions. Currently ModCooker uses always "overwrite". I thought of a few more (merge, delete), but to add them I probably need to increase the complexity of the User Interface - and I kind of shun that right now.


Edit: 2 new features went in, so I updated the mainpost accordingly.
« Last Edit: August 22, 2015, 03:26:51 AM by Merry76 »
Have a problem or a fortress so awesome it needs to be shared?

Well, go on, dont be shy! Use the GnomeworldPool Dropbox account!
How to share Savegames

Scmadar

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: ModCooker!
« Reply #1 on: August 16, 2015, 12:45:01 PM »
Great work! I've been waiting for something like this :) (and trying to write my own, slowly, while I waited)

Could you post your source code for the rest of us programmers to see? (also what language did you work in?) We might have ideas for things to make mo better. We promise we won't laugh or make snide comments. Or steal your code, much.
Of course bad style is okay, style comes after utility unless you're working with a group.

I have a utility written in Python that will merge tilesheets and fix the Sprites.xml values, I'll clean it up a bit (e.g. make it readable) and post it in a bit.

Splitting the xml values into nice parse-able objects is hard, yeah. I am trying to use a recursive comparison type thing, where things are identified by some unique text within their subtree - and can have child trees to search through too. For example:  Items are identified by their ID, Jobs by their Type, and overwriting a Job that differs from the source means that each mod must be mutually exclusive in the things it changes (no two mods can edit the same Job (like BuildWall) or one of them will be overriden). So, to combat that, recursion - within each Job, also compare lists of ConstructionID's - update those children instead of the entire Job. It's painfully slow to go through all the xml and identify all these things, but I think it'll be the best bet until the vanilla game merges mods or major changes happen to the framework.

Merry76

  • Moderator
  • Hero Member
  • *****
  • Posts: 3448
    • View Profile
Re: ModCooker!
« Reply #2 on: August 16, 2015, 01:22:03 PM »
I have choosen C# to code it. Its free, and its rather easy to use and well documented. And I learned to code by analyising excel macros...  ;)

I have zipped the project and uploaded it to dropbox. Anyone can see what I did, and steal/reuse whatever they like. I dont think its the bees knees anyway...

https://www.dropbox.com/s/xt72qd1olwe46lf/ModCooker.zip?dl=1

I will continue to develop it further though. I have seen that it currently treats all files the same (for example, it really botches up the tilesheet.png, treating it as an xmlwhole and butchering it in the process...). Also, I have contacted RoboB0b about the different ID's that the XML files use (for example, ammo has a "special" AmmoID - there is little reason for it to not use the tag "ID" as items and materials do... its just a hassle to have a special case for almost every xml I read).
« Last Edit: August 17, 2015, 12:55:57 PM by Merry76 »
Have a problem or a fortress so awesome it needs to be shared?

Well, go on, dont be shy! Use the GnomeworldPool Dropbox account!
How to share Savegames

seronis

  • Hero Member
  • *****
  • Posts: 600
    • View Profile
Re: ModCooker!
« Reply #3 on: August 17, 2015, 05:46:56 AM »
Public Service Announcement.

If you post a dropbox link for the love of god change   dl=0  to  dl=1  so that people downloading dont get the splash page spam and just "get the download".

Merry76

  • Moderator
  • Hero Member
  • *****
  • Posts: 3448
    • View Profile
Re: ModCooker!
« Reply #4 on: August 17, 2015, 12:56:43 PM »
If you post a dropbox link for the love of god change   dl=0  to  dl=1  so that people downloading dont get the splash page spam and just "get the download".

I didnt know that. Changed it, of course.
Have a problem or a fortress so awesome it needs to be shared?

Well, go on, dont be shy! Use the GnomeworldPool Dropbox account!
How to share Savegames

gcook725

  • Sr. Member
  • ****
  • Posts: 262
  • Check out Glassworks!
    • View Profile
Re: ModCooker!
« Reply #5 on: August 18, 2015, 09:34:16 AM »
Thanks for mentioning my mod ;D

Anyways, a few questions.

1) What should mod authors keep in mind when making things compatible with Modcooker?
2) Does mod cooker combine tilesheets too?
3) What happens if multiple mods modify the same item? For example I edit tables in Glassworks to include tables made of glass as a material so that I wouldn't have to make a special new item ONLY for glass tables (which would be unintuitive).

Check out my first mod: Glassworks!
It has windows!
Also, check out my Twitter!

Merry76

  • Moderator
  • Hero Member
  • *****
  • Posts: 3448
    • View Profile
Re: ModCooker!
« Reply #6 on: August 18, 2015, 11:20:30 AM »
Dont mention it :)

As for your questions: for the moment, ModCooker is in its very, very early early stages. It can only handle a few of the xml files as I intend them to be (mainly because the whole "ID" thing - I contacted RoboB0b for this, but he is probably still occupied with PAX or something). When I know we will stick with the currend 3rd level identifiers for "Items", I will implement them accordingly.

1) If you want to maximise ModCooker compatibility, only include the data that actually differs from vanilla. Its easier for you to maintain, and ModCooker will glue it together with vanilla with ease (once the ID thing is done properly, of course).
2) Not yet, but its the next thing going in. I will probably use special class that holds all sprites indipendently (checking for duplicates), and then put it together again into one tilesheet. The "put it together into one tilesheet" is actually the hard part, believe me. Reading Sprites out and pasting them together is rather simple, but arranging them without jumbling them every time... eludes me at the moment. There are probably several ways to do this... I might play around with it for a while.
3) Currently, the only method of writing a the mod is by overwriting the definition that was already there. So basically if you place your mod first, your table definition gets entirely overwritten by the next mod that touches the "table" object. This is why its important that someone who balances weapons does not include the definitions of tables in his mod, hence crippling yours. I plan to do a more elaborate "merge" behaviour, which merges both attributes. So if someone has modded the table to include strawberries, and you did add glass, both strawberries and glass are valid options in the final mod. As you can see, this will probably not work with every XML file. Also, a few of them are simple definitions, there isnt much to be modded - I do think its perfectly save to keep them "as is" and not mess with them.
Have a problem or a fortress so awesome it needs to be shared?

Well, go on, dont be shy! Use the GnomeworldPool Dropbox account!
How to share Savegames

Scmadar

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: ModCooker!
« Reply #7 on: August 19, 2015, 05:04:13 PM »
Sorry for the wait! When I said 'in a bit', I really meant Soon™.

Here's my python utility to mash spritesheets together!

It's written in Python 2.7, so it will not (currently) run on Python 3. If this is an issue for anyone I will work on porting it to 3.3

https://www.dropbox.com/s/70vtdysj1034qym/spritepacker.zip?dl=1

To use it, simply unzip it anywhere and run spritepacker.py from the command line. Help is available using the -h option. In brief, pass it the names of all the mod folders you want to use, and watch it do its thing! At the end, copy over the created default.png and Sprites.xml files to their proper places in the folder created by Merry's awesome utility, and run the game.

Let me know how it works for you! If you run across any issues please tell me so I can fix them :)

----------
Soon™ is a registered trademark of Blizzard Entertainment, Inc. All rights reserved.

gcook725

  • Sr. Member
  • ****
  • Posts: 262
  • Check out Glassworks!
    • View Profile
Re: ModCooker!
« Reply #8 on: August 20, 2015, 09:15:37 AM »
Dont mention it :)

As for your questions: for the moment, ModCooker is in its very, very early early stages. It can only handle a few of the xml files as I intend them to be (mainly because the whole "ID" thing - I contacted RoboB0b for this, but he is probably still occupied with PAX or something). When I know we will stick with the currend 3rd level identifiers for "Items", I will implement them accordingly.

1) If you want to maximise ModCooker compatibility, only include the data that actually differs from vanilla. Its easier for you to maintain, and ModCooker will glue it together with vanilla with ease (once the ID thing is done properly, of course).
2) Not yet, but its the next thing going in. I will probably use special class that holds all sprites indipendently (checking for duplicates), and then put it together again into one tilesheet. The "put it together into one tilesheet" is actually the hard part, believe me. Reading Sprites out and pasting them together is rather simple, but arranging them without jumbling them every time... eludes me at the moment. There are probably several ways to do this... I might play around with it for a while.
3) Currently, the only method of writing a the mod is by overwriting the definition that was already there. So basically if you place your mod first, your table definition gets entirely overwritten by the next mod that touches the "table" object. This is why its important that someone who balances weapons does not include the definitions of tables in his mod, hence crippling yours. I plan to do a more elaborate "merge" behaviour, which merges both attributes. So if someone has modded the table to include strawberries, and you did add glass, both strawberries and glass are valid options in the final mod. As you can see, this will probably not work with every XML file. Also, a few of them are simple definitions, there isnt much to be modded - I do think its perfectly save to keep them "as is" and not mess with them.

Ah, so still on the simpler side (I figured it would be due to the length of time since you said you'd start working on it and when you released it).

A programming friend of mine and I were discussing how to properly fuse mods together completely. The best solution I could come up without requiring mod authors jump through a bunch of hoops was having the default files as a reference and then having the mod "stitcher" compare to see where the differences were and then overwrite the differences, adding/removin things that were required.

Alternatively, there could be a code system that modders can use for the program to recognize which tells the program where all the changes that were made to the default code would be placed, or something like that. But that could be complicated since that would probably require modifications of the default mod files that modders would use to have already defined codes for all of the default content.

Either way, a "standards of practice" for modders might be best so that everyone is on the same page when creating their mods. Things like proper documentation, properly modifying default items, etc. I've been meaning to write a sort of thing like this for a while, I just haven't gotten around to it... just like I've been meaning to update Glassworks to the most recent RC for the last several weeks, though that's mostly due to a restructuring of the mod that I've been planning. Now that there is some Steam Workshop support, I might look into a quick compatibility update here in another week or so, and possibly writing up a rough draft for the Standards of Practice to show and see what other people think of it, as well as what kinds of suggestions might show up. Definitely wouldn't be before Sunday though, since I work every day at least up until that point.

Check out my first mod: Glassworks!
It has windows!
Also, check out my Twitter!

Merry76

  • Moderator
  • Hero Member
  • *****
  • Posts: 3448
    • View Profile
Re: ModCooker!
« Reply #9 on: August 22, 2015, 03:22:00 AM »
New version! Lots of good stuff, or so I think:

After I got some "Insider Info", I deceided to catch the Identification of Modding items on the userlevel - not in my code. This means that ModCooker now needs a ModCookerSettings.xml to run properly.
https://www.dropbox.com/s/7dg3le8zbk6hc84/ModCookerSettings.xml?dl=1
In there, you can configure how ModCooker should handle the files. Let me elaborate:

This is ammo.xml:
Code: [Select]
<Ammo>
  <Item>
    <AmmoID>MusketRound</AmmoID>
    <WeaponSize>12.0</WeaponSize>
    <Damage>Pierce</Damage>
    <Point>1</Point>
    <VelocityModifier>25.0</VelocityModifier>
  </Item>

  <Item>
    <AmmoID>Bolt</AmmoID>
    <WeaponSize>20.0</WeaponSize>
    <Damage>Pierce</Damage>
    <Point>1</Point>
    <VelocityModifier>10.0</VelocityModifier>
  </Item>
</Ammo>

What we want, is that ModCooker recognizes both "MusketRound" and "Bolt" as unique, moddable items. Afterall, its clear that this is the case. However, ModCooker is stupid and has to be told this. So we add this to ModCookerSettings.xml:

Code: [Select]
<configuration>
  <file>
    <FileName>ammo.xml</FileName>
    <IDToIdentify>AmmoID</IDToIdentify>
  </file>
.... (the rest goes/stays here)

Edit: I updated the ModCookerSettings.xml now. It contains everything I think can be automatically parsed and merged by replacing these items.

Sprite Merging works now, gives you a preview of the tilesheet it cooks together (rather ugly because magenta isnt easy on the eyes, but whatever). Note that it takes a lot of time to merge bigger tilesheets - reason for this is that it first compares if the SpriteID is already present (if it is, it just overwrites the old sprite with the new), then it checks if the sprite is already in use - this is a size first, then bit-by-bit comparisation. Its fast enough if it has to compare sprites a few dozend times, but if you add the standard spriteset to another one, it takes... a long time. Minutes even! Anyway, it works. Just dont place your mod in front of the vanilla mod, and you are fine - for performance reasons and to keep the tilesheet from changing all the time, it just takes the first tilesheet it finds "as is". Still "cooks" it though, so the magenta gets holes where the tilesheet isnt used. Should still work. Also, I use a default TileSheet of 1024x1024 - the time might come when this has to be adjustable, probably a setting in ModCookerSettings.xml - for now, I am happy that thing actually does something.

« Last Edit: August 22, 2015, 12:04:59 PM by Merry76 »
Have a problem or a fortress so awesome it needs to be shared?

Well, go on, dont be shy! Use the GnomeworldPool Dropbox account!
How to share Savegames

gcook725

  • Sr. Member
  • ****
  • Posts: 262
  • Check out Glassworks!
    • View Profile
Re: ModCooker!
« Reply #10 on: August 22, 2015, 09:58:06 AM »
I can kinda see what you're doing there with the newest update, but what might be interesting is to have the Modcooker look for a file created by the mod author that has a list of all modified/new objects in each file so that the ModCooker knows what to look for exactly. More work on the mod author's part, sure, but it might make the program easier to use and run more efficiently.

Check out my first mod: Glassworks!
It has windows!
Also, check out my Twitter!

Merry76

  • Moderator
  • Hero Member
  • *****
  • Posts: 3448
    • View Profile
Re: ModCooker!
« Reply #11 on: August 25, 2015, 11:35:10 PM »
Just to give you guys a heads up: development on this tool is halted because RoboB0b is coding his own implementation. If there is something official, there is little need for an indipendent solution.
Have a problem or a fortress so awesome it needs to be shared?

Well, go on, dont be shy! Use the GnomeworldPool Dropbox account!
How to share Savegames

seronis

  • Hero Member
  • *****
  • Posts: 600
    • View Profile
Re: ModCooker!
« Reply #12 on: August 28, 2015, 01:28:03 PM »
Curious is gnomoria the only game you play?  If you flesh it out a bit more the modcooker code might be useful to you on other games too

Merry76

  • Moderator
  • Hero Member
  • *****
  • Posts: 3448
    • View Profile
Re: ModCooker!
« Reply #13 on: August 29, 2015, 12:44:49 AM »
Its the only game I actually wanted to mod. I play a whole lot of other games, but when it comes to modding there I just am on the consumer side ;)
Have a problem or a fortress so awesome it needs to be shared?

Well, go on, dont be shy! Use the GnomeworldPool Dropbox account!
How to share Savegames