Updated daylength patch for 1.4.1 and r26674

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Post Reply
james.a.wagner3
Engineer
Engineer
Posts: 2
Joined: 04 Jul 2014 22:47
Location: Pennsyltucky, USA

Updated daylength patch for 1.4.1 and r26674

Post by james.a.wagner3 »

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.
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.
User avatar
kamnet
Moderator
Moderator
Posts: 8548
Joined: 28 Sep 2009 17:15
Location: Eastern KY
Contact:

Re: Updated daylength patch for 1.4.1 and r26674

Post by kamnet »

I'm not familiar with that version, how does this handle the issue of profit?
james.a.wagner3
Engineer
Engineer
Posts: 2
Joined: 04 Jul 2014 22:47
Location: Pennsyltucky, USA

Re: Updated daylength patch for 1.4.1 and r26674

Post by james.a.wagner3 »

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.
User avatar
kamnet
Moderator
Moderator
Posts: 8548
Joined: 28 Sep 2009 17:15
Location: Eastern KY
Contact:

Re: Updated daylength patch for 1.4.1 and r26674

Post by kamnet »

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.
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: Updated daylength patch for 1.4.1 and r26674

Post by Wahazar »

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 ?
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: Updated daylength patch for 1.4.1 and r26674

Post by Wahazar »

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.
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: Updated daylength patch for 1.5.0 and r27185

Post by Wahazar »

Finally, there it is, patch working on r27185:
dltgd_patch.diff
day lenght patch with town production divider
(12.77 KiB) Downloaded 117 times
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.
User avatar
romazoon
Tycoon
Tycoon
Posts: 1291
Joined: 20 Jun 2010 23:16

Re: Updated daylength patch for 1.4.1 and r26674

Post by romazoon »

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.
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)
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 ;) )
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: Updated daylength patch for 1.4.1 and r26674

Post by Wahazar »

In case of this patch, cargo aging is unaffected:

Code: Select all

static const int CARGO_AGING_TICKS        = 185; ///< cycle duration for aging cargo
...
this->info.cargo_age_period = CARGO_AGING_TICKS;
Secondly, you should not consider yearly income (obviously it would be greather if days are longer),
but compare same real time period.
User avatar
romazoon
Tycoon
Tycoon
Posts: 1291
Joined: 20 Jun 2010 23:16

Re: Updated daylength patch for 1.4.1 and r26674

Post by romazoon »

McZapkie wrote:In case of this patch, cargo aging is unaffected:
james.a.wagner3 wrote:cargo aging are not affected by the multiple.
are you really sure that it s meaning cargo aging is "adapted" to the daylenght setting ?
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...
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: Updated daylength patch for 1.4.1 and r26674

Post by Wahazar »

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:

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.
	 */
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.
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...
What I expect is, that the given train have the same income from one turn, and the same running costs during that turn,
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.
User avatar
romazoon
Tycoon
Tycoon
Posts: 1291
Joined: 20 Jun 2010 23:16

Re: Updated daylength patch for 1.4.1 and r26674

Post by romazoon »

McZapkie wrote:cargo aging intervals (which are still 185) are equal 1.25 of game day
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: What I expect is, that the given train have the same income from one turn....
Ok, i understand better the importance to you for the profitability/real time.


Have you found what's the thing with passenger profit different then ?
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: Updated daylength patch for 1.4.1 and r26674

Post by Wahazar »

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

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);
...
and vehicles *_cmd.cpp, for example

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);
...
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:

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));
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?
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.
Rull
Engineer
Engineer
Posts: 4
Joined: 16 Jul 2015 14:46

Re: Updated daylength patch for 1.4.1 and r26674

Post by Rull »

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?
Eddi
Tycoon
Tycoon
Posts: 8258
Joined: 17 Jan 2007 00:14

Re: Updated daylength patch for 1.4.1 and r26674

Post by Eddi »

Rull wrote:or will I run into integer range overflows and crash my game or -worse-, loop some integers?
very likely, but nobody ever made sure that this doesn't already happen with 31... or 2...
Rull
Engineer
Engineer
Posts: 4
Joined: 16 Jul 2015 14:46

Re: Updated daylength patch for 1.4.1 and r26674

Post by Rull »

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.
pi1985
Engineer
Engineer
Posts: 107
Joined: 16 May 2013 08:22
Location: Ukraine

Re: Updated daylength patch for 1.4.1 and r26674

Post by pi1985 »

Two remarks to the patch.
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));
}
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):

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);
	}
...

}
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.
Image
Image
Image.
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 12 guests