Jump to content
The Dark Mod Forums

joebarnin -New Coder


New Horizon

Recommended Posts

Yeah. What we also still need is an objective screen, then we should be pretty complete with the menu gui.

 

I thought the objectives screen was already working?

Link to comment
Share on other sites

  • Replies 72
  • Created
  • Last Reply

Top Posters In This Topic

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

Link to comment
Share on other sites

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.

 

I don't really have anything I could give you right now, other than the background textures, which probably won't be much use. I'm comfortable moving/resizing/modifying things, so it might be best if you just worked with plain text for now until the functionality is done, and then I can take it and add all the graphics, etc.

 

The main coding features, as far as I can see, would be the following:

 

1. Read and display custom info on what starting items player should have

 

2. Allow players to drop those items before starting map.

 

3. Read and display custom information about what items are available to purchase (these will probably have to be set up as inventory entities first) as well as how much they cost.

 

4. Find a way to add purchased items to the player's starting inventory before map start.

 

5. Read custom amount of starting gold, keep track of current gold total, disallow purchases player can't afford.

 

6. Keep track of totals for items with multiple copies (eg, arrows).

Link to comment
Share on other sites

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

 

Very strange. I'll look into that. :)

Link to comment
Share on other sites

I think the main things right now are:

 

1. Run a GUI on map load, keeping everything else (AI, physics, basically all other entities) inactive until purchasing is done (but the frame clock might actually have to run to do certain GUI actions that are timed, like fade in a menu over X seconds). [NOTE: You might want to search the code for g_stoptime. This stops time for everything but the player, so you may want to use similar code to let the player update while they're running the GUI, but stop time for everything else].

 

2. Figure out how to do the following from the GUI (maybe via scriptfunctions, or whatever the best way is to call commands from GUI's, I don't know much about that) :

 

- Set spawnArg variables (basically key/value pairs that all entities have on an object of theirs called spawnArgs)

 

- Spawn an entity (or schedule it to spawn when the purchasing ends). The inventory system is set up so that each unique item needs an entity in order for it to be added. Stackable items only need 1 entity for several, e.g., you would have 1 broadhead arrow entity with a "count" spawnArg of 30.

 

NOTE: I might have been wrong when I said you should call PostEvent before.

@Sparhawk: Could you explain how inventory items that the player starts with "know" how to add themselves to the player's inventory at the start? Is it a spawnarg on them? If so, which one? If that's easy to set up, you might not need to call PostEvent (of course you'd need our codebase to test this part). My understanding is that when they purchase something in the shop, it has to be spawned as an entity in the map, and then at some point during map initialization but after the shop GUI, these entities add the items to the player's inventory? When exactly do they add themselves, when they spawn, or do they schedule an event?

 

We need to think about the timing IMO, because when the purchasing screen is up everything else is paused, so you might not be able to spawn things. Maybe it would suffice to have the shop keep track of what was bought and then spawn it all at the end?

 

3. Shop details

 

- How will mappers set which items are available in the shop, quantity, prices. Could be setting spawnArgs on the worldSpawn (entity #0 that every map has, can be used to store general map information), or maybe adding another text file for their map, who knows. For the item type, they should probably specify the "classname" variable, since this is what you input when you spawn items.

 

- Total avialable loot for purchasing (for now this can be a number read from the same data as the shop items/prices, later on we might want to make it a persistent variable to support multi-mission campaigns)

 

- Coming back to items the player gets automatically: Right now this can be done by the FM author placing entities in the map and setting spawnargs on them by hand. If the shop code has the ability to read from a mapper's list of items and put those entities in the map when the player buys stuff, we might as well have the shop read from a list of starting items and automatically put those in the map as well, to save the FM author some time.

 

Anyway, those are just some suggestions, if you think of something better that's fine too. :)

Link to comment
Share on other sites

Btw, when pausing the game, there are some subtleties about handling the ingame sound when you pause the game. I don't know if this would apply to the purchasing screen or not, since it's running right at the beginning, maybe you don't need to worry about this, but here is some code that pauses the game including the ingame sound (I believe it still lets GUI sounds play).

 

void idGameLocal::PauseGame( bool bPauseState )
{
if( bPauseState )
{
	gameSoundWorldBuf = soundSystem->GetPlayingSoundWorld();
	gameSoundWorldBuf->Pause();
	soundSystem->SetPlayingSoundWorld( NULL );

	g_stopTime.SetBool( true );
}
else
{
	soundSystem->SetPlayingSoundWorld( gameSoundWorldBuf );
	soundSystem->GetPlayingSoundWorld()->UnPause();

	g_stopTime.SetBool( false );
}
}

Don't ask me why you have to buffer the gameSoundWorld and set it to NULL, that's just how it works. (A lot of things are undocumented, and someone at www.doom3world.org found this out by trial and error. :) )

Link to comment
Share on other sites

How will mappers set which items are available in the shop, quantity, prices.

 

We'll want to have default values for the prices, rather than let mappers pick an arbitrary price each time.

 

As well, there will need to be some key/var that tells the gui what 3d model is being used for the item, in order to display it during a mouseover.

Link to comment
Share on other sites

One question. When the shop comes up, is the map already loaded or not? I suppose the shop would be a startup event of the map, right? If that's the case, then inventory items have to be spawned into the inventory. Normally they are part of the map definition, but I have to look up the details on this.

Gerhard

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

There's also the difficulty menu, which will be specific to the map but has to be run before the map itself is loaded (I presume, in order to affect things difficulty should affect). In fact, the difficulty level might also affect the amount of gold and available purchase items there are, so I guess it would have to be run first.

Link to comment
Share on other sites

Yes, difficulties should load first, authors will expect to be able to choose how much a player starts with, along with what inventory they start with at the start of game.

 

In T2 you have:

 

Start or load (new game or load)

-difficulties with descriptions

--loadout screen (purchase screen), also shows items author gave player including loot (all this varies by difficulty)

---briefing movie if one exists

----gameplay

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Cool, glad to hear things are working out. I wouldn't worry too much about the difficulty settings for now, that's going to be a major undertaking when we eventually get to it. As long as there's some mechanism to maybe pick which items and starting gold are available from a few different lists corresponding to different difficulty levels, that should be enough for now.

 

Access to our source is up to Sparhawk.

Link to comment
Share on other sites

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 B) 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

Link to comment
Share on other sites

Oh, I didn't realize you were getting into the actual GUI interface yet, or I would have given you a little more direction. :mellow: The specific details about size, font, position of text boxes, mouseover effects, etc, are all things I don't mind doing, and will probably have to tweak anyway since that mockup NH posted isn't totally up to date.

 

Or do we want a more dynamic mechanism, which would involve a scrollable list (listDef)?

 

Yes, we'll need to have listDefs for those areas, since we don't know how many items a mapper may want to make available.

 

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?

 

You'll probably want to create something similar to our .xdata files for readables (though I don't know much about them--there's info on the wiki though).

 

When the time comes, I have the descriptions for items already written. We'll be using the actual model itself for the image, rather than a 2d screenshot, so the "image" will need to point to a model.

 

If they wanted to override the default Cost, we should probably allow this too (?).

 

There should be defaults set, but yes, they should be able to be overwritten.

Link to comment
Share on other sites

Oh, I didn't realize you were getting into the actual GUI interface yet, or I would have given you a little more direction.

 

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.

Link to comment
Share on other sites

Great progress so far!

 

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 B) it was easier. But if having an unlimited number of For Sale items is important, I would need to switch to a listDef.

If you can figure out how to do the dynamic list/listDef, I think that would be best. We actually need scrollable lists in some other GUIs, but we have very few people working on GUIs right now and no one's figured out how to set them up yet. So if you could get the listDef working for this and also document how to set it up in general, that would be very helpful.

 

* How and where to define the generic definitions of items. Right now for each item there is the following data:

... 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?

So you're asking how we can define the shop data for a given item in a list somewhere, so that the FM author doesn't have to put in that stuff every time they define a list of items available for a mission? That's a good question. My first thought is to use entityDefs in some sort of centralized def file, and probably name them with some specific prefix like ShopItem_Flashbomb so that they don't conflict with other entityDefs for the actual items. Then in your code, you could take a single name, "flashbomb", and call gameLocal.FindEntityDefDict( va("ShopItem_%s", <the short name> ) )

 

We've used a system like that for stuff in the past; basically make a list of them in a single def file, like shopitems.def and put them in /def/. With this system, it's easy for FM authors to add additional shop items, because they'd just need to create a def file for their map with some entityDef ShopItem_* blocks to add additional shop items, then pack that def file into their .pk4, so they can add items without having to edit the original mod-wide item file which might change with future revisions.

 

In case it's not clear what I'm talking about, it would be something like:

tdm_shopitems.def

entityDef ShopItem_flashbomb
{
  "displayName" "Flashbomb" // can't use "name" since this is used internally
  "desc" "<description of what flashbomb does>"
  "item_clasname" "item_flashbomb" // can't use "classname" since this is used internally
  "image" "<material file to display for the icon in the shop window>"
  "price" "25"
}

 

* 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 (?).

I can start a thread polling the mappers about this. I would think putting spawnargs on the worldspawn would be easiest, because we can then write something in our DarkRadiant editor that brings up a shop-item GUI and writes the spawnargs automatically based on what the FM author puts in the pop-up menu. It's also easy to get spawnargs in the code. (call idEntity::spawnArgs.GetBool, etc).

 

* 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.

This question is a bit complicated, because I'm not sure if the frame loop has to be already running or not for GUIs to work properly (fade in/fade out, etc). One option that I'm not sure we talked about before would be to make the shop a part of the main menu GUI, and just read ahead in the map file what it needs. (If you know the name of the map the user selected, you can call some functions to read spawnArgs from entities in that mapfile, like the worldspawn for example, before the map is actually loaded). That could work, because we know GUIs work in the main menu, but we don't have to worry about pausing everything else like we would if we tried to call it after the map was loaded and the frame loop was running. Now that I think about it, that might be the best option.

 

Unfortunately we don't actually have anything written yet for selecting which mission to play from the main menu, but you can imagine that when we do, that could just run from within the main menu GUI and read ahead in the mapfile to load up both the shop and the difficulty/objective info.

* when the user is done, spawn purchased items

IMO it's easier to think about this as a completely separate event for now that could happen much later. As long as we can store somewhere a list of classnames and quantities to add to the player's inventory, adding the items later will be easy. You'll also need the TDM inventory code for this, so I wouldn't worry about it for now.

Link to comment
Share on other sites

but we have very few people working on GUIs right now and no one's figured out how to set them up yet.

 

It's not making scrollable text that's hard (it's pretty straightforward, although scrollbar sliders are another matter). The apparent problem is having editDefs *inside* a listDef. Apparently, that doesn't work, though I haven't tried it myself to verify. Now that Napalm has disappeared and I'm off for the summer, I plan on getting back into the guis, so this will be good timing. :)

Link to comment
Share on other sites

Do the items the player has chosen NEED spawned?

I'm not programmer so this is just what I know of how Dromed did it, a programmer would be able to say whether or not it is a good way to proceed.

 

In Dromed the author creats objects and links them to a "store" which is just a marker. This way they already exist in level and thus would be spawned on load.

Of course I don't know how they are linked to player from purchase...

 

But this lets the author limit what is available. I don't think we want to just have as many water arrows as player can purchase available, I think author needs choice. This is alsohow items/difficulty was controlled.

author can link 3 water arrows to store.

arrow 1 = stack count 5

arrow 2 = stack count 5, destroy difficulty 2 (won't be available on hardest setting)

arrow 3 = stack count 5, destroy difficulty 1,2 (won't be available on 2 hardest settings)

 

so easy diff could purchase 15 arrows, med 10 and hard only 5. Instead of spawning the items they would need linked to player and un-purchased ones would be destroyed.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

It's not making scrollable text that's hard (it's pretty straightforward, although scrollbar sliders are another matter). The apparent problem is having editDefs *inside* a listDef. Apparently, that doesn't work, though I haven't tried it myself to verify.

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...