OpenTTD has been removed from Google Play Store!!!

[planetmaker]

First of all: nice that it works. With your explanation here I was able to find a patch to our sources; without certainly not. I still didn't find any license information anywhere.

Let me quote from the amended readme:

How to compile demo application
===============================

Launch commands
rm project/jni/application/src
ln -s ballfield project/jni/application/src
./ChangeAppSettings.sh -a
android update project -p project -t android-15
Then edit file build.sh if needed to add NDK dir to your PATH, then launch it.
It will compile a bunch of libs under project/libs/armeabi,
create Android package file project/bin/MainActivity-debug.apk,
and install it to your device or emulator, if you specify option -i or -r to build.sh.
Then you can test it by launching Ballfield icon from Android applications menu.

There are other applications inside project/jni/application directory,
some of them are referenced using Git submodule mechanism, you may download them using command
git submodule update --init
Some of them may be outdated and won't compile, some contain only patch file and no sources,
so you should check out Git logs before compiling a particular app, and checkout whole repo at that date:
gitk project/jni/application/<directory>

within a readme which starts like

This is SDL 1.2 and 1.3 ported to Google Android (also bunch of other libs included).
Sources or patches of the individual games are in the directory project/jni/application.

That's IMHO quite a strech, if that's called "providing source" or linking source. Anyway, with your explanation here, some source can be found, though not by the letter of the license (a patch is not the source, technically). But how do I know which date I should look at to get the exact source used to build the binary I have?

Disregarding that above:
Looking at the pkg at http://sourceforge.net/projects/libsdl- ... k/download provides the actual package an android users gets, right? And inside the package, I assume the openttd binary is called there /lib/armeabi/libapplication.so. I see no readme, license information or anything whatsoever which indicates to the user what rights he has, who wrote the programme and where s/he can obtain sources.

Further, but a bit on a tangent: I wonder which base graphics (and base sound and base music) you provide to the users by which means. I didn't find any hint... but at least base graphics are essential. How is that handled?

[Zuu]

(I wrote this before seeing planetmakers response, but from a quick review of his post, my post is not a duplicate of his)

What you could do is to besides the link to each game have a link to the source code of that game. When you get to the github page it is not very self explanatory that you have to go into the projects/jnl/application/ folder to find the source code of OpenTTD.

For OpenTTD, I would link to this page:
https://github.com/pelya/commandergeniu ... on/openttd

This way it is much easier to see that there are sources for OpenTTD if you scroll down quickly to look for OpenTTD. Additionally, you don't give up on github because you don't know that you have to go into the 'jnl' folder.


Still, I see two problems:

• Technically a patch is not the complete source code.
• You don't offer sourcecode for each binary version of your port. I'm not a git user, but on the website I couldn't find any tags or commit messages that could be paired to the binary versions that you offer. Thus its non-easy to figure out which patch version to get in order to eg. obtain the sources for version 1.1.2 of your port.

A solution to these two problems is to in addition to building binary packages, also build a source package that you upload as a downloadable file. Another solution (not technically correct, but a large improvement over current situation) is to provide a clear information on how to get the OpenTTD sources for eg. 1.1.2 and how to obtain the patch for that version so that oneself can produce the exact same sources that you used to build 1.1.2.

[pelya]

The patch file contains the revision number of the OpenTTD SVN, also I'm compiling it from the SVN tag for a specific version (so the release named 1.2.2 on Google Play is OpenTTD 1.2.2 release sources plus my patch).
Putting license info inside the .apk file isn't very obvious, many users will probably not even know that the .apk file is a zip archive, so I guess the license should go into the app description.
I can pull out all the sources into the archive at the moment when I'm compiling it, and I can upload it to SF.net in a semi-automated way, no problem, I just don't see much sense in such activities when I'm providing a Git repository. Also I'll need not only to provide OpenTTD sources in that archive, but the complete SDL repo with all the libraries and build scripts, that's a waste of space for something only few people will actually download (I don't care much though, the space isn't mine, it's provided by SF.net, and it's well-known that SF.net servers have rubber self-expanding harddrives)
If you actually want to build the Android release yourself, you'll probably just ask me for instructions by email or at forum.
The data files provided with the game are OpenGFX, OpenSFX and OpenMSX sets (what else could it be, really?)
So, what would you propose? Update readme yet again, or just pull all the sources together into an archive?

[planetmaker]

Ok, first of all on-topic:
Looking at the e-mail you quoted: the take-down request came from a company 31x limited which claims copyright on the game transport tycoon; thus this take down was not initiated by anyone from the (open)ttd community. It might be a legal representative of Chris Sawyer himself as he seems to be or was a director of that company according to a brief web search..

On the package itself:
I like to see an android port, an official one even. Sadly, as far as I know we didn't see anything from you, neither patch, nor communication or anything in that respect though - until this incident. Which obviously makes us look bad though we have so far no business at all in this affair.

The patch file contains the revision number of the OpenTTD SVN, also I'm compiling it from the SVN tag for a specific version (so the release named 1.2.2 on Google Play is OpenTTD 1.2.2 release sources plus my patch).
Putting license info inside the .apk file isn't very obvious, many users will probably not even know that the .apk file is a zip archive, so I guess the license should go into the app description.
I can pull out all the sources into the archive at the moment when I'm compiling it, and I can upload it to SF.net in a semi-automated way, no problem, I just don't see much sense in such activities when I'm providing a Git repository. Also I'll need not only to provide OpenTTD sources in that archive, but the complete SDL repo with all the libraries and build scripts, that's a waste of space for something only few people will actually download (I don't care much though, the space isn't mine, it's provided by SF.net, and it's well-known that SF.net servers have rubber self-expanding harddrives)
If you actually want to build the Android release yourself, you'll probably just ask me for instructions by email or at forum.
The data files provided with the game are OpenGFX, OpenSFX and OpenMSX sets (what else could it be, really?)
So, what would you propose? Update readme yet again, or just pull all the sources together into an archive?

With respect to providing source:
It is good practise to provide a tar ball for each release you make which is sufficient to build the final product. The tar ball usually need not include the libraries (which SDL qualifies as). If custom libraries are needed, they could be released similarely released.

That said, patch with a well-established source it is based on often is accepted instead. But I'd feel much more comfortable with that procedure if I could then go to your git repo and simply checkout a tag called "openttd-1.2.2-19" (or however the actual release pkgk is then called). Checking the contents of a single file over several revisions to find which is applicable is very inconvenient. That way I can only find the latest release at best and would have to bisect your git repo to find the source for a specific other release of yours.

With respect to readme and licenses within the pkg: yes, most users won't see or read it. Still I do believe providing both the readme (amended to show what you changed: port to android with an amendment where your patch is found; best directly link to the openttd dir there as suggested by Zuu) and the gpl license file within the pkg would suit you very well. It will necessarily make sure that every person who receives your binary is in possession of the license and has means to retrieve the source. It's the safe side. I downloaded the pkg from your website and didn't get any such offer. Thus the pkgs as provided there do not fulfill the license. Even when the website itself talks about license (where?) and offers the source, the download pkg doesn't hint anything about the license. So yes, please add the official readme appropriately amended and add the COPYING file.

As far as I see the required changes are relatively minor. Yet I'd like to see a proper unhacked OpenTTD on android. That's feasible, given a tiny bit of effort. I understand that changes to OpenTTD's source are essential to make it work on android. Yet still you hacked the version detection and change certain settings and compiler directives, thus your releases do not actually correspond to the official sources and the displayed version mis-represents the state of the source. This gives the impression that it is an official OpenTTD port - which it clearly isn't (yet?). If proper patches are supplied to us, there very soon would not need be a need for a patched OpenTTD to be able to compile it for android. So I'd like to ask you to either to talk to us so that we can amend sources properly thus that OpenTTD compiles unmodified to obtain the desired version or alternatively to make the releases thus that it's indicated to be a modified version.

[pelya]

Looking at the e-mail you quoted: the take-down request came from a company 31x limited which claims copyright on the game transport tycoon; thus this take down was not initiated by anyone from the (open)ttd community.

What a refreshment, a person who actually bothered to read the original email.

I like to see an android port, an official one even. Sadly, as far as I know we didn't see anything from you, neither patch, nor communication or anything in that respect though - until this incident. Which obviously makes us look bad though we have so far no business at all in this affair.

But I did write to forums! For some unfathomable reason I decided that the official forums are the proper way to contact the devs. I've even opened a bug, it got turned down though.
http://www.tt-forums.net/viewtopic.php? ... 20#p913949
http://bugs.openttd.org/task/4270

But I'd feel much more comfortable with that procedure if I could then go to your git repo and simply checkout a tag called "openttd-1.2.2-19"

Okay, I'll put a tag inside my repository for each release. In fact, I was doing that back then, and Github even automatically generates an archive with a repository snapshot for each tag, which is nice, but then people started to use those archives and complained about bugs in SDL I've already fixed in the repo, so I've stopped using tags.

Still I do believe providing both the readme (amended to show what you changed: port to android with an amendment where your patch is found; best directly link to the openttd dir there as suggested by Zuu) and the gpl license file within the pkg would suit you very well.

Okay, I'll do that.

Even when the website itself talks about license (where?)

The readme file in the repository contains license info at the end, also each library ar application in my repo contains it's own license file. I'll update app description on Google Play, when the ban will be lifted, and I'll add license info to my site.

This gives the impression that it is an official OpenTTD port - which it clearly isn't

I'll also put that to the app description.

If proper patches are supplied to us, there very soon would not need be a need for a patched OpenTTD to be able to compile it for android.

I've put #ifdefs around all Android-specific changes inside my patch, except for the file misc_settings.ini, because .ini format does not support #ifdefs (does it?). So it might be applied to the official repo right away, I guess.

[planetmaker]

I like to see an android port, an official one even. Sadly, as far as I know we didn't see anything from you, neither patch, nor communication or anything in that respect though - until this incident. Which obviously makes us look bad though we have so far no business at all in this affair.

But I did write to forums! For some unfathomable reason I decided that the official forums are the proper way to contact the devs. I've even opened a bug, it got turned down though.
http://www.tt-forums.net/viewtopic.php? ... 20#p913949
http://bugs.openttd.org/task/4270

Please accept my appologies. I was not (anymore?) aware of that.

Yet, the flyspray task does not provide any patch(es) which address the single issues (we like atomic commits) but only one big patch which contains whitespace changes, breaks version detection unconditionally and doesn't obey our coding style (comments!). But let's discuss that below in a bit more detail:

Generally, I think we need to split this into a series of patches:
a) base patch which ensures compilation without addressing any UI changes or improvements.
b) check for required libs
c) UI changes, each as separate patch.

Quickly going through your patch:

But I'd feel much more comfortable with that procedure if I could then go to your git repo and simply checkout a tag called "openttd-1.2.2-19"

Okay, I'll put a tag inside my repository for each release. In fact, I was doing that back then, and Github even automatically generates an archive with a repository snapshot for each tag, which is nice, but then people started to use those archives and complained about bugs in SDL I've already fixed in the repo, so I've stopped using tags.

If you need a special SDL library (version), a check for the required version within the configure script or makefile should do the trick here.

I've put #ifdefs around all Android-specific changes inside my patch, except for the file misc_settings.ini, because .ini format does not support #ifdefs (does it?). So it might be applied to the official repo right away, I guess.

[/quote]
Yes, using #ifdefs for the platform-specific stuff is the way to go. I haven't looked at that code recently, but iirc htink you're right there Still, that means that another solution need be found unless there's good reason to change the defaults for every single platform.

Let's talk settings:
screen resolution:
different devices feature different resolutions, also on android. why change default?
change font defaults:
OpenGFX comes with built-in sprite fonts. Why not use those? Do 2px make this huge difference?

Lines 92-106 looks like the wrong place and way to address scrolling behaviour.

Whitespace:
Lines 42-62 are non-op changes and should be left out.
Lines 180-200 are pointless out-commented code lines

Other:
Why is threaded drawing disabled (lines 211-225)
I'm sure MIN(X,Y) is defined somewhere. Make use of that instead of re-definition (Line 253)
Adding OpenGFX+BigGUI is unfortunate and not nice. It would already be improved, if done so as static NewGRF. A zoom-able UI is the proper way (Lines 375-395). See also here.
Breaking version check (Lines 409-420) is inacceptable. But not needed when everything is properly patched in the official sources.

[pelya]

I've put tags to the SDL repo, and put license info to my site.

Screen resolution

It's fine if it's 640x480, SDL will stretch that to whatever physical resolution you have, although setting 800x480 is better, because most devices are wide-screen. Setting that to native device resolution results in the awfully small text on modern devices with HDPI displays, and Android users do not bother to change game settings - they rate 1 star and uninstall (and editing .cfg file is totally beyond their skills).

OpenGFX comes with built-in sprite fonts

They do not provide a native language support. Those .ttf files at least provide cyrillic support, and umlauts for most European language. Also, most complaints I've got were about fonts that are hard to read, so with 2px increase I'm being conservative.

Why is threaded drawing disabled (lines 211-225)

Because it does not work this way with Android port - calls to SDL_Flip() should be done from the main thread (and to SDL_WaitEvent() too). I can enable software videobuffer compatibility mode inside SDL, but then FPS will become much lower.

Adding OpenGFX+BigGUI is unfortunate and not nice. It would already be improved, if done so as static NewGRF. A zoom-able UI is the proper way (Lines 375-395)

Well okay, but I have no idea how to enable zoomable UI inside OpenTTD code, or how to add static NewGRF.

I'll fix other inconsistencies in my patch, when I'll have slightly more free time.

[Eddi]

maybe instead of hacking new default values into the code, you could make an "installer" that puts a modified .cfg? then you could put fonts and static grfs into this "template .cfg", and openttd will fill out the rest of the values on first run.

[pelya]

maybe instead of hacking new default values into the code, you could make an "installer" that puts a modified .cfg? then you could put fonts and static grfs into this "template .cfg", and openttd will fill out the rest of the values on first run.

Actually, SDL can do that with ease, I'll follow your suggestion.

[pelya]

There was a development regarding the Play Store takedown - basically, they've forwarded my counter-request to the party which requested the take-down, if they won't answer in 2 weeks the Google will lift the ban:

The Google Team removals@google.com

8:36 AM (7 hours ago)

to me
Hi,

We have received your DMCA counter notification dated October 3, 2012. As
described in 17 U.S.C. 512(g), we will forward the counter notification to
the complainant. If we do not receive notice that the complainant has
brought a court action within 10 to 14 days, we will reinstate the
material in question. We appreciate your patience in this process.


Regards,
The Google Team

[ahlis]

There was a development regarding the Play Store takedown - basically, they've forwarded my counter-request to the party which requested the take-down, if they won't answer in 2 weeks the Google will lift the ban:

The Google Team removals@google.com

8:36 AM (7 hours ago)

to me
Hi,

We have received your DMCA counter notification dated October 3, 2012. As
described in 17 U.S.C. 512(g), we will forward the counter notification to
the complainant. If we do not receive notice that the complainant has
brought a court action within 10 to 14 days, we will reinstate the
material in question. We appreciate your patience in this process.


Regards,
The Google Team

Fingers crossed

[pelya]

I've cleaned up my patch, and moved most of my hacky changes into .cfg file, which is getting installed automatically along with the app: http://bugs.openttd.org/task/5330
Also, I've added a minimal support for Android native screen keyboard in the text edit fields, the build is here, if you're interested: https://sourceforge.net/projects/libsdl ... k/OpenTTD/
I'll upload it to Google Play when they'll lift the ban, so you'll get an update automatically.
Now the Android OpenTTD build is so much more official and GPL-compliant, as it was never before

[kamnet]

Interesting. The person who filed the original complaint has to respond by showing that they've taken court action?

[Supercheese]

Interesting. The person who filed the original complaint has to respond by showing that they've taken court action?

Don't attempt to apply logic to legal topics, it will quickly lead to headaches and high blood pressure.

[Dave]

Suppose we'll find out now if CS has got a problem with this.

Didn't he sanction a release of TTD on Android not long back though? Maybe that's the company's problem.

If so - they will get laughed out of court if they do bring anything haha. There's nothing here that breaks copyright law.

And that's subjective... Surely?

[Hyronymus]

His company surely is alive still. Thanks to a UK law on public availabilty of account files I found this:
https://www.duedil.com/company/SC374055 ... financials

Also interesting is an overview of the shareholders:
https://www.duedil.com/company/SC374055/31x-ltd/people (more on Marjacq: http://www.marjacq.com/team)

[Eddi]

the site seems to be down for maintenance.

however, what i find more interesting is that at the last contact with CS about the copyrights, the answer was that he doesn't have the rights because they all went to microprose (and likely went to atari from there).

[Zephyris]

I'll upload it to Google Play when they'll lift the ban, so you'll get an update automatically.
Now the Android OpenTTD build is so much more official and GPL-compliant, as it was never before

Thanks for doing this, I would be a huge fan of clean trunk OpenTTD on Android and it is great to see you making steps towards this.

[Dave]

A bit more playable as well please?

[Yexo]

A bit more playable as well please?

Working on it.