Transport Tycoon Forums

Posted: **04 Mar 2010 11:34**

ChillCore wrote:Could it be that you have not checked out the correct revision of the source before trying to patch?
When a diff/patch is made it is done so against the revision the creator had installed at that moment.

Revisions of the source and patch are the same.

Posted: **04 Mar 2010 11:38**

fivejc wrote:Revisions of the source and patch are the same.

Where did you get this patch? I can't find any patches with the revision r19289 at fonsinchen's usual patch place: http://fickzoo.com/fonsinchen/patches/against_trunk/

Posted: **04 Mar 2010 11:40**

it could well be that you applied the patch in the wrong dir.

if the Makefile is in ~/ottd that's where you apply the patch. Not in ~/ottd/src
~/src as your screenshot seems to hint at is a bad idea.

Posted: **04 Mar 2010 11:58**

petert wrote:
fivejc wrote:Revisions of the source and patch are the same.
Where did you get this patch? I can't find any patches with the revision r19289 at fonsinchen's usual patch place: http://fickzoo.com/fonsinchen/patches/against_trunk/

From http://users.tt-forums.net/petert/dev/CargoDist/r19289/

planetmaker wrote:it could well be that you applied the patch in the wrong dir.

if the Makefile is in ~/ottd that's where you apply the patch. Not in ~/ottd/src
~/src as your screenshot seems to hint at is a bad idea.

Ok. That's good advice

Posted: **04 Mar 2010 14:45**

fivejc wrote:
petert wrote:
fivejc wrote: Revisions of the source and patch are the same.
Where did you get this patch? I can't find any patches with the revision r19289 at fonsinchen's usual patch place: http://fickzoo.com/fonsinchen/patches/against_trunk/
From http://users.tt-forums.net/petert/dev/CargoDist/r19289/

Lol. That was funny.(To read...)

Planetmaker wrote: it could well be that you applied the patch in the wrong dir.

if the Makefile is in ~/ottd that's where you apply the patch. Not in ~/ottd/src
~/src as your screenshot seems to hint at is a bad idea.

Nice spotting. I totally missed that bit.

[OT]
petert,
may I suggest that when you provide binaries you do so against a revision chosen by the patchmaker unless you are absolutely sure what you are doing.
I have had bugs introduced in "the other patch" while bumping without being alerted by svn there was a problem.
If this happens with one of your bumped binaries and then the user goes complaining to the patchmaker, said patchmaker has no clue where the bug came from because he can not know what you have done, or what you may have forgotten to do without him/her going through your patch.
Do continue to provide binaries. It is very much appreciated by many people but please, be carefull when bumping as it might generate some unnecessary bugreports, or even funny conversations (see above).
I am not saying you introduced bugs, just saying that It may happen and solving it can take a lot of time.

[/OT]

Anyway I hope fivejc has a working binary by now.

Posted: **04 Mar 2010 15:23**

ChillCore wrote:
Anyway I hope fivejc has a working binary by now.

Oooo... That's illusory hope, because my MinGW installation isn't able to applying any of the patches!

Posted: **04 Mar 2010 15:42**

I am no longer on windows but while I was I used Turtoise svn to patch.
I just noticed that the wiki for compiling on linux has some information concerning applying patches that the mingw page has not.

Could you try this command and see if it helps?

Code: Select all

patch -p1 < mydiff.diff

Posted: **04 Mar 2010 17:26**

I work on windows and I have TortoiseSVN, but this kind of patches doesn't work with Tortoise.

I have tried every code and none of them worked!!

Posted: **04 Mar 2010 17:50**

fivejc wrote: I work on windows and I have TortoiseSVN, but this kind of patches doesn't work with Tortoise.

I know but I never tried with -p1 before so it was worth a shot.

You have two options remaining however:

1. The easy way:
- Install GIT and pull directly from fonso's repository. (see first post in the cargodist thread)

2. The hard way:
Translate the patch so it can be used by Turtoise.
- http://www.tt-forums.net/viewtopic.php? ... 2&start=60 ninth post
- Next page second post.

Posted: **04 Mar 2010 20:02**

ChillCore wrote:[OT]
petert,
may I suggest that when you provide binaries you do so against a revision chosen by the patchmaker unless you are absolutely sure what you are doing.
I have had bugs introduced in "the other patch" while bumping without being alerted by svn there was a problem.
If this happens with one of your bumped binaries and then the user goes complaining to the patchmaker, said patchmaker has no clue where the bug came from because he can not know what you have done, or what you may have forgotten to do without him/her going through your patch.
Do continue to provide binaries. It is very much appreciated by many people but please, be carefull when bumping as it might generate some unnecessary bugreports, or even funny conversations (see above).
I am not saying you introduced bugs, just saying that It may happen and solving it can take a lot of time.
[/OT]

I wasn't completely sure what you meant. Are you saying you want to lower the number of trunk-related bug reports by not bumping the revision number? I would disagree. I remember one build with a serious train-building bug, and I had to bump it to trunk so that it would not have the bug. I think that a newer trunk version usually contains a smaller amount of bugs.

Posted: **04 Mar 2010 22:54**

petert wrote: I wasn't completely sure what you meant. Are you saying you want to lower the number of trunk-related bug reports by not bumping the revision number?

I meant bug reports in patch threads.
If all would be like it should be, there would be no patch-bug reports made to the Devs, unfortunately ...

I would disagree. I remember one build with a serious train-building bug, and I had to bump it to trunk so that it would not have the bug.

In case of discovering a serious bug I would report it to the patchmaker so he can post a new version and only then post a new binary so he knows for himself what has changed and where in that version. For all you know half his/her patch depends one that one piece of code you fixed.
The above assuming the patch is under active development, and you are not a co-patch-writer. Bumping an old patch you like with a newer version is another story.

I think that a newer trunk version usually contains a smaller amount of bugs.

I agree but its not like the new binary can not wait a day. when a patchwriter bumps his patch he first takes a look at the changelog, at least I do and I can tell on the beforehand if a certain bugfix or new feature is going to cause problems for me or not while bumping most of the times. eg. smallmap zooming and colours.

Just to give you an example of what can happen.
The terraforming cost code in the other patch. I have commented it out because I know it belongs somewhere else and I did not get to moving it yet.
You could have decided that you can fix it by removing the return and putting it before the return that is allready there. Yes that would seem to fix the bug, but It would also break the way the patch is written. We calculate our terraforming costs elsewhere.
Then in six months time someone comes along complaining that some other costs are off and I have no clue where to start looking, remember, you fixed the bug in your version but by accident created a bug somewhere deeper in the code. I have continued in another way but the player is playing with your version and complains to me. Now I am looking for a bug that does no longer exists in my version ...

Or even worse, the patch gave no error because the cost calculation has snuggled itself before the other return so nothing appeared broken -> our custom code is no longer executed but the patch runs. You post the new patch, I have not looked at the changelog because I was feeling lazy for a week or two and continue without worries because peeps have been playing for some time with your patch and had no problem. Then in six months ...
The "worse" scenario would not be your fault but I would have spotted it maybe if I was bumping myself. I have had a few bugs slip past me like that when I was struggling to get past a certain revision.

To conclude:
Most programmers appreciate it very much when you present them code to fix their code, yours truly included. If you know about a bug or you have code by all means post it. (eg. flyspray for vanilla OpenTTD bugs)
Most programmers if not all do not appreciate bug reports for code they have not written. (eg. patch bugs on flyspray)

/me thinks enough off topic for today. me also still thinks it was funny moehahahaa. Signature material. roflol.

Posted: **24 Apr 2010 15:26**

How can I get TortoiseSVN to use the -p option? (skip leading dir)

Posted: **24 Apr 2010 17:40**

I don't think that is possible, it is a known limitation of tortoiseSVN that it does not understand mercurial or git patches.

That is quite likely mentioned several times in this thread already.

The common solution is to get a better patch program, and use that instead.
I don't know how/where to get that, but I am sure it is explained at the forum and/or at the wiki. Just search for it.

Before you consider patching the source, did you try compiling and running an unpatched version first? (to check your compiler setup).

Posted: **24 Apr 2010 17:49**

Yes, finally got my compiler working.

I have searched all day and I couldn't find any strait answers, nor a better patching software.

The Wiki is very outdated and unhelpful in this case

Posted: **24 Apr 2010 19:05**

Bøtteknott wrote:The Wiki is very outdated and unhelpful in this case

The wiki is as useful for "noobs" as the "noobs" that figured it out make it. It might sound very harsh and stupid, but... for the people that patches and diffs are child's play, it is usually inconceivable what you "noobs" see as the difficult/hard to understand bits.

Also development, at least in many cross platform open source projects, uses a lot of console/command line tools and the developers are familiar with that. For the "random" Windows user the command prompt is just a black box with meaningless text and a flashing rectangle. They can't make sense of it; they can't even understand that the command prompt doesn't work very well for software development, which is why you need to install extra stuff that is hardly updated since Windows XP and as such has a massive list of issues with Vista and 7, not to mention that the updated version for Vista and 7 is utterly and completely broken at some points.

Even then, most "noobs" w.r.t. patching have zero knowledge of programming languages but still want to apply multiple patches because they sound interesting without having any clue how to solve the problems when two patches are colliding. It's nice you want to try, but without some affinity for programming I fear it will end in tears and frustration as I've seen on here and other places over the years.

Posted: **25 Apr 2010 01:59**

What Rubidium means is: please write down what you think is outdated/difficult to understand and add that to the Wiki.

Posted: **25 Apr 2010 19:10**

In this page the section about "Compiling zlib" is outdated as the url in the installation is dead...bla bla bla...replace with point number 4 on this page.

The first post in this topic (Click here if you need to read it again) is the source to a lot of compiling questions and problems. It hides a big secret. Wanna know what the secret is? It only works for LINUX!
Why not mention that in the first post and save you a lot of time modding the forum? Clearly, as we can see by your attitude, you're tired of stupid questions like that.

Posted: **25 Apr 2010 19:25**

Bøtteknott wrote:It only works for LINUX!
Why not mention that in the first post and save you a lot of time modding the forum? Clearly, as we can see by your attitude, you're tired of stupid questions like that.

Not. Those commands require a bash, the first few posts are misleading. One you install MSYS using that guide, you can type those commands there.

Posted: **25 Apr 2010 19:36**

Bøtteknott wrote:Clearly, as we can see by your attitude, you're tired of stupid questions like that.

The only tiresome thing is people who *think* that they know it all (now) and then come with an attitude and start be become abusive.

Posted: **10 May 2010 22:15**

Bøtteknott wrote:In this page the section about "Compiling zlib" is outdated as the url in the installation is dead...bla bla bla...replace with point number 4 on this page.

The first post in this topic (Click here if you need to read it again) is the source to a lot of compiling questions and problems. It hides a big secret. Wanna know what the secret is? It only works for LINUX!
Why not mention that in the first post and save you a lot of time modding the forum? Clearly, as we can see by your attitude, you're tired of stupid questions like that.

Since it is a wiki, did you bother to edit and update the page with the correct directions?

As for me, I'm stuck on the zlib compile/installaton part myself. I'm in msys and here's where I'm getting hung up:

Code: Select all

Administrator@KAM-GIGABYTE /home/zlib-1.2.3/mingwPORT
$ mkdir /usr/src/zlib-1.2.3
mkdir: cannot create directory `/usr/src/zlib-1.2.3': No such file or directory

BWAH? Is there a reason I can't create this directory?

Transport Tycoon Forums

Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file

Re: Howto apply a patch/diff file