Topic: Important Editor Tasks

1 — 10 of 15 Posts 1 2 next »

toptopple Topic Opener Joined: 2013-10-30, 08:11 Posts: 156 At home in WL-forums	Posted at: 2016-12-05, 09:56 By principle this has been asked for before, but perhaps we can be more specific. I see a great need for the editor to allow for switching visibility of 3 map layers: - building spots (already implemented) - resources (not implemented) - immovables (not implemented) These layers should be selectable independently for the creation of the map view in a constitutive way. That means, if you switch off one layer, e.g. Immovables, the rest of the map shall be displayed as if the components of this layer are completely absent. This is important for judging the constitution of the other layers! To give you one example: if there are Immovables present on the map (trees, stones, alike) you cannot see how the ground works out e.g. with building spots or with terrain height when these "immovables" are actually removed in the game. Also you cannot trace Port Spaces, big building spots, etc. So when you switch off the Immovable layer, the rest of the map should render as if they were not present. Whether this is easy or difficult to implement I don't know. It depends on how the current implementation is modularised. Some keyboard shortcuts should be set up to allow these switches. Top Quote

king_of_nowhere Joined: 2014-09-15, 18:35 Posts: 1668 One Elder of Players	Posted at: 2016-12-05, 17:23 yeah, i already proposed it one or two years ago, but as far as i know, nobody worked on it. Edited: 2016-12-05, 17:23 Top Quote

GunChleoc Joined: 2013-10-07, 15:56 Posts: 3317 One Elder of Players Location: RenderedRect	Posted at: 2016-12-05, 20:35 Resources should be pretty easy, immovables will probably take some more work. Toggling the resources overlay has been on my personal wishlist for a long time now. So many branches, so little time... Busy indexing nil values Top Quote

toptopple Topic Opener Joined: 2013-10-30, 08:11 Posts: 156 At home in WL-forums	Posted at: 2016-12-06, 07:43 Can we prepare the implementation strategy here? 1. First to decide on the user interface matters! - which keyboard-keys to use for the toggles? - should there be buttons available for the toggle? - how to indicate the switch states (should be visible whether display of a layer is ON or OFF)? 2. Side effects of OFF states - tools to add/remove objects of the layer's object types are disabled - saving the map must undo all OFF states before continuing 3. Perfomance of OFF switch (layer L) - remove objects of L from constitutive lists of the map (?) - alternatively: make layer L itself a constitutive list of the map (and switch off visibility) - call complete recreation of map display 4. Perfomance of ON switch (layer L) - add objects of L to constitutive lists of the map (?) - alternatively: make layer L itself a constitutive list of the map (and switch on visibility) - call complete recreation of map display Edited: 2016-12-06, 07:52 Top Quote

SirVer Joined: 2009-02-19, 15:18 Posts: 1440 One Elder of Players Location: Germany - Munich	Posted at: 2016-12-06, 07:58 yeah, i already proposed it one or two years ago, but as far as i know, nobody worked on it. Actually I tried implementing layers because I thought it would be simple. I learned that with the current design it is more work than I was expecting and I never got around doing that extra work. I agree that it would be awesome! the implementation is largely dictated by our OverlayManager class that already handles the currently drawn icons. You ask it to show a graphic on one or many nodes and it will hand you back an identifier. Later you can toggle these graphics using this identifier. Top Quote

GunChleoc Joined: 2013-10-07, 15:56 Posts: 3317 One Elder of Players Location: RenderedRect	Posted at: 2016-12-06, 08:17 Regarding the UI, once I get around to doing the toolbar redesign that I have i mind, we would have a menu dropping up from the button, with an entry for each layer that will toggle it. For just building spaces and resources, toggling through all states with the space bar would be feasible. If we add the immovables as well, probably not so much. Busy indexing nil values Top Quote

toptopple Topic Opener Joined: 2013-10-30, 08:11 Posts: 156 At home in WL-forums	Posted at: 2016-12-07, 14:11 >For just building spaces and resources, toggling through all states with the space bar would be feasible. If we add the immovables as well, probably not so much. In my judgment, toggling Immovable is as improtant as switching the spot graphics. So a one-key toggling is not really useful. Also, I'm not a great friend of "dropping" function bars, but that may be a matter of taste. If you were a painter, you wouldn't like your palette dropping forth and back as you access it. I would prefer a stable function line if that option were available. ;) For the price that function line may grow confusing, having 3 buttons all-time available would be a good solution. They can function both for triggering the toggles and for showing the current state of display. If you have a vanishing bar, you would have to otherwise indicate the current state of display. I wouldn't like to go without this all-time visible. Top Quote

toptopple Topic Opener Joined: 2013-10-30, 08:11 Posts: 156 At home in WL-forums	Posted at: 2016-12-11, 10:10 @GunChloec Can we agree somehow on whether there will be a stable function line in the editor? Not sure if I understand what you mean with "dropping up menus" but I must say I don't see the few buttons we have currently at the bottom as posing any problem. Also, a hiding function line would delay function access and make memorizing their availability an unnecessary human task. So I beg not to perform technical innovation for its own sake but always adapted to what suits the requirements! How we proceed with the display toggle switches depends on fixing this issue first. Top Quote

GunChleoc Joined: 2013-10-07, 15:56 Posts: 3317 One Elder of Players Location: RenderedRect	Posted at: 2016-12-12, 11:08 The bottom buttons will stay as there are, with possible additions for the 2 new overlay toggles. What I was thinking at having pop up from the bottom and then disappear when an item is selected is e.g. the tools menu and the main menu. IMO it clutters the screen. As to keybard shortcuts, we could keep the space bar for the buildhelp for consistency and use r for resources and i for immovables. It would also be nice to have keyboard shortcuts for opening each tool - maybe we should make a complete list on what we would like to access in the editor, assign hotkeys to all of them and list them in a bug. This way, we won't get hotkey collisions when we implement them and we won't need to change things later. Busy indexing nil values Top Quote

toptopple Topic Opener Joined: 2013-10-30, 08:11 Posts: 156 At home in WL-forums	Posted at: 2016-12-13, 09:58 That sounds acceptable. Some dialog shortcuts already exist, some others would have to be invented. The "Widelands Developer Documentation" is not accessible for modifications to the public. We could, however, introduce another developer documentation section: the "Concepts" section, and incite a culture of introducing plans for implementation projects which are capable of being criticized (which e.g. is not the case for Tibor's AI experiments). Here we can give interested people opportunity to contribute to the evolving ideas or methods on how to implement them, by making comments or even changing the head text. For this to function, this section must be publically write accessible. Anyways, I have set up a list of shortcuts which either exist or are conceptually assigned for the editor UI. Should I proceed with opening a Wiki page for "Improving the Editor" or something? Then we could have subtasks there for various concepts. Top Quote

1 — 10 of 15 Posts 1 2 next »