Do odpalania wielu sesji romka bez clienta. Dobra już ogarnąlem.
Osiągnięcie bardziej stabilnej gry za pomocą modyfikacji skrótu.
-
- General
- Destoy
- Closed
Rekrutacja do zespołu RoM PL została otwarta! Więcej informacji: Rekrutacja do zespołu RoM.
-
-
Witajcie!
Przeczyściłam ten temat, ale bardzo proszę o zachowanie spokoju, docenienie pracy innego użytkownika forum, a także kulturalną rozmowę. W przeciwnym razie będą podejmowane różne działania moderacyjne :>
Miłej dyskusji
-
Wydaję mi się Panie GM że rozmowa jest nad wyraz kulturalna. Destoy całkiem możliwe że to działa nie wiem ale fajnie że jest ktoś kto się podejmuje czegokolwiek względem tej gry(na gf nie można liczyć) . Ale wydaje mi się że jeśli coś takiego byłoby dostępne wszyscy byśmy mieli tego rodzaju "modyfikację" clienta. Bardzo wiele osób grało w roma i niektórzy z nich posiadali większą władzę i wiedzę o grze niż gm-i czy Celes. Jeśli coś takiego by zdawało egzamin podzielili by się z kolegami z gildii a Ci podali dalej. Ale możliwe że odkryłeś tajemnicę, powodzenia w pracy i szukaniu. Z tego co wiem kiedyś był dostepny cały kod roma ale chyba skasowali
-
Głownym problemem Rom jest to że gra jest w wersji 32 bity a dodatkowo moze obsłuzyc max 2gb RAM (pozostałe 2 Gb do których ma dostep aplikacja 32 bity zarezerwowane jest dla systemu), pewnym rozwiazaniem jest modyfikacja plików .exe by obsługiwały 4gb RAM, ( np program 4gb Path ntcore) ale dopóki Wydawca nie zdecyduje sie na wydanie 64 bitowej wersji crashe zawsze beda , bo gra przy szybkiej zmianie stref/duzej ilosci tekstur/detali poprostu sie zapycha
-
Na innych licencjonowanych serverach (nie GF) grupa zarządzająca poprawiła stabilność i wydajność romka w dość znaczący sposób. Jednak da się.
4gb Path ntcore - przerabiałem pare lat temu, ale nie zauważyłem niestety zbyt duzej różnicy.
-
Dość znaczący sposób to mało powiedziane.
Można śmiało powiedzieć że zlikwidowali 90% powodów crashy.
Dodatkowo zwiększono m.in. ilość RAMu jaką klient może używać.
Klient potrafi chodzić 2-3 dni bez disconnecta i bez crasha, wliczając rajdowanie i wojny.
Dodatkowo (można by przekazać jako sugestię do RW), kilka rzeczy redukujących możliwość wystąpienia problemów:
- możliwość wyłączenia widoczności petów innych graczy
- rozbudowane ukrywanie efektów (własne, mobów, innych graczy)
- ukrywanie efektów mikstur przemian
- zmiana zasięgu widoczności NPC
Chcieć = móc
-
Głownym problemem Rom jest to że gra jest w wersji 32 bity a dodatkowo moze obsłuzyc max 2gb RAM (pozostałe 2 Gb do których ma dostep aplikacja 32 bity zarezerwowane jest dla systemu), pewnym rozwiazaniem jest modyfikacja plików .exe by obsługiwały 4gb RAM, ( np program 4gb Path ntcore) ale dopóki Wydawca nie zdecyduje sie na wydanie 64 bitowej wersji crashe zawsze beda , bo gra przy szybkiej zmianie stref/duzej ilosci tekstur/detali poprostu sie zapycha
Ten patch nie sprawi, że plik .exe zacznie obsługiwać 4gb RAM.
On działa w dużym uproszczeniu tak, że ustawia flagę 0x20. Ogólnie kiedyś przy 32bit jeśli posiadałeś 4GB RAM, to 2GB było dzielone na grę, a 2 na sam system. Dlatego często gry miały narzucone taki limit z góry.
Taki NTCORE mówi systemowi, że jeśli to możliwe program potrzebuje więcej niż 2 GB RAMU, maksymalnie do 4 i nie zawsze to może działać i nie każdy plik wykonalny .exe zacznie "obsługiwać" te 4GB.
A samo kod wygląda mniej więcej tak:
Code- static bool IsLargeAware(string file)
- {
- using (var fs = File.OpenRead(file))
- {
- return IsLargeAware(fs);
- }
- }
- // Checks if the stream is a MZ header and if it is large address aware
- static bool IsLargeAware(Stream stream)
- {
- const int IMAGE_FILE_LARGE_ADDRESS_AWARE = 0x20;
- var br = new BinaryReader(stream);
- if (br.ReadInt16() != 0x5A4D) //No MZ Header
- return false;
- br.BaseStream.Position = 0x3C;
- var peloc = br.ReadInt32(); //Get the PE header location.
- br.BaseStream.Position = peloc;
- if (br.ReadInt32() != 0x4550) //No PE header
- return false;
- br.BaseStream.Position += 0x12;
- return (br.ReadInt16() & IMAGE_FILE_LARGE_ADDRESS_AWARE) == IMAGE_FILE_LARGE_ADDRESS_AWARE;
- }
Trzeba próbować, a nuż się uda, ale nie wszystko Ci pomoże i część to brednie są, tak jak kiedyś krążył mit o tym jak program czyszczący pamięć niby zmniejsza crashe do 0, ale taki program nie ma racji bytu i to tylko placebo, które nic nie robi, podobne gówno jest w google play na android, który Ci kasuje aplikacje w tle i pogarsza tylko sytuację xd
-
mam jeszcze 2 opcje do sprawdzenia ale zostawiam to wam:
+mat_queue_mode 2 - Forsuje wykorzystywanie wielowątkowości przez grę.
Oraz:
-heapsize 4194304 > dla RAM'u 8GB DDR3. CS:GO będzie używał 8GB, zamiast domyślnych 2GB.
-Heapsize 1048576 (Komputer z 2GB pamięci RAM)
-Heapsize 1572864 (Komputer z 3GB pamięci RAM)
-Heapsize 2097152 (Komputer z 4GB pamięci RAM)
-Heapsize 3145728 (Komputer z 6GB pamięci RAM)
-Heapsize 4194304 (Komputer z 8GB pamięci RAM)
-Heapsize 6291456 (Komputer z 12GB pamięci RAM)
-Heapsize 8388608 (Komputer z 16GB pamięci RAM)
-Heapsize 12582912 (Komputer z 24GB pamięci RAM)
-Heapsize 16777216 (Komputer z 32GB pamięci RAM)
Oba parametry pochodzą z z cs:go. Jakby ktoś chciał się przyczynić innym to efekty swoich testów proszę zamieszczać tu. Powodzenia -
@PanDoria
ROM zbiera bardzo dużo śmieci i ich potem nie czyści, WinAPI pozwala na manipulację WorkingSet, i to faktycznie odrobinę pomaga.
Są memcleanery które mogą to robić, ale dla siebie napisalem kilka linijek w C#, i różnica jest widoczna.
Mimo wszystko, do stabilnej rozgrywki droga daleka.
Code- static void cleanup()
- {
- var romProcess = Process.GetProcesses().Where(pr => pr.ProcessName.ToUpper() == "CLIENT" );
- foreach (Process pro in romProcess)
- {
- long used = pro.WorkingSet64 / 1024 / 1024;
- if (used > 1000)
- {
- GC.Collect();
- GC.WaitForPendingFinalizers();
- if (Environment.OSVersion.Platform == PlatformID.Win32NT)
- SetProcessWorkingSetSize(pro.Handle, -1, -1);
- }
- }
- }
Metody:
https://docs.microsoft.com/en-…t?view=netframework-4.7.2
-
Udało mi się uruchomić pozostałe 2 wątki dla RoM-a. Normalnie używa tylko dwóch.
Udało mi cię to dzięki parametrowi +mat_queue_mode -2
Teraz u mnie wpis wygląda następująco:
"C:\Runes Of Magic\Runes of Magic.exe" +vt_maxPPF 8 +mat_queue_mode -2
Efektem jest parę fps więcej w krytycznych sytuacjach. Efekt można zaobserwować w Monitorze zasobów (perfmon.exe). Menedżer zadań>Wydajność i u dołu jest Otwórz monitor zasobów. Bez tego parametru można zobaczyć że RoM wykożystuje 2 wątki a z parametrem wszystkie.
Zastanawia mnie że gra wykorzystuje tylko procent wydajności procesora oraz udało mi się zaobserwować że crash następuje kiedy gra osiągnie ową wydajność. Interesuje mnie to...
-
Patrzycie na to, złej strony. Problemem roma nie jest to, że obsługuje maks 2gb i jest 32bitowy. Problem jest to, że gra jest niestabilnym śmieciem.
Rom mógłby obsługiwać dowolną ilość pamięci i tak by się prędzej czy później wysypywał.
Grzebanie w ustawieniach buforów GPU i strumieniowaniu nie ma sensu w przypadku roma. Tekstur jest tyle co kot napłakał.
Odblokowywanie z poziomu systemu dostępności większej ilości rdzeni nic nie daje. Gra jest napisana bodajże pod dwa wątki i z większej ilości nie potrafi korzystać.
Na koniec dodam, że 32 bitowego programu nie da się od tak przerobić na 64bit Jedyną możliwością jest przekompilowanie całości na wersję 64bit.
-
Zgodzę się z tobą ale to co robię działa
-
Camist
Closed the thread.