News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Forge costs

Started by Ves, September 30, 2017, 09:29:55 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ves

Hi James,
Reading another thread mentioning forge costs, I could not think of anyplace that is displayed in the game?
How would you suggest to display the cost and wether it is already forged to the player?
Where in the code can the cost be found?

jamespetts

I do not think that this is currently displayed. The relevant code for calculating this is in sint64 way_builder_t::calc_costs().

As to the best way of displaying this, this is not an easy question; perhaps in the tooltip displayed when a way is dragged?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

I was having a look, and found neuen_weg_bauen() where there where some calculations. I initially tried to copy the calculations to the ground info window to see what it said, and it did show up some costs, however it was not consistent (probably due to a mistake on my side).

I will look at the way_builder_t::calc_costs().

I was thinking of two things:
First, along with splitting the tooltip in two, showing a forge cost and a build cost, the value could as well be shown in the ground info, if no other roads or buildings is on it. A small text would tell what it means, and why a value seems lower some places than other. Either one value pr waytype, alternatively only the most common ones (road, rail and air). Since there is nothing else in the window, however, I think all could be displayed.

Second, would it be possible to create a get_forgecost(), so I dont have to duplicate all the calculations with the risici of errors? I note that the calculations in way_builder_t::calc_costs() seems identical to neuen_weg_bauen(), but there might be a reason? Where should this calculation in this case be placed?

jamespetts

I cannot remember now why I did not create a get_forge_cost() method - but reducing code duplication is always a good thing, all other things being equal - do feel free to do this if you can make it work (and get_forge_cost is better than get_forgecost, since "forge" and "cost" are separate words).

Your suggestions for how to implement this in the UI seem sensible, too, and should help people to understand how the costs are calculated. Thank you for htis.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Now I have created

double karte_t::get_forge_cost(waytype_t waytype, koord3d position)
{
sint64 forge_cost = get_settings().get_forge_cost(waytype);
const koord3d pos = position;

for (int n = 0; n < 8; n++)
{
const koord kn = pos.get_2d().neighbours[n] + pos.get_2d();
if (!is_within_grid_limits(kn))
{
continue;
}
const koord3d kn3d(kn, lookup_hgt(kn));
grund_t* to = lookup(kn3d);

const grund_t* gr_neighbour = lookup_kartenboden(kn);
if (gr_neighbour && gr_neighbour->get_weg(waytype))
{
// This is a parallel way of the same type - reduce the forge cost.
forge_cost *= get_settings().get_parallel_ways_forge_cost_percentage(waytype);
forge_cost /= 100ll;
break;
}
}
return forge_cost;
}

and linked it to the ground info window and it appears to work.

Some questions:
In its current implementation the value halves whenever the tile is next to an existing road, as I understand it should, however the value changes to full price again if the road next to it is deleted. So there is no memory of where there have been old roads, which I had imagined it should remember? Also tiles underneath the roads show the half cost, I thought the forge cost should be 0 here?
Could you elaborate how this mechanism works? Do I have to make the checks myself in get_forge_cost()?

Second, I do not feel comfortable making the way_builder_t::calc_costs(), and neuen_weg_bauen(), use this on my own. There are a bunch of parameters in those that I dont understand how to use or how to connect. Maybe you could do that at some point in the future?

Vladki

I think that mothballed roads are the way to avoid forge costs, and the way to remember where a road used to be.

Perhaps it should be more obvious how to mark roads obsolete than shift+drag.

Sent from my ONEPLUS A3003 using Tapatalk


Ves

If that is true, I would very much suggest a swap of the commands, if at all possible:
Destruction button turns the way into mothballed.
Destruction button + Ctrl removes the way completely and resets the forge cost.

That might, although, be quite difficult to change...?

jamespetts

Thank you for your work on this. I am not sure what you are referring to in relation to the two stated methods, as I cannot immediately remember precisely what they do without looking at the code in detail: does way_builder_t::calc_costs() calculate the cost that is paid by the player, or is this used only for AI? What parameters are you having trouble with?

In relation to old ways, remembering where ways used to be would be a whole new (and complex) feature and require a whole new data structure. Given that on a tile where a way once stood any number of things may have been built and destroyed in the meantime, hundreds of years might have elapsed, or any amount of earthworks done, there seems very little sense in reducing the way cost on the basis that, once upon a time, a neighbouring way stood on a tile.

As to swapping mothballing commands, I do not think this sensible: players reasonably expect things to go away if one deletes them. Mothballing is a very specific thing, keeping the infrastructure, but rendering it unusable and free to maintain for the time being. This is fundamentally different to deleting and should not share the same command.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

I was wondering where actual calculations for the forge cost where done, or wether it is always calculated directly in, say way_builder_t::calc_costs().
Since my own code returns the "parallel cost", even though the tile already has a way, it suggests that I have to make that check for my self and return "0" if there is a way already on the tile?

What I will be having problems with is to make way_builder_t::calc_costs() and neuen_weg_bauen() to use my code.

jamespetts

I must confess that I cannot now recall precisely where the calculations are done; I should have to work out from the code where this occurs in the same way as you, I imagine. I am not sure what you mean by the second sentence - can you elaborate?

When you refer to having problems making those methods use your code, what did you want your code to do such that it needs to alter those methods? I thought that you just wanted to display the forge cost in the GUI?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

yes, I only want to display it in the GUI, however, I am now doing the calculations in parallel to in way_builder_t::calc_costs() and neuen_weg_bauen() We talked about earlier that it might be a good idea to have not three parallel calculations, but only one.
I am, however, done with the get_forge_cost(), and I have created another one which returns true or false dependent on wether the forge cost is reduced in any way, and it is everything available on here: https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/gui-classes

jamespetts

I should note that I am currently staying with my parents, and cannot easily work on or look into the code, so forgive me for not being able to give as comprehensive a set of replies as I might prefer to be able to give.

Can I check - is the problem with get_forge_cost() that it does not take account of the parallel way discount, or is there some other issue?

Also, can I check that you have added the appropriate .dat files for any new translation texts?

Thank you very much for your work on this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Well, the get_forge_cost() do indeed take into account of the parallel ways (or rather, it checks for any adjecant waytiles), and I have added a check to return 0 if there already is a waytype of the same type as we are returning the costs for on the tile.
So there are no problems with that in this sence.

It is only a question of code duplication.

No, I have omitted the base text file from the commit, since I want to keep it and populate with all the classes gui.

edit
Changing the tooltip seems a bit harder than I initially thought. I might do that at some point, but I dont think for now unfortunately.

jamespetts

Ahh, is this based on the passenger-and-mail-classes branch rather than the master branch?

Thank you again for your work on this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves


jamespetts

Splendid, thank you for clarifying.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.