Transport Tycoon Forums

Posted: **30 Dec 2010 17:38**

Attached is an early new years gift, hopefully fixing a few bugs.

It seems that I managed to fix the highlighting problem with copypaste in a somewhat acceptable way, at least I hope so.
It required some nudging and bumping in tilehighlight_type.h but it is working again. (-> half like before

)
The only downside of getting it to work again is that when using the terraform tools you first have to click somewhere on the map before the higlighting of that tool kicks into action. If you hold shift while doing so you wil get a cost estimate and you do not accidently raise the wrong tile.

Also some changes in trunk have fixed the issues with the BR420 and the ICE3 from the DB set it seems.

Updated:
- Cargodist to r21642
- Partial refit patch reduced to the select all vehicles button. (Trunk in r21567)

Changed:
- When vehicle income is too low to display due to the daylength factor pay 1.
- Adjusted CopyPaste to trunk. (exept for the TILE_LOOP.)
- Adjusted Wallclock (departures gui patch) to trunk. (strgen_tables.h, strings.cpp)
- Adjusted measurements tools to trunk.
- Maybe adjusted another patch to trunk along the way that I forgot to mention ...

Todo:
- Fix saving copypaste templates. (If you try the game will crash!)
- As advanced maths is beyond me, and I have to study the code provided by Alberth some more before understanding how it works exactly, I still have to implement the fractional vehicle income. (See a few post back.)

To test:
Please test everything related to tilehighlighting, I think I tested about everything from buying rails to funding new towns but I might have missed something.

Remember to keep backups, also when creating scenarios, you never know when the reduce to 0 bytes bug might strike again. I have tried saving over and over again yesterday but I could not reproduce it and I still do not know what is the cause of it happening sometimes.

Enjoy.

Posted: **30 Dec 2010 18:20**

Thank you for this new version Chill

You might be interested in adding this new patch: http://www.tt-forums.net/viewtopic.php?f=33&t=52085

And what about the town growth patch you mentioned a few posts earlier? If it is the same one like in the French Version (HFR 2.0) it's actually fun to play with. Really challenging....

Anyway... thank you again.. I really appreciate all your work

Posted: **30 Dec 2010 18:44**

Dwight_K._Schrute wrote:Thank you for this new version Chill

You might be interested in adding this new patch: http://www.tt-forums.net/viewtopic.php?f=33&t=52085

And what about the town growth patch you mentioned a few posts earlier? If it is the same one like in the French Version (HFR 2.0) it's actually fun to play with. Really challenging....

Anyway... thank you again.. I really appreciate all your work

Hey, this seems like a pretty cool patch, if it works with this patch pack that would be great

In the mean time you can just use nutracks to keep all trains on freight routes at a certain top speed

Posted: **30 Dec 2010 18:56**

Dwight_K._Schrute wrote: Thank you for this new version Chill

My pleasure.

You might be interested in adding this new patch: http://www.tt-forums.net/viewtopic.php?f=33&t=52085

If it does as promised it seems like a nice little patch yes. It does not need many, if any, adjustments for inclusion neither. (Just a bit of codingstyle.)
Only thing that I am worried about a litlle bit (without actually testing) is the CPU usage with large networks ... but there is an on/off switch so that should be OK.
I will test soon to see wat gives.

And what about the town growth patch you mentioned a few posts earlier? If it is the same one like in the French Version (HFR 2.0) it's actually fun to play with. Really challenging....

I do not know what patch dkarn has used, there have been quite a few town growth patches and maybe he wrote it himself.
I do not doubt that it is fun to use, if you like suuch challenges, but if you want me to include it I will need the patch first.
Also do you not find that the towns grow to fast? When I glanced through the code dkarn removed the adjustments according to daylength in the patchpack ...

Anyway... thank you again.. I really appreciate all your work

This time it required some 'sweat' ...
I really hope I did not miss something and that this version is stable enough with all those changes in the code everywhere.

NekoMaster wrote: Hey, this seems like a pretty cool patch, if it works with this patch pack that would be great

As I mentioned to Dwight, it would be easy to implement but I first want to test it on a large game with many vehicles.
Also, did you get to test Rubidium's patch for the vehicle acceleration yet? http://www.tt-forums.net/viewtopic.php? ... 6&start=58

Posted: **30 Dec 2010 18:58**

ChillCore wrote:People will notice if payment is not consistent. Imagine a group of 4 identical vehicles. All are waiting for full load and travel along the same route.
How do you explain that two are making a profit and two are not?

The same problem arises when you have two vehicles going 10 tiles at the same speed (no delays etc), one with 1 passenger and the other with 20 passengers.
Both are paid 1 pound... How do we explain this?

As a businessman i would then prefer a vehicle with less cargo space than another vehicle with more cargo space as i can get a marginally higher profit if a transfer less passengers at a time.
And with the GRF's i use there are vehicles that increase capacity and still have the same travel speeds. Upgrading to those will see me lose profit even when i transport more passengers.

I prefer the "less than a pound" idea presented above.

Posted: **30 Dec 2010 19:27**

I understand and agree Cadde, but as I mentioned before I quit shool way too early. I was 15 when I quit thus advanced maths is beyond me and I do not understand bitshifting yet.

If you can make heads or tails from what Alberth explained(*) feel free to implement it(**) and I will be happy to include it in the patchpack.
If not you will have to be patient untill I understand a bit better. If I left it as was, as a businessman, you would get nothing at all with very high daylength settings.

(*) It does not sound complicated but when I look at the code in industry_cmd.cpp it confuses the hell out of me (for the moment).
(**) Search for _date_daylength_factor in economy.cpp (2x in 'void CargoPayment::PayFinalDelivery' and 2x in 'Money CargoPayment::PayTransfer')

Posted: **30 Dec 2010 19:51**

ChillCore wrote:... I was 15 when I quit thus advanced maths is beyond me and I do not understand bitshifting yet.

That's good then. I'm 15 and i don't understand bitshifting and >> either yet

On a side note, and i don't wish to be rude, but i personally think you should concentrating on getting more height levels in trunk before 1.1 gets split off rather than your (still awesome) patchpack. IMHO, it would be more useful...

Posted: **30 Dec 2010 20:43**

ChillCore wrote:I understand and agree Cadde, but as I mentioned before I quit shool way too early. I was 15 when I quit thus advanced maths is beyond me and I do not understand bitshifting yet.

If you can make heads or tails from what Alberth explained(*) feel free to implement it(**) and I will be happy to include it in the patchpack.
If not you will have to be patient untill I understand a bit better. If I left it as was, as a businessman, you would get nothing at all with very high daylength settings.

(*) It does not sound complicated but when I look at the code in industry_cmd.cpp it confuses the hell out of me (for the moment).
(**) Search for _date_daylength_factor in economy.cpp (2x in 'void CargoPayment::PayFinalDelivery' and 2x in 'Money CargoPayment::PayTransfer')

Simply put... If you have the value PI (3.14...) and you want to present it without using a float...

x = 210,767 (That's a DWORD, 32 bits of unsigned INT)

When you left-shift it 16 bits you essentially take the value of the 16 bit integer to the left. In other words...

x = 210,767 << 16
is the same as
x = 3

In the binary world:

0000 0000 0000 0011 || 0011 0111 0100 1111
where "||" represents the 16 bit boundary.
"<< 16" in effects means "flush" the 16 bits to the right into the void. Thus we are left with a 16 bit representation of an integer with the value 3

0000 0000 0000 0011 || 0011 0111 0100 1111 << 16
0000 0000 0000 0011 || xxxx xxxx xxxx xxxx = 3

If you want the fraction you right-shift it 16 bits so you take the value of the 16 bit integer to the right.

y = 210,767 >> 16
is the same as
y = 14159
or...
0000 0000 0000 0011 || 0011 0111 0100 1111 >> 16
xxxx xxxx xxxx xxxx || 0011 0111 0100 1111 = 14159

If you combine the two variables (X and Y) you can print the floating point value.

Code: Select all

a = 210,767
x = a << 16;
y = a >> 16;
char floating[10];
sprintf(floating, "%d.%d", x, y);

Which would give the result "3.14159"

All you need to be concerned with is...

If you want to add 1 to the variable "a" then you do "a += 1<<16" and to subtract you do "a -= 1<<16".
If you want to divide the fraction by 2 you would do "a -= ((a>>16) / 2)>>16"

Unless i got that part horribly wrong, doing this in my head now...

And a quick google turned up this which might be more helpful: http://en.wikipedia.org/wiki/Arithmetic_shift

EDIT: Messed up my original post. Left and right shift wordings are now in their correct places...

Posted: **30 Dec 2010 20:56**

I'm really not convinced about some of the maths and code I see in your explanation Cadde.

Firstly left shift is << and right shift is >>.

Code: Select all

a = 210,767
x = a << 16;
y = a >> 16;
char floating[10];
sprintf(floating, "%d.%d", x, y);

Will not give the result you intend, for several reasons.

Pi in 16-bit offset fixed point is 20861.
You can't use that method to print the fractional part of a fixed point number.

If you want to divide the fraction by 2 you would do "a -= ((a>>16) / 2)>>16"

That's wrong, division and multiplication by a constant are the same in fixed point as with integers.

Without wanting to sound brusque, you need to look up what fixed point is yourself before you try to explain it to someone else.

Posted: **30 Dec 2010 21:26**

JGR wrote:I'm really not convinced about some of the maths and code I see in your explanation Cadde.

Firstly left shift is << and right shift is >>.
Code: Select all
a = 210,767
x = a << 16;
y = a >> 16;
char floating[10];
sprintf(floating, "%d.%d", x, y);
Will not give the result you intend, for several reasons.

Pi in 16-bit offset fixed point is 20861.
You can't use that method to print the fractional part of a fixed point number.

If you want to divide the fraction by 2 you would do "a -= ((a>>16) / 2)>>16"
That's wrong, division and multiplication by a constant are the same in fixed point as with integers.

Without wanting to sound brusque, you need to look up what fixed point is yourself before you try to explain it to someone else.

Hardly tried to explain fixed point. the main goal was to explain how arthimetric bit shifting works.
Further more, no matter how i twist and turn it with shifting i can't turn 20861 into 3.14159 so i can only deduce we are talking about two different things here and if you look back a page i went by what Alberth posted.
Also note i wanted to divide the fractional part of the number, not the whole number...

If you have an explanation on how you think it works then please share or link a page of relevance.

EDIT: Oh, just realized i got confused in my explanation. Indeed you are correct that << is left shift and >> is right shift but i reconstructed my entire post while i was typing it and thus forgot to change the left/right shift words.

Posted: **31 Dec 2010 09:27**

ChillCore wrote:

Can you please point me to the versions you are using for the Canadian trainset and the Canadian station set so I can test again with the same versions you have.

Hello, here they are. In my game the crash usually happens a few days after the start.

Posted: **31 Dec 2010 12:56**

Cadde wrote:Hardly tried to explain fixed point. the main goal was to explain how arthimetric bit shifting works.
Further more, no matter how i twist and turn it with shifting i can't turn 20861 into 3.14159 so i can only deduce we are talking about two different things here and if you look back a page i went by what Alberth posted.
Also note i wanted to divide the fractional part of the number, not the whole number...

If you have an explanation on how you think it works then please share or link a page of relevance.

EDIT: Oh, just realized i got confused in my explanation. Indeed you are correct that << is left shift and >> is right shift but i reconstructed my entire post while i was typing it and thus forgot to change the left/right shift words.

I made a mistake in my post, apologies, it's actually: 205887.

You need to remember that in fixed point, the fractional part is a binary one, not a decimal one.
ie.
0 0 0 0 | 0 0 0 0
8 4 2 1 | 1/2 1/4 1/8 1/16
If you intend to convert it to a decimal representation, you need to do some adjustment.
Along the lines of:
a = 205887
x = a >> 16;
y = a & 0xFFFF;
char floating[7+precision];
sprintf(floating, "%d.%d", x, y*10^precision/2^16);

As for bit-shifting, best forget about fixed point for that, and just think about integer division or multiplication by powers of two.
ie. 21<<1=42 010101<<1=101010
21>>1=10 010101>>1=001010

To avoid all this off-topicness.
@Chrill I take it that 11.6 will be savegame compatible with 11.3? (Save me downloading it on this slow connection if not...)

Posted: **31 Dec 2010 13:54**

Lord Aro wrote:
ChillCore wrote: ... I was 15 when I quit thus advanced maths is beyond me and I do not understand bitshifting yet.
That's good then. I'm 15 and i don't understand bitshifting and >> either yet

Stay in shool my friend and you will.

Lord Aro wrote: On a side note, and i don't wish to be rude, but i personally think you should concentrating on getting more height levels in trunk before 1.1 gets split off rather than your (still awesome) patchpack. IMHO, it would be more useful...

What remains to be done is fiddling here and there. eg. for the smallmap colours I need to change a few colours, recompile, check if they fit, adjust, recompile rince, repeat (many times).
Some other parts eg. the missing warning when resizing a heightmap too much (and resulting crash afterwards) is puzzling me as in the scenario editor it works as it should.

In it's "small_patches" form it becomes hard to see what is where ... there are normal patches and helper patches and so on. It is hard splitting up such a big patch in logical pieces that can be applied on top of each other while keeping code functional between applying them. Almost everything depends so heavily on other things ... but it has to be done if we want Devs to keep their sanity when reviewing the patch.
I have not given up, do not worry. This patchpack is a major playtesting round, although it became bigger than I intended at first, thanks to the many feedback and help I received along the way. Maintaining the patchpack forces me to look at things I would not look at if I would remain fixed on the more height levels patch alone.

I might try again using GIT or HG ...

Also 1.1.0 is already branched from trunk ... inclusion in a stable release is not my goal, trunk is and then it will get in a stable release automagically.

Cadde & JGR wrote: ... bitshifting ...

Thank you for the link and the explanations.
I have been reading a bit at the other end of the link already ...

I also had a nice PM and I am starting to see te light.

dimon22_g wrote:
ChillCore wrote: Can you please point me to the versions you are using for the Canadian trainset and the Canadian station set so I can test again with the same versions you have.
Hello, here they are. In my game the crash usually happens a few days after the start.

Thank you. I will try again in a bit.

JGR wrote: @Chrill I take it that 11.6 will be savegame compatible with 11.3? (Save me downloading it on this slow connection if not...)

It is, my own longlasting savegame is started with somewhere around v10.
Best thing is to keep your last savegame, rename it to include "v11_3" and keep that as a backup somewhere. If then it happens that there is something fundamentally flawed in the new version you can go back to the previous using your backup.

I am planning on breaking it but I did not yet take (enough) time to try and restore current trunk compatibility first as more important things had to be fixed first.

Posted: **31 Dec 2010 14:04**

JGR wrote:I made a mistake in my post, apologies, it's actually: 205887.

You need to remember that in fixed point, the fractional part is a binary one, not a decimal one.

...

Ah, now you are making sense, I got that all wrong then and stand corrected.
Last work i did with something resembling this "problem" was reverse engineering EVE Online's cache files. There they represented currency as a 64 bit base 10 deal... Long time ago.
Either way, both methodologies work but yours probably supports more precision. On the other hand the one i detailed won't get rounding errors.

Posted: **31 Dec 2010 17:47**

chillcore wrote: Can you please point me to the versions you are using for the Canadian trainset and the Canadian station set so I can test again with the same versions you have.
dimon22_g wrote: Hello, here they are. In my game the crash usually happens a few days after the start.
Thank you. I will try again in a bit.

Hmm ... I still can not reproduce.
I let it run for a few months in v11_5 and a few years in v11_6 without crashes, I think I will need the savegame you load to make it happen instead of the crashed savegame to reproduce ...

You mentioned revision 21532 in your initial post. Was that a typo and did you mean r21523 or have you bumped and compiled yourself?

Something strange I noticed with the download content.
The two GRFs dimon_22_g has posted say v1.0 but when I clicked the "Check Online Content" button, before I put the correct ones in place myself, OpenTTD tried to find the v0.3 versions, which were the replacement grfs I had already, instead of the 1.0 versions.
The Canadian GRFs are not on bananas but I think this is irrelevant concerning this bugsie.

I have not yet tried if the same happens in clean trunk if compatible replacements are found.

Posted: **31 Dec 2010 22:58**

I was using win32 build from ColdIce that is in this forum thread a few days ago. This was the version where "automate" button in timetables was fixed.

chipp_v11_5_1_r21532.rar [3.7 MiB]
Downloaded 145 times

Is there a newer compiled version? Maybe I'll just try a newer one and it will work.

About version of canadian set - I think I just took it directly from this thread
http://www.tt-forums.net/viewtopic.php?f=67&t=47730.
In my game under check online content it does not appear at all. Not even version 0.3

Posted: **31 Dec 2010 23:51**

dimon22_g wrote: I was using win32 build from ColdIce that is in this forum thread a few days ago. This was the version where "automate" button in timetables was fixed.

chipp_v11_5_1_r21532.rar [3.7 MiB]
Downloaded 145 times

OK, I know what confused me now. v11_5 is r21523.

I have downloaded v11_5_1 now but I still can not not reproduce it.
I will need the savegame that produces the crash instead of the crash.sav and your config file.

Is there a newer compiled version? Maybe I'll just try a newer one and it will work.

Not yet ... but compiling yourself is really not that hard.

About version of canadian set - I think I just took it directly from this thread
http://www.tt-forums.net/viewtopic.php?f=67&t=47730.
In my game under check online content it does not appear at all. Not even version 0.3

Neither in my version or anybody elses. They will not appear as they are not on bananas. (They are on grfcrawler or in the link you provided).

I think you misunderstood.
Open the gui for loading a savegame but instead of clicking "load" click the "NewGRF Settings" button. On the bottom of that gui you find "Check Online Content", when you click that a new gui will open listing the GRFs that you are missing or the normal online content when none are missing.

I already had v0.3 for both GRFs and they were loaded as replacements.
However when trying to download the correct versions the patchpack searches for the 0.3 versions with is pointless as I have them already instead of searching for the 1.0 versions.

Also next time you may want to post the link instead of posting the GRFs or PM them to me.

@Devs:
I think that the gui should stay empty here if none are missing instead of displaying the normal content of bananas.

Happy NewYear everyone, I wish you all a fantastic and healthy year to come.

Posted: **01 Jan 2011 09:38**

ChillCore wrote: I think you misunderstood.
Open the gui for loading a savegame but instead of clicking "load" click the "NewGRF Settings" button. On the bottom of that gui you find "Check Online Content", when you click that a new gui will open listing the GRFs that you are missing or the normal online content when none are missing.

Thanks for the explanations, I did not worked with it as have a collection of grfs downloaded from openttdcoop and usually just search for replacement files there.

ChillCore wrote: Also next time you may want to post the link instead of posting the GRFs or PM them to me.

Lol! Point taken.

ChillCore wrote: Happy NewYear everyone, I wish you all a fantastic and healthy year to come.

Same to you and everybody. And thanks a lot for the nice pathpack.

I will play some other maps (and newgrfs), if still have problems, will save and post you the game before the crash. In this case I think it was about two years before, so makes no sence to load an older game.

Posted: **01 Jan 2011 09:51**

a bit off-topic

dimon22_g wrote: Thanks for the explanations, I did not worked with it as have a collection of grfs downloaded from openttdcoop and usually just search for replacement files there.

Your first place to look should always be the online content. The #openttdcoop NewGRF pack is only maintained as legacy for old savegames (and some ancient newgrfs where the authors disappeared or didn't yet bother to upload them to the online content) and as such will since the introduction of the online content in 2009 never contain new NewGRFs anymore.

Posted: **02 Jan 2011 17:58**

ChillCore wrote:I do not know what patch dkarn has used, there have been quite a few town growth patches and maybe he wrote it himself.
I do not doubt that it is fun to use, if you like suuch challenges, but if you want me to include it I will need the patch first.
Also do you not find that the towns grow to fast? When I glanced through the code dkarn removed the adjustments according to daylength in the patchpack ...

I don't know which patch is included there either. But it seems not to work properly anyway. It works fine with food. But when it comes to goods there has to be a bug. Since I don't know if a thread exists for that patch... I can't report it anywhere

But I don't think the towns are growing to fast with this patch (I assume we talk about the same one because dkarn is mentioned in the French forums)... We play with daylength factor 4 and sometimes I wish they could grow a little bit faster

So here's a windows binary including the build log (in German though)

r21667M_ChillPP_v11_6.rar: (3.92 MiB) Downloaded 139 times

Transport Tycoon Forums

Chill's patchpack v14_7

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5

Re: Chill's patchpack v11_5