Messages

Maybe extending the script functions (if that is even necessary) and generally implementing the setup as an AGS game would be a good idea. The problem I see with having a dedicated windowed application is that it either requires a different GUI framework for different platforms or you have to add huge library dependencies. Having the setup run inside the engine would make it instantly cross-platform (ScummVM works like this) and configurable by the average AGS developer (no need to compile anything).

If the engine in setup mode starts with sane defaults (windowed, software rendering, 640x480, 32 bit game, sound disabled maybe) it should work as well as the current winsetup.

It tells the xml parser to ignore everything inside the CDATA field, so that it doesn't get interpreted as xml: http://www.w3schools.com/xml/xml_cdata.asp . Exlamation mark and double brackets are just how it is written.

Yes, that is the problem. I ususally build on Windows or through a virtual machine connected to a Windows share so I don't notice usually .

Having both AGSLua.h and agslua.h (i.e. copying the file) should be the easiest fix for now. This has to be really fixed in the agslua repo.

The agslua plugin is pulled in from its original repository as a submodule, which has to be initialized separately.

On the command line this is done like this:

Code: shell

git submodule init
git submodule update

I uploaded a build of the develop branch here: http://jjs.at/daily/branches/develop/AGS_for_PSP_2013-04-14_18-16-58.zip

Joseph DiPerla provided two intermediate builds in this post: http://www.adventuregamestudio.co.uk/forums/index.php?topic=44768.msg636449832#msg636449832 You could also try those.

The newest version is compiled with the latest NDK and GCC 4.7. The previous ones were with older toolchains, I hope this didn't break anything (it didn't for me, but you never know).

Also can you provide system logs (logcat) that show the engine crashing?


Edit: About Ouya... I guess it is all about supporting the controller and providing meta information for their store. Since their launcher app doesn't really work on my phone (screen too small and I cannot manage to sign up) and the launcher also doesn't work on the emulator because it requires a "real" network connection (emulator only has 3g network) I will not do any work on it for the moment. The overarching problem of deploying for Android has not been solved anyway so Ouya support is not that useful right now.

You are running the game by just typing "acwin" instead of "acwin.exe", right? This is a way in which I can reproduce the GetShortPathNameW message.

Just realized that I won an award! Thank you very much!

I could not be at the ceremony in the beginning and later had connection troubles unfortunately, maybe next year I will make it.

It is very much possible to build Allegro with VS2012 (I did that previously). It has to be patched anyway (for __old_pack_fopen) so builds from the Allegro site are not usable. But I only tried linking the result to the engine, not to the native editor part. I generally don't know why the engine links against different libraries than the editor (fake edit: now that I look at the files shipping with the editor I guess the editor components link against the dynamic VC runtime while the engine is statically linked).

I also don't know if there is a good reason why the Allegro library is version 4.2.2. It might actually be beneficial to update that to 4.4 along with new version of Vorbis, Ogg and Theora. Of course the issue of updating the libraries is completely independent of building with VS2012, it can as well be done with VS2008.

Any comments from other linux users on this patch?

It's pretty awesome I'd say. Mode switching for fullscreen now works on my Linux Mint and unsupported graphic modes properly return failure.

The only downside I could see is that running AGS without X will now always fail I guess. But since a) nobody does that and b) the Allegro 4.4 Debian package does not contain the framebuffer driver anyway, it doesn't really matter.

I'll upload my save game soon.

EDIT: Here you are! Note that you'll have to go to the fourth floor and talk to the boss first then it will automatically bring you to the room where the problem is happening.

This should be fixed in the newest daily build. Because wrong values were previously stored in the save game you have to use my patched save from here: http://jjs.at/temp/pb_agssave.zip . It is at the same position as the save you uploaded. Loading from any other previous savegame would still cause the error, starting a new game works fine.

The libraries build just fine with the latest NDK (8d). I don't understand the problems with compiling because for me it is very simple. Download the NDK zip file and extract it somewhere. Then either add the ndk directory to the PATH environment variable or don't (works either way if you don't mind typing the full path to ndk-build). To build the libaries, open a command prompt, change into the source directoy "Android/library/" and type "ndk-build" or "c:\path\to\ndk\ndk-build". That's it.

But I just realised that the libraries are included in the APK file in my daily builds too. You can get them by adding a ".zip" extension to the APK and opening it. Then copy the folders in the "lib/" folder (that is armeabi-x, mips, x86) into "Android/library/libs/".

BTW, JJS, will there be any change to plugin stubs registration?

I pushed the change. Stubs are now only registered if the game tries to load the plugin and neither the plugin can be loaded nor a built-in plugin is found.

That warning is because the second parameter is implicitly cast to void* for every call to ccAddExternalFunctionForPlugin(). Generally it is a good idea to reduce the warning count and especially to get the source to compile without compatibility settings (e.g. -fpermissive). In this case it is easy and harmless, some others might be more subtle and indicate an underlying bug. So just explicitly casting everything (which would silence a lot the warnings) is not helpful in the long run.

I think I know why there is no rain. The engine contains stubs for plugin functions. The snow/rain module uses the same functions as the plugin I think. Probably the stubs override the modules functions.

The code that registers the stubs should be made conditional on whether the plugin is actually loaded. I never got around to do that :/

Check this: https://github.com/adventuregamestudio/ags/blob/master/Engine/plugin/global_plugin.cpp#L419
Commenting out all calls that register snowrain functions should do the trick for now.

Yes and fullscreen is the default.

but i still can't have my build running without errors, i don't think it's a matter of having the apple license at all...or i'm wrong?

What error do you have now? Is your installation of xcode properly patched to produce unsigned binaries? You might have to change or remove the post build event that is run after the build has finished. It is written for xcode 3.x because that is what I use.

Edit: Actually there were files missing from the xcode project, so that is probably the issue. I fixed that, sorry for the trouble.

Also I am now uploading IPA files of the engine to the daily build location http://jjs.at/daily/ . They will be updated more regularly than the Cydia repo.

That utility cannot directly chop off the engine though. It can only extract everything and then pack it again. It should be trivial to make a script that removes the exe directly (if you don't suck at scripts like me). It is certainly no problem with a hex editor. The engine exe ends with "PADDINGXXPADDING", the data starts with "CLIB". Cut must be made in between. Also the end of the file contains the offset to the CLIB start iirc. Edit: Yeah, it is the 4 bytes directly before CLIB at the end of the file.

I just tried the beta upload with the original Linux engine and a modified one that always returns "Windows".

Original: Neither rain sound effect nor rain.
Fake version: Rain sound effect but no rain.

1. How often (when, in which cases) should the version change?

Till now the engine version was increased every time there was a "significant" change. The bigger the change, the higher the version jump. This sounds reasonable to me because there is no fixed release schedule that could dictate a version number.
For the current development version 3.3 would be suitable I think.

2. Should the engine and editor versions strictly correspond? For example, if we change something in the engine, but nothing in editor, should we still increase editor's version? What about opposite situation (some editor features reworked, but engine stays the same)?

In my opinion: yes to both. This avoids confusion and is also how things were handled in the past. It could be specified that the "build" number (the last four digits) of the version don't have to match since increasing that should be more of a small bugfix thing than a feature change.

Concerning savegames. As I said, there's version string written to them, and if it does not strictly match current engine's, engine refuses to restore the game. I was thinking that in our case we have a hugely modified new version of an engine, but with no differences to data formats and the ways to interpret loaded data. If we increase the engine version, however, the savegames made by new engine will become incompatible with original games made on vanilla 3.2. This is illogical, since technically savegame format, and saved data is totally the same. That's why my suggestion is to write not the current engine version string, but "earliest backwards-compatible" version string to the save games, so that, in case of any need, earlier versions of the engine could restore saves made by newer engine builds.

I agree with this.


Also: For a release based on the current sources the game and room file version should stay the same as 3.2.1.