Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Daniel]

Hi everybody,

I want to use the FadeOut and FadeIn methods but I'm not sure where to place these calls. I want to fade out the current scene the moment the user clicks the "Options" button, then open the "Main Menu" window (that covers the entire screen) in system exclusive mode, and only then fade in with the "Main Menu" window already in place.
I tried to place the FadeOut and FadeIn calls in the most logical places but I get weird results. The FadeOut works fine but the FadeIn doesn't work at all. The "Main Menu" window just appears without fading in. In addition, the FadeOut (that worked the first time) stops working as I go back and forth between the window and the scene, they just disappear and appear without fading out and in, and even the FadeOut that worked the first time stops working.

Does anybody know what am I doing wrong?

[Jerrot]

Hi Daniel,

I want to use the FadeOut and FadeIn methods but I'm not sure where to place these calls. I want to fade out the current scene the moment the user clicks the "Options" button, then open the "Main Menu" window (that covers the entire screen) in system exclusive mode, and only then fade in with the "Main Menu" window already in place.

With some help of Mnemonic, this part works fine for me. I guess you made the same mistake as I did and used Scene.FadeIn instead of Game.FadeIn.

I tried it this way in the game.script:

Code: [Select]

    // load and display the main menu window
    Game.FadeOut(1000, 0, 0, 0, 255);
    WinCaption.Visible = false;
    var WinMainMenu = Game.LoadWindow("interface\system\mainmenu.window");
    WinMainMenu.Center();
    Game.FadeIn(1000, 0, 0, 0, 255);
    WinMainMenu.GoSystemExclusive();
    [...]
It doesn't work for me the other way though (closing the Main Menu with FadeOut), since it seems you can't "FadeOut" the game (with opened Main Menu) while in exclusive mode, so the Main Menu window can only be closed to go back to game. Mnemonic is going to check this later... 

Jerrot.

[Daniel]

Thanks,

Well, The FadeIn works fine now, the reason it wasn't working before is because I seem to be an idiot...

Anyway, the FadeOut still works only once (with the same code you posted). From the second time and on, the behavior is as follows: it goes black immediately, it then delays for the requested 1000msec with totally black screen, and only then the FadeIn of the window kicks in. Weird...

About the Fade methods not working in system exclusive mode, is there a real reason to this or is it just something that needs to be fixed?

[Jerrot]

Well, The FadeIn works fine now, the reason it wasn't working before is because I seem to be an idiot...

Surely that's not the reason.

Anyway, the FadeOut still works only once (with the same code you posted). From the second time and on, the behavior is as follows: it goes black immediately, it then delays for the requested 1000msec with totally black screen, and only then the FadeIn of the window kicks in. Weird...

Hmm, strange. After the part I quoted I only unloaded the window and made another FadeIn() and it worked fine, even multiple times. Maybe you could post us your whole event where you handle the Main Menu call ? And did you add anything to the window script (on "close"...) ?`

About the Fade methods not working in system exclusive mode, is there a real reason to this or is it just something that needs to be fixed?

Mnemonic told me to check it out, he thought it should work. Maybe I just made something wrong.

[Mnemonic]

Ok, here I am with a solution (hopefully )

First the code to display the main menu:

[code]

[Mnemonic]

BUT! As I noticed now, I used GoExclusive instead of GoSystemExclusive. Because the GoSystemExclusive freezes the timer, making the fading unusable

[Daniel]

Well, now it's a lot better. The consecutive fade out problem is gone and both fade out and fade in work a lot better.

There are two issues remaining though:

1. What are the implications of the main menu window as well as all other windows (save, load, options, etc.) not working in system exclusive mode but only in exclusive mode? Does the fact that the game is not really paused when these windows are operated have any meaning at all? If so, do I have to give up the fading between the various windows?

2. The fading-in that is caused by the FadeIn call at the top of the window's script seems a lot more "sudden" than all the other fades, although it has exactly the same parameter as all the others. What could be the reason? Maybe a delay during window loading or something?

[Mnemonic]

1. What are the implications of the main menu window as well as all other windows (save, load, options, etc.) not working in system exclusive mode but only in exclusive mode? Does the fact that the game is not really paused when these windows are operated have any meaning at all? If so, do I have to give up the fading between the various windows?

Well, if the window runs in system exclusive mode, it freezes all the other scripts. In a regular exclusive mode all the scripts keep running, i.e. something can happen while the player is not looking.
Anyway, I'll add some Game.FadeOut2 and Game.FadeIn2 methods which will be unfreezable.

2. The fading-in that is caused by the FadeIn call at the top of the window's script seems a lot more "sudden" than all the other fades, although it has exactly the same parameter as all the others. What could be the reason? Maybe a delay during window loading or something?

I haven't noticed that in my testing application...

[Daniel]

Anyway, I'll add some Game.FadeOut2 and Game.FadeIn2 methods which will be unfreezable.

Is it necessary to have both FadeOut & FadeIn and also FadeOut2 & FadeIn2?

I haven't noticed that in my testing application...

Maybe I'm noticing this a bit more cause I'm using the default duration of 500msec. With this setting, the FadeIn at the top of the window's script is barely noticeable and the window just seems to appear almost immediately. The FadeIn after the Game.UnloadObject(WinMainMenu), however, is clearly noticeable with the same default duration of 500msec.

Anyway, this is a minor issue so don't feel obligated to check it right now, if you have a lot more burning issues to deal with. You can leave it for some other time when you find yourself bored with nothing else to do (which if you're anything like me, this means never )

[Mnemonic]

Is it necessary to have both FadeOut & FadeIn and also FadeOut2 & FadeIn2?

Yes, I think it is. While FadeOut and FadeIn are based on WME's internal timer, FadeOut2 and FadeIn2 will be based on Windows system timer. It means the first two will be saved together with savegames, while the second two won't. Both options are necessary because (in theory) you can have very long fades which need to be saved in progress (I know it's unlikely in case of fading the entire screen, but one never knows )

[McCoy]

Yes, I think it is. While FadeOut and FadeIn are based on WME's internal timer, FadeOut2 and FadeIn2 will be based on Windows system timer. It means the first two will be saved together with savegames, while the second two won't. Both options are necessary because (in theory) you can have very long fades which need to be saved in progress (I know it's unlikely in case of fading the entire screen, but one never knows )

Hehe, thinking about day/night cycles don't you? . Anyway, I don't like the "numbers" way, it can lead to errors while coding and you can forget what does what... Now it's only with Fades, but who knows, if it continues this way in the future, we'll might end up with a messy script system, and I don't want that, in fact I like WME scripting because every method name is very descriptive and logic. So why not adding a new parameter to the Fade* method for that feature, or giving it a more descriptive (but longer...) name like FadeInAsync or something if a new method is really necessary?

[Mnemonic]

Hehe, thinking about day/night cycles don't you?

Yes But as I said, it's unlikely someone's gonna use the Game.Fade* methods for it.

Anyway, I don't like the "numbers" way, it can lead to errors while coding and you can forget what does what... Now it's only with Fades, but who knows, if it continues this way in the future, we'll might end up with a messy script system, and I don't want that, in fact I like WME scripting because every method name is very descriptive and logic. So why not adding a new parameter to the Fade* method for that feature, or giving it a more descriptive (but longer...) name like FadeInAsync or something if a new method is really necessary?

Ok, you're not the only one who doesn't like it (hi Jerrot! ) Unfortunately adding a new parameter IMHO isn't feasible, since the fading methods already have a handful of optional parameters and if I added an extra one, you'd have to fill in all the others when using this new one.
Fade*Async also isn't possible, because these methods already exist (fading without blocking the script execution).
Ok, other ideas for names while keepng the names reasonably short?
There's another similar problem. I added the multi-channel music support, so currently there are two variations for each music function, such as PlayMusic / PlayMusic2, while the *Music2 functions take a channel number as the first parameter. Now, how to name all the secondary music functions? Jerrot suggested PlayMusicMC (for multichannel) but it's not exactly transparent either..

[McCoy]

Why not *MusicChannel? Maybe it doesn't look that good alone, but if it takes the channel number as first parameter, it wold be something like:

Code: [Select]

Game.StopMusicChannel(3);

Very straightforward and clear when it comes to coding IMHO ... Or maybe an optional parameter: if it's empty, then it works as the old method, and if there's some number, it uses that channel. It's not like with the fades methods because for PlayMusic there are currently only 2 parameters, and I think than a third optional one will not be that annoying. And moreover, for the rest of music functions, there's no parameter at all right now... (except for SetMusicPosition)

And about fades... you're right, there's async taken, I didn't know, so... maybe Fade*Global or something like that? Something short that shows that the process is independent from the rest of the main game loop... Fade*Daemon? But it's not exactly that... I'm out of ideas right now, but if something worthy comes to my mind, I'll post it.

[Mnemonic]

How about Fade*Unfreezable? Those methods will be rarely used anyway, so IMHO it doesn't really matter too much.

As for the music, yeah, thanks, that might work. Although GetMusicPositionChannel is a bit too long. I'm against adding an extra parameter to the existing methods, because in my opinion having the channel as a first parameter is much more consistent and transparent.

[McCoy]

Well, if someone is going to use a method a lot, and the name is long, he/she can always make some kind of "alias" trough scripting... It's a work-around, I know ... But it's that, or numbers, and IMHO the first option is better (just my taste).

And I think Fade*Unfreezable is OK, you're right, they're not going to be much-used methods so something descriptive is OK.