usage (BARDZO WAŻNE!)

Jeśli w taki sposób to nie działa, to raczej nie będzie się dało tego zrobić.

Prostym rozwiązaniem może być sprawdzanie w if'ach argumentów i w else dodać wiadomość o poprawnym użyciu. 

8 godzin temu, CoFFeIN04 napisał:

Jeśli w taki sposób to nie działa, to raczej nie będzie się dało tego zrobić.

Prostym rozwiązaniem może być sprawdzanie w if'ach argumentów i w else dodać wiadomość o poprawnym użyciu. 

No dobrze a jak zrobić żeby sprawdzać czy argument faktycznie jest liczbą, a nie jest zapisany jako Text tyłko integer? 

8 minut temu, TeZetYT napisał:

No dobrze a jak zrobić żeby sprawdzać czy argument faktycznie jest liczbą, a nie jest zapisany jako Text tyłko integer? 

Wystarczy określić jego typ jako 'integer', a nie 'text'. Proszę zwrócić uwagę, że to nie wykonujący komendę decyduje czy argument to będzie "40", czy też 40, a sama osoba tworząca komendę. To ona podejmuje taką decyzję poprzez określenie typu argumentu. Przykład poniżej.

command /komenda <integer> <text>:
	trigger:
		# [...]

W powyższym przykładzie argument nr 1 zawsze będzie typem całkowitym ('integer'), a argument nr 2 zawsze będzie typem tekstowym ('text'). Warto zauważyć, że dziedzina pierwszego argumentu (prościej mówiąc, liczba możliwych wartości) jest węższa niż dziedzina drugiego argumentu. Jeżeli użytkownik spróbuje podać jako pierwszy argument wartość inną niż liczba całkowita, wiadomość z pola 'usage' zostanie wysłana. Drugi argument natomiast przyjmie dowolną wartość i nie ma mowy o podaniu do niego niepoprawnej wartości.
Co prawda nie wspomniałem o tym, ale oba argumentu muszą zostać podane przy wykonywaniu komendy, co objawia się brakiem nawiasów kwadratowych przy argumentach w definicji komendy.

Po więcej informacji odsyłam do poradnika mojego przyjaciela, Pana Marudy:

Odpowiadając szerzej na Pana pytanie, gdyby mieć pewną wartość o nieznanym typie zapisaną do zmiennej, możemy skorzystać z poniższego warunku.

if {_myVar} is an integer:
if {_myVar} is a text:
if {_myVar} is a player:
# [...]

9 godzin temu, TeZetYT napisał:

Witam mam bardzo poważny problem, otóż nie mogę dać niczego w procentach do sekcji komendy USAGE, np jak daje %arg-1% to zamiast argumentu wyświetla się po prostu %arg-1%

ma ktoś jakieś rozwiązanie na to? Jeśli tak to proszę o szybką odpowiedź bo jest to dla mnie bardzo ważne!

Tak jak zostało to wyżej powiedziane, nie jest to możliwe. Rozwiązanie już podał kolega wyżej.

Pozdrawiam.

20 minut temu, Kormic napisał:

Wystarczy określić jego typ jako 'integer', a nie 'text'. Proszę zwrócić uwagę, że to nie wykonujący komendę decyduje czy argument to będzie "40", czy też 40, a sama osoba tworząca komendę. To ona podejmuje taką decyzję poprzez określenie typu argumentu. Przykład poniżej.

command /komenda <integer> <text>:
	trigger:
		# [...]

W powyższym przykładzie argument nr 1 zawsze będzie typem całkowitym ('integer'), a argument nr 2 zawsze będzie typem tekstowym ('text'). Warto zauważyć, że dziedzina pierwszego argumentu (prościej mówiąc, liczba możliwych wartości) jest węższa niż dziedzina drugiego argumentu. Jeżeli użytkownik spróbuje podać jako pierwszy argument wartość inną niż liczba całkowita, wiadomość z pola 'usage' zostanie wysłana. Drugi argument natomiast przyjmie dowolną wartość i nie ma mowy o podaniu do niego niepoprawnej wartości.
Co prawda nie wspomniałem o tym, ale oba argumentu muszą zostać podane przy wykonywaniu komendy, co objawia się brakiem nawiasów kwadratowych przy argumentach w definicji komendy.

Po więcej informacji odsyłam do poradnika mojego przyjaciela, Pana Marudy:

Odpowiadając szerzej na Pana pytanie, gdyby mieć pewną wartość o nieznanym typie zapisaną do zmiennej, możemy skorzystać z poniższego warunku.

if {_myVar} is an integer:
if {_myVar} is a text:
if {_myVar} is a player:
# [...]

 

Tak jak zostało to wyżej powiedziane, nie jest to możliwe. Rozwiązanie już podał kolega wyżej.

Pozdrawiam.

problem w tym, że gdy dam typ argumentu integer, to gdy podam tekst, to pokaże brzydkie correct usage, a nie mogę dać swojego tekstu w USAGE bo yamla się tam nie da dać przez te procenty, a kiedy dam np. if {_} is an integer: to skrypt nawet nie przejdzie do wykonania tej sekcji, bo widzi że źle dałem argument zły i mimo wszystko wyśle mi to co jest w usage, no a w usage nic nie dam bo yamla tam musze wkleić  Mam nadzieję, że rozumie Pan, co mam namyśli bo nie wiem czy dobrze to wytłumaczyłem jaki mam problem z tym.

25 minut temu, TeZetYT napisał:

problem w tym, że gdy dam typ argumentu integer, to gdy podam tekst, to pokaże brzydkie correct usage, a nie mogę dać swojego tekstu w USAGE bo yamla się tam nie da dać przez te procenty, a kiedy dam np. if {_} is an integer: to skrypt nawet nie przejdzie do wykonania tej sekcji, bo widzi że źle dałem argument zły i mimo wszystko wyśle mi to co jest w usage, no a w usage nic nie dam bo yamla tam musze wkleić  Mam nadzieję, że rozumie Pan, co mam namyśli bo nie wiem czy dobrze to wytłumaczyłem jaki mam problem z tym.

W takim razie można to inaczej rozwiązać. Przykład poniżej.

command /komenda [<text="10">]:
	trigger:
		set {_numberArg} to arg parsed as integer
		{_numberArg} is set
		send "Podany argument jest liczbą całkowitą." to sender

Ten fragment kodu wykorzystuje sztuczkę polegającą na tym, że wyrażenie 'parsed as' w przypadku niemożności przemianowania na inny typ nic nie zwraca, a więc zmienna {_numberArg} będzie pusta. Jeżeli jednak podany argument jest liczbą całkowitą, wiadomość zostanie wysłana.

Pozdrawiam.

W dniu 9.07.2024 o 10:13, Kormic napisał:

W takim razie można to inaczej rozwiązać. Przykład poniżej.

command /komenda [<text="10">]:
	trigger:
		set {_numberArg} to arg parsed as integer
		{_numberArg} is set
		send "Podany argument jest liczbą całkowitą." to sender

Ten fragment kodu wykorzystuje sztuczkę polegającą na tym, że wyrażenie 'parsed as' w przypadku niemożności przemianowania na inny typ nic nie zwraca, a więc zmienna {_numberArg} będzie pusta. Jeżeli jednak podany argument jest liczbą całkowitą, wiadomość zostanie wysłana.

Pozdrawiam.

a jak zablokować dodawanie większej ilości argumentów niż jest zdefiniowanych w komendzie z własną wiadomością bez sekcji usage?

10 minut temu, TeZetYT napisał:

a jak zablokować dodawanie większej ilości argumentów niż jest zdefiniowanych w komendzie z własną wiadomością bez sekcji usage?

Proszę zauważyć, że jeżeli argument typu 'text' nie jest ostatni to można go zapełnić jednym słowem, a jeżeli jest na końcu, wtedy ilość słów jaką może pomieścić, jest nieograniczona.

Aby ograniczyć ilość słów w ostatnim argumencie typu 'text' do jednego, należy użyć wyrażenia 'split at' i sprawdzić ile elementów zwróci te wyrażenie. Najprościej będzie więc zapisać jego wynik do lokalnej listy zmiennych. Przykład poniżej.

command /test <number> [<text="test">]:
	trigger:
		set {_arg2::*} to arg-2 split at " "
		if size of {_arg2::*} > 1:
			stop
		send "%arg-1% %arg-2%" to sender

Łatwo zauważyć, że powyższy problem można sprowadzić do sprawdzenia czy drugi element listy istnieje i czy nie jest on tekstem postaci "". Co prawda podejrzewam, że Skript usuwa spacje na początkach i końcach argumentów, jednakże wymaga to sprawdzenia.

# [...]
set {_arg2::*} to arg-2 split at " "
if:
	{_arg2::2} is set
	{_arg2::2} is not ""
then:
	send "&6Argument nr 2 nie może składać się z więcej niż jednego słowa." to sender
	stop
# [...]

Pozdrawiam.