Konrad-GM

Jeżeli przechowujesz dane typu karty kredytowe, to fakt, może jakaś dodatkowa warstwa by się przydała. Niemniej jak ktoś Ci już wejdzie na serwer i będzie mógł przeglądać pliki i bazę danych - to Twoje "dodatkowe" zabezpieczenie i tak nie będzie działać, po prostu nie trzymaj kart kredytowych na serwerze, bo jeden wyciek może Cię kosztować sporo Spróbuj może szyfrowanie AES, MySQL nawet ma funkcję wbudowaną AES_ENCRYPT. W C# masz też systemową klasę System.Security.Cryptography.Aes (powinno działać też na Mono). Btw. Jeżeli zależy Ci na szyfrowaniu połączenia Serwer -> Klient, to w zupełności wystarczy Ci SSL (bo próbujesz szyfrować dodatkowo dane w PHP, których i tak nikt nie zobaczy), nikt nie podejrzy takich danych, serio, nie ma czegoś "lepszego".

A nie możesz wysłać w POST/GET parametru? np. secret_key i sprawdzić w PHP, czy się zgadza i dopiero wysyłać dane? Jeżeli secret_key jest niepoprawny to nie wysyłaj nic i tyle.

Ale SSL właśnie to robi, co chcesz osiągnąć. Szyfruje w jedną jak i drugą stronę i tylko te dwa endpointy potrafią zaszyfrować/rozszyfrować wiadomość. Jeżeli używasz protokołu HTTP (GET oraz POST) to ja nie rozumiem, po co Ci jeszcze jakieś inne szyfrowanie... Jeżeli Mono to pewnie pozostaje Ci użycie jakiejś biblioteki 3rd party. Ale jaka jest "najlepsza" to nie mogę powiedzieć, bo w Mono nie pracuję (HttpClient powinien być też dostępny w Mono) Dodatkowo napisałeś, że chcesz programem w PHP wysłać coś do C#, tylko, że C# nie odbierze CI informacji, jak nie jest serwerem (nie odbierze POST). Jeżeli zakładasz serwer w C#, to też możesz skorzystać z połączenia po SSLu, działa na tej samej zasadzie.

SSL, jest nawet .NET-owa funkcja pod C# https://docs.microsoft.com/en-us/dotnet/api/system.net.security.sslstream?view=netframework-4.8, a jakiś konkretny protokół Cię interesuje? Bo jeżeli PHP to podejrzewam, że chodzi o HTTPS, .NET-owy HttpClient też obsługuje SSL-a out of the box.

1. Użyj "dziedziczenia" (ustaw parent w GMie), w sensie dodaj obiekt obj_enemy i obiektom m. in. obj_zombi ustaw parent = obj_enemy (zrób to dla wszystkich wrogich jednostkach), wtedy wystarczy Ci tylko jedna funkcja od sprawdzania najbliższej instancji obj_enemy: if distance_to_object(obj_enemy)<250 { var potwor = instance_nearest(x,y,obj_enemy) var pocisk = instance_create(x,y,obj_pocisk) pocisk.direction = point_direction(x,y,potwor.x,potwor.y) } obj_pocisk Create Event: speed = 10 2. Sprawa się komplikuje, musisz pobrać wszystkie obiekty obj_enemy o dystansie < 250 i sprawdzać, od najbliższego, czy przypadkiem nie ma kolizji między obj_zolnierz a obj_sciana np. funkcją collision_line. (może ktoś ma lepszy pomysł nawet, ja nie bardzo )

Daj zwykłą białą teksturę

1. Źle używasz trygonometrii do obracania wektorów, potrzebne są 2 funkcje trygonometryczne, cos i sin, coś takiego: // x' = x * cos α - y * sin α // y' = x * sin α + y * cos α var angle = degtorad(ruchdrzwi); var rx = cos(angle); var ry = sin(angle); d3d_draw_wall( x - 4 * rx, y - 4 * ry, 25, x + 4 * rx, y + 4 * ry, 10, sprite_get_texture(spr_drzwi,1), 1, 1 ) 2. Użyj macierzy, macierze są super // Wersja powyższego rozwiązania, ale przedstawione jako macierz: // [cos α -sin α] // [sin α cos α] var angle = degtorad(ruchdzwi); d3d_transform_set_rotation_z(angle); d3d_transform_add_translation(x, y); d3d_draw_wall(-4, 0, 25, 4, 0, 10, sprite_get_texture(spr_drzwi, 1), 1, 1) d3d_transform_set_identity();

Albo szybciej, ~2x szybciej, wystarczy przerzucić się na monitor 120hz/144hz/240hz i gra może okazać się niegrywalna. Ale to oczywiście dotyczy jak update będzie zsynchronizowany do odświeżania ekranu, jeżeli będzie cap na FPS 60fps, to wtedy posiadanie monitora o wyższym odświeżaniu nie ma kompletnie tutaj znaczenia, ale też odpada płynniejsza animacja i zysk z posiadania "szybszego" monitora jest żaden.

Używasz funkcji sprite_get_number, która zwraca Ci liczbę klatek danego sprite, ale z kodu na rysowanie widzę, że używasz oddzielnych sprite a nie klatek jednego sprite. To Ci nie ma prawa zadziałać bo zwyczajnie wywołanie `sprite_get_number(spr_ilustracja4)` zwraca Ci prawdopodobnie wartość '1'. Może użyj funkcji array_length_1d zamiast sprawdzania klatek sprite'a. (pamiętaj, że funkcja dla tablicy z jednym elementem tablica[0]=100 zwróci Ci wartość '1', a indeksujesz tablice od '0') W draw może daj też warunkowe sprawdzanie, czy klatkę możesz wyświetlić if (index == 0) { // draw ilustracja1 }

Tak, GMS 1.4 radzi sobie z wektorową grafiką, ale z tego co wiem wspiera jedynie format SWF: https://help.yoyogames.com/hc/en-us/articles/216755938--GMS-S-Vector-Sprites GameMaker nie rastruje wektorów do bitmapy jako tekstura, tylko posługuje się poligonami, więc skalowanie takich sprite'ów nie powinno dawać efektu pikseli.

Może array_unique?

No do pisania pluginów w wordpressie w zupełności wystarczy, powodzenia.

Nic złego nie jest w filter_var, ale w sposobie w jaki budujesz zapytania. "SELECT * FROM table WHERE x = $y" nawet jak używasz filter_var, to łatwo błąd popełnić. Dlatego też wymyślono coś takiego jak parametryzacja w mysqli->prepare, czy PDO->prepare, a Twój argument "może okazać się że znajdzie ktoś nowy backdoor" jest po prostu głupi, bo równie dobrze błąd może dotyczyć mysqli, czy nawet serwera apache/nginx... Dużo łatwiej złapać się na SQL Injection Twoją metodą niż używając parametryzacji i PDO. A tak w ogóle to nie uchronisz się w 100% przed błędami, aktualizuj serwer i tyle. PS. ten błąd PDO dotyczył biblioteki mysql akurat, bo wewnętrznie używa funkcji "mysql_real_escape_string"...

Przecież Ci wyżej podesłałem link jak ten błąd wygląda z PDO. Backdoor to nie tylko nieumiejętne korzystanie z PDO. To chociaż użyj parametryzacji z mysqli: https://www.php.net/manual/en/mysqli.prepare.php

W tym wypadku zapewne nie, ale jak będziesz nawet przypadkiem wrzucał tam $_POST czy $_GET, to zwykłe niedopatrzenie może spowodować sporo problemów. A ten błąd zapewne o którym słyszałeś, to o niewłaściwym kodowaniu bazy danych, tutaj masz rozwiązanie: https://stackoverflow.com/a/12202218

Żeby się nauczyć, ot. Nabywasz teraz złej praktyki po prostu (i do tego zwyczajnie niebezpiecznej ) .

Niepoprawnie odnosisz się do klucza w tablicy, nie powinno tam być tych pojedynczych cudzysłowów ', poprawnie to powinno wyglądać tak: $inputs = [ "lvalue" => 5, "rvalue" => 10 ]; $solutions = [0, 15, 30]; $string = "$inputs[lvalue] + $inputs[rvalue] = $solutions[1]" Dodatkowo nie buduj tak zapytań :facepalm: chociaż użyj prostej funkcji jak mysql_real_escape_string Najlepiej będzie jak przerzucisz się na PDO i będziesz robił parametryzowane zapytania. np. https://www.php.net/manual/en/pdo.prepare.php

Dart? Ja osobiście już wolę TypeScript bo znam JS a TS to świetne dopełnienie i nie widzę sensu uczenia się kolejnego skryptowego języka, zwłaszcza, że Dart nie jest jakoś szczególnie "lepszy" (chodzi mi o przeglądarki ofc. gdzie z miejsca w Dart odpadają inne JSowe biblioteki). A tak poza tym, to Fluttera też nie znam. Pisałem kiedyś appki w Cordova i Ionicu, do prostych appek są ok, ale do bardziej rozbudowanych szczerze odradzam, powolne to to, a ogólnodostępne biblioteki (zwłaszcza w Cordova) są tragicznie napisane i w dodatku JS potrafi czasami być nieprzewidywalny, zwłaszcza przy próbie wspierania pierdyliard wersji androidowych webview-ów czy iosowych javascriptcore-ów, bo klijent chce żeby działało nawet na afrykańskim kapciu. Zapewne Dart + Flutter sprawdziłby się na tym polu dużo lepiej. (albo nawet NativeScript? kiedyś muszę spróbować, wygląda obiecująco dla JS/TSowców, albo się w końcu nauczę czegoś pożytecznego, jak Java)

Sprawdzenie w google to minuta, dosłownie https://dotnet.microsoft.com/apps/xamarin Tak, Xamarin to framework do pisania appek w C#, obsługuje Androida jak i iOSa.

To jest zapis w JSONie, w PHP wygląda on tak (jako tablice asocjacyjne): <?php $array = [ "foo", 123456, ["bar" => 123, "baz" => [1, 2, true, true, false]], [1, 2, ["value" => 3], null] ];

json_encode/decode nie powinien mieć w takim razie problemu, jako przykład może to wyglądać równie dobrze tak: [ "foo", 123456, { "bar": 123, "baz": [1, 2, true, true, false] }, [1, 2, { "value": 3 }, null] ]

Nie ma najlepszego wyboru, są różne frameworki, a każdy z frameworków inaczej działa i służy do czegoś innego. Jakby nie patrzeć, to Android i iOS też mają swoje "frameworki" ale nie są multiplatformowe. Wybierz taki framework, w którym najbardziej będzie Ci odpowiadał stack technologiczny, który znasz/lubisz i spełnia wymagania co do Twojego projektu. Może to być PhoneGap/Cordova + Ionic, NativeScript, Xamarin są tymi popularniejszymi. Pamiętaj, że jak wybierzesz stack PhoneGap/Cordova/Ionic/NativeScript, to żeby zrobić coś bardziej rozbudowanego, to musisz i tak znać budowę obu platform, a nawet pisać pod nie rozszerzenia w Java i Objective-C. PS. To, że wybierzesz stack PhoneGap/Cordova/Ionic/NativeScript nie znaczy wcale, że będzie łatwiej. Jak znasz JS, czy TS byle jak, to efekt będzie taki sam jakbyś miał usiąść do Xamarina czy pisał od razu na Androida w Javie czy iOSa w Objective-C. Edit: NativeScript działa trochę inaczej, on binduje API Androida i iOSa do JavaScriptu, ale i tak żeby napisać rozszerzenie, trzeba je pisać też pod daną platformę, tyle, że w JS/TSie.

Nie, brakuje przecinka. Musisz utrzymać poprawną semantykę JSONa bo Ci się wykrzaczy, rzuci wyjątkiem i tyle.

Użyj GROUP BY i grupuj pole `data_id_sender` https://dev.mysql.com/doc/refman/8.0/en/group-by-modifiers.html

Poradników jest masa, ale nie dotyczą one samego GMa, bo takich pewnie nawet nie ma. Wystarczy, że w GMie możesz wysyłać HTTP requesty i możesz zaimplementować obsługę jakiejś bramki płatności. A jakiej, to już zależy od Twoich preferencji. PS. Ja osobiście w GMie nie implementowałem bramek płatności, ale o ile wiem jest to możliwe.