Power Crystals' Modding Tools

ShanRevan
Second-Lieutenant
Posts: 813
Joined: Mon 10 Feb 2014 04:46
Contact:

Power Crystals' Modding Tools

Postby ShanRevan » Mon 23 Mar 2015 14:21

Edit by Shifu: Topic locked. New topic can be found here http://forums.eugensystems.com/viewtopic.php?f=187&t=57927

OLD POST BELOW
============================================================================

Hi everyone. Meant to get this out ages ago but, well, shit happens.

This was originally intended to be released like a year ago but the author wanted to write up some more documentation and develop it a little more first, so we held off on releasing it. Anyway that didn't really work out and so here we are. The tool has a number of limitations that never got addressed, particularly in addressing nested map data types but is still very useful.

The tool is essentially a commandline interface for enohka's tool. You can use it to mass extract data from .dat files (warning: extracting a whole dat takes a very long time, and will give you a few gigabytes of XML files and folders from memory. Maybe not that much but it was a lot), or automatically apply changes specified in an XML file.

Oh yeah. one last thing. Don't match by instance ID's. You can do this but it's not version agnostic (although that may no longer matter).

You can get it here: WGPatcher 1.2
NOTE - It includes an (older) version of Enohka's tools. I recommend updating them, but it works fine either way. This is download link the author of the tools made.


I'll try and answer some questions as I have time, in the mean time I am providing a couple of example XML files from uralgraznomod

Transports.xml
Rifles.xml
TanksB.xml




I'll leave you with some quotes from the guy explaining the tool as he made it. presented from most recent to oldest.

A new version that I have 100% arbitrarily determined is 1.2.
The first argument is now the command you want it to perform; valid values at this time are "dump", "apply", "help", and "version".
"Dump" can now optionally have an ndfbin path to limit it to that ndfbin, and then optionally on top of that the name of a class to limit it to that class in that ndfbin.
There is a file (config.xml) in the zip that allows you to set the matchconditions that dump mode uses. It ships with default ones for TAmmunition and TUniteAuSolDescriptor. If a class is not present here, it will use __order.
Dump mode is also far more verbose instead of just being a black screen for half an hour.
I got tired of remembering whether I set the tag for creating instances to <ndfadd> or <ndfcreate> so now both work and do the exact same thing.
"Apply" can accept multiple patch XML files as commandline arguments (up to as many as Windows will let you pass). They will be processed in the order they were provided.
More detailed help text.
Numerous internal improvements that probably none of you will care about.

power crystals - about an earlier release wrote:Now supports <ndfcreate> and <ndfdelete> at the same level as <ndfpatch>. Both require the "ndf" and "table" attributes; <ndfcreate> needs nothing else but <ndfdelete> can have a <matchconditions> with all the usual rules about those (if you don't supply one, it will delete every instance of that class). The "__order" matchcondition value also now supports the special values of "first" and "last" which you can use to find the stuff you just added since by default they will have no values by doing something like this (which is in the included testpatch.xml file):

Code: Select all

   <ndfcreate ndf="pc\ndf\patchable\gfx\everything.ndfbin" table="TUniteAuSolDescriptor" />
   
   <ndfpatch ndf="pc\ndf\patchable\gfx\everything.ndfbin" table="TUniteAuSolDescriptor">
      <matchconditions>
         <matchcondition property="__order">last</matchcondition>
      </matchconditions>
      <changes>
         <change property="NameInMenuToken" type="LocalisationHash">8E14D59D2C0F8600</change>
         <change property="AliasName" type="WideString">TestString</change>
      </changes>
   </ndfpatch>


Also as shown it now supports LocalisationHash and WideString type properties so that should be everything you need for TUniteAuSolDescriptor and TAmmunition creation. I think.


power crystals - explanation, but for an even earlier version wrote:Ok, here's another one. Please read the disclaimers below before continuing because it's still not done, it's just less not done than before.

The format for <matchcondition> elements changed (value moved from the value attribute to the actual element value, ala <matchcondition ...>3</matchcondition>), the "reference" operation was folded into "set" because I figured out how to support those along the same code path, the "forcetype" attribute was renamed to just "type", and it now supports "append", "delete", and "clear" operations for manipulating lists. It also got slightly dumber about auto-detecting types of list elements. The dump mode should produce valid XML files that can be read back in, though it doesn't support every property type yet - if you run it on a TUniteAuSolDescriptor it'll yell about LocalizationHash and WideString properties. I'll get to those eventually. It also still doesn't support a more specific export than "the entire .DAT file". Again, it's on the list.

It also doesn't really support lists inside lists but I'm not sure you can actually do that as is anyway. If I'm wrong, please tell me.

With all the above caveats, you can theoretically use this thing right now provided you don't need to change one of the unsupported property types (if you do, tell me and I'll prioritize it). The example patch file has been updated with the current syntax, and that syntax should be relatively stable now. I ran one file each from TUniteAuSolDescriptor and TAmmunition and got it to stop giving errors except for the aforementioned types, but that's all the testing I have time for tonight. Let me know if it breaks.

Technical details, building one of the example mods as I go:

Each file opens with a [fixed]<wargamepatch>[/fixed] element. This contains one or more [fixed]<ndfpatch>[/fixed] elements. [fixed]<ndfpatch[/fixed] elements require two attributes, "ndf" which is set to the path of the ndfbin file in the .DAT being patched, and the name of the table (or class) in the .ndfbin this patch is affecting. It can also optionally have a "name" attribute which has no effect on the output but shows up in some of the error messages. If no name is provided, the patcher will assign a numeric value starting at 1. So so far:

Code: Select all

<wargamepatch>
   <ndfpatch ndf="pc\ndf\patchable\gfx\everything.ndfbin" table="TUniteAuSolDescriptor" name="KUBs for all">
   </ndfpatch>
</wargamepatch>


This doesn't actually do anything, though. Next, each [fixed]<ndfpatch>[/fixed] can contain a [fixed]<matchconditions[/fixed] element, which in turn contains a number of [fixed]<matchcondition>[/fixed] elements. These describe what parts of the table are affected by this patch. If you want to affect the entire table, you can leave out this section entirely. Each [fixed]<matchcondition>[/fixed] requires a "property" attribute naming the property being matched, and a value that is the value of the property being matched. To match the Polish Kub, we add this like so:

Code: Select all

<wargamepatch>
   <ndfpatch ndf="pc\ndf\patchable\gfx\everything.ndfbin" table="TUniteAuSolDescriptor" name="KUBs for all">
      <matchconditions>
         <matchcondition property="ClassNameForDebug">Unit_2K12_Kub</matchcondition>
      </matchconditions>
   </ndfpatch>
</wargamepatch>


Finally, each [fixed]<ndfpatch>[/fixed] contains a [fixed]<changes>[/fixed] element, which in turn contains a number of [fixed]<change>[/fixed] elements. Each change requires a "property" attribute naming the property being changed and a value as the value of the element. For simple values (numbers and strings) the raw value is fine; for more advanced types, there are some XML structures to represent things like references and maps. Look at some of the stuff it dumps for these. I'll document them in more detail another time.

[fixed]<change>[/fixed] elements can also have a "type" attribute naming the type being used, which may be necessary if you are changing the type of a property (this includes properties that are currently "Unset"!). It can also optionally have a "key" attribute for interacting with lists - if the list contains maps, the key is used to find a map with a matching key; otherwise, it is the numeric index of the list element (starting at 0). Finally, it can have an "operation" attribute. The default operation is "set", which just changes the value. The other values are "append" which adds the specified value to the end of the list; "delete", which deletes an element from a list (requires a "key" attribute), and "clear", which clears all elements from the list.

So to make a simple change, here's what it looks like to give those Kubs 8 cards:

Code: Select all

<wargamepatch>
   <ndfpatch ndf="pc\ndf\patchable\gfx\everything.ndfbin" table="TUniteAuSolDescriptor" name="KUBs for all">
      <matchconditions>
         <matchcondition property="ClassNameForDebug">Unit_2K12_Kub</matchcondition>
      </matchconditions>
      <changes>
         <change property="MaxPacks" type="UInt32">8</change>
      </changes>
   </ndfpatch>
</wargamepatch>


But if we want to set their price to $5, that's in a list, so you need to add the key, too:

Code: Select all

<wargamepatch>
   <ndfpatch ndf="pc\ndf\patchable\gfx\everything.ndfbin" table="TUniteAuSolDescriptor" name="KUBs for all">
      <matchconditions>
         <matchcondition property="ClassNameForDebug">Unit_2K12_Kub</matchcondition>
      </matchconditions>
      <changes>
         <change property="MaxPacks" type="UInt32">8</change>
         <change property="ProductionPrice" key="0" type="Int32">5</change>
      </changes>
   </ndfpatch>
</wargamepatch>


Now if you'd rather not write these things from scratch, running it without the second argument (so it's a .DAT only) will cause it to save every instance as its own XML file that you can look at to use as a base. Just rip out all the changes you don't actually want and start from that.

I hope that makes sense. Let me know if you have any further questions or if it blows up in your face.

[sub]e: uploaded one with a bad test patch; if you managed to download it in the like 30 seconds between when I posted this and I noticed try again[/sub]



power crystals - about the first release wrote:
It takes a .DAT file as the first argument and a .XML file as the second, and it will produce a "_patched.DAT" file next to the first one. It works for most basic things, but I want to get feedback on how useful this actually is before I do anything more complex. Included is a demonstration and 100% useful patch that gives the Polish KUB 8 cards at $5, sets all tanks to 1940, and gives Moto '90s the fuel truck death blast.

Note that it is not fast. There's some reasonably easy things I could do to make it faster with repeated patches of the same table but as above I don't want to bother until I know there's a demand for it.

So as to how it actually works:

The root is a "wargamepatch" element that contains zero or more "ndfpatch" elements. Each "ndfpatch" requires an "ndf" attribute that is the full path to the ndfbin file, and a "table" element that is the name of the table in the ndfbin file. It can optionally have a "name" attribute; this does nothing on its own but it will show up in the console output so it makes telling them apart easier (if you don't supply a name, it just names them 1, 2, 3...).

Each patch can have zero or more match conditions, specified as "matchcondition" elements under the "matchconditions" element. These have a "property" and a "value" attribute. Match conditions are applied in the order listed and will narrow the set of affected objects from everything in the listed table to whatever matches the specified condition. Because the id is determined when the ndfbin is compiled, you need to figure out yourself what to match on. As a last resort, you can use a special "__order" property which is the order in the list of instances (starting at 0). Multiple match conditions are treated as an AND.

Each patch will have zero or more changes, as "change" elements under the "changes" element. The value of the change element is the value written to the property. Each change has a "property" attribute which is the property affected by this change. It can also optionally have a "key" attribute, which is either the element number for lists (starting at 0) or the key if the collection is of maps. The key attribute is ignored for non-lists. Changes can also optionally have an "operation" attribute, which defaults to "set" if it is not present. "set" is a straight property set. The only other currently supported value is "reference", which is used for reference values as describing those is more difficult than a single text field can handle.

If the operation is set to "reference", the value is a "reference" element with a "table" attribute specifying the table containing the referenced object. The reference element can then contain another "matchconditions" set with the same rules as the ndfpatch element.

e: forgot this one:
If the value of a property is currently "Unset", the patcher will not be able to determine what type of value to use. In this case, you need to specify a "forcetype" attribute on the change element whose value is whatever the mod tool GUI shows you.

If all of that made your head hurt, go look at the xml file included in the download which demonstrates basically everything I just said.

Things you cannot do right now include but may not be limited to:
- Match based on references, lists or maps
- Add or remove elements from lists
- Set references in lists
- Set things to null
- Change the keys of maps
- Pretty much anything involving strings
- Change any non-NDF files (localization, images, whatever)

I am really curious about any feedback on this thing but even if it's the worst thing ever it was at least fun to write so I'm pretty happy. It has reasonable error handling but isn't perfect, so if you get something that isn't descriptive enough show me the patch file you're working with so I can figure out what went wrong.

User avatar
MenDuck
Major
Posts: 1880
Joined: Sat 6 Sep 2014 23:03
Contact:

Re: Power Crystals' Modding Tools

Postby MenDuck » Mon 23 Mar 2015 16:12

Great job! The W:AB Noob will be pleased :twisted:

User avatar
Darkmil
Brigadier
Posts: 3025
Joined: Mon 29 Oct 2012 15:17
Location: Massy
Contact:

Re: Power Crystals' Modding Tools

Postby Darkmil » Mon 23 Mar 2015 21:29

:shock:
:twisted:
MINE !!!
Image

User avatar
Narcissistic Black
Major
Posts: 1892
Joined: Tue 14 Jan 2014 01:58
Contact:

Re: Power Crystals' Modding Tools

Postby Narcissistic Black » Mon 23 Mar 2015 21:30

Yes he will be pleased.
The First Narcissist
Image
Click signature to see Modification, Alpha Released. Try now.

Guggy
General
Posts: 8645
Joined: Thu 17 Nov 2011 02:53
Location: peaceful skeleton realm
Contact:

Re: Power Crystals' Modding Tools

Postby Guggy » Mon 23 Mar 2015 22:07

Extremely powerful tool, glad the release went public! :) Did you finally manage to make contact with him again, Shan?

User avatar
F.F.R. Wetherby
Specialist
Posts: 18
Joined: Mon 23 Mar 2015 22:06
Contact:

Re: Power Crystals' Modding Tools

Postby F.F.R. Wetherby » Mon 23 Mar 2015 22:10

Hello and many thank for this tool,

I just have a problem, i have download the tool, put all file on my desktop and launch Wgpatcher.exe for see what this tool is able to do and when i lauch the game nothing appear. I just want to ask if i have missing something like a path file for the exe.

Thank in advance.

Sorry for bad english.
Force Française de Ruse, clan français COH2,W:RD et ARMA 3, viendez nombreux:


http://ffrforum.clicforum.fr/portal.php

User avatar
jonas165
Brigadier
Posts: 3109
Joined: Sun 13 Oct 2013 06:01
Contact:

Re: Power Crystals' Modding Tools

Postby jonas165 » Mon 23 Mar 2015 22:28

Ohh this looks awesome! Thanks alot, I will try it out ASAP.
Image
Alpha release. Click signature for more

User avatar
The W:AB Noob
Lieutenant General
Posts: 4568
Joined: Fri 12 Jul 2013 22:29
Location: United States, Central Time Zone
Contact:

Re: Power Crystals' Modding Tools

Postby The W:AB Noob » Mon 23 Mar 2015 23:51

MenDuck wrote:Great job! The W:AB Noob will be pleased :twisted:

YESYESYESYESYES!!!!!!!!!!

THE DAY HAS COME!

THANK YOU SHAN! (And Power Crystals?)
Image
W:RD Sandbox Mod 5.4.3 Click -> Image

ShanRevan
Second-Lieutenant
Posts: 813
Joined: Mon 10 Feb 2014 04:46
Contact:

Re: Power Crystals' Modding Tools

Postby ShanRevan » Tue 24 Mar 2015 03:14

F.F.R. Wetherby wrote:Hello and many thank for this tool,

I just have a problem, i have download the tool, put all file on my desktop and launch Wgpatcher.exe for see what this tool is able to do and when i lauch the game nothing appear. I just want to ask if i have missing something like a path file for the exe.

Thank in advance.

Sorry for bad english.

Hi. It's a commandline tool. That means you can't just click on it to open it up. You have to open the commandline (ie cmd.exe) and navigate to the folder it's in (hint: hold down shift, then right click in the folder with it and click on "open command window here") , then type in commands. It makes things a lot simpler if you put all the input files in that folder as well (ie the DAT you are editing and the XML files).

User avatar
kvnrthr
Chief Warrant Officer
Posts: 518
Joined: Mon 10 Sep 2012 13:29
Location: Jakarta, Indonesia
Contact:

Re: Power Crystals' Modding Tools

Postby kvnrthr » Tue 24 Mar 2015 04:53

As someone who has no idea how to mod, what is the difference between this mod tool and the regular one?
Hoping for a better next-gen Wargame and new engine in a few years...
One can dream ;_;

Return to “Modding”

Who is online

Users browsing this forum: No registered users and 14 guests