Topic: Altitude indicator and undo at all possible?
Astuur![]() Topic Opener |
Posted at: 2011-04-21, 18:45
I'm currently trying to get more used to the Editor. 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. ![]() ![]() |
ixprefect |
Posted at: 2011-04-22, 06:42
An altitude indicator should be really easy to do. An "undo" function is of of course technically possible, but it may require a major re-architecting of how the editor works internally. I'm not really familiar enough with those internals to estimate how difficult that would be. ![]() ![]() |
Astuur![]() Topic Opener |
Posted at: 2011-04-22, 08:32
Thanks, that is good news As for an Undo function, -- well, save and reload is an alternative, albeit not a comfortable one. I am currently starting from an automatically generated map. There is another question I'd like to ask:
I am trying to create an area in a map that would allow buildings of medium size (yellow), 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. ![]() ![]() |
SirVer |
Posted at: 2011-04-23, 14:01
I cannot answer the question with big <-> medium buildings. You might achieve better control with immovables that cannot be removed though. About the undo feature: beside the major redesign it would need, it is also quite hard to achieve as some actions are not easily reversible. E.g. if you change the height of one field on a flat terrain to 30 or so, the neighbouring fields change as well. This is not done by the editor but by the map recalculation. One would need to cache the complete height map in each step to make this reversible. Of course this is a technicality and should not be an excuse for not having undo support. ![]() ![]() |
Astuur![]() Topic Opener |
Posted at: 2011-04-23, 15:04
OKay, maybe someone capable feels like takling this. 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. ![]() ![]() |
ixprefect |
Posted at: 2011-04-26, 18:19
Height differences only account for whether one can build big or small buildings. Medium-size build icons can only appear when there are other immovables in the vicinity, especially roads. ![]() ![]() |
Astuur![]() Topic Opener |
Posted at: 2011-04-26, 18:50
Ah -- thank you. Edited: 2011-04-26, 19:00
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. ![]() ![]() |
ixprefect |
Posted at: 2011-04-26, 23:07
The reason is mostly historical. When we first wrote the buildcaps computation, we tried to keep the results close to those of Settlers 2, so that S2 maps could be loaded in Widelands without too many changes. And now changing the way those computations are done comes with a lot of pain because changing those calculations requires us to go over the existing maps again to make sure none of them are broken by the changes. So even though strictly speaking, it would be logically consistent to have a range of height differences that eliminates big buildings but not medium ones, there is a lot of inertia and changing those computations seems a bit daunting to me. ![]() ![]() |
Astuur![]() Topic Opener |
Posted at: 2011-04-27, 08:03
It's always a great pleasure to be rewarded for asking simple questions with such in-depth explanations! I guess this is the same fragment of code that does the "smoothing" of the landscape altitudes? The comparison also made me realize how superior the WL editor really has become! Do you think this can be done at reasonable effort? 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. ![]() ![]() |
ixprefect |
Posted at: 2011-04-27, 16:19
We still want to be able to load those old maps, even though direct compatibility has become less important over time. For example, if you really want to play S2 maps in Widelands, you almost always have to adjust the resource distribution. Still, this is one of those things where not just compatibility with S2 matters, but also compatibility with Widelands itself (existing maps and so on). As for merging the worlds into one so that all terrain types can be used within a single map, I like this idea as a long term goal. Of course we need to think about how the different immovables (such as different tree types) interact with such a merger. It shouldn't really be a problem in terms of map compatibility, we just need to establish a dictionary that translates the old "separate world" terrain and immovable types into the new ones. Your inquiry about cliffs and friends is a good one. I remember we had a discussion about possibly adding cliffs not so long ago. I think they could be realized with a combination of altitude changes and something like an additional object - the good old fake approach to cliffs, seen in so many strategy games from I believe the original Dune to StarCraft, to Age of Empires. But it's not a minor change to allow consistent, unbroken cliffs, so it really requires an intense combination of code and artwork for a proper implementation. Finally, about the "shape" of the tool for changing the terrain, I am also not too happy. In my opinion, the smallest tool size should change individual triangles of the terrain, and all larger tool sizes should change an entire hexagon of the terrain, to make it easier to create smooth coastlines. I've added an entry on Launchpad to keep track of this: https://bugs.launchpad.net/widelands/+bug/771838 ![]() ![]() |