|
Sat 14 Apr 2012 11:43:43 PM UTC, SVN revision 53932:
Make leader_image paths in the saved games index binary path-independent (part of bug #18683)
This makes it possible to store in the save_index image paths that can
be used in the Load Game dialog even when displaying units whose
graphics are in binary paths not currently loaded. This alleviates the
effect of bug #19410 on the whole mechanism, but not completely.
When the save_index is missing, this won't work properly; we'll need to
add the leader_image attribute to the saved game config itself later.
(Browse SVN revision 53932) |
Sun 05 Feb 2012 01:11:02 AM UTC, comment #12:
Waiting on bug #19410 now.
|
Sat 04 Feb 2012 08:53:37 PM UTC, comment #11:
image::exists() apparently doesn't try very hard to locate images for non-default binary paths. As a result, the leader image is still missing for saved games of currently-loaded campaigns and eras.
I'll try to figure out a different way to detect whether an image can be loaded later (the only reason I didn't use the original image::get_image() test is that it causes noise in stderr).
|
Sat 04 Feb 2012 08:45:05 PM UTC, SVN revision 52921:
Restore leader unit image in Load Game dialog (bug #18683)
(Candidate for 1.10 branch.)
This functionality is back with a slight change to r47758 in order to
left-align the map snapshot only when the leader image cannot be loaded.
We also no longer spam stderr with errors about missing leader images
(which can be caused by unloaded campaigns or eras).
Anonymissimus pointed out this functionality was still found in the GUI2
version of the dialog (--new-widgets). Whoever last changed the saved
games summary code probably only bothered to update this experimental
code without fixing the normal GUI1 dialog. As I pointed out in the
tracker, the layout code was still in place.
As a compromise for the time being, we always assume the "magenta"
palette for TC recoloring now. This doesn't seem to be a problem since
the old code already made an annoying assumption of side 1 using the 1
(red) color range instead of permiting the use of the side.color value,
or reflecting the currently playing side number at the time of the save
generation.
I may later extend the saved games summary to include additional
information to get rid of the magenta and side 1 limitations.
(Browse SVN revision 52921) |
Sat 04 Feb 2012 04:13:07 PM UTC, comment #9:
Note that I recently got to see some leader sprites there by using the --new-widgets parameter (gui2 version of load game dialog).
|
Wed 18 Jan 2012 11:27:30 PM UTC, comment #8:
Also note that extract_summary_from_config is only called by manager::load_summary in savegame.cpp:277 project-wide, and that this happens for a certain savegame only in case that the summary wasn't already present in the save_index (since acquiring the summary is expensive).
other bug in the series: bug #19215:
|
Wed 18 Jan 2012 11:15:27 PM UTC, comment #7:
The information to display is acquired in the function extract_summary_from_config in gamestatus.cpp:369ff, which also assigns the unit id to the leader key instead of its type.
However, even after fixing that, I can't get the image to show for unknown reason, though it is loaded correctly AFAICT.
The leader key's value can be empty or a unit id for both turn saves or start-of-scenario saves.
|
Sun 08 Jan 2012 02:09:40 PM UTC, comment #6:
The GUI (GUI1) code implementing the leader sprite presentation in the save preview panel still exists in trunk as of this writing (r52545) and can be found in src/dialogs.cpp, lines 384 to 399 (in the implementation of the <anonymous>::save_preview_pane::draw_contents() method), so it is possible this feature wasn't intentionally disabled or removed.
The save_index.gz file (which is already a PITA due to other bugs) stores .leader and .leader_image attributes under [save] nodes, but .leader doesn't contain useful data -- for turn saves, it corresponds to the side 1 leader (individual) unit id, but for start-of-scenario saves it's an empty string. Neither is what the GUI1 code expects (a unit type id).
|
Mon 24 Oct 2011 02:56:14 PM UTC, comment #5:
Adapt bug title.
|
Sun 16 Oct 2011 03:25:02 PM UTC, comment #4:
Eh, you're right. I remember the leader sprite reacting to which unit actually is the leader (canrecruit=yes).
However, the feature could as well have been removed at some point for some reason.
Seems to be in 1.9.8 already.
|
Fri 14 Oct 2011 09:29:26 AM UTC, comment #3:
The minimap part of this is fixed, but not the leader sprite part. I do recall seeing leader sprites in that dialog at one point, but I don't remember when they disappeared.
|
Mon 10 Oct 2011 01:16:03 PM UTC, comment #2:
Due to the token changes revert, this bug has probably never existed. Please check.
|
Tue 20 Sep 2011 09:20:42 PM UTC, SVN revision 51235:
Fixed bug #18682 load dialog bug where all times were 1969, by changing incorrect iterator from i to j on line 624. Bug #18683 is not fixed by this patch. Other bug in the series are bug #18665, bug #18649
(Browse SVN revision 51235) |
Sun 18 Sep 2011 12:30:29 AM UTC, original submission:
Sometimes, the minimap preview and the leader sprite are missing in the load game dialog. If they are present, the dialog will use the first save's minimap and leader sprite for all saves.
|
Related Recipes:
Battle for Wesnoth - Bugs: bug #18683, Leader sprite is missing in the...