Gonozal_VIII patchpack r12180

[BR 155]

Sorry guys, I think a newer PaxDest with better performance has been released in between. This patchpack is amazing, maybe the best I've ever been playing , but it's not the newest one anymore.

[jaybud4]

Nowhere close to newest.
This is 12180, right?
..We're up to something like 128xx now, aren't we?

[Draakon]

Nowhere close to newest.
This is 12180, right?
..We're up to something like 128xx now, aren't we?

At the time of writing, the newest is r12882. And this patch pack needs a update.

[BlueEagle_nl]

If you agree, Gonozal, I can try to get the current version of your Patchpack up-to-date to current trunk, and include a Linux (at least Ubuntu/Debian compatible) build. It'll include the updates from YAPP and PaxDest to mention some in that case, and also Trunk will get a boost up to r12882. Just need your 'blessing' to try this out!

[planetmaker]

If you agree, Gonozal...

He hasn't been around for weeks, if not months.

[BlueEagle_nl]

Well, in that case I'll start working on it ASAP, but I'm not that good in coding in C++...
Also I can't build Win32 builds on my PC (running Ubuntu Hardy), so I really need one who can do that for me...

[Aphfaneire]

I would greatly appreciate any work you guys can do on improving this pack.

I cant wait! In the mean time ill keep trying to perfect PBS signals, im so used to the old ones that ive got several traffic jams where trains randomly stop and i dont know why. Its something to do with platforms being blocked and the size of junctions, but why its causing so much hassle is beyond me!

The reports of all the lost trains got so big that it was causing my game to crash! Every second the news was getting these reports, so much so that they wouldnt even pop up. Ive changed the settings, but i still have my signaling problems.

Why isnt there a wiki for PBS, im lost in trying to perfect it.

[PhilSophus]

Well, in that case I'll start working on it ASAP, but I'm not that good in coding in C++...

I suggest you take a look at Roest's patchpack and maybe join forces with him. His pack is up-to-date and contains a considerable amount of the patches that also were in this patchpack (esp. big ones like paxdest). You would save a lot of time by taking that as a basis (if Roest agrees, of course).

[Draakon]

Well, in that case I'll start working on it ASAP, but I'm not that good in coding in C++...

I suggest you take a look at Roest's patchpack and maybe join forces with him. His pack is up-to-date and contains a considerable amount of the patches that also were in this patchpack (esp. big ones like paxdest). You would save a lot of time by taking that as a basis (if Roest agrees, of course).

Not the enginepool.

[Roest]

Not the enginepool.

tough luck

[BlueEagle_nl]

Well, in that case I'll start working on it ASAP, but I'm not that good in coding in C++...

I suggest you take a look at Roest's patchpack and maybe join forces with him. His pack is up-to-date and contains a considerable amount of the patches that also were in this patchpack (esp. big ones like paxdest). You would save a lot of time by taking that as a basis (if Roest agrees, of course).

Well, Roest, do you agree when I start using your Patchpack as base for the new version of this pack? Or, let's state it a bit different: when we join forces to ie. build the biggest and handiest patchpack (well, too big gets not handy anymore...) for OTTD which can be found here?

[Alberth]

Imho the goal should be to reduce the size of the patchpack to 0, and put all stuff into trunk.

Alberth

[BlueEagle_nl]

That's indeed the main goal of all patches out here, but for now, that's not yet happening...

For now, I can't get PaxDest in, there's something wrong with the patch (something with ottdRectangle in station.cmd.cpp) which prevents OTTD from building. But, I'm trying to get all other patches in.

[Alberth]

That's indeed the main goal of all patches out here, but for now, that's not yet happening...

It is not ever going to happen by taking the direction you are going. To get things in trunk, patches need to be smaller, not bigger.

Constructing a patch-pack is good for testing and finding problems by play-testing. Maintaining a patch-pack for a longer time costs effort that is not spend in further development (that is, suppose you maintain it for a year. What progress have you made then after that time?). Also, there are only a few users that benefit from your efforts, since most players never play with a patch-pack.

For now, I can't get PaxDest in, there's something wrong with the patch (something with ottdRectangle in station.cmd.cpp) which prevents OTTD from building. But, I'm trying to get all other patches in.

What is wrong with this picture? "Hmm, it doesn't work. Ah wait, instead of solving, I add more complexity....."

Instead of walking around problems, why don't you try to solve them instead? Finding them is easy, solving them is the real challenge.

Sincerely,
Albert

[BlueEagle_nl]

@Alberth: I am trying to fix that, at least, I've asked Roest for an up-to-trunk version of the patch. This should fix that problem. For the time being, I'm not getting PaxDest in, also because I ain't that good in coding in C++... The troubles I have sometimes getting all the rejects passed, are already enormous sometimes...

So in the mean time I'll try to get all other patches in, and get them up and running, but PaxDest stays out-of-pack until the fix is found by either me, Roest or someone else.

[Alberth]

@Alberth: I am trying to fix that, at least, I've asked Roest for an up-to-trunk version of the patch. This should fix that problem.

In my view you are not fixing anything, you've passed on the problem to Roest.

In addition, you did not tell him what the cause of the problem was. Was it due to a change in trunk? Was it due to a change introduced by another patch you included? Was it a combination of both?

If you instead can tell him 'this and this had changed in that source, and I fixed it in this and this way, here's the fix', he can examine and take your fix and spend time on other problems.

For the time being, I'm not getting PaxDest in, also because I ain't that good in coding in C++...

If you want to do development in OpenTTD, start coding/debugging. It is not very realistic to expect that others will solve your merge problems for you.

The troubles I have sometimes getting all the rejects passed, are already enormous sometimes...

Getting big rejects is a sign that your patches get in each others way.
Do you verify correctness of the merges? 'merge ok' by a tool means it found a place to do its merge. That doesn't mean that the place it found was also the place intended by the patch author nor that the change does not interfere with other changes you merged earlier.

[PhilSophus]

I fully agree with Alberth.

@BlueEagle_nl:
When I suggested "joining forces with Roest" I didn't intend to say "do the easy work and push problems to Roest" but "don't do the work again that Roest already has done".

Not being good in C++ coding isn't something to be set in stone. But how do you want to improve if you give up on the slightest problem? From what I grasped, it isn't a hard problem you encountered, some identifiers renamed, pushed into a class or something like that. I don't want to put you down with that, but want to encourage you to try it yourself and learn from that.

On the other hand, starting with integrating a big patch pack maybe isn't the best thing for you. The real problems start when it merges, it compiles, but has strange (maybe even spurious) errors, you don't know which patch is responsible for. With all that patches from different areas of OpenTTD it may require a lot of knowledge on its internal workings to solve. So maybe starting maintaining a small abandoned patch and thereby learning about the area it deals with may be a better task to start with.

Of course, doing the laborious work of solving all these "simple" conflicts that occur when combining a lot of patches is also a valuable contribution I (and probably many others) appreciate a lot. I just wanted to give the food for thought that going a small step beyond one's own abilities is a way to learn.

[BlueEagle_nl]

@Alberth: I am trying to fix that, at least, I've asked Roest for an up-to-trunk version of the patch. This should fix that problem.

In my view you are not fixing anything, you've passed on the problem to Roest.

In addition, you did not tell him what the cause of the problem was. Was it due to a change in trunk? Was it due to a change introduced by another patch you included? Was it a combination of both?

If you instead can tell him 'this and this had changed in that source, and I fixed it in this and this way, here's the fix', he can examine and take your fix and spend time on other problems.

For the time being, I'm not getting PaxDest in, also because I ain't that good in coding in C++...

If you want to do development in OpenTTD, start coding/debugging. It is not very realistic to expect that others will solve your merge problems for you.

Sorry for my statement back there. Indeed, I've asked Roest for an up-to-trunk version of this patch, which is indeed not fixing the bug myself.

I tried renaming the ottdRectangle-definition to the Rect-definition used in other places, but some of its objects are also renamed, so I have to find a workaround for that. So, in that way I AM trying to fix the problem.

The troubles I have sometimes getting all the rejects passed, are already enormous sometimes...

Getting big rejects is a sign that your patches get in each others way.
Do you verify correctness of the merges? 'merge ok' by a tool means it found a place to do its merge. That doesn't mean that the place it found was also the place intended by the patch author nor that the change does not interfere with other changes you merged earlier.

I have verified correctness of merges each time I applied a new patch. I construct a new build each time I changed source, be it through a patch, or a manual edit to ie. move all non-trunk-patches to a new Patch Config tab, and test everything thoroughly.

@BlueEagle_nl:
When I suggested "joining forces with Roest" I didn't intend to say "do the easy work and push problems to Roest" but "don't do the work again that Roest already has done".

Like I mentioned before, I am trying to fix the problem, but I ran into some bigger issues which are beyond my knowledge, or which I can't find that easily...

Not being good in C++ coding isn't something to be set in stone. But how do you want to improve if you give up on the slightest problem? From what I grasped, it isn't a hard problem you encountered, some identifiers renamed, pushed into a class or something like that. I don't want to put you down with that, but want to encourage you to try it yourself and learn from that.

It's an Identifier which is renamed, but also lost some objects assigned to it...

On the other hand, starting with integrating a big patch pack maybe isn't the best thing for you. The real problems start when it merges, it compiles, but has strange (maybe even spurious) errors, you don't know which patch is responsible for. With all that patches from different areas of OpenTTD it may require a lot of knowledge on its internal workings to solve. So maybe starting maintaining a small abandoned patch and thereby learning about the area it deals with may be a better task to start with.

Each time I added a patch, I compile the new build and test all changes which are made. This way I can find which patch causes the problems which occur.

Of course, doing the laborious work of solving all these "simple" conflicts that occur when combining a lot of patches is also a valuable contribution I (and probably many others) appreciate a lot. I just wanted to give the food for thought that going a small step beyond one's own abilities is a way to learn.

Thanx, I'll take your advices (also of the others) and use them...