Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] Adding more default protocols for vanilla blocks using the serial port #117

Open
Zenithsiz opened this issue Sep 14, 2020 · 6 comments

Comments

@Zenithsiz
Copy link

As the title suggests, adding more protocols other than the furnace protocol for other vanilla blocks.

From the README, I understand it's possible to create new protocols for blocks, which TIS-3D will use, but I believe most common vanilla blocks should have implementations within the library, given that the furnace has one.

Originally I wanted to submit this as a PR by adding a few protocols, but I do not have enough knowledge in java, the fabric API and this library to successfully contribute, so I'm opting to at least share some ideas.

Following are possible suggestions for some blocks, extrapolating from how the current furnace protocol works.
These are, of course, suggestions, and I'd love to see these protocols implemented, if possible, in any way found feasible, not just with these specific mechanics.

Most of these suggestions use the ability of the serial port to query the progress of a block that processes items (as mode 1 on the furnace currently operates) and the number of items in a slot (as mode 0 on the furnace currently operates).

I have also attempted to keep most suggestions relatively "simple" in spirit of the mod, as to not make the module be able to do too much. I've also tried to include some examples that would be possible with each new additions to motivate it (and find possible workarounds if the suggestions aren't worth it). Most of the examples use the idea of having a display monitor the block status, as I believe this is a common use case for this, the only thing we cannot do well is query the block state, which would be that these modules would serve for.

I also understand some of these would be feasible using a comparator to interface with the block and then reading the redstone output, but this is primitive, as it has a very low range of values for most blocks (0-15), such as chests, and does not allow for some of the use-cases suggested.

Possible block suggestions:

Chest / Barrel / Hopper

It would be legal to write to the module any value n ranging from 0-30 (or 0-5 if on a hopper). Reading from the module would then return the number of items in the nth slot.
I'm not familiar with the fabric API, but if double chests were interfaced as 1 unit, I would suggest the value ranging from 0-60 if a double chest is interfacing, else one would use 2 modules to fully read a double chest, which I also believe would be fitting for this mod.

Example

A possible use case for this interface would be to display a heat map of items in a chest on a display module, by reading each slot and writing it to it's respective place in the screen. This would allow the user to quickly see if any of their chests are getting full in a storage system and which ones are not sorted and messy.
Another use case is simply to count the total number of items in a chest or in a full storage system and display it to the user.

Brewing stand

Similar to the furnace, interfacing with this block would have 7 possible values, ranging from 0 to 6, inclusive. Disregarding order, these would provide access to:

  • Blaze powder in the fuel slot
  • Current fuel progress
  • Brewing progress
  • Item on top slot
  • Items on the bottom slots (using 3 values).

Example

A possible use case for this inteface would be to display a progress bar on a display module for the brewing system, as well as the current fuel level (possible considering leftover blaze powder in the fuel slot, by multiplying it's amount by 30 and adding it to the fuel, if this one ranges from 0-30).

Campfire

Similar to the chest, I believe 4 possible values would benefit this block, each one querying the remaining cooking time for each of the corners (or 0 if nothing is cooking).

Example

As with the furnace examples, one could simply split a display module into 4 and show the progress of each corner in a neat way.

Furnace / Blast furnace / Smoker

I believe it would also be fitting to extend the furnace module to be able to read the remaining slots on the block (input and output slots) as well as both the fuel burn and the cooking progress (which is already implemented).
I haven't been able to test if the serial port works with the blast furnace and smoker, but if not I would suggest it having the same interface as the normal furnace.

Example

It would be possible to divide a display module vertically into 2 progress bars, where the top part measures the current smelting progress and the bottom measures the current fuel (possible taking into account remaining fuel in the fuel slot, although one would need to know which type of fuel it is to know how many items it would smelt. This is not a functionality I would add to the serial port and would instead require the user to know ahead of time, or possible create another module that could give this information)

Respawn anchor

This block would simply have a read operations that would return the amount of fuel left in it.

Example

Having a vertical display of the number of respawns left in the anchor and possible sound an alarm each time it changes to signify it has gone down. Possibly even sounding a constant alarm when empty so the user knows to refill it before leaving.

Redundancy

As this item can only store 4 charges, a comparator can read it's signal losslessly, so there isn't much use for the serial port to do it as well, aside from providing a more direct interface.

Lectern

This block could be both written / read, where reads would return the current page, and writes would set the current page.

Example

I don't have a particular good use case for this, it would be neat to have, but doesn't serve much of a purpose, as it suffers from the same problem as the respawn anchor, where it's signal is near-lossless.

Another suggestion that comes up with the expansion of these blocks is to provide the "progress" values with their native values where applicable, such as the fuel of a brewing stand (0-30), the fuel of a furnace (0-100 in vanilla, using the lava bucket to get 100 operations) and the number of seconds left to smelt on a camp fire (0-30). Of course, other values such as the smelting progress have no units, and so an arbitrary range, such as the current 0-100 works fine, although maybe it would be good to use 0-255 to allow for more precision and make it all fit neatly into 1 byte.

The following are blocks I believe this module should not interface with and why they were excluded:

Enchanting table

As the interface is per-player and does not have shared storage, nor are the enchantments shared by players, there is not much the interface could read from this block. I do not believe it's worth interfacing with it due to this.

Ender chest

As with the enchanting table, the storage is not shared by all players, so the module would not be able to access any particular player storage.

@Sturmlilie
Copy link

Cool suggestions! We're currently in the process of fleshing out the API for extensions under fabric (see #115 ). I have a sample extension using the unstable API-in-progress here: https://github.com/Sturmlilie/TIS-3D-Additions.
A couple days ago, I was indeed working on a sample serial protocol using the API; I just cleaned it up and pushed it here: Sturmlilie/TIS-3D-Additions@3d28de9

It should have everything needed, including a manual book entry. I based the code off of the original furnace protocol. The ideas all seem very great. My hope is that once the API is stable, someone can implement them individually from the base mod, and then if Sangar likes them, they could also be merged back into the base.

@Zenithsiz
Copy link
Author

Thanks! I've looked through the brewing stand protocol using the new API you linked and it seems less overwhelming than the furnace protocol I looked at before, looks pretty easy to use and extend.

I'm not super confident in my abilities, but once the new API reaches stable, if you'd like, I'd be happy to try to implement some of the new base protocols, possibly after some discussion into what they should actually be.

@fnuecke
Copy link
Member

fnuecke commented Sep 15, 2020

Sounds cool :)
As you mentioned, this is sorta-kinda possible with a comparator, which is why this just never was a priority.
It would definitely be a nice addition!

@Szasdragon
Copy link

The Lectern could tell how many pages has the book on it, and what is the current page's number. The Lectern coud be used to controll like Redstone contraptions.

@Sturmlilie
Copy link

@Szasdragon Added a lectern protocol to the sample extension: https://www.curseforge.com/minecraft/mc-mods/tis-3d-additions/files/3122710

@UQuark
Copy link
Contributor

UQuark commented Apr 19, 2024

I'd really like to incorporate tis-3d-additions into the base mod. The license seems to be compatible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants