fade/changeRoom execution order

[Monsieur OUXX]

Hi,

this question has already been asked 1000 times, but there is a slightly different parameter here :

People have often been complaining that if you use the "FadeIn" or "FadeOut" functions and then any other function, they are not executed in the expected order (this is often solved by adding some calls to the "Wait" function).

But here, I'm not using "FadeIn" or "FadeOut". I'm just using "changeRoom" and I'm expecting the automatic transition  to start at the right time, which doesn't happen : the character first teleports to the coordinates used as parameters in "changeRoom" and THEN the fadeOut happens, which is very unpleasant.

I am using AGS 3.0 RC4.

[Monsieur OUXX]

Sorry to up, but I know that someone knows the answer, and I guess that this problem is different from the usual FadeIn/changeRoom one.

[ncw14]

i have the same problem but and i cant find a solution here but im sure someone knows, im the person who asks instead of answers

[monkey0506]

I can't say for sure why it would be doing this...I thought AGS was supposed to change the Character's x/y values in the "enters room before fadein" event automatically...not before the previous room is ever faded out. Though it's a bit unwieldy, you could perhaps workaround the issue by leaving the x/y values out of the ChangeRoom call and then either in the global on_event or the room's local handlers you could do:

Code: ags

if (player.PreviousRoom == Z) {
  player.x = X;
  player.y = Y;
}

[ncw14]

its probalably doing it because this command comes before others that are executed in that room try moving the line to the last line in that section
(i cant word things good)

it worked for me

[Monsieur OUXX]

its probalably doing it because this command comes before others that are executed in that room try moving the line to the last line in that section
(i cant word things good)

it worked for me

"changeRoom" is the one and single executed command : i put it in the interaction "player stands on this hotspot".

As I said, i don't use any explicit "fadeIn"/fadeOut; if I was using them it could explain the "bug" since changeRoom is always the last executed command (it is explained in the manual)... But he I expect the automatic transition to sort it out!

monkey : thanks for your workaround, I've been thinking of other workarounds myself but I'm waiting for a correct solution for this extremely simple issue. Might it be an AGS 3.0 bug? Could it be that CJ simply made the engine to execute fadeOut/changeRoom/fadeIn in a row exactly the same way as the end-user would have done it?

[Khris]

i put it in the interaction "player stands on this hotspot".

That interaction was probably only included due to backwards compatibility, in 2.72 there was a remark: "(obsolete, use regions)".

Try to use a region instead, putting the code into "player walks onto region".
This might fix it.

[Monsieur OUXX]

put the code into "player walks onto region". This might fix it.

Thanks, KhrisMUC, I'll test that

I tried that, it does exactly the same...
1/ Players teleports to the "changeRoom" coordinates
2/ The automatic fadeOut/fadeIn happens.

Nobody tried that with AGS 3.0 RC4? I used the default template, the one with the talking skull.

[ncw14]

put a funtion after changeroom like

GUIOff(STATUSLINE) //and then
GUIOn(STATUSLINE) // Put these in the same thing as player.changeroom but put it after it

ps - this is not updated the newest way to do is is more complicated though so i stick to this

if you dont use statusline Gui then do something like
the same thing but replace (STATUSLINE) with a Gui you use

[Monsieur OUXX]

put a funtion after changeroom like

GUIOff(STATUSLINE) //and then
GUIOn(STATUSLINE) // Put these in the same thing as player.changeroom but put it after it

ps - this is not updated the newest way to do is is more complicated though so i stick to this

if you dont use statusline Gui then do something like
the same thing but replace (STATUSLINE) with a Gui you use

Oh yes, this is an archaic way to proceed
But... I can't understand that nobody knows the answer. do people use changeRoom and they don't have the issue, or do they just DON'T use this function

[Khris]

I've tried this myself now. It works fine in 2.72, but RC4 does indeed move the character, then fade out. Definitely a bug.

[Monsieur OUXX]

I've tried this myself now. It works fine in 2.72, but RC4 does indeed move the character, then fade out. Definitely a bug.

I don't know if you reported this in the RC4 thread. Having a look and adding the post if necessary.
Thanks for having investigated, KhrisMUC