Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Thu Jun 21, 2018 12:39 pm

All times are UTC




Post new topic  Reply to topic  [ 16 posts ] 
Author Message
PostPosted: Wed Jun 13, 2018 11:45 am 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 114
v03
fix one of the previous bugs

What id does so far
1. you can select in the game settings the time factor you want to slow the game.
2. this option for now is available also while you are inside the game and play maybe later will be only in the creation ?
3. this patch tries to have everything run in normal time part the aspect of the display date

Auto-save is still done in normal months so you have the same game experience
Now the display date in status bar shows hours and minutes so you can see the normal days pass as time useful if you choose big slow factor.
So long in the testing the cargo payment rates production of industries all seem to work normal and the mechanics are tot broken
The company financial window change at the new slow year.
The vehicles do service in normal days.
Open discussion what the information window of a vehicle should show? The window now shows 150 days. IF we change the word days to cycle the game will work perfect. Since it will be an easy way to compare this value between games and it will have the same meaning.
150 cycles will always be 150 normal days. Else if we change this number to be in slow days then you will have t convert this number to normal days to compare between games.

bug
for one reason when you first start ottd either you load or start a game the first N days where N is your slow factor the game will auto save every normal day!!!!! i am looking the code and trying to figure out why this N first days are so special. After them the game runs normal. And if you load a game, or start another one there will be no problem. so when you start ottd as an advice set the factor to 1 start s new game let it auto save 1 time and then you can play this game or load your game you wanted to play.

i imagine there will be complains that the game display information the wrong way in some windows
if you want the game the show information different please give feedback


Attachments:
File comment: windows 64 binary
bin.7z [4.64 MiB]
Not downloaded yet
File comment: files that are changes to compile
v03.7z [139.69 KiB]
Not downloaded yet


Last edited by ANIKHTOS on Wed Jun 20, 2018 2:27 pm, edited 2 times in total.
Top
   
 Post subject: feed back
PostPosted: Wed Jun 13, 2018 12:03 pm 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 114
Quote:
You are missing an important point. Even if you introduce your own "new call" that yields slow year and slow month etc, the existing NewGRFs do not know this call and do not use it.
Everything is fine if you only use default vehicles, but that is not enough. This is a big issue with the game development, as there are many many NewGRFs that will either:


not benefit from the new feature
appear glitchy
break altogethe


they do not need to know this feature, this feature is supposed to mask and hide
the game need not to realize that there are 2 clocks in the game
and the code make sure that there is 1 clock in the game

the new calls are just there for future use for people that would like to use and exploit the slow day slow month slow year

the whole idea was to get this feature in the game without realizing the game that it was introduced.

when the game ask for a date it will always get the SLOW DATE
there will be no other date to confuse the game.
and since almost everything is tight up with days from the beginning aka _date parameter there will be no problem
since there is 1 counter of days and that is always increasing at a slower rate.


Quote:
I invite you to look into newgrf.cpp line 5750 or so, function GetGlobalVariable. You see there there are various ways in which NewGRFs access the global variables _date, _cur_year, cur_month etc. Mind you, this is ALL newGRFs not just vehicle ones, e.g. also industries. You can NOT introduce new parameter values or change the meaning of the existing ones without breaking compatibility with older GRFs, therefore, you can only change what the function returns for each parameterer.


i look the code end??
there will be no problem calculating that NO PROBLEM AT ALL

Quote:
So let's say you replace current year with your "slow year", but leave everything else untouched. This will cause all newgrfs to introduce stuff to the game according to the slow year, which is what you want. But now years have N * 12 months, as far as NewGRFs are concerned, and that might break e.g. NewGRFs that accumulate usage or production or stockpiles on yearly basis. In addition, variable snowline height or production on specific months of the year will be glitchy, e.g. a factor 2 you will experience 8 seasons per game (two springs, two winters etc)


Nope the year do not have 12N months now
there will be N game year inside a slow year all of them with 12 game months.
you do realize that all the call in the game are still done in the normal year?? and not in the slow year??


Top
   
 Post subject: hmm
PostPosted: Wed Jun 13, 2018 12:25 pm 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 114
okey lets try to make ti visual how it works
d = game day D slow day, m game month M slow month y game year Y slow year


so the game start lets say 1st january

1 game days display date 1st January runs all calls for new day
2 game days display date 1st January runs all calls for new day
3 game days display date 2nd January runs all calls for new day + runs all calls for slow day (empty for now)

31 game days display date 10 nth January runs all calls for new day + runs all calls for new month

91 game days display date 1st February runs all calls for new day + runs all calls for new month + runs all calls for slow month (empty for now)

in 365 game days it will call the on new year the new day the new month calls,

1095 game days it will run all calls

well i do not know it that help to visualize things??

the game days are the same and will not change
the game months are the same and will not change
the year game is the same and has not changed

you will have the N factor of game years in the slow year with all of them having 12 normal months
and in a slow year each month will be N factors since you have N years inside the slow year


Top
   
PostPosted: Wed Jun 13, 2018 1:21 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Jan 18, 2014 6:10 pm
Posts: 1072
Sound familiar to this patch:
viewtopic.php?f=33&t=82407&hilit=daylength

_________________
My experimental openTTD server: 149.156.194.203:3979 non-standard client, now testing: JGRPP http://tiny.pl/ggnch
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, preindustrial houses, wired, ECS industry extension.


Top
   
PostPosted: Wed Jun 13, 2018 1:43 pm 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 114
McZapkie wrote:
Sound familiar to this patch:
viewtopic.php?f=33&t=82407&hilit=daylength


completely different approach
he reset the year to start again multiple times

which i do not know if it make some odd behaviour to have things in game from the future

but well in the end all different approaches will try to go to the same goal
make game year last longer

with my approach the time line is linear ever increasing with his approach the time line goes back and fourth
you will have 31 December of 1950 to go to 1 st January 1950

would you be interested in trying it out and have some feedback i would appreciated


Top
   
PostPosted: Wed Jun 13, 2018 2:03 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Jan 18, 2014 6:10 pm
Posts: 1072
ANIKHTOS wrote:
would you be interested in trying it out and have some feedback i would appreciated

There is couple of daylenth patches, currently I'm using this one: "another fay length patch"
viewtopic.php?p=1148227#p1148227 which is implemented in JGR patch pack.

_________________
My experimental openTTD server: 149.156.194.203:3979 non-standard client, now testing: JGRPP http://tiny.pl/ggnch
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, preindustrial houses, wired, ECS industry extension.


Top
   
PostPosted: Wed Jun 13, 2018 2:11 pm 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 114
McZapkie wrote:
ANIKHTOS wrote:
would you be interested in trying it out and have some feedback i would appreciated

There is couple of daylenth patches, currently I'm using this one: "another fay length patch"
viewtopic.php?p=1148227#p1148227 which is implemented in JGR patch pack.

i know there are other patches
and i know how heated this topic is i have been following it for years

but i decide the time has come to make my hands dirty and give it a go

the foundations of the idea is that game will still run the same as now
nothing will change but the date been slower thus the vehicles will be introduced later in the game

and it seems that i got what i aimed for
the game time and game mechanics are in place and everything runs normal

only the date progressing slower

i wanted to have the same game experience but only the game last longer
and i manage to do that


Top
   
PostPosted: Thu Jun 14, 2018 11:25 pm 
Offline
Traffic Manager
Traffic Manager
User avatar

Joined: Tue Oct 19, 2010 7:49 pm
Posts: 156
Quote:
Sound familiar to this patch:


Similar, not the same. In that patch, too, you have a "display date" and an "internal date". The advantages are laid out very well by ANIKHTOS above. The difference is that the patch here has the GUI clock simply be N times slower than the internal, whereas in mine each year wraps around N times before moving forward.

Quote:
i look the code end??

I had also thought of your approach (not trying to take the credit, the original idea is credited to fonso in the other thread), so I analyzed the code in Visual Studio to see all references to those date/tick globals etc. The thing that stopped me is the access that NewGRFs have to these globals, in the function you quoted above (newgrf.cpp).

So, the problem that I see with your approach, is that newgrfs will get the "slow" month (_cur_month) when they ask the game for it. Is this correct? If the answer to the above is yes, then you can expect problems. Some newgrfs have hardcoded assumptions about e.g. how many times industries can produce in a month. I vaguely recall a problem with ECS with respect to this, in one of the older threads, cannot remember now.

The problem for me is that I lack the knowledge of the codebase to tackle all these problems. That function allows NewGRFs to read date, day, month, year, as well as "long format date". I do not know which is used for what by any and all newgrfs, maybe there is a way to work around all the problems, then I think the approach is valid.

_________________
Citizens Celebrate! First train arrives in <insert your favourite town/station name here>!


Top
   
PostPosted: Fri Jun 15, 2018 12:23 am 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 114
Tafidis wrote:
Quote:
Sound familiar to this patch:


Similar, not the same. In that patch, too, you have a "display date" and an "internal date". The advantages are laid out very well by ANIKHTOS above. The difference is that the patch here has the GUI clock simply be N times slower than the internal, whereas in mine each year wraps around N times before moving forward.

Quote:
i look the code end??

I had also thought of your approach (not trying to take the credit, the original idea is credited to fonso in the other thread), so I analyzed the code in Visual Studio to see all references to those date/tick globals etc. The thing that stopped me is the access that NewGRFs have to these globals, in the function you quoted above (newgrf.cpp).

So, the problem that I see with your approach, is that newgrfs will get the "slow" month (_cur_month) when they ask the game for it. Is this correct? If the answer to the above is yes, then you can expect problems. Some newgrfs have hardcoded assumptions about e.g. how many times industries can produce in a month. I vaguely recall a problem with ECS with respect to this, in one of the older threads, cannot remember now.

The problem for me is that I lack the knowledge of the codebase to tackle all these problems. That function allows NewGRFs to read date, day, month, year, as well as "long format date". I do not know which is used for what by any and all newgrfs, maybe there is a way to work around all the problems, then I think the approach is valid.


the biggest issue with newgrf is that there was NO STANDARD which parameter to use and how to use it
which give a freedom to the writers to ling their time to what ever variable they feel was better for them

so not only in this scenario but in any other topic there will be problem with some newgrf not working and needed to be re written

maybe there need to be a standard on what variables negrf will use??

anyway the game is in development for long long time now
i imagine others have thought the 2 clocks approach before.
and yes it is possible to more than one people thing the same thing without knowing the other have thought of it
who thought it first does it really matters?? or who can make it work??

1 question do you have problem with your patch that is not linear??/ do you get N times ask if you want to test a prototype???

i will write a new code
_cur_month will be at same time the slow and normal month
to increase compatibility with newgrf yeap the code is going to be more crazy :-)


Top
   
PostPosted: Fri Jun 15, 2018 4:20 pm 
Offline
Traffic Manager
Traffic Manager
User avatar

Joined: Tue Oct 19, 2010 7:49 pm
Posts: 156
Quote:
who thought it first does it really matters?? or who can make it work??


Obviously different people can come up with same idea independently. I was not trying to take credit away from you. Sorry if I made that impression. Also obviously, thinking something is one thing, making it is another (and much more difficult).

Quote:

1 question do you have problem with your patch that is not linear??/ do you get N times ask if you want to test a prototype???


Yes. My patch shows finances windows and updates vehicle stats every 1/N years, Moving snowline would imply N season cycles per year (not tested, but based on the implementation). Prototypes remain in their test period N years. Subsidy offers stay around and -once acquired- last for N years. Just to name a few of the glitches.

Quote:
i will write a new code
_cur_month will be at same time the slow and normal month


My suggestion would be to read and understand the code more. There are many things (beside newgrfs) that get touched by these time variables. For example cargodist linkgraph updates happen every K days. If they happen every N*K days instead, it could affect the gameplay. What i did was find all reference of the globals in the entire codebase (_date, _tick_counter, _cur_year etc). There are literally hundreds of them. My plan for your approach was to make it configurable if "slow" or "normal" version of the variable should be used for EACH instance (or many of them, anyway). But I stumbled upon this newgrf.cpp and stopped there, because I think either choice there breaks some behaviour, Any game-mechanic can be re-coded to listen to this or that clock, but newgrfs can't.

Quote:
so not only in this scenario but in any other topic there will be problem with some newgrf not working and needed to be re written


So that is not possible for many newgrfs, due to licenses, lost sources, etc.

In the end, there are two reasons why (i think) no daylength patch ever made it to trunk before:

  • No full glitch-free implementation that is fully backwards compatible and at least acknowledges that some game-balancing issues occur. A simple magic solution that accomplishes this does not seem to exist
  • It is really too much work to do the above, when you can constrain yourself to use vehicles of a specific era via newgrfs or simply not upgrading the way things are now.

Now if you are happy coding/ playing with your patch and improving it, I would be looking forward to what you come up with.

_________________
Citizens Celebrate! First train arrives in <insert your favourite town/station name here>!


Top
   
 Post subject: experimental branch v2
PostPosted: Fri Jun 15, 2018 4:41 pm 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 114
would you like to test experimental code v2??


_cur_month flip flops all the time to meet the need of the moment

when there is to call the newmonth calls it change to normal months + something to indicate a month has passed
when the new months calls finish it goes back to the slow value

the problem is i need people to test and report bugs and what they want to see

i also fix the servicing of vehicles done in slow days which was too long
now servicing is done again in normal days periods

thank all for the testing and reporting

by my testing so far the time continues to be linear

well there are many interesting question know
for example in the details window of a vehicle lets say a train you see 150 days for internal servicing
should this values change to tell slow days??
or change the name days to 150 cycles ??

so when you look at this value you can say its your personal one you like
if we put the slow days then you can see easier when the vehicle will go for service

there is reasons to show each
or we can have an even 3 option instead of seeing when was last services we can have it tell us days left to service and this can be in slow days
every option has its pros it cons and there is no right answer
its what you will like more to see as info


Last edited by ANIKHTOS on Tue Jun 19, 2018 8:10 pm, edited 1 time in total.

Top
   
 Post subject: bin v2
PostPosted: Fri Jun 15, 2018 8:19 pm 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 114
nothing


Last edited by ANIKHTOS on Tue Jun 19, 2018 8:10 pm, edited 1 time in total.

Top
   
PostPosted: Sat Jun 16, 2018 2:49 pm 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 114
have you noticed problems in servicing the trains with your code??
servicing check this line

date of last service+ interval >= _date
if this is true then it goes for servising

if a train service in 30 December and the game wraps when it will get re serviced ??


Top
   
 Post subject: version 3
PostPosted: Tue Jun 19, 2018 8:39 am 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 114
and we got to v3 of experimental code
now you can select the factor of how slow the game goes iin the settings-> environment
value 1 means normal time and you can slow it down with higher values for now max value is 365 but i am thinking to raise it to 1440

for now you can change the speed of the game while playing :-)
but after the testing will finish this will be removed and you will be able to set the factor at beginning??
any though on that??

change the display of the date to include hours and mins and this way you can see the normal day pass as time
helps not seeing the date frozen if you have chosen big factor

bug
while i try to change th display of date only in the status bar it changed it everywhere !!!!
working on solving it out

bug2
when you start the game the game auto saves every normal day until you pass 1 slow day
but after you play 1 game any new games after thet or load games will work fine
recommend for now to start a game with factor 1 so you go fast to next next slow day and avoid the autosaves

i am looking to solve this bugs
but i am more interested from you to try it and tell me if there is any broken mechanics of the game?/
cargo payment
industry production things like that

the code is moving forward slowly but steady

thanks a lot to all of you for your support

binary in the first posts


Top
   
PostPosted: Wed Jun 20, 2018 11:14 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Apr 28, 2003 6:52 pm
Posts: 1182
Could you also post the source code so that non-Windows users can compile it?


Top
   
PostPosted: Wed Jun 20, 2018 2:29 pm 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 114
Snail wrote:
Could you also post the source code so that non-Windows users can compile it?



okey solved the bug 1 from the previous posst
bug2 is still bugging me but it seems i have and idea that i can solve it
but it will make the code a bit complex to write
added also the altered files so you can compile it yourself;

enjoy and waiting feedback


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 16 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000-2018 phpBB Limited

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2018.
Hosted by Zernebok Hosting.