Messages

[IFF]

I can confirm the naming issue. IFF a character name starts with the 'c' prefix, then AGS will (for legacy purposes) define the preprocessor macro "NAME" (where "NAME" is the rest of the character's name, sans the 'c' prefix). View names are similarly made into macros, but lack any prefix. So a character "cName" and a view "Name" will actually conflict. Unless I'm mistaken, AGS's compiler actually has a "proper" preprocessor for macros in that it does a text replacement in your scripts. This would mean that it could be phased out of the editor altogether without negatively affecting legacy games. I'm not aware of anyone who has upgraded to current versions of the editor that is still relying on character name macros (typically used with the legacy character script functions).

[can't]

There's no built-in IsModeEnabled, but you can't switch to a disabled mode:

Code: ags

bool IsModeEnabled(this Mouse*, CursorMode mode)
{
  CursorMode oldMode = this.Mode;
  this.Mode = mode;
  bool result = (this.Mode == mode);
  this.Mode = oldMode;
  return result;
}

Usage:

Code: ags

if (mouse.IsModeEnabled(8))
{
  // do stuff
}

Edit: See also - MousePlus module

[to]

If I understand you correctly, the player character themselves doesn't participate in this dialogue, just the other two characters are speaking to the player at this point, yes?

You don't have to use the built-in dialog system if the player isn't going to speak... but regardless... You can create a pair of global variables to handle this. You can make them bool variables that default to false, and name them something like spokeToA and spokeToB.

As far as setting the player character, that's a simple matter of calling the SetAsPlayer function at the appropriate time. Here's an example using dialog scripts.

Code: ags

// character A dialog
@1
  if ((spokeToA) && (spokeToB))
  {
CharacterA: Why would they think that?
option-on 2 // Become Character A?
option-on 3 // Leave.
option-off 1 // (blank option)
    return RUN_DIALOG_RETURN;
  }
  else
  {
CharacterA: If you see Character B, tell them I want to talk to them.
    spokeToA = true;
  }
stop
@2
  cCharacterA.SetAsPlayer();
stop
@3
stop

Code: ags

// character B dialog
@1
  if (spokeToA)
  {
CharacterB: Did I do something wrong?
    spokeToB = true;
  }
  else
  {
CharacterB: Oh, hi.
  }
stop

Relevant entries in the manual: Other features -> Global variables, Tutorial -> Setting up the game -> Conversations, and Scripting -> Character functions and properties -> SetAsPlayer

Edit: Snarky beat me to the post. Hope this helps though.

I uninstalled Avast, ran CCleaner, rebooted, and reinstalled Avast. I have no more problems with Avast and AGS. (NOTE: Avast was also causing other issues, such as Spotify not updating, so it was definitely an Avast issue)

[Latest binaries]

Latest binaries are up with some significant changes. First of all, the plugin is now feature-complete with stats and leaderboards! AGSGalaxy also now supports unified builds by default (agsgalaxy.dll). If you want to continue using the Galaxy-specific struct name of "AGSGalaxy" in your game scripts, feel free to use the "disjoint" plugin (agsgalaxy-disjoint.dll) instead. All this really changes is how you call the Galaxy functions, but the two versions (unified and disjoint) generally shouldn't be used together (theoretically they won't conflict, but there's just no reason to have both since they do the same thing).

[Latest binaries]

Sorry for the unresponsiveness folks. Latest binaries are up with some significant changes. AGSteam now supports unified builds by default (agsteam.dll). If you want to continue using the Steam-specific struct name of "AGSteam" in your game scripts, feel free to use the "disjoint" plugin (agsteam-disjoint.dll) instead. All this really changes is how you call the Steam functions, but the two versions (unified and disjoint) generally shouldn't be used together (theoretically they won't conflict, but there's just no reason to have both since they do the same thing).

@Neo_One: You don't have to even initialize the Steam API to release a game on Steam. A lot of Steam games don't use Steamworks, have no achievements, etc. You only need to use this plugin if you have achievements, and as such, you do have to tell the plugin when the achievements (etc.) should be set. You do this with some simple function calls, such as:

Code: ags

AGS2Client.SetAchievementAchieved("ACHIEVEMENT_01");

Where "ACHIEVEMENT_01" is the API name of your achievement (as set up on the Steamworks backend website). This is how Steam knows that the achievement has been unlocked. You would call this function whenever the player triggers the action that unlocks the achievement.

@Mark: Not sure, I'll look into it. I know Linux has been an on-going issue for you. I will contact you.

[REGARDING 'UNIFIED' CLIENT PLUGINS]

REGARDING 'UNIFIED' CLIENT PLUGINS

The client plugins I have written (AGSteam and AGSGalaxy) now support "unified" building by default. This means that you will use "AGS2Client" in place of "AGSteam" or "AGSGalaxy" in most cases. A call such as:

Code: ags

AGSGalaxy.SetAchievementAchieved("NAME");

Will instead become:

Code: ags

AGS2Client.SetAchievementAchieved("NAME");

(and likewise for AGSteam)

The benefit behind this is that you can toggle between AGSGalaxy and AGSteam (or other future plugins) without having to change your game scripts. To take full advantage of the unified plugin builds, you must ensure that the "API name" (the name you call from your game scripts) is exactly the same on both the Steamworks and GOG Galaxy backend websites. This is what makes the unified build work! Once the achievements are set up properly on the backend websites, you can toggle between using the AGSteam and AGSGalaxy plugin and rebuild your game without having to change any code (or duplicate any code). For an example of this in action, see the Steam+Galaxy project (instructions).

Note that the unified builds replace the client-specific struct name ("AGSteam"/"AGSGalaxy") with "AGS2Client", and so the version macro is replaced with "AGS2Client_VERSION". However, to ensure that client-specific functions can still be utilized, the client-specific version macro is also defined. So the AGSteam unified plugin will define "AGS2Client_VERSION" and "AGSteam_VERSION" both with the version number of the Steam plugin. AGSGalaxy will define "AGS2Client_VERSION" and "AGSGalaxy_VERSION" both with the version number of the GOG Galaxy plugin. This is necessary in particular to initialize the GOG Galaxy plugin, which requires a client ID and client secret not required in initializing the Steam plugin. See the Steam+Galaxy project for an example of how to implement this.

You may instead choose to utilize the "disjoint" build of the plugin, which still uses "AGSteam" or "AGSGalaxy" instead of "AGS2Client", but this means you will have to use separate code for Steam and Galaxy builds. A practical reason why you might want to do this is to allow "Galaxy crossplay" builds. Essentially that means that you would include BOTH the AGSGalaxy AND AGSteam disjoint builds AT THE SAME TIME. You would initialize both client APIs, and call their respective functions separately. Doing so would allow you to have a single build of your game released on Steam and GOG Galaxy. As long as the player has both clients installed, then they can gain achievements for both clients at once. The disjoint plugin builds have "-disjoint" in the filename, but you can rename the binary (DLL) as needed for compatibility with an older game that uses client-specific game scripts.

Now that I've finally gotten around to finishing the GOG plugin and updated the Steam plugin, I made a sample project that shows how you can set up your achievement code once in AGS and not have to worry about duplicating the code.

Downloads and such

To set up your game (using the Steam+Galaxy project), there are only a few things that need to be done:

1) Make sure that on the Steam and GOG backend websites, your achievements are set up with exactly the same API names (this is the name you use to set the achievements from AGS).
2) Replace the contents of "steam_appid.txt" in your Compiled folder with your Steam game's app ID. For release builds, you can delete this file entirely, but you don't have to.
3) In the Achievements script header, add your GOG Galaxy client ID and client secret.
4) In the Achievements script header, create friendly enum names for each achievement.
5) In the Achievements script file, set the API name that corresponds to each enum'd achievement.
6) In the Achievements script file, modify or remove the on_key_press function to match your game's needs. Call Achievements.Set as needed (instead of AGS2Client.SetAchievement!) and you will also be able to build with both plugins disabled.
7) Make sure you have the appropriate plugin enabled for the release you want to build (if any), and "Rebuild all files" (trust me, it's for the best when changing plugins).
8) For release, make sure to remove the Steam- or GOG-specific plugins from your Compiled folder.

P.S. I've also recently come across "Galaxy Crossplay". I'm not aware of any AGS games using matchmaking features (yet!), but it would be entirely possible to use both plugins simultaneously and thereby allow setting achievements in Steam to also set the achievement in GOG Galaxy. For this you would need the "non-unified" variant of the plugins. I'll work on cleaning up the project files to make more sense of this, and release appropriately named binaries.

[EDIT:]

I wasn't aware that this was an issue!

I will no go ahead and replace all of the floats in the AGSteam, AGSteamStub, and AGSGalaxy plugins.

EDIT: Done! (This AGS2Client interface is making this process so much easier!)

Btw, you also should never use bool in any function you are registering with RegisterScriptFunction. I learned that the hard way.

[FULL]

The AGSGalaxy plugin: GOG Galaxy stats, achievements, and leaderboards for AGS!

FULL source code is available, as GOG Galaxy API is open-source (er... not strictly licensed? I don't seem to actually find the full source code for the API or client anywhere, but it definitely isn't licensed in a closed-source fashion)!

Download (see this post in deciding which version to download)


Cheers! For an example, please check out the Steam+Galaxy project.

I'm not sure when this issue first started occurring (I have been busy with other things for some time and have been away from AGS), but Avast antivirus is apparently now blocking AGS executables on my system. I'm not sure if this is something only in my local settings, but I wanted to mention it.

Currently it seems Avast is attempting to open the EXE in a sandbox, but for some reason it seems to be failing to do so. I have to manually kill the Avast system service or three separate instances of the executable will hang indefinitely, with no window appearing.

Pooling floats seems very much the worse option in this case. Attempting to keep a unique pool would require using some arbitrary epsilon and a lot of floating-point comparisons. Not keeping a unique pool would require adding an item to the pool every time a float is converted into StackData -- and note that AGS lacks destructors! The pool would never be able to release an item without an explicit function call placed by the user. Memory conservation would not even be guaranteed by pooling the floats, as if the total number of floats converted into StackData exceeded the number of StackData objects currently in existence (despite the lack of destructors, the objects are still destroyed if they go out of scope with no references to them), then there would effectively be a memory leak (memory reserved that is never again referenced by the program, which is never freed until the program terminates). No, I don't think that this is a better solution. Perhaps I could mangle floats and store them in some combination of StackData.Type, StackData._idata, and StackData._scacheID. The question, then, I think, would be whether it's worth conserving 4 bytes of memory (per StackData instance) to have to reconstruct floating-point values... something like:

Code: ags

return (IntToFloat(this._idata) + (IntToFloat(this._scacheID) / 1000000));

Floating-point division every time the value is retrieved? Ugh!

I still just don't think it would be worth reclaiming 4 bytes of memory per StackData object (1 KB per 256 StackData objects). You would have to have well over 200K StackData objects at any given time for that to amount to a single MB of "lost" memory. You could have a million StackData objects and have "lost" less than 4 MB of available RAM. This is hugely insignificant.


As for the suggestion to use the AsString property as a sort of "ToString" conversion method, I actually like the idea. I could easily see reimplementing the "StrictTypes" setting to allow that behavior to be toggled.

Thank you for your feedback. While I don't agree on the float issue, it is appreciated!

If nothing else, the bundle was worth it to me for the games it includes. The fact that you get a PRO license for Game Maker and source code for several of the games is a nice added benefit, even if you don't intend to use GM for releasing games. That said, I don't even like GM but I still bought the bundle.

P.S. If you do buy the bundle, don't expect to be using Game Maker any time soon. You have to go through the Yoyo Games website to get your license key, and their server is extremely overloaded from the response to this Humble Bundle. If you can even manage to register an account and get your HB key put in on their site, don't hold your breath on getting the license or getting the GM software to properly register that license. Their server has completely crashed multiple times since this HB began.

Presumably we would only need the latest stable and development builds for download? Bitbucket.org associates a "Downloads" page with git repos (gives you a place to host the binaries without versioning them).

Have a code for 10 Second Ninja, free to whoever finds and murders those who have been stealing codes without even letting anyone know.

...or, you know, whoever PMs me first to request it. Whichever. I'm flexible.

I hear tale that the leechbots have been eradicated. If not, someone owes me a copy of 10 Second Ninja back!

[P.S.]

As far as the Steam overlay goes, the latest version of the Steam plugin uses the following code (released as part of the open-source stub):

AGSteamMain.cpp:162

Code: cpp

int AGS_EngineOnEvent(int event, int data)
{
    if (event == AGSE_FINALSCREENDRAW)
    {
        // use this as main_game_loop
        // the screen is drawn every actual game loop anyway
        AGSteam::Stub::GetAGSteam()->Update();
    }
    else if (event == AGSE_KEYPRESS)
    {
        typedef int (*IsKeyPressed_t)(int);
        IsKeyPressed_t IsKeyPressed = reinterpret_cast<IsKeyPressed_t>(engine->GetScriptFunctionAddress("IsKeyPressed"));
        bool isShift = ((data == 403) || (data == 404)); // is pressed key shift
        bool isTab = (data == 9); // is pressed key tab
        bool isShiftTab = ((data == 0x00001111) || // shift+tab as a single key
            ((isShift) && (IsKeyPressed(9) != 0)) || // key is shift and tab is held
            ((isTab) && ((IsKeyPressed(403) != 0) || (IsKeyPressed(404) != 0)))); // key is tab and shift is held
        return isShiftTab; // Claim (Shift+Tab), ignore other keys
    }
    return 0;
}

I added this when working on Al Emmo. I don't recall if Chris said this definitely fixed everything, but it attempts to force the engine to ignore the Steam overlay being opened and closed. As I recall, that seemed to be enough to stop AGS from going crazy in the background. If not, then I might consider having the plugin keep track of whether the overlay is open, but I was afraid of that somehow getting out of sync and causing worse problems. Just to be sure, you are using the latest version of the plugin linked in the first post?

P.S. As you obviously are a Steam developer, I could give you access to the full source code of the plugin if needed.

I do know that the most recent versions of Visual Studio Express actually do allow mixed assemblies (e.g., the Native DLL), but I think that requires to use the latest versions of the VC++ compiler as well. It might be worth loading the project into VS 2013 Express (with VS 2008 Express installed) and see if manually selecting the 2008 compiler will allow it (but I wouldn't hold my breath).

In any case, it would be really useful to have the engine's dependencies rebuilt with a newer Visual Studio so that the project files could be updated. I've never been able to successfully figure out how to do that though.

[noloopcheck]

I requested the noloopcheck keyword, possibly in relation to an earlier version of the Stack module or EncryptedFile module (IIRC) because they have to process large amounts of data. I also made use of the keyword in the EasyBake module, where again I was processing huge chunks of data at once.

Outside of exceptional cases of large data processing, the noloopcheck keyword is probably more dangerous than useful, but it is precisely because AGS has a "newbie-friendly" mechanism to catch infinite loops. As for recursive functions, that would overflow the stack long before it would hit the 150k loop limit, so that is also a non-issue. Sorry I don't really have anything more useful to contribute, but I wanted to clarify that the situation ollj is describing simply doesn't exist in AGS.

This is not a totally uncommon or unheard of mistake, though it is interesting to me how often it is a mistake made by those using the more "advanced" script features like custom structs.

Linkage of variables (read as: "struct instances") works exactly* the same here as it does in, say, C/C++ (*different keywords, and variables must be explicitly exported). The idea that a variable may be intended for script-level scope but not intended for project-level scope is not inconceivable. Personally I like the import/export method as it makes it more explicit that you are referring to a variable defined by some other script and/or that you intend this variable to be used by other scripts.

Another difference, I suppose, is that C++ compilers would probably complain about multiple definition if a variable were defined (rather than just declared) in a header file and included in multiple script files... but that could quite easily be disabled in compiler settings and without any use of "extern" I would expect much the same end-result as well (separate copies of "the same" variable).

I'm guessing that isn't anything I did...? Heh, glad to hear you were able to pinpoint it. I was digging through the native code previously and was pretty baffled by that one!