Chill's patchpack v14_7

[ChillCore]

Maybe, Maybe not. Time will tell. I do not keep time, nor do I like Timeframes as rush-jobs are a guarantee for bugs with a Capital B.

I am still looking for that crash bugsie. And I have to check if I bumped correctly, I had to make quite some changes to keep the patchpack running and I still have the feeling I have forgotten something somewhere.

Two things I can tell you now ...
- The changes mentioned above to muzzy will not change much for the next release.
- I still do not know if I will keep the savegame compatibility with the previous version.

[Muzzly]

Added:
-----
- Max_grf_v0.2
- Company_profile_20363_v02 (Not yet tested and needs safer saving and loading code according to comments in the thread)

Wow, you have already added patches I was willing to add myself
Actually, there is already next version company_profile_v4_20441.patch http://www.tt-forums.net/viewtopic.php? ... 7&start=20

Because I was asking you already too often to add one or other patch. I was thinking to do it myself and post it here. How can I postmail it to you ? Is there some kind of private messaging in tt-forum ?

Thanks for adding max_grfs and company_profile patches !!!
Now I am thinking to make chill pathcpack 32bpp "compatible" !!! . There is already patch for 20445 http://www.tt-forums.net/viewtopic.php? ... &start=680 But I do not want to overflow you with work. I'll try to make it myself ( to patch on top of your patch ).

Sad side:
When I think about it, actually the work you are doing will be lost in let say half a year, if non of the patches will be included to trunk. It is a bit sad, that people are investing their time ( for coding or testing ) but nothing changes. For example MiniIN story. It was also like a big patchpack and what ...... now it is discontinued.

[Dewin]

I was willing to apply latest leasing patch myself, but is to difficult to patch already patched source.

I was trying to do this myself with mixed success.

If you're only trying to fix the 'cloned vehicles are leased' bug, the fix ends up being really simple:

1. Open src/vehicle_type.h
2. Locate the following near line 67.

Code: Select all

enum BuildCommand {
	BUILD_BUY           = (1 << 0), ///< Buy the vehicle
	BUILD_LEASE         = (1 << 1), ///< Lease the vehicle
	BUILD_COMMAND_MASK  = 0xF,
};

3. Change (1 << 1) to (1 << 3) on the BUILD_LEASE line.
4. Compile

[ChillCore]

Wow, you have already added patches I was willing to add myself

I have a cristal ball ...

Actually, there is already next version company_profile_v4_20441.patch http://www.tt-forums.net/viewtopic.php? ... 7&start=20

Cool will check it out in a bit.

Because I was asking you already too often to add one or other patch. I was thinking to do it myself and post it here. How can I postmail it to you ? Is there some kind of private messaging in tt-forum ?

There is a "PM", as in private message, button next to the profile button underneath each post someone makes.
You must be logged in to see it. Also a user can disable it if he wishes to do so.
You will be presented with an editbox similar to the postbox ... you can attach files to your PMs just like making posts ... just check it out ...
See your profile to configure if you want to receive an email if you have a private message and more.

Now I am thinking to make chill pathcpack 32bpp "compatible" !!! . There is already patch for 20445 http://www.tt-forums.net/viewtopic.php? ... &start=680 But I do not want to overflow you with work. I'll try to make it myself ( to patch on top of your patch ).

Wow, You mean "32bpp extra zoom" right, good luck with that one.
There are two reasons why I have not yet done so.
- The first is that when using 8bpp sprites there will be glitches. (This is why I would rather not include it for now ... Maybe you can update an older version that does not have this bug? Also someone stepped up recently and may be capable of fixing it ...)
- Secondly it will be a touch cookie in both viewport.cpp and smallmap_gui.cpp.
-- In vieport cpp you will have to merge with more height levels.
-- In smallmap_gui.cpp you will have to merge against more height levels and cargodist which have already been merged with each other in a few places ...

Don't let me stop you, it can be done but it will be hard work.

Sad side:
When I think about it, actually the work you are doing will be lost in let say half a year, if non of the patches will be included to trunk. It is a bit sad, that people are investing their time ( for coding or testing ) but nothing changes. For example MiniIN story. It was also like a big patchpack and what ...... now it is discontinued.

There is nothing sad about it. It is a fact of life.
I knew that before I started. So did the MiniIn guys. So does anybody who starts making a patchpack.

There is a positive side too. For example the bug in Cargodist with the waypoint orders did not show with Cargodist alone. Yet it was there and a combination of patches made the patchpack crash and revealed them ...

As I said single patches are included in trunk if finished like they should. Having them in a patchpack does not change that in any way.

[michielh]

I just wanted to say how much I appreciate your patchpack, ChillCore! I've been playing it for a few weeks and it works fine. Only had some problems with removing signs on bridges, but I've read that has been solved already.

Just a shame the automated seperation patch isn't working properly with waypoints. I usually build big passenger networks, with intercity's and so on, but the stations are getting way to big if I can't send a small train to a small platform. I hope that's going to be fixed sometime.

[broodje]

In my opinion the problem lies partly in the main branch. Why should waypoints (or any 'via' destinations) be timetabled? I think they shouldn't count as timing point in the timetable at all, you can't halt trains at 'via' destinations after all.

[Rubidium]

Why should waypoints (or any 'via' destinations) be timetabled?

Because that happens in the real world as well, e.g. the Shinkansens that pass through a station without stopping (effectively "via") are scheduled as can be seen in http://www.youtube.com/watch?v=6IJtlkCVkSg where you'll notice the driver saying it passes the stations on schedule.

[broodje]

Ah, but a dev that I know once told us that OpenTTD doesn't replicate real life (TM) .
All fun apart, I know Junctions are used as timetabling points in real life, but what use does it have in OpenTTD? If a train is running early or late the program can't do anything about that until it has stopped at a station.

[FooBar]

but what use does it have in OpenTTD?

It could be used to see gathered delay on the track section /before/ the waypoint, or /after/ the waypoint and by that give you directions where to improve your network.

There might be more reasons to have it and even the majority of people might not use it. A buggy patch[0] should never be a reason to remove a feature from trunk.


[0]IMO it is buggy as it does not work with all possibilities of trunk. I'm also rather certain that there's one way or another to change the patch and make it fully functional with all features of trunk.

[Dante123]

Why should waypoints (or any 'via' destinations) be timetabled?

Because that happens in the real world as well, e.g. the Shinkansens that pass through a station without stopping (effectively "via") are scheduled as can be seen in http://www.youtube.com/watch?v=6IJtlkCVkSg where you'll notice the driver saying it passes the stations on schedule.

this reminds me, i still need to upload my personal vids of the Shinkansens

[ChillCore]

I just wanted to say how much I appreciate your patchpack, ChillCore! I've been playing it for a few weeks and it works fine. Only had some problems with removing signs on bridges, but I've read that has been solved already.

Just a shame the automated seperation patch isn't working properly with waypoints. I usually build big passenger networks, with intercity's and so on, but the stations are getting way to big if I can't send a small train to a small platform. I hope that's going to be fixed sometime.

Thank you for the kind words.

Yeah it is a shame that it does not work properly yet.

Maybe you can replace your waypoints by station tiles and use non-stop via orders.
Note: I have not tried this yet and do not know how the seperation will be affected or how cargodist will react.

Another possible solution is not using waypoint but modifying your config file.
- yapf.rail_longer_platform_penalty = 800 (increase by factor 5 or someting)
- yapf.rail_longer_platform_per_tile_penalty = 0 (set to some high value)
- yapf.rail_shorter_platform_penalty = 4000 (increase by factor 5 or something)
- yapf.rail_shorter_platform_per_tile_penalty = 0 (set to some high value)
Note: You may have to fiddle a bit until it behaves as you want. I have tried this some long time ago and it works but your trains may be waiting for the platform to clear instead of taking eg. a free but longer platform.

[0]IMO it is buggy as it does not work with all possibilities of trunk. I'm also rather certain that there's one way or another to change the patch and make it fully functional with all features of trunk.

I agree with you on this one.
Waypoints should be ignored in regards of separating trains.
Maybe the time travelled before and after the waypoint should be added and the result used for separating the trains. Which brings us to the next problem. What if two or more waypoint orders folllow each other in the order list ... The middle part should not be counted twice.
Solving it properly may not be as easy as it sound.
Disclaimer: I have not yet studied the patch long enough to know what to change where or how it works exactly ...

[Eddi]

In my opinion the problem lies partly in the main branch. Why should waypoints (or any 'via' destinations) be timetabled? I think they shouldn't count as timing point in the timetable at all, you can't halt trains at 'via' destinations after all.

just because you see no use for something, doesn't mean it isn't useful.

for example you could have a junction where you need to know the order that the trains come through. there you can set a waypoint, timetable all trains, and check the waypoint's timetable [not yet implemented in trunk, but ITiM had that feature]. Same holds for checking when an express train is scheduled at an intermediate station, to know when to hold back a slower freight or passenger train, for easier overtaking.

[broodje]

@eddi, I have a feeling the timetabling system might need some improvement then before your example works. At the moment you have to watch timetables to much to use them. As soon as I remove a single piece of track, or change a signal, the train waiting for my reconstruction becomes 'late' and it is rather hard to fix that without having a whole lot of slack in the timetable (which makes trains pass a junction in the correct order rather a hit or miss affair, instead of a certain way to control your trains)

Anyway, enough bitching about the current implementation of timetables, I guess the auto separation patch should just try to add up the time before and after the waypoint to get a proper separation. I hope something like that would work, you almost double the capacity of your 'realistic' junctions with it as trains won't pile up behind each other.

[Dante123]

cant wait for the new version of the patch that leasing error when cloning is pretty annoying in the current version hahah.

some other bug that i noticed:
when you terraform land, but you dont have the money for the current operation, the land does get brown as when it is changed, but nothing happens.
this also happens on water tiles, and thus the cost for raising dry brown land is cheap, but water aint cheap.

[ChillCore]

cant wait for the new version of the patch that leasing error when cloning is pretty annoying in the current version hahah.

Attached is what I have so far.
I just found the solution to how to prevent the game crashing when opening the "signal program gui" after bumping beyond r20450(+) about ten minutes ago.

some other bug that i noticed:
when you terraform land, but you dont have the money for the current operation, the land does get brown as when it is changed, but nothing happens.
this also happens on water tiles, and thus the cost for raising dry brown land is cheap, but water aint cheap.

That comes from the more height levels patch. Please see the first post that I have edited some time ago or read the logfile that can be found in the more height levels patch thread.
This is a unfinished part of the patch. I can not code and test at the same time. Lately I have been having my hands full of just keeping up with trunk ...

Also your statements "water aint cheap" and "when you do not have the money" seem to be fighting with eachother.
If you do not have the money. Nothing should happen besides being given a warning text that your pockets are empty.



Updated:
-------
- Leasing patch updated to v3_r20424
- Moreheightlevels updated to 27_10_r20481 (Will be posted in a bit ...)
- Cargodist updated to r20479

Added:
-----
- Max_grf_v0.2
- Company_profile_20363_v02

Changed:
-------
max station grfs = 64

Please report if the game crashes due to opening a new window.
Also little warning note: If you want to bump to trunk good luck with keeping the split_refit patch going, I messed up a bit when trying and did not manage to do so yet.

Edit: Not savegame compatible with previous versions.
Edit2: Buggy in the buy stations gui (rail_gui.cpp) and maybe a few other places. v9_6 is posted on the next page, it should be much more stable.

[Dante123]

can someone compile that version ?

Also your statements "water aint cheap" and "when you do not have the money" seem to be fighting with eachother.
If you do not have the money. Nothing should happen besides being given a warning text that your pockets are empty.

this is what i mean:
http://www.youtube.com/watch?v=oHDsa1NzyUo
(best to be viewed in HD)

[ChillCore]

As I mentioned the bug is known and written down in the first post, beneath known bugs there is a section dedicated to more height levels bugs.

If you do not have enough money to complete the teraforming command the entire terraforming command will fail.
That part works correctly as you can see that sometimes it fails (not enough money) and sometimes you can raise tiles (enough money).

The first bug is that if you do not have enough money the land is cleared <- this does not cost money as afterwards you could still rise single tiles ...
The second bug with this is that you are not given a warning that you do not have the money to complete the terraforming.

The solution is to give a warning that there is not enough money before clearing the tiles and aborting before clearing the tiles.
Clearing tiles, the brown tiles you see, is done before terraforming and is normal behaviour. I have been looking at it before but did not get to solving it properly yet ...

[Scautura]

And as requested, one (so far untested) binary (diff included for posterity):

Or not, the binary bundle is too large (MingW/MSYS unstripped - 4.5Mb) - would anybody have any concerns if it's hosted on my own server?

Removed due to issues.

[Dante123]

thank you thank you!
i wanted to compile myself, but the wiki is outdated so i cant even get the mingw working -.-

is this one modded some more by you ? or is this the chill's patchpack from his last post ?

[Lord Aro]

but the wiki is outdated so i cant even get the mingw working -.-

it isn't the wiki that's outdated, it's the fact that one of the packages (zlib1.2.3) doesn't work anymore.
i believe that an updated version is being worked on (by me if no one else )