Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Fri Nov 16, 2018 9:21 pm

All times are UTC




Post new topic  Reply to topic  [ 23 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Wed Jun 13, 2018 11:45 am 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 119
v04

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.
In the vehicle details window, the interval 150 days is changed to interval 150 cycles to be more with the spirit of the patch. Which translates to 150 normal days of game passing. Which will make this number to be the same for all the games you play depend less the slow factor you play with. Also because it will be hard to calculate when next service will, now it is displayed the next service date. Also this is the programmed next day of service of the vehicle for now this will not be able to be changed by changing the interval number. Changing the interval will take affect when the next programmed date is calculated.

The files are up in githhub
https://github.com/ANIKHTOS/OpenTTD/
enjoy and wait for feedback


Attachments:
File comment: source files to compile
ottdv047z.7z [5.96 MiB]
Downloaded 25 times
File comment: windows 64bit binary
binv04.7z [4.64 MiB]
Downloaded 23 times


Last edited by ANIKHTOS on Sun Jun 24, 2018 11:30 pm, edited 10 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: 119
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: 119
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: 1083
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.
Addicted to freeciv longturn.


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

Joined: Thu Jan 17, 2013 5:13 am
Posts: 119
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: 1083
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.
Addicted to freeciv longturn.


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

Joined: Thu Jan 17, 2013 5:13 am
Posts: 119
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: 157
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: 119
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: 157
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: 119
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: 119
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: 119
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: 119
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: 1194
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: 119
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
   
 Post subject: new version v04
PostPosted: Sat Jun 23, 2018 2:26 pm 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 119
v04 is here at last
the previous bugs are gone ;-)

Attachment:
status-bar.png
status-bar.png [ 19.27 KiB | Viewed 1255 times ]

as you can see the status bar shows the normal days to pass as time :-) no long boring watching the same date

Attachment:
vechicle.png
vechicle.png [ 11.21 KiB | Viewed 1255 times ]

few changes in the detail window of the vehicles
the service interval now says cycles and not days to be more in the spirit of the patch
which means cycles= normal days pass thus you will keep the same number across all the game seven with different slow factors which will make it easier to know if you have your default favourite setting.

Also since now to calculate the next service date would be a pain the window now shows the next service date instead of last service.
so it will be easy to see how long this vehicle has until next service.

for now the date displayed will be the next date of service and will not be affected if you change the interval
it will affect the new service date to be
adding 1 more variable to store for each vehicle it will make game slower for no reason

any thoughts??

the code will be posted in the first post


Top
   
PostPosted: Sun Jun 24, 2018 9:42 pm 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 119
Attachment:
veh-age.png
veh-age.png [ 49.81 KiB | Viewed 1032 times ]


also as you can see the age of vehicles is still calculated in normal years, the game played use a slow factor of 5 and as you can see 5 normal years will pass before the date in the status bar will show 1 year. This keeps the age of vehicles the same in all the games you play. And the experience is the same.

The running cost is shown as running cost per normal year
maybe add also a second number there to show how much it will produce in a slow year??

but keeping the display like that this number is relevant the same according different games


Top
   
PostPosted: Mon Jun 25, 2018 9:53 am 
Offline
Traffic Manager
Traffic Manager
User avatar

Joined: Tue Oct 19, 2010 7:49 pm
Posts: 157
Nice work ANIKHTOS

Didn't have time to play, but I see you are already going down the route of making decisions like "mechanic X should get normal years, but Y should get slow years". There are always supporters for both, with "realism" and "gameplay" being the main factors.


  • default time scale (factor 1). Years pass very fast, something like 6 min in our own (not the game's) time. And trains take months or years to complete routes. Unrealistic-duh. That's why there so many patches like this
  • Custom time scale (factor 10). The slow year lasts 10 times as the normal year. Gameplay dictates that you would now have to replace your "Kirby Paul" Steam engines (with a listed maximum life of 10 years) right about the end of this one slow year, to keep things as they are in a normal (factor 1) game, wrt to replacing vehicles. But a steam age that gets old in only one (game) year? That's a bit uintuitive again. Also, new vehicles get introduced in a way that you can replace aging vehicles with a newer model, now you will only be autorenewing them several times before anything new comes up
  • Should trial period for newly introduced vehicles last 1/10 slow year? Or a full slow year?
  • Why not allow servicing interval to also be stretched with the time scale factor (i.e. simply give it in slow days)? Granted, it makes the game "easier" because you do not have to service that often, but one could argue it keeps things simpler for the player.

So, my suggestion would be to add configuration options for each of these items, e.g. "servicing interval in cycles/days", "Vehicles age every day/cycle". These options are only temporary, i.e. they are there for testing. 90% of these could be removed in the end, but the one or two people cannot agree on maybe can stay. Look at cargodist. For a feature you can turn completely off, there are about 15 settings to change (although to be fair mostly they are finetuning the algorithm to the map you are playing)

I always think of timescale patches like larger maps. They extend a physical dimension (time instead of space). Some things are bound to be different than "normal". E.g. in larger maps airplanes are even more overpowered (they benefit from great distances due to their speed) or it is much easier to find two industries with an ideal distance between them at the start of the game to make your first route. (This used to be harder in original TTD. I remember playing the first 10 yeras with ships only on "hard" difficulty, because initial loan was never enough to complete a cargo route and buy a train, so you had to build up your capital). Or let's say it is simply much easier to make money and get higher performance score, the larger the map gets. Time scaling will similarly inevitably offer some advantage (more time to built up a greater part of the map by some game year) but simultaneously break some other things (e.g. town or tree growth balancing). This is why I think these config options might be a good idea for people to test such effects.

Last thing. Does your status bar update every minute now? or does it depend on the factor? In mine, the status bar updates every normal game day (so exactly as fast as it used to). The time is rounded to the nearest hour, half hour, or quarter, depending on the factor you set. So, e.g. for factors up to 24 you only see whole hours (1st Jan 1930 01:00) etc and never see any minutes. Up to factor 48 you only see full/half hour marks, (1st Jan 1930 00:30) etc and from then on you also see quarters (1st Jam 1930 00:15). I thought this makes me feel like time is passing steadily (more frequent updating/uneven intervals might make me anxious lol!)


Keep up the good work!

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


Top
   
PostPosted: Mon Jun 25, 2018 7:23 pm 
Offline
Engineer
Engineer
User avatar

Joined: Thu Jan 17, 2013 5:13 am
Posts: 119
Tafidis wrote:
Nice work ANIKHTOS
.
Last thing. Does your status bar update every minute now? or does it depend on the factor? In mine, the status bar updates every normal game day (so exactly as fast as it used to). The time is rounded to the nearest hour, half hour, or quarter, depending on the factor you set. So, e.g. for factors up to 24 you only see whole hours (1st Jan 1930 01:00) etc and never see any minutes. Up to factor 48 you only see full/half hour marks, (1st Jan 1930 00:30) etc and from then on you also see quarters (1st Jam 1930 00:15). I thought this makes me feel like time is passing steadily (more frequent updating/uneven intervals might make me anxious lol!)

Keep up the good work!

the status bar time is depending on your factor . if you have a factor lets say 6 the time will be shown every 4 hours
but it you have a factor lets say 5 the time will change 4 hour and 48 min if you go extreme and put a factor 1440 then the time will change every min


Tafidis wrote:

  • default time scale (factor 1). Years pass very fast, something like 6 min in our own (not the game's) time. And trains take months or years to complete routes. Unrealistic-duh. That's why there so many patches like this
  • Custom time scale (factor 10). The slow year lasts 10 times as the normal year. Gameplay dictates that you would now have to replace your "Kirby Paul" Steam engines (with a listed maximum life of 10 years) right about the end of this one slow year, to keep things as they are in a normal (factor 1) game, wrt to replacing vehicles. But a steam age that gets old in only one (game) year? That's a bit uintuitive again. Also, new vehicles get introduced in a way that you can replace aging vehicles with a newer model, now you will only be autorenewing them several times before anything new comes up
  • Should trial period for newly introduced vehicles last 1/10 slow year? Or a full slow year?
  • Why not allow servicing interval to also be stretched with the time scale factor (i.e. simply give it in slow days)? Granted, it makes the game "easier" because you do not have to service that often, but one could argue it keeps things simpler for the player.

So, my suggestion would be to add configuration options for each of these items, e.g. "servicing interval in cycles/days", "Vehicles age every day/cycle". These options are only temporary, i.e. they are there for testing. 90% of these could be removed in the end, but the one or two people cannot agree on maybe can stay. Look at cargodist. For a feature you can turn completely off, there are about 15 settings to change (although to be fair mostly they are finetuning the algorithm to the map you are playing)


my intention in this patch is not to break any game mechanics
keep the game running as it is now but only stretch the display time so everything will go slower and you will have more time to enjoy an era

and that the beauty now steam engines will be auto replaced with the same engine rather replaced with a newer model

well ti be realistic there will be always a conflict of intuition or realism to start with look the distance of 1 tile in the game and look the station its unrealistic the scale but we still love the game

about the age thing 10 years for an engine is unrealistic there are trains that run for 50 60 or more years depending on how quality they were build so the 10 years in the game is UNREALISTIC to begin with

but if we extent the life according to the factor we play how much you should pay for the train?? N times?? then your initial loan need to be extended also N times because you will not be able to build any route

since the game run in normal time, and all the mechanics are still operating in normal time i consider to keep them as they are
and yes you will replace the train in 1 slow year but you need to remember that for the game it has passed 10 years not 1. the game experience remains the same

now the discussion show normal days/months/years info or slow days/month/years

i think if you go to slow then you will complicate things for no reason
now you service every 150 days you still do that but the game just say cycles so you will not be ocnfused
imagine if i had to put slow days it would say with a factor of 10 15 days?? what about factor 11?? 13 days??? and the rest shown as time?? 15.03??? and if you like some lines to have special intervals what then?? you will have a number maybe more realistic but not practical
changing to cycles you keep the same number 150 that we all know and love and it will be easy with no need of calculating if it is the desired one. and as you see now the last service is change to next service which make it easier to see when the next service is

the same for the running cost , in the next patch there will be both the normal running cost per normal year, and the running cost per slow year. which will satisfy everyone
changing the numbers to slow time it will not make the comparable to other games

also changing the age of vehicles we change the mechanics and we need to address everything that will be affected
as it is now the detail windows shows the same age in normal years so you will see it been old unless you are watching it will not be that odd
also if we multiply the age by a factor n then you loose the first 2 years of better rating
a train that you replace every 10 years is not the same as a train replaced every 100 years ? so what next increase also the phase to be 20 normal years??

a lot of talk will be about display information and not about the mechanics
showing the running cost change nothing to the game since it still runs in normal years so the normal number will be used
i just added the slow number as an eye candy

but thank you i need to investigate the prototypes and the subsidies how the game deals with them normal time or slow time??
to be in the spirit of not breaking mechanics they need to be in normal time

but this things is more important for me right now. if there is a problem problem in game mechanics
i checks the cargo payment rate and it is on normal time so no break in mechanics there :-)

thank you very much for your feedback
well maybe later i can but some options to some things that will change the game and act as difficult settings
but for now i still want to be sure that there are no broken mechanics or odd behaviour in the game
when this part is finished then we can talk and fight about options as difficult settings.
but then if we put the options we need to disable the possibility to change factor in the game
or else it will be a nice cheating when you want to replace vehicles lower your factor everythign will cost less replace then increase factor again lol


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 23 posts ]  Go to page 1 2 Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 8 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.