Skrypt na to, aby przedmiot red_dye nazwany &7test nie mógł się stackować nigdzie

W dniu 19.06.2024 o 13:09, The_Kodi napisał:

Skrypt na to, aby przedmiot red_dye nazwany &7test nie mógł się stackować nigdzie

Najprostszy sposób jaki przychodzi mi do głowy to nadanie każdemu z tych barwników unikalnych znaczników (tagów) NBT zawierających czas w nanosekundach wyznaczony względem pewnego arbitralnie ustalonego momentu (czasu). Nie będzie to widoczne dla gracza, a i unikamy nasłuchiwania do rozmaitych wariantów zdarzenia 'on inventory click'.

Proszę bardzo. Skrypt był testowany i zdaje się, że wszystko działa tak jak powinno.
Do jego poprawnego działania wymagane są dodatki skript-reflect i SkBee.

Rzecz jasna, niemożliwym jest uczynienie wszystkich istniejących już na serwerze barwników na serwerze niestackowalnymi. Możemy jedynie przy pewnych zdarzeniach i tworzeniu nowych czynić je takimi. Ponadto, proszę sobie wyobrazić chociażby sytuację, w której gracz posiada setki tych barwników w skrzyni. Przy takiej podmianie albo by je stracił z tej skrzyni, albo zostałyby one wyrzucone na ziemię.

Jak może Pan zauważyć, podmiana przedmiotu następuje tylko przy podnoszeniu przedmiotów. Wydaje mi się, że jest to wystarczające. Zresztą, gdybym miał podmieniać te przedmioty w ekwipunkach lub skrzyniach graczy, doszłoby do czarnego scenariusza, który opisałem wyżej.

import:
	java.lang.System
	
options:
	stackableItem: red dye named "&7test"

function addUnstackableNBTTag(i: item) :: item:
	if tag "timeID" of nbt of {_i} is set:
		return {_i}
	set {_newTimeID} to System.nanoTime()
	add "{timeID:%{_newTimeID}%L}" to nbt of {_i}
	return {_i}
		
pick up:
	1 of event-item is {@stackableItem}
	tag "timeID" of nbt of event-item is not set
	cancel event
	delete event-dropped item
	set {_amount} to item amount of event-item
	loop {_amount} times:
		drop addUnstackableNBTTag({@stackableItem}) at event-player

Na koniec dodam, że mogłem również to rozwiązać za pomocą modyfikacji CustomModelData lub PersistentDataContainer, ale nie zrobiłem tego w ten sposób, bo miałem ku temu pewne powody.

• Nie użyłem CustomModelData, gdyż blokuje to możliwość używania jakichkolwiek paczek zasobów (resource pack). Gdyby było tego mało, nie ma gwarancji, że już jakiś inny plugin nie wykorzystuje CustomModelData jako na przykład systemu ID.
• Nie wprowadzałem również danych do PersistentDataContainer, ponieważ użycie NBT w tym przypadku było zwyczajnie prostsze (ten sposób zajmuje mniej linijek).

Gdyby coś było nie tak ze skryptem, proszę dać znać.

Pozdrawiam.