Implement a system similar to AO pairing, whereby multiple (possibly more than two) characters can be shown in one screen. An example use cases in DR games includes Ultimate Talent Development Plan in DRV3, where the player takes control of one character and they can be shown alongside other characters when talking to them, although this could see far more use in RPs by virtue of the party system, which already gets people moving together.

An expansion of this system could also be included where a character may not necessarily be shown in the same place. For example, DRAE show character sprites in one of two positions: left

and right

Note the two systems can be implemented together, as to show multiple character in one screen, they should not overlap.

This will require server assistance to mandate which sprite to update, possibly in the form of implementing a similar system to AO's server side pairing.

Some questions to answer are:

1. Who decides what the positions should be? Theme option? Client?
2. Should there any "sliding/fading" be performed when needing to move sprites to accommodate the new number of sprites? See https://youtu.be/bqwPLwozbps?t=40 for an example

Regardless of the ongoing audio slider discussion, we should add the option to mute the client if the window is not focused. The way it would be implemented is as follows.

There is a new checkbox option added in the config panel audio tab: "Mute if window is not focused". If the window is focused, all audio remains regardless of the option. If the window is not focused:

• If the option is off: no change.
• If the option is on: all audio options of the client (including music, SFX, blips and system options) are muted. This should not change the slider values the player sees (that is, say, if the system slider was at 60% and the config panel is up but not focused, the slider/value the player sees should effectively still indicate 60%).

The meaning of "window is focused" is: either the main lobby/courtroom is focused, a notice messagebox is focused (like the one you get when you are disconnected from a server), the config panel is focused, or the player is selecting a file to open (applicable when you are trying to open a text file as a note with the built-in notepad).

The default value of the option should be "Off" (don't mute the client if the window is not focused).

Program is slow. Optimizing it would be decent. It's C++ after all.

Instead of variants corresponding to one folder, multiple asset lookup for variants should be split into two components: by gamemode and time of day. This would more closely follow the UI style of Danganronpa games, where UI assets, their location, fonts, etc. depend on the current gamemode (daily life, deadly life, trial, NSD, etc.) and time of day (day, night, unknown). In particular, a variant would be a combination of gamemode and time of day (where possibly none, one or both are not set).

They would follow a similar logic of what variants did (follow a hierarchy of files to look for, use lower priority file only if higher priority file does not exist) as follows:

1. base/themes/THEME NAME/gamemode/GAMEMODE NAME/time/TIME OF DAY/ASSET
2. base/themes/THEME NAME/gamemode/GAMEMODE NAME/ASSET
3. base/themes/THEME NAME/time/TIME OF DAY/ASSET
4. base/themes/THEME NAME/ASSET
5. base/themes/DEFAULT THEME/ASSET

In particular, if DRO wants to draw an asset, it first checks if path 1 is valid. If it is, it uses that. Otherwise, it tries 2, 3, and so on.

The server would send two packets that dictate gamemode and time of day. The client when it receives either packet will automatically switch to using the appropriate assets for the new combination of gamemode and time of day

• 'GM': would have one argument, indicating the client what gamemode to switch to. Expected values include 'daily', 'deadly', 'school', 'trial', 'nsd'. An empty string indicates no gamemode, and would just mean asset hierarchy goes 3, 4, 5.
• 'TD': would have one argument, indicating the client what time of day it is. Expected values include 'day', 'night', 'unknown'. An empty string indicates no time of day (which is different from unknown), and would just mean asset hierarchy goes 2, 4, 5.

As a bonus, this would also solve the remaining issue of #47 which was how to change the UI based on the CL packet to reflect time of day. This would make the responsibility of the server to order a switch to a particular time of day, instead of the responsibility of the client to do logic based on the CL packet.

Allow for an explicit way to add new lines in chat messages. DRO will happily render new lines, but the only way to add them right now is by copy-pasting texting that already had new lines into the IC chatbox and sending that. This could help separate important points which would otherwise be shown in one line. For example:

Of course, special care must be taken so that a user may not put too many newlines in their message, because you could use that to clear out logs, so perhaps a limit should be imposed (say, no more than 4 newlines, as most themes are fit to show at most 3 lines anyway?)

Currently, Danganronpa Online allows for users to have the default color of messages they send IC as white, green, red, orange, blue, yellow, pink and purple. However, the corresponding RGB colors DRO actually uses are hardcoded in the client, which results in themes having to work around the hardcoded palette when designing themes (most noticeably white is currently an off-white shade, which does not look well in all themes).

I would like it so that the RGB meaning of 'White', 'Green', 'Red', 'Orange', 'Blue', 'Yellow', 'Pink', 'Purple' was a theme option theme designers could change, akin to how they can define the colors highlight characters produce (e.g. / /, \ , ( ), etc.).

So that you may have something as simple as:
[08:50] Leifa: Look, it's the time.

If there are issues opening a file or saving to a file, Danganronpa Online will silently fail without giving any sort of indication to the user. Example situation include:

Let's say I had my note file in a flash drive in F:/ I open it in DRO and edit all fine and dandy, until I unplug the flash drive while DRO still has that file selected.
then future writes will fail silently and future reloads will fail silently.
Or if I had a note file open, then open it with another editor that keeps the file open, subsequent DRO saves will fail silently.
Or if I open a file, then move the file in the OS to a different location, future reloads fail silently and saving has undefined behavior.

Danganronpa Online should raise error messages for these situations prompting the user to take action.

Unrelated, upon picking a character that has judge buttons but selecting a theme devoid of information regarding wtce buttons, this will cause the client to try to check for an index that is out of range, leading to a failed assert, forcefully closing the client.

This is probably the case for other systems since they seem to have made with a lot of copy & paste.

The theme GM Mode v2 is one such theme that will fail to pass the assertion.

Example use: in DR games while in a nonstop debate, a character may counter a point. The old UI remains on screen while the shout animation is displayed, and changes automatically only once the character starts talking. The server is unable to tell the length of a shout, so it cannot accurately guess when the character starts talking. Moreover, sending a reload theme order while a shout is playing cancels the shout (and displaying the message).

Then, we must do it so that if an order to reload theme arrives while an interjection is playing arrives, delay the execution of the theme reload until after the interjection is fully shown; and make sure the upcoming message is displayed.

Currently in AO it is easy to filter through characters in the character select screen via a handy 'Search' searchbox in the top. If a value is put in the searchbox, only characters whose folder name start with the search value are shown in the character select screen, drastically reducing search time. This can be especially helpful for Danganronpa Online, given that the default character roster has 200 characters, and other servers may introduce additional characters.

Interjections are a confusing mess right to the point that it doesn't have any real rhyme or reason as to why the current system is as is.

1. Interjections can be defined by characters, current theme's variants, current theme, default theme and a placeholder theme. Too much.
2. Interjections all have a suffix associated, _bubble yet custom is exempt from it. Why?

Obviously, interjections needs to have less targets it looks into, cutting half of it or just providing a different targeting would be better. And as said above, there is no reason why custom interjections are exempt from receiving the _bubble suffix, so I would suggest enforcing it.

Add a new packet setting for MS that would hide player sprites when received, the old compatibility mode is an hardcoded string that the server send: "../../misc/blank"

If the "always_pre" config is true, selecting a character should check the Pre checkbox automatically, not only once the player has changed to an emote that indicates preanimation is required.

Moreover, if "always_pre" is true, the preanimation checkbox is not ticked and the player chooses a sound effect, the preanimation box should be ticked automatically. That is because for DRO to play a sound effect, a preanimation order must be included with the IC message.

Most widgets should have helpful tooltips.

We need to figure out what to do with the clock, because right now in theory we could use the timer for it

The current implementation of themes all around are a bother and do not help in any major way, furthermore there are theme conflicts when you wish to use a stylesheet, meaning that it could potentially bring some things to not work proper, an issue.

A complete rework for themes would probably be of use, as well as re-implementing custom UI elements hierarchy to not cause possible crashes due to some issues (recursion issue) as mentioned in #102

Reworking the theme structure would help immensely and alleviate potential risks where more file formats are introduced.

Finally, reworking the UI itself to make actual use of some of its features would go an extremely long way for mod customization.

We need case sensitivity.

Add an option to courtroom_fonts.ini whereby theme designers may decide how their text is aligned on screen. For example, they may want shownames to appear right-aligned rather than left-aligned, or have the music list show tracks center aligned, or have IC messages be vertically-centered.

Particular care must be taken care with the IC message on viewport, as the current implementation of chat_tick() adds one character at a time, so DRO does not know how to render the full message with the intended alignment until the full message is rendered, which is not how how DR games do it (if a message is centered, all letters when added are rendered in their intended place from the get go).

Currently, Danganronpa Online reports 'DRO Client' as the name of the application and no game icon to Discord. I would like this to behave more similar to AO2, which reports 'Attorney Online 2' and the Attorney Online icon.

Allow each characters to have a sounds folder from which can use sounds.

I would like to readd audio sliders as follows:

1. There is a "master" slider on client. This slider is linked to the master slider in the audio tab in the config panel. Adjusting either slider automatically adjusts the other. The x, y, width and height of the slider can be modified via courtroom_design. If such an option is not present in courtroom_design, the default of 0, 0, 0, 0 should be assumed.
2. There is a "sound" QPushButton/Label widget on client, which displays either an image or text. If enable_label_images in courtroom_config.ini is true, this widget will use an image (like "sound.png") if available, and just show the text "Sound" if the file is unavailable. If that tag is false instead, the widget should just show the text "Sound". The x, y, width and height of the widget can be modified via courtroom_design. If such an option is not present in courtroom_design, the default of 0, 0, 0, 0, should be assumed. The overall behavior of this widget should be similar to the "Pre", "Flip" and "Hidden" widgets (not the checkbox, the labels).
3. Assume a player clicks on the "sound" widget. This should open a collapsible box/show widget, which we will call "Volume Mixer widget" for the sake of a name; an action we call opening the volume mixer. Clicking on the "sound" widget again should close the collapsible box/hide widget' an action we call closing the volume mixer. I'm not sure what the background color of the volume mixer widget should be (or if we want it to be transparent for that matter, probably this tbh).
4. There is a new checkbox in the Audio tab called "Hover to open the volume mixer". If that checkbox is off, the behavior of the "sound" widget is exactly as described in 3. If that checkbox is on, the behavior is modified as follows:

• Assume the volume mixer widget is closed. The user may then open the volume mixer by either clicking the "sound" widget or by hovering their cursor over the widget for some small duration of time (say 0.5 seconds).
• Assume the volume mixer widget is open. The user may then close the volume mixer by either clicking the "sound" widget or by moving their cursor so that it is not on the sound widget or the volume mixer widget for some small duration of time (say 0.5 seconds). In particular, if the cursor leaves either widget and, after that small duration of time the cursor is still not on either widget, the volume mixer widget should close automatically.

5. The volume mixer is divided into multiple horizontal slots, all stacked on top of one another, each corresponding to one modifiable audio option (currently 4: system, music, effects, blips). Each slot has the same width and height as every other slot. Each slot's width is the volume mixer width, the height I'm not sure. If the height of all slots exceeds the defined height of the volume widget box, a vertical scrollbar should appear.
6. Each volume mixer slot should contain two items: a slider and a label (AOLabel maybe?). The slider should stretch to fit some high enough percentage of the slot's width (say 80-90%), the label should be immediately to the right of it and use the remaining space. The slider and label are to work as follows (using System as an example)

• The system slider in the system slot is linked to the system slider in the audio tab in the config panel. Adjusting either slider automatically adjusts the other.
• The label shows either an image or text. If enable_label_images in courtroom_config.ini is true, this widget will use an image (like "system.png") if available, and just show the text "System" if the file is unavailable. If that tag is false instead, the widget should just show the text "System".

If an incoming IC message has char ID -1 but includes showname information, include the showname information

There is noticeable lag on the current iteration of the master branch (7fd9424). After checking out arounds, there are two bottlenecks.

ackMS
The handling method needlessly rework multiple widgets in an attempt to clear the current selection of items.

This is a particularly bad speed issue because for some reason, multiple of the implementations were never reworked to be cleaner. This means a large bulk of the rework would result of the SFX listing.

MS
This one has a bunch a I/O checks and also modify heavily some of the widgets as well for no good reason whatsoever.

Adding the ability to switch between audio-devices would help users who may switch occasionally audio devices (such as Speakers -> Headphones), it would provide a way to users to potentially fix audio issues if they have one with certain devices.

Add a new option for each audio channel called: Ignore Suppression

If enabled, this prevents the program from suppressing (muting) audio channels when out of focus. The System channel has this option permanently active and is shown as greyed out in the panel. This is to prevent people from claiming that they're missing system audio cues because they disabled them, thus reporting a fake issue.

Displaying the number of people currently formulating their thoughts within the client could provide some feedback on whatever someone is going to be saying something soon, this would effectively make it much more obvious whatever someone might be replying to someone or not.

In the case of a roleplays, this would provide information of whom might be replying very soon, and in some cases could hint that someone is hesitating to reply, leading to other people potentially suggesting or pushing them to speak out. (There's always a shy one after all.)

CONCEPT
The client handle nearly everything about it. It not only sends notification to the server that they're writing but also do the calculations required to know when someone has 'timed out' on their writing.

This means multiple smaller packets (msprep) are sent to the server whenever text is being edited, the server would then transmit back to other clients in the same area that this specific user is currently preparing a message, or 'thought'.

Upon reception, the client would immediately push the packet on a queue that constitute a number of information.

The bubble and rectangle are purely cosmetics, they are just here to make it less boring to look at. The number provides in-real time the number of people actively preparing their thoughts.

After a certain time passes or the server send a clearing packet, the user will be purged from the queue, thus reducing the number of people shown as actively formulating their thoughts.

Since the server provide the user_id to the client as they connect, this makes it easy for the client to filter out their own messages if required.

PACKETS

Client: ms_think#%
This packet is forwarded to the server whenever the player is starting to formulate a thought in the IC field.

Server: ms_think#{user_id}#{chr_id}[#{chr_folder_name}]#%
This packet is forwarded to all clients within the area at the discretion of the server, user_id is a necessity to be able to reliably predict when a user timed out on their thoughts.

user_id A unique user identifier, required by the client to keep track of users and their thoughts.
chr_id The character id that the user has as of writing.
chr_folder_name The folder of the last character the user has spoken with. If the user has changed characters (chr_id) in-between, the server will not provide this argument until their next message was provided.

In the case of the sneaking mechanic, the server is left with the choice whatever to notify clients or not.

Server: ms_think_clear#{user_id}#%
This packet is forwarded to each clients whenever a user send a message to IC. This ensures that they are immediately cleared off the list even if they immediately started formulating new thoughts.

The IC log could benefit from showing a different color for the user, this would provide a quick self-identification when skimming through the log.

Because of the shared name between a shout and its button, AOMovie::play will select the button's image for a shout if the shout does not have an image.

This is despite the shout image selection only iterating through animated (gif, apng and webp) images, as AOMovie::play does a search of its own with the full set of potential image extensions.

A user can easily run into this issue when they try to create a theme variant, and want to use the theme variant system by not replicating files shared with the main theme in the theme variant folders.

There are two way to fix this issue:

1. Rewrite AOMOvie::play and/or the image selection system to ignore the shout button's image,
2. Force the shout buttons to have different names than their respective shouts, like <shout>_button.png.

Currently, if your IC chatlog is scrolled, it is by design that the chatlog will not automatically scroll to snap to top/bottom (depending on chat orientation) to show newer messages. This helps when a user is looking for a particular message and multiple people are talking, as it means they do not have to keep looking for a message. However, someone who is unaware of such a mechanic could be confused to see their IC chatlog stopped.

My proposal is rather simple: add some sort of overlay notification similar to Twitch's, which has a similar functionality for its own chat.

This will make it explicit that they chatlog is not moving because they have their chatlog scrolled. It would disappear if the chatlog is snapped to top/bottom (depending on chat orientation).

A similar overlay could be added to the OOC chatlog, which employs the same functionality.

AO currently has an option widget where you can turn on/off enhanced Discord integration. When this option is on, Discord will report your server and current character in your profile if you allow Discord to report your current game. If this option is off, Discord will only report you are playing Danganronpa Online. Currently DRO implicitly always states your server and current character.

By doing this, players in private servers may hide server names and/or characters they are playing, which can help maintain privacy or avoid spoiling without players having to resort to deactivating Danganronpa Online as a game.

I would like this to be an option widget in the configuration panel.

Currently the mute list adds [X} to each muted name to check if a character is muted. It would be better if it used Qt's builtin checkboxes

The APNG plugin gets automatically linked if it is present in the imageformats/ directory in the build directory, and loaded if it's present in the same directory when running.

Trying to pull it in with QPluginLoader not only does not work, it erroneously tells the user that loading it failed, even if it didn't.

If the detection of the successful loading of the APNG plugin is needed, what it should be done instead is checking the supported fileformats for something like QMovie -- if "apng" is not amongst it, then the plugin loading failed.

Because no one cares about looking at a line without any content inside.

Right now the game identifies itself as AO 2.4.8, which is meaningless as this is vastly different from 2.4.8. We probably want to come up with our own version scheme.

Title.

This would further help test that Danganronpa Online can be built for multiple operating systems, as well as help neatly pack future releases so that the code maintainers don't have to do that manually.

Currently credits only include AO devs, not DRO devs.

Currently once a note file is open the only way to close it is by opening a new note file or closing DRO. An ingame way of closing note files would be nice.

chrini

When a client is provided a character that is not the spectator slot, the client will send back information to the server regarding the final-target folder (due to ini-swapping) and its display name (used for server-messages).

Definition
chrini#<string: target folder>#<string: showname from char.ini of target folder>

Allow theme creators to add an additional asset to their theme folder chatbox_self. The way it works is as follows

1. If someone else talks IC:

• Show the regular chatbox

2. If the client talks IC (and gets to see themselves talk IC)

• If chatbox_self cannot be found using normal asset lookup rules, show the regular chatbox following normal asset lookup rules.
• If chatbox_self is found using normal asset lookup rules, use that instead.

This can help further differentiate someone else talking and you talking, which is relatively useful in first person mode and is what the DR games do. For example

(Note the orange fade when Hajime speaks vs Kazuichi)

Shownames should not only be remembered between session but be easier to input, not relying on slash command to do the job.

This would require modifying the packet handling server-side to allow such modifications as well and make it so that the showname is an entirely optional argument.

Allow Danganronpa Online to display multiple viewports at the same time. This would help support minigames such as cross-swords or mass panic debates, as well as allow surveillance clients, which can watch over multiple players in different areas in one screen (aimed theoretical maximum of 16 screens at the same time, which represents the standard number of players in a Danganronpa Killing Game, although 9 screens would also be fine, just have two clients each watching 8/9 players).

Some questions to consider are:

1. What decides how the multiple screens will be split/together together? That is, who should be in charge of deciding how 2 screens are shown (position, stretch to fit vs. crop in some manner)? Theme variant option? Client decision?
2. How does DRO choose to draw assets? Should courtroom_design be expanded so that it lists positions for each viewport asset? Are positions based on absolute positioning (that is, 0, 0 top-left window corner), or relative positioning (that is, 0, 0 of the viewport)? Are sizes based on absolute sizes (an asset that is established has size 136x78 is shown at that resolution) or does the client/theme resize the assets following some rules (for example, if using a 4x4 grid of screens, all assets are shrunk to width/4*height/4)?
3. In both cases described in 1, what if we want to allow two or more ways of splitting the screen (think mass panic debate splitting the screen in three portions differently in each trial; or wanting to support V3 style first person-which would use 2 screens, one larger than the other- and cross swords-two vertical panes-).

• If the answer to 1 is theme, should each theme variant be able to set multiple such splits, or be limited to one per variant?
• If the answer to 1 is client, how would we ensure we can support those different styles.

4. How do we link different screens to follow certain types of IC packets. To explain this, consider the current system which has just one screen. This one screen is effectively generally tracking and displaying messages sent by any player in the same area. We need to generalize this system so that each screen can only show certain messages.
5. How many viewport chatboxes should be shown on screen? Cross-swords has people talk in turns, so only one chatbox is required; while mass panic debates allow three people to be talking at the same time, let alone camera feeds were multiple people are talking at the same time. We would ideally want to support both styles, so we would need to make a decision on how to support this: theme variant option or client decision?

• If per theme: we need a theme option that establishes how chatboxes should be shown (one per viewport or one per client)
• If per client: how can the client tell which chatbox mode to use (see previous point).

6. While the answer is trivial if all screens show character in the same area, what is the effect of having screens show different areas of the server? In particular, we need to answer these questions:

• How are incoming IC messages logged? There is exactly one IC log and it can be confusing at a glance to have the IC log show messages from multiple areas one after the other, so there must be a way to distinguish between different area messages. A similar question is posed for incoming OOC messages.
• When I send an IC message, what area will it go to? All areas I have a screen on? The current area? A specific area (and if so how do I tell DRO which area I want)? Similar question is posed for outgoing OOC messages.

7. What is the effect of the player changing areas while having multiple screens active? Should it reset DRO back to "one-screen mode" or do some sort of magic to show

If we could add a system of unit tests to DRO, it could help reduce the amount of manual testing needed for new features, prevent regression bugs, and help assist cross-system compatibility (given we now support Windows and Linux).

Notes may instantly reload when not meant to if selected slots are closed without being deselected first.

1. Load file to slot 1
2. Select file 1
3. Close slot 1 without deselecting slot 1
4. Create a new slot 1
5. Load file to slot 1
6. File instantly loads, despite slot 1 not being selected

In particular, in this example the file should not have loaded. It should have only loaded if the user chose to open the file in slot 1.

Servers may indicate they have ".opus" tracks in their music list and send that information to clients. However, even if clients have the .opus files themselves, their music list will still mark those tracks as "not found". A similar phenomenon occurs with sfx tracks.

For both cases, the client will also fail to find an ".opus" track if given just the name.

It recently came to my attention that a few of the sfx that come with a default setup are actually a tad too long (e.g. sounds/general/sfx-cello.wav). While we technically prevented the vastly more annoying situation where you can play music as sfx by doing the folder jump check, we still face this spam possibility with these long sfx (even potentially those added with custom packs).

We should make it so that if a client processes a new IC message, it makes it stop playing any sound effects/voicelines played in the previous IC message that may continue playing.

Currently, every emote button requires two files exist: one for when the button is 'off' (that is, not selected) and one when the button is 'on' (that is, selected). While this gives ultimate freedom on how each emote button individually looks, this freedom is rarely used and for the most part, character creators design characters as follows: each on button is equivalent to the off button + some semitransparent image. In particular, unneeded extra effort is exerted by the character creators, who for each off button they must create an on button identical to the off button, but you drag some semitransparent image on top, which can be cumbersome especially for characters with lots of emotes.

I would like to automate this process as follows. If for a particular emote,

1. both an _off and _on file exist, use the two as currently used (to preserve backwards compatibility with the already thousands of character folders that exist).
2. only an _off file exists, if there exists a new 'selected.png' or similarly named file, when the emote button is pressed, the 'selected.png' file is drawn on top of the currently selected emote, similar to how character buttons are overlaid a 'taken.png' in the character selected screen if they are taken.
3. only an _off file exists and no 'selected.png' file exists, a default semitransparent gradient pattern is drawn on top of the emote button when it is pressed.

This process could in theory be further devolved by allowing theme creators not to put the '_off' tag after the name of the button if they choose to exercise either option 2 or 3. Of course, this would break backwards compatibility with previous DRO clients and cross compatibility with AO (as they all require the '_off' tag), so we need to be mindful.

For whatever reason, aonotepicker.cpp have Courtroom method implementation in their source file which frankly shouldn't be the case.

Solution would be to:

• move the implementation in the associated courtroom source files and not an arbitrary one
• rework AONotePicker to have an actual implementation instead of leaving it to Courtroom

How possible is it to add an argument to courtroom_design.ini/lobby_design.ini that would allow assets to be rotated in any direction. For example, assuming rotation number is an angle from 0 to 360, 0=360 meaning no rotation and larger numbers indicating more counterclockwise rotation, we could give each asset a fifth (optional?) argument indicating the angle of rotation.

This can prove useful to emulate certain aspects of Danganronpa, where not all assets are displayed straight:

While it is entirely possible that theme creators may decide to simply provide "pre-rotated" versions of their images for themes, providing that additional flexibility allows text to be rotated as well.

AOApplication is, I'll be honest, a very poorly implemented piece of shit that do not deserves to exist in any shape or form at the current time.

It's too powerful of a class and has too much reach everywhere. A removal of it or at the very least, heavy rework, would help tremendously impact it's crappy effects and also potentially reduce the dependency of it being absolutely everywhere, which is poor design.