hi.
i'll explain more bits detail about the tool i had implied at URL Redirection ... topic.

i'm developing new tool D3modman.
D3modman will verify your Doom3 installation and show what required files are missing or hidden by influence of numerious installed MODs.
D3modman's behavior is based on knowledge of numerious MOD verfication info.
the knowledge is scripted by several xml files.

one screenshot from developing ver is avail:
http://homepage3.nifty.com/kkdf/images/ ... 604.01.png

1. why verification for Doom 3 installation?

it is NOT required to verify your Doom 3 installation by D3modman AT ALL in ANY REASON.
D3modman will just provide you a way to make sure a certain MOD MAY work correctly.

the problem is that, there is latent possibility that any files in pk4 file, distributed by a MOD, may be overridden by other pk4 file supplied by other MOD.

for example:
a file "def/weapon_soulcube.def" is in pak000.pk4.
ZZ-DEditCleanDefsV1.pk4, the part of entity def cleanup pakage developed by by Eutectic, also contains "def/weapon_soulcube.def".
if you install def cleanup package, your original "def/weapon_soulcube.def" file distributed by id Software will be overridden.
because the pk4 name "ZZ-DEditCleanDefsV1.pk4" precedes "pak000.pk4" by filesystem inside Doom 3. (the first character "Z" precedes an one "p".)
so, the collided file "def/weapon_soulcube.def" is replaced with "ZZ-DEditCleanDefsV1.pk4".

as well, when you install new MOD to your Doom 3 installation, can you make sure that any files won't be overriden by already installed MODs?
if any unexcepted collision exists, Doom 3 may imply you the problem by displaying a message line such as "entity type monster_xxx not defined".

D3modman will help you to make sure existence of any file collisions.

* i don't say def cleanup package may cause any problems by file collision, explicitly. i just mentioned that the package just overrides some files contained in original Doom 3 instllation.
* although i sometimes say such as "the files are overriden", the real files in your folder will NOT be overriden. Doom 3 engine formally overrides the files inside engine while game play.

2. how to verify

it is easy.
to verify a certain MOD is ready and activated, satisfy all of next criteria.
a) required files (such as .map/.proc/.mtr), which are distributed by MOD author, stay on your Doom 3 base folder or other MOD folder.
b) their files are not overridden by indirect way with other MOD installation. indirect way means latent dangerous possibility that a pk4 file from other MOD may override any required files for target MOD.

3. generally, what's xml

XML is a text file format, like HTML, recommended by w3c.

XML's main purpose is to script various kind of data and to exchange them between applications.

next column page has easy introduce about XML and good comparation between XML and HTML.

An XML primer
http://studio.tellme.com/general/xmlprimer.html

4. format of xml for D3modman
4.1. terms

i use the words "ModMan xml" (unofficial Doom 3 MOD managing, xml format) to point a xml format used by D3modman.

i sometimes use "ModMan app" to represent a program which uses ModMan xml.

4.2. root objects in ModMan xml

each ModMan xml has a root element "site".

site contains 1 or more root objects recognized by ModMan app.

currently, 3 known root object types are: package, deployment, distribution objects

4.3. 3 name types in ModMan app

each object has distinct names so that you can identify target object.

3 name types are: myname, localname, qname

myname is a name scripted in ModMan xml

myname also has a concept local name/global name.
local is used by a certain ModMan xml. local name cannot be referenced by other ModMan xml.
for example, to represent a "xxxyyyzzz MOD v1.0" package.

global is used by many ModMan xml. global name can be referenced by 1 or many other ModMan xml.
for example, to represent a "Doom3 v1.0" package.
global one is used by dependency concept, some package object in any ModMan xml may point any global names to describe "requirement".

myname also has namespace concept like following format.
a) "my package name"
b) "::my package name"
c) "my namespace::my package name"

a) and b) represents a local package name format.
c) represents a global package name format.

localname is a kind of qualified name displayed by ModMan app

qname is a qualified name internally used by ModMan app

sample 1a: if you have a name "my_package" for package object in test.xml, 3 names should be,
myname = "my_package"
localname -> "test.xml::my_package"
qname -> "Package_t::test.xml::my_package"

sample 1b: it is good idea to include your name as author into myname as namespace.
myname = "author name::my_package"
localname -> "author name::my_package"
qname -> "Package_t::author name::my_package"

4.4. object tree in ModMan xml

Code:

+ site
|
+--+ deployment ...
|  |
|  +--+ file ...
|
+--+ distribution ...
|  |
|  +--+ file ...
|
+--+ package ...
   |
   +--+ header ...

... means the element repeats 1 or more times.

4.5. package root object

pacakge object represents a "MOD".
package also points deployment and distribution objects to represent composition elements.

package element has next format

Code:

<package
   deployment   ="deployment_name"
   disrtibution ="disrtibution_name"
   favicon      ="ico_file_name"
   game_dir     ="base_or_your_mod_folder"
   name         ="package_name"
>
   <header ...></header> ...
</package>

4.6. deployment root object

deployment object represents required files to run on Doom 3 as a MOD.
deployment element includes 1 or more file objects.

Code:

<deployment
   name="deployment_name"
>
   <file ... ></file> ...
</deployment>

4.7. distribution root object

distribution object represents what file do you distribute with your MOD package (e.g. files in .zip file).
distribution element includes 1 or more file objects.

Code:

<distribution
   name="distribution_name"
>
   <file ... ></file> ...
</distribution>

4.8. file object

file object represents a file entity.
if a file object in;
... deployment, it represents a file recognized by Doom 3 engine. name format is like "def/player.def".
... distribution, it represents a file in your drive. such as "doom3.exe", "base/pak000.pk4", "base/game00.pk4".

Code:

<file
   name        ="filename"
   hash_CRC32  ="checksum"
   hash_MD5    ="strong_hash"
   size        ="filesize"
   mtime       ="file_modified_time"
   cl_severe   ="needed_file_at_client_side"
   sv_severe   ="needed_file_at_server_side"
   name_prefix ="base_or_your_mod_folder"
>
</file>

"name" is file name. format is depends on parent element (distribution, deployment).
"hash_CRC32" has 8 digit hexadecimal integer form.
"hash_MD5" has 32 digit hexadecimal integer form.
"size" has interger format.
"mtime" has date time format like "YYYY/MM/DD hh:nn:ss".
"cl_severe" is "0" or "1".
"sv_severe" is "0" or "1"
"name_prefix" is like "base" or "mymod". folder name in your Doom 3 install folder.

i'll complete this document once more later...

EDIT: section 3 and 4 updated (29 Nov).

Nice tool. So based on what you're saying even though you have your mod files in your own folder there's still the potential for items to be over written?

I'll move this to the D3mods thread where it'll get more notice.

thanks kat.
about goal/solution of the tool, you points well!

i had 2 motives to start this one.

1. to solve potential over written issue for items
as kat mentioned, and as you know, "overwritten" issue is difficult potential problem, when you install new MOD.

2. to try unknown published MOD for you
thru this chance, there will be a big database, which has list of numerious MOD packages.
it will be very fun to search various kind of MOD you don't try yet (map MOD, weapon MOD, ...).

Wow, very nice. Super damn useful, I was thinking it would be nice to have something check files like this for me for quite some time now.

Very useful tool for me and explained very detail :wink:

Nice one!

hi.
i'll explain more bits detail about the tool i had implied at URL Redirection ... topic.

i'm developing new tool D3modman.
D3modman will verify your Doom3 installation and show what required files are missing or hidden by influence of numerious installed MODs.
D3modman's behavior is based on knowledge of numerious MOD verfication info.
the knowledge is scripted by several xml files.

one screenshot from developing ver is avail:
http://homepage3.nifty.com/kkdf/images/ ... 604.01.png

1. why verification for Doom 3 installation?

it is NOT required to verify your Doom 3 installation by D3modman AT ALL in ANY REASON.
D3modman will just provide you a way to make sure a certain MOD MAY work correctly.

the problem is that, there is latent possibility that any files in pk4 file, distributed by a MOD, may be overridden by other pk4 file supplied by other MOD.

for example:
a file "def/weapon_soulcube.def" is in pak000.pk4.
ZZ-DEditCleanDefsV1.pk4, the part of entity def cleanup pakage developed by by Eutectic, also contains "def/weapon_soulcube.def".
if you install def cleanup package, your original "def/weapon_soulcube.def" file distributed by id Software will be overridden.
because the pk4 name "ZZ-DEditCleanDefsV1.pk4" precedes "pak000.pk4" by filesystem inside Doom 3. (the first character "Z" precedes an one "p".)
so, the collided file "def/weapon_soulcube.def" is replaced with "ZZ-DEditCleanDefsV1.pk4".

as well, when you install new MOD to your Doom 3 installation, can you make sure that any files won't be overriden by already installed MODs?
if any unexcepted collision exists, Doom 3 may imply you the problem by displaying a message line such as "entity type monster_xxx not defined".

D3modman will help you to make sure existence of any file collisions.

* i don't say def cleanup package may cause any problems by file collision, explicitly. i just mentioned that the package just overrides some files contained in original Doom 3 instllation.
* although i sometimes say such as "the files are overriden", the real files in your folder will NOT be overriden. Doom 3 engine formally overrides the files inside engine while game play.

2. how to verify

it is easy.
to verify a certain MOD is ready and activated, satisfy all of next criteria.
a) required files (such as .map/.proc/.mtr), which are distributed by MOD author, stay on your Doom 3 base folder or other MOD folder.
b) their files are not overridden by indirect way with other MOD installation. indirect way means latent dangerous possibility that a pk4 file from other MOD may override any required files for target MOD.

3. generally, what's xml

XML is a text file format, like HTML, recommended by w3c.

XML's main purpose is to script various kind of data and to exchange them between applications.

next column page has easy introduce about XML and good comparation between XML and HTML.

An XML primer
http://studio.tellme.com/general/xmlprimer.html

4. format of xml for D3modman
4.1. terms

i use the words "ModMan xml" (unofficial Doom 3 MOD managing, xml format) to point a xml format used by D3modman.

i sometimes use "ModMan app" to represent a program which uses ModMan xml.

4.2. root objects in ModMan xml

each ModMan xml has a root element "site".

site contains 1 or more root objects recognized by ModMan app.

currently, 3 known root object types are: package, deployment, distribution objects

4.3. 3 name types in ModMan app

each object has distinct names so that you can identify target object.

3 name types are: myname, localname, qname

myname is a name scripted in ModMan xml

myname also has a concept local name/global name.
local is used by a certain ModMan xml. local name cannot be referenced by other ModMan xml.
for example, to represent a "xxxyyyzzz MOD v1.0" package.

global is used by many ModMan xml. global name can be referenced by 1 or many other ModMan xml.
for example, to represent a "Doom3 v1.0" package.
global one is used by dependency concept, some package object in any ModMan xml may point any global names to describe "requirement".

myname also has namespace concept like following format.
a) "my package name"
b) "::my package name"
c) "my namespace::my package name"

a) and b) represents a local package name format.
c) represents a global package name format.

localname is a kind of qualified name displayed by ModMan app

qname is a qualified name internally used by ModMan app

sample 1a: if you have a name "my_package" for package object in test.xml, 3 names should be,
myname = "my_package"
localname -> "test.xml::my_package"
qname -> "Package_t::test.xml::my_package"

sample 1b: it is good idea to include your name as author into myname as namespace.
myname = "author name::my_package"
localname -> "author name::my_package"
qname -> "Package_t::author name::my_package"

4.4. object tree in ModMan xml

Code:

+ site
|
+--+ deployment ...
|  |
|  +--+ file ...
|
+--+ distribution ...
|  |
|  +--+ file ...
|
+--+ package ...
   |
   +--+ header ...

... means the element repeats 1 or more times.

4.5. package root object

pacakge object represents a "MOD".
package also points deployment and distribution objects to represent composition elements.

package element has next format

Code:

<package
   deployment   ="deployment_name"
   disrtibution ="disrtibution_name"
   favicon      ="ico_file_name"
   game_dir     ="base_or_your_mod_folder"
   name         ="package_name"
>
   <header ...></header> ...
</package>

4.6. deployment root object

deployment object represents required files to run on Doom 3 as a MOD.
deployment element includes 1 or more file objects.

Code:

<deployment
   name="deployment_name"
>
   <file ... ></file> ...
</deployment>

4.7. distribution root object

distribution object represents what file do you distribute with your MOD package (e.g. files in .zip file).
distribution element includes 1 or more file objects.

Code:

<distribution
   name="distribution_name"
>
   <file ... ></file> ...
</distribution>

4.8. file object

file object represents a file entity.
if a file object in;
... deployment, it represents a file recognized by Doom 3 engine. name format is like "def/player.def".
... distribution, it represents a file in your drive. such as "doom3.exe", "base/pak000.pk4", "base/game00.pk4".

Code:

<file
   name        ="filename"
   hash_CRC32  ="checksum"
   hash_MD5    ="strong_hash"
   size        ="filesize"
   mtime       ="file_modified_time"
   cl_severe   ="needed_file_at_client_side"
   sv_severe   ="needed_file_at_server_side"
   name_prefix ="base_or_your_mod_folder"
>
</file>

"name" is file name. format is depends on parent element (distribution, deployment).
"hash_CRC32" has 8 digit hexadecimal integer form.
"hash_MD5" has 32 digit hexadecimal integer form.
"size" has interger format.
"mtime" has date time format like "YYYY/MM/DD hh:nn:ss".
"cl_severe" is "0" or "1".
"sv_severe" is "0" or "1"
"name_prefix" is like "base" or "mymod". folder name in your Doom 3 install folder.

i'll complete this document once more later...

EDIT: section 3 and 4 updated (29 Nov).

Nice tool. So based on what you're saying even though you have your mod files in your own folder there's still the potential for items to be over written?

I'll move this to the D3mods thread where it'll get more notice.

thanks kat.
about goal/solution of the tool, you points well!

i had 2 motives to start this one.

1. to solve potential over written issue for items
as kat mentioned, and as you know, "overwritten" issue is difficult potential problem, when you install new MOD.

2. to try unknown published MOD for you
thru this chance, there will be a big database, which has list of numerious MOD packages.
it will be very fun to search various kind of MOD you don't try yet (map MOD, weapon MOD, ...).

Wow, very nice. Super damn useful, I was thinking it would be nice to have something check files like this for me for quite some time now.

Very useful tool for me and explained very detail :wink:

Nice one!

hi.
i'll explain more bits detail about the tool i had implied at URL Redirection ... topic.

i'm developing new tool D3modman.
D3modman will verify your Doom3 installation and show what required files are missing or hidden by influence of numerious installed MODs.
D3modman's behavior is based on knowledge of numerious MOD verfication info.
the knowledge is scripted by several xml files.

one screenshot from developing ver is avail:
http://homepage3.nifty.com/kkdf/images/ ... 604.01.png

1. why verification for Doom 3 installation?

it is NOT required to verify your Doom 3 installation by D3modman AT ALL in ANY REASON.
D3modman will just provide you a way to make sure a certain MOD MAY work correctly.

the problem is that, there is latent possibility that any files in pk4 file, distributed by a MOD, may be overridden by other pk4 file supplied by other MOD.

for example:
a file "def/weapon_soulcube.def" is in pak000.pk4.
ZZ-DEditCleanDefsV1.pk4, the part of entity def cleanup pakage developed by by Eutectic, also contains "def/weapon_soulcube.def".
if you install def cleanup package, your original "def/weapon_soulcube.def" file distributed by id Software will be overridden.
because the pk4 name "ZZ-DEditCleanDefsV1.pk4" precedes "pak000.pk4" by filesystem inside Doom 3. (the first character "Z" precedes an one "p".)
so, the collided file "def/weapon_soulcube.def" is replaced with "ZZ-DEditCleanDefsV1.pk4".

as well, when you install new MOD to your Doom 3 installation, can you make sure that any files won't be overriden by already installed MODs?
if any unexcepted collision exists, Doom 3 may imply you the problem by displaying a message line such as "entity type monster_xxx not defined".

D3modman will help you to make sure existence of any file collisions.

* i don't say def cleanup package may cause any problems by file collision, explicitly. i just mentioned that the package just overrides some files contained in original Doom 3 instllation.
* although i sometimes say such as "the files are overriden", the real files in your folder will NOT be overriden. Doom 3 engine formally overrides the files inside engine while game play.

2. how to verify

it is easy.
to verify a certain MOD is ready and activated, satisfy all of next criteria.
a) required files (such as .map/.proc/.mtr), which are distributed by MOD author, stay on your Doom 3 base folder or other MOD folder.
b) their files are not overridden by indirect way with other MOD installation. indirect way means latent dangerous possibility that a pk4 file from other MOD may override any required files for target MOD.

3. generally, what's xml

XML is a text file format, like HTML, recommended by w3c.

XML's main purpose is to script various kind of data and to exchange them between applications.

next column page has easy introduce about XML and good comparation between XML and HTML.

An XML primer
http://studio.tellme.com/general/xmlprimer.html

4. format of xml for D3modman
4.1. terms

i use the words "ModMan xml" (unofficial Doom 3 MOD managing, xml format) to point a xml format used by D3modman.

i sometimes use "ModMan app" to represent a program which uses ModMan xml.

4.2. root objects in ModMan xml

each ModMan xml has a root element "site".

site contains 1 or more root objects recognized by ModMan app.

currently, 3 known root object types are: package, deployment, distribution objects

4.3. 3 name types in ModMan app

each object has distinct names so that you can identify target object.

3 name types are: myname, localname, qname

myname is a name scripted in ModMan xml

myname also has a concept local name/global name.
local is used by a certain ModMan xml. local name cannot be referenced by other ModMan xml.
for example, to represent a "xxxyyyzzz MOD v1.0" package.

global is used by many ModMan xml. global name can be referenced by 1 or many other ModMan xml.
for example, to represent a "Doom3 v1.0" package.
global one is used by dependency concept, some package object in any ModMan xml may point any global names to describe "requirement".

myname also has namespace concept like following format.
a) "my package name"
b) "::my package name"
c) "my namespace::my package name"

a) and b) represents a local package name format.
c) represents a global package name format.

localname is a kind of qualified name displayed by ModMan app

qname is a qualified name internally used by ModMan app

sample 1a: if you have a name "my_package" for package object in test.xml, 3 names should be,
myname = "my_package"
localname -> "test.xml::my_package"
qname -> "Package_t::test.xml::my_package"

sample 1b: it is good idea to include your name as author into myname as namespace.
myname = "author name::my_package"
localname -> "author name::my_package"
qname -> "Package_t::author name::my_package"

4.4. object tree in ModMan xml

Code:

+ site
|
+--+ deployment ...
|  |
|  +--+ file ...
|
+--+ distribution ...
|  |
|  +--+ file ...
|
+--+ package ...
   |
   +--+ header ...

... means the element repeats 1 or more times.

4.5. package root object

pacakge object represents a "MOD".
package also points deployment and distribution objects to represent composition elements.

package element has next format

Code:

<package
   deployment   ="deployment_name"
   disrtibution ="disrtibution_name"
   favicon      ="ico_file_name"
   game_dir     ="base_or_your_mod_folder"
   name         ="package_name"
>
   <header ...></header> ...
</package>

4.6. deployment root object

deployment object represents required files to run on Doom 3 as a MOD.
deployment element includes 1 or more file objects.

Code:

<deployment
   name="deployment_name"
>
   <file ... ></file> ...
</deployment>

4.7. distribution root object

distribution object represents what file do you distribute with your MOD package (e.g. files in .zip file).
distribution element includes 1 or more file objects.

Code:

<distribution
   name="distribution_name"
>
   <file ... ></file> ...
</distribution>

4.8. file object

file object represents a file entity.
if a file object in;
... deployment, it represents a file recognized by Doom 3 engine. name format is like "def/player.def".
... distribution, it represents a file in your drive. such as "doom3.exe", "base/pak000.pk4", "base/game00.pk4".

Code:

<file
   name        ="filename"
   hash_CRC32  ="checksum"
   hash_MD5    ="strong_hash"
   size        ="filesize"
   mtime       ="file_modified_time"
   cl_severe   ="needed_file_at_client_side"
   sv_severe   ="needed_file_at_server_side"
   name_prefix ="base_or_your_mod_folder"
>
</file>

"name" is file name. format is depends on parent element (distribution, deployment).
"hash_CRC32" has 8 digit hexadecimal integer form.
"hash_MD5" has 32 digit hexadecimal integer form.
"size" has interger format.
"mtime" has date time format like "YYYY/MM/DD hh:nn:ss".
"cl_severe" is "0" or "1".
"sv_severe" is "0" or "1"
"name_prefix" is like "base" or "mymod". folder name in your Doom 3 install folder.

i'll complete this document once more later...

EDIT: section 3 and 4 updated (29 Nov).

Nice tool. So based on what you're saying even though you have your mod files in your own folder there's still the potential for items to be over written?

I'll move this to the D3mods thread where it'll get more notice.

thanks kat.
about goal/solution of the tool, you points well!

i had 2 motives to start this one.

1. to solve potential over written issue for items
as kat mentioned, and as you know, "overwritten" issue is difficult potential problem, when you install new MOD.

2. to try unknown published MOD for you
thru this chance, there will be a big database, which has list of numerious MOD packages.
it will be very fun to search various kind of MOD you don't try yet (map MOD, weapon MOD, ...).

Wow, very nice. Super damn useful, I was thinking it would be nice to have something check files like this for me for quite some time now.

Very useful tool for me and explained very detail :wink:

Nice one!