Topic: wouldn't it be nice to have a minable tree-friendly terrain?
GunChleoc |
Posted at: 2015-12-06, 19:16
Looks good to me The terrain names could also lose their numbers (meadow 1 to 4 => meadow) Busy indexing nil values Top Quote |
kaputtnik |
Posted at: 2015-12-06, 20:54
I still would like a tree master to have a look though The numbering is ok i think. Top Quote |
GunChleoc |
Posted at: 2015-12-06, 20:58
Definitely! Busy indexing nil values Top Quote |
kaputtnik |
Posted at: 2015-12-07, 22:18
I have finished Summer. The pictures are a result reading the last spreadsheet from king_of_nowhere. It would be good if he could approve my interpretation I used only images for terrains<->trees combinations which are may of most interest. This could be the maximum possible information in a two dimensional table But it looks nice Such an information in the editor (maybe over an help button or pressing F1 ?) would be really nice. But there is one disadvantage: Changing terrains affinities will cause much work on adjusting the in game help. Top Quote |
king_of_nowhere Topic Opener |
Posted at: 2015-12-08, 01:55
yes, looks good. The problem is accessibility. i tried to look in the wiki, but i could not find the page withoout your link. that page won't do much good if people won't see it Top Quote |
GunChleoc |
Posted at: 2015-12-08, 10:02
When the page is done, we should link it in: https://wl.widelands.org/wiki/Development/ https://wl.widelands.org/wiki/EditorHelpHelp/
We should calculate any such help on the fly from the existing terrain values and affinities. This way, no manual adjustments will be needed. Of course, we will need to look at the code first to see if this is possible. Edited: 2015-12-08, 10:04
Busy indexing nil values Top Quote |
king_of_nowhere Topic Opener |
Posted at: 2015-12-08, 11:49
i don't know if large popup windows of help text that 90% of people won't be intersted in would really be helpful. maybe in the lower bar, where there are the "tools", "buildhelp" "players", we could add another function "user manual" that would contain all the instructions, including that one. by the way, in such a manual we could add the information on the conditions of elevation needed for the terrain to be buildable: for all buildings, maximum difference of 1 beteween the building and its flag. For small buildings, maximum difference of 3 with adjacent corners. For medium and large buildings, maximum difference of 2 for a distance of 2 corners in all directions, and for large buildings in addition the 3 corners at W, NW and NE must be free from obstacles. Took me a while to figure those out. And I still don't know the conditions for mines. Top Quote |
GunChleoc |
Posted at: 2015-12-08, 14:35
+1 Busy indexing nil values Top Quote |
kaputtnik |
Posted at: 2015-12-08, 18:27
I've linked it already in https://wl.widelands.org/wiki/EditorHelpToolMenu/#terrain-tool and https://wl.widelands.org/wiki/EditorHelpToolMenu/#immovable-tool
Yes, of course Take a look at http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/logic/terrain_affinity.cc#L77 If you have a solution it would be good to have the result also here on the website encyclopedia. I think this is all much work... if i am ready with the wikipage and the forested mountain branch is merged i want to work on some stuff on the website including repairing the encyclopedia (even if we don't have the json export function for widelands yet). Top Quote |
GunChleoc |
Posted at: 2015-12-08, 22:24
The function probability_to_grow is executed on a node, which then takes into account the terrains of the top right, top left, and left neighbours. So, far, so good. However, it also calls field->terrain_r() and field->terrain_d(), which are 2 terrains - and completely undocumented in the code. So, before we can refactor this function to pull out the calculation for a single terrain, we need to track down what terrain.r and terrain.d mean. Busy indexing nil values Top Quote |