Mojang rozpoczyna banowanie serwerów niezgodnych z EULA

[thomasward]

Z jednej strony to dobre, ale jak się utrzymają servery?

[kuvuś]

Można nadal sprzedawać dodatki graficzne, pety, itp. Więc trochę możliwości jest, tylko trzeba umieć wymyślić coś ciekawego, co nie łamie EULI.

[Burned123]

Jakie dodatki graficzne?

[kuvuś]

Particle, disco zbroja, itp.

[cola!]

Minecraft został oficjalnie ubity strzałem w łeb. Zniszczyli tę grę

[Wahazar]

Pod warunkiem, że mieliby na czym grać Bo jak mamy postępować zgodnie z EULA, to należałoby zacząć od zablokowania wstępu na serwery graczom non-premium. A w Polsce takich graczy jest pewnie 80-90%.

 

Właściwie to gdzie w EULA jest napisane, że należy blokować dostęp graczom non-premium?

Niezgodne z EULA jest rozpowszechnianie skrackowanych launcherów, ale od kiedy uruchamianie serwera w trybie 'off-line' jest niedozwolone?

 

Odnośnie blokady serwerów P2W, uważam osobiście że to dobry pomysł, takie serwery to nieuczciwość do sześcianu:

1. nieuczciwość graczy płacących wobec niepłacących

2. nieuczciwość administracji drenujących pieniądze z graczy

3. nieuczciwość względem innych serwerów (duże przychody pozwalają na mocną reklamę i 'normalne' serwery nie mają szansy się przebić)

[Gosiiia]

 

Pod warunkiem, że mieliby na czym grać Bo jak mamy postępować zgodnie z EULA, to należałoby zacząć od zablokowania wstępu na serwery graczom non-premium. A w Polsce takich graczy jest pewnie 80-90%.

 

Właściwie to gdzie w EULA jest napisane, że należy blokować dostęp graczom non-premium?

Niezgodne z EULA jest rozpowszechnianie skrackowanych launcherów, ale od kiedy uruchamianie serwera w trybie 'off-line' jest niedozwolone?

 

 

Oto fragment EULA:

 

Therefore, if you comply with and follow the Brand and Asset Usage Guidelines and Naming Guidelines above YOU MAY:

• charge for access to your server, including a server which hosts your Mods, BUT only if:
  • you make a single charge per person that is the same for everyone;
  • you give everyone you charge, access to all the Mods that you choose to have on your server (except only in respect of genuine admin tools / admin Mods which should be reserved to administrators);
  • you only give access to your server to users who have a genuine paid for version of Minecraft;
  • you own or control the server and continue to do so for the whole time that you charge for access to it - so, if you sell the actual servers or server space with Mods pre-installed on them, you must ensure that the person buying the server is aware that she must follow these rules. Essentially you can't get round the rules above by setting up servers with Mods on and then selling those set-ups; and
  • overall your access charges should be targeted to cover your operational costs of running the server.

Jak widać zgodne z EULA jest dawaie dostępu do serwera jedynie graczom, który posiadają oryginalną, płatną wersję Minecrafta.

[Aintence]

Minecraft został oficjalnie ubity strzałem w łeb. Zniszczyli tę grę

Tak bo minecraft istnieje tylko dzieki wszystkim piratom z polski.

/s

[Wahazar]

 

 

Właściwie to gdzie w EULA jest napisane, że należy blokować dostęp graczom non-premium?

Niezgodne z EULA jest rozpowszechnianie skrackowanych launcherów, ale od kiedy uruchamianie serwera w trybie 'off-line' jest niedozwolone?

 

 

Oto fragment EULA:

 

Therefore, if you comply with and follow the Brand and Asset Usage Guidelines and Naming Guidelines above YOU MAY:

• charge for access to your server, including a server which hosts your Mods, BUT only if:
  • you make a single charge per person that is the same for everyone;
  • you give everyone you charge, access to all the Mods that you choose to have on your server (except only in respect of genuine admin tools / admin Mods which should be reserved to administrators);
  • you only give access to your server to users who have a genuine paid for version of Minecraft;
  • you own or control the server and continue to do so for the whole time that you charge for access to it - so, if you sell the actual servers or server space with Mods pre-installed on them, you must ensure that the person buying the server is aware that she must follow these rules. Essentially you can't get round the rules above by setting up servers with Mods on and then selling those set-ups; and
  • overall your access charges should be targeted to cover your operational costs of running the server.

Jak widać zgodne z EULA jest dawaie dostępu do serwera jedynie graczom, który posiadają oryginalną, płatną wersję Minecrafta.

 

Faktycznie, ale jest to fragment wycięty z Minecraft Commercial Usage Guidelines i odnosi się do serwerów, które pobierają opłaty za wstęp, w standardowej EULA nie widzę nic takiego.

 

Swoją drogą nie rozumiem, nie płacić za samą grę, a płacić za wirtualne itemy w grze?

[Memust]

Jak to jest? EULA z tego co wiem nie jest wymagana do akceptacji na niektórych silnikach, np. Thermos. Dalej, czy to dotyczy tylko wersji 1.9.2+, czy banowane są wszystkie serwery, a może tylko 1.7.10 i wyższe? Jak kiedyś czytałem, EULA mojangu stosuje się do serwerów na wszystkich wersjach. I czy wprowadzona zmiana będzie wpływała tylko na oficjalne launchery, czy też inni gracze, korzystający z piratów będą mogli grać bez przeszkód? Jeśli tak będzie, to Mojang tylko na tym ucierpi.

 

Moim zdaniem wpłynie to źle na Minecrafta, bo celem EULI mojangu pierwotnie miało być wyeliminowanie wielkich, nastawionych tylko i wyłącznie serwerów na Pay2Win. Większość hypixelów itd. była zmuszona zmienić zawartość swoich ItemShopów na pety, boostery i mystery case'y. Rozumiem Microsofta - wydali 2,5mld dolarów i chcą, żeby nikt nie korzystał z ich gry w celach zarobkowych bez odprowadzenia % od zysku, ale takie zmiany zaszkodzą MC.

 

Serwery zaczną eliminować same siebie, bo prawie każdy łamie EULE w celu utrzymania serwera, albo wszyscy zatrzymają się na 1.9.2 i niższych wersjach. Eliminacja konkurencji zniszczy jakość serwerów, bo podstawa dobrego rynku to konkurencja. Bez niej nie ma się o co starać. Czy Mojang chce udupić, za przeproszeniem, wszystkie serwery w ładny sposób i wprowadzić swoje? To nie zadziała - brak konkurencji i unikalności Minecraftowych serwerów zakopią tą grę w grobie już na zawsze.

 

Mam nadzieję, że serwery przetrwają, bo bez nich MC to dno. W zasadzie już od jakiegoś czasu 99% serwerów jest tworzonych dla kasy, a nie z pasji, ale jest ten 1% do pogrania na. Na obejście restrykcji mojangu zawsze znajdzie się sposób, ale wynajdą go tylko najlepsi w cwaniactwie. A największą zaletą MC jest to, że każdy może dołączyć się do tworzenia, a co z tego wynika, jest wielka różnorodność...

[kuvuś]

@Memust EULA to taki jakby regulamin narzucany przez Mojang dot. serwerów. Serwery są blokowane od wersji 1.7.x, ponieważ kod blokujący serwery został dodany do biblioteki, która jest używana przez grę od w. w. wersji.

[xRECORD2K]

No i dobrze, mam dość tego, że VIP może se latać po mapie a gracz gówno może Chociaż wystarczy że wymyślą pieniądze za paysafecard i problem z głowy 

[redpapryka1234]

Dobra zmiana wchodziłem na nie jeden serwer gdzie vip dostawał tyle rzeczy gdzie ktoś zbiera taki przez 3 dni  i nie miał w połowie takich itemek

[Nightday96]

No powiedzcie sami... Co to za sprawiedliwość że dzieci, które mają za dużo kasy, kupują VIP'y zatruwając innym grę. Na jednym nawet było że dostawało się full enchant miecz na 20 oraz ekwipunek diamentowy razem z ulepszonymi złotymi jabłkami itd.. Siedzieli poza granicą spawnu i zabijali kogo popadnie, za ekranem pewnie się bardzo cieszyli... 

[Feernea]

Czytam to i czytam. Czy przypadkiem dla Mojangu nie chodziło o to, że zabronione jest sprzedawanie 'wejściówek' na serwer dla non premek a nie całkowity zakaz wpuszczania non premium? Można to odebrać dwuznacznie, więc proszę o Wasze opinie.

 

Jeśli to tylko ta pierwsza opcja, to nie mamy się o co martwić.

[Nightday96]

Czytam to i czytam. Czy przypadkiem dla Mojangu nie chodziło o to, że zabronione jest sprzedawanie 'wejściówek' na serwer dla non premek a nie całkowity zakaz wpuszczania non premium? Można to odebrać dwuznacznie, więc proszę o Wasze opinie.

 

Jeśli to tylko ta pierwsza opcja, to nie mamy się o co martwić.

Tak chodzi o tą pierwszą. Wypuszczanie non premium raczej zawsze będzie możliwe. Tylko, że inne serwery aby się utrzymać oferują graczom niesamowite bonusy i możliwości, co nie podoba się Mojangowi, gdyż zarabiają na nich właściciele. 250 Graczy i załóżmy że 80 z nich to vipy które kosztują 11.07 80*11,07 = 885,60, czyli całkiem nie mało...

[Burned123]

 

Czytam to i czytam. Czy przypadkiem dla Mojangu nie chodziło o to, że zabronione jest sprzedawanie 'wejściówek' na serwer dla non premek a nie całkowity zakaz wpuszczania non premium? Można to odebrać dwuznacznie, więc proszę o Wasze opinie.

 

Jeśli to tylko ta pierwsza opcja, to nie mamy się o co martwić.

Tak chodzi o tą pierwszą. Wypuszczanie non premium raczej zawsze będzie możliwe. Tylko, że inne serwery aby się utrzymać oferują graczom niesamowite bonusy i możliwości, co nie podoba się Mojangowi, gdyż zarabiają na nich właściciele. 250 Graczy i załóżmy że 80 z nich to vipy które kosztują 11.07 80*11,07 = 885,60, czyli całkiem nie mało...

 

 

Zapomniałeś o prowizji, która wynosi +/- 50%, dodając do tego fakt, że taki zarobek nie tworzy się w miesiąc tylko w kilka bo raczej mało prawdopodobne, że w jeden miesiąc 80 osób wykupi vipa.

 

Ja ogólnie popieram karcenie serwerów tworzonych przez dzieci, które chcą zarobić na gotowych plikach. Nawet bym się ucieszył gdyby zostały same premium serwery, przynajmniej gdzie bym nie spojrzał to nie byłoby setki steve'ów

[Memust]

Updatując. Mojang wprowadza EULĘ - świetnie! Tylko za wcześnie. Problemy z utrzymaniem wszystkich serwerów, tych ogarniętych też, będą. Porządny dedyk nie jest taki tani. Czekam, aż Mojang wypuści Alphe Win 10 na C++. Wreszcie skończą się dni pie***** Javy, która zżera niesamowite ilości zasobów. Kiedy to się stanie, 500-600 graczy na MC Win 10 pomieści się na serwerze na którym pomieściłoby się 50 MC Javy.

[Velta]

Mojang wprowadza EULĘ - świetnie! Tylko za wcześnie.

Za wcześnie? Powinna być od samego początku. ;p

[ReFaza]

Mi się ten pomysł bardzo podoba, koniec z vipami i mikropłatnościami na serwerach mc 

Z przyjemnością zgłoszę jakiś serwer 

[Nightday96]

 

Mojang wprowadza EULĘ - świetnie! Tylko za wcześnie.

Za wcześnie? Powinna być od samego początku. ;p

 

Ona była od samego początku, ale nikt się z nią nie liczył...

 

 

Mi się ten pomysł bardzo podoba, koniec z vipami i mikropłatnościami na serwerach mc 

Z przyjemnością zgłoszę jakiś serwer 

Może w końcu zapanuje jakaś sprawiedliwość :-)

[GotoFinal]

Updatując. Mojang wprowadza EULĘ - świetnie! Tylko za wcześnie. Problemy z utrzymaniem wszystkich serwerów, tych ogarniętych też, będą. Porządny dedyk nie jest taki tani. Czekam, aż Mojang wypuści Alphe Win 10 na C++. Wreszcie skończą się dni pie***** Javy, która zżera niesamowite ilości zasobów. Kiedy to się stanie, 500-600 graczy na MC Win 10 pomieści się na serwerze na którym pomieściłoby się 50 MC Javy.

Ja się tak przyczepie...

Wydajność minecrafta nie jest wynikiem javy, a mojangu, ich kod to po prostu porażka.

A ramu minecraft nie zjada dużo, java zjada więcej na zapas, dzięki czemu potrafi szybciej przygotować pamięć - alokacja nowych obiektów jest znacznie szybsza niż w czystym C.

No i beznadziejny kod minecrafta strasznie męczy jave niepotrzebnymi alokacjami, co tylko sprawia że java bierze więcej zapasowego ramu i czasami laguje czyszczac to co mojang narozrabiał.

 

Wydajnościowo dobrze napisany kod javy nie jest dużo wolniejszy od kodu w cpp, potrafi nawet po kilku wykonaniach stać się szybszym.

(za wyjątkiem kodów jak konwertery vid/img czy kompresje itd.)

 

 

A zlikwidowanie minecrafta w javie zabiło by go.

Tyle modów, pluginów, wszystko by zniknęło. A żadne API w C nie da nam tylu możliwości co kod minecrafta w javie bez API.

 

 

A problemy wydajnościowe w MC... są 2 główne, i ich tak łatwo nie przeskoczysz niestety:

- Ładowanie chunków, mc ładuje chunki jednocześnie zatrzymując resztę serwera, podobnie z zapisem chyba. (nie jestem pewien)

Spigot np pozbywa się częsciowo tego problemu, zapis jest w osobnym wątku, a większość ładowania chunka jest też w osobnym wątku.

Jednak dalej zostaje problem po stronie serwera, by nadażyć z ładowaniem chunków, a trudno to zrobić wielowątkowo - dysk przeszkadza - dysk nie umie wielowątkowo pracować :P

Oczywiście dobry kod ma szansę to ulepszyć, ale jedno jest pewne - nie za darmo. Ram pewnie na tym ucierpi

Można np mapować pliki (niektóre, lub wszystkie) świata bezpośrednio na RAM, np admin serwera określa że chce poświęcić 1GB pamięci na mapę, i wtedy 1 GB pamięci przeznaczamy tylko na pliki mapy, z takich plików w ramie możemy czytać jak chcemy,

jest tylko 1 problem: masa pamięci będzie się marnować, np przerwy w pamięci między plikami - a są wymagane by to dobrze działało. Więc może się okazać że ten 1 GB będzie jak np 800MB.

Ale za to jakie plusy... można zapisywać i odczytywać świat z prędkością działania ramu, jak serwer skraszuje to nic nie tracisz - system sam zadba o to by zapisać te fragmentu pamięci znowu do plików.

Ale wykonanie czegoś takiego wymaga sporo pracy.

 

 

- tickowanie wszystkich światów i entity w 1 wątku, całe mc leci w 1 wątku, tym większa aktywna część mapy tym gorzej, procek musi w ciągu 50ms obliczyć ruchy dla kilku tysięcy mobów, wykonać aktualizacje niektórych bloków, np piecyków. Układy redstona.... po prostu wszystko

Poprawienie tego też nie jest proste, ale tutaj już mi się nie chce tłumaczyć wszystkich praw jakim to się rządzi, od razu przejdę to możliwości:

Po 1 można tickować światy osobno, wtedy problematycznym momentem będzie jedynie przechodzenie między światami, to już by był spory postęp, zamiast sektorów na bungee, można by robić sektory na światach.

Po 2 można dzielić mapę na... no właśnie na sektory, tak jak opisane wyżej, tylko lepiej, bo wbudowanie, tutaj problematyczne byłby granice sektorów, bo tutaj nie można sobie pozwolić na blokowanie budowy itd.

IMHO najlepiej by było dzielić to zgodnie z plikami zapisu, tak by 2 osobne sektory nigdy nie współdzieliły jakiegoś pliku.

+ takie dzielenie powinno być dynamiczne, bo 100 wątków ma większej mapie to też beznadziejny pomysł. Czyli w zależności od obciążenia fragmentów mapy łączą się i dzielą na sektory.

 

 

Wszystko to chcemy osiągnąć w diorite, ale nie wiem czy się uda, daleka droga a czasu mało ;/

 

Ok, z nudów się rozpisałem, wracam robić co miałem.

A ty nie marudz o javie o której działaniu nic nie wiesz, tak samo jak o cpp

[Nightday96]

 

Updatując. Mojang wprowadza EULĘ - świetnie! Tylko za wcześnie. Problemy z utrzymaniem wszystkich serwerów, tych ogarniętych też, będą. Porządny dedyk nie jest taki tani. Czekam, aż Mojang wypuści Alphe Win 10 na C++. Wreszcie skończą się dni pie***** Javy, która zżera niesamowite ilości zasobów. Kiedy to się stanie, 500-600 graczy na MC Win 10 pomieści się na serwerze na którym pomieściłoby się 50 MC Javy.

Ja się tak przyczepie...

Wydajność minecrafta nie jest wynikiem javy, a mojangu, ich kod to po prostu porażka.

A ramu minecraft nie zjada dużo, java zjada więcej na zapas, dzięki czemu potrafi szybciej przygotować pamięć - alokacja nowych obiektów jest znacznie szybsza niż w czystym C.

No i beznadziejny kod minecrafta strasznie męczy jave niepotrzebnymi alokacjami, co tylko sprawia że java bierze więcej zapasowego ramu i czasami laguje czyszczac to co mojang narozrabiał.

 

Wydajnościowo dobrze napisany kod javy nie jest dużo wolniejszy od kodu w cpp, potrafi nawet po kilku wykonaniach stać się szybszym.

(za wyjątkiem kodów jak konwertery vid/img czy kompresje itd.)

 

 

A zlikwidowanie minecrafta w javie zabiło by go.

Tyle modów, pluginów, wszystko by zniknęło. A żadne API w C nie da nam tylu możliwości co kod minecrafta w javie bez API.

 

 

A problemy wydajnościowe w MC... są 2 główne, i ich tak łatwo nie przeskoczysz niestety:

- Ładowanie chunków, mc ładuje chunki jednocześnie zatrzymując resztę serwera, podobnie z zapisem chyba. (nie jestem pewien)

Spigot np pozbywa się częsciowo tego problemu, zapis jest w osobnym wątku, a większość ładowania chunka jest też w osobnym wątku.

Jednak dalej zostaje problem po stronie serwera, by nadażyć z ładowaniem chunków, a trudno to zrobić wielowątkowo - dysk przeszkadza - dysk nie umie wielowątkowo pracować :P

Oczywiście dobry kod ma szansę to ulepszyć, ale jedno jest pewne - nie za darmo. Ram pewnie na tym ucierpi

Można np mapować pliki (niektóre, lub wszystkie) świata bezpośrednio na RAM, np admin serwera określa że chce poświęcić 1GB pamięci na mapę, i wtedy 1 GB pamięci przeznaczamy tylko na pliki mapy, z takich plików w ramie możemy czytać jak chcemy,

jest tylko 1 problem: masa pamięci będzie się marnować, np przerwy w pamięci między plikami - a są wymagane by to dobrze działało. Więc może się okazać że ten 1 GB będzie jak np 800MB.

Ale za to jakie plusy... można zapisywać i odczytywać świat z prędkością działania ramu, jak serwer skraszuje to nic nie tracisz - system sam zadba o to by zapisać te fragmentu pamięci znowu do plików.

Ale wykonanie czegoś takiego wymaga sporo pracy.

 

 

- tickowanie wszystkich światów i entity w 1 wątku, całe mc leci w 1 wątku, tym większa aktywna część mapy tym gorzej, procek musi w ciągu 50ms obliczyć ruchy dla kilku tysięcy mobów, wykonać aktualizacje niektórych bloków, np piecyków. Układy redstona.... po prostu wszystko

Poprawienie tego też nie jest proste, ale tutaj już mi się nie chce tłumaczyć wszystkich praw jakim to się rządzi, od razu przejdę to możliwości:

Po 1 można tickować światy osobno, wtedy problematycznym momentem będzie jedynie przechodzenie między światami, to już by był spory postęp, zamiast sektorów na bungee, można by robić sektory na światach.

Po 2 można dzielić mapę na... no właśnie na sektory, tak jak opisane wyżej, tylko lepiej, bo wbudowanie, tutaj problematyczne byłby granice sektorów, bo tutaj nie można sobie pozwolić na blokowanie budowy itd.

IMHO najlepiej by było dzielić to zgodnie z plikami zapisu, tak by 2 osobne sektory nigdy nie współdzieliły jakiegoś pliku.

+ takie dzielenie powinno być dynamiczne, bo 100 wątków ma większej mapie to też beznadziejny pomysł. Czyli w zależności od obciążenia fragmentów mapy łączą się i dzielą na sektory.

 

 

Wszystko to chcemy osiągnąć w diorite, ale nie wiem czy się uda, daleka droga a czasu mało ;/

 

Ok, z nudów się rozpisałem, wracam robić co miałem.

A ty nie marudz o javie o której działaniu nic nie wiesz, tak samo jak o cpp

 

U mnie np minecraft ramu to nie zjada dużo, gorzej z CPU...

[GotoFinal]

 

 

Updatując. Mojang wprowadza EULĘ - świetnie! Tylko za wcześnie. Problemy z utrzymaniem wszystkich serwerów, tych ogarniętych też, będą. Porządny dedyk nie jest taki tani. Czekam, aż Mojang wypuści Alphe Win 10 na C++. Wreszcie skończą się dni pie***** Javy, która zżera niesamowite ilości zasobów. Kiedy to się stanie, 500-600 graczy na MC Win 10 pomieści się na serwerze na którym pomieściłoby się 50 MC Javy.

Ja się tak przyczepie...

Wydajność minecrafta nie jest wynikiem javy, a mojangu, ich kod to po prostu porażka.

A ramu minecraft nie zjada dużo, java zjada więcej na zapas, dzięki czemu potrafi szybciej przygotować pamięć - alokacja nowych obiektów jest znacznie szybsza niż w czystym C.

No i beznadziejny kod minecrafta strasznie męczy jave niepotrzebnymi alokacjami, co tylko sprawia że java bierze więcej zapasowego ramu i czasami laguje czyszczac to co mojang narozrabiał.

 

Wydajnościowo dobrze napisany kod javy nie jest dużo wolniejszy od kodu w cpp, potrafi nawet po kilku wykonaniach stać się szybszym.

(za wyjątkiem kodów jak konwertery vid/img czy kompresje itd.)

 

 

A zlikwidowanie minecrafta w javie zabiło by go.

Tyle modów, pluginów, wszystko by zniknęło. A żadne API w C nie da nam tylu możliwości co kod minecrafta w javie bez API.

 

 

A problemy wydajnościowe w MC... są 2 główne, i ich tak łatwo nie przeskoczysz niestety:

- Ładowanie chunków, mc ładuje chunki jednocześnie zatrzymując resztę serwera, podobnie z zapisem chyba. (nie jestem pewien)

Spigot np pozbywa się częsciowo tego problemu, zapis jest w osobnym wątku, a większość ładowania chunka jest też w osobnym wątku.

Jednak dalej zostaje problem po stronie serwera, by nadażyć z ładowaniem chunków, a trudno to zrobić wielowątkowo - dysk przeszkadza - dysk nie umie wielowątkowo pracować :P

Oczywiście dobry kod ma szansę to ulepszyć, ale jedno jest pewne - nie za darmo. Ram pewnie na tym ucierpi

Można np mapować pliki (niektóre, lub wszystkie) świata bezpośrednio na RAM, np admin serwera określa że chce poświęcić 1GB pamięci na mapę, i wtedy 1 GB pamięci przeznaczamy tylko na pliki mapy, z takich plików w ramie możemy czytać jak chcemy,

jest tylko 1 problem: masa pamięci będzie się marnować, np przerwy w pamięci między plikami - a są wymagane by to dobrze działało. Więc może się okazać że ten 1 GB będzie jak np 800MB.

Ale za to jakie plusy... można zapisywać i odczytywać świat z prędkością działania ramu, jak serwer skraszuje to nic nie tracisz - system sam zadba o to by zapisać te fragmentu pamięci znowu do plików.

Ale wykonanie czegoś takiego wymaga sporo pracy.

 

 

- tickowanie wszystkich światów i entity w 1 wątku, całe mc leci w 1 wątku, tym większa aktywna część mapy tym gorzej, procek musi w ciągu 50ms obliczyć ruchy dla kilku tysięcy mobów, wykonać aktualizacje niektórych bloków, np piecyków. Układy redstona.... po prostu wszystko

Poprawienie tego też nie jest proste, ale tutaj już mi się nie chce tłumaczyć wszystkich praw jakim to się rządzi, od razu przejdę to możliwości:

Po 1 można tickować światy osobno, wtedy problematycznym momentem będzie jedynie przechodzenie między światami, to już by był spory postęp, zamiast sektorów na bungee, można by robić sektory na światach.

Po 2 można dzielić mapę na... no właśnie na sektory, tak jak opisane wyżej, tylko lepiej, bo wbudowanie, tutaj problematyczne byłby granice sektorów, bo tutaj nie można sobie pozwolić na blokowanie budowy itd.

IMHO najlepiej by było dzielić to zgodnie z plikami zapisu, tak by 2 osobne sektory nigdy nie współdzieliły jakiegoś pliku.

+ takie dzielenie powinno być dynamiczne, bo 100 wątków ma większej mapie to też beznadziejny pomysł. Czyli w zależności od obciążenia fragmentów mapy łączą się i dzielą na sektory.

 

 

Wszystko to chcemy osiągnąć w diorite, ale nie wiem czy się uda, daleka droga a czasu mało ;/

 

Ok, z nudów się rozpisałem, wracam robić co miałem.

A ty nie marudz o javie o której działaniu nic nie wiesz, tak samo jak o cpp

 

U mnie np minecraft ramu to nie zjada dużo, gorzej z CPU...

 

Wina kodu mc :P Niestety.

Java to nie ma prawie nic do rzeczy, tylko GC może mulić, polecam zmienić na G1GC i miec jave 8.

-Xmx1G -XX:-UseAdaptiveSizePolicy -XX:+UseG1GC -Xmn128M

i to już może pomóc.

 

Tyko ostrzegam że jak z G1GC dacie javie np 10GB ramu, to się nie zdziwcie jak po kilku godzinach będzie 6GB/10GB - daliście 10GB to używa 10GB :P

Ja na 1GB chyba mam tylko problemy jak dam widoczność 32x32 i latam szybko po mapie.

[Memust]

@GotoFinal bez cytatu, za duze to jest

 

Na początku zgodzę się - nie mam zbyt dużego pojęcia o tym, jak działa Java czy C++, na pewno nie jestem mądrzejszy od Ciebie w tych sprawach. Myślę jednak, że trochę źle mnie zrozumiałeś. Według mnie, przyczyną tak dużego zapotrzebowania na zasoby systemowe Minecrafta nie jest tylko zastosowanie Javy, chociaż także. Wiadomo, Mojang nie starał się zoptymalizować kodu najlepiej jak umiał, bo nie miał na to czasu. Jednak musi być jakaś przyczyna, dla której Mojang zdecydował się napisać MC od nowa w C++, a nie w Javie. Kod jest cholernie messy i bardzo dobrze, że go poprawiają. Problem jest jednak także z Javą. Można znaleźć wiele language benchmarków porównujących języki. Są także takie dla gier. W nich wszystkich C++ wychodzi na prowadzenie, czasami bardzo mocno. Dlatego uważam, że cep jest lepszy od Javy, ale mogę się mylić.

 

@topic

 

Bardzo dobrze, że banują wszystkie cholerne Pay2Winy, ale problem też uderzy w zwykłe serwery, które stoją na granicy. Prawie na pewno serwery będą zarabiać mniej z usług kosmetycznych niż z usług które dają przewagę graczowi. Uderzy to też w hostingi, które pewnie zaczną zamykać interesy lub zwiększać ceny, ze względu na mniejszą ilość serwerów, ale może także być odwrotnie, w co wątpię.