Updated daylength patch for 1.4.1 and r26674
Moderator: OpenTTD Developers
-
- Engineer
- Posts: 2
- Joined: 04 Jul 2014 22:47
- Location: Pennsyltucky, USA
Updated daylength patch for 1.4.1 and r26674
I spent some time making a current day length patch. It was initially based off of Sacro's patch from like '05.
A new setting is implemented in Economy on 1.4.1 and World Generation of r26674 (Latest trunk right now.) that lets you multiply to DAY_TICKS by a constant factor. Station rating, industry production, and town growth all increase with the DAY_TICKS multiplier. Station acceptance, station linkgraph, and cargo aging are not affected by the multiple. (Station acceptance should be occur almost instantaneously in my opinion, and to be honest, I don't know what a station linkgraph is.)
I've tested this in single player and multiplayer with no clear ill effects. The 1.4.1 version will fail to load the main screen save due to "chunk size differences", but the latest SVN is not affected.
I may change the station rating back to stock if I think it moves too slow but it hasn't been an issue yet. Another plan is to add a second setting that divides the ticks for industry growth so that the player can incrementally adjust station production as day length increases. Assuming people care, I should have windows builds uploaded in a day or two, assuming I can get this Win7 VM running. Cross compiling on Linux is a female dog.
//Edited for detail and clarity when I'm not running around like a nut.
A new setting is implemented in Economy on 1.4.1 and World Generation of r26674 (Latest trunk right now.) that lets you multiply to DAY_TICKS by a constant factor. Station rating, industry production, and town growth all increase with the DAY_TICKS multiplier. Station acceptance, station linkgraph, and cargo aging are not affected by the multiple. (Station acceptance should be occur almost instantaneously in my opinion, and to be honest, I don't know what a station linkgraph is.)
I've tested this in single player and multiplayer with no clear ill effects. The 1.4.1 version will fail to load the main screen save due to "chunk size differences", but the latest SVN is not affected.
I may change the station rating back to stock if I think it moves too slow but it hasn't been an issue yet. Another plan is to add a second setting that divides the ticks for industry growth so that the player can incrementally adjust station production as day length increases. Assuming people care, I should have windows builds uploaded in a day or two, assuming I can get this Win7 VM running. Cross compiling on Linux is a female dog.
//Edited for detail and clarity when I'm not running around like a nut.
- Attachments
-
- svn-daylength.patch
- r26674 patch
- (10.2 KiB) Downloaded 168 times
-
- daylength.patch
- 1.4.1 patch
- (10.28 KiB) Downloaded 216 times
Last edited by james.a.wagner3 on 05 Jul 2014 07:30, edited 3 times in total.
Re: Updated daylength patch for 1.4.1 and r26674
I'm not familiar with that version, how does this handle the issue of profit?
Do you like drones, quadcopters & flying toys? Check out Drone Strike Force!
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | GarryG's Auz Sets
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | GarryG's Auz Sets
-
- Engineer
- Posts: 2
- Joined: 04 Jul 2014 22:47
- Location: Pennsyltucky, USA
Re: Updated daylength patch for 1.4.1 and r26674
Not sure what you mean by handling profit, but the answer to your question may be in my now edited post. The way it is set now, days move slower, but since industry production is also tied to the multiple, trains take longer to load. Like I said, I do plan to add another setting to divide by the industry ticks to try and help scale the production. It's hard to find a good balance with the industry. Making it easier to get a complete train line before the trains get horribly old was a large part in my search to find a patch for the current versions so that's what I worked on first.
Re: Updated daylength patch for 1.4.1 and r26674
One of the classic problems with daylength patches is that even though you've slowed down time, the payment for cargo has not been equally reduced to compensate. Therefore the higher the daylength you select, the more money you end up making per day, and in a short amount of time you're easily a millionaire.
Do you like drones, quadcopters & flying toys? Check out Drone Strike Force!
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | GarryG's Auz Sets
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | GarryG's Auz Sets
Re: Updated daylength patch for 1.4.1 and r26674
Patch was compiled successfully after minor revisions (settings_gui.cpp) using Linux gcc,
but compilation failed in case of Microsoft VC++ 10 - C2864 error because of byte daylength = 1 declared in struct EconomySettings.
Where I should properly initialise this variable? In afterload.cpp ?
but compilation failed in case of Microsoft VC++ 10 - C2864 error because of byte daylength = 1 declared in struct EconomySettings.
Where I should properly initialise this variable? In afterload.cpp ?
Re: Updated daylength patch for 1.4.1 and r26674
Finally I overcome Visual C++ error and assertion issue by initialisation _settings_newgame.economy.daylength = 1
in openttd.cpp main subroutine.
Basically patch is working well, but I have impression, that passenger generation/income is much to high in comparison to the 1x daylength factor.
I'm using FIRS with improved station ratings, therefore passengers are not affected by station rating.
in openttd.cpp main subroutine.
Basically patch is working well, but I have impression, that passenger generation/income is much to high in comparison to the 1x daylength factor.
I'm using FIRS with improved station ratings, therefore passengers are not affected by station rating.
Re: Updated daylength patch for 1.5.0 and r27185
Finally, there it is, patch working on r27185:
with cross-platform compilation enabled.
Additionally, another setting is provided: town production divider.
Despite of balance of day length factor itself, passenger and mail production level is often criticized, especially if cargodist is used or custom industry newgrfs.
Standard divider is 8, and with this patch, one can change it from 1 (insanely high production of houses) to 64 (very low number of passengers and mail).
Such divider affect only standard passenger and mail generation, not the custom one derived from callbacks.
with cross-platform compilation enabled.
Additionally, another setting is provided: town production divider.
Despite of balance of day length factor itself, passenger and mail production level is often criticized, especially if cargodist is used or custom industry newgrfs.
Standard divider is 8, and with this patch, one can change it from 1 (insanely high production of houses) to 64 (very low number of passengers and mail).
Such divider affect only standard passenger and mail generation, not the custom one derived from callbacks.
Last edited by Wahazar on 24 Apr 2015 16:49, edited 1 time in total.
Formerly known as: McZapkie
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
Re: Updated daylength patch for 1.4.1 and r26674
Let s consider a train going from A to B, and running always full of passenger (not waiting for full load, just many passenger waiting at stations)McZapkie wrote:impression, that passenger generation/income is much to high in comparison to the 1x daylength factor.
I'm using FIRS with improved station ratings, therefore passengers are not affected by station rating.
now let s consider consider trip from A to B takes 100 days (with normal daylenght),
this same train with daylenght x2, will only need 50 days.
So you can expect vehicule with any daylenght to improve their revenue PER YEAR
Now let s consider cargo aging (if daylenght don t modificate it at all), EACH TRIP with a daylenght x2 should give you a better payment than with daylenght x1, because people pay more for travelling faster (50 days against 100)
In term of Profit/Rentability, a daylenght x2, means you need 2 times less vehicles to transport the same amount of cargo as with daylenght x1. It also gives a overall profitability boost to your company, so this too will "make you think some business became too profitable (less investment for same quantity of cargo transported and eventually better paid cause faster delivered)
Now FIRS or station ratings has nothing to do with difference of payment. Eventually, station rating could affect the number of passenger carried...but if you transport less people you canno t make any "sane" comparison of profitability.
Note that freigh benefit the same way from daylenght, but with FIRS it s hard to notice at begin because the low production level make the capacious vehicles wait a long time at station (for full load) wich probably reduce the advantage of "fast delivery payment". Also Freight are much less sensitive to the fast delivery payment than is passengers.
Now, you might think that with running cost that are doubled(for daylenght x2) we should not see the profit bump as much, but running cost are a "fix" cost (even at x2), while the cargo because of faster delivery is not a "fix revenue" but simply get greater and greater (the more daylenght, the more profit effect)
that s my analysis of the situation, i could be wrong, but basically that s what i always experienced with any daylenght (and that s what i tried to explain you on your server last night )
Re: Updated daylength patch for 1.4.1 and r26674
In case of this patch, cargo aging is unaffected:
Secondly, you should not consider yearly income (obviously it would be greather if days are longer),
but compare same real time period.
Code: Select all
static const int CARGO_AGING_TICKS = 185; ///< cycle duration for aging cargo
...
this->info.cargo_age_period = CARGO_AGING_TICKS;
but compare same real time period.
Re: Updated daylength patch for 1.4.1 and r26674
McZapkie wrote:In case of this patch, cargo aging is unaffected:
are you really sure that it s meaning cargo aging is "adapted" to the daylenght setting ?james.a.wagner3 wrote:cargo aging are not affected by the multiple.
I can t read code, but personnaly when i read that cargo aging is "unaffected" I expect it to be unrelated to daylenght, wich would mean with daylenght you transport everything faster= better payments (since the cargo aging is not affected, how could it be scaled to daylenght)
and about the yearly income comparison, my way is totally valid way to compare profit, i could just not guess that you are comparing profitability/real time...
Re: Updated daylength patch for 1.4.1 and r26674
You are not transporting everything faster. Vehicle speed is the same tiles per ticks.
Common misunderstanding is, that there are game days used for calculations.
Internally there are ticks, for example:
Above is the original code, which is unaffected. Game day last longer, for example 74 * 2, and therefore cargo aging intervals (which are still 185) are equal 1.25 of game day instead of 2.5, finally, you should get same income from one train at the certain distance, regardless of daylength factor (I checked it with the saved game, 4x larger daylength gives approximately the same income for food and chemicals, even slightly (10%) smaller due to longer waiting for full load).
Summarizing, most of the game calculations are based on ticks, not days, and there is no need to adjust anything.
Real issues are in case of monthly and yearly based calculations, especially mixed ticks and date based industry production calculations.
regardless of daylength setting.
Yearly income is irrelevant, imagine that you are playing scenario (without building new tracks), instead from 1950-2050, in 1950-2150 time span, and all vehicles are always available.
You would expect 2x greater income from 2x longer game, right?
Same if daylength is x2, yearly income is x2 greater but you must wait 2x longer for it, I think it is OK.
Common misunderstanding is, that there are game days used for calculations.
Internally there are ticks, for example:
Code: Select all
inline byte DaysInTransit() const
{
return this->days_in_transit;
}
/* Gets the number of days this cargo has been in transit.
* This number isn't really in days, but in 2.5 days (CARGO_AGING_TICKS = 185 ticks) and
* it is capped at 255.
* @return Length this cargo has been in transit.
*/
Summarizing, most of the game calculations are based on ticks, not days, and there is no need to adjust anything.
Real issues are in case of monthly and yearly based calculations, especially mixed ticks and date based industry production calculations.
What I expect is, that the given train have the same income from one turn, and the same running costs during that turn,the yearly income comparison, my way is totally valid way to compare profit, i could just not guess that you are comparing profitability/real time...
regardless of daylength setting.
Yearly income is irrelevant, imagine that you are playing scenario (without building new tracks), instead from 1950-2050, in 1950-2150 time span, and all vehicles are always available.
You would expect 2x greater income from 2x longer game, right?
Same if daylength is x2, yearly income is x2 greater but you must wait 2x longer for it, I think it is OK.
Formerly known as: McZapkie
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
Re: Updated daylength patch for 1.4.1 and r26674
ok i ll take your word for it ( i based my statement on the the impression i had that this daylenght is making "each" ticks longer...so i though that cargoaging ticks would also be slower)McZapkie wrote:cargo aging intervals (which are still 185) are equal 1.25 of game day
Ok, i understand better the importance to you for the profitability/real time.McZapkie wrote: What I expect is, that the given train have the same income from one turn....
Have you found what's the thing with passenger profit different then ?
Re: Updated daylength patch for 1.4.1 and r26674
I found a bug in this patch: yearly running costs were multiplied by daylength factor (to keep unchanged cos of running through same distance),
but it was multiplied only for GetRunningCost function in engine.cpp
and vehicles *_cmd.cpp, for example
which resulted in multiplication of value in purchase menu, but real accounting was unchanged.
I fixed it by applying in each vehicle *_cmd.cpp file:
where #define DAY_TICKS (74 * _settings_game.economy.daylength) ///< ticks per day
Now running costs are accounted with higher values, but still real annual costs are improperly calculated.
For daylength factor x1, total annual running costs are properly calculated, for 2x factor, costs are 2x higher in comparison to GetRunningCost function, for 4x factor, costs are 2x smaller (if compared to GetRunningCost()), for 8x factor, correctly calculated.
Any idea, what is missing?
but it was multiplied only for GetRunningCost function in engine.cpp
Code: Select all
Money Engine::GetRunningCost() const
...
cost_factor = (GetEngineProperty(this->index, PROP_ROADVEH_RUNNING_COST_FACTOR, this->u.road.running_cost) * _settings_game.economy.daylength);
...
Code: Select all
Money RoadVehicle::GetRunningCost() const
...
uint cost_factor = (GetVehicleProperty(this, PROP_ROADVEH_RUNNING_COST_FACTOR, e->u.road.running_cost) * _settings_game.economy.daylength);
...
I fixed it by applying in each vehicle *_cmd.cpp file:
Code: Select all
void RoadVehicle::OnNewDay()
{
...
CommandCost cost(EXPENSES_ROADVEH_RUN, this->GetRunningCost() * this->running_ticks * _settings_game.economy.daylength / (DAYS_IN_YEAR * DAY_TICKS));
Now running costs are accounted with higher values, but still real annual costs are improperly calculated.
For daylength factor x1, total annual running costs are properly calculated, for 2x factor, costs are 2x higher in comparison to GetRunningCost function, for 4x factor, costs are 2x smaller (if compared to GetRunningCost()), for 8x factor, correctly calculated.
Any idea, what is missing?
Formerly known as: McZapkie
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
Re: Updated daylength patch for 1.4.1 and r26674
If I read the patch correctly, this is limit to a multiplier of 31, right?
I would really like to run a game so that 1 ingame year matches exactly with 1 real day.
That would require a multiplier of 118.39, or 8761 ticks per day. (resulting in something like 3 real-life minutes and 56 seconds per game day).
Could I just change the "max = 31" to something higher, or will I run into integer range overflows and crash my game or -worse-, loop some integers?
I would really like to run a game so that 1 ingame year matches exactly with 1 real day.
That would require a multiplier of 118.39, or 8761 ticks per day. (resulting in something like 3 real-life minutes and 56 seconds per game day).
Could I just change the "max = 31" to something higher, or will I run into integer range overflows and crash my game or -worse-, loop some integers?
Re: Updated daylength patch for 1.4.1 and r26674
very likely, but nobody ever made sure that this doesn't already happen with 31... or 2...Rull wrote:or will I run into integer range overflows and crash my game or -worse-, loop some integers?
Re: Updated daylength patch for 1.4.1 and r26674
Never mind, I took another approach.
I would have no problem earning the same amount per trip, and scaling running cost like you attempt.
However, there are a few problems with that.
Firstly, running cost doesn't actually scale (With daylength at x100, running cost did correctly display as $300,000 a year instead of 3,000$. But game-days only charged for $7 in terms of vehicle individual profit number, the monthly balance and the actual money subtraction.)
More importantly, with that fixed, you would also need to rebalance vehicle purchase cost to keep that significant (otherwise just buying the lowest running cost vehicle far outweighs that).
Also, taxes on your loan still work on yearly basis, as does inflation, and vehicle maintenance, breakdowns, etc.
I don't think you can really claim it will be a normal game, just stretched.
So I turned it around. Instead of increasing running costs and everything else along with it, I just decreased income.
With income divided by 100, my vehicle nets me like 5$ a trip. It does 3 trips a day, so that amounts to still 5,000$ a year. It still costs 3,000$ a year to run, so it makes the same profit per year.
I know this wasn't what you were going for, initially it wasn't what I was trying to do either, but it works fantastic for me.
I guess the variant with vehicle prices, debt, inflation, construction cost, etc. scaled would be fun as well though.
I would have no problem earning the same amount per trip, and scaling running cost like you attempt.
However, there are a few problems with that.
Firstly, running cost doesn't actually scale (With daylength at x100, running cost did correctly display as $300,000 a year instead of 3,000$. But game-days only charged for $7 in terms of vehicle individual profit number, the monthly balance and the actual money subtraction.)
More importantly, with that fixed, you would also need to rebalance vehicle purchase cost to keep that significant (otherwise just buying the lowest running cost vehicle far outweighs that).
Also, taxes on your loan still work on yearly basis, as does inflation, and vehicle maintenance, breakdowns, etc.
I don't think you can really claim it will be a normal game, just stretched.
So I turned it around. Instead of increasing running costs and everything else along with it, I just decreased income.
With income divided by 100, my vehicle nets me like 5$ a trip. It does 3 trips a day, so that amounts to still 5,000$ a year. It still costs 3,000$ a year to run, so it makes the same profit per year.
I know this wasn't what you were going for, initially it wasn't what I was trying to do either, but it works fantastic for me.
I guess the variant with vehicle prices, debt, inflation, construction cost, etc. scaled would be fun as well though.
Re: Updated daylength patch for 1.4.1 and r26674
Two remarks to the patch.
1. Station rating recalculation (station_cmd.cpp):
delete_ctr is increasing every tick by one and if it becomes equal STATION_RATING_TICKS, station rating is calculated.
BUT delete_ctr is BYTE. For example I'm using day length eq 10. STATION_RATING_TICKS will be 1850. But delete_ctr will overflow on 256 and station rating will calculated not every three days, but seven times a day.
2. Town behaviour issue (town_cmd.cpp):
time_until_rebuild set a time in ticks to delete one house and build another. In my experience, when this live unchanged, with high day length town doesn't grow, even if it have to grow, but it completely rebuild. And it's population also may decreese. But no new buildings will be build.
1. Station rating recalculation (station_cmd.cpp):
Code: Select all
/* called for every station each tick */
static void StationHandleSmallTick(BaseStation *st)
{
if ((st->facilities & FACIL_WAYPOINT) != 0 || !st->IsInUse()) return;
byte b = st->delete_ctr + 1;
if (b >= STATION_RATING_TICKS) b = 0;
st->delete_ctr = b;
if (b == 0) UpdateStationRating(Station::From(st));
}
BUT delete_ctr is BYTE. For example I'm using day length eq 10. STATION_RATING_TICKS will be 1850. But delete_ctr will overflow on 256 and station rating will calculated not every three days, but seven times a day.
2. Town behaviour issue (town_cmd.cpp):
Code: Select all
/**
* Tile callback function.
*
* Periodic tic handler for houses and town
* @param tile been asked to do its stuff
*/
static void TileLoop_Town(TileIndex tile)
{
...
if ((hs->building_flags & BUILDING_HAS_1_TILE) &&
HasBit(t->flags, TOWN_IS_GROWING) &&
CanDeleteHouse(tile) &&
GetHouseAge(tile) >= hs->minimum_life &&
--t->time_until_rebuild == 0) {
t->time_until_rebuild = GB(r, 16, 8) + 192;
ClearTownHouse(t, tile);
/* Rebuild with another house? */
if (GB(r, 24, 8) >= 12) BuildTownHouse(t, tile);
}
...
}
Who is online
Users browsing this forum: No registered users and 12 guests