This version uses SDL_GetTicks() as a monotonic source to avoid the
previous version's pitfalls, namely the fact that the game's framerate
may not necessarily be a constant, and in particular, the old code
assumed a completely different framerate than what we ended up with
after the texture-based rendering changes in 1.17.x, resulting in an
almost-unnoticeable text fade due to the update() function being
called WAY more often than before.
Note that the reliance on SDL_GetTicks() means the timings break
at some point after 49 days of game runtime, exactly once. This
should result in a visible "jitter" effect if the 32-bits ticks value
wraps around in the middle of a fade sequence, but other than that
it's not that big of a deal to warrant requiring SDL 2.0.18+ for the
64-bit version.
(cherry picked from commit db30ca53ae)
selected schedule will write to utils/schedule.cfg on scenario save
HOTKEY_EDITOR_CUSTOM_TODS is disabled unless user loads scenario
custom_tod:Preview button and associated callback added.
editor:translatable attributes now written with leading underscore
editor:support for multiple custom time schedules
* Duplicated text
* Favour generic term 'file manager' over Microsoft terminology.
* Clarify language code use.
* Replace inconsistent spelling of 'add-on'.
The key word of course being "start". This PR changes the editor by default to work at the add-on level instead of in its own separate scenarios and maps directories. The goal is to make the editor more useful generally, but also specifically to make it much easier for players to distribute content they create using the editor:
* When they click the Editor button on the main menu, they will first be prompted to choose an add-on (or mainline), or to create a new add-on.
* When saved, if the scenario cfg is in the format previously generated by the editor, it will be converted to the new format and to use the [multiplayer] tag, the map_file attribute, and have the map data saved to a separate .map file.
* Relatedly, the editor now knows how to handle scenarios with the map_file attribute at all (which yes, does mean that currently wesnoth's editor doesn't know how to load its own mainline scenarios from their cfg).
* When opening the file chooser dialog, it now defaults to their selected add-on's directory.
If they choose to create a new add-on, then the editor creates for them:
* a basic but functional _main.cfg.
* an empty achievements.cfg (at this point mostly just so they might see it at some point and realize achievements exist, but ideally an achievements editor dialog could be created eventually).
* an empty _server.pbl file.
* a proper add-on directory structure containing the standard set of folders (maps/, scenarios/, units/, utils/, images/, etc).
Additionally, as an initial proof of concept for actually using this new add-on level functionality, a new Add-ons dropdown has been added to the editor's top bar, with a pbl editor option. This allows populating the blank _server.pbl file as well as editing an existing _server.pbl. There is also an option to change the add-on's ID, which will update the add-on's folder name and _main.cfg.
Misc other changes:
* The ability to add a recruit list to a side has been added back as a text box on the edit side dialog. While admittedly this doesn't allow players to select units from within the editor itself, it does set the actual side's recruit list (rather than a specific unit's extra_recruits), will show the user what the current recruit list for the side is (which the previously removed implementation didn't show anywhere), and correctly sets the faction as Custom so that the recruit list is used.
* When saving an old-style editor scenario, everything that can be triggered via [event] is either moved to a start event with a specific id attribute. Exceptions to this are [time], [side], and [side][village]. This is done so that the editor can know (for the most part) what things are actually its own to safely replace. As such, aside from the three previously mentioned tags plus the start event, any other WML added to a scenario by a UMC author is preserved rather than being overwritten - the editor no longer replaces the entire contents of the scenario file.
* The editor no longer writes out cfg files missing the top level scenario tag. If it doesn't find one or this is the first save of a new scenario it defaults to [multiplayer], but otherwise it will properly handle finding [test] or [scenario] as well.
* Requires that map files have the .map extension and scenario files have the .cfg extension. Also it assumes that .map files do actually only have map data in them and the .cfg files do actually have valid WML in them. I understand that this is not a limitation it had previously, but I don't think this is an unreasonable thing to require.
* Addresses part of #7667 by just not using regex for figuring out the map_data attribute value.
Additionally, it is not possible to change the currently selected add-on without going back to the main menu, clicking the editor button, and choosing a different add-on. This is intentional - I don't want to deal with having multiple add-ons open at the same time. If someone feels really strongly otherwise, then they can implement that themselves later.
* Resolution options now use "Window size" instead since it is more
accurate to the current implementation of fullscreen
* Theme becomes "Interface theme" to make its meaning clearer in the
absence of additional built-in themes
* "Automatic pixel scale multiplier" just becomes "Automatic scale"
since the rest can be inferred from the context of the option being
located right under the Pixel scale multiplier slider
This regroups some of the display options together in more logical
blocks:
- Limit FPS and VSync with Resolution and Pixel scale multiplier
- Theme and Show floating labels/team colors/grid
- Animated map and Animated water
- Show unit idle/standing animations
(Unwieldy diff because of all the grid reshuffling)
* Make the label more compact for translations ("Log File" instead of
"Open Log File")
* Make the tooltip slightly more specific about the file's identity
* Relocate the button to the bottom row to use real estate better
In commit fc7c87b765 someone missed the
logic surrounding the Open Log File button's setup that should've been
made not Windows-specific anymore.
This commit enables the Open Log File button back whenever Wesnoth has
a log file open for the current session. It also removes a few more
leftovers of the old Windows-specific UI layout path.
This still defaults to searching by the selected player name, but now also allows searching by:
* player name
* game name
* one of scenario id, era id, or modification id
The game name, scenario id, era id, and modification id support a leading and/or trailing wildcard for partial matches by essentially replacing the leading and/or trailing asterisk with a percent sign.
Scenario, era, and modification parameters are the ID, not the name, since the server gets the translated value for the name. Therefore searching by name would only give partial results in nearly all situations. So while this is probably unintuitive to a player, it still seems like the less bad option.
---------
Co-authored-by: Gunter Labes <soliton@wesnoth.org>
This adds support for having up to 28 distinct sub-achievements within a single achievement. This limit exists since wesnoth's layout isn't smart enough to tell a horizontal listbox to actually use its scrollbar instead of forcing a horizontal scrollbar on the whole window.
Additionally this adds the [set_sub_achievement] and [has_sub_achievement] WML tags and their respective lua functions. [has_sub_achievement] is unsafe for use in MP, for the same reasons that [has_achievement] is.
At some point in the future I'd like to come back and add some search parameters - right now it shows the game history of the currently selected player in the lobby, but ideally it would instead have options for player name, era, scenario, etc.
This isn't the complete set needed to allow `check_mixed_indent` to
run over the data/gui directory, it's just these small changes:
* Remove the single space from lines indented "tab ... tab space".
* Convert lines indented with "tab ... tab four_spaces".
Although these are WML files, the coding standard for the data/gui
directory is to indent with tabs instead of spaces.
Instead of being either complete or incomplete, achievements can now specify a value at which they will be considered complete. For such achievements that are not yet complete, a progress bar is added to the achievements dialog showing how close to completion the achievement is.
* Add basic achievements functionality.
This reads the mainline achievements.cfg and then all the achievements of each installed add-on.
This is intentionally handled separately from other WML loading so that:
a) All achievements and their status are able to be displayed on the main menu right after Wesnoth starts and regardless of which add-ons are active.
b) Add-ons can add additional achievements to other content, whether UMC or mainline. For example, a modification that adds more achievements for mainline campaigns.
Marking something as achieved is handled by the new [set_achieved] tag and whether an achievement has been completed can be checked via [has_achievement].
There is no attempt to prevent people from manually editing which achievements they've accomplished.
NOTE: These are *not* in any way related to Steam achievements!
These orbs no longer look the same as the player's own orbs, so they
won't cause confusion in multiplayer.
The relevant part of the advanced preference now shows:
```
[ ] - Show ally orb
[ ] - During ally’s turn, use a two-color orb to show movement
Radio buttons for colors: ( ) ( ) ( ) ( ) ( ) ( ) ( )
```
That offers these choices:
* Don't show ally orbs at all
* Always use the one-color (with ally color, not status)
* Use the two-color when that ally is playing, single color at other times
* Use the two-color when that ally is playing, no orb at other times
Rename some `allied_orb` functions to be `ally_orb`. This makes them consistent
with both the names of the corresponding `enemy_orb` functions and the WML
attribute that's used in the preferences file.
This probably doesn't need a change to the in-game help, at least for the en_US
version of the documentation. The current text in data/core/help.cfg is:
* Blue for allied units, except during that ally's own turn.
* During the ally's own turn, their units will be shown with the colors showing
whether the units can still move and attack; however their moves, and the
corresponding orb changes, are delayed as explained in "Shroud and Fog of War'.
Add some spacing to make it clearer what is grouped with what, move the
disengage orb's setting to be part of the partial orb's group, and add
a tooltip for it.
This dialog uses checkbox labels as section headers to indicate what the rows
of colors refer to. This commit doesn't change that, but it makes the grouping
clearer. Actual section headers would take additional space and probably not
look any better.
* Add ability to allow secondary authors to upload an add-on.
The secondary_authors attribute is a comma-delimited list of forum accounts that can also upload updates to an add-on. Secondary authors can't change the primary/secondary authors and can't delete the add-on.
The primary author can also make someone else the primary author by:
* Putting their username in the secondary_authors attribute
* Putting someone else's username in the author attribute
* Uploading the add-on while selecting themselves
This works since they are still (until the upload is done) the primary author in the database, so they are allowed to change the authors list, including in this case.
Bot-hosted games are now shown in a separate tab from player-hosted games, based on the new auto_hosted attribute on the game creation WML. This is not something that's available to be selected during game creation since it's assumed it will instead be set by the bot implementation. Note that this isn't *really* putting games into two separate tabs, it just looks that way for UI/UX reasons.
Resolves#6939
This implements an add-on extraction progress dialog that does not
actually run its own event loop, allowing the caller to take ownership
of it (display() static method) and update its state using a callback
function object. The object in question is passed into the add-ons
management API and used to update the dialog status each time an add-on
file is written to disk as part of the pack extraction process.
In order to avoid stalling the extraction process in UI code, the
callback is invoked for every single file, but the dialog's progress
update method places a time restriction on GUI2 API calls of 120
milliseconds -- this is a good throttle interval that allows add-ons to
be extracted in about the same amount of time as before while still
updating the progress bar smoothly enough for add-ons that take longer
than that.
(This is not the most trivial code to test, so it is suggested to add a
sleep/delay API call in unarchive_file() in src/addon/manager.cpp to
introduce artificial delays.)
One issue with this code, however, is that because modeless_dialog
doesn't execute its own event loop, the only way to get the dialog to be
updated is to force a draw event in ourselves via the new
gui2::dialogs::modeless_dialog::force_redraw() method. This is really a
side-effect of my design choice here to run the dialog in the middle of
a blocking operation instead of somewhere where events are being
processed normally. I'm not entirely sure if the draw events would be
pushed even in that case, however.
Closes#1101.
