Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by joebarnin

  1. You've got it in the right place. It needs to be either in the \darkmod\xdata folder or the \<modname>\xdata folder. The name of the .xd file doesn't matter. The name of the xd entry does matter, so for example: maps/saintlucia/mission_briefing { "num_pages" : "2" "page1_body" : "test page 1" "page2_body" : "test page 2" } One question: are you using tdmlauncher.exe to start TDM? Because if you're just running doom3.exe and you don't have the fs_game command line variables set up correctly, then any files in your \saintlucia folder won't be found. It sounds like you've got the file in \darkmod\xdata, so this doesn't apply in that case anyway.
  2. "Install mission" just puts the FM name into currentfm.txt. When TDM launcher runs (either from the restart or when you run it from the desktop), it read this file and sets the +set fs_game command line variable. So when doom3 runs the correct FM is on doom's path (via the fs_game variable). This also explains why the graphics options reset when you switch mods -- doom looks for the DoomConfig.cfg in the fs_game location, and (I guess) creates a default if it can't find it. I would call this a bug -- when you install a mod, I should probably copy the existing DoomConfig.cfg to the new mod directory, if one doesn't exist there. That will at least get your defaults correct. Unfortunately, if you change settings in one mod, they won't apply to others (because they get saved in the local FM dir). At least, that's my understanding of it. I'll look into what can be done to fix this. In some ways, it's very powerful; you can have different settings for each FM. But I would guess most people don't want that level of granularity. Right, this is a feature or a bug, depending on how you look at it . The idea was, you're backing up to a previous screen, so you're throwing away whatever choices you've made. I could keep track of what choices were made and try to populate the shop screen accordingly. Note that the FM designer could specify completely different parameters for the shop, based on difficulty (starting cash, the number and types of items available, and the cost of each item can vary based on the difficulty). So automatically giving you what you chose before might not be a good idea (or even possible). But if there's demand for this feature, I can put it in.
  3. Springheel - if there's any New Mission GUI work you want to hand off to me, just let me know.
  4. greebo, you are a god! By the time I received the Topic Subscription Notification, you had already fixed the problem! Thanks! joe
  5. Well, I'm confused (which is not big news ). I'm not in a position to check this out right now, but I'll look into it tonight. That's great that it works like that -- I'm just surprised that it does!
  6. Doh! I forgot about the forum access limitations! I thought I was being so clever (i.e., lazy) to simply reference my previous note. Thank you so much Crispy for summarizing this. This is correct, as long as you run tdmlauncher.exe, which is found in the \Doom3\darkmod directory. tdmlauncher starts doom3 with all the right command line args to enable this. So presumably we will need to create a desktop icon pointing to the tdmlauncher executable as part of the TDM install process.
  7. Would that be why they are in separate folders?Basically, yes. It doesn't move the pk4s, it just points to them. Each mod needs to be in a subdirectory of the D3 directory. There are some test FMs in SVN but I don't know if you have access. You don't really need a pk4 -- the files can be separate, in pk4s, or a combination. See the link in my previous note for the details, but all you need is a startingMap.txt, a darkmod.txt, and the map files, all in a folder under the D3 main directory. The loader does the rest.
  8. Actually, it's even simpler than that . No files are copied at all -- the loader just restarts D3 with a command line that specifies where the mod files are. The full details are here, but the key is the use of the "fs_game_base" and "fs_game" command line options.
  9. I actually experimented with it this way (no faded drops) and I concur, it looks better (IMHO).
  10. Here are the buttons that are currently text: New Mission: Start Install this Mission (dislays on the left when you select a mod on the right) Main Menu (already a graphic, but I think this should be moved to the right side of the page (it doesn't look good where it is), and thus the colors will have to change) Briefing: New Mission Objectives Difficulty: Briefing Buy Equipment Shop: Difficulty Start Mission If you create the graphics, I'll be happy to place them in the guis.
  11. Looks like sound is not permitted while a map is loading. I added a timer to the saintlucia gui, and verified that it worked by having the timer change the visiability of a background (just as a test). But when I had the timer try to make a sound, it didn't work. This makes sense -- if you start TDM and then bring up the doom command prompt, the music keeps playing. But as soon as you type "map <mapname>", the music stops. I suspect map loading shuts down all sounds. At least, that's my theory. *edit* And the Doom3 SDK agrees with me . See http://www.iddevnet.com/doom3/, scroll down to 01/31/05 Map Loading: " When you issue a "map" command, the following process happens: Mute Sound System ...
  12. I would guess you would need the drip sound code in some sort of timer loop. The way it is now in saintlucia.gui, it only gets executed once, when the menu loads. I'll experiment.
  13. I'd like to do some cleanup of the Start Mission menu chain (New Mission, Briefing, Objectives, Purchase). I'd like to get these menus looking and behaving as consistent as possible. Before I dive in I think we need to reach consensus on some basic questions of the menus. (Maybe consensus has already been reached, in which case someone just needs to tell me ). Text vs. Graphics. Some menus use graphics for buttons, others use text. I'd love to make things consistent -- which way do we go? Graphics give you more control over the rollover behavior (I think). Using text is nice because it's easy to change. Also, some buttons have to be text because their value can be specified by the map creator (for example, the 3 difficulty levels (Easy, Medium, Hard) can be overridden in the map). If we declare that buttons are all text, I can make this change. If we want buttons to be graphics, I don't have the knowledge on how to do this, but perhaps I could be taught. Fonts: Is there a rule for when to use carleton and when to use nancy? The current rule seems to be that main button text and "headings" are carlton, and everything else is nancy. Or should we just use one of them? Perhaps this is moot, depending on the answer to the Text vs. Graphics question. joe
  14. Looks great! When I first realized what the "loading bar" was, it kind of freaked me out. I'm sure that was the intent. There was a long pause after the loading bar finished on my machine too. It took about as long after the bar finished as before (about 2 mintues each way). Don't know if there's any way around that. Your drip sound script, maybe you need to use the < comparison (not ==) like Crispy said.
  15. Looks good, Tels, thanks. I just tested it out and found a problem -- the code that reads the StartingMap.txt file needs to hande Windows/Linux line ending differences. I will fix the code, but for the time being I've checked in a new version of StartingMap.txt that works (I just removed the trailing LF).
  16. I can take care of this tomorrow (Monday) night.
  17. Actually I took the briefing parchment from the Thief's Den mission and renamed it.
  18. joebarnin


    The Briefing screen is now part of the New Mission gui chain (after you Start the mission, before Objectives). The Briefing text is read from an xdata. Details at the wiki: http://wiki.thedarkmod.com/index.php/Briefing Thanks to greebo for figuring out some xdata issues.
  19. Sorry, I've been out of touch for a week or so. I'll get right on incorporating this.
  20. This makes sense now, thank you. The name of the image for each shop item is specified in tdm_shopitems.def. Each entityDef has an "image" field. All we need is for the name of the shader to match the name in this field. Right now, many of the "image" fields in this file are unspecified and some are specified incorrectly. So you can just create the shaders and images with any reasonable set of names, and I will modify tdm_shopitems.def to match. (I'll be checking in the code changes in support of this later today). Springheel, while I've got your attention, I'd like to get the New Mission and Objectives screens beyond the "work in progress" phase. Can you provide the background images for these pages? The New Mission screen needs room for a) displaying the name of the currently-installed mission, a Start button, c) a list of FMs (including a More button for paging down and an "Install FM" button), and d) a Main Menu button. Pretty much just what the curernt mock-up page has. If you supply the background image, I can do the GUI and code work to match. The Objectives page currently just uses the default background. Again, if you can supply a background with room for the set of items that are displayed now, I'll do the rest. No hurry if there are other items on your to-do list; just letting you know I'm ready when you are.
  21. On the purchase screen (when starting a mission), I'm trying to get an image to display when the user hovers over the name of an item to purchase. As an example, there's a file \guis\assets\purchase_menu\broadhead_image.tga. So I have a windowdef called hoverImage, and if I do this: set "hoverImage::background" "guis/assets/purchase_menu/broadhead_image.tga" The image displays, but without background transparancy, so there's a big white background. Interestingly, if I just say: set "hoverImage::background" "guis/assets/purchase_menu/broadhead"; it looks great. So, doom automagically knows to look for a "_image.tga" suffix, and support image transparency? Weird. So I went with that. I want this to be dynamic, so I need to do something like this: set "hoverImage::background" "gui::forSale0_image" where the "forSale0_image" variable is set in the shop.cpp code, depending on what's for sale. Unfortunately, when I do it this way, and try to use the filename without "_image.tga", doom reports an error: "Couldn't load image: guis/assets/purchase_menu/broadhead". If I include the "_image.tga" in the variable value, the image is found, but as before it has the white background. Can anyone cast any light on this?
  22. 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.
  23. Right. That's a better way of doing it.
  24. 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.
  25. 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.
  • Create New...