Skocz do zawartości

pablo1517

Użytkownicy
  • Postów

    2 138
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    1

Treść opublikowana przez pablo1517

  1. Jeśli nadal Cie to interesuje (w co wątpie xD) to mam na wykończeniu parser XML do GM'a i pewnie w ciągu tygodnia skończe.
  2. To jest wlasnie zmiana ceny. Kiedys w tej cenie miescil sie zestaw X+Y+Z, teraz juz tylko X+Y, bo cena sie zmienila.
  3. 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.
  4. pablo1517

    Top Hat

    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
  5. Prawda jest taka ze trzeba sobie kupic Mac'a i robić na iOSy, IPad i IPhone bo tam ludzie kupują (no chyba ze super crap)
  6. 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.
  7. Czyi myślicie, że są klepacze? A google np. też potrafi udostepniac repertuar kin jak sie wpisze w przeglądarkę. Kurde musi być jakiś sposób.
  8. Na taka tez potrafiłem wpaść, ale to jest wlasnie BARDZO oporowe.
  9. 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.
  10. 1. W helpie/dokumentacji GMa... 2. Odbieranie Tak. Wysyłanie skąd chcesz. 3. Jest do sciagniecia wsrod przykladow GMa.
  11. Ale jednak dużo profesjonalnych gier (np Torchlight 2) śmiga tylko w trybie p2p więc jakoś to muszą robić.
  12. 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.
  13. Dobra nie przeczytałem drugiego błędu. Przecież 2gi błąd mówi wyraźnie, że pliki .ini MUSZĄ być w tym samym folderze co plik .exe więc nie możesz sobie wybierać tego za pomocą funkcji get_open_filename. Po prostu wpisz tam nazwę pliku np GML ini_open("plik.ini")
  14. Zmień GML ini_open(working_directory+'/'+string(projekt001)) na GML ini_open(projekt001) i jak?
  15. 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.
  16. 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.
  17. 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.
  18. Eee aha czyli nie nadaje sie do robienia "masła" ale nadaje sie do robienia "masła". Logic. Jedno i to samo. 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.
  19. 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.
  20. Miałem z tego warunek :D ale zdałem. https://www.google.pl/#q=Systemy+wyszukiwania+informacji
  21. pablo1517

    PHP

    Ostatni post: 25.01.2013 Nie powiedziałbym...
  22. Faktycznie, mi tyle wystarczy, ale jeśli faktycznie coś znajdziesz to mozesz tu wrzucic bo chętnie zobaczę.
  23. Z tą kulą to nie, bo jeśli ja uderzę lecąc pod kątem powiedzmy 45 stopni w spód kuli to to nie będzie point direction od srodka kuli xP, aczkolwiek kule od kuli łatwo odbic w miarę sensownie bez zaawansownej fizyki. Skrypt sprawdze.
  24. Hahahah, czemu nie ma przycisku "Lubie To" do postów :D
  25. pablo1517

    PHP

    https://gmclan.org/index.php?plik=66 xD już trzeci raz to wklejam dziś
×
×
  • Dodaj nową pozycję...