Messages

Code: ags

if  (Button74.Animate(17, 1, 4, eRepeat))

Button.Animate does not return a value, it is the command to start the button animating. So, obviously, this won't work.

As you pointed out, there's not any type of Button.Animating property to let you know if the button is currently animating. The best option presently is just to create a separate bool variable to track it yourself. When you call Button.Animate, set the bool to true. When you stop the animation (e.g., change the NormalGraphic), set the bool to false. Then you can check if the button is animating by checking your variable.

[Download]

This is something that's been needed for a while now, and though it took a fair amount of ground-work, the process for building for Linux is actually quite simple.

You can select the target platform(s) under the General Settings pane (currently only Windows and Linux, "DataFile" option cannot be turned off).

NOTE: If your project uses any plugins, the editor will search EDITOR/linux/lib32 and EDITOR/linux/lib64 for the appropriate shared library file. This always matches the pattern "lib" + plugin_name + ".so". The appropriate variant for "agsteam.dll" is "libagsteam.so". If a required plugin is not found you will be prompted whether you wish to continue with Linux compilation.

NOTE: Currently the Linux folder is not emptied by the editor, so your files may get out of date if you choose not to build for Linux.

Download
Source

Edit: 2 November 2014, I have now uploaded a full build of the AGS Editor (including latest commits from develop-3.4.0 branch, this is post-3.4.0.1 but pre-3.4.0.2) with the option of building for Linux. The editor now builds the game data files separately from the Windows EXE, so this is also the first version to not rely on publishing the Windows EXE for Linux versions. NOTE: The ags32 Linux engine currently included in this build is NOT up-to-date (I believe it is from an earlier 3.3.1 build). I will make sure that updated Linux engine files for both 32- and 64-bit are included in future versions. Also note that the Windows compiled files are now placed in Compiled/Windows.

Edit: (3 May 2014) I uploaded a new version which places the Linux files into a subdirectory of the editor directory. This also includes a bugfix -- the original version was producing Linux scripts with Windows-style line endings, which has been corrected.

HandsFree, I'm reasonably certain that running with the debugger has deleted the executable from the Compiled folder since 3.0 was first introduced.

Right mouse click not opening inventory: Check your scripts for on_mouse_click, and let's see what you have.

Player character not showing up in the room: You probably set ShowPlayerCharacter to false for that room. Check your room's properties.

[latest]

It appears that CW's latest patch fixed the most recently introduced bug (incorrect graphics filters). The latest APK is available here.

Regarding creating a newer build: I looked at Github to build a newer APK but the source files (at least the important ones) do not seem to be updated since the December 2013 build. I am not a great Android developer (or software developer for that matter), but judging by the files it is not that easy to combine the newer ags builds with the Android libraries, effectively just rebuilding the file linked above. So as far as I know there is no point in rebuilding the above.

The files in the Android folder are the Java-specific library and the launcher app. The actual engine itself is still built against the native C++ source (using the NDK), so these changes wouldn't be reflected in the Android folder.

CW has been working with me to try and get rid of the most recent fatal error, which was caused due to some incorrect code on Android which doesn't support graphics filters. I haven't had a chance to test it just yet, but CW posted a patch here. I will do a full rebuild later today to confirm if this patch resolves the issue. If so, I will upload the APK.

[dozens]

Or do you do the whole Salt Hash thing, downloader service packaging, etc...? The compiling the downloader service is what is giving most of the trouble.

Yes, that. I recall I had a bit of trouble getting everything working quite as I wanted it to (which is great since I've lost that source in a HDD crash), but for the most part I just followed the documentation on Google's API sites.

If you're interested in the reported cases of crashing I'm referring to, send a message over to Chris at Himalaya Studios and inquire as to why Al Emmo hasn't been released to the Play Store yet. Because honestly both of us would have loved to seen that squared away months ago.

I remember one case that had mentioned this, maybe two. I didn't realize it was so widespread which really is a little concerning and I would love to know, just out of curiosity, if the same thing is happening on the iphone builds. Anyone have any reports on that?

Okay, so "dozens" might be a bit of an embellishment, but it was more than just a few sporadic cases. It was enough to deter the release of Al Emmo on Android (Chris himself was one of those reporting it). I haven't heard of any issues with the iPhone, which I assume would be the case if there were similar problems -- seeing as Gemini Rue has been available for iOS for quite some time.

I'm trying to get a working build of the latest master branch (as I'm aware you're also doing) to see if improvements that have been made in the past several months have had any impact. The current master's auto filter selection code isn't working on Android (at all) though, so I'm narrowing that down to a specific point where it stopped being able to load games.

As to the root cause, I'm skeptical of the multithreaded audio, but haven't been able to confirm or deny. If you check the issue tracker, there's some reports by rofl0r about some major issues in that code anyway.

[Edit:]

That APK refuses to install on my Galaxy Tab 3 (and yes, I have Unknown Sources checked). Could you upload a signed APK?

Edit: Actually, I was able to confirm that the latest master is fatally bugged for Android anyway. [Android: Failed to find acceptable graphics filter (Undefined) #151]

I'm looking into it.

[the engine] is silently and randomly crashing...it's been reported by dozens of people.

[The Android port of the engine is bugged.]

No, there's not any reason. And I never said that you have to show the launcher screen. You don't. The Android port of the engine is bugged.

An OBB file is an Opaque Binary Blob file which can be whatever type of file you want it to be.

As a case in point, I have published a beta build of a standalone app that uses an OBB file for the game, and it works just as well as using the launcher app. The problem is that the engine itself is bugged. I've tried quite ferociously to track down the offending code, but debugging an issue which has never manifested on any device I've tested has proven to be practically impossible.

If you're interested in the reported cases of crashing I'm referring to, send a message over to Chris at Himalaya Studios and inquire as to why Al Emmo hasn't been released to the Play Store yet. Because honestly both of us would have loved to seen that squared away months ago.

[dozens]

Commercial releases aren't going to be viable until someone can determine why it is silently and randomly crashing. I have personally been unable to replicate this on any of my Android devices, but it's been reported by dozens of people.

Using OBB files (despite your weird complaints) is a total non-issue. It's perfectly easy to use them (assuming the total game size doesn't exceed 2 GB).

The Android packaging and expansion programming is the issue.

It really isn't.

The issue is that the Android port doesn't work.

The shell script was the one provided with the AGS source by BigMC I think, but not by me. I modified it to symlink the appropriate AGSteam plugin just-in-time, but I don't see why there would be any issues with you using it. Dump an AGS game in the data folder and you should be good to go on any Debian 7 compatible platform (Ubuntu, Linux Mint, etc.), unless they use plugins which will have to be either recompiled or a stub created for them.

AGS doesn't directly have a way to add new members to the existing structs, but you can add new methods. So while you can't add a Character.health member, you could add Character.GetHealth and Character.SetHealth:

Code: ags

struct CharStats
{
  int Health;
};

CharStats CharStat[100];

int GetHealth(this Character*)
{
  return CharStat[this.ID].Health;
}

void SetHealth(this Character*, int health)
{
  CharStat[this.ID].Health = health;
}

Usage:

Code: ags

cNorman.SetHealth(50);
cGuy.SetHealth(cGuy.GetHealth() - 20);

[amazing]

Well the great thing about the question is that it's not contractually binding. It says, "would you" but it doesn't provide any circumstances. You're free to fill in the blanks.

That being said, it would be amazing if someone went and contributed to one of Square Enix Collective's testing campaigns. That would be a sure sign of success for whatever the hell The Collective is meant to be for... (Something about they'll provide non-financial support? Huh?)

Happy Birthday monkey_05_06 !

Oh hey, thanks for noticing. It was a pretty quiet day, but I ended it with several delicious cups of hot cocoa, and everything was good. Hard to believe that was a week ago already!

[player]

I suppose i will have to put the code in every room then

Since player.PreviousRoom returns -1 for the first room the player enters, you can just use on_event for this.

Code: ags

// GlobalScript.asc

function on_event(EventType event, int data)
{
  if (event == eEventEnterRoomBeforeFadein)
  {
    if (player.PreviousRoom == -1)
    {
      // player entering the very first room upon loading the game
      // do stuff here
    }
  }
}

No. Nothing has changed. Exact same behavior. Multiple days. Multiple attempts clearing everything. Multiple systems. It's not a localized issue.

I don't want to keep pushing out updates for users that don't need it, so I've uploaded to a beta branch for testing. It shouldn't break save games, so as long as this resolves the issues then I'll push it out to the main branch. Please tell anyone experiencing issues to 1) Send you the "CrashInfo.dmp" file if they can, and 2) Opt-in to the "Bug-fix" beta.

To get the CrashInfo file they can right-click on The Cat Lady and choose "Properties", then "Local files" and "Browse local files".

To opt-in to the beta branch, they can choose "Betas" from the Properties pane and it should show up in the drop-down list. There's no password.