SrRapero720
[WF v3.0.0] Planned features for the next major update
PLANNED FEATURES FOR VERSION 3.0.0
All listed features here are planned for the next major update of WATERFrAMES, in conjunsion of WATERMeDIA v3. Here you can suggest more features, discuss about the listed ones or contribute to them
Core Features
- [ ] Upload images from local storage
- [ ] Commercials: Pre-defined media sources displayed every 3 minutes while playing a video
- Config must have an option to disable, add or remove
- An option to broadcast custom commercials to everyone in the world using the mod (by the mod owner, limited to youtube media sources)
- [ ] Rickroll everyone
- [ ] Multiple media sources (playlists)
- Support for Youtube playlists
- [ ] Rewrite the recipes to be much harder to make any display+
- [ ] Shutdown displays in a radius (PEM)
- [ ] Override URLs of displays (HACK)
- [ ] Interference: Some circunstances can make all displays just not play correctly the media
- [ ] Creaking hearth: stay nearby of a creaking hearth
- [ ] Pale biome: displays on that biome will lost signal momentaneously
- [ ] Nether: radioactive biomes will cause interferences
Item features
- [ ] USB: Item which stores media sources
- Supports uploaded media and online media
- Playlist support
- [ ] Bateries: Item which stores Forge Energy (FE) and powers few specific items and blocks
- Batteries has 3 variants
- Disposable: Has a low amount of FE, are charged by default and cannot be recharged
- Rechargable: Has a mid capacity of FE, are not charged by default and can be recharged
- Creative: Infinite FE battery, can be recharged and is charged by default (uncharged variant stores an infinite amount of FE)
- Batteries has 3 variants
- [ ] Tablet: Item display to watch images and videos in your hand
- Requires batteries
- Can be placed on lecterns
- [ ] Remote Control: Rework of its functionallity
- Requires batteries to work
- Displays will have its own specific remote and cannot be cross-used
- Remotes can be used on "focus" mode (like create redstone control)
- Remote must validate display dimension
- [ ] Smart Remote Control: An universal variant, let you open the display screen remotely
- Can be placed on lecterns
- Cannot put or pull the USB
- Stores media sources (playlists) and can be synced to displays)
- [ ] Include a command for those features for server-admins
Block features
- [ ] Inclined TV
- Add a 15° TV option for the normal TV
- [ ] Projector's projection will be restricted to the most closer block (config option enabled by default)
- [ ] Modular redstone input: Choose actions or create scripts for redstone inputs
- Can handle options like: Play/Pause/Stop, Reset, Seek to, Fast Foward, Rewind and Shutdown
- Scripts are stored only in the displays
- [ ] Multi-options redstone output: Choose what info should output using comparators
- Can handle options like: Media Time and Playlist position.
- [ ] New block: Projector Squared
- Renders the media in a square on all horizontal faces
- Cannot be relocated (image is centered by default)
- Can be resized
- Can be rotated
- Can be transparentized
- Audio source is by default on the display
- [ ] New Block: Old CCTV (#107)
- Is a modern TV reskin but using a 1:1 aspect ratio
- Includes 2 styles
- [ ] New block: Hacking laptop
- Can shutdown (PEM) displays in a radius
- Overwrite URLs (Hacking) from all displays in a radius
- Server-Admin command to perform this without the block
- [ ] New block: Radios
- Are not displays, those only plays audio
- Doesn't support any remote
- Can put only USBs
- Block has a overlay showing the status
Screen Redesign
- [ ] Screen rewrite: Adding tabs for different features such as [media, rendering, permissions, aspects]
- [ ] Media: Playlist, Item "disk": contains a URL, File selector.
- [ ] Rendering: Alpha, Brightness, Rotation, Projection distance, Image position, Audio position, Volumes
- [ ] Permissions: Auth players to edit the frame (who places it = owner)
- [ ] Aspects: add block costetics such as textures
QoL Features
- [ ] Custom Advancements:
- Crafting displays
- Making a playlist
- Placing SRC on a lectern
- Using books as USB
- Watching a commercial
- Watching an Universal commercial
- Getting hacked
- Hacking
- Getting PEM'ed
- PEM'ing
- [ ] Displays can be edited on inventory without placing it
- [ ] Create mod compatibility
- Display can play media on assembled contraptions
- Can open screens on assembled contraptions
FINISHED IN 2.1.0
- [x] Use Translucent RenderType instead of directly use shaders + tesselator (better shaders compat shaders and solves #53)
- [x] #76
- [x] #37
CONSIDERED (NOT PROMISED in that UPDATE)
- Earbuds: Maybe i make another mod
- ~~Sound Pyshics Remastered compatibility: Depends on the WATERMeDIA v3 OpenAL API~~. Impossible due to SPR limited (unexistance) contact channels
- Mute Minecraft BG music when displays are nearby
- Data-Driven rendering: resourcepacks can customize picture rendering (posicion)
- Villagers: add a new village job, new trades (arround WF stuff) and more
- Enchantments: make RC's enchantable to increase max radius and battery duration)
- Overlays: Have a small Gui on the image renderer (begin controlable using RC arrows), texts saying "no signal", volume bar, channel index text and more things that can be added in a overlay)
Psst, you should add headphones/earbuds, and have the tablet play in-world audio unless those are worn. Could have curios optional compatibility too. Also battery could be done a la IC2-style battery, copper rod above 2 redstone, surrounded by 4 iron.
10/10 mod :3
Battery would just be a nuisance. If it really gets implemented add a config option to make it optional.
batteries are a great idea because the mod is not a core gameplay mod @diefesson. its also about implementation, sure adding batteries that have a set finite duration is boring and annoying. adding a config to enable and disable/modify these features would be mighty handy. i suggest the following.
3 types of batteries:
- creative battery - has infinite durability
- wireless battery - can be charged by wireless charging mods and the like
- normal battery - does what you think a battery does
Make sure to account for mods like [ https://modrinth.com/mod/enchancement ] that remove durability from items. big fan of the mod and everything it brings. Thanks
@sargeow Not sure how other mods could distinguish between normal and wireless batteries in a generic and clean way. What about "disposable" and "rechargeable" batteries?
- Creative: as stated above by sargeow.
- Disposable: cheap materials. Already charged when crafted. Can't be recharged.
- Rechargeable: expensivier materials. Can be recharged using RF.
Of course the consume and storage of energy could be changed in the config
I second what diefesson said, much better phrasing for each item than what i initially said!
Creative, Rechargeable and Disposable batteries are good ideas, on discord someone suggested disposable batteries when you haven't any mod to recharge FE stuff. but the concept here is way better defined
wireless batteries no.
you could add a new block named "Speaker" where you can connect a tv/frame/projector to it and the sound plays on it instead of the display, and you can chain multiple of them to create spatial audio
wowowo chill first i need to make a proper sound engine to process audio in java and have SoundPhysicsRemastered compat and then we will talk about Spartial audio
you could add a new block named "Speaker" where you can connect a tv/frame/projector to it and the sound plays on it instead of the display, and you can chain multiple of them to create spatial audio
I have some suggestions to generalize and simplify this request:
- Generalize code
- implement a MediaController: it's responsible for keeping track of URL and playback time, and providing decoded media.
- Every player block has a MediaController, but has the option to use the another block MediaController via linking, achieving master-slave syncing
- This way player blocks can have different playback capabilities (eg: BW color filter, audio channel filter...) independent of MediaController
- Create two new blocks
- Speaker Block: as playback capabilities are now independent of the MediaController a speaker is simply a "screen" without video
- Controller Block: just a utility. Acts like a "screen" without video or audio. It's main purpose is to have player blocks linked to it.
- UI changes
- With the changes above it would be nice to have some UI changes
- Player UI: every player has this UI (screens, speakers...). It will provide access to most of the already implemented features
- Audio Channel UI: accessible from Player UI. A list of toggles for what audio channels this block should reproduce
- Controller UI: as the controller hasn't most of player capabilites it could use a different UI to show current media metadata
This would also prevent some of the needs for a full fledged audio engine and complex spatial audio implementations as sound is simply played at speaker position
Ps: please don't interpret my suggestion as pressure to implement features. I just want to help. And sorry for the text wall 😅
wowowo chill first i need to make a proper sound engine to process audio in java and have SoundPhysicsRemastered compat and then we will talk about Spartial audio
just a suggestion, would really love to see spatial audio though, would be really cool but i'm not adding pressure for features
you could add a new block named "Speaker" where you can connect a tv/frame/projector to it and the sound plays on it instead of the display, and you can chain multiple of them to create spatial audio
I have some suggestions to generalize and simplify this request:
Generalize code
- implement a MediaController: it's responsible for keeping track of URL and playback time, and providing decoded media.
- Every player block has a MediaController, but has the option to use the another block MediaController via linking, achieving master-slave syncing
- This way player blocks can have different playback capabilities (eg: BW color filter, audio channel filter...) independent of MediaController
Create two new blocks
- Speaker Block: as playback capabilities are now independent of the MediaController a speaker is simply a "screen" without video
- Controller Block: just a utility. Acts like a "screen" without video or audio. It's main purpose is to have player blocks linked to it.
UI changes
- With the changes above it would be nice to have some UI changes
- Player UI: every player has this UI (screens, speakers...). It will provide access to most of the already implemented features
- Audio Channel UI: accessible from Player UI. A list of toggles for what audio channels this block should reproduce
- Controller UI: as the controller hasn't most of player capabilites it could use a different UI to show current media metadata
This would also prevent some of the needs for a full fledged audio engine and complex spatial audio implementations as sound is simply played at speaker position
Ps: please don't interpret my suggestion as pressure to implement features. I just want to help. And sorry for the text wall 😅
also this is pretty cool
I have an idea—could Waterframes support multithreading? In server environments, whenever the TPS fluctuates, the video playback tends to stutter or rewind. This is especially noticeable when players log in, as even a slight TPS drop causes video disruptions, which really hurts the experience.
Would it be possible to move the video playback/sync logic to a separate thread, similar to how Simple Voice Chat works? That way, even if the server TPS drops, the audio doesn’t lag—and the same could apply to videos.
you have an essential missunderstanding on how watermedia works on multiplayer. WaterMedia computes the media playback and timing of the mediaplayer. while waterframes acts like a time orchestator with no direct effects on multimedia processing
On server-side, the game calculates how much time has elaped and sends it to all clients to synchronize all players.
Now, this was done like that because the time orchestator also fires other stuff like redstone output (comparators) redstone input, blockstates and more, which requires to be in the mainthread.
Making waterframes offthread whould be a very hardcore change, because i have to do my own "tick timing", synchronization arround both threads and use atomic or volatile values over normal ones, which honestly will hit the performance way harder than lightLevel = (currentTime / maxTime) * 15.
Yes, you get a technical smoother playback, but with a performance tradeoff of at least 1TPS (because synchronize data between threads is not performance-cheap)
BUT, after saying all that technical explanation, i have to say... this was an already addressed issue, waterframes integrates by default a config option on server-side called "tickTimeCorrection", which (-as the name suggest), fixes the timing of the ticks when the TPS are low (enough). based on pure mathematical operations too.
you have an essential missunderstanding on how watermedia works on multiplayer. WaterMedia computes the media playback and timing of the mediaplayer. while waterframes acts like a time orchestator with no direct effects on multimedia processing
On server-side, the game calculates how much time has elaped and sends it to all clients to synchronize all players.
Now, this was done like that because the time orchestator also fires other stuff like redstone output (comparators) redstone input, blockstates and more, which requires to be in the mainthread.
Making waterframes offthread whould be a very hardcore change, because i have to do my own "tick timing", synchronization arround both threads and use atomic or volatile values over normal ones, which honestly will hit the performance way harder than
lightLevel = (currentTime / maxTime) * 15.Yes, you get a technical smoother playback, but with a performance tradeoff of at least 1TPS (because synchronize data between threads is not performance-cheap)
BUT, after saying all that technical explanation, i have to say... this was an already addressed issue, waterframes integrates by default a config option on server-side called "tickTimeCorrection", which (-as the name suggest), fixes the timing of the ticks when the TPS are low (enough). based on pure mathematical operations too.
Thank you for your explanation regarding this part. However, I did try toggling this configuration option (which should be enabled by default). The behavior I observed is that the tickTimeCorrection doesn’t seem to compensate quickly enough. For instance, after a player joins, the TPS drops, and then about 2 seconds later, the video playback experiences a reversal (depending on the severity of the lag, it may rewind by 2–10 seconds). I’m wondering if there’s a way to make tickTimeCorrection more aggressive?
So I can upload files from my local computer to the USB in the game and share them with others to view, right?
Dropping a suggestion here - for an added twist on survival worlds, it would be cool to have a config option that (if true) requires the displays/screens to have redstone power to function.
