RivMemory - sprawdź zużycie RAM bezpośrednio w grze

Riveilli · 9 Marca 2016

//

MowiaMiJanusz · 9 Marca 2016

Plugin jest okej

MrG2K · 9 Marca 2016

Nie rozumiem. Chodzi o sprawdzenie RAMu serwera, czy gracza? Bo ram gracza przecież pod F3 jest...

Riveilli · 9 Marca 2016

Nie rozumiem. Chodzi o sprawdzenie RAMu serwera, czy gracza? Bo ram gracza przecież pod F3 jest...

Chodzi o sprawdzanie aktualnego zużycia pamięci serwera, nie gracza.

MrG2K · 9 Marca 2016

Nie rozumiem. Chodzi o sprawdzenie RAMu serwera, czy gracza? Bo ram gracza przecież pod F3 jest...
Chodzi o sprawdzanie aktualnego zużycia pamięci serwera, nie gracza.

A, chyba że tak, wtedy wart uwagi.

KrejZi1337 · 9 Marca 2016

Plugin posiada jakieś permisje czy jak ?

TheMajster · 9 Marca 2016

Przydało by sie rozłożyć ten plugin na 2 klasy, ja w klasie głównej poraz pierwszy nie widzę onEnable ...

§ - te znaczki mogą Ci sie popsuć wiec lepiej zrób fixa z & na §.

  if (!sender.isOp()) {
            sender.sendMessage(this.tag + "Nie posiadasz wystarczaj\u0105cych uprawnie\u0144.");
            return true;
        }

Sprawdzaj permisje a nie op'a

Po co to ?

String.valueOf(freeMemory / 1024L / 1024L)

Jak wiadomość to String wiec nie musisz odczytywać tak :

Wystarczy samo freeMemory / x / x

Riveilli · 9 Marca 2016

@KrejZi1337

trzeba być operatorem, plugin nie posiada permisji

@TheMajster

1) po co rozkładać plugin który ma mniej niż 60 linijek i jedną komendę na dwie klasy?

2) co masz na myśli?

2) nawyk, na jedno wychodzi

AdamGrzegorz · 9 Marca 2016

@KrejZi1337

trzeba być operatorem, plugin nie posiada permisji

@TheMajster

1) po co rozkładać plugin który ma mniej niż 60 linijek i jedną komendę na dwie klasy?

2) co masz na myśli?

2) nawyk, na jedno wychodzi

Po prostu kolega się gówno zna, prawda @TheMajster? Nie odpisuj nawet, pogadamy jeszcze raz na ts3 o podstawach javy i znikniesz na "5 minut".

Nie "mogą się popsuć", tylko po prostu mapowanie kolorów to HEX (16 kolorów), nie cała ich gama.

Zrób sobię metodę:

public static String fixColors(String text) {
    return ChatColor.translateAlternateColorCodes(text, '&');
}

I za każdym razem jak coś piszesz na czacie dawaj to w fixColors();

Uwierz mi że działa kilkanaście razy szybciej (testowałem!)

Wiele klas nie jest w tym wypadku tak bardzo potrzebne, chociaż rzeczywiście mogłeś komendę przerzucić do innego pliku. A w klasie głównej przy onEnable(); rejestrować komendy. Szczerze powiedziawszy jest to strasznie nieczytelne i troszkę głupie wstawiać czysty onCommand w klasie głównej na "sucho".

Nie dawaj String.valueOf, można bez problemu dodawać longa/inta do wiadomości. I nie wychodzi na jedno, po prostu robisz niepotrzebny syf w kodzie, a tego nikt nie chce!

I tak troszkę boli mnie te days, hours... Nie lepiej ogarnąć sobie fajnego parsera? w FunnyGuilds jest coś podobnego:

https://github.com/dzikoysk/FunnyGuilds/blob/master/src/main/java/net/dzikoysk/funnyguilds/util/Parser.java#L69

albo z pełnym parsowaniem "godziny/a" itp: (nie wiem kim jest autor, nie obraź się jeżeli nim jesteś! )

  public static String parseTimeDiff(long millis)
  {
    if (millis == 0L) return "0";

    long days = TimeUnit.MILLISECONDS.toDays(millis);
    if (days > 0L) millis -= TimeUnit.DAYS.toMillis(days);
    long hours = TimeUnit.MILLISECONDS.toHours(millis);
    if (hours > 0L) millis -= TimeUnit.HOURS.toMillis(hours);
    long minutes = TimeUnit.MILLISECONDS.toMinutes(millis);
    if (minutes > 0L) millis -= TimeUnit.MINUTES.toMillis(minutes);
    long seconds = TimeUnit.MILLISECONDS.toSeconds(millis);
    if (seconds > 0L) millis -= TimeUnit.SECONDS.toMillis(seconds);

    StringBuilder sb = new StringBuilder();
    if (days > 0L) {
      sb.append(days);
      long i = days % 10L;
      if (i == 1L) sb.append(" dzien "); else
        sb.append(" dni ");
    }
    if (hours > 0L) {
      sb.append(hours);
      long i = hours % 10L;
      if (i == 1L) sb.append(" godzine ");
      else if (i < 5L) sb.append(" godziny "); else
        sb.append(" godzin ");
    }
    if (minutes > 0L) {
      sb.append(minutes);
      long i = minutes % 10L;
      if (i == 1L) sb.append(" minute ");
      else if (i < 5L) sb.append(" minuty "); else
        sb.append(" minut ");
    }
    if (seconds > 0L) {
      sb.append(seconds);
      long i = seconds % 10L;
      if (i == 1L) sb.append(" sekunde");
      else if (i < 5L) sb.append(" sekundy"); else
        sb.append(" sekund");
    }
    return sb.toString();
  }

Troszkę wolniejsze ale działa ciekawiej, bo trochę dziwnie mieć "2 godzin, 1 minut, 2 sekund"

Riveilli · 9 Marca 2016

@AdamGrzegorz, dzięki, rzeczywiście parser to dobry pomysł - wprowadzę zmiany w wolnej chwili.

bartzz · 9 Marca 2016

@KrejZi1337

trzeba być operatorem, plugin nie posiada permisji

@TheMajster

1) po co rozkładać plugin który ma mniej niż 60 linijek i jedną komendę na dwie klasy?

2) co masz na myśli?

2) nawyk, na jedno wychodzi

1. Bo tak się po prostu robi i tyle. Nie powinno się pisać w jednej klasie, jest to nieprzejrzyste. Wydajesz coś na publika - rób to jak najlepiej.

3. Nie wychodzi na jedno, bo zamiast odczytywać Stringa, to trzeba odczytać statyczną metodę z obiektu String, przekonwertować ponownie na Stringa, więc no.. :((

@KrejZi1337

trzeba być operatorem, plugin nie posiada permisji

@TheMajster

1) po co rozkładać plugin który ma mniej niż 60 linijek i jedną komendę na dwie klasy?

2) co masz na myśli?

2) nawyk, na jedno wychodzi

Po prostu kolega się gówno zna, prawda @TheMajster? Nie odpisuj nawet, pogadamy jeszcze raz na ts3 o podstawach javy i znikniesz na "5 minut".

Nie "mogą się popsuć", tylko po prostu mapowanie kolorów to HEX (16 kolorów), nie cała ich gama.

Zrób sobię metodę:
public static String fixColors(String text) {
return ChatColor.translateAlternateColorCodes(text, '&');
}
I za każdym razem jak coś piszesz na czacie dawaj to w fixColors();
Uwierz mi że działa kilkanaście razy szybciej (testowałem!)

Wiele klas nie jest w tym wypadku tak bardzo potrzebne, chociaż rzeczywiście mogłeś komendę przerzucić do innego pliku. A w klasie głównej przy onEnable(); rejestrować komendy. Szczerze powiedziawszy jest to strasznie nieczytelne i troszkę głupie wstawiać czysty onCommand w klasie głównej na "sucho".

Nie dawaj String.valueOf, można bez problemu dodawać longa/inta do wiadomości. I nie wychodzi na jedno, po prostu robisz niepotrzebny syf w kodzie, a tego nikt nie chce!

I tak troszkę boli mnie te days, hours... Nie lepiej ogarnąć sobie fajnego parsera? w FunnyGuilds jest coś podobnego:

https://github.com/dzikoysk/FunnyGuilds/blob/master/src/main/java/net/dzikoysk/funnyguilds/util/Parser.java#L69

albo z pełnym parsowaniem "godziny/a" itp: (nie wiem kim jest autor, nie obraź się jeżeli nim jesteś! )
public static String parseTimeDiff(long millis)
{
if (millis == 0L) return "0";

long days = TimeUnit.MILLISECONDS.toDays(millis);
if (days > 0L) millis -= TimeUnit.DAYS.toMillis(days);
long hours = TimeUnit.MILLISECONDS.toHours(millis);
if (hours > 0L) millis -= TimeUnit.HOURS.toMillis(hours);
long minutes = TimeUnit.MILLISECONDS.toMinutes(millis);
if (minutes > 0L) millis -= TimeUnit.MINUTES.toMillis(minutes);
long seconds = TimeUnit.MILLISECONDS.toSeconds(millis);
if (seconds > 0L) millis -= TimeUnit.SECONDS.toMillis(seconds);

StringBuilder sb = new StringBuilder();
if (days > 0L) {
sb.append(days);
long i = days % 10L;
if (i == 1L) sb.append(" dzien "); else
sb.append(" dni ");
}
if (hours > 0L) {
sb.append(hours);
long i = hours % 10L;
if (i == 1L) sb.append(" godzine ");
else if (i < 5L) sb.append(" godziny "); else
sb.append(" godzin ");
}
if (minutes > 0L) {
sb.append(minutes);
long i = minutes % 10L;
if (i == 1L) sb.append(" minute ");
else if (i < 5L) sb.append(" minuty "); else
sb.append(" minut ");
}
if (seconds > 0L) {
sb.append(seconds);
long i = seconds % 10L;
if (i == 1L) sb.append(" sekunde");
else if (i < 5L) sb.append(" sekundy"); else
sb.append(" sekund");
}
return sb.toString();
}
Troszkę wolniejsze ale działa ciekawiej, bo trochę dziwnie mieć "2 godzin, 1 minut, 2 sekund"

1. No niestety tutaj rację i masz i nie masz, bo ogólnie rzecz biorąc, to popsuć się nie mogą, ale mogą zostać zastąpione. Dzisiaj jest kolorek, za tydzień to może być emotka, nie wiesz co Mojang zaplanuje.

3. Co do tego syfu, to nie dość, że nieprzejrzyste, to i wolniejsze! Szybsze jest (int + "string"), niż (Integer.toString(int)) - testowane przez mojego wiernego kumpla zahuska.

Nota bene to ten kod od parsowania, to też mam parę zastrzeżeń. Ale najważniejsze, to tworzenie za każdym użyciem nowego obiektu StringBuilder'a. Przy jednorazowym użyciu nie wpłynie na wydajność, ale gdyby tak używać tego częściej, to już byłby problem.

A pluginek taki sobie, nawet nie można skonfigurować wiadomości ani nic.

AdamGrzegorz · 10 Marca 2016

@KrejZi1337

trzeba być operatorem, plugin nie posiada permisji

@TheMajster

1) po co rozkładać plugin który ma mniej niż 60 linijek i jedną komendę na dwie klasy?

2) co masz na myśli?

2) nawyk, na jedno wychodzi

1. Bo tak się po prostu robi i tyle. Nie powinno się pisać w jednej klasie, jest to nieprzejrzyste. Wydajesz coś na publika - rób to jak najlepiej.

3. Nie wychodzi na jedno, bo zamiast odczytywać Stringa, to trzeba odczytać statyczną metodę z obiektu String, przekonwertować ponownie na Stringa, więc no..
@KrejZi1337

trzeba być operatorem, plugin nie posiada permisji

@TheMajster

1) po co rozkładać plugin który ma mniej niż 60 linijek i jedną komendę na dwie klasy?

2) co masz na myśli?

2) nawyk, na jedno wychodzi

Po prostu kolega się gówno zna, prawda @TheMajster? Nie odpisuj nawet, pogadamy jeszcze raz na ts3 o podstawach javy i znikniesz na "5 minut".

Nie "mogą się popsuć", tylko po prostu mapowanie kolorów to HEX (16 kolorów), nie cała ich gama.

Zrób sobię metodę:
public static String fixColors(String text) {
return ChatColor.translateAlternateColorCodes(text, '&');
}
I za każdym razem jak coś piszesz na czacie dawaj to w fixColors();
Uwierz mi że działa kilkanaście razy szybciej (testowałem!)

Wiele klas nie jest w tym wypadku tak bardzo potrzebne, chociaż rzeczywiście mogłeś komendę przerzucić do innego pliku. A w klasie głównej przy onEnable(); rejestrować komendy. Szczerze powiedziawszy jest to strasznie nieczytelne i troszkę głupie wstawiać czysty onCommand w klasie głównej na "sucho".

Nie dawaj String.valueOf, można bez problemu dodawać longa/inta do wiadomości. I nie wychodzi na jedno, po prostu robisz niepotrzebny syf w kodzie, a tego nikt nie chce!

I tak troszkę boli mnie te days, hours... Nie lepiej ogarnąć sobie fajnego parsera? w FunnyGuilds jest coś podobnego:

https://github.com/dzikoysk/FunnyGuilds/blob/master/src/main/java/net/dzikoysk/funnyguilds/util/Parser.java#L69

albo z pełnym parsowaniem "godziny/a" itp: (nie wiem kim jest autor, nie obraź się jeżeli nim jesteś! )
public static String parseTimeDiff(long millis)
{
if (millis == 0L) return "0";

long days = TimeUnit.MILLISECONDS.toDays(millis);
if (days > 0L) millis -= TimeUnit.DAYS.toMillis(days);
long hours = TimeUnit.MILLISECONDS.toHours(millis);
if (hours > 0L) millis -= TimeUnit.HOURS.toMillis(hours);
long minutes = TimeUnit.MILLISECONDS.toMinutes(millis);
if (minutes > 0L) millis -= TimeUnit.MINUTES.toMillis(minutes);
long seconds = TimeUnit.MILLISECONDS.toSeconds(millis);
if (seconds > 0L) millis -= TimeUnit.SECONDS.toMillis(seconds);

StringBuilder sb = new StringBuilder();
if (days > 0L) {
sb.append(days);
long i = days % 10L;
if (i == 1L) sb.append(" dzien "); else
sb.append(" dni ");
}
if (hours > 0L) {
sb.append(hours);
long i = hours % 10L;
if (i == 1L) sb.append(" godzine ");
else if (i < 5L) sb.append(" godziny "); else
sb.append(" godzin ");
}
if (minutes > 0L) {
sb.append(minutes);
long i = minutes % 10L;
if (i == 1L) sb.append(" minute ");
else if (i < 5L) sb.append(" minuty "); else
sb.append(" minut ");
}
if (seconds > 0L) {
sb.append(seconds);
long i = seconds % 10L;
if (i == 1L) sb.append(" sekunde");
else if (i < 5L) sb.append(" sekundy"); else
sb.append(" sekund");
}
return sb.toString();
}
Troszkę wolniejsze ale działa ciekawiej, bo trochę dziwnie mieć "2 godzin, 1 minut, 2 sekund"
1. No niestety tutaj rację i masz i nie masz, bo ogólnie rzecz biorąc, to popsuć się nie mogą, ale mogą zostać zastąpione. Dzisiaj jest kolorek, za tydzień to może być emotka, nie wiesz co Mojang zaplanuje.

3. Co do tego syfu, to nie dość, że nieprzejrzyste, to i wolniejsze! Szybsze jest (int + "string"), niż (Integer.toString(int)) - testowane przez mojego wiernego kumpla zahuska.

Nota bene to ten kod od parsowania, to też mam parę zastrzeżeń. Ale najważniejsze, to tworzenie za każdym użyciem nowego obiektu StringBuilder'a. Przy jednorazowym użyciu nie wpłynie na wydajność, ale gdyby tak używać tego częściej, to już byłby problem.

A pluginek taki sobie, nawet nie można skonfigurować wiadomości ani nic.

Nadal czegoś nie rozumiesz, kolory w minecraft to nie cały alfabet a jedynie HEX czyli 16 możliwych warunków (0 do F) dlatego Mojang nie może wprowadzić nic innego, musiałby naruszyć zasadę działania HEX lub zmienić pobieranie kolorów już nie na HEX, a np. na własny system (bo w RGB, HEX itp. nie dodasz emotek).

translateAlternateColors jest nawet do kilkunastu razy szybszy, replacowanie za każdym razem & na paragraf naprawdę nie jest dobrym rozwiązaniem. A w pluginie liczy się szybkość, prawda?

PS: Oczywiście że ten kod do parsowania nie jest dobry, dałem jedynie przykład jak MOŻNA to zrobić, nie jak POWINNO się robić! :]

bartzz · 10 Marca 2016

@AdamGrzegorz Ale chwila.. przecież ja to wiem ;_; ale chodziło mi o to, ze paragraf nie jest jakoś z dupy domyślnie ustawiony w środowisku Windowsa.

A co do replace'owania, to na pewno, nic nie negowałem, ale ogółem "".replace jest lipne :|. Lepiej używać replace'a ze StringUtils, a najlepiej to zrobić własną na podstawie Suppliera, ale już goto to kiedyś tłumaczył.

Pozdrawiam, liczę na poprawę tych błędów!

In-ferN-O · 10 Marca 2016

Pluginek ok Lecz to jest w Essentials

10 Marca 2016

Nie patrzyłem w kod, bo mnie to niezbyt interesuje, ale

Przydało by sie rozłożyć ten plugin na 2 klasy, ja w klasie głównej poraz pierwszy nie widzę onEnable ...

nie, nie przydałoby się rozkładać na dwie klasy pluginu, który wykonuje jedną czynność

permisje

uprawnienia*

Po co to ?

String.valueOf(freeMemory / 1024L / 1024L)

najlepszym wyjściem byłoby String.format, ale lepsze już "xxx: " + String.valueOf(124 * 12123 * 123123 * 123), niż sam nawias z działaniem

1. Bo tak się po prostu robi i tyle. Nie powinno się pisać w jednej klasie, jest to nieprzejrzyste. Wydajesz coś na publika - rób to jak najlepiej.

"tak się robi" to żaden argument, wydał plugin jako binarkę, więc formatowanie kodu to tylko i wyłącznie jego zmartwienie

3. Nie wychodzi na jedno, bo zamiast odczytywać Stringa, to trzeba odczytać statyczną metodę z obiektu String, przekonwertować ponownie na Stringa, więc no..

String.valueOf wywołuje metodę toString() podanego argumentu, więc nie "odczytujesz" metody, tylko po skompilowaniu pojawia się opcode ją wywołujący, poza tym nie ma różnicy, czy toString() zostanie wywołane przez valueOf, czy przy łączeniu liczby ze stringiem

Ale najważniejsze, to tworzenie za każdym użyciem nowego obiektu StringBuilder'a. Przy jednorazowym użyciu nie wpłynie na wydajność, ale gdyby tak używać tego częściej, to już byłby problem.

.NET i Java mają garbage collector.

bartzz · 11 Marca 2016

Nie patrzyłem w kod, bo mnie to niezbyt interesuje, ale

Przydało by sie rozłożyć ten plugin na 2 klasy, ja w klasie głównej poraz pierwszy nie widzę onEnable ...

nie, nie przydałoby się rozkładać na dwie klasy pluginu, który wykonuje jedną czynność

permisje

uprawnienia*
Po co to ?
String.valueOf(freeMemory / 1024L / 1024L)
najlepszym wyjściem byłoby String.format, ale lepsze już "xxx: " + String.valueOf(124 * 12123 * 123123 * 123), niż sam nawias z działaniem

1. Bo tak się po prostu robi i tyle. Nie powinno się pisać w jednej klasie, jest to nieprzejrzyste. Wydajesz coś na publika - rób to jak najlepiej.

"tak się robi" to żaden argument, wydał plugin jako binarkę, więc formatowanie kodu to tylko i wyłącznie jego zmartwienie

3. Nie wychodzi na jedno, bo zamiast odczytywać Stringa, to trzeba odczytać statyczną metodę z obiektu String, przekonwertować ponownie na Stringa, więc no..

String.valueOf wywołuje metodę toString() podanego argumentu, więc nie "odczytujesz" metody, tylko po skompilowaniu pojawia się opcode ją wywołujący, poza tym nie ma różnicy, czy toString() zostanie wywołane przez valueOf, czy przy łączeniu liczby ze stringiem

Ale najważniejsze, to tworzenie za każdym użyciem nowego obiektu StringBuilder'a. Przy jednorazowym użyciu nie wpłynie na wydajność, ale gdyby tak używać tego częściej, to już byłby problem.

.NET i Java mają garbage collector.

Wiesz, ze toString(), a + "" to żadna różnica?

toString() - 72ms

+ "" - 76ms

A co do formatowania, to jednak są jakieś zasady, które Oracle narzuca, np nazwy paczek z małych liter. Choć formatowanie narzuca nam już bardziej IDE, to i tak: wydajesz coś pod publikę - trzymaj się zasad.

Nie rozumiem co ma Garbage collector do tworzenia za każdym razem nowego obiektu.

Riveilli · 12 Marca 2016

refresh

12 Marca 2016

toString() - 72msWiesz, ze toString(), a + "" to żadna różnica?

+ "" - 76ms

Tak, właśnie to napisałem wyżej na twoje "3. Nie wychodzi na jedno, bo zamiast odczytywać Stringa, to trzeba odczytać statyczną metodę z obiektu String, przekonwertować ponownie na Stringa, więc no.. ", które sugeruje, że String.valueOf powoduje większy narzut, tutaj dokładniejsze dane o prędkości.

A co do formatowania, to jednak są jakieś zasady, które Oracle narzuca, np nazwy paczek z małych liter. Choć formatowanie narzuca nam już bardziej IDE, to i tak: wydajesz coś pod publikę - trzymaj się zasad.

Nikt niczego nie narzuca, są pewne wytyczne od Oracle, których albo się trzymasz, albo nie. IDE pozwala skonfigurować każdy aspekt formatowania kodu. I powtarzam, wydał binarkę, nie kod.

Nie rozumiem co ma Garbage collector do tworzenia za każdym razem nowego obiektu.

To, że posprząta po opuszczeniu metody. 1, 2.

bartzz · 13 Marca 2016

toString() - 72msWiesz, ze toString(), a + "" to żadna różnica?

+ "" - 76ms

Tak, właśnie to napisałem wyżej na twoje "3. Nie wychodzi na jedno, bo zamiast odczytywać Stringa, to trzeba odczytać statyczną metodę z obiektu String, przekonwertować ponownie na Stringa, więc no.. ", które sugeruje, że String.valueOf powoduje większy narzut, tutaj dokładniejsze dane o prędkości.

A co do formatowania, to jednak są jakieś zasady, które Oracle narzuca, np nazwy paczek z małych liter. Choć formatowanie narzuca nam już bardziej IDE, to i tak: wydajesz coś pod publikę - trzymaj się zasad.

Nikt niczego nie narzuca, są pewne wytyczne od Oracle, których albo się trzymasz, albo nie. IDE pozwala skonfigurować każdy aspekt formatowania kodu. I powtarzam, wydał binarkę, nie kod.

Nie rozumiem co ma Garbage collector do tworzenia za każdym razem nowego obiektu.

To, że posprząta po opuszczeniu metody. 1, 2.

Ale chwila. Garbage collector ma się nijak do zlego nawyku, mianowicie za każdym razem tworzenia nowego obiektu.

Nie wydał kodu, racja, ale jednak Oracle narzuca nam pewne rzeczy, w prawdzie dlatego, żeby móc oddzielić zmienne od innych dupereli itp. Ale jednak wydając coś pod publikę przy poważniejszych projektach powinien sie trzymać tych zasad.

13 Marca 2016

toString() - 72msWiesz, ze toString(), a + "" to żadna różnica?

+ "" - 76ms

Tak, właśnie to napisałem wyżej na twoje "3. Nie wychodzi na jedno, bo zamiast odczytywać Stringa, to trzeba odczytać statyczną metodę z obiektu String, przekonwertować ponownie na Stringa, więc no.. ", które sugeruje, że String.valueOf powoduje większy narzut, tutaj dokładniejsze dane o prędkości.

A co do formatowania, to jednak są jakieś zasady, które Oracle narzuca, np nazwy paczek z małych liter. Choć formatowanie narzuca nam już bardziej IDE, to i tak: wydajesz coś pod publikę - trzymaj się zasad.

Nikt niczego nie narzuca, są pewne wytyczne od Oracle, których albo się trzymasz, albo nie. IDE pozwala skonfigurować każdy aspekt formatowania kodu. I powtarzam, wydał binarkę, nie kod.

Nie rozumiem co ma Garbage collector do tworzenia za każdym razem nowego obiektu.

To, że posprząta po opuszczeniu metody. 1, 2.
Ale chwila. Garbage collector ma się nijak do zlego nawyku, mianowicie za każdym razem tworzenia nowego obiektu.

Nie wydał kodu, racja, ale jednak Oracle narzuca nam pewne rzeczy, w prawdzie dlatego, żeby móc oddzielić zmienne od innych dupereli itp. Ale jednak wydając coś pod publikę przy poważniejszych projektach powinien sie trzymać tych zasad.

To nie jest zły nawyk, to się nazywa trzymanie obiektów lokalnych z dala od globalnych.

Wszystko zależy od tego, jakie nazewnictwo ustalisz z teamem.

bartzz · 14 Marca 2016

^ Nie, to się nazywa niepotrzebne lagowanie serwera. A jest to złym nawykiem nie przez to, ze tworzy nowego StringBuildera (bo jest dosyć szybki), ale tworzy nowy obiekt przy użyciu każdej metody. Miałem w moim Starym pluginie metodę na pobieranie miejsca (w topce) gracza. Robiłem to w try/catch, 15 miejsc. A jak był tylko jeden to 14 obiektów Exception. Wyobrażasz to sobie?

A trzymać sobie może tę metodę (razem z wcześniej zainicjowanym obiektem) w jakiejś klasie z utilsami.

Riveilli · 15 Marca 2016

refresh

Riveilli · 16 Marca 2016

refresh

Riveilli · 18 Marca 2016

refresh

SoQrAy · 18 Marca 2016

Świetny plugin! Na długo zostanie przy moim serwerze.

Zaloguj się

👋 Witaj na MPCForum!

RivMemory - sprawdź zużycie RAM bezpośrednio w grze

Rekomendowane odpowiedzi

Gość

Gość

Gość

Gość

Gość

Gość

Zarchiwizowany