Transport Tycoon Forums

If you want to see it in the game proper, I'd recommend patching against the trunk, not 0.5, because the architecture of OpenTTD is changing rapidly and significantly. 0.5 is going to seem very out of date to anybody who wants to port the patch forwards.

Updated to the last revision (r7993)

BTW, the svn does not contain nsignalw.grf and a lot of other grfs for running OTTD. Download them from the rc5.0 source.

That is not true. Due to syncing beyond r7759, where a lot of moves occured, a lot of files have changed their location. So did those grfs; they moved to bin/data.
Most likely you are running the executable which is under trunk/. That executable is _not_ the executable of any revision after r7759, as the generated executable is now in bin/.

You should remove openttd and all *.o files in trunk/ and use the binary that is in bin/.

Well the new configure needs anyway some more work, since it does not work with mingw (at least on my machine), since it assumes libpng, freetype, and zlib in /usr/local/include (which does not neccessarily exist of course, since you could (and I did) install mingw and msys in C:\programme\).

So I had to build it without freetype, zlib and png support. But I could not start this binary, it complains about about missing language pack (even though I just run the makefile). I just run the makefile, after configure, so I think this new makefile needs to settle a little.

I have not the time in the moment to find out why I cannot start this, but the patch compiles properly, so try your own.

./configure --with-zlib=F:/Programme/MinGW/lib/libz.a --with-png=F:/Programme/MinGW/lib/libpng-config --with-freetype=F:/Programme/MSYS/1.0/src/freetype-2.2.1/builds/unix/freetype-config

This is how configure works for me with MSYS/MinGW.
Zip, png and freetype were compiled with mingw too.
I think they gave some errors, but the required .a files were compiled correctly.

My point was just that if there is the option --without-zlib --without-png --without-freetype and the configure script runs, make runs, but then the exe cannot start ... (because of "missing language packs", even though everything seems fine). Or is this a Win98 error, because unicows.lib is not linked?

That's the non-unicode build and win9X symptom. And it's not fixable for now because mingw doesn't support it.

Since I built a unicode simutrans version in Win98 I am sorry, I have to doubt your statement that this is not possible. You can use the full range of unicode functions in Win98, if you link with unicows.lib.

Well, then good luck to anybody who wants to support my patches any longer.

Hi guys,

I patched a r8007 nightly succesfully (I think), but I don't know how to use it...

I built 2 networks of 3 train stations with a train (pax & mail) per network.
I built a line between these networks with a train going from network1-station1 to network2-station1.

I don't know how to have the information of my passenger destinations.

Any help ?

Thanks ,

Christophe.

patches -> Economy -> passengers with destination (or so) on
Three settings:
- how many times they maximum will transfer
- how much the passenger rate should be reduced (power of two)
- after which time a certain connection will be treated as abondoned (should be longer than your longest round trip time for and consiste/bus)

Why would one want to reduce the number of passengers? Because every transfer effectively doubles the number of passengers at the stop.

(Personal rant: The current aim of the development team seems to frustrate all patch developer and furthermore render all old patches useless which all these deleting and recreation of files loosing all history and the possibility to transfer patches across ... Perhaps a branch and then all changes at once would be a much more friendlier policy. And there is svn mv there for a reason, if mostly filenames were changed! Thus one has really to do the patching by hand. I really wonder why no one has objected to this.)

In both cases svn move was used!

We even tried to make upgrading your patches as easy as possible as the commits where all the files get renamed/moved do not modify the files itself. Just svn update to the revision before the rename, make a diff, svn update to the revision of the rename, apply patch and then you can just svn up to the latest revision.

Furthermore doing two completely different things in one branch is asking for trouble, and there was not even a plan to make OpenTTD C++ compatible when the makefile rewrite stuff was merge.

OK, I apologize for the rant about not moving.

However, applying the patch and then the moving resulted in the changed c files to be not moved, because first svn deleted all files and then added them again. Thus the "original" C-files appeared again and the patches were lost to all files (probably only all files with conflicts?). Maybe a problem with my svn-clienten then. (The h-files did work, but economy.c did for instance not.)

Hi Prissi,

Thanks for your explanations, it's OK now, I got it

Thanks for your time.

Christophe.

(for the future, this patch will join the main code ?)
[/img]

Unlikely, since it cries also for CargoPackets for normal goods which are not implemented.

And it's still very buggy. Are you still working on solving the error's in for instance economy.c?

Since I am the head coder for Simutrans, and my wife had a bady six weeks ago, my daily programming time is less than an hour. I do not play OTTD regularly and, moreover, now I cannot even test is at work (since we use Win98). Therefore my efforts will be small.

However, there has been very litle bug reports of the later releases. For five begs for updates less than a bug report, and only one reproducable situation. I did some work and I think debugging the rest should be not very difficult given some time to play around (which I do not have).

I the echo is that low, (compared to 50+ posts for simutrans) then my motivation is not too high. But it is open source, so somebody can easily continue.

Also the biggest problem for cargo packets is, that the developers does not want cargo to have a destination (at least this is the impression one could get from this thread further up). This make routing rather difficult. Otherwise the current code could easily extended to cargo packets, the foundations are there and working.

(Btw. the renovated vehicle read/writer and the unified vehicle info dialog are thinks that could go into the trunk easily.)

Update to r8104, fixed bug with 0 passengers, did rub stable over night

Hey.

I've done everything mentioned for Windows (used TortoiseSVN), in this topic: viewtopic.php?t=21678

I've applyed the diff-file again using TortoiseSVN, but I can't see the pacth working.

I've also updated the OTTP with the latest nightly patch, so I think I sould be using the newest files.

I'm absolutely newbie in this Open source universe, so if anyone can help me that would be great.

You compiled after applying the patch, right?

You must be inside the trunk folder to apply this patch. (But I am not sure if TortoiseSVN can do this, I rather use the mingw-tools for this.)

Ok, here the window exe.