Messages

[on_key_press]

I tried putting your first code (from your post 10 Nov, 5.49) into my global script, and that resulted in the behaviour I described (i.e. if Space was held down, pause was toggled repeatedly, instead of just once). Here I'm not talking about how the script works, but about the actual experience when playing the game.

I don't think the problem as you describe it has anything to do with my code, so much as it has to do with the way that on_key_press works. So, to clarify, are you holding down the Space key during a blocking event, or during non-blocking event(s) when this happens?

[KeyPressAlways module]

To clarify, on_key_press is always executed repeatedly. Holding a key down will call on_key_press several times, but I don't know the rate offhand. Using on_key_press for this will cause your game to pause/unpause repeatedly.

The code in repeatedly_execute_always (from the code I posted) only executes if a blocking function is running and the pause key (eKeySpace) has been pressed (but not held). Holding down the pause key during a blocking function will only toggle the pause state once, not repeatedly.

This is a discrepancy between the behavior when a blocking script is running vs. when it isn't running.

If you want the on_key_press behavior to match the repeatedly_execute_always behavior, then you should use the KeyPressAlways module, which permits disabling the normal on_key_press function in favor of your custom on_key_press_always function (described in the module documentation).

If you want the repeatedly_execute_always behavior to match the on_key_press behavior, then you could add a variable to control how often the "held" state of the pause key resets.

Code: ags

eKeyCode pauseKey = eKeySpace; // this allows the key to be reassigned without having to change multiple lines in the script below
bool pauseKeyHeld = false; // whether the pause key has been held down from a previous game loop

// TODO: Adjust poll time as needed, e.g. GetGameSpeed() / 2 or GetGameSpeed() * 2
#define PAUSE_KEY_POLL_TIME GetGameSpeed()
int pauseKeyPoll = 0;
 
void TogglePause()
{
  if (IsGamePaused())
  {
    UnPauseGame();
  }
  else
  {
    PauseGame();
  }
}
 
function on_key_press(eKeyCode keycode) // standard on_key_press, NEVER called during blocking scripts
{
  if (keycode == pauseKey)
  {
    TogglePause();
  }
  if (IsGamePaused())
  {
    return;
  }
}
 
function repeatedly_execute_always() // called every game loop, during blocking AND non-blocking scripts
{
  if (!IsInterfaceEnabled()) // blocking script is running
  {
    if (!pauseKeyPoll) // poll timer expired, reset poll timer and "held" state
    {
      pauseKeyPoll = PAUSE_KEY_POLL_TIME;
      pauseKeyHeld = false;
    }
    else // poll timer not expired, update poll timer
    {
      pauseKeyPoll--;
    }
    if (IsKeyPressed(pauseKey)) // check raw state of pause key, key physically held down
    {
      if (!pauseKeyHeld) // if pause key was not previously held (last game loop) or poll timer expired
      {
        pauseKeyHeld = true; // set pause key as continuously held
        TogglePause(); // toggle pause state
      }
    }
    else if (pauseKeyHeld) // if pause key marked as held, but key has been physically released
    {
      pauseKeyHeld = false; // set pause key as not held
    }
  }
}

Could you post the code you're using? Because the code I posted doesn't do that. (bit irritable just now, sorry if I'm being short with you)

What it does not do, is that it does not literally suspend the script function at arbitrary point, but continues executing script commands until it either reaches the action that calls engine updates inside script (e.g. Wait, or blocking movement), or exits script function back to the engine.

Hmm, yes, I guess in that case you're right. Calling PauseGame is not a blocking action, so it can't arbitrarily pause the execution of a script function like Wait does. If that was asked about, I apologize for overlooking that. I think it has often been asked about as a "non-blocking Wait" which would yield control of the game script for the rest of the game loop like Wait does, but without running in the blocking thread. Pausing the game doesn't do that.

There are a lot of things which should respect the game's paused state, but there are just as many things which shouldn't. Whether or not a module's functions should respect the pause state depends entirely on the function that the module is providing, and module authors should bear the responsibility of making sure that they respect the pause state in a way which is logically consistent with the behavior they provide. The code snippet I provided here does respect the pause state. The KeyPressAlways module which I referenced in the other thread, is too abstract to force any particular behavior regarding the pause state, so it is up to the module user in that case to determine whether key presses should go before or after an "IsGamePaused" condition (which they would write in their own script, below the module).

I'm not sure what more beyond that you might have meant, but the engine's PauseGame and UnPauseGame methods do not, as you previously asserted, represent a "'character-protection' pause". With the proper logic in script modules and end-user developer scripts, these functions both work exactly as described by tor.brandt in the original post. The whole problem in this thread was one of bad logical conditions, not a bug or insufficient pause feature.

[exactly]

it occured to me that it's actually not possible to make an on_key_press PauseGame() function that overrides a currently running blocking script.
This means that it's not possible to pause the game e.g. while a character is speaking.

This is incorrect. You have unfortunately been misinformed.

PauseGame() function that overrides a currently running blocking script, and somehow stores the running script and the current "position" within that script, such that it can be resumed after UnPauseGame()

This is exactly how PauseGame/UnPauseGame currently works. See my reply in Beginners' Technical Questions. You were simply calling "IsKeyPressed" too often, without storing a "held" state of the key (which AGS doesn't do for you). There is actually a module for that, called KeyPressAlways.

[during]

The following works perfectly:

Code: ags

eKeyCode pauseKey = eKeySpace;
bool pauseKeyHeld = false;

void TogglePause()
{
  if (IsGamePaused())
  {
    UnPauseGame();
    //lblPaused.Text = "Paused? false";
  }
  else
  {
    PauseGame();
    //lblPaused.Text = "Paused? true";
  }
}

function on_key_press(eKeyCode keycode)
{
  if (keycode == pauseKey)
  {
    TogglePause();
  }
  if (IsGamePaused())
  {
    return;
  }
  //if (keycode == 'A')
  //{
  //  player.Say("Hello World!");
  //}
}

function repeatedly_execute_always()
{
  if (!IsInterfaceEnabled())
  {
    if (IsKeyPressed(pauseKey))
    {
      if (!pauseKeyHeld)
      {
        pauseKeyHeld = true;
        TogglePause();
      }
    }
    else if (pauseKeyHeld)
    {
      pauseKeyHeld = false;
    }
  }
}

And by "works perfectly", I mean this suspends the game, even during character speech and other blocking events.

Edit: Actually, there is a discrepancy. AGS apparently calls on_key_press periodically, though not as often as repeatedly_execute_always, so if you hold down a key the non-blocking event will run again after a period of time, while this blocking event will not exhibit that behavior, only (un)pausing the game once per key press. It could be made (presumably) to match the non-blocking behavior, but IMO, the way I've implemented this blocking event gives a better experience.

[SCRIPT_API_v340]

It's a bug in AGS, but as 3.4.0.3 is an alpha version it's doubtful that anyone will try to use the module with an earlier 3.4.0.x version. As you have the final release of AGS 3.4.0 (3.4.0.12), you can just delete the final digit from the line:

Code: ags

#ifver 3.4.0.3

(Line 3 of the module) So it should instead read:

Code: ags

#ifver 3.4.0

I have a mostly completed version 4.2 of the module which will use the SCRIPT_API_v340 preprocessor macro instead, which will make sure that the module has a sufficiently high AGS version without encountering this bug.

Also, SayBackground works fine for my purpose... if there is only one instance of talk.
But [code] only displays the second line, since, as you mentioned, the non-blocking actions are carried out simultaneously.
But I'd like it to first display the first line and THEN the second.
I guess I will have to use the timer then... I'll try to sort that out.

The QueuedSpeech module should be able to do what you're looking for with the background speech.

Watch out, Dave, this module has a serious (i.e. game crashing) bug: http://www.adventuregamestudio.co.uk/forums/index.php?topic=23806.msg636534826#msg636534826

Pushed a bugfix after reading this. Problem only occurs if the currently speaking (in the background) character starts walking while still talking. It was a feature that was prematurely released, but as that was nearly two years ago... well, it's fixed now.

[Edit:]

I've only just noticed this bug report. I haven't been around the forums much lately. The line in question was an incomplete attempt at getting the character to be able to move about freely without destroying or stopping the queued speech. This code was not meant to be included in the production release of v4.0, I apologize for that. Commenting it out won't harm anything in the rest of the module. I will upload a fixed v4.1 shortly, which will utilize #362 for AGS v3.4.1+ (and ignoring that feature for prior AGS versions).

Edit: Actually... looking at the changelog, it seems that I forgot that the feature wasn't fully implemented. It's been well over a year since I released this version, so I don't recall.

Edit, Mk. II: v4.1 is uploaded, and I even tested the changes.

Found an actual bug in this release. Keep an eye out for missing libs in your APK. Rebuilding seems to correct the problem, but I need to make sure that Gradle is always including these files. Fixed with v0.0.2-alpha.

[EXPERIMENTAL]

This is an EXPERIMENTAL build of the plugin for Android building. DO NOT use this plugin for releases!!

Downloads


Please view the README for instructions on using this plugin.

Source code

[Edit:] 19 August 2017, v0.0.3-alpha was released which permits the plugin to now function properly with AGS 3.4.0 (the latest stable version as of this writing). You need to download the plugin DLL and the "Android.zip" attachment as well. Extract "Android.zip" into "EDITOR_DIRECTORY/Android" (so, "EDITOR_DIRECTORY/Android/armeabi/libags_parallax.so", etc.), and the rest will work as detailed in the README.

As a technical note, this probably won't become feasible until the Allegro backend can be updated/replaced, which would essentially require a rewrite of the entire engine. I believe that Allegro 5 and SDL 2 both support HTML5 canvas, but I could be wrong about that. In any case, like CW said, it's not really possible ATM.

Using this thread as somewhat of a dev log for the plugin...

I was toying around a bit with security details since some passwords and other private data are involved, but I think it's a futile effort as the build chain depends on those items being available as plain text. What I can do is attempt to read those items directly from the Android Studio project (which is set up by the plugin as part of the build process) without serializing any of it to/from Game.agf.

I think the easiest way of collecting the necessary metadata from the user is a simple dialog wizard, which can be prepopulated from prior builds. That can be set up pretty simply. Then the last task will be to extract graphics resources from a zip archive, which isn't set up yet.

The plugin should be available pretty shortly, I think.

[large]

Got a fully automated build, but the process is still far too complicated for implementation directly into the editor. It will have to remain as a plugin, but that's not that big of a deal as I see it.

Prerequisites for the automated build are down to:

• JDK
• Android SDK
• Java keystore (required for signing, very simple to generate and only needs to be set up once)
• Following text items:


• string SdkDir: Path to the Android SDK installation (will look in default locations, but may require manual entry if installed elsewhere)
• string PackageName: Your app's package name (e.g., "com.bigbluecup.game")
• int VersionCode: Your app's version code (unique, increment only version used by Google Play Store)
• string VersionName: Friendly-text version
• string KeyStorePath: Path to your keystore
• string KeyStorePassword: Password for your keystore
• string KeyStoreAlias: Alias in your keystore file (usually each app will have a unique alias in your private keystore)
• string KeyStoreAliasPassword: Password for your app's alias in the keystore
• string GameName: Your game's name as displayed on the device
• int ObbVersion: The version code of your APK expansion file (to be updated if making changes to your game, as opposed to changes to the app itself)
• string ObbPassword: If you want your APK expansion file to be encrypted (though this isn't supported on all Android versions, AFAIK)
• string RSAPublicKey: Provided by Google Play Developer Console after your first APK file is uploaded (will default to embedding OBB file if left blank)
• string PrivateSalt: Comma-separated signed byte values ([-128, 127]) used as a salt when downloading your OBB file from Google Play
• Graphics resources (icons, etc.) (will accept a zip archive as input to replace these files)

As you can see, most of the text items are specific to your app, and many of them only need to be updated once. With these few items set up, an editor plugin will be fully capable of deploying an APK and OBB expansion file, ready for upload to Google Play. I should be able to have a plugin ready pretty soon, actually. As mentioned, the process isn't suitable for integration into the editor (I'm currently invoking two separate command-line processes, which will make tracking any errors much, much more difficult, and there are a large number of files (file count, not large in size) that have to be created on-the-fly).

Updated the OSD project, and expanded the README. This should clarify what is needed to build your own project's standalone APK.

[and]

Looked at the Android Studio project and I was jumping through some hoops to try and get the NDK build process to work with an older version of Android Studio and and out-of-date NDK (AGS didn't build with the then-latest NDK). During the process I used an experimental gradle plugin, but I don't think that was necessary. Using the latest (stable) gradle plugin everything seems to be building correctly, but I need to test further, and the project files required several changes.

This also made it apparent that however I was invoking the NDK from Android Studio was expecting the project to be located at the (ags-source)/Android/library path, which isn't really practical. I'm working on updating that to use a local property to point to the AGS source directory and then copy the built files as necessary. All of this (read as: this paragraph, not the entire post) only applies if not using the pre-built libraries which are linked in the README, though of course those libraries are out-of-date, relative to the latest AGS versions. Additionally, AGS (master) isn't building with the latest NDK, but that's not really related and I think it is because the newer NDK doesn't really use the Android.mk file...

The above paragraph also isn't really related to being able to build everything from the editor, as that would rely on pre-built libraries. It should be possible for the editor to make a copy of a "base" Android Studio project, do the necessary text and resource replacements, invoke a Java process to build the game files into the necessary OBB, and then invoke the gradle command line to build the Android Studio project.

Dialog scripts use a special syntax. Any normal scripting commands (including assigning variables) must be indented, e.g., "  myVar = true;" vs "myVar = true;". Make sure the line starts with at least one space.

[already Compiled AGS games]

As CW said, you need to use the jobb/jObbifier tool to package already Compiled AGS games.

I've updated my jObbifier project to build with Gradle, and I believe I can also invoke my patched jobb library from the Gradle command line (or, rather, I can definitely invoke the java command as a process... and build the Android Studio project using the Gradle command line). If this is the case, then it may be possible to invoke a full build of the Android Studio project from an AGS plugin, but that will still take some time.

I don't have the time to explain to you how to use Android Studio, if that's what you're asking for, but there are tutorials on getting started... beyond that I really don't know what more you're wanting.