Starting a new patchpack

[ChillCore]

^^^^ thread title(*) to be changed in the future ... please read on in the second post.

Reserved for future use.


(*) and the rest of this post too ...

[ChillCore]

Let's say you decide to "restart" the patch pack. To get that off to a good start, you would select a bunch of patches to include,

There are many patches that I would like to have in (again) ... let's start small and see where we get instead of me giving the long list of included patches in my previous patchpack.

and integrate them into the current major trunk revision, which would be 1.2.0. For clarity reason, you would call it 1.2.0 as well. Once it is stable, the features are frozen, which means that no new features will be added in any of the patches. The only development that will be going on in this branch, is bugfixing and compatibility fixing to the minor trunk releases, like the current 1.2.1.

Do we have to call it 1.2.x? I'd really rather not. I know that most people who venture into the Development forum are aware that they are not playing vanilla OpenTTD ... but still I'd rather avoid all and any confusion possible.

Simultaneously you have a second branch, lets say you start that at revision 1.2.50. That way the revision number clearly shows what's what. 1.2.<50 are "stable" releases correlating with the stable releases of mainstream OTTD and 1.2.>50 are the bleeding edge versions, which include the same bugfixes and compatibility fixes as the <50-revisions, but also get new features. This might create a bit of a work-overhead, as you have to back port all bugfixes from the >50 revisions to the <50 revisions, but you can always release a "stable" ChillPack!OTTD whenever OTTD releases a minor trunk release.
Those of a more adventurous disposition can meanwhile choose to plug the latest 50+ revision into an OTTD nightly. Inclusion of new patches into the pack would only happen in the 50+ revisions, keeping the 50- revisions stable. As I said, it is a wee bit more work than absolutely neccessary, but it will give the ChillPack users the option of playing a reasonably up-to-date version in comparison to the vanilla release.

I really like the idea of having two branches and I do not (yet) mind the work-overhead but can we please call them Some_Name_vx.x_rxxxxx and Some_Name_vx.x_rxxxxx-dev

The critical question is whether or not a 1.2.0 based ChillPack will be stable before the "trunkies" release 1.3.0. If not, it would make sense to start development at the current trunk-nightly and have no stable release.

Indeed current trunk is as good a starting point as any.

The first stable one would then be ChillPack 1.3.0.

That would only be by april next year but I do not mind that fact

On a technical level I would suggest to depart from the monolithic patch approach. I would suggest to keep each patch seperate.

Great idea.

That'll probably add a gazillion #ifdef's to the source, but it also allows to disable patches at source level (via ./configure parameter). That makes it easier to discontinue patches that are terminally broken or have found their way into the trunk. Imagine the trunk does some major changes to map handling, which would break the heightlevels patch. Instead of nerfing the whole patch pack, you could temporarily disable it via hardwired ./configure option. All other patches in the nightly would still work and those, who want the heighlevels patch can revert back to the latest stable release. Once the heightlevel patch has been fixed, it can be re-enabled in the next nightly.

Can you please explain in more detail on how to disable patches at source level? I like the idea (I think) but I do not know how you would do that.

It has been suggested to me, some time ago, to let each patch have its own branch and merge them in a separate one ... this is not the same mechanism as you suggest is it?


Now some more concerns of mine ...
- You prefer using HG or GIT or something else; SVN is not an option is it ...(I am willing to learn something new if needed)?
- Can you create an account on the openttdcoop site please, that will allow us to be managers of the (new if you prefer but not really needed) patchpack repository both ... or did you have a different place in mind?
- When do you want to start? Many patches I would like to be included (again) need updating. I enjoy doing this very much (most of the times); I have been postponing this restart long enough now I think.
- Please realise that I made some commitments to my family members ... I am not going anywhere but I might be absent from time to time for a few days (that being my choice not theirs).
- How will we call this patchpack? If i were to do a new patchpack on my own I was going to call it "Chipp_Too" but since I am no longer alone suggestions are welcome ...

ps.
- These questions are not directed at Lukewolf alone ... anyone, feel free to give your 2cc.
- I am willing to let you have the first post on a new thread if you want in case you have more free time available than me and would prefer this (since recently only the first post can be adjusted forever instead of all posts)

[Alberth]

I would like it too if you use a different number than 1.2.x, to avoid confusion. People will forget about the "patchpack" suffix, and cause all kinds of confusion about versions.
May I suggest "chillpack 2012" instead as version?

As for ./configure enabling, I think he means you can say something like

Code: Select all

./configure --disable-foo

to disable the foo patch during compile.
It means that the patch has to be modified for each hunk (changes between two @@ lines) like

Code: Select all

.. // original unmodified source code
#if FOO_ENABLED
.. // modified lines for doing foo here (the '+' lines of the patch)
#else
.. // foo was disabled with ./configure, do what was here originally (the '-' lines of the patch)
#endif
.. // original unmodified source code

If another patch touches the same lines, it gets tricky though.

[Eddi]

Do we have to call it 1.2.x?

i strongly advise against that. when people come up and want support for "version 1.2.x", then we really don't want to be asking them "original or patchpack?". you should give completely different version numbers.

idea:
OpenTTD <X>PatchPack 2.x for the 1.2.x-based version
OpenTTD <X>PatchPack 3.x for the trunk (and later 1.3.x)-based version
OpenTTD <X>PatchPack 4.x for the future trunk (and later 1.4.x)-based version
etc.

(but that may still be too close to the original version)

That'll probably add a gazillion #ifdef's to the source, but it also allows to disable patches at source level (via ./configure parameter). That makes it easier to discontinue patches that are terminally broken or have found their way into the trunk. Imagine the trunk does some major changes to map handling, which would break the heightlevels patch. Instead of nerfing the whole patch pack, you could temporarily disable it via hardwired ./configure option. All other patches in the nightly would still work and those, who want the heighlevels patch can revert back to the latest stable release. Once the heightlevel patch has been fixed, it can be re-enabled in the next nightly.

Can you please explain in more detail on how to disable patches at source level? I like the idea (I think) but I do not know how you would do that.

i don't like the idea of #ifdef-ing large parts of the code. if you use a patch-queue or equivalent, then simply reverting the patch will do (unless you had special changes for merging two patches, but then it gets complicated either way)

It has been suggested to me, some time ago, to let each patch have its own branch and merge them in a separate one ... this is not the same mechanism as you suggest is it?

fonso has some rather complex git-based merging scheme for CargoDist, maybe he can give you some practical tips

[Lukenwolf]

Alberth has explained the disabling of patches at source level quite well. If you call ./configure with default options, by default all patches would be enabled, but people can disable certain patches or you may change the default for a patch from enabled to disabled, for instance if you know that a certain patch is currently broken by latest trunk changes. Later, when it has been adapted it can be re-enabled by default. That way you can temporaryly disable patches without having to remove them from the patch pack completely

I'll create a coop account tomorrow. I'm currently on a business trip, but I'll be back in my office tomorrow. I think coop is a good place to host it. I'll leave the choice between git and Mercurial to you. I'm familiar with both of them

I'm excited to get the show on the road

Cheers, Lukenwolf

[Terkhen]

#ifdefs have the disadvantage of altering the patches, making them unusable for future trunk inclusion and requiring further work whenever you want to add a new patch or, in some cases, changes in many patches if the hunks are nearby enough.

Mercurial patch queues are specially designed to deal with patches; they allow to develop each patch separately. As long as your patches don't alter the same part of the code twice, it is quite easy to remove one or more of them. It might get tricky in some cases, though.

Why is enabling/disabling each patch in the final build a necessity?

[Rubidium]

#ifdef-ing patches will increase the work significantly. Especially if patches depend on eachother.

For example you got a cargo d*st and a infrastructure sharing patch, then you end up with (eventually) 4 different binaries. As both patches depend on eachother, you can't simply test only the first or only the second, no you need to test all cases. This quickly spirals out of control and beyond management.

For example, occasionally e.g. non-network, builds are broken because one didn't consider those #ifdefs. Luckily there are no real interdependencies in the current dependencies/#ifdefs in OpenTTD so you usually get of by testing all enabled and all disabled.

Another issue is that some patches might depend on another patch to be present. This will then cause unneeded complexity in the configure script as it needs to test and warn/fail whenever some setting is not right. For example fontconfig without freetype (makes no sense to be able to choose fonts when you can't load them).

So I wouldn't even want to consider #ifdef-ing patches. It will end up as one big jungle of totally spaghetti.

[Lukenwolf]

That is quite a philosophical debate, really. #ifdef'ing individual patches would be the ideal situation, but in reality it will be a mix of patch-clusters that get either enabled or disabled. It will also boil down to which patch to include and the overall quality of the patches themselves. If the individual patch maintainers make their patches completely disable-able (is that a word ) source level triggering will not be neccessary.

[ChillCore]

If the individual patch maintainers make their patches completely disable-able (is that a word ) source level triggering will not be neccessary.

Most patches are written like that and if not we can make them to be that way before including them instead if #ifdef-ing?

[Lukenwolf]

Sounds like a plan

[planetmaker]

If the individual patch maintainers make their patches completely disable-able (is that a word ) source level triggering will not be neccessary.

Most patches are written like that and if not we can make them to be that way before including them instead if #ifdef-ing?

Adding a cfg or even adv. setting for each patch doesn't really change the complexity which you get with using #ifdef - you just replace the pre-processer #ifdef by a C/C++ if (condition) {

Of course config settings make sense for some. But e.g. for things like more heigth level changes or so?

[frosch]

Mercurial queues have a feature called "guards" which allows conditonal applying of patches. Maybe that is an option for you

http://hgbook.red-bean.com/read/advance ... l#id433787

[Ottomobeale]

>chillpack 2012
Two thumbs up for that name.

1) Daylength, even if it only goes up to a multiplier of 16 or so. (past 16 cities tend to close down houses etc)
2) XL maps. I dont intend to run an 8k x 8k but 8k x 512 sounds fun.
3) Cargodist. Including the ability to turn it off.
4) Some timetable separation patch, especially for trams.
5) Signals on tunnels and bridges

If I could request a patch that does not exist I would request one that at least somewhat more intelligently autoreplaces road vehicles with a defined replacement.
IE: If cargo = iron ore then use model 123 (set by user)
If cargo = passengers then use model 234 (set by user)
etc.
As it stands now if you autoreplace that early truck in the 1960s you get another early truck.

[Eddi]

1) Daylength, even if it only goes up to a multiplier of 16 or so. (past 16 cities tend to close down houses etc)
2) XL maps. I dont intend to run an 8k x 8k but 8k x 512 sounds fun.
3) Cargodist. Including the ability to turn it off.

these are fairly obvious choices

4) Some timetable separation patch, especially for trams.

i recommend "slim timetable separation" here, the other one has... issues... and is not very configurable.

5) Signals on tunnels and bridges

i would try "new map features" here, which does not contain signals on bridges yet, but may be extendible enough. the existing "signals on bridges and in tunnels" patch is IMHO a dead end.

there is also a similar approach by michi_cc which i only know under the working title "cool stuff", which achieves similar (or better) flexibility under the hood.

If I could request a patch that does not exist I would request one that at least somewhat more intelligently autoreplaces road vehicles with a defined replacement.
IE: If cargo = iron ore then use model 123 (set by user)
If cargo = passengers then use model 234 (set by user)
etc.
As it stands now if you autoreplace that early truck in the 1960s you get another early truck.

err, you realize that user-defined Autoreplace has been implemented years ago?

[FLHerne]

As a long(ish)-term user of ChillPP, I would consider CargoDist, infra-sharing, bridge/tunnel signals and some form of vehicle separation (personally, I think STS is better than the one you have now) to be absolutely essential, along with that one-line patch for blocking extra windows when ctrl-cloning .
More heightlevels is awesome for mountainous regions, whereas I've never managed to serve much of the huge maps.
Departure board, traffic-lights etc are shiny, but hardly a central part of the game.

I'm glad that you're updating this pack - I started working on my own after Grf-v8 got common, but that just proved to me how hard it actually is . Thanks for keeping this one working!

[Lordmwa]

SLS is great and all but when you have large networks the click and forget functionality is incredbibly useful!

[Eddi]

we discussed that already extensively...

[FLHerne]

STS is great and all but when you have large networks the click and forget functionality is incredbibly useful

My main gripe with ATS is its tendency to react to a delay by slowing everything down, which then causes long dwell times and blocks other services, which then get slowed down themselves...and before you know it there are month-long dwell times everywhere . STS doesn't seem to do that as much, for which I'm willing to sacrifice a couple of minutes of my time . 'Better' is of course entirely subjective .

we discussed that already extensively...

Ah well.

[cirdan]

5) Signals on tunnels and bridges

i would try "new map features" here, which does not contain signals on bridges yet, but may be extendible enough. the existing "signals on bridges and in tunnels" patch is IMHO a dead end.

Since you mention my patch...

Adding the "new map features" patch into a patchpack should not be done lightly. It is very large and invasive, and is likely to interfere heavily with anything that touches the map array, the pathfinders or the vehicle controllers, and to a lesser extent with many other things.

That being said, if you are up for a challenge, it does open up new possibilities (no real implementation so far) for signals on bridges, since the new map array reserves two bits on every tile which can be bridged over for that purpose. So an adaptation of the signals-on-bridges patch to work on top of the new map array would be less hackish.

If you decide to include my patch in the pack, you can certainly count on my help to integrate it.

[ChillCore]

Hello Cirdan,
Sorry to say that I did not find the time yet to examine/test your patch queue ...

Just wanted to say that if you want to join in the effort of starting a new patchpack you are more than welcome.

Of course config settings make sense for some. But e.g. for things like more heigth level changes or so?

You mean just enable it (while saving the heighltevel information in 8-bits) and leave out all of the if-else stuff?

Mercurial queues have a feature called "guards" which allows conditonal applying of patches. Maybe that is an option for you

http://hgbook.red-bean.com/read/advance ... l#id433787

Thank you for that link. I'll have a good read in a bit.
There is much I do not yet know about HG ...



Please keep suggesting patches for inclusion. I will assemble a list of requested ones in the first post soon-ish.
No promises though that they will all be included.