date (and console) patch

[Panther]

I use the latest nightly (2074) and i made some changes to see the real time in the statusbar (also i'll know i've played too much

In the savegame names it will be added, too, but windows does not like ':' in filenames. I'll fix it later.

I'll add some functions to console, too, but now i've not got too much time.

Picture is here: http://cfhay.inf.elte.hu/~panther/opent ... e.2074.png

[Panther]

':' problem fixed (on Windows filenames will contain '.'. Diff file: http://cfhay.inf.elte.hu/~panther/opent ... 074-2.diff

[orudge]

Hmm, could I ask personally... why?

[Panther]

Hmm, could I ask personally... why?

why not?

I play with enemy-territory (FPS ), too, and there is an option, that i can see the system time - and i think it is a good feature.

It would be optional, if it'd be in patches.

I also made some changes to let the trains run all kind of railways, not only on its type, but the code is not clean enough to post it

[Gorre]

I also made some changes to let the trains run all kind of railways, not only on its type, but the code is not clean enough to post it

With all due respect...it is...stupidity. Do you know that maglevs doesn't have any wheels? Maglev means 'magnetic levitation'
I think more handy would be allowing tropical/arctic trains to work on temperate climate and vice versa.

[Panther]

With all due respect...it is...stupidity. Do you know that maglevs doesn't have any wheels? Maglev means 'magnetic levitation'

I know, it is stupid (but normal and monorail railways have better graphics with modified grf files).

I tried to understand the code and that i can change it or not. Nothing more.

I think more handy would be allowing tropical/arctic trains to work on temperate climate and vice versa.

This sounds good.

[Gorre]

I tried to understand the code and that i can change it or not. Nothing more.

Very well! So, good luck!

[Panther]

I made the patch optional (Interface patches). It based on r2093.

[pasky]

I can understand showing it in statusbar, but why to put it to savegame names too? Virtually all systems store file creation/modification time, they can show it to you, frequently you can sort it by that (which is exactly what OTTD does, BTW), etc. So why to clutter the filename with it explicitly?

[Panther]

That's right. But I played a lot with the same game in 0.3.6 after 2090 reached. As you know that means every new year will be 2090 and the old year 2089. If the date counter (now 16 bit long) would be larger (32bit long), it would be above 2144 (and there could be a name collision... I don't know the correct expression....).

Hm, it could be an optional thing?

EDIT: Last year is 2090 - but why?

[Darkvater]

Because the date is an uint16, and is counted as days. As the game starts in 1920 it's max life is ~179 years, which is around 2090 (give or take). It needs increasing but a lot of other data depends on it so that takes a while.

And I'm sorry but I don't think that patch has any real added value to the game.

[Panther]

Because the date is an uint16, and is counted as days. As the game starts in 1920 it's max life is ~179 years, which is around 2090 (give or take). It needs increasing but a lot of other data depends on it so that takes a while.

I know.

EDIT: I would like to know why uint16, why not uint32. I really enjoy the gameplay after year 2051 too, despite - there are no more new vehicles.

And I'm sorry but I don't think that patch has any real added value to the game.

Well, that's right. The goal wasn't "real added value", just a small thing. And it was easy to implement.

[Darkvater]

why uint16? Because TTD had uint16. You have to remember OpenTTD is based (eg cloned from disassembly) on TTDLX. So every fault and limitation TTDLX had, OpenTTD has or had at some point in the past.

And since nobody had the time to wade through the entire codebase and find out where the date and all its related variables still rely on uint16, it's still uint16.