Add InventoryView#sendTitleUpdate(Component)

[nopjar]

Adds a possibility to send a title update (packet). This does not change the title on the server.

resolves #7950

[nopjar]

Inline the imports (makes for a smaller diff, and less conflict on updates)

Done. Makes some lines extremely long, but nevermind I guess.

[Astralchroma]

This would be great for some stuff I am working on, is there any chance this could be merged soon?

[lynxplay]

I am unsure if this shouldn't live in UnsafeValues. The behaviour is definitely not 100% intented.

[broken1arrow]

This would be great for some stuff I am working on, is there any chance this could be merged soon?

If this not will be added, I can give code some work from 1.8.8 to at least to 1.19.1. but newer versions it use json to string

[Astralchroma]

This would be great for some stuff I am working on, is there any chance this could be merged soon?

If this not will be added, I can give code some work from 1.8.8 to at least to 1.19.1. but newer versions it use json to string

The related issue (#7950) listed some code which should work, so I have converted it to 1.19.2 mojang mappings for our own use.

[broken1arrow]

I am unsure if this shouldn't live in UnsafeValues. The behaviour is definitely not 100% intented.

Yeah is not "intended" behavior but it not exist other options to update inventory tittle while is open and under my testing is it safe run it asynchronous.

Could be something even Mojang self could implement long ago, is several cool things you can do with dynamic tittle (like tell amount of x item if the inventory currently add items or get removed and so much more).

[broken1arrow]

This would be great for some stuff I am working on, is there any chance this could be merged soon?

If this not will be added, I can give code some work from 1.8.8 to at least to 1.19.1. but newer versions it use json to string

The related issue (#7950) listed some code which should work, so I have converted it to 1.19.2 mojang mappings for our own use.

Yeah that are my older code. I made a better upgraded version with less repeated code (if I'm not update that).

Or do you use the Mojang mappings directly?

[Astralchroma]

This would be great for some stuff I am working on, is there any chance this could be merged soon?

If this not will be added, I can give code some work from 1.8.8 to at least to 1.19.1. but newer versions it use json to string

The related issue (#7950) listed some code which should work, so I have converted it to 1.19.2 mojang mappings for our own use.

Yeah that are my older code. I made a better upgraded version with less repeated code.

Interesting, could you send that "upgraded version"?

[lynxplay]

Yeah is not "intended" behavior but it not exist other options to update inventory tittle while is open and under my testing is it safe run it asynchronous.

I am not saying that it isn't working, it certainly works right now. I am arguing that it may be better in unsafe values as this functionality may stop working at any point in the future as it is not intended behaviour.

[Astralchroma]

Yeah is not "intended" behavior but it not exist other options to update inventory tittle while is open and under my testing is it safe run it asynchronous.

I am not saying that it isn't working, it certainly works right now. I am arguing that it may be better in unsafe values as this functionality may stop working at any point in the future as it is not intended behaviour.

That or maybe a sort of unsafe API annotation, along with clear documentation that it is unsafe.

[broken1arrow]

This would be great for some stuff I am working on, is there any chance this could be merged soon?

If this not will be added, I can give code some work from 1.8.8 to at least to 1.19.1. but newer versions it use json to string

The related issue (#7950) listed some code which should work, so I have converted it to 1.19.2 mojang mappings for our own use.

Yeah that are my older code. I made a better upgraded version with less repeated code.

Interesting, could you send that "upgraded version"?

was on mobile and to lazy to check, but that are pretty updated, but not hurt if made more improvements like not have several loadNmsClasses() methods some do same thing more or less. But yeah as always time is your enemy :)

[broken1arrow]

Yeah is not "intended" behavior but it not exist other options to update inventory tittle while is open and under my testing is it safe run it asynchronous.

I am not saying that it isn't working, it certainly works right now. I am arguing that it may be better in unsafe values as this functionality may stop working at any point in the future as it is not intended behaviour.

In theory should it work on newer versions (so long mojang not remove the packet some get send to player or get moved).

If i understand how paper compile the jar (they add the different nms mappings already (so this will find right classes) and so long mojang not remove that code to send packets I think it will exist for long time).

[Astralchroma]

This would be great for some stuff I am working on, is there any chance this could be merged soon?

If this not will be added, I can give code some work from 1.8.8 to at least to 1.19.1. but newer versions it use json to string

The related issue (#7950) listed some code which should work, so I have converted it to 1.19.2 mojang mappings for our own use.

Yeah that are my older code. I made a better upgraded version with less repeated code.

Interesting, could you send that "upgraded version"?

was on mobile and to lazy to check, but that are pretty updated, but not hurt if made more improvements like not have several loadNmsClasses() methods some do same thing more or less. But yeah as always time is your enemy :)

Ah, well I only really need 1.19.2 as the plugin is designed for a specific server, so I've just done this.

// NMS trickery to update the Inventory name without re-opening it
// See https://github.com/PaperMC/Paper/issues/7950 and https://github.com/PaperMC/Paper/pull/7979
(event.whoClicked as CraftPlayer).handle.connection.send(
	ClientboundOpenScreenPacket(
		(event.whoClicked as CraftPlayer).handle.containerMenu.containerId,
		(event.whoClicked as CraftPlayer).handle.containerMenu.type,
		PaperAdventure.asVanilla(buildPageText(target, pageNumber))
	)
)

[broken1arrow]

This would be great for some stuff I am working on, is there any chance this could be merged soon?

If this not will be added, I can give code some work from 1.8.8 to at least to 1.19.1. but newer versions it use json to string

The related issue (#7950) listed some code which should work, so I have converted it to 1.19.2 mojang mappings for our own use.

Yeah that are my older code. I made a better upgraded version with less repeated code.

Interesting, could you send that "upgraded version"?

was on mobile and to lazy to check, but that are pretty updated, but not hurt if made more improvements like not have several loadNmsClasses() methods some do same thing more or less. But yeah as always time is your enemy :)

Ah, well I only really need 1.19.2 as the plugin is designed for a specific server, so I've just done this.

// NMS trickery to update the Inventory name without re-opening it
// See https://github.com/PaperMC/Paper/issues/7950 and https://github.com/PaperMC/Paper/pull/7979
(event.whoClicked as CraftPlayer).handle.connection.send(
	ClientboundOpenScreenPacket(
		(event.whoClicked as CraftPlayer).handle.containerMenu.containerId,
		(event.whoClicked as CraftPlayer).handle.containerMenu.type,
		PaperAdventure.asVanilla(buildPageText(target, pageNumber))
	)
)

Yeah that are better way :) sadly I need it to work on any minecraft version.

[lynxplay]

In theory should it work on newer versions (so long mojang not remove the packet some get send to player or get moved).

Yes the method will still be able to "rename" an inventory, however the fact that there is any difference between the method and simply opening a new inventory with the same item is completely up to how the client handles a reused container id.

E.g. the client may simply properly open a new (or well the same) inventory when said packet it send in the future, resetting the mouse on the screen similar to opening a new inventory. This is what I am referring to when I am saying that this method may be unstable/abuses not intended behaviour. As there is not specific packet for renaming an open window and vanilla never uses this logic, this method relies on the specific quirk in the client to deliver different functionality from just opening a new inventory with the same items.

[broken1arrow]

In theory should it work on newer versions (so long mojang not remove the packet some get send to player or get moved).

Yes the method will still be able to "rename" an inventory, however the fact that there is any difference between the method and simply opening a new inventory with the same item is completely up to how the client handles a reused container id.

E.g. the client may simply properly open a new (or well the same) inventory when said packet it send in the future, resetting the mouse on the screen similar to opening a new inventory. This is what I am referring to when I am saying that this method may be unstable/abuses not intended behaviour. As there is not specific packet for renaming an open window and vanilla never uses this logic, this method relies on the specific quirk in the client to deliver different functionality from just opening a new inventory with the same items.

Sry for late replay. It will not reset the mouse this method if is what you referee to, open same menu again not break anything. The only way to break it, is if you send wrong packet to the client (hopper inventory instead of chest or wrong size). But you can easy build away this issues with player method (get the inventory player open that are 99% fail safe then).

What this exploit or use is the packet some server send to player (i don't think mojang can or will remove that because even mojang self really on that packet).

[Owen1212055]

Although this is rather nice, it's a bit hacky as we need to resend the entire inventory like this. What are some of the example use cases for this? Because at least, I'm not sure this is something we should encourage people to use.

[broken1arrow]

Although this is rather nice, it's a bit hacky as we need to resend the entire inventory like this. What are some of the example use cases for this? Because at least, I'm not sure this is something we should encourage people to use.

Here is examples (but you can do so much more, like animate the title) https://youtu.be/FvGoCpEh5cY

use the close inventory trick, break it for you (you can't have items on the cursor then). This packet is send async or it will be buggy.

Right now i has to hock in to nms and need check every minecraft version, so i know it still works. It could be better ways, but is mojang self use this but not in same way as i do it.

[Owen1212055]

I see, so you're using it to show information. That's interesting, but, maybe i'd mark this api as @ApiStatus.Experiemental?

[broken1arrow]

I see, so you're using it to show information. That's interesting, but, maybe i'd mark this api as @ApiStatus.Experiemental?

You can see my mess to class here https://github.com/PaperMC/Paper/issues/7950 (I think I has done some improvements some are not updated in the tread). But should work from 1.8.8 to 1.19.2 :)

Yes or page numbers, but you can do more like animations and in 1.16+ you can also exploit gradients to make crazy animated patterns (I not try it because I know that can be laggy).

[broken1arrow]

Ether way can be smart add @ApiStatus.Experiemental :) I mean if you not use it correctly, you will get strange issues (I don't know exactly the implementation plan in paper). Is not good idea send wrong inventory size in the packet to player (that not end up right at all) and player can end up lose items (no mater if it a "menu" or "custom inventory you store items").

[Owen1212055]

Thankfully we shouldn't have to worry about the wrong inventory sizes being sent, as the bukkit impl should have those values already given.

[broken1arrow]

Thankfully we shouldn't have to worry about the wrong inventory sizes being sent, as the bukkit impl should have those values already given.

yeah but the methods i use I need also specify right inventory and size or it will end up wrong inventory for client :) no mater the inventory player accentually open (but has not full view how it will be implemented in paper).

Ether way should be safe use it async (only side-effects in some rare cases it not update to latest info (but update it one more time and it is fine)).

[nopjar]

It seems like that this change is not really a thing. That's why I am closing it.

[broken1arrow]

It seems like that this change is not really a thing. That's why I am closing it.

It is ofc a thing and give me as developer more control over the title. No current method allow to change title without open inventory again.

I have use it from 1.8.8 to 1.19.4 and one plugin use my more hacked method on 100+ servers and 1000+ users has seen this without realizing the title update on the fly.

Add option directly, give me more time do other stuff than keep update for every Minecraft version.