joebarnin

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.

Sure thing, I can package it up tonight. What's the best way of delivering it?

When the shop code starts up, it now reads the default item information from entityDefs. It searches all entityDefs for those that are named ShopItem_<whatever>. These entityDefs define the properties (Name, Description, class, cost, image) of items that can be purchased at a shop. We'll create a default .def file that contains the item definitions for the standard items, but this could be extended just by creating a new .def and adding ShopItem_* entityDefs to it. Next, I'll code up grabbing the list of items for sale (and available gold) from spawnargs on the worldspawn.

I haven't found anyway of doing this either. I can get a listDef to display the list of items for sale, and I can specify the font and size, but I can't control the behavior of the list itself. So the highlighting behavior is fixed: left-click highlights a row in a green shaded box (see the Doom 3 "Load Game" page for how it looks) and sends the onAction event; double-click sends the onEnter event. This behavior isn't too bad, except for the ugly highlighting. I haven't seen any way of overriding these listDef behaviors, but obviously I'm no expert. There is another solution, if we can't get listDefs to work the way we want to. That would be to have a fixed size list, with a "More Items" button that would be displayed if we had more than one page worth of items. So let's say we define 6 windowDefs in the Items For Sale list, plus a "More Items" button just below this list. If there are 6 or fewer items for sale, they all show up in this list, and "More Items" is invisible. If there are more than 6 items for sale, the first six show up, and "More Items" is visible. When the user hits "More Items", the next 6 items show up (replacing the original 6). We page through the items until we get back to the first 6. Basically it's a way of getting the functionality of a scrollable list, but still maintaining full control over the look and feel of the UI.

Not to worry, I knew the GUI I was building was throwaway. It allowed me to design the underlying C++ code. It won't be a big deal to switch the code over to a new GUI.