[Feature Request] Knowing whether the debug window for teleport is being used

[Vincent]

One thing I've always liked to have is a feature to know whether the debug window (for teleporting) is being used or not 🙄 what I'd like to do is teleporting to a room and then check inside the script if the player is inside the room by teleport or not something like:

Code: ags

function room_Load()
{
   if (game.debug_mode)
   {
      if (game.debug_teleported) ... 
   }
}

or is there a workaround to do this already without having a custom debug window?

[eri0o]

Erh, you can just set a global variable if you use and then unset it in your check. The script that creates the teleport window you mention is in your global script - you can also not use that and write your own one that actually prepares the game state for each place before going there.

[Vincent]

Erh, you can just set a global variable if you use and then unset it in your check.

I think I dont get what you mean, how do I check if I just used the teleport? I mean the one you show by pressing ctrl+X

[eri0o]

The Ctrl codes in AGS are in your global script, they only come pre-written as a suggestion, but you can do whatever you want with them.

[Vincent]

If I press ctrl+x, selecting a room and teleport into it, how do I check with a global variable if I used the teleport or not? I mean the pre-defined Ags debug window and not a custom one, is there a way to do that?

[Snarky]

You take this bit of your GlobalScript:

Code: ags

// called when a key is pressed
function on_key_press(eKeyCode keycode) 
{
  // ...
  else if (keycode == eKeyCtrlX)
  {
    // Ctrl-X will let the player teleport to any room
    Debug(3, 0);
  }
}

And change it to set a Global Variable (that you have created), for example callled teleporting:

Code: ags

// called when a key is pressed
function on_key_press(eKeyCode keycode) 
{
  // ...
  else if (keycode == eKeyCtrlX)
  {
    // Ctrl-X will let the player teleport to any room
    teleporting = true; // <-- Added this!
    Debug(3, 0);
  }
}

Now in the room enter function, you check whether teleporting is set, and remember to set it to false (in every room):

Code: ags

function room_Load()
{
  if(teleporting)
  {
    // Do stuff
  }
  teleporting = false;
}

I don't remember if the debug window lets you cancel the room change. In that case, this will have a side-effect that the next time you change the room, it will think you used the teleport. But since it's a debug feature, that doesn't seem like a big problem.

[Vincent]

Well yea I thought about this too but there is a problem I think, I mean let's suppose I open the debug window by ctrl+x but then I do 'cancel' instead of teleporting, that variable will stay true because I hitted ctrl+x

:EDIT: yes, you can 'cancel' or 'confirm' the process of teleporting, also it would be interesting to have a feature to check if that specific debug window is visible or not apart from check if you use to teleport into a room or not

[eri0o]

Erh, it looks like it's best to give some tooling so you can make your own window of that. Just to be clear, you can, you just make a GUI and write your own stuff for that and then just use that in that place in global script - a lot of larger games do that because usually the room alone isn't a good indicator of where in the story the player is.

But let's say there is a RoomInfo struct with read-only properties like Description, then you can do something like:

Code: ags

for(int i=0, j=0; j<Room.Count; i++)
{
  if(Room.Exists(i){
    RoomInfo* = Room.GetRoomInfo(i);
    // do stuff
    j++
  }
  i++
}

[Crimson Wizard]

It should not be at all difficult to make a custom GUI for teleporting, and I've seen many devs actually do that in their game. Besides it's often important not to teleport to a particular room but to a particular story stage, which AGS cannot do on its own of course, so you will have to do a custom gui again.

But speaking directly of the proposed feature, what is the use case? Or, which difference do you want to handle with this?

If you want to know that player appeared in the room not following the story, but "jumping over", then you could rather use your own "story"-related global variables to find that out. You may also check player's position in the room to find out that it's wrong (in case you must fix it).
EDIT: there's also player.PreviousRoom, which may be used in conjunction with the story vars.


EDIT 2: speaking of the teleport window result, it's possible to make the Debug function return a true or false value (1 or 0) depending on the player's choice.
(On a side note, this Debug function is ugly as hell)

[eri0o]

Maybe return room number or something that means cancel?

[Vincent]

If you want to know that player appeared in the room not following the story, but "jumping over", then you could rather use your own "story"-related global variables to find that out.

Okay so I guess the only way is to make a proper custom debug window which handle also the 'story'- related variables, teleporting etc. Thanks everyone for the input

speaking of the teleport window result, it's possible to make the Debug function return a true or false value (1 or 0) depending on the player's choice.

You mean it can be done by editing the engine? I think that might could be useful, so maybe if the value is true then it means you teleported

[Crimson Wizard]

You mean it can be done by editing the engine? I think that might could be useful, so maybe if the value is true then it means you teleported

Yes, I think i'd rather suggest to add a return value indicating Teleport window result, rather than a new variable to game struct. The reasons for this are:
* The "Teleport" window is not a part of the script API directly, it's hidden in the generic Debug command, so it's better to not add anything related to it in the global structs.
* This variable would have a too narrow use-case, it will be useless if a developer decided to make their own debugging controls, or even a random ChangeRoom call for testing.

So handling this situation will be as suggested above, except you do:

Code: ags

    // Ctrl-X will let the player teleport to any room
    teleporting = Debug(3, 0);

Maybe return room number or something that means cancel?

Yes, the return value could be a room number, or -1 for cancel, for instance.

[eri0o]

I think now that you mentioned the whole debug API your suggestion of just a true or false is better, as it could at some point be extended to other debug commands - showing mask returns true, hidden mask returns false and such. Not suggesting adding it now, just that the true/false approach works better in this sense. Just thinking from it being more intuitive, so this could be guessed/infered.

Thinking on the comment that shows up when mouse over the function it could have the added sentence "Returns false when action is cancelled" and this could be extended to be true to all debug commands.

[Crimson Wizard]

For the long term I'd rather consider replacing this function with explicit Debug struct that has various tools in it, than keep shoving in various commands with different logic.

[Snarky]

Well yea I thought about this too but there is a problem I think, I mean let's suppose I open the debug window by ctrl+x but then I do 'cancel' instead of teleporting, that variable will stay true because I hitted ctrl+x

The question is if this is really a serious problem. After all, this is just a debug tool for your own use. It doesn't have to be perfect as long as you know its limitations.

I also suspect it might be possible to do a workaround by wrapping ChangeRoom() calls in a helper function. Or show a GUI with a button to reset the teleporting variable. But you haven't really explained why you want this, so it's hard to suggest the best solution.

[Vincent]

Of course its not a serious problem, I think your workaround will work just fine. I just wanted to know if the player appeared in the room not following the story variables but just "jumping over" on it and if that so setting some variables accordingly. The main reason of having this request was avoiding having a custom debug window but this seems a proper way to go ahead or using your workaround will just do all of this