39dll - host

[karolo320]

Siema.

 

Bawię się z 39dll od wczoraj i mam pewien problem.

Mam dwóch graczy, jeden stawia serwer, a drugi dołącza.

Jeśli host się poruszy to automatycznie zmienia swój status na klienta.

I to mój problem :D Nie wiem dlaczego tak się dzieje, nigdzie nie przestawiam

glabal.master, ale jakoś samo się przestawia.

 

Z góry dzięki.

 

Dołączam projekt

https://gmclan.org/up7221_12_cs.html

[Borek]

W Graczu2 w poruszaniu, masz kod: if place_free (x+2,y) global.master=false

Zapomniałeś dodać AND

[karolo320]

omfg, sprawdzalem 10 razy.

 

Wielkie dzieki :D

[Borek]

To nie koniec, w sprawdzaniu przesyłu danych zamień global.master z false na true i w drugim graczu tak samo, tylko na odwrót.

Dodatkowo masz źle wpisane if place_free(y+2,y) Pierwsza wartość to jest X a nie Y

[karolo320]

gdzie w sprawdzaniu przesyłu danych? ja tego nie ogarniam jeszcze :D

[kt1117]

Ja skorzystam z okazji i zadam swoje pytanie:

Jeśli mam grę opartą o 39dll, i testuję ją lokalnie, to jak zmienię IP na adres serwera to zadziała? Bo ja mam wewnętrzne i hostować nie mogę, ale kolega ma zewnętrzne,podał mi swoje IP, ja wpisałem i nie działa, dlaczego? Może gracz też musi mieć zewnętrzne?

[karolo320]

powinno działać, kolega może nie ma zewnętrznego?

[kt1117]

Podobno sprawdzał i mówi, że ma, pewnie ja coś spierdzieliłem.

[Borek]

Ja skorzystam z okazji i zadam swoje pytanie:

Jeśli mam grę opartą o 39dll, i testuję ją lokalnie, to jak zmienię IP na adres serwera to zadziała? Bo ja mam wewnętrzne i hostować nie mogę, ale kolega ma zewnętrzne,podał mi swoje IP, ja wpisałem i nie działa, dlaczego? Może gracz też musi mieć zewnętrzne?

 

Gracz nie musi mieć zewnętrznego żeby się połączyć do serwera. Teoretycznie jeżeli kolega podał ci IP ( mając zewnętrzne ), to powinno działać bez problemu, jeżeli nie działa to albo ma firewalla ustawionego, albo nie ma przekierowanych portów na ruterze.

[kt1117]

Dzięki, wiele mi wyjaśniłeś, spróbuję teraz zobaczyć te porty i firewalla.

[karolo320]

A jak jest z tworzeniem obiektów w czasie gry? Obiekt2 (host) stworzy obiekt to co zrobić, żeby klient widział ten obiekt?

[kt1117]

Wysyłasz jednego bajta z jakimś tam numerem, a odbierając ten numer tworzysz obiekt.

Wysyłasz:

GML (Tworzenie obiektu)

writebyte(1)

Odbierasz:

GML

if readbyte()=1

instance_create(...)

Takie coś.

[karolo320]

Pytań ciąg dalszy...

W stepie pocisku (robię shootera multiplayer) mam

 

GML

clearbuffer();

writebyte(2);

writeshort(x);

writeshort(y);

writeshort(direction)

sendmessage(global.otherplayer)}

 

a w odbiorze:

 

GML

if messageid=2

{

pocisk.x = readshort()

pocisk.y = readshort()

pocisk.direction=readshort()

}

 

I zauważyłem (albo to net mi nawala, ale aż tak bardzo to raczej mało możliwe. Jeśli tak to sorry za pytanie :D) że

gdy jest np 10 pocisków to na drugim kompie wyświetla tylko jeden (losowy) co klatkę. Czyli w jedną klatkę widać ten, potem ten itd.

[Borek]

Przede wszystkim nie robi się przesyłania danych pocisków co stepa, no chyba że są to zdalnie sterowane rakiety :D

Taki myk zapcha łącze w ciągu sekundy.

 

Ty potrzebujesz jedynie przy stworzeniu pocisku wysłać raz informacje:

 

Rodzaj pocisku, X, Y, Kierunek, Szybkość i to wszystko, a u klienta po prostu tworzysz pocisk o takich parametrach jakie wysłał serwer.

Robisz kolizje pocisku u klienta i na serwerze i musi działać :)

 

GML

// Serwer:

// W CREATE pocisku:

clearbuffer();

writebyte(2);

writebyte(1); // Rodzaj pocisku np. z karabinu, shotguna itp.

writeshort(x); // Pozycja wystrzelenia pocisku

writeshort(y);

writeshort(direction); // Kierunek w którym ma polecieć pocisk

writebyte(speed); // Szybkość wystrzelonego pocisku

sendmessage(global.otherplayer);

 

// Klient

 

if ( messageid == 2 )

{

a = instance_create(x,y,pocisk)

 

a.rodzaj_pocisku = readbyte();

a.x = readshort();

a.y = readshort();

a.direction = readshort();

a.speed = readbyte();

}

 

Oczywiście to jest przykład napisany pod Twój system, bo ja to bym to jeszcze inaczej zrobił, ale póki się uczysz to wystarczy takie coś :)

[karolo320]

Dzięki.

[pablo1517]

A z ciekawości, Borku jak byś to jeszcze inaczej zrobił :D?

[karolo320]

a jeszcze mam takie pytanie: Jak z serwera wysyłam np 3 wiadomości co kratkę (jak wcisne W to wysyłam położenie, jak strzelam to też i jeszcze coś) To przed każdym wysłaniem trzeba czyścić buffer? I jeszcze: Co to jest ten buffer? On przechowuje te wysłane wiadomości?

[Borek]

A z ciekawości, Borku jak byś to jeszcze inaczej zrobił :D?

 

Ja bym nie robił wysyłania danych w evencie CREATE pocisku :) Bo to zabiera milisekundy różnicy wystrzelenia. Po drugie nie jestem zwolennikiem pakowania kodu do każdego obiektu, bo później szukam po obiektach.

Serwer jak dostanie info o wystrzale, to już powinien tworzyć pocisk u siebie oraz w tym samym momencie przesyłać do innych dane o jego pozycji itp. a nie robić warunek CREATE w pocisku i dopiero wtedy przesłać dane.

 

a jeszcze mam takie pytanie: Jak z serwera wysyłam np 3 wiadomości co kratkę (jak wcisne W to wysyłam położenie, jak strzelam to też i jeszcze coś) To przed każdym wysłaniem trzeba czyścić buffer? I jeszcze: Co to jest ten buffer? On przechowuje te wysłane wiadomości?

 

Tak, trzeba czyścić buffer.

[gnysek]

Bufor (PWN)

 

Bufor to jest taki stos w którym dane czekają zanim je wyślesz. Coś jak np. zwiedzanie muzeum w grupie po 15 osób - najpierw się buforuje grupa, a potem przewodnik ją zabiera i buforuje się następna.

[pablo1517]

Borek ale to jak, wysyłałbyś kilka stepów przed stworzeniem pocisku :D? Przecież nie wiadomo kiedy np. player naciśnie "fire".

[Cekol]

Ja to zawsze robiłem tak, że serwer do wszystkich klientów wysyłał swój "current_time" (co 2 klatki czy 4)

Potem gdy klient "wysyłał strzał" wysyłał też ten "current_time" otrzymany od serwera.

Serwer gdy odebrał dane o strzale obliczał laga porównując aktualny "current_time" do tego odebranego, po czym przyśpieszał pocisk tak, aby była synchronizacja zależna od laga ;p

[Dawidds]

Ja bym nie robił wysyłania danych w evencie CREATE pocisku Bo to zabiera milisekundy różnicy wystrzelenia. Po drugie nie jestem zwolennikiem pakowania kodu do każdego obiektu, bo później szukam po obiektach.

Serwer jak dostanie info o wystrzale, to już powinien tworzyć pocisk u siebie oraz w tym samym momencie przesyłać do innych dane o jego pozycji itp. a nie robić warunek CREATE w pocisku i dopiero wtedy przesłać dane.

Taka drobna nieistotna techniczna wskazówka - Create wykonuje się w momencie wywołania instance_create(), żadnego stepa ani żadnej milisekundy później. Wiem, że to dziwne, ale tak już jest i nic z tym nie możesz zrobić.

[Borek]

Borek ale to jak, wysyłałbyś kilka stepów przed stworzeniem pocisku :D? Przecież nie wiadomo kiedy np. player naciśnie "fire".

 

Ale i tak wszystko jest na karku serwera, to on decyduje o tym że pocisk ma być stworzony, gracz mu przesyła tylko informacje że chce wystrzelić.

Gracz wysyła chęć wystrzału -> Serwer sprawdza czy to możliwe, jeżeli tak, to tworzy obiekt i W TYM SAMYM momencie wysyła do innych że wystrzelono pocisk, a nie jakieś dodatkowe EVENTY w CREATE pocisku.

 

Taka drobna nieistotna techniczna wskazówka - Create wykonuje się w momencie wywołania instance_create(), żadnego stepa ani żadnej milisekundy później. Wiem, że to dziwne, ale tak już jest i nic z tym nie możesz zrobić.

 

Tak czy inaczej jak pisałem wcześniej, bez sensu jest wrzucać kod do create pocisku, jak można wszystko zrobić w jednym miejscu za pomocą a = instance_create(); a.speed = x; itd.

Każdy ma swoje metody :) Ja już chyba z 10 razy pisałem kod sieciowy na różny sposób i za każdym razem coraz bardziej go usprawniam. Po prostu robię tak, żeby było jak najbardziej wygodnie i przejrzyście, tym bardziej jak mamy mocno rozbudowany projekt.

[I am Lord]

Ja to zawsze robiłem tak, że serwer do wszystkich klientów wysyłał swój "current_time" (co 2 klatki czy 4)

Potem gdy klient "wysyłał strzał" wysyłał też ten "current_time" otrzymany od serwera.

Serwer gdy odebrał dane o strzale obliczał laga porównując aktualny "current_time" do tego odebranego, po czym przyśpieszał pocisk tak, aby była synchronizacja zależna od laga ;p

To coś czego brakuje Borkowi w Aliensach, delta timingu.

[pablo1517]

Ale i tak wszystko jest na karku serwera, to on decyduje o tym że pocisk ma być stworzony, gracz mu przesyła tylko informacje że chce wystrzelić.

Gracz wysyła chęć wystrzału -> Serwer sprawdza czy to możliwe, jeżeli tak, to tworzy obiekt i W TYM SAMYM momencie wysyła do innych że wystrzelono pocisk, a nie jakieś dodatkowe EVENTY w CREATE pocisku.

 

To być oczywista oczywistość :sp_ike:

[Borek]

To coś czego brakuje Borkowi w Aliensach, delta timingu.

 

Delta timing ssie w GM niestety... Miałem w Alienach zaimplementowany. Po pierwsze synchronizacja nawala, pomimo że wszystko jest dokładnie co do milisekundy, a po drugie przeszkadza niesamowicie w pisaniu, bo

do większości zmiennych trzeba dopisywać np. direction += 2 * Timer.delta

 

Chyba że ktoś posiada lepsze rozwiązanie :)

 

To być oczywista oczywistość :sp_ike:

 

No to co się dziwisz? :P

[Tymon]

Chyba że ktoś posiada lepsze rozwiązanie :)

Cóż. Teraz przynajmniej masz powód by się ze mną zobaczyć.

[gnysek]

Ale i tak wszystko jest na karku serwera, to on decyduje o tym że pocisk ma być stworzony, gracz mu przesyła tylko informacje że chce wystrzelić.

Gracz wysyła chęć wystrzału -> Serwer sprawdza czy to możliwe, jeżeli tak, to tworzy obiekt i W TYM SAMYM momencie wysyła do innych że wystrzelono pocisk, a nie jakieś dodatkowe EVENTY w CREATE pocisku.

 

Zakładając, że create jest wykonywane w momencie gdy obiekt się tworzy, to CREATE zostaje wykonane przed wysłaniem tych danych:

 

GML

instance_create(0,0,objCostam);

//teraz wykonuje sie create dla objCostam

writebyte(...)

 

Ale są to różnice rzędu mikrosekund

[I am Lord]

Delta timing ssie w GM niestety

 

Zdaje się że pysio pisał jakiegoś dllela, który usprawniał ten GMowy timer.

[pablo1517]

Gnysiu, u mnie to jest na odwrót :P. Fajnie, tośmy sobie porozmawiali i nic z tego nie wynikło xD