Skocz do zawartości

pablo1517

Użytkownicy
  • Postów

    2 138
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    1

Odpowiedzi opublikowane przez pablo1517

  1. Nie mówimy tu o zmianie ceny tylko o tym co wchodziło w skład wersji Pro 2 lata temu, a co jest teraz.

    A teraz w GM:S Pro nie ma eksportu na Mac OS.

     

    To jest wlasnie zmiana ceny. Kiedys w tej cenie miescil sie zestaw X+Y+Z, teraz juz tylko X+Y, bo cena sie zmienila.

     

    oferta chyba sie zmienila tylko dla tych ktorzy jeszcze nie kupili.
  2. Panowie i Panie !

    Kiedy 2 lata temu rozpoczęła się sprzedaż GameMaker Studio, Yoyogames oferowało wersję Pro z następującymi

    eksportami :

    - Windows

    - Mac OS

    - Mobile - (możliwość testowania).

     

    395_Feature_comparison.png

     

    Więc dlaczego teraz posiadacze GM:S Pro mają dopłacać za eksport na Mac OS 99,99$ ??

    Dla minie to wygląda na oszustwo lub na próbę wyłudzenia - jak kto woli.

     

    CO WY NA TO ???

     

    https://yoyogames.com/news/117

     

    Zmiana ceny po 2 latach to oszustwo?

     

    NO NIE! Ja pamiętam jak chleb kosztował 80gr a teraz średnio po 3 zł! Dla mnie to wygląda na oszustwo lub próbę wyłudzenia - jak kto woli.

  3. Tobie bliżej do lewaka jak już żebrzesz, że chcesz za darmo bo zuy Nikas kapitalista śmie żądać zapłaty za swoją pracę xD.

     

    Ja osobiście raczej poczekam aż sie Nikas zarobi i w przyszłości postanowi rzucić jakąś przecene z okazji świąt czy cos to wtedy sobie kupie :P

  4. Da sie z tego utrzymac ale nie bedziesz robil swoich wymarzonych gier. Prawda jest taka, ze jesli np celujesz w androida, to pierwsze piec gier wypuszczasz za darmo. Zalozenie jest takie, ze robisz hurtowo malutkie gry i wypychasz na shopa, po pewnym czasie wyrabiasz sobie jakies "imie" tam i powoli w miare jak robisz oczywiscie cos lepszego zaczynaja sie pojawiac tacy co za te gry gotowi byliby zaplacic jakiegos grosza. Takze nie jest to łatwa droga.

  5. Siemka, mam takie pytanie z innej beki troche. Ogólnie to koleżanka mnie zapytała, czy byłbym w stanie zrobić appke na androida, która by wyswietlała jakieś tam przepisy do gotowania, a na drugiej zakładce repertuar kina/kin na bieżący dzień. O ile tam przepisy wyświetlać z bazy to jest pikuś, o tyle zastanawia mnie, w jaki sposób są zrobione appki na google shopie, takie jak wlasnie appka WP.PL z repertuarem kin.

     

    Czy oni tam mają kogoś zatrudnionego, kto im ręcznie aktualizuje bazy danych z repertuarem na najblizsze 3 dni? Czy może jest jakiś automatyczny sposób, o którym nie wiem?

     

    Pozdrawiam,

    Pablo.

  6. Możliwe, że da sie jeszcze wybierać pliki .ini o ile bedą w tym samym folderze co .exe. Lub po prostu zmień format pliku.

    Podejrzewam, że to dziwne zabezpieczenie można by obejść na około otwierając plik .ini z dowolnego miejsca jako zwykły plik tekstowy, kopiując zawartość, tworząc z niej tymczasowy plik ini w folderze z grą i otwierając te tymczasówkę, ale moim zdaniem szkoda zachodu.

  7. Mineło 3 latka i temat do mnie wrócił jak strzała. Chcę zaimplementować multiplayer na zasadzie kombinacji p2p ale w taki sposób, że jest tylko 1 host przez ktorego wędrują dane do reszty graczy. Tyle, że ten 1 host to będzie jeden z graczy. Dawniej kiedy nikomu z nas na jakości aż tak bardzo nie zależało, po prostu olewało się problem publicznego IP i mówiło się otwarcie "Ściągnijcie sobie hamachi". Dziś to nie przejdzie :D.

     

    Aby każdy mógł sobie zahostować grę (bez potrzeby posiadania publicznego IP) należy przeprowadzić zarówno UDP jak i TCP hole punching lub jak kto woli NAT punch-through.

    Moje pytanie brzmi, czy obecny Networking w GM:S jest w stanie to zrobić. Nie wiem czy ktoś próbował się bawić, tym networkingiem, ja próbowałem i jest problem. Problem polega na tym, że GM nie daje nam kontroli co do tego na jakim porcie otwieramy swoje sockety. Tzn. daje nam możliwość kontrolowania tej sprawy w przypadku socketów nasłuchujących, ale nie w przypadku portów wysyłających (tak, to śmiesznie zrobione, ale w GM:S żeby móc funkcjonować na protokole UDP należy otworzyć 2 oddzielne sockety, 1 jako server-socket i 1 jako socket do wysyłania, nawet na kliencie gry).

     

    Cały koncept obczytałem tutaj: http://www.brynosaurus.com/pub/net/p2pnat/

    Jednak są momenty gdzie brak znajomości "technicznego angielskiego" trochę dokucza.

     

    Pomińmy taką bzdurę jak omijanie routera, ponieważ dzisiaj naprawdę port forwarding to już nie jest czarna magia i tutaj można konsumenta zmusić do tego, żeby odblokował sobie porty na domowym routerze. Problem się pojawia gdy to ISP odgrywa rolę NATu, wtedy trzeba przebić dziurę.

    Mam takie jeszcze pytanie małe do kogoś kto sie orientuje w tym dokładnie jak działają NATy. Jeśli mamy podobną architekturę jak ta którą wyjaśnił Gnynsek, czyli mamy komputery A i B, gdzie każdy jest zasłonięty przez swój NAT, niech będzie to NATa i NATb. Czy NATy same rozkminiają odpowiedni routing w przypadku hole punchingu?

     

    PRZYKŁAD:

    Komputer A wysyła pakiet z protu 6000 do serwera S. Ponieważ po drodze NATa mógł zmienic port na np. 6500 bo taki ma wolny to serwer S zapamietuje ze wiadomosc przyszła z publicznego adresu IP NATa + port 6500. To są publiczne dane, które później S wyśle dla komputera B. Ta sama sytuacja tylko w drugą stronę zrobi sie gdy komp B wyśle pakiet do serwera S. Ostatecznie chodzi mi o to, że komputer B wyśle wiadomość nie na port 6000 bo ten został zakryty przez NATa. Komp B wyśle pakiet na IP NATa : 6500 (czyli na publiczne dane). Teraz czy NATa zrozumie, że jest to odpowiedź, która jest adresowana do A i sam przekieruje wiadomosc odpowiednio?

     

    Ogólnie ponieważ UDP w GM:S wymaga otwarcia 2 socketów (do wysyłania i do odbierania) i nie ma możliwości kontroli na jakim porcie otwiera się ten wysyłający socket, to wydaje mi się, iż zrobienie H-P jest po prostu nie możliwe, ponieważ NAT będzie przekierowywał odpowiedź na port, z którego wiadomość wyszła na początku, a ponieważ to nie będzie ten sam port, na którym otworzyliśmy socket nasłuchujący to wiadomość pójdzie sie walić. :/

     

    Czy komuś udało się w pełni zaimplementować taki hole punching? Bonus points jeśli na GMie.

  8. Co do buffera to moim zdaniem nie ma sensu robić nowego za każdym razem jak wysyłasz wiadomość. Ja sobie zrobiłem 1 buffer w CREATE mojego obiektu odpowiedzialnego za synchronizację i tym bufferem sie posługuje przez cały okres wymiany danych, niszczę go wraz ze zniszczeniem obiektu.

    Dla jasności, to nie jest tak, że wysyłasz buffer po sieci. Buffery to jedynie sposób trzymania danych binarnych w GM:Studio, dlatego przy wysyłaniu piszesz buffer_tell(buff) - co oznacza miejsce, do którego są zapisane dane w bufferze. Funkcja wysyłająca zczytuje dane do tego miejsca w bufferze i wysyła już tylko informacje tam zapisane, a nie zaś sam buffer.

  9. Troche necro, ale myślę, że warto dopowiedzieć, że mimo wszystko te callbacki wykonają się w takiej kolejności w jakiej przyszły. Tzn. że nie musisz się martwić o to, że np. połączy sie na raz 5 osób i dostaną to samo ID bo to raczej nie możliwe, chyba, że im whardcodujesz to samo id xD. Po prostu async event wywoła się 5 raz jeden po drugim, ale to nie znaczy, że w różnych stepach. Myślę, że jest do tego oddzielny wątek zarezerwowany.

  10. przy okazji mozna dopowiedzieć że wbudowany networking nie nadaje się do gier online, a jedynie do trybów multiplayer.

     

    Eee aha czyli nie nadaje sie do robienia "masła" ale nadaje sie do robienia "masła". Logic. Jedno i to samo.

     

    dlatego jak ktoś chce robić gierke online to lepiej od razu dllki uzyć.

     

    Znów bzdura. Dllki, wszystkie, które są dostępne aktualnie na sieci dla GM'a są pisane albo tylko dla windowsa albo tylko dla desktopów, czyli nie są cross-platform. Wbudowany NOWY networking jest cross-platformowy - będzie więc działać tak samo na desktopach, androidach itp. Jest to co najmniej imponujące.

    Fakt, że GMowej appki nie opłaca się odpalać na serwerach dedykowanych nie zostanie rozwiązany przez DLL'e bo przecież to wciąż będzie GAME MAKER ODPALAJĄCY DLL'a ;>. Tryb graficzny nadal zostanie. Jedyne co należy napisać sobie POZA game makerem to tzw. serwer globalny, który będzie tylko zbierał informacje o istniejących grach/serwerach i podsyłał listę serwerów dla graczy szukających gier.

     

    Właśnie piszę sobie prosty multiplayer z obsługą UDP. Nowy networking jest o niebo lepszy od starego dziadostwa, który oferował GM.

  11. On chyba chce porównywać całe "paczki" takich stringów, do tego potrzebne jest przeciążenie operatorów, ale GM tego nie oferuje.

    Można zrobić sobie script który by wyglądał przy wyowałniu tak

    Porownaj(value1, value2) np.

     

    Nvm. Tak jak mówił konrad wczytaj sobie wszystkie linijki do jakiejś struktury danych ds_*, a potem pętlą porównujesz to z kluczem.

×
×
  • Dodaj nową pozycję...