question on dark mod i am new so dont flame me

[Crispy]

I still don't understand why FM overwriting assets couldn't work in one directory, unless we put all the mod assets in .pk4 form also? If the mod assets are not in .pk4 and just in the directory, and the FM comes in as a .pk4 with files of the same name, won't the files in the .pk4 overwrite the mod assets as desired?

Files in the directory override PK4s.

 

During development you don't want to have to re-pack all the files every time you change something, so the game is set up to look for files in the directory to override files in the packs.

The confusion may arise because Quake 3 did it the other way around.

 

So in order to use PK4s vs. unzipped files for FM distribution, the mod assets would have to be in PK4 files and the FM assets would have to be unzipped.

 

The fs_game_base thing definitely sounds promising though.

[STiFU]

It does, but wouldn't you need some kind of installer for that too?? Since you need an installer either way, I got a different idea. FMs that substitute TDM-defaults could be shiped in zip format instead of pk4. A frontend tool would list both though and if it's a zip-file, simply unzip it in the TDM directory and start the mission. If it's a pk4 it would just start the map directly. Very simple and no complicated implementation...

[Fidcal]

The problem with extracting files is avoiding overwriting and then deleting them all afterwards without deleting anything else. T2's Darkloader and Garrettloader does a pretty good job but most sensible level designers have a completely separate install just for Dromed else they cannot play FMs while developing their own, at least not risk-free. If a pk'd up FM solution can be found it would be preferable imo.

[New Horizon]

Files in the directory override PK4s.

 

So in order to use PK4s vs. unzipped files for FM distribution, the mod assets would have to be in PK4 files and the FM assets would have to be unzipped.

 

The fs_game_base thing definitely sounds promising though.

 

Say what? That isn't right...I've never had that happen. If you pop a 'genericmap.pk4' into the darkmod directory, any original darkmod files that have been included in the pk4 will alter the unzipped mod directory files. That's how it has always worked for me. Doom 3 will override unzipped files with the pk4 that the map is packaged in, not the other way around. I know this is true, because when rdumple released his classic Thief hud mod, it was packaged in a pk4 and the pk4 didn't even have a map in it...just the hud.gui and his custom files. It overwrote the original hud with a classic Thief hud.

 

The easiest way for FM authors to setup their work is to package all of their custom content...map included...in a pk4. We simply have to tell them to use a creative prefix or suffix.....their username 'googoo_mossybits.tga' for example, or googoo_moss.mtr.

 

They might run into the odd conflict, but it's unlikely to be too serious.

[greebo]

Say what? That isn't right...I've never had that happen. If you pop a 'genericmap.pk4' into the darkmod directory, any original darkmod files that have been included in the pk4 will alter the unzipped mod directory files.

Sorry, but I checked the PK4 behaviour with a custom HUD icon that was existent both in the PK4 and the physical mod folders, and the PK4 files were overridden. I also checked that with a normalmap that I deliberately uglyfied in the PK4 files - the changes were only visible when I deleted the unzipped version.

 

If you scroll up the console on Doom 3 startup you'll see the search path:

Current search path:
C:\Games\Doom3/darkmod
C:\Games\Doom3/darkmod\test.pk4   <<< (this is my test archive)
C:\Games\Doom3/darkmod\darkmod.pk4
C:\Games\Doom3/base
C:\Games\Doom3/base/pak008.pk4
C:\Games\Doom3/base/pak007.pk4
etc.

As for the order of the PK4 files, it seems it's in descending alphabetical order.

[New Horizon]

Sorry, but I checked the PK4 behaviour with a custom HUD icon that was existent both in the PK4 and the physical mod folders, and the PK4 files were overridden. I also checked that with a normalmap that I deliberately uglyfied in the PK4 files - the changes were only visible when I deleted the unzipped version.

 

If you scroll up the console on Doom 3 startup you'll see the search path:

Current search path:
C:\Games\Doom3/darkmod
C:\Games\Doom3/darkmod\test.pk4   <<< (this is my test archive)
C:\Games\Doom3/darkmod\darkmod.pk4
C:\Games\Doom3/base
C:\Games\Doom3/base/pak008.pk4
C:\Games\Doom3/base/pak007.pk4
etc.

As for the order of the PK4 files, it seems it's in descending alphabetical order.

 

That doesn't make sense. Did we change something? When rdumple created his custom hud, all we had to do was drop it into the darkmod folder and it would override the unzipped hud.gui in the gui folder. I'm somewhat perplexed by this. The last time I used rdumple's hud pk4 wasn't very long ago. I'm 100% sure that this was the way things worked originally, because people have had issues with pk4's over riding our unzipped files.

[greebo]

I don't know what drumple's PK4 did, but feel free to do a test on your own. Just try to override a DEF file or a texture using a PK4.

[New Horizon]

I don't know what drumple's PK4 did, but feel free to do a test on your own. Just try to override a DEF file or a texture using a PK4.

 

Found the answer.

 

This was a change made in the Doom 3 1.3 update.

 

"New class of .pk4 files: 'addon paks' are only referenced when the map is loaded in."

 

I knew I wasn't crazy.

 

So, that explains why the pk4's refuse to overwrite when a map is not present. As I mentioned earlier though, if the map is there...the pk4 should take priority over the unzipped files. I was thinking it would be pretty silly if they didn't retain that functionality with the map present...it would pretty much render pk4's useless.

[Fidcal]

In the light of that this first part is probably obsolete but I'll post it anyway just in case..

 

How bad would it be if mappers are told they can't override originals but must create new files. What would it affect? A changed original texture would then also need a copy of the material file def and the normal map, etc. instead of just using the originals. A little extra work but also a little bigger pk4 map file. But how often are mappers doing this? Substantially? Trade off that restriction against the advantage of neat pk4 fan missions all self-enclosed little packages. You could have several in the darkmod folder at once all nicely listed on the Dark Mod menu so long as mappers use very distinctive names so they don't clash with each other.

 

Suppose the pk4 prefix name is limited to just a few characters and these chars prefix all new files? Not a happy solution but Blackheart Manor becomes BHM.pk4 and a file inside might be BHM_name..... Just an idea. [EDIT] what I mean is of course that if anyone else produced a BHM.pk4 then they cannot co-exist in the folder at once.

[greebo]

@New Horizon: Ah, that seems to explain it.

[Ishtvan]

So to test it definitively, we could put a map in a .pk4 in addition to a new hud.gui, and it should overwrite our hud.gui. Does this happen?

[New Horizon]

You mean a new hud.gui in the unzipped folders? The pk4 with the map within it should definitely overwrite the one in the unzipped folders. I can't test that right now though, my system is in a ...state of dismemberment.

[STiFU]

Fidcal, the filename of a pk4 does only matter for the loading sequence. You can even save one on your TDM folder under another name. What matters are the filenames inside the archive. Also, if you just change the difusemap (or anything else) of a shader you can still refer to the original texture files. No problem at all!!

 

But cheers to ID. I was as suprised to hear about the "map based pk4 priority" as New Horizon, but in the end, they did a really great job on this one. Although this implies, that modders/mappers may not include map-unrelated content into their fm, like a new mainmenu, because this would be loaded before the map and could possibly overwrite the tdm-default files. (To protect this from happening TDM could prefix their pk4s with an "AAA")

 

[bTW, nice interesting discussion here]

Edited August 1, 2007 by STiFU

[Ishtvan]

Although this implies, that modders/mappers may not include map-unrelated content into their fm, like a new mainmenu, because this would be loaded before the map and could possibly overwrite the tdm-default files.

Some FM authors might want to do just that, why not let them? It doesn't physically overwrite the files on the HD, just in that instance of the D3 file system. Assuming we have a loader that copies in a single .pk4 for the FM you want to load, and moves it / deletes it when done, there's no problem if an FM decides to replace the mainmenu GUI, or change player voices to female for a different character, or whatever. As long as the FM has a pk4 that moves in when it's selected, moves out when not, it should work fine.

 

The only concern is they'd have to update their own mainmenu GUI version it we released a new TDM version with new mainmenu GUI functionality, since I'm sure there will be a few "patches" from us after we release.

[Fidcal]

Fidcal, the filename of a pk4 does only matter for the loading sequence. You can even save one on your TDM folder under another name. What matters are the filenames inside the archive. Also, if you just change the difusemap (or anything else) of a shader you can still refer to the original texture files. No problem at all!!

 

Yes, I agree and understand but didn't make my point clear. This idea might be obsolete now anyway but I'll clarify: What I was saying was that the Dark Mod team make a 'rule', ie, 'recommend', that all mappers should stick to. So, my own map might be called 'Manor Royale' (working title so far) so if I stick to the 'rule' then I name my pk files say, MRL.pk4 and files inside are prefixed MRL_. If everyone stuck to this rule then it would be impossible for there to be conflict between one FM and another's files because either they would be named differently or, if they happened to be the same (eg if someone by chance had 'Murder, Risk, & Loot' so also prefixed their names with MRL_) then it would be impossible for them to be in the darkmod folder at the same time because both pk4 files would be called MRL.pk4. Having said all that I don't particularly like it!

 

Ditto about referring to the original texture files if you just change the diffusemap. I know you can; I'm saying should mappers be told not to do this. It's all a trade off as to (just) copying the other files and renaming them PLUS the overhead in pk4 size AS AGAINST a possible happy solution of avoiding conflict. I parenthesised 'just' because I don't know how often this is commonly done (dozens and dozens of files?) so how much of a nuisance.

 

No such rule could be enforced but any FM issued with conflicts would soon be known and players would avoid putting it in with other FMs at the same time or just not play it... Probably.

[STiFU]

Ahhh, now I see. Sorry. That prefix thing is definitely good, but of course most mappers should already do it by default... Since we learned that the pk4 of the map has priority, it isn't needed that much anymore though. But still, better safe than sorry!!

 

About that pk4 name. You can still just rename it. No problem!! You just have to hope the bsp files aren't called the same.

 

As long as the FM has a pk4 that moves in when it's selected, moves out when not, it should work fine.

With a bit of luck yes. To make sure it works, we'd have to achieve that that special file is loaded at last so that the files inside overwrite the beforeloaded files. But again renaming the pk4 could help out...

[sparhawk]

You don't have to load the Dark Mod via the futuristic-style Doom 3 menus

 

In fact, when I work on TDM, I never see anything from Doom 3 unless I intentionally make it so. For all I know it could be already the finished game. Even though you could load the Darkmod, via the Doom 3 menu, I'm not sure if it would really work that way. It should work, but I have a suspicion, that there are still some differences when loading it this way.

[Capela]

The times i load the Darkmod from Doom3, it worked perfectly.

[sparhawk]

Do you always load it from Doom? It should work just the same, this way, but I had the feeling that sometimes it may a little bit screwed up.

[Capela]

Just when im doing the *.pk4 file, to see if everything is ok, i go to doom3 mod section, select the Darkmod and run the map from the pk4 file. The several times that i did this i never felt anything wrong.