SOLVED: player.ChangeView() has no effect

[Cerno]

Hello all.

I am trying to implement an in-game menu that allows to change the player's appearance.
The menu is always open in addition to the existing SCUMM VerbCoin GUI.

I added a character and two views. The character is defined in the AGS GUI to have view 1.
I want to use scripting to change to view 2 if a game GUI button is pressed.
So I added a gui to the game and placed some buttons on it.
Then I added a script resource with the following code:

Code: args

function on_event(EventType event, int data)
{
  if (event == eEventGUIMouseDown)
  {
    GUIControl *control = GUIControl.GetAtScreenXY(mouse.x, mouse.y);
    if (control == changeappearance) //name of the button
    {
      player.ChangeView(2); //view to change to
    }
  }
}

In the game, nothing happens when I press the button.
According to the debugger, the function is called fine, so I guess the script is okay.

I tried the following modifications:

* added SetIdleView before ChangeView --> The character changes to the idle view correctly after a time and immediately back to the incorrect view 1
* added a second, non-player character and try to change it to view 2 using the ChangeView function --> Works correctly.
* called the function by the player character's name instead of by player --> Same error
* called LockView(2) --> Correctly changes the view (but I suppose auto-view changes will not work unless I unlock the view. When I do that, the character switches right back)

Any ideas where I could look?
Are there any automatic view changes back to the starting view?

I was unable to find anything in the manual under the ChangeView function.

[edit: figured out code tags]

[Khris]

You might have to use

Code: ags

    if (control.AsButton == changeappearance) ...

But, there's a much simpler way: just double-click the button in the GUI editor and a function is created and linked to the button's on_click event.
Just call the ChangeView command in that function and you're set.

The event you're using is only meant to detect clicks on GUIs outside any active controls.

[Cerno]

Thanks for the input Khris.

This helped improve the code structure but did not solve the problem.
As far as I can tell, control and control.AsButton do the same thing in my example
The suggestion of using the on_click-function also works the same.

But as I stated before, the function ChangeView is called, however, the character immediately turns back to the original view.

[OG]

Cerno, you're making things overly complicated for yourself.

As Khris said, using a gui button's on_click to change the player view is so much simpler. I can not fathom why you would do it any other way tbh.

Code: AGS

function Button1_OnClick(GUIControl *control, MouseButton button)
{
player.ChangeView(VIEW1);
}

This works flawlessly. Obviously the 'Button1' and 'VIEW1' are subject to be different depending on what button or view you intend to use/ change to.

You either make as many buttons as you wish there to be view changes, or you decide that:

Code: AGS

function Button1_OnClick(GUIControl *control, MouseButton button)
{
if (player.View ==1){
player.ChangeView(VIEW2);
}
if (player.View ==2){
player.ChangeView(VIEW3);
}
if (player.View ==3){
player.ChangeView(VIEW1);
}
}

Or something similar.

If I missed a bracket, Khris will let you know! (Kidding Khris! )

[Khris]

But as I stated before, the function ChangeView is called, however, the character immediately turns back to the original view.

You had said that nothing had happened at all, this is different from the view changing, then reverting to the original one.
Can you confirm that this is what's happening?

Are you using any modules?

Also make sure that the new view has at least four loops and at least two frames in every loop, just to be on the safe side.

[Ryan Timothy B]

Also make sure that the new view has at least four loops and at least two frames in every loop, just to be on the safe side.

I've never had an issue with a single framed loop; even if it's just meant as a precaution it doesn't sound like a good suggestion to me.


Cerno, you wouldn't happen to have the code that changes the character to View 1 inside the repeatedly execute or repeatedly execute always function?
The other possibility I believe is likely the case: in the room editor, you wouldn't happen to have the walkable area the character is standing on having AreaSpecificView set as 1, would you?

[Cerno]

Hello all.

Thanks a lot for your input. Now on to the specifics:

@Onker: Sorry for not making it clear enough. I did take Khris's advice and put the function in the onclick function (I said that it made my code clearer, didn't I?). I also said that it did not solve my problem.

@Khris: I guess I did not describe it properly. Both is true. There is no perceivable change, but if I change the idle view, the character changes to idle and then back to the incorrect view 1. So I was thinking the game changes the character to view 2 and changes it back to 1 without displaying the change. Possibly I was jumping to incorrect conclusions.

Afaik I am not using any modules. I have 4 loops each with only one frame. Since the change works fine for non-player characters that use the same view I would assume that it cannot be the loops, as Ryan suggested.

@Ryan: I am not using any repeatedly execute functions. Good call on the AreaSpecificView, but alas, it's 0.

However, something else is strange:
I created a new game from scratch. Then I copied the old text-based files over the new game (agf, asc, ash).
I did not copy the binary formats (rooms and sprites).
After importing the images into the game the switch now works.

So I'm guessing that the error was in the rooms binary file. I had some hopes that the AreaSpecificView was at fault, but unfortunately it's not. Does anyone have an idea about a similar setting that might cause this?

I really would like to find out what's wrong, as rebuilding the game from scratch does not sound like a fun way to solve the problem should it reappear when the game is more advanced.

Thanks for the input all and please keep posting

[Cerno]

BAM, and here we have it.

The setting at fault here is the room's PlayerCharacterView. It was set to 1 instead of 0.
What I did not know is that this setting overrides any script changes. I assumed it was a kind of default value.

Thanks all for participating, especially to Ryan for getting me on the right track.
Consider this closed.

[Ryan Timothy B]

What I did not know is that this setting overrides any script changes. I assumed it was a kind of default value.

I did not know that even existed, so thank you as well. I never did play around with the room editor all that much throughout these years - generally just scripts.