Chill's patchpack v14_7

[Kogut]

Advanced settings, linkgraph, change (a)ssymetric to manual.

[Birdbrain]

Advanced settings, linkgraph, change (a)ssymetric to manual.

Thanks.
I should have been able to find that myself.

[romazoon]

Hey there,

I have a small problem with The Chillpatchpack v13.5 installed on my computer... and this is since i installed a YACD version on my computer.

image of the problem : (the black area is not black, and keep mirroring what's on the map...)

Romazoon Corp., 08_08_1925.png

(470.33 KiB) Downloaded 1 time

My first guess would be that some settings in my openttd.cfg have been changed during the YACD instalation (every different version i installed are using the same openttd.cfg but it's the first time i encounter that problem).
So does anyone would know wich one and what s the right settings ? Or would it have something to do with the black tiles.grf ?

thanks in advance

Edit : I just found out that the three needed grf were missing in my data folder (not the grf folder)...so i installed them back (the flat-balcktiles.grf, the copy paste.grf, and the trafficlight.grf).... but i still had the same problem.
I then checked the Blitter setting in openttd.cfg : it s on 32bpp anim, but if i set it to 32 bpp optimised(like advised in the first post of this thread) the game ask me if this "32 bpp optimised is really existing and then doesn t launch. Anyone know what s wrong ?

[ChillCore]

Hi romazoon,

Your problem is not caused by YACD nor is the problem in your configfile.
You have upgraded OpenGFX which includes new sprites that my patchpack does not take into account yet.
Either downgrade to the previous version of OpenGFX or wait a bit untill I boot my other computer(*) to fix the issue ... (it is just two lines I need to change but I have to check the numbers)

I will post the lines to modify shortly but before posting a new version of the patchpack ... I have another little issue to solve:
I have in my newest (functional) version a few new features, one of which bumps the savegame, but I did not bump to a newer revision.
My problem is that the revision still is 22553M but games saved with the new version will not load in v13_5 or earlier.
Anybody that knows how I can make this clear to players without changing the revision string manually to display v13_x?



(*)
Completely offtopic but after three weeks of trying to get Ubuntu 11.10 to behave as I want and re-installing it seven(!) times I am going to move away from Ubuntu.
I am now toying around with LinuxMint, Xubuntu, Kubuntu and Debian-live.
So far I am liking LinuxMint best, they will be keeping compatibility with Gnome2 (most likely they will be using the Mate fork in the future) and not turn my desktop in some sort of smartphone failure. If/when they do then it wil be removed faster than it was installed.
Luckily I was/am testing on a seperate machine and did not make the misstake of upgrading my 11.04 install (and never will) so everything I did before is still there and I can continue without having to re-install everything (even if it will be on an outdated OS in the future).
[/rant]



Also, quick poll:
As I mentioned before, in the near future I may be looking at the possibility to host the source somewhere and doing the tedious job of maintaining and extending the patchpack in a collaborate process.
I am just waiting for LinuxMint 12 to be released so I can have a fresh installation of the newest version. I will be using this setup for OpenTTD only.
If people are interested to join please reply to the thread and or send me a PM, just so I have a rough idea of how many coders we are (if any). Also please mention what would be your prefered version control system (Git or HG).
Please do not reply if you are not interested, or just want to say that it is a good idea to do so.

I then checked the Blitter setting in openttd.cfg : it s on 32bpp anim, but if i set it to 32 bpp optimised(like advised in the first post of this thread) the game ask me if this "32 bpp optimised is really existing and then doesn t launch. Anyone know what s wrong ?

Can you please try optimized with a z, most likely I have made a typo ... (although s and z both are valid english, IIRC)
Can not check myself at the moment as I do not have installed any additional software on this PC as mentioned above.

[romazoon]

Hi Chillcore

Thank you very much for your fast answer, that s very appreciated


Also the Z instead of S in optimized was indeed working ! thanks for that too

[ZxBiohazardZx]

sourcecode hosting can always be done on github for free if you chose to use git, the only issue is finding a person who is willing to maintain it

[JGR]

I'd personally prefer Hg, mainly because I'm more used to it and TortoiseHg >>> TortoiseGit, but realistically there's little difference between the two systems.

Various sites offer free Git and Hg repositories, that's not really an issue.

[Jacko]

Careful! Hg is poisonous !!!!! (Science joke)
Also the chunnels only work if the shoreline tile is green. Don't know if this is a bug.... try it out.

[ChillCore]

Hi Chillcore

Thank you very much for your fast answer, that s very appreciated

You was just lucky I was browsing the forum at the moment.
Unfortunatly, I still have a lot of posts to reply to ... I should get to that sooner than later.

Also the Z instead of S in optimized was indeed working ! thanks for that too

Thank you for testing, I will update the first post shortly.
As for your glitches problem ... I am now at my other puter and will have a looksie at the code to change after changing the first post.
It will be more than 2 line but it is just increasing the numbers (that the patch ads) in table/sprites.h by 2. I have not yet done so myself so this is untested at the time of writing.

sourcecode hosting can always be done on github for free if you chose to use git, the only issue is finding a person who is willing to maintain it

HG code can be hosted on the coopserver if requested (and the offer is still valid).
Also someone offered (svn) space on his personal server a long while ago, but I am not sure if it is a good idea doing that ... there were over a 1000 (woot) downloads of v13_5 last time I checked so the bandwith usage would be a lot higher then it was at the time of the offer.

The point of setting up a remote repository would be that everyone with access(*) can contribute and fix/tune/add code lowering the workload for me ...
Keeping up the pace I was going at before is more than a dayjob.
I could solve that by asking for donations, stopping to search for a dayjob and doing the patchpack for a living but somehow that does not feel correct as I re-use code of many people (Devs and patchwriters) and I would be cashing in for the efforts of someone else.

(*) I do not plan to grant anybody access (or anonymous) just like that for obvious reasons, at least not without seeing some sample code first.

I'd personally prefer Hg, mainly because I'm more used to it and TortoiseHg >>> TortoiseGit, but realistically there's little difference between the two systems.

I myself have a slight preference towards GIT but that is only because I am more used to using it (although I still fail to pull a complete patch from it ).
There are however many extensions to HG that I have not explored yet (eg. pbranch sounds usefull.)
Also I have been using the nautilus gui extension untill now instead of doing things via the console, so most likely I have not even touched the power of HG by far.

Careful! Hg is poisonous !!!!! (Science joke)

I did not go to shool long enough to get it but I am guessing that I need to have a looksie at the periodic table of Mendeleev?

Also the chunnels only work if the shoreline tile is green. Don't know if this is a bug.... try it out.

Could be that the shoretiles need not to be bare anymore... I will check in a bit.
Thank you for reporting.

[JGR]

HG code can be hosted on the coopserver if requested (and the offer is still valid).
Also someone offered (svn) space on his personal server a long while ago, but I am not sure if it is a good idea doing that ... there were over a 1000 (woot) downloads of v13_5 last time I checked so the bandwith usage would be a lot higher then it was at the time of the offer.

The point of setting up a remote repository would be that everyone with access(*) can contribute and fix/tune/add code lowering the workload for me ...
Keeping up the pace I was going at before is more than a dayjob.
I could solve that by asking for donations, stopping to search for a dayjob and doing the patchpack for a living but somehow that does not feel correct as I re-use code of many people (Devs and patchwriters) and I would be cashing in for the efforts of someone else.

(*) I do not plan to grant anybody access (or anonymous) just like that for obvious reasons, at least not without seeing some sample code first.

Google code, github, bitbucket, are the most obvious free sites which would be suitable. I mainly use sourceforge ATM, but frankly would not especially recommend it.
I don't know about the coopserver, so can't comment on that.

You ought to make read-only access anonymous. After that, the usual way this sort of thing is done is that people submit patches, after which, if they're sufficiently good, you can give them commit access to a personal branch, from which you can pull, or just give them trunk access.

You can always ask for donations. If people don't feel that that is appropriate, they're free to just not donate. Pretty much every software project ever has re-used code from other people, so you needn't worry about that.
I will say that you will almost certainly not get enough donations to match a day job.

I myself have a slight preference towards GIT but that is only because I am more used to using it (although I still fail to pull a complete patch from it ).
There are however many extensions to HG that I have not explored yet (eg. pbranch sounds usefull.)
Also I have been using the nautilus gui extension untill now instead of doing things via the console, so most likely I have not even touched the power of HG by far.

To be honest, you probably won't need most of the esoteric features, and you can always investigate them later if it turns out that you do need them.

I did not go to shool long enough to get it but I am guessing that I need to have a looksie at the periodic table of Mendeleev?

Hg = Mercury (kviksilver if I remember rightly)

[Lord Aro]

personally, i would go for hg (mercury - mercurial ) but that's only because i'm used to hg, can git seems more complex to me

i would also go for coop webspace - easy, can easily build projects for you, and very easy to get help

[crocodile]

Good evening.

I would like to ask, if there is any chance that this autoconvert patch would be included in this patchpack. It allows to convert trains from one type of rails to another.

[ChillCore]

Concerning the older unanswered posts ... I have not forgotten and I am not going to ignore them, I am going to grab a bite and then set myself to it ...

Also the chunnels only work if the shoreline tile is green. Don't know if this is a bug.... try it out.

Could be that the shoretiles need not to be bare anymore... I will check in a bit.

Confirmed, but not sure if it can be considered a bug ...
Technically, and as far as OpenTTD is concerned, a bare sloped tile is not a shoreline even if its lower side meets water.
The same thing happens if you try to build a ship dock or ship depot on bulldozed land.
Can't/won't fix sorry.

HG code can be hosted on the coopserver if requested (and the offer is still valid).
Also someone offered (svn) space on his personal server a long while ago, but I am not sure if it is a good idea doing that ... there were over a 1000 (woot) downloads of v13_5 last time I checked so the bandwith usage would be a lot higher then it was at the time of the offer.

Google code, github, bitbucket, are the most obvious free sites which would be suitable. I mainly use sourceforge ATM, but frankly would not especially recommend it.
I don't know about the coopserver, so can't comment on that.

More options than needed,
IIRC, many moons ago OpenTTD repository was hosted by sourceforge, but Devs (ours) moved away for some reason.
I think for the reason of sourceforge being too slow but do not quote me on that, I remember reading something somewhere about that three years ago.
Anyway, they had a reason to move and therefore I would rather not go there ... whatever the reason was.

The point of setting up a remote repository would be that everyone with access(*) can contribute and fix/tune/add code lowering the workload for me ...

(*) I do not plan to grant anybody access (or anonymous) just like that for obvious reasons, at least not without seeing some sample code first.

You ought to make read-only access anonymous. After that, the usual way this sort of thing is done is that people submit patches, after which, if they're sufficiently good, you can give them commit access to a personal branch, from which you can pull, or just give them trunk access.

Something like that was what I had in mind, ofcourse some will be granted access faster than others because I already read code from them over the last couple of years.
My biggest concern is someone just throwing code in without considering the relation to other patches or not caring about coding style at all ... ofcourse that is something to deal with and think about later.

Keeping up the pace I was going at before is more than a dayjob.
I could solve that by asking for donations, stopping to search for a dayjob and doing the patchpack for a living but somehow that does not feel correct as I re-use code of many people (Devs and patchwriters) and I would be cashing in for the efforts of someone else.

You can always ask for donations. If people don't feel that that is appropriate, they're free to just not donate. Pretty much every software project ever has re-used code from other people, so you needn't worry about that.

True, true.
There have been many days in the past that I was coding (mainly testing and debugging for more than 10 hours a day) So in a way it would be somewhat justified ...

I will say that you will almost certainly not get enough donations to match a day job.

If whenever I decide to ask for donations I know that I should not expect to become a millionaire.
If each player that downloaded v13_5 would donate but 10 euros a year I could live of it and it would still be more than what I have at the moment.
My needs are not that high: roof over the head, being able to eat every day, a beer from time to time and a computer (with 2MB/s internet connection) to keep me busy.
All the rest is pure luxury.
Anyway, I have no intention (at the moment) to do so.

I did not go to shool long enough to get it but I am guessing that I need to have a looksie at the periodic table of Mendeleev?

Hg = Mercury (kviksilver if I remember rightly)

Ah kwik (in dutch), nasty stuff indeed.

personally, i would go for hg (mercury - mercurial ) but that's only because i'm used to hg, can git seems more complex to me

I feel exactly the same way, except HG and Git would need to change place in your sentence

i would also go for coop webspace - easy, can easily build projects for you, and very easy to get help

I know, but for the sake of building binaries the code can also be hosted elsewhere -> see CargoDist.
If we/I decide to go the HG way the coopserver would be my first choice, close to home.

Good evening.

I would like to ask, if there is any chance that this autoconvert patch would be included in this patchpack. It allows to convert trains from one type of rails to another.

Hello crocodile, welcome to my thread.
I will add the patch to my requested patches folder for the moment and will have a looksie at the code in a bit for possible conflicts.
Note that I have not yet decided if I am going to continue my current patchpack or start over from scratch so please do not expect it to be added by tomorrow or so ... unless there are absolutely no conflicts at all.



Now finally, to solve those glitches when using OpenGFX 0.3.7, please find attached a patch that fixes the issue.
You have to apply it on top of the patchpack using the -p1 flag as it is a GIT patch.
Old and new versions of the patchpack should and will most likely still be compatible in MP games.
If you are using Tortoisesvn for patching you are better of applying the code manually (it is only five lines long).

As for the new features I talked about before: I have still to find a way to make it clear ingame that you are playing with a newer version that is based on the same revision as before but is not backwards compatible ...
Just to tease you , here is what I have added so far in my local functional version.
- Configurable drag limit when building trees (20-128 tiles²)
- <)- Option to show townpopulation always in white instead of rating-coloured.
- Hotfix for CargoDist (stations pool can shrink).
- Town gui resizes correctly when the towngrowth patch kicks in.

[Eddi]

IIRC, many moons ago OpenTTD repository was hosted by sourceforge, but Devs (ours) moved away for some reason.
I think for the reason of sourceforge being too slow but do not quote me on that, I remember reading something somewhere about that three years ago.
Anyway, they had a reason to move and therefore I would rather not go there ... whatever the reason was.

IIRC the main reason for switching away from sourceforge was that the steps in making a release were not scriptable, so lots of tedious work had to be done manually each time, for each compile target.

I have still to find a way to make it clear ingame that you are playing with a newer version that is based on the same revision as before but is not backwards compatible ...

if you use a vcs like mercurial or git, the branch/tag name will automatically be taken as the "revision". e.g. you will end up with something like "OpenTTD h0123abcd-chipp13_6"

[Terkhen]

Give mercurial queues a look. Unless there is an equivalent for git of course.

[Rubidium]

IIRC the main reason for switching away from sourceforge was that the steps in making a release were not scriptable, so lots of tedious work had to be done manually each time, for each compile target.

Well, the not being scriptable is caused by another issue... every (roughly) 2 months they changed the methods to upload files. So each time you had to do something slightly different which became quite annoying.

It was also the time that the old compile farm was in the state "going away", so we needed a solution for that as well. For that we needed a server, but it's pointless to let it run idle 95% of the day, so it could just as well run the website and all other required services much better than sourceforge ever did.

Now more back on topic. I'd reckon that the guys at dev.openttdcoop.org would be more than happy to help you setting up a mercurial patch queue, or a mercurial repository (extrapolating from the infrastructure sharing patch service). They might even help you with git. Furthermore they might be happy to provide a place for compiled binaries, and then the compile farm can build standard nightly binaries at a given time and push them to there. No more need for posting patches on the forum and waiting for people to put up builds. An added benefit of the dev.openttdcoop.org is that they might be able to provide a bug tracker and wiki for your project like e.g. the infrasharing patch.

In any case, I think they are willing to help you, you just need to ask them.

[ChillCore]

IIRC, many moons ago OpenTTD repository was hosted by sourceforge, but Devs (ours) moved away for some reason.
I think for the reason of sourceforge being too slow but do not quote me on that, I remember reading something somewhere about that three years ago.
Anyway, they had a reason to move and therefore I would rather not go there ... whatever the reason was.

IIRC the main reason for switching away from sourceforge was that the steps in making a release were not scriptable, so lots of tedious work had to be done manually each time, for each compile target.

Well, the not being scriptable is caused by another issue... every (roughly) 2 months they changed the methods to upload files. So each time you had to do something slightly different which became quite annoying.

It was also the time that the old compile farm was in the state "going away", so we needed a solution for that as well. For that we needed a server, but it's pointless to let it run idle 95% of the day, so it could just as well run the website and all other required services much better than sourceforge ever did.

Thank you for clearing that up Rubidium.

I have still to find a way to make it clear ingame that you are playing with a newer version that is based on the same revision as before but is not backwards compatible ...

if you use a vcs like mercurial or git, the branch/tag name will automatically be taken as the "revision". e.g. you will end up with something like "OpenTTD h0123abcd-chipp13_6"

I had already noticed Git doing that but did not pay attention to the HG ingame version string.
If it does too than that is great and my problem is solved except for the fact that I have to be able to pull a complete patch from my source(s) as I prefer one blob of code to review my code and search for errors. I should still have some PM's explaining the methods for both GIT and HG (I never delete PM's and I still have lots of free slots for more to be preserved), else there is still google.
Thank you for explaining

Give mercurial queues a look. Unless there is an equivalent for git of course.

I am testing HG with the moreheightlevels patch while I am testing GIT with my most recent version of my patchpack to see what can be achieved by both mechanisms of version control.
SVN is not an option as when I push it goes for the official repository, which is (luckily) password protected .

I believe that GIT (¿since recently?) has the option (¿extension?) to have some sort of HG patchqueue system, while HG has the pbranch extension to have GIT style branches.
I would like to combine both (git like)branches and HG MQ's as both are equally useful, this is most likely possible but I did not get that far yet.

Now more back on topic. I'd reckon that the guys at dev.openttdcoop.org would be more than happy to help you setting up a mercurial patch queue, or a mercurial repository (extrapolating from the infrastructure sharing patch service). They might even help you with git. Furthermore they might be happy to provide a place for compiled binaries, and then the compile farm can build standard nightly binaries at a given time and push them to there. No more need for posting patches on the forum and waiting for people to put up builds. An added benefit of the dev.openttdcoop.org is that they might be able to provide a bug tracker and wiki for your project like e.g. the infrasharing patch.

In any case, I think they are willing to help you, you just need to ask them.

Being the nice guys that they are I am pretty sure that they are still willing to host the source and/or binaries.
I thought that they prefered HG over GIT at the dev.openttdcoop.org but I should ask instead of assume ...

The bug tracker system is certainly a feature that appeals to me and would be very welcome, I do keep track of most bugs but some slip my attention as I have noticed from browsing back in the thread from time to time. Also the wiki to explain the usage of the included patches would be useful although I still think that one is better of reading the corresponding patchthreads in order to get a better understanding of their functions (or limitations).

As for the binaries ... I have experienced very little to no whining about (windows) binaries not being provided fast enough. The biggest benefit that is see here, besides binaries for all supported platforms, is that I no longer have to check for missing files or included GRFs(*) that should not be there.

All in all I have known of the benefits of using a proper version control system all along but I was comfortably used to svn and doing things the hard way.



(*)
Speaking of GRFs that should not be distributed ... I will have to pull someones ear for posting a s**tload of them without liscences. I will get to that when I will be replying to all of them unanswered posts.

[Michi_cc]

If it does too than that is great and my problem is solved except for the fact that I have to be able to pull a complete patch from my source(s) as I prefer one blob of code to review my code and search for errors. I should still have some PM's explaining the methods for both GIT and HG (I never delete PM's and I still have lots of free slots for more to be preserved), else there is still google.
Thank you for explaining

git diff origin..master will give you a single diff for all changes that are on the branch master and not on the origin branch (you might need to change the branch names depending on your setup).

I believe that GIT (¿since recently?) has the option (¿extension?) to have some sort of HG patchqueue system, while HG has the pbranch extension to have GIT style branches.
I would like to combine both (git like)branches and HG MQ's as both are equally useful, this is most likely possible but I did not get that far yet.

The complete equivalent to a HG patch queue would be quilt. Personally I see no reason to use external tools for that as git rebase --interactive can do everything with commits that you'd want to do. Modify a commit, change a commit message, reorder or squash two commits, all there. Additionally making use of the staging area (index) coupled with selective staging using git add --interactive (or much easier with git citool, just right click on a diff line to either stage that line or the whole diff hunk) makes splitting patches into nice commits very easy. And you can always use rebase to make embarrassing mistakes disappear

PS: Watch the next nightly for a surprise feature

-- Michael Lutz

[kamnet]

I think both starting over with a new patch pack and using the co-op would be a great way to have a complete, clean break and do everything in an organized manner.

[Kraks]

Now finally, to solve those glitches when using OpenGFX 0.3.7, please find attached a patch that fixes the issue.
Old and new versions of the patchpack should and will most likely still be compatible in MP games.

I've applied patch to the patchpack with russian translation (see this post) and compiled it for Win32:

chipp_v13_5_r22554_OGFX_Fix_ru_win32.rar

Win32 binaries (chipp+ru_transl+OGFX-Fix)

(4.84 MiB) Downloaded 227 times

chipp_v13_5_r22554_OGFX_Fix_ru_src.7z

chipp+ru_transl+OGFX-Fix sources

(5.01 MiB) Downloaded 109 times

chipp_v13_5_r22554_OGFX_Fix_ru_patch.rar

chipp+ru_transl+OGFX-Fix patch

(287.89 KiB) Downloaded 102 times

* "ru" in file names means that this version includes also russian translation. Other languages are present as they were in original patchpack v13.5