joebarnin

Sorry, I've been out of touch for a week or so. I'll get right on incorporating this.

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.

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?

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.

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

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.

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.

It is not. I just dropped it in on my version of mainmenu.gui, changed the font to carleton. It doesn't look too bad, except when you select a row, then you get an ugly green highlight. Someone told me how to change the highlight color but I can find the info now. I'll look into it. Using this technique, we could have a Mods button on the first screen, for swapping mod directories.

Right now this is in the C++ code, which is bad. I'll come up with a fix to make it available in the GUI or someplace. And I'll add a space after it. Thanks, Shatten, for figuring this out. I believe this is called "kerning". Higher-end composition systems don't reduce the font width, they actually carry a separate table of values for character pairs. This is the the amount to "back up" when laying out a pair of characters, after laying out the first character. Trivia for the day.

I like #1. If a .pk4 contains multiple maps (a campaign), the player shouldn't be able to pick the map to start with. I thought there was a problem with DLLs loading, so that if a .pk4 contained a DLL, then once the engine started it was too late to copy .pk4 files into the darkmod folder, because the DLL wouldn't get loaded. Or did I misunderstand? If that's not an issue, we don't need a loader and all of this can be done from the menus.

Question about the New Game menu. Would the player ever be selecting the mission to play? It sounds like we're leaning towards a DM version of GarrettLoader (or something similar). Users would pick the mod, and GL would copy the .pk4, and delete other add-on .pk4 files (to prevent file collisions). So, does there even need to be a New Game menu? When the player hits New Game, the map that is loaded is not choosable. If the mod has just one map, then that's the map to play. If the mod is a campaign, then the map to play is the first of the campaign. Perhaps each .pk4 should contain a starting mission file, which contains the name of the first map in the mod (or the only mission in the mod, in the case of a single mission mod). So there is no mission choice for the player. New Game goes straight to the Difficulty screen. Now, we (DM developers, mappers, testers, designers, etc) need some way to load an arbitrary map. Maybe, if there is no starting mission file, that's when the New Game menu shows up, supplying a list of all maps in the map directory. This would really be seen only internally.

So would there be another button in the Shop to get to Difficulty/Objectives? Actually, you have to choose Difficulty first, since that may affect what you can buy. I suppose I could dynamically modify the shop contents if the user changes difficulty, but that starts to get complicated from the user point of view. For example, they start with Easy, buy a water arrow, switch to Difficult (which allows no water arrows for sale), and suddenly the water arrow they bought is removed from the purchased items. Confusing to the user. So I think you have to choose difficulty up front. But you probably want to get briefed before choosing difficulty. So Briefing video/text -> Difficulty screen -> Shop screen. And Shop has links to replay the briefing. And a back button to Difficulty, in case they want to change difficulty (which would effectively be a restart on the Shop).

I'm not sure what's in the Mission Info. Is this the Difficulty/Objectives? Or Briefing text? (Is there going to be Briefing text?).

How about this: By default, we go to the Shop screen after the Difficulty/Objectives screen, even if there are no items to purchase. This enables item dropping and display of item info. If there are no shop items, a suitable message will be displayed ("Nothing available for purchase" or something). And, since there may be items that the mapper does not want dropped, I'll add a new spawnarg "startingItem_#_candrop 0", and the GUI will disable the Drop button for that item. And (just to provide total flexibility to the mappers), I will provide a "shop_skip 1" spawnarg that will skip the Shop menu altogether, going straight from Difficulty to starting the map. How does that sound?

My next update will fix these issues. "Buy Equipment" will be renamed "Start Mission". If the shop_gold_start spawnarg is absent, this indicates there is no shop, so "Start Mission" will go straight to the map. Otherwise the shop menu will appear. Should be checked in tomorrow.

Do we want to make it easy for the level designer to specify the difficulty names (say, worldspawn args in the map)? In other words, just leave a space for the names and I'll fill them in with text. We can define defaults (e.g, Easy, Average, Difficult) in some def file somewhere, to be used if the modder doesn't specify difficulty names. Actually, not "Start mission", but "Buy equipment" or something like that, because the Shop is the next screen.

I can certainly get the functionality working without the graphics. I guess I'll move ahead with the coding, and as the graphics become available I'll plug them in. As for the Difficulty screen, at a minimum it has to contain space for the 3 difficulty strings, and room for objectives list. I presume the difficulty strings (e.g., "easy", "medium", "hard") won't be hard-coded, but in fact can (must?) be specified by the mod designer. And I guess the screen needs forward and back buttons of some sort. I don't recall the order: briefing, difficulty, purchase, I think. So, back to briefing, forward to purchase? As for the gamma standard, I'll take whatever you have. I'm still confused - is it a fullscreen GUI? So we replace the slider that's there now with a button that displays the fullscreen gamma standard?

I've been doing some coding for pre-mission stuff (purchasing items, difficulty, etc), which involves some changes to the mainmenu GUI. Right now for any new screens I'm not using any backgrounds, but it would be nice to plug in the real graphics (I can do the GUI work, I just need the canvas (background) images). I'm looking for graphics for the following: Purchase screen Difficulty selection / objectives display Gamma standard image (gamma adjust) If anything already exists for these, I would appreciate a pointer to it. I looked through the concept art discussions, but it was hard to tell if conclusions were ever reached. I believe that the purchase screen should like something like this, except with page scroll arrows (up and down) for each of the 3 lists. The difficulty screen needs room for the 3 difficultly strings (which presumably will be specified in the map?), plus an area for the list of objectives (also with page scrolls). The gamma image will presumably go on the left-hand side of the Video Settings screen, am I correct? If these graphics aren't people's priorities right now, that's cool. But since I'm in the mainmenu GUI right now, it's a good time to plug them in.

Springheel had the answer: Turns out the offending phrase was: tdm__player__base (with only one '_' between each word). If you search for that word you'll get the same error. It appears to have something to do with the phrases that start with tdm, followed by the underscore character, followed by at least two more characters (!). Bizarre. Anyway, thanks to Springheel for the solution!

Sorry for the global post, but this is joebarnin and I can't post to the private forums or sent a PM. Here's the error I get: ----------------------------------------------------- Forbidden You don't have permission to access /darkmod/index.php? on this server. Baby Jesus cries... ----------------------------------------------------- I am logged in as joebarnin when I try to post.

I could probably figure it out, but if you can get a hold of that code easily, I'll take it. Thanks! *EDIT* Never mind, figured it out.

Update: the Gold amount, Items for Sale, and Starting Equipment are now all read from the spawnargs on the worldspawn. Still to do: Dynamic lists. I can think of three possibilities: a) live with current suboptimal listDef UI, figure out how to modify the listDef UI, or c) use my earlier proposal for lists. Use the real GUI instead of my temporary one Where to plug in the Shop (I like Ishtvan's idea of making it part of the main menu GUI) Spawning the "bought" items when the mission actually starts

Found it. In Visual Studio .NET 2003, File menu, Advanced Save Options, Line endings. Options are: Current Setting, Windows, Macintosh, Unix. Mine is set to Current Setting (I have no idea what that means).

Weird. I'm running XP Media Center Edition. I used Visual Studio .NET 2003 to edit the C++ files. I'll fix for the highlighting problem.

I'm familiar with TortoiseSVN (we use it at my job) so that works out. I've uploaded to /joebarnin/shop.pk4. This is a Doom3 mod. The purchase screen takes the place of the PDA (that's just temporary of course). So if you start a new D3 game you'll have to play far enough into it to get the PDA - just takes a couple of minutes. Then hit TAB and you should see the screen. (I did figure out how to get the screen to come up sooner, but it would then hang Doom3 and I hadn't figured out how to fix that yet). To the same folder I also checked in the C++ files I modifed or created, if your interested.