joebarnin

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.

Status I've got a mostly-working GUI implemented. It is ugly but functional, and based on the mockup provided by New Horizon. It is a .gui file and some C++ classes. It provides the user-interface functionality of the purchase screen. Things like: Mouse over an item and it changes color (if you can afford it); select an item in the Items For Sale area and it is moved to Items Purchased (and vice versa), with displayed quantities and gold amount adjusted. Mouse over also displays name/description in separate area (no image yet). "Drop" buttons decrement items in the Starting Equipment area. The Items Purchased area is dynamic (starts off empty, grows as items are added to it, shrinks as items are removed from it). What isn't done: * use the real GUI instead of my temporary one. * read Items For Sale and Starting Equipment from mission files (currently these are hardcoded). * figure out how to launch this screen at appropriate time during mission startup (right now, for testing purposes, it is just a HUD replacement). I've just started looking into this one. * when the user is done, spawn purchased items * figure out how to go back to the Objectives screen * switch over to Darkmod SDK. Questions: * Right now, my GUI supports fixed length lists in the various areas (Items For Sale, Items Purchased, Starting Equipment). So, for example, there can be up to six different types of items for sale. Which items are available is totally up to the modder, but there would be a fixed limit. It is easy to change that number to be larger or smaller, but at some point we would have to lock it in. Is that acceptable? Or do we want a more dynamic mechanism, which would involve a scrollable list (listDef)? I chose the fixed number because a) that's what the mockup GUI looked like, and it was easier. But if having an unlimited number of For Sale items is important, I would need to switch to a listDef. * How and where to define the generic definitions of items. Right now for each item there is the following data: - name - class name (to spawn) - description - image - cost e.g., ("Flashbomb", "flashbombClass", "This device is used to blind guards temporarily, giving you time to escape", "flashbomb.gif", 250). Presumably we should define this info in a file somewhere (not in code)? Is there an existing mechanism for this, or should I just wing it? * Similarly, for a given mission how and where does the modder define the list of Items for Sale (and the list of Starting Equipment)? Ishtvan suggested either setting spawnArgs on the worldSpawn (entity #0), or storing them in another text file associated with the map. Is either way preferred? I would think the specification would be a list of {classname, quantity} pairs. If they wanted to override the default Cost, we should probably allow this too (?). Jeff

I am a moron. A stupid mistake - I saved a .script file in the wrong directory, so my change didn't get picked up. Damn computers, they do exactly what you tell them to! The GUI to C++ path works fine now. Sorry about that.

When the user clicks on an object in the "Items for Sale" column, several things have to happen: put the item in the "Items Purchased" column (if it wasn't there alerady), or increment the count if it was there already, decrement the count of that item in "Items for Sale" (or remove it if it the count is down to 0), decrement the Gold value by the cost of the item. I was planning on doing all of this in the C++ code, by modifying C++ variables and then updating the GUI by calling SetState* methods on the various defs of the GUI object (the idUserInterface object). So, I want to invoke a C++ method from the onAction event handler of the item in the GUI. I've tried using the techniques I mentioned before, but either they don't work with GUI scripts, or I don't know how to use them. I suppose I could modify idEntity::HandleGuiCommands and just add new command strings that can be called from GUI scripts. That seems like overkill. Or, am I going at this the wrong way?