Objectives Display Gui

[Ishtvan]

Okay, on my local build, I got the PDA working in the map (you have to place an item_pda) and renamed the objectives GUI to a PDA, so the objectives GUI comes up when you hit tab. Predictably though, time does not stop.

 

@Napalm: Didn't you say there was a GUI command that could stop time like menu_ something, or am I remembering wrong?

[Napalm]

Hmmm, There is a "notime" bool that you can place in the desktop, but I am unclear as to whether it stops game time or stops time in the .gui, which would mess it up. I guess you/I can try it and see, but I'll be working pretty non-stop days this week untill sunday.

[Ishtvan]

It looks like it is already set?

 

windowDef Desktop
{
rect	0,0,640,480
menugui 1
background "guis/assets/objectives/background.tga"
notime 1

 

Hmm, this could mean it will be a pain to try and get the game time to stop when you open up the objectives. The main menu code seems to be skirted around in the SDK. Seems like it's mostly handled outside the SDK.

 

I dunno though, it seems to be based on idUserInterface. @Gildoran did you use that class for the GUI overlay?

[Gildoran]

'notime' has no relation to the game-time. What happens is each windowDef has its own time variable to control events/animations/etc. 'notime' is used to prevent the window's time from starting before you tell it to. In fact, in ID's GUIs, they often use notime on windowdefs to simulate procedures.

 

I think I did use the idUserInterface class for the gui overlay.

[Darkness_Falls]

Springheel wrote: Oh, for the 'next page' buttons, I think simple arrows at the bottom is the best way to go. The down arrow moves to the next page, the up arrow moves back.

I disagree. I think there should be dog-eared corners on the paper for indicate next/previous page(s); like I think some Thief 2 readables do. Or maybe it's Myst games that do that. Either way, arrows seem too gamey when the whole objectives GUI is meant to look pretty realistic. If we *have* to go with arrows, I feel they should be pointing left & right, rather than up & down. I don't think I've ever seen a page turning interface where the arrows point up and down; so I do not think that would be as intuitive for most people.

[Ishtvan]

Okay, implementation-wise, does anyone have a problem with overloading the D3 PDA with our objectives GUI?

 

It wouldn't stop time as-is though, that's the only problem. I have no idea how to stop time (properly) because the D3 exit to main menu code is not provided in the SDK. You could do g_stoptime 1 and immobilize the player, but sounds would still get messed up. I don't kow how you pause sounds and resume. Maybe I could look into what happens to sounds when you save and restore, to see if that offers any clues.

[Gildoran]

I'd like to suggest another possibility... What about using the main menu to contain the objectives? It's not so different from T1/T2... When in a map, if you pressed escape, there was a menu you could save/load/set-options from, as well as look at the objectives/map. If you went to the objectives screen, you could exit out to the menu.

[Ishtvan]

Hmm, that is possible, but I have no idea how to set gui variables on the main menu from the SDK like how we can set them on the PDA. The main menu GUI isn't directly addressed anywhere in the SDK it seems.

[Gildoran]

The save/load windows should have hints on how to do that. A lot of the save/restore window logic is actually in the SDK rather than the GUI. When the savegame window is opened, the GUI asks the SDK to fill out the the save game slots with any existing save files, and the SDK does so somehow.

[Gildoran]

BTW, as for how to actually display the objects, have you thought about using a list-def? They're normally used for things like listing save-games or servers you can join...

[Ishtvan]

Display what objects?

 

I think Napalm already covered that for now. We can make it more elegant later if time allows, but for now a list of 20 objectives that are used on-demand should be okay for our purposes.

[Gildoran]

Er, sorry... I meant "objectives", not "objects".

[Springheel]

Speaking of GUIs, what's the current plan for the Objectives & Map gui? The last status I recall is that maps were going to be inventory items that you call up by using them instead of hitting a separate key, and objectives might be off of the main menu GUI?

 

The reason I ask is for trying to code objectives to talk to the GUI. Napalm made this objectives GUI that we can use, but I don't know if it's going to be brought up in a separate GUI that's brought up with a specific key (like the D3 PDA), or if it's going to be part of the main menu?

 

Well, I think we decided we didn't want an in-game component to the objectives screen. It should be a separate menu that pauses the game, rather than an in-game gui like a book.

 

That said, I know nothing about calling GUIS, so I don't know how that would be done. Wasn't there some problem calling the objectives gui, and that's why we considering attaching it to the main menu?

[Ishtvan]

There wasn't a problem calling it, we would just overload the PDA. Problem is, this would not stop time. The only way I know to reliably stop time (so that sounds, etc, do not keep playing) is to bring up the main menu. Maybe that is why we were talking about having it in the main menu?

 

Code-wise it's actually harder to address the main menu GUI from the SDK (in order to update it with objective changes), because I'm not sure what the reference to the main menu GUI is. I remember trying to track it down before and not finding it on a first pass, didn't have time to do a more extensive check. The PDA is pretty obvious though. Maybe we could ask the EOC guys if they have done anything where the main menu changes ingame due to the SDK?

 

It would be nice if we could see how to stop time ourselves, then we could just use Gildoran's system to overlay an arbitrary GUI without worrying about how to update the main menu GUI from the SDK. Last I checked though, the call to bring up the main menu was mostly hidden outside of the scope of the SDK. It's some console command that is handled by the precompiled code we don't get access to.

[Springheel]

There wasn't a problem calling it, we would just overload the PDA. Problem is, this would not stop time. The only way I know to reliably stop time (so that sounds, etc, do not keep playing) is to bring up the main menu.

 

I think stopping time is important. I don't think it's fair to have the player have to find a safe spot to check their objectives. Also, we'll need the ability to check objectives before the player starts the mission as well, won't we? That would seem to suggest that it has to be part of the main menu. Though if it's a big problem to update the main menu info, then perhaps there could be two versions--one that shows just the initial objectives, and then an in-game one that is updated as the player completes them?

[Springheel]

I did some searching D3W and found someone who claimed to have a way to do just what we want to, though he doesn't go into a lot of detail. Hopefully it's enough to point someone with programming knowledge in the right direction?

 

http://www.doom3world.org/phpbb2/viewtopic...;highlight=stop

[Ishtvan]

Nice find!

 

Yeah, it works. You have to simultaneously stop time, too, in order for the sound to pick up where it started. Once you do that though, we pretty much have what we want: time freezes, sound freezes, and everything starts up where it left off, except currently the player can still move around and needs to be immobilized.

 

So now we can stop time and sound, but there are still some unanswered questions:

 

Will an overlayed GUI actually work with time stopped? The frame clock is not advancing, and presumably scripts are not running. So will the GUI script run?

 

What about getting sound in the GUI after we've stopped all game sound? I have a suspicion of how to do this, I think you have to allocate a new soundworld for the GUI, and set that to the currently playing sound world, but unfortunately there's no Id example to follow because they did it all outside the SDK.

[Ishtvan]

Will an overlayed GUI actually work with time stopped? The frame clock is not advancing, and presumably scripts are not running. So will the GUI script run?

 

Hmm, the answer is "sort've"

 

I tried playing with the D3 PDA, which is basically an overalyed GUI, while setting and unsetting "g_stoptime". Some things work, some things don't work:

 

-Things that make instantaneous changes work, like you can browse through the user email menu and select different emails, since they pop up instantaneously.

 

-Anything that has any sort of timed transition does NOT work (I guess this makes sense, since the game timer is effectively not running). So no fadeouts or anything like that will work, that just hangs the GUI because it sits there waiting for the fade.

 

-Oddly enough, videos within GUIs work, maybe because it's just a pipe to an external video player.

 

-The keyboard command for exiting out of the PDA DOES work, which is fortunate, since that's the command we need to start time again.

 

As-is, we could maybe make an objectives GUI that pops up instantly, goes away instantly, changes pages instantly, etc. and stops time and sound. (Actually, we could have it fade in and fade out over some short amount of time, but the game world would have to still be going for these times).

 

Otherwise, we can probably make SDK modifications to specifically tell GUIs to advance their timers, because the g_stoptime code is all within the SDK. It already makes an exception for the player, allowing the player to walk around etc while time is stopped, so we'd have to figure out how to make an exception for the player's GUIs also, but that might take time (unless it is as simple as finding the pointer to the GUI and calling ::Think() on it).

 

If we want it to stop time, our choices seem to be between that and make it an offshoot of the main menu, then figure out how to set GUI vars on the main menu from the SDK, if possible.

[Ishtvan]

This is what I'd suggest:

 

1. Create a GUI overlay like the PDA (or overload the D3 PDA if we decide we won't need it for anything... the only thing I can think of is maybe some future ingame editor PDA). This stores the objectives GUI (and maybe map GUI, if we later decide that maps should be a non-game element instead of read in realtime).

 

2. Create a function like gameLocal::PauseGame() that stops time and stops sound, and disables player movement (but leaves mouse input alone so they can still use GUIs), this is straightforward to do.

 

3. In the impulse command to bring up/down the objectives GUI, call the function to pause/unpause the game.

 

4. Make sure the objectives GUI has no timed transitions for now, other than possibly fade in / fade out while gametime is still running. Everything you do once the GUI was open (e.g. page turning, maybe select different maps) would have to happen instantaneously.

[Springheel]

Luckily the Objectives GUI is probably the least interactive of them all. There are really only two or three actions--next/prev page, onEsc, and possibly a Main Menu button. So that shouldn't be a problem.

 

Doesn't sound like pausing time during reading is going to be realistic though, since we'll have time-based features there, like page-turning animations/sfx, etc.

 

If we use the PDA for objectives, however, will the player be able to see them before entering the map? Normally the objectives appear when the player chooses their difficulty level before starting the mission. I think that's necessary, since the difficulty level affects your objectives, and players will need that feedback to make their decision.

[Ishtvan]

If we use the PDA for objectives, however, will the player be able to see them before entering the map? Normally the objectives appear when the player chooses their difficulty level before starting the mission. I think that's necessary, since the difficulty level affects your objectives, and players will need that feedback to make their decision.

 

No, they wouldn't be able to see them before the mission in that case. You'd have to link to another objectives GUI in the pre-mission loading screen or something, if you want to see them before the map really starts. I don't even know how the pre-mission load screen is going to work, code-wise. Is it going to be an offshoot of the main menu that dynamically loads, or is it going to be a separate map or something?

 

A separate map might work actually, since it could effect the difficulty setting and items and everyting for the mission map. You'd just need some way of telling the map which mission data to load so that we only have to make one pre-load map.

[Springheel]

Ok, so we could still use the PDA for 'during play' objectives.

 

We'll need to discuss all the pre-mission screens that we'll need--the purchase screen, the pre-mission objectives, the difficulty/playstyle screen...any others?

[sparhawk]

There is a designdocument which should describe all this already:

 

http://forums.thedarkmod.com/index.php?showtopic=285

[Ishtvan]

I'm talking more about implementation than design. Although that design says that everything should be a branch off the main menu, rather than something like a meta-map. Is that how we want to do it then? Do we know how to do that?

[sparhawk]

Well, that was the first version. But at least it should show all the screens that we need. And I think the hierarchy should also be implemented like that, because we need it this way. If the option screen exists twice, once as a main menu branch, and once as a PDA menu, is IMO an implementation detail.