Messages

1) What is the total file size of the game assets? (file size of the Compiled/Data folder)
2) Are you using the OBB file that the plugin builds, or are you building the OBB file yourself?
3) Are you trying to embed the OBB file into the APK (e.g., RSA public key is blank), or load it from external storage (RSA public key is filled in)?
3a) If loading the OBB from external storage, are you certain that you've placed the OBB file in the correct location?
4) Do both of the console windows that pop-up during the Android build process show that their respective processes were successful?

[[code]

Your code from the first post, with fixed [code][/code] tags:

Code: ags

//global header
import function FaceDirectionWithoutTurn (this Character*, CharacterDirection, BlockingStyle);
 
// global script
 
 function FaceDirectionWithoutTurn (this Character*, CharacterDirection, BlockingStyle)
{
  SetGameOption (OPT_TURNWHENFACING , 0);
  this.FaceDirection(CharacterDirection, BlockingStyle);
  SetGameOption (OPT_TURNWHENFACING , 1);
}

CharacterDirection and BlockingStyle are the names of enums, and are used exactly the same way as you would use int. Namely, you need to give your parameters a name in the function definition:

Code: ags

 function FaceDirectionWithoutTurn (this Character*, CharacterDirection direction, BlockingStyle block)
{
  SetGameOption (OPT_TURNWHENFACING , 0);
  this.FaceDirection(direction, block);
  SetGameOption (OPT_TURNWHENFACING , 1);
}

imports do not need to have named parameters, and for enums it is conventional to not give them names in the import unless their use is ambiguous. However, in the function definition your parameters must have names or you can't access the value passed in.

Maybe so, but I still think it makes more sense to not have something like this hard-coded. It would be trivial to implement in the default template, whereas implementing custom "when mouse moves to top of screen" behavior is far less trivial (not "difficult" per se, but definitely less simple than the former).

It just wasn't expected, for a "No Action" button click to have side-effects.

The link doesn't work.

Yup. Renamed the project where the downloads were hosted and forgot to update the links. Editing now.

The mouse is repositioned from remove_popup_interface, which is called from gui_on_mouse_up. Correction to the above: The mouse is only repositioned if clicking on an enabled GUI button, slider, listbox, or inventory window, after process_interface_click has been run. It still seems (to me) counter-intuitive to move the mouse and hide the GUI if the click didn't do anything though. However, I can't really think of any justification for an enabled control of these types with no associated action as a general case.

That said, I keep going back and forth on whether this should be considered as "by-design" or not. Is automatically moving the mouse like this actually something that should be hard-coded into the engine? Perhaps it would make more sense to expose the PopupAtMouseY and PopupStyle to the script API, and update the default template to preserve this behavior while not enforcing it at the engine level.

And it doesn't work HOW? What happens when your game gets to that point? If it won't compile, or if it crashes, what does the error message say? "It doesn't work" is not a helpful bug description.

Ok I understand.

I lol'd.

After clicking on a GUI whose visibility is set in the editor as "When mouse moves to top of screen", the mouse cursor is repositioned to just below the GUI PopupYPos. This apparently happens no matter whether any script event is run, cursor mode is set, etc. The relevant script in the engine seems to be:

Engine/ac/gui.cpp#L290

Code: cpp

void process_interface_click(int ifce, int btn, int mbut) {
// ...
    if (rtype==kGUIAction_None) ; // line 290
// ...

But nowhere in that function nor any of the functions that call it does it apparently move the mouse cursor. I can understand the reasoning behind hiding the GUI if something actually happens, but if the click doesn't do anything then hiding the GUI seems to be counter-intuitive (e.g., player accidentally clicks on GUI background instead of button).

If it matters, I found this behavior on 3.4.1-b5.

A number of users also reported the speed up problem after activating the steam overlay, which is activated using shift-tab.

To be presice, that's not speeding up, that's key press not being unregistered, and this every following speech gets skipped by a "key press".

Dave, I've sent you (via Facebook) a modified build of the Steam plugin that should completely ignore any keyboard input (to AGS) if the Steam overlay is active. Let me know if that helps, and I'll push out the revision for everyone else, thanks!

Looks like we probably had similar results. Since I was specifically emulating speech, I also had to account for the "feature" whereby if a character is standing in the far left or far right quarter the screen's horizontal space, the available width for character speech is truncated by 1/5 of the width of the screen... Chris Jones was kind enough to cue me in on that.

Magic numbers!

There is now a wiki, which explains using AGS2Client plugins.

[both]

Sorry for the confusion. The AGSteam plugin now uses the AGS2Client interface. To make building for multiple clients (e.g., both Steam and GOG Galaxy) simpler, I replaced the game script struct "AGSteam" with "AGS2Client" in both the AGSteam and AGSGalaxy plugins.

Code: ags

AGSteam.SetAchievementAchieved("ACHIEVEMENT_01");

Would then become:

Code: ags

AGS2Client.SetAchievementAchieved("ACHIEVEMENT_01");

The practical upshot to doing this is that if you are using both AGSteam and AGSGalaxy, then you could avoid nastiness such as:

Code: ags

#ifdef AGSteam_VERSION
AGSteam.SetAchievementAchieved("ACHIEVEMENT_01");
#endif
#ifdef AGSGalaxy_VERSION
AGSGalaxy.SetAchievementAchieved("ACHIEVEMENT_01");
#endif

You would just toggle the active plugin and hit rebuild. Hopefully that makes sense.

The "disjoint" builds preserve the client-specific names ("AGSteam" and "AGSGalaxy") in the scripts, so if your game already depends on those scripts you can use the disjoint build of the plugin.

[AGSteam-disjoint.dll]

I've updated the Windows DLL downloads for AGSteam to avoid the need for any particular C++ runtime to be installed, which was an oversight on my part in the first place. Will work on updating other download links. Sorry for the confusion.

To be clear, if you're replacing "agsteam.dll" from a game which uses "AGSteam" in the game scripts (e.g., AGSteam.SetAchievementAchieved(...)), then make sure to grab the AGSteam-disjoint.dll and rename it to "agsteam.dll".

Hardlinks don't break if one of the links is deleted. I also thought that the hardlink function was set to do a file copy as a last resort, though obviously not.

it does not put explicit Dialog.Start there, but "return" statement with the number of next dialog, which triggers dialog run in the engine.

So the regular script equivalent of goto-dialog X is simply   return X;?

In fact, I just tested it, and that's precisely the case.

Code: ags

  if (cond1) {
    // do something
    return 2; // goto-dialog 2
  }
  else {
    // do something else
    return RUN_DIALOG_RETURN; // don't go to dialog 2
  }

[does]

Using Dialog.Start() does break goto-previous (at least when Start is called from a dialog script). Using goto-dialog in a braceless condition does not.

[[code]

Right, you won't be able to use braces on the condition, so you would need to rearrange it as:

Code: ags

  if (!cond1) {
    // do something else
    // don't go to dialog 2
    return RUN_DIALOG_RETURN;
  }
  // since the "if" now contains a "return" statement, then the "else" block is implicit
  // for the following commands, cond1 is true
  // do something
goto-dialog 2

P.S. Use [code] and [/code] blocks around your code in the forums!

Using:

Code: ags

@1
  if (cond)
goto-dialog 1
return

Generates a warning that the "return" will be ignored, but with 3.4.0, this works as expected, and the "goto-dialog" is, in fact, run conditionally.

[above]

ScrollingDialog is the name of a script module I wrote. Script modules have to be imported into your game (see the manual). If the script has been imported to your game, you have to make sure that the ScrollingDialog script is above the script where you're using the module functions in the Scripts tree.


That said, Khris' suggestion about using an alternative may be an easier approach if this is the only thing you need it for.

[dialog option tagging]

The ScrollingDialog module has this feature built-in:

One really cool feature that the module includes is dialog option tagging. What that means is that you can create a custom tag that you will later replace with some other text, such as a character's name. You tell the module what you want to replace the tag with (using ScrollingDialog.SetTag), and then when the dialog options are drawn, the module will handle it for you!

Code: ags

  cPet.Name = "Spike";
  ScrollingDialog.SetTag("%PETNAME%", cPet.Name);

Then if you have a dialog option set to "My dog's name is %PETNAME%." (for example), then the text would be displayed as "My dog's name is Spike.".

There is also a built-in tag for the player name (ScrollingDialog.PlayerNameTag), which is always replaced with the current player name. This will save you from having to change the tag if you change the player, as it will always stay up-to-date with the current player character.

NOTE: If you are using a tagged dialog option, you should always leave the Say check-box unchecked. The module can't overwrite the actual dialog option text, so if the player reads that option, they would end up saying the original text, as set up in the editor. If you want the player to read that option, then instead include a line such as this in your dialog script:

Code: ags

// dialog script
@S
return;
@1 // My dog's name is %PETNAME%.
  player.Say(ScrollingDialog.SelectedOption.Text); // say "My dog's name is Spike."
return;

This will ensure that the dialog tags are replaced appropriately.

You would simply call ScrollingDialog.SetTag when you needed to update the value, such as:

Code: ags

ScrollingDialog.SetTag("%BUYSELL%", "something");

The "tag" can be any text, just make sure it's something unique that wouldn't normally appear in your dialog option text.