Jump to content
The Dark Mod Forums

joebarnin

Member
  • Content Count

    379
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by joebarnin

  1. 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.
  2. 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.
  3. 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.
  4. 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
  5. 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.
  6. 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?
  7. I've started prototyping this. Some things are making sense, some things I'm struggling with. But before I start asking questions, should I be working with vanilla D3 SDK, or with DM? I'm currently using D3 and if that's the right thing for now, that's fine. But if I should be using the DM toolkit, I'll switch over (once someone points me to the source, etc.). And, I might as well ask my question. I've got code in C++ that creates and initializes a test GUI, but I can't figure out how to invoke the C++ code when the user performs actions in the GUI (like, buys an arrow). I've looked at scriptEvents and script variables but they don't seem accessible from GUI scripts (just ai, weapon, and map scripts). I tried "runScript" but that doesn't seem to be working, at least the way I'm calling it. I am I missing something? I suppose this is more of a question for a general D3 forum... joebarnin
  8. New Horizon - Now I seem to have correct access to the Contributor forums. Thanks! Ishtvan, Springheel - thanks for all of your ideas and suggestions -- please keep them coming if you think they'll help me. Some of the questions you raise are issues I had thought of too, so at least I'm starting to get my head around what needs to be done. I'll grind away in learning/experimenting mode for a little while, then maybe write up a short design doc, encapsulting these ideas.
  9. Springheel - If you've got the Purchase Screen GUI components ready for me, go ahead and send them along. Even if it's just a work-in-progress, that'll give me something I can play with. If not, that's okay too. New Horizon - Now I see the Contributors forum, with a "No topics were found. This is either because there are no topics in this forum, or the topics are older than the current age cut-off." message. There is only one topic ("No Topics Here"). My date range is set to all. Am I supposed to see or have access to anything else? joebarnin
  10. So, how about if I start with vanilla D3 SDK and see how far I can get. If I start running into issues that require the DM codebase, then I can upgrade. Does that make sense? Also, I'm currently on version 1.3 of D3 and the D3 SDK. Should I upgrade both to 1.3.1?
  11. That's great, because which graphics I should use (and how to do GUIs in general) were on my list of a jillion questions. I'll let you know when I get to that point! Thanks, Jeff
  12. The pre-mission equipment store project sounds perfect! I don't have any particular areas I want to work on, and that sounds like a great first project. But I'm a bit confused, Ishtvan. It sounds like you want me to work on the vanilla D3 SDK to start with. But then you say that the DM inventory system different from the one in D3. So, should I code to vanilla D3 to start with, then port to DM once it's done? I'm fine with that, I just want to make sure I understand. No doubt I will have one jillion other questions (*Gasp* "Sir, that's not a number." *Gasp*) as I proceed, but for now I can get started. joebarnin
  13. I just realized in my original email I wrote "I'm not offering my services as a modder". What I meant to say was "mapper". Sorry, when you're 48 you start making mistakes like that. :-) Sorry about the lack of sample code. Almost all of what I've done recently is for work, and I'm wary of making that public without heavily obfuscating it. But if need be, I can. joebarnin
×
×
  • Create New...