Topic: Getting rid of the green balls in the immovable bobs menu tabs

Can anyone tell me what needs to be done to have meaningful icons there
instead of the green balls?
Anything I could do?

Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top

Quote

I have been looking into this and doing so, two ideas emerged.
Just "first thoughts" so far, but since SirVer seems to be already at revamping the editor,
I should bring them up now.

1) Many of the immovable and critters - even trees- are really linked logically to the terrain type.
You would want to place a cactus in a desert, but not a fern.
Skeletons and dead trees look more appropriate in swamps and deserts, than on green pasture.
A chamois is an animal for mountain terrain, but not for swamps.
You can only place tracks on a soft surface (snow, sand),
and so on....

2) We should go for quite a few more items in the editor; many things are missing, that would be nice to have.
By doing so, it becomes ever more important to sort the items according to how frequently you will need them, and
a simple display to show what is available may not be helpful.

So, I am wondering, whether it may not be a good idea to have a dynamic sorting of all bobs, rather than a static one,
and so have some intelligence built into the editor.
I don't want to prevent anyone from placing a reindeer in a desert, but I'd offer camels, snakes and scorpions first on the list of "placeable items".
And maybe we could give up the distinction between movable and immovable for the editor UI.

Sorted list could be created for each terrain type, and displayed depending on:

• the terrain under the mouse cursor (nice!)
• the predominant terrain on screen currently
• or user chosen from a list of terrains. (not so helpful)

As always, I cannot judge about the feasability or effort and whether it's worth the benefit.
Others can

Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top

Quote

Hehe, I can give that right back, Nasenbaer: I understand your point!
It is the view of someone who has done much work inside the editor, and has well learned to use it, as it is.
So, "no change" probably guarantees the fastest workflow for you.

One of the things, that I had in mind with the dynamical lists, was to attract newcomers a bit more to that task,
as it is something that can be done without programming skills (leaving LUA out of the picture for the moment).
Another side-effect was to endorse a meanigful choice.
The negative part is clearly to force a re-learning onto experienced users like yourself --
but that can't be helped, unless the Editor is left unchanged.
Your opinion surely counts a lot here for all the map-making experience that you have.
But who knows, even experienced users might find a new sorting helpful, if it is done in a logical way,
and though the order changes from terrain to terrain, at some point, everybody will find his way there too.

Yes, we will need some submenus as the items get more, but must be careful not to introduce more of them than is necessary.
A good balance of visible map area vs. more clicks for the choice must be found.

Independant from that, I think the trees take too much visible space in the picklist.
I would rather see them in a tree submenu - but the option to create you own custom tree paintbrush of all species and sizes
must be kept; I think it is superb feature.

The same is true for the different sizes of harvestable stones, and might be adressed in a similar way.
And of course different pictures are better than just green dots.
Whether a new, more generic picture, or, as you suggest, just the first one of the group would be better,
will depend on the content of the group in question.

Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top

Quote

I personally like Nasenbaer's options A and B about equally. There is a parallel to how wares and workers were put into meaningful groups manually, and doing the same type of thing for the immovables in the editor seems like a good idea.

A lot of the "secondary" immovables such as the small trees could be moved into some "additional items" category, making it easier to select the "primary" immovables that you want (tree types).

Top

Quote