On Sat, Feb 20, 2010 at 04:14:36PM +0100, Fabian Mueller wrote: > Mark de Wever wrote: > > Historical the map editor was intended to only edit map and nothing more > > fancy. So I think we should first discuss, what do we want the map > > editor to become or whether it should stay a map editor. > > > The map editor should stay a map editor.
Sorry but the rest of your mail disagrees with that, what you want is something more than just a map editor. I've no problem that you want that the map editor can do more as just editing a map, but don't claim it should stay a map editor. What you're aiming for is something between a map editor and scenario editor. > Some more advanced scenario editor would maybe be better implemented > as an extra tool. But all use cases that have been proposed so far > are very map bound from wml developers point of view. For all the > issues I need to work with the map editor but translate some of it's > output manually to the wml code the map editor is the right place. A lot more scenario things are map bound, victory upon reaching X, an event that triggers if you move to Y. If you add events for locations, why stop there and not directly add other events as well... So again my question, where do we want to do with the map editor, let it be a simple map editor or move it more and more to a scenario editor? > >> * Text labels associated with a hex > >> > > > > I think this isn't really required, especially not if a set of hexes can > > have a id. At least not in the map editor, if we add a scenario editor > > this objection no longer holds. > > > Why do you want to do that with a second layer involved? > Edit the map, assign id's, edit the wml and remember what id needs to > be named "blah" for team a and "blub" for team b. This will most > likely lead to the old problem again: You need to work with 2 > applications at once to work on the same issue for no reason. When using proper ids shouldn't be too hard to remember them, much better as trying to remember a random coordinate. > >> * Scenery or item images. > > > > Idem. > > > To bring the placement of scenery or item images to the editor was > *the* reason I started the project. If you don't see the need for > that then try to arrange a map with several items and sound sources > like it is done in IFTU for example. > > Honestly, (please don't be offended) you need to have experience as a > campaign designer to value what the new proposals offer. I'm not offended, I just wonder whether bolting those features into the map editor is a good idea. Like I said before is it a good idea to transform the editor into this and where do we want to stop. <snip> > >> On the other hand, I think it *is* important that all the > >> static-object annotations associated with a map live in its .map file. > >> If they're separated from the map data, editing them and keeping > >> the map and annotation parts in sync will get messy and attract bugs. > >> > > > > As said on irc I think we should postpone discussing these details until > > we get the design goals set. I'm quite hesitant about changing the map > > format and see several cans of worms being opened here. If for example > > we want to allow to place units as well the map format changes will be > > too big so we better find another solution. > > For example scenario foo.cfg gets > > foo.map -> containing the map > > foo.units -> containing the units > > foo.label -> containing the labels > > foo.icon -> containing the icons. > > > To say it again and again: The map format (map_data) is not planned to > be touched in any way. Sorry but it was proposed on irc to change the map_data format, maybe not explicitly this time, but the last time I discussed it with esr it was. So if it's no longer the plan, good. > The editor is going to read and write the [map] tag. > I believe that everything that is needed to do this is already in place. > >> The roadmap needs to look like this: > >> > > > > -1. Decide what we want the editor to be able to edit and do, not only > > in a few weeks, but preferably what we want it to do in a few years. > > > > > The editor should handle all location related issues. > That means the placement of labels, items, sound sources, units, and > named locations. What about the location bound event. > Labels is already working in my branch, I plan to work on items and > sound sources next. > Named locations will be a little more problematic since this is a > multihex issue. > The hardest task will be the units, that will be done at last. > > 0. Decide whether to bolt this on top of the map editor or that creating > > a new editor is the better way to go. When we decide to do it in a > > separate editor, the person doing the job should decide whether to start > > from scratch or not. (I prefer s/he will, but it's his/her time to > > spend.) > > > No, that is not a better way to go. > It will lead to the same situation we have already: > Multiple programs are involved in the same working process. > That is like you have two programs for chatting in irc. > One you can only write in and one you can only read from. IMO that depends on step -1 so not going to discuss that now. <snip> I think we need to discuss point -1 further, what do we want to have in a visual tool and what not. -- Regards, Mark de Wever aka Mordante/SkeletonCrew _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
