Currently, the chat timeout is fixed to 30s, that's fine for most notifications but scenarios may want to have some messages more long-lasting, as done in that patch.
Details
Details
- Reviewers
wraitii - Group Reviewers
Restricted Owners Package (Owns No Changed Paths)
Check that it works as expected
Diff Detail
Diff Detail
- Repository
- rP 0 A.D. Public Repository
- Branch
- /ps/trunk
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
Buildable 4127 Build 7261: Vulcan Build (Windows) Jenkins Build 7260: Vulcan Build Jenkins Build 7259: arc lint + arc unit
Event Timeline
Comment Actions
Successful build - Chance fights ever on the side of the prudent.
Updating workspaces... Build (release)... Build (debug)... Running release tests... Running cxxtest tests (308 tests)....................................................................................................................................................................................................................................................................................................................OK! Running debug tests... Running cxxtest tests (308 tests)....................................................................................................................................................................................................................................................................................................................OK! Checking XML files...
Comment Actions
The simulation should remain agnostic of GUI styling.
Ideally subtitle / dialog support where the GUI is hidden and the sentence is displayed until the user clicks or presses a key would be used.
Another idea might be to abstract the tutorial panel so that it could be reused here.
A quick and clean alternative would be to execute a cmpGUIInterface.PushNotification with a new type, arbitrary data and processing it in gui/session/messages.js (it can just call addChatMessage with a custom type that always ends up translated). Thus the GUI can optimize arbitrarily for dialog style chat messages (chat timeout, chat message display format like hiding the playername).
Comment Actions
Agnostic to style, yes. But that's not style we are talking about: it is the simulation (and scenarios) which know how long a message has to be displayed. It is not to the gui to decide such a thing. Of course, we can have a different message type for each duration, but that's not really scalable.
Comment Actions
Yet it's a GUI modification.
If use cases for arbitrary chatTimeout values per simulation-sent chat notification are identified, then your patch must be correct.
If there are only 2-3 use cases for a different chatTimeout identified, we should add the 1 or 2 new gui notification types instead.
A dialog between units might be more recognizable as:
[color="green"]Gaul Woman:[/color] foo bar than
[color="green"]Player 3:[/color] gaul woman: foo bar since that denotes a chat message sent by a player.
So a unit-dialog ought to have a custom gui notification type either way.
A new gui notification type can be implemented with a handful of lines (remember rP19260, + calling aichat code for translation), I can post them if wanted.
(A review should also point out that chat messages not disappearing in the order they appeared might come unexpected to the player, but is not wrong if it is designed to be that way.)
Comment Actions
This does seem like it would be better suited to a "gameplay-dialog" notification type.
Comment Actions
The simulation can send timed string messages printed in the middle of the screen (such as the wonder victory message) using GuiInterface.AddTimeNotification.
GUIInterface.PushNotification can be used to send custom events.
The tutorial panel is also a possibility (that also provided a back in history button iirc?)
RTS like dialogs betwen ingame characters should, if used widely for a campaign or such, probably not use the chat.
The information flow must be GUI pulling simulation events, not simulation pushing GUI settings, at least if we want to keep the simulation GUI agnostic. The simulation shall describe what happened in the simulation, and the GUI can chose freely how to present that, which colors, icons, sounds, positions and whatever to use.
So it really depends on the use case what way to implement.