Messages

Cassie, this is what I was referring to in the last paragraph of my previous post. Probably looming through the history of the Android folder on Github will turn up what I removed, but I don't have time to investigate that right now.

I'd like to claim it, but honestly I feel like I take advantage of this thread too much. I'll leave it for someone else!

[2]

EDIT2: I haven't yet learnt everything about how Build targets work, but I have the impression that some things there are unnecessarily complicated, such as composing output paths. I believe that build target should not need to define which path to build output in, but rather receive one from caller.

The idea behind this was that the caller shouldn't have to know anything about the build target in order to build it. Perhaps that was contrived or misguided, but my primary concern really was getting everything to work properly by that stage.

2. Important changes to acsetup.cfg are not copied to final build folders.

The original rationale behind this was that the developer may wish to have separate configuration options based on the platform, so overwriting the platform configuration was intentionally avoided. Perhaps important changes (resolution, color depth) could be persisted without overwriting the entire config file?

That's the general idea, yes. I don't foresee any need to have the Steam plugin pushed out over GOG Galaxy, for example, so there's a good chance that most of the function calls could be set up in a synonymous way.

The source code for the various client plugins can reference this interface to reduce code duplication. Some minimal defaults are already in-place, so things like registering the script header and the various functions can largely be handled by the AGS2Client interface. New (common) features (if any) could also be implemented at the interface level, and perpetuated to the client plugins by updating the git submodule (as opposed to having to recreate the changes for each plugin).

This probably won't be widely useful to most people. But in theory it allows me to maintain both plugins in a user-friendly and open-source way while supporting closed-source frameworks like Steamworks with relatively little unseen/private code. This also is an effort to make sure that the client plugins may be properly stubbed for platforms that the client doesn't yet support.

[https://github.com/monkey0506/ags2client_demo]

This may be fairly mundane, but I have created a common interface for client plugins that AGS can use to communicate with clients like Steam and GOG Galaxy. In fact, those are the only two clients I know of presently that offer the whole game-library-with-achievements-and-so-forth type of "client", but it's always possible that others will rise up.

In related news, this does mean that I am working on a GOG Galaxy plugin! Hopefully that should be made available soon. As far as I know, the GOG Galaxy SDK is open source, so that plugin will also be fully open-sourced, unlike AGSteam. The official stub source code for AGSteam will later be updated to this much improved interface as well.

I created a demo project to show how this interface can be used to stub these client plugins rather simply. You can grab the source for that at the link below (the interface itself is a referenced submodule in a separate repo):

https://github.com/monkey0506/ags2client_demo

P.S. Additionally, this common interface should make it relatively simple for AGS devs to implement Steam and Galaxy features in a uniform fashion. That seems like it would be appreciated.

P.S.S. The Visual Studio solution files I provided for the demo are VS 2013 solution files, and the interface does make use of C++11 features. The demo was tested with AGS 3.4.0.5 and gave me no issues.

I think the Custom Dialog GUI module can pretty much accomplish what you're looking to do. I haven't actually used it though, so you may want to read through that module's thread for more info on setup and use.

When I import the GameList project I have a number of errors with the files in the 'src' and 'gen' directory which stops the project from building.

Make sure that you are also importing the engine and marking it as a library for the GameList project -- they are two separate projects, the latter depending on the engine to build and run.

I spoke to a coder friend who has a lot of experience with working with cross-platform stuff and had said the game would need to be packed into an obb file being over 50mb. You would then need to write a good bit of Java to get the current version of the AGS Android engine to bypass the start-up game list menu screen, set various graphical options and screen orientation and unpack the game from the .obb.

Yes and no on this. To release on the Google Play store the APK itself cannot exceed 50 MB, which is when you would need to pack your game into an OBB file. The Android SDK has a tool for this, but the last time I was looking into this (quite some time ago, actually) the tool was badly bugged and could not pack more than 512 MB into a single OBB file (the particular formatting used in these OBB files should allow at least 2 GB). I wrote a simple fix for it, and I was able to publish standalone APKs with game data packaged in OBB files over the Play store, but none were ever released because there were game-stopping silent crashes in all tests conducted by anyone other than myself.

Regarding reading the OBB file, there's no need to "unpack" it, as it can be mounted as a read-only disk directly, and the engine can be set up quite simply to divert write operations to the appropriate data directory. It's really quite simple to set this part up. I had more difficulty trying to design a decent UI for the downloader in case the OBB file had been corrupted or deleted yet the APK still installed (the code was simple enough, I'm just not a visual design type of person).


I do also realize that I inadvertently changed some code that removed the on-screen menu from the engine, but I have not had time to look into this. This alongside the silent crash issue (reported by Himalaya Studios) were the major issues that prevented many titles being published on the Play store. After the summer I may have more time to look into this again, but right now I am sorely lacking in free time to spend on this.

[Edit:]

The Linux engines seem to be out of date in this version (3.4.0.5). Were they rebuilt for this release? If they are going to be included then they will need rebuilding for each release. Should we perhaps maintain their release separately?


Edit: I didn't create the archive for this purpose (actually, I'm having some issues with my VM talking to the host), but here are the latest 3.4.0.* Linux binaries (versioned as 3.4.0.5, but includes updates since that release). This also includes the AGSteam binaries, which of course aren't necessary, but like I said I needed this for something else. This archive can be extracted directly on top of "Editor/Linux" to update the Linux binaries used by the new compiler.

As an additional tip, functions that support string formatting directly always end with "..." as the last parameter:

AbortGame(const string, ...)
Display(const string, ...)
String.Format(const string, ...)

There may be others (don't recall ATM) but these are common examples. If the last parameter isn't "..." then you can just call String.Format in place of the string parameter you want to format.

I replied to your PMs about this, but to be clear, the steam_api.dll is the compiled DLL for the Steamworks API. Unless you're using Steamworks features (such as stats, achievements, leaderboards, etc.) then you shouldn't need to worry about steam_api.dll at all. By way of reference, some of Wadjet Eye Games' early games on Steam (prior to development of the AGSteam plugin) didn't include steam_api.dll at all. It simply wasn't necessary because they weren't using any of those features.

The latest alpha versions have (experimental) support for targeting Linux directly, but no other build targets currently exist. Android would be fairly simple in terms of just packaging the data file, but to build a full APK would take a lot more work to streamline into a single build process.

As for running the game in a browser, there's currently no way of doing that AFAIK (in particular, the AGS engine runs on native C++ code, and I'm not aware of any simple way of converting that to a web-friendly format).

Speaking of the Humble Borderlands Bundle, I got a 25% off coupon for merchandise from the 2K store, but I'm not really interested in anything they have for sale. Not exactly a Steam key, but PM me if you want the coupon code.

[The Dream Machine: Chapters 1-3]

The Dream Machine: Chapters 1-3

Please post if you claim. Please. Puh-leeez.

Very well, if you insist. Thanks.

Frankly I am worried about Magnifier recreating dynamic sprite at every update rep-exec call. Unless I am mistaken. I think it could be optimized to remember last sprite and not redraw if it did not change.

Possibly, but that would assume that nothing on the screen had changed, which isn't something the module can really make such a strong guarantee about. Also, I'm not sure that it would affect this usage anyway.

I wrote the Magnifier module some time ago (and am short on time at the moment), but if you try to read back the Magnifier.Sprite, maybe displaying it with a Display command each time it changes, is it being properly updated in the structure? Do you see the initial sprite, or any of the frames?

[P.S.]

"members table", you say?



P.S. Tested. Exact same behavior as before.

• Go to wiki (shows not logged in).
  
• Click login, brings to forum login.
  
• Enter details, log in. Returns to forum home page.
  
• Go to wiki (total failure to load, same error as above).
  
  Is literally no one else experiencing this?

Color me skeptical ('twas just a baseless suggestion), but if others aren't having the same issue then by all means please give it a try.

[P.S.]

I've noticed that the wiki login has never been fixed...

Clicking "login" from the wiki brings me to an SMF login page for the forums (which I was already logged into). Logging in brings me back to the forum homepage. Going back to the wiki produces the following error:

MediaWiki internal error.

Original exception: exception 'MWException' with message 'SkinTemplate::makeTalkUrlDetails given invalid pagename User:' in /var/www/ags/w/includes/SkinTemplate.php:721
Stack trace:
#0 /var/www/ags/w/includes/SkinTemplate.php(648): SkinTemplate->makeTalkUrlDetails('User:')
#1 /var/www/ags/w/includes/SkinTemplate.php(448): SkinTemplate->buildPersonalUrls()
#2 /var/www/ags/w/includes/OutputPage.php(1989): SkinTemplate->outputPage()
#3 /var/www/ags/w/includes/Wiki.php(543): OutputPage->output()
#4 /var/www/ags/w/includes/Wiki.php(446): MediaWiki->main()
#5 /var/www/ags/w/index.php(59): MediaWiki->run()
#6 {main}

Exception caught inside exception handler: exception 'MWException' with message 'SkinTemplate::makeTalkUrlDetails given invalid pagename User:' in /var/www/ags/w/includes/SkinTemplate.php:721
Stack trace:
#0 /var/www/ags/w/includes/SkinTemplate.php(648): SkinTemplate->makeTalkUrlDetails('User:')
#1 /var/www/ags/w/includes/SkinTemplate.php(448): SkinTemplate->buildPersonalUrls()
#2 /var/www/ags/w/includes/OutputPage.php(1989): SkinTemplate->outputPage()
#3 /var/www/ags/w/includes/Exception.php(227): OutputPage->output()
#4 /var/www/ags/w/includes/Exception.php(272): MWException->reportHTML()
#5 /var/www/ags/w/includes/Exception.php(620): MWException->report()
#6 /var/www/ags/w/includes/Exception.php(690): MWExceptionHandler::report(Object(MWException))
#7 /var/www/ags/w/includes/Wiki.php(449): MWExceptionHandler::handle(Object(MWException))
#8 /var/www/ags/w/index.php(59): MediaWiki->run()
#9 {main}

P.S. Just looking at the error message, it might be related to my username having underscores in it?

The CFG is a plain-text INI-formatted file. Just simply create a Windows application in C#, Java, etc. and utilize an existing INI library to read/write the keys/values. It's actually very simple to do. You could even create such a thing in AGS using RickJ's INI module, but that would be rather silly and frustrating as the setup "game" would share the config file with the actual game.

A typical CFG file looks something like this:

Code: ini

[sound]
digiid=-1
midiid=-1
digiwin=1096302880
midiwin=-1
digiindx=0
midiindx=0
digiwinindx=0
midiwinindx=0
threaded=1
[misc]
gamecolordepth=32
screenres=1
defaultgfxdriver=D3D9
gfxdriver=D3D9
titletext=Project Setup
windowed=0
antialias=1
refresh=0
gfxfilter=None
game_width=1024
game_height=768
[language]
translation=English
[graphics]
driver=D3D9

Most things are pretty much self-explanatory. You can toy around with the winsetup if you're not sure what something does or if it seems to not be working. You can also reference the source code (but, of course, that's written in C++...). At some point, someone should probably create a wiki entry for all of the config options. Shouldn't take long to document.... hmmm...

It was definitely using the new compiler. Project was imported from 3.3.3 and worked fine initially. I'm actually curious if the files became corrupted when the computer restarted (automatically) for Windows Updates. I may have left the project open for several days...

I'd have to talk to m0ds to see if he's okay with me sending you files (as this isn't my game). As I said, I preserved the bad CRM files, so perhaps I can create a new project with 1 or 2 of these bad rooms. I'll let you know what he says. I hadn't modified any of the rooms except to edit their script files, so in the end I extracted the old CRM files back on top of the project and rebuilt, seemingly fixing everything.

I attempted to upgrade The Apotheosis Project to 3.4.0.4 to see how well it would work out. Initial builds seemed fine, but as room scripts were modified, somehow the room file version was changed. The editor could still read all of the CRM files just fine, but the engine crashed immediately, denoting a "bad packed file". The only place this seems to happen is if the room file version has a mismatch, but I haven't yet been able to pull out what file version is being reported. Still have the bad CRM files, but I'm attempting to revert to AGS 3.3.3 for now.