Very nice. Knightly++ for implementing this. Now I just have to wait for the next official release (I know there are the nightly builds, but given that I maintain packages for Debian I feel I should use them as well ).
when selecting a station and selecting "Details", there is a list of lines that stop at this station. As I often also have vehicles active that are not ****igned to a line, it would be helpful to have them in a list as well. Could there be a list of vehicles that stop at a station as well? It should only include those vehicles that are not ****igned to a line.
The problem is, that some parts of simutrans are not free, like pak128 set. Furthermore the Artistic Licence forbids charging for the package itself or redistribution.
What about this change to copyright.txt? I think even those wanting to misinterpret things should have a hard time doing so and it mentions explicitly that pak sets may have their own licence:
The source code from the program is available under the Artistic Licence. +This is a written permission as demanded for above for every right granted +by the Artistic License. Note, however, that individual pak sets may come +with their own license. + Download the source from https://sourceforge.net/projects/simutrans or find out about our svn in the forum.
Here is also a patch for the other change to licence.txt I suggested (mentioning the new files in the skins.src/ directory):
--- a/simutrans/licence.txt +++ b/simutrans/licence.txt @@ -7,6 +7,7 @@ Simutrans source code is provided by the current simutrans team
This includes the translations from: http://translator.simutrans.com/ +the images and .dat files included in the source distribution, the midi files and the fonts with the execption of the m+10r.bdf, which is taken from the M+ font project: http://mplus-fonts.sourceforge.jp/
Edit:
And because somebody just pointed to an old thread: Is the `no-sell' restriction intended to be stricter than the one in the Artistic License? That is, is selling intended to be forbidden even as part of a software compilation (such as, for example, a Linux distribution as Debian) as well or just selling Simutrans on its own (as the Artistic License states)? From prissi's comment above I take that it is not intended to be stricter than the Artistic License. I think this does not need an extra comment when the change I suggested above is done.
*sighs* I really don't like discussing license problems :-/
today I got a bug report in Debian by somebody who interpreted simutrans/copyright.txt as forbidding modification and selling (even in the ways permitted by the Artistic License):
Quote
The wording does not make it clear if the non-free clauses are meant as additional restrictions trumping the Artistic License or if the Artistic License is meant as an additional freedom trumping the non-free clauses.
Note: "non-free clauses" refers to "Simutrans may not be sold or modified in any way without written permission by the author.".
I think one must want to misunderstand in order to think that one is forbidden to modify/do other things with Simutrans as permitted by the Artistic License as otherwise releasing it under the Artistic License would not make sense at all...
But in order to try and make everybody happy:
1. Is my ****umption that the statement that Simtrans is available under the Artistic License counts as a written permission to modify/sell/whatever as required in the statement above correct?
2. If yes, can this be included in copyright.txt? Maybe just remove the problematic sentence [1] and optionally add something along the lines "For uses not mentioned in the Artistic License you must ask the author for permission." (might need better wording though...)?
Thanks in advance and sorry for causing such boring bureaucratic work, Ansgar
PS: One other minor thing comes to mind: could you please include the files in skins.src/ in the statement what contains source code in simutrans/licence.txt as well? As far as I know it moved over from the pak64 and is thus not yet mentioned there.
Copying the files from the *.zip files to the locations used by the Debian/Ubuntu package will not work (the executable will look for game data in the wrong directory).
If you have version 102.0, I ****ume you use Ubuntu Karmic? In that case there are packages for 102.2.2 available in the karmic-backports repository. See https://help.ubuntu.com/community/Repositories/Ubuntu#Ubuntu Updates how to enable this repository. You need to update simutrans, simutrans-pak64 and simutrans-data (which should be included automatically as a dependency). Later Ubuntu releases (Lucid and Maverick) both include 102.2.2.
In case you want to use the binaries as released in the *.zip files, I think installing them in some other directory (such as a subdirectory of your home directory) might be easier.
Ah, I remember there was a special concrete lorry in the past. I didn't think you could transport them as boxed goods. Is it possible that tis was changed sometime? AAC stones probably cannot be transported by a concrete lorry after all
But I think it should be save to close the bug by now.
forwarding an older bug report from Debian I had forgotten about:
Quote
I couldn't find any road/train vehicle that was able to transport concrete. IIRC, there were both present in some version which I get earlier from upstream (before .deb era).
Hmm, interesting. When I access the site via a German proxy it works. Maybe the server is randomly banning IP addresses from other countries? It would be better to not do so... There is also a thread on the Japanese forum [1] about it (you can see nightly 403 fobidden in the topic ).
That 403 page also includes annoying flashing ads... Even the "Impressum" link leads to a 404 (not found) page that also includes those really annoying ads...
yes you're right, I found that activating NEW_PATHING lets the program run fine, whilst OPTIMISE breaks it. Now I looked in the Makefile and the only conclusion I can draw is that it's a toolchain bug. If anyone agrees I'll head over to GCC and post a bugreport.
More likely is a bug in Simutrans. An optimizer may make certain ****umptions about the code, but a program could be written in a way that these are not true. In that case it will likely crash or give wrong results.
Quote
ansgar: in the meantime, can you deactivate OPTIMISE for the amd64 autobuild?
Yes, but I configured ccache to use a different cache directory for amd64 and i386 (IIRC it didn't work at all before). I just cleaned the cache anyway.
Starting with the next build (simutrans|makeobj)-exp-latest should redirect to the files including a date. This way the browser should save the files that way as well.
I suppose I should ask how the simutrans git mirror is updated automatically, since at the moment I only know how to manually update a git mirror of an svn repo. (Maybe someone just has a cron job running, but unfortunately I can't really do that.) Anyone know who aburch is and how he or she does this?
That is a cron job. If there is interest, I can setup another one for pak128.Britain as well.
brian m. carlson submitted a bug report in the Debian Bug Tracker:
Quote
I have a simutrans game that I have been playing for some time and I now have more than 1 000 000 000¢. However, the game now displays such large amounts of money as 1,000.0M¢, which can be a little confusing when, for example, I am in the finances window. Although I understand the need for compactness, I'd still prefer it if it listed the full quantity. I would, however, be okay if for compactness with such large numbers, the decimal point and fractional credits were left off.
Thanks for the info. Unfortunatly I cannot backport versions which are not in the Ubuntu repository. [...] I could ask for a sync request with Debian unstable to Lucid and backport that version, that would be an option. For now I cannot do much about it.
Hi,
I already filed a sync request [1] for the latest stable release of Simutrans. Could you wait with the backport until the new version is available in Ubuntu? There is also a backported package (simutrans, simutrans-pak64 and simutrans-pak128.britain) available in the Debian Games Team PPA [2].
the attached patch corrects some spelling errors that I found while updating the Debian package (lintian, one of Debian's QA tools, finds some common spelling errors in binary programs). One spelling error remains: "artifical" (instead of "artificial"). I did not correct this one as it was also present in the translations.
Note: The patch is against the sources for 102.2.2.
I'm not sure why demo.sve should be causing problems?
It's a bug in an older version of Simutrans. Ubuntu (and Debian) usually don't update software after a release, you have to update to a newer release in order to get newer versions of the software. It is still possible to upload bug fixes (at least for severe bugs), but this would require someone to look for the exact change required to fix this bug. As I mostly care about Debian which no longer ships this version, I will probably not do so.
I did make a newer package for simutrans available in an inofficial repository which should no longer have this particular issue. It also includes a package for pak128.Britain.
any updates on the release plans for 102.2.2? Ubuntu's feature freeze is on Feb 18th and it means more work for me to ask them to include a new upstream release after this (esp. as I don't use Ubuntu myself).
Debian unstable and Ubuntu Lucid currently include simutrans and pak64 102.2.1, and pak128.Britain 1.06.
are there any plans when to release Simutrans 102.2.2? Ubuntu will freeze in a few weeks [1] for the next release, Debian might freeze in March [2]. After the freeze new upstream releases are generally no longer included. I would of course like to include the latest bug fixes in the packages for both distributions. Currently Debian has 102.2.1 in unstable. Ubuntu still has 102.2, but should update to 102.2.1 soon.
Both Debian and Ubuntu do not update packages in after release (except for serious bugs and security issues), but I provide some more recent packages for Simutrans in the pkg-games PPA on Lanchpad. They are identical to the packages in Debian unstable, but are build for earlier Ubuntu releases.
Do you think that you could send me the code so that I could integrate that function into Simutrans-Experimental, at least, the Linux version using precompiler directives?
Sure, it is available from git.debian.org. But after applying it, simutrans won't look for data in the program directory any longer, only in /usr/share/games/simutrans. So it is only useful if applied to the packaged version of Simutrans.
[offtopic]Might it be possible to include these .deb files in the non-free part of Ubuntu/Debian?[/offtopic]
Could you also include in this repository the newest ST version? Because in Ubuntu there are allways old versions.
There is no statement from the copyright holder that redistribution is allowed, so it cannot be distributed by Debian/Ubuntu (not even in the non-free section). I will not upload packages for the simutrans binary and pak64 to this repository. They wouldn't be more current than the version included in Debian unstable anyway. If you want to install a more recent version of simutrans on the latest stable release of Ubuntu, there are packages available from the pkg-games PPA.
Any chance of getting Pak128.Britain-Ex for Simutrans-Experimental, too?
Simutrans-experimental does probably not look in /usr/share/games/simutrans for paksets? If not, there is no use for packages. They only ease installation to this system-wide location. (Note: Debian's version of simutrans has a patch to look there.)
The packages should work on both Debian and Ubuntu. Please report any problems.
Note: Adding the repository to sources.list might not work on amd64 for now as I did configure something wrong for that. Will probably try to fix that later.
I already created a Debian package for pak128.Britain two months ago. I have now updated the package for release 1.05 and uploaded it to my PPA repository on Launchpad[1]. It should be usable, but I will wait a bit longer before asking for an upload to Debian as a new stable release for Simutrans seems to be coming soon. Comments are always welcome.
Creating a package for pak128 should be really simple, but as it cannot be uploaded to Debian and/or Ubuntu due to a missing distribution license, I have not done so.