At http://www.openttd.org/nightly.php you can download several versions of the OTTD Nightly. On the main page you see that the latest version r7515. In the archive section however the latest version is r7553. Question, why is on the main page the latest version r7515 and not r7553?
TrueLight:"Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?" <@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter. He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
Works fine for me, too. Maybe you should check your system for virus or spy-/malware.
Edit: There was an accidently double post, because of an forum error I got, I just deleted the second post.
Denke nie gedacht zu haben, denn das Denken der Gedanken ist gedankenloses Denken. Wiki Page/Talk, Member of the OpenTTD Scenarios Team Looking for OpenTTD scenarios? - Here's a List of player-made scenarios. Please help us grow the database with your contributions.
I noticed that there wasn't a rpm version available for Fedora (7) of either the stable or nightlies, so I decided to create one. I'm attaching the required .spec file for the rpm creation to this post.
Usage:
1. Make sure you have a rpmbuild-environment and following packages installed: gcc, gcc-c++, SDL-devel, zlib-devel, libpng-devel and desktop-file-utils
2. save the attachment as openttd.spec to ~/rpmbuild/SPECS/
3. download the OTTD-source-nightly-r10166.tar.bz2 (or newer) package to ~/rpmbuild/SOURCE/
4. open console and cd into ~/rpmbuild/SPECS/ (and modify row #2 in the openttd.spec file to match source version.)
5. issue the following command: "rpmbuild -ba openttd.spec", and wait for the build to finish
6. cd into ~/rpmbuild/RPMS/i386/ and install the openttd-nightly-r10166-1.fc7.i386.rpm package as root. (again, if you used a newer source the package name will differ)
7. copy sample.cat, trg1r.grf, trgcr.grf, trghr.grf, trgir.grf and trgtr.grf to /usr/share/openttd/data/ as root from your copy of TTD
(8. copy the contents of the gm folder from your copy of TTD to /usr/share/openttd/gm/)
You can now launch openttd from Applications->Games->Tactics & Strategy->OpenTTD
If you want the music to play, you'll need both timidity++ and esound. Then go to System->Preferences->Hardware->Sound, open Sound-tab and Enable software sound mixing (ESD).
If you find any errors or have any suggestions, let me know.
Has the timing parameters been changed for lost trains ?? Every nightly after r10343 keeps telling me trains are lost when they are not . Someone explained to me that after a certain amount of time has elapsed the lost message is triggered . I am using a very large map (2048 x 2048) and steam trains from the 1930`s period and so there is bound to be a while before they reach their destination . Every minute or so the screen is plastered with most of my trains reported lost when they are perfectly on route . r10343 was fine and so were all the nightlies previous but the last three must have had some timing parameters changed . Is there likely to be any modification to rectify this in future releases ? Thanks
I downloaded on the 7th of july. The exe file have a size of 2.51 MB
I also downloaded the source code (rev10499) and compiled it. My executable file is only 1.48 MB...
I wonder if it's the same version (??)
Or just my VS2005 that produce a smaller binary file ?
MagicBuzz wrote:I have a small question about the Nightly build.
I downloaded on the 7th of july. The exe file have a size of 2.51 MB
I also downloaded the source code (rev10499) and compiled it. My executable file is only 1.48 MB...
I wonder if it's the same version (??)
Or just my VS2005 that produce a smaller binary file ?
Nightly build are compiled by gcc, which is different compiler (builds are created on some compile farm using cross-compile) ...
When I build using mingw+msys, my binaries are about 2MB ... yet another different size. So unless you don't use same compiler with exactly same settings and have exactly same libraries, expect the binary to be different ... but it should behave the same. Gcc is just less effective when it comes to size of bniary in this case.
If you need something, do it yourself or it will be never done.
in fact, i used to make some patch several months ago, and VS 2005 was creating exe files bigger than the nightly's, so i was just unsure the current source code available on svn was the same