Important Dates

Latest Posts

Topic: To all map creators; Terrain menu

kaputtnik
Avatar
Topic Opener
Joined: 2013-02-18, 20:48
Posts: 2514
OS: Archlinux
Version: current master
Ranking
One Elder of Players
Location: Germany
Posted at: 2015-04-07, 14:12

Thanks for your explanation of "global fertility".

Every tree can have different value. Even if you pick only one biome (coniferes, deciduous, ... ). Imagine that there can be soil where are significant changes between birch and aspen (both deciduous), also coniferes trees will grow in good way: better than aspen, worse than birch.

Yes, that would be a problem if there are more than 4 sort of trees which do grow on a specific terrain type. Are there more than four?

Ok, lets say we use your suggestion and want to add more flexibility to mapmakers by adding more terrains to each biome (something that i want: more colored flexibility). F.e. we add more mountain terrains to "Summer" which are colored different. Currently there are four mountain terrains and we add four further mountain terrains. I imagine this also for "normal" terrains (f.e. add more beach terrains). The result is that the menu will grow in a huge way and, we need two tabs for the "Summer" biome... and maybe two tabs for each Wnter/Blackland/Desert biome.

GunChleoc wrote:

Maybe the tree affinity information shouldn't come with the terrain tool, but with the "place trees" tool?

Yes, i thought also in this direction. Best would be to have both: HInts to trees in the terrain menu + hints to terrains in the "place tree" tool. The trees have great importance and the importance should be reflected in the menus.

For the tree type currently picked to be placed, add a colored overlay to the map that represents the tree's affinity to each terrain tile on the map.

That would be great. I think this overlay should allready be shown, when terrains are placed on the map. Thats because normally terrains are first placed, and afterwards the trees are placed. So if the overlay is only shown after all terrains are placed, the mapmaker see mistakes (of terrain placing) too late.

As to the tabs in the terrain tool, looks like we have 2 different strategies used to create a map, and we might not find consensus. Maybe we need to add both tab models to the tool?

Yes, this would be the best: Add a switch-button which toggles the menu from "Biome mode" to "colored mode" (or "buildability mode") and vice versa. face-smile.png

Another idea: Add the possibility to filter the terrains to specific sort of trees. F.e. add checkboxes for each sort of tree. Checking some of the boxes restrict the terrains to those which are good for this kind of trees. All other terrains disappear. Hmmm...


Top Quote
einstein13
Avatar
Joined: 2013-07-29, 00:01
Posts: 1116
Ranking
One Elder of Players
Location: Poland
Posted at: 2015-04-07, 16:53

kaputtnik wrote:

Every tree can have different value. Even if you pick only one biome (coniferes, deciduous, ... ). Imagine that there can be soil where are significant changes between birch and aspen (both deciduous), also coniferes trees will grow in good way: better than aspen, worse than birch.

Yes, that would be a problem if there are more than 4 sort of trees which do grow on a specific terrain type. Are there more than four?\

Yes, there are 16 (?) types of trees, each can grow with on every type of terrain with different affinity.

Ok, lets say we use your suggestion and want to add (...) more terrains to each biome (...)The result is that the menu will grow in a huge way

This result will be always, even with your suggestion. If we add enough terrain types, we will have lots of terrain types in every tab. Your idea has more complex choosing -> more tabs -> the number to reach "too many terrain types on each tab" is smaller.

GunChleoc wrote:

Maybe the tree affinity information shouldn't come with the terrain tool, but with the "place trees" tool?

With one tree type it is possible, but:

For the tree type currently picked to be placed, add a colored overlay to the map that represents the tree's affinity to each terrain tile on the map.

Imagine that you are choosing multiple types of trees. What should be displayed then?

kaputtnik wrote:

The trees have great importance and the importance should be reflected in the menus.

I don't think that it is needed there. It should be explained somewhere else.

GunChleoc wrote:

As to the tabs in the terrain tool, looks like we have 2 different strategies used to create a map, and we might not find consensus. Maybe we need to add both tab models to the tool?

As I mentioned before, it will bring lots of complexity to the editor. Some kind of "Options" for editor? It is possible to code, but lots of coding.

kaputtnik wrote:

Another idea: Add the possibility to filter the terrains to specific sort of trees. F.e. add checkboxes for each sort of tree. Checking some of the boxes restrict the terrains to those which are good for this kind of trees. All other terrains disappear. Hmmm...

How do you expect to work that idea? All the terrain <-> tree match is a number betwen 0.0 and 1.0. So how do you expect to "choose" the terrain type? With 50%? And if there will be a tree wchich will not work in ANY of terrain type above 50%? What then? Or there will be a tree very flexible (every terrain > 50%)? What then? The idea is good to think of, but there are dozens of problem to have good algorithm for that.

Sorry that this sounds like I am a hater to that idea, but it will simply not work with saying "checkbox and look for that". It needs LOTS OF math/algorithm/anything to put inside.


einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top Quote
kaputtnik
Avatar
Topic Opener
Joined: 2013-02-18, 20:48
Posts: 2514
OS: Archlinux
Version: current master
Ranking
One Elder of Players
Location: Germany
Posted at: 2015-04-07, 20:40

Yes, there are 16 (?) types of trees, each can grow with on every type of terrain with different affinity.

I read this like "every tree do grow on every terrain"? That isn't true.... in don't find the failure of my understanding.

The trees have great importance and the importance should be reflected in the menus.

I don't think that it is needed there. It should be explained somewhere else.

I totally disagree with this. I don't say that all the complexity of trees should be shown, but hints about them must be in the editor to prevent frustration of the user. We have discussed this earlier.

Hmmm...

This should show that this idea wasn't ready, it was just a thought while writing the post. Also this should show that i don't stick on my suggestion face-smile.png

On which points do we agree? It's frustrating...


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3317
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2015-04-07, 22:53

einstein13 wrote:

GunChleoc wrote:

Maybe the tree affinity information shouldn't come with the terrain tool, but with the "place trees" tool?

With one tree type it is possible, but:

For the tree type currently picked to be placed, add a colored overlay to the map that represents the tree's affinity to each terrain tile on the map.

Imagine that you are choosing multiple types of trees. What should be displayed then?

I was assuming that one can only place 1 tree type at the same time.

einstein13 wrote:

GunChleoc wrote:

As to the tabs in the terrain tool, looks like we have 2 different strategies used to create a map, and we might not find consensus. Maybe we need to add both tab models to the tool?

As I mentioned before, it will bring lots of complexity to the editor. Some kind of "Options" for editor? It is possible to code, but lots of coding.

Actually, not lots - at the moment, each terrain has 1 editor category assigned in the Lua init. If we change the coding around a bit to have a list of categories instead, the same terrain could be added to multiple tabs. It would take some time to edit all the files, but the coding wouldn't be too complex. If we add an option button, that would take some more coding, but if we just add a few more tabs, it shouldn't be too much of a problem.

kaputtnik wrote:

Yes, there are 16 (?) types of trees, each can grow with on every type of terrain with different affinity.

I read this like "every tree do grow on every terrain"? That isn't true.... in don't find the failure of my understanding.

In principle, they could grow on many terrains at least (unless it's water etc), but for some the chance is just extremely small that they will survive past the seed stage. Probabilities are always fluid.

kaputtnik wrote:

The trees have great importance and the importance should be reflected in the menus.

I don't think that it is needed there. It should be explained somewhere else.

I totally disagree with this. I don't say that all the complexity of trees should be shown, but hints about them must be in the editor to prevent frustration of the user. We have discussed this earlier.

How about displaying the top 4 trees with the highest affinity? Or as many as icons fit in a row on the terrain square. Then add the info on the tooltip that more tree types might grow there.


Busy indexing nil values

Top Quote
einstein13
Avatar
Joined: 2013-07-29, 00:01
Posts: 1116
Ranking
One Elder of Players
Location: Poland
Posted at: 2015-04-08, 00:42

kaputtnik wrote:

Yes, there are 16 (?) types of trees, each can grow with on every type of terrain with different affinity.

I read this like "every tree do grow on every terrain"? That isn't true....

That is true. The possibility of growing the tree is always above 0. It can be very small.

On which points do we agree? It's frustrating...

Basic point: we should change the layout to bring some more information to the editor.

GunChleoc wrote:

(...) How about displaying the top 4 trees with the highest affinity? Or as many as icons fit in a row on the terrain square. Then add the info on the tooltip that more tree types might grow there.

I didn't told that there should be none infromation, but not all. Also bringing all the infromation will frustrate new players. For sure.

I think that tooltip information is the best place for that. Is it possible to show part of tooltip after time delay? It would be even much better, because any additional information will bring less space to see other terrain type images. I don't like when tooltip hide more important information.


einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3317
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2015-04-08, 10:06

einstein13 wrote:

I think that tooltip information is the best place for that. Is it possible to show part of tooltip after time delay? It would be even much better, because any additional information will bring less space to see other terrain type images. I don't like when tooltip hide more important information.

No, we can't have a time delay on tooltips. Good idea about putting tree info into them though, they can have multiple rows, like when building or dismantling a building where the resources are shown.


Busy indexing nil values

Top Quote
einstein13
Avatar
Joined: 2013-07-29, 00:01
Posts: 1116
Ranking
One Elder of Players
Location: Poland
Posted at: 2015-04-08, 10:47

GunChleoc wrote:

Good idea about putting tree info into them though,

I thought that it was your idea ;P

I'm waiting for kaputtnik: do you think that it is good idea? Will it bring all the information you need?

they can have multiple rows, like when building or dismantling a building where the resources are shown.

We can try to add some lines with 'best fit', as you suggested. First idea (your) is to bring 4 best fit trees. Second- my - just to try 6 of them. It is lots of lines and I don't know if it will look good.

But there is also another idea: to sort the affinities and pick the number of shown species dynamically. For example if we have affinities like {90%, 85%, 5%, 3%, 2%, ...} it is good to show only first two. Another example(*): {10%, 9%, 7%, 5%, ...} it is good to put first 4 or 6 OR put information "all species: bad behaviour". It can be mathematically calculated, how many species should be shown, but also we need tree-specie-number-limit (4? 6?), because if we have "optimal soil" it will bring lots of species, so there will be loooong list.

( * ) - for sure barren steppe from summer brings all affinities less than 1%. Almost none trees can grow there.


einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3317
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2015-04-08, 15:57

einstein13 wrote:

GunChleoc wrote:

Good idea about putting tree info into them though,

I thought that it was your idea ;P

Just to make sure that we are talking about the same thing: My original suggestion was for little icons appearing on top of the terrain graphic in the menu, with a limit on how many we could display before you can't see the terrain icon full of trees (scnr).

The tooltip is what appears when you hover your mouse over something - there would be sufficient space for all tree types there.

E.g. we could have one little icon with the most frequent tree type or a "generic" tree, and when you hover you see all of them ranked by their affinity, and some appropriate coloring in the background for each of them. Or a text with the affinity in %.


Busy indexing nil values

Top Quote
einstein13
Avatar
Joined: 2013-07-29, 00:01
Posts: 1116
Ranking
One Elder of Players
Location: Poland
Posted at: 2015-04-09, 01:16

GunChleoc wrote:

einstein13 wrote:

GunChleoc wrote:

Good idea about putting tree info into them though,

I thought that it was your idea ;P

Just to make sure that we are talking about the same thing: (...)

Yes face-smile.png I understood my mistake very soon. face-smile.png So I wrote "thought", not "think" face-smile.png

we could have one little icon with the most frequent tree type or a "generic" tree,

If it is a biome type (deciduous, palms, coniferous, wasteland trees)- it is the best idea. I was thinking about tooltip for some time and I think that the information there will be not enough or too much. If you have to read dozens of words, you'd rather use your brain & memory. If you have one icon for biome, you don't have to remember all things. Then you can read more specific information (tooltip) to know more. And if you want to know everything about the terrain type- you have to go for manual (article/ wiki/ another work about affinity/ own calculations).

So my current idea is to add one small icon of type of biome for each terrain type and short information in tooltip about best fit trees. Number of them can be discussed later.

you see all of them ranked by their affinity,

I don't think that all of them should be shown. Some (4 or 6) is the best.

and some appropriate coloring in the background for each of them. Or a text with the affinity in %.

Percentage is not the best idea here. Most of numbers are useless for common people. They can see the difference, but they don't feel it. There is (almost) no difference between 66% and 67%, but most people will see both values with huge difference. The coloring can be better idea. Simplier and more intuitive: you can see that there is almost no difference between tree types/ terrain types (for example on meadows, summer).

Also about coloring: I would pick standard coloring from red to green: red - (orange) - yellow - (lime green) - green. Simple to understand and simple to show in RGB mode face-smile.png


einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3317
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2015-04-09, 13:15

I would be for using graphics in the tooltip and no text there. Let's not use the numbers, you have a good point there.


Busy indexing nil values

Top Quote