Chill's patchpack v14_7

[Dwight_K._Schrute]

Oh Thank you for this version ChillCore. ie for the trafficlights and the town growth patch

Here's a binary, the patch I've used and the buildlog

[Sensation Lover]

Yes, Thank you very much! BTW i tried to compile a binary but didn't make it. when i tried the last command line "make --without-lzma" it didn't generate the exe file in the bin folder...

[ChillCore]

Oh Thank you for this version ChillCore. ie for the trafficlights and the town growth patch

Here's a binary, the patch I've used and the buildlog

Thank you Dwight_K._Schrute for the binary and the buildlog.

For the (many) warnings coming from town.h line 242 ... this change should solve them.

Code: Select all

-		if (larger_town) default_growth_rate / 2;
+		if (larger_town) default_growth_rate /= 2;

My fault ... typo that was not present in the original patch.
The only side effect will be that in larger towns the default rate is not devided by two and they will be treated the same as small towns. Nothing critical wil happen, I hope. Strange that gcc throws no warning about that.

Checking the warnings coming from CargoDist (cargopacket.h and .cpp) will take a bit longer ... It could be present in the official CagoDist patch maybe not. As I do not get those warnings, me checking CargoDist alone is no use ... Could you check please, if you find some time? If they are there too then i do not have to compare diffs, saving me some time.
I will post an updated patch when I have found the cause of the warnings.

Yes, Thank you very much! BTW i tried to compile a binary but didn't make it. when i tried the last command line "make --without-lzma" it didn't generate the exe file in the bin folder...

I have not yet tried to compile this version without lzma. I did with a previous version not so long ago but I made some changes since then. Will check in a bit to see if I can reproduce on Ubuntu.
Thank you for reporting. Can you tell me what the error message was/is, please?

[Yexo]

"make --without-lzma" won't work at all. Before you execute "make" you'll have to configure first. Try "./configure --without-lzma && make".

[Sensation Lover]

"make --without-lzma" won't work at all. Before you execute "make" you'll have to configure first. Try "./configure --without-lzma && make".

i'll try that. thank you. I followed the instructions on wiki, but the step you said is not present

[Yexo]

Which instructions did you follow exactly? Please link to the exact wiki page.

[Sensation Lover]

Which instructions did you follow exactly? Please link to the exact wiki page.

this ones. http://wiki.openttd.org/Compiling_on_MinGW
i only didn't compile the part with "libicu", all the rest was done exactly the same, and 2 times.

[of_darkness]

Whats upp with the train length setting? i cant build 99cars long trains WITH!!!!! 64 tiles(rutor in Swedish as my openttd is Swedish) tl setting, only 64 cars long trains is accepted. is it some change in trunk or a bug or?

[NekoMaster]

Whats upp with the train length setting? i cant build 99cars long trains WITH!!!!! 64 tiles(rutor in Swedish as my openttd is Swedish) tl setting, only 64 cars long trains is accepted. is it some change in trunk or a bug or?

Actually, its been changed to count the number of tiles long your train is, this is I guess 1) to make making consists easier and 2) so you don't go over your station length limit.

[ChillCore]

As NekoMaster said, recent-ish codechange in trunk.

i cant build 99cars long trains WITH!!!!! 64 tiles

The number next to the train in the depot is the number of tiles and not wagons.
The number of wagons you can attach depends of the lenght of those wagons, 128 wagons if two wagons are exactly 1 tile long, more if they are shorter less if they are longer ...

[ChillCore]

In reply to vanished post by of_darkness ... ... and for everybody else that has the trainlenght problem.

Have you changed the Advanced Setting after loading your savegame? Default is 7 and it is set at that value for existing savegames that did not yet have the setting saved before. (All patchpack savegames before v12.)
Changes made from the main menu only count for new games and do not affect savegames. (-> For settings that are saved that is.)

You can find it here Vehicles -> Trains -> Maximum lenght of trains. (Just for people new to the setting.)


Edit:
Post recovered from browser memory.

Well as i opened a depot in an existing game and cloned a existing max length train i cant move wagons in it as it says they are longer then normally.

Hehe, computers ...I guess what they say about the internet is true ... if you post it, it is there forever

[of_darkness]

As NekoMaster said, recent-ish codechange in trunk.

i cant build 99cars long trains WITH!!!!! 64 tiles

The number next to the train in the depot is the number of tiles and not wagons.
The number of wagons you can attach depends of the lenght of those wagons, 128 wagons if two wagons are exactly 1 tile long, more if they are shorter less if they are longer ...

Hmm in further testing it seams that i was wrong when i thought my trains where shorter so... il maybe be swayed over to think its good change..

[Eddi]

The counter never counted cars. only half-tiles which incidentally works for default vehicles, but not for newgrf-provided vehicles.

[ffpp]

The counter never counted cars. only half-tiles which incidentally works for default vehicles, but not for newgrf-provided vehicles.

That is why it is so useful to see whether a train will still fit into a certain-length station. Counting the cars wouldn't help too much with that.

[AppeL]

when compiling with visual c++ i get an error. i attached the building log. anyone knows what i need to do?

i gathered it has something to do with music?
but i followed all the steps in the compiling tutorial to compile w/o music o_O

[ChillCore]

when compiling with visual c++ i get an error. i attached the building log. anyone knows what i need to do?

i gathered it has something to do with music?
but i followed all the steps in the compiling tutorial to compile w/o music o_O

..\src\music\dmusic.cpp(24) : fatal error C1083: Cannot open include file: 'dmksctrl.h': No such file or directory

dmksctrl.h is not part of OpenTTD.

Sounds like you forgot to do something.

Microsoft® DirectX SDK earlier than August 2007

Information: The DirectX SDK from November 2007 is the first one which supports Microsoft® Visual Studio 2008. But it's also the first version which doesn't support DirectMusic which is needed to compile OpenTTD. That is why we must copy the missing files from an older version, prefered the final one for DirectMusic: 'August 2007'.

* Extract (no double-click, do not install) dxsdk_aug2007.exe in an extra directory and you get a file called dxsdk_aug2007.exe (yes that's right, both files have the same name).
* Extract the second dxsdk_aug2007.exe in an extra directory.
* Now copy following 9 files from .\dxsdk_aug2007\dxsdk_aug2007\Include\ to <personal folder>\shared\include (note: Please update the paths as necessary):

* dls1.h
* dmdls.h
* dmerror.h
* dmksctrl.h
* dmplugin.h
* dmusbuff.h
* dmusicc.h
* dmusicf.h
* dmusici.h

Have you extracted the files and copied them to the correct location?

If that does not fix it someone else will have to help you as I am not familiar with Visual Studio.

[Rubidium]

I am still not comfortable with HG and patch queueing simply because I have not taken the time to read up and experiment with it.
I have not forgotten about that offer and I do appreciate it but somehow there is something that I do not like about working with HG or GIT ... can't put my finger on what exactly ... no longer having a clear overview of all changes at once and pulling patches from them are two of them ...

You could just make a (hg) repository with the patch and a little metadata; then #openttdcoop's server can automagically create a repository with that patch applied which can then be compiled by OpenTTD. An example of this are the 32bpp ez patches; see http://hg.openttdcoop.org/32bpp-ez-patc ... ce79e2c631 for the files that they distribute.

For your case one patch and the series files would probably be enough.

Note that I'm not that familiar with what is going on internally, but I reckon it would be relatively easy to get this started. After all, you're releasing patches already and putting those into a hg repository isn't the hardest thing in the world.

[AppeL]

i managed to compile now.

the towngroth requires goods thing is good, however, i have some questions:

what does "transported goods ratio" mean? i am transporting 3241 passengers (needed 536), 0 mail (89 needed) and 0 goods (178 needed)... how does that add up to 25%? o_O

also, it seems to me that the demand does not get multiplied by daylength factor. i am playing with daylength = 30. the above value of 536 passengers needed is from the option "hard" and the town population size is 3576... seeing that i am already doing 6 times the amount needed for the maximum growth on difficulty "hard", it either really does need some tuning or daylength is not accounted for? o_O

edit: i just tried it with daylength=1 and the values stay the same, so daylength is not accounted for in this patch. the "passengers last month" value obviously gets divided by 30, therefore i have 121 passengers, but 536 are needed for 100% growth on difficulty hard.
can i add in the daylength factor manually somewhere in the source or is it too complex?

also, how does this patch work in conjunction with FIRS? is it still just cargo class "goods" or does "food" (with FIRS GRF you can also deliver food to towns in temperate) count as "goods" aswell?

[NekoMaster]

If your going to play with longer days I'd suggestion upping the town cargo production setting so that the towns will produce more passengers and mail to compensate for the extended days

[AppeL]

If your going to play with longer days I'd suggestion upping the town cargo production setting so that the towns will produce more passengers and mail to compensate for the extended days

my problem is not, that it is too hard, but it is too easy...

the town cargo production goes up automatically with extended days (from 121 (daylength=1) to 3xxx (daylength=30))
the cargo needed does not go up by the factor 30 and stays at 500.. so while i only delievered 25% (actually this is where the 25% might come from in my above example.. it mistakenly calculates for daylength=1) of the needed amount in dl=1 (which is how it should be), i delievered 6 times as much the needed amount for daylength=30.

so what i am saying is, that the "cargo needed" value does not take into account that with daylength patch, one month is a lot longer and therefore i can deliver a lot more cargo in one month. therefore the cargo demand also needs to go up.