mainmenu art

[sparhawk]

When you choose a mod, it must restart with the keyword fs_game <mod name>, right? How would we do that and still preserve the DLL in the main mod? Or can we copy in the FM .pk4 within the mod and then restart our own mod from our mod using the same load mod GUI command? We might not even need a menu, just use that load mod GUI command as a way to restart after copying in the .pk4 that actually works.

 

Restarting the mod might work. After all there is no primary Doom 3 game. The original game is also a mod, with no special behaviour. The game DLL is in a PK4, and when the game starts it behaves exactly like it does when loading a mod. The engine is a complete seperate entity, which loads the mod at some point, which happens to be the Doom 3 game, when you are running the unmodified game. So it definitely should be possible to reload the mod, by switching the mod back to ourselve as if it were just loaded.

[Ishtvan]

Cool. @JoeBarnin, since you said you put the choose mod functionality in your version of the GUI, would it be possible to test it out and see if we can start out in our mod and "load mod" back to our mod? If so, next step would be to start the mod, copy in a pk4 while it's running (just by running in windowed mode and copying it manually), re-load the mod from ingame, and make sure it adds whatever's in the pk4 file. It should, but you never know.

 

If so, I think we solved all our problems with no need for an external loader. From there, we can set up an ingame GUI to crawl through the FMs available (initially in some directory that D3 doesn't load files from), maybe with a brief summary text and picture file for each. When the user selects one, we copy in the pk4 of that FM and then call "load mod <darkmod>" to restart the engine and load all the files from the FM pk4. Then when a different FM is loaded, we delete or move back the old pk4.

[Fidcal]

While you're looking at these memus, there's a restart game after dying and mission fail. Hope you can also work that in somewhere in the main menus without dying so the player can just choose to restart without having to die or reload the map.

[joebarnin]

Sorry for the lack of progress on the pre- and post-mission stuff. My job is in crunch time, and my personal life is sucking up all remaining time (we have house guests, and are in the process of buying a house). I hope to be able to get some work in this week, or at least by the weekend.

[joebarnin]

Made some good progress today. Played with the "loadMod" command in GUIs -- I couldn't get it to work within our mainmenu gui, and besides it requires that you use the listdefs. So I experimented with spawning a new doom3.exe instance (with appropriate args) and then exiting the current instance. That worked fine.

 

So, what I am implementing is this:

 

A new item on the first menu, "Choose Mod" (or whatever we want to call it). This brings up a list of .pk4 files in a specific directory (for now, /darkmod/mods). User picks one. I delete all of the .pk4 files in the /darkmod directory (except darkmod.pk4, of course) and copy the selected .pk4 to that directory. I then spawn a new doom3.exe and exit.

 

[side note: modders will be required to name their pk4 files with a prefix we define (currently, "darkmod_"). This is because the idLib::fileSystem doesn't distinguish between files in the current mod directory and files in the doom3/base directory. So when I delete .pk4 files (see above), I need to know which ones are darkmod-related.]

 

All players have to do is put the darkmod mods (.pk4 files) in the /darkmod/mods folder. Everything else is done within Darkmod with a nice user interface. No external loader required.

 

Thanks to everyone for contributing ideas. I'm not done but I think this is going to work.

[sparhawk]

Be aware, that if the PK4 contains a DLL which Doom might recongize, you may not be able to delete the file while Doom 3 is still running.

[Crispy]

Cool, sounds good. Hopefully D3 won't keep locks on any of the files. DLLs should be OK since D3 actually copies the DLL out of the PK4 before loading it, but if it's holding onto other resources that could be bad. In that case we'd need to maybe use a batch file / shell script to delete the PK4 and then launch D3.

 

Couple of comments:

 

- When you launch D3, it would be nice to preserve the command-line arguments that the previous instance of D3 used. e.g. I pass a "set windowed mode" command to D3 when I start it up. This might not be possible though since we don't have access to main(). This isn't critical anyway, since D3 does remember many of those settings.

 

- Rather than deleting all PK4s matching a certain pattern, IMO it would be cleaner and safer to have a "current_fm.txt" file in the main Dark Mod directory which contains the filename of the currently installed Fan Mission PK4.

 

- The term Fan Mission is more familiar to the Thief community than the term "mod", so I think we should use FM to refer to mapper-created missions/maps. This also helps distinguish between the D3 concept of a "mod" (e.g. The Dark Mod itself is a "mod") and our concept of a mapper-created modification to TDM.

 

- At some point we'll probably want to make it possible to have a "pretty" name for each FM PK4, rather than displaying a file list. Whether we do that using long filenames (i.e. just strip off the prefix and the extension, so darkmod_Crispy's Awesome Mission.pk4 would display as "Crispy's Awesome Mission"), or by putting a file inside the PK4 itself and reading that (this is better since it means we can have names like "Mission Pack X: The Subtitle Dilemma" which, because of the ":" character, are not valid filenames).

[sparhawk]

Cool, sounds good. Hopefully D3 won't keep locks on any of the files. DLLs should be OK since D3 actually copies the DLL out of the PK4 before loading it, but if it's holding onto other resources that could be bad. In that case we'd need to maybe use a batch file / shell script to delete the PK4 and then launch D3.

 

I think it does. At least on Windows, I seem to remember that I couldn't update the PK4 with a new dll, while Doom 3 or DarkRadiant is running. Since the DLL doesn't have any function inside the PK4, this means that the PK4 is locked while it is running.

[Fidcal]

Sounds great. This is going to be perfect. Keep in mind to display the FM's readme, ideally both before and after selection.

[greebo]

I think it does. At least on Windows, I seem to remember that I couldn't update the PK4 with a new dll, while Doom 3 or DarkRadiant is running.

DarkRadiant is definitely keeping locks on the PK4s, I can't say if Doom3 itself does it too.

[Springheel]

a prefix we define (currently, "darkmod_")

 

Maybe "tdm_" would be more inobtrusive.

[sparhawk]

TDM is also TeamDeatchMatch in D3 terminology. But I guess it doesn't really matter for this purpose.

[Ishtvan]

That sounds great.

 

I agree with Crispy that it might make more sense to store the name of the currently loaded pk4 and delete that one when loading a new one, rather than deleting all pk4's in the directory. Then we wouldn't even need a prefix, right?

[joebarnin]

That sounds great.

 

I agree with Crispy that it might make more sense to store the name of the currently loaded pk4 and delete that one when loading a new one, rather than deleting all pk4's in the directory. Then we wouldn't even need a prefix, right?

Right. That's a better way of doing it.

[SneaksieDave]

It sounds like it might (and I assume it does) but just to be sure: does this design handle the case of standalone "add-on" PK4s, those which have nothing to do with the currently loaded mission, but instead just add assets contributed by the community (e.g., "Joe's Custom TDM Water Textures" or "Mary's Improved Lamp Models")?

 

Actually that brings to mind the Morrowind Launcher, where you tell the game which data files you want enabled.

[Crispy]

Yes it does. You just chuck them into the darkmod directory. D3 will detect and use them as normal, and the mission loader won't touch them.

[Ishtvan]

Yeah, we could add a separate menu for managing those kinds of things later on. For now we just want to get the basic idea working though.

[joebarnin]

sparhawk was right, the .pk4 is locked when doom3 is executing, so I can't delete it. So what I'm doing is the following: spawn a helper program, then exit immediately. The helper program will pause for a second or two, then delete the .pk4, then spawn doom3 with all the right args, then exit. Irritatingly, the only way I can figure out to get the helper app to run without a console window opening up briefly is to make it a Windows App. If anyone knows how to avoid this, let me know; otherwise, I'll need help creating a linux version of the helper program. It's only a few lines long.

[Crispy]

There usually is a way to prevent the console window from opening, often using a compiler switch. Depends on the compiler of course. I forget what it is for VC++, but some documentation digging should turn it up. I believe you can also use resource files to get the same effect.

 

The helper program may not be needed for Linux, since Linux doesn't tend to lock files as much as Windows does. Not sure whether or not D3 Linux locks PK4s though.

[sparhawk]

On Windows if you use the linker switch for console applications, it will always open a window.

 

/SUBSYSTEM:WINDOWS No window

/SUBSYSTEM:CONSOLE With window

 

http://msdn.microsoft.com/library/default....f.subsystem.asp

 

Under linux, if you don't open a window, none is shown, as it is just another process. You would explicitly have to code it, to do it.

[OrbWeaver]

The helper program may not be needed for Linux, since Linux doesn't tend to lock files as much as Windows does. Not sure whether or not D3 Linux locks PK4s though.

 

In my experience I have never seen a file locked on Linux, I'm not even sure if it is possible.

[sparhawk]

Text file busy.