Map background images refactoring

Bug #1377394 reported by GunChleoc
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Fix Released
Undecided
Unassigned

Bug Description

Some of the campaign maps have background images, but the tag isn't exposed in the editor. I have 2 solutions in mind:

1. We could have a nifty file selector in the editor to make sure that the user selects an image that already exists.

2. We could have a standard filename for the background image. The map could then simply check if the file is there when loading, and we would remove the "background" option from the map packet. We would have to duplicate some image files then though - the tutorial and 2 Barbarian scenarios share the same background image. Currently, we have:

campaigns/tutorial01.wmf/elemental:background="tribes/barbarians/pics/campmap-tut1+2.jpg"
campaigns/t01.wmf/elemental:background="tribes/barbarians/pics/campmap-tut1+2.jpg"
campaigns/t02.wmf/elemental:background="tribes/barbarians/pics/campmap-tut1+2.jpg"
campaigns/t03.wmf/elemental:background="tribes/barbarians/pics/campmap-tut3.jpg"

campaigns/emp01.wmf/elemental:background="tribes/empire/pics/campmap-emp01.jpg"
campaigns/emp02.wmf/elemental:background="tribes/empire/pics/campmap-emp02.jpg"

campaigns/atl01.wmf/elemental:background="campaigns/atl01.wmf/pics/everythinglost.jpg"

Note that we also have an inconsistency here . Some pics are in the tribes, and one is in the campaigns.

For option 1., I would vote to put them in campaigns/pics.
For option 2., I would vote to name them <scenario folder>/pics/background.jpg.

Related branches

Revision history for this message
wl-zocker (wl-zocker) wrote :

I have always wondered where that image comes from.

I vote for option 2 for two reasons:
- We have the init.lua, whose name cannot be chosen by the map maker. Why should we do it differently for the background?
- The image belongs to the map. If the map is copied, but not the image (I think of user-created maps), the link will become invalid.

Note that I work on the tutorial - I do not think that they need a special background. I also plan to remove the first campaign (see bug 1088222), so there would not be any dupllicates.

GunChleoc (gunchleoc)
Changed in widelands:
status: New → Confirmed
milestone: none → build19-rc1
tags: added: campaign cleanups lowhangingfruit
Revision history for this message
SirVer (sirver) wrote :

A couple of disjunct thoughts:

- I suggest duplicating what we have for "include" for Lua scriptings. There we use the special map: prefix to indicate that something should be loaded from the map.
- How much sense do these loading backgrounds still make? Now that we use on demand loading, campaign basically start instantly, so the loadings screens are not shown for long anyways. We could just remove "special" loading screens. The graphics are pretty, we should reuse them in other places if possible.
- I would not expose anything in the Editor. I think the proper way forward for the editor is to split it from the main binary and ship it as an extra executable. Main reason is that on some platforms, designing maps will be unpractical - i.e. on tablets. So why should there even be the option?

Revision history for this message
GunChleoc (gunchleoc) wrote :

I still see them long enough to add a little flavour - but not long enough to scrutinize the maps in them.

We could bzr move them anyway for now to have a uniform format, and we can do the code magic for Lua later, once we know what we want?

Revision history for this message
SirVer (sirver) wrote :

sgtm.

GunChleoc (gunchleoc)
Changed in widelands:
assignee: nobody → GunChleoc (gunchleoc)
status: Confirmed → In Progress
Revision history for this message
SirVer (sirver) wrote :

Fixed in r7210.

Changed in widelands:
status: In Progress → Fix Committed
GunChleoc (gunchleoc)
Changed in widelands:
assignee: GunChleoc (gunchleoc) → nobody
GunChleoc (gunchleoc)
Changed in widelands:
status: Fix Committed → Fix Released
Revision history for this message
GunChleoc (gunchleoc) wrote :

Fixed in build19-rc1.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.