Skocz do zawartości

Konrad-GM

Użytkownicy
  • Zawartość

    2681
  • Rejestracja

  • Ostatnia wizyta

  • Wygrane w rankingu

    24

Ostatnia wygrana Konrad-GM w Rankingu w dniu 21 Grudzień 2019

Konrad-GM posiada najczęściej lubianą zawartość!

Reputacja

48 Duża Cegła Społeczności

O Konrad-GM

  • Tytuł
    Legendary Hobo
  • Urodziny 07/31/1992

Contact Methods

  • Website URL
    https://lethiandev.github.io/

Previous Fields

  • Steam
    samael_x92
  • Użytkownik GameMaker Studio 2
    Nie
  • Użytkownik GameMaker Studio
    Tak
  • Użytkownik GameMaker 8
    Nie
  • Użytkownik GameMaker 7 i wcześniejszych wersji
    Nie
  • Użytkownik Unity
    Nie
  • Uytkownik Godot
    Tak

Profile Fields

  • Płeć
    Mężczyzna

Ostatnie wizyty

23464 wyświetleń profilu
  1. Podejrzewam, że Ty nie jesteś programistą, a marketingowcem, z którymi @gnysek ma pewnie masę doświadczenia w pracy ;P Ale nie jesteś programistą, żeby zrozumieć na czym to polega, dlatego ciężko będzie przekazać Ci konkretną wiedzę techniczną (nie da się jej przekazać w jednym zdaniu, żeby napisać stronę ecommerce), skoro nie wiesz jakie to jest skomplikowane - chociażby taka obsługa bramek płatności, jeszcze gorzej, jak będzie trzeba obsłużyć ich kilka, kolejne abstrakcje, kolejne interfejsy które trzeba, niestety, zaprogramować. BTW. To jest prosta i konkretna odpowiedź z doświadczenia a nie z wywyższania się. Albo napisz swoją wtyczkę, w takim np. Presta masz masę gotowych interfejsów w systemie i możesz je obsługiwać jak CI się tylko podoba bez myślenia, jak zaimplementować kolejkowanie zamówień czy obsługę bramek płatności, w tym skonfigurować serwer SMTP i wygenerować oraz wysyłać maile (np. z fakturami) do klientów - a to chyba jest ważne w marketingu? Bo przeważnie nie jest to tak dobry pomysł jakby się wydawało, zwłaszcza, jak nie ma się doświadczenia z programowaniem. Starsi koledzy też pewnie tak myśleli, ja np. napisałem własny sklep dla własnych potrzeb (i kilka innych stron), masa zabawy z tym była... generalnie polecam napisać swój sklep, sporo się nauczysz i zrazisz do takich przekonań Ale tu jest już jakaś funkcja, przez którą będziesz umieszczał dane, dodajmy do tego formularz zgłoszeniowy, że ktoś chce kupić jakiś przedmiot, może nawet bramkę płatności XSS podałem dla przykładu, pierwsza strona Google pod hasłem "common ecommerce website vulnerabilities" - https://lirax.org/6-common-security-vulnerabilities-in-e-commerce-systems/ Jak dla mnie fajny CMS, kilka stron na nim postawiłem i działa naprawdę nieźle - w tym w łatwy sposób można dodawać podstrony bezpośrednio w HTMLu (z wbudowanym silnikiem template'ów). Generowałem w nim PDFy, wysyłałem customizowane maile, zarządzałem użytkownikami (poza adminami/redaktorami ofc.)... Ale nie stawiałem na nim sklepów, tutaj własną wtyczkę musiałbyś dopisać (co jest banalne w October CMS), albo skorzystać z wtyczek z marketu
  2. Nie jestem jasnowidzem i nie mogę powiedzieć co jest niezabezpieczone, sporo zależy jak napiszesz taki sklep. Możesz poczytać sobie o łatkach zabezpieczeń innych kombajnów jak np. Wordpressa żeby mieć ogólny zarys czym jest chociażby taki XSS i np. w jakich niespodziewanych miejscach można umieścić kod https://wordpress.org/news/category/security/ Może też dlatego @gnysek poleca użyć gotowca jak Presta, bo podejrzewam, że działa marketingowo a nie próbuje podbić rynek swoim autorskim super frejmworkiem Jak dla mnie pisz własny sklep, jeżeli to nie jest pisane dla klienta a tylko do celów własnych, to sporo się nauczysz i nabierzesz doświadczenia jak to działa od kuchni. PS. Presta też jest mocno podatna na zmiany i czcionki spokojnie mógłbyś zmienić Edit: Może rzuć okiem na OctoberCMS, dość ciekawe rozwiązanie, można w dość łatwy sposób pisać szablony bezpośrednio w HTMLu i doklejać kod PHP, mega prosty CMS i w dodatku podstawowa instalacja ma minimalnie wymagane pluginy.
  3. xD xDD Akurat większość problemów dot. zabezpieczenia to wbrew pozorom wcale nie SQL injection. Community i battle-testy. Czyli nie wiesz, co jest wymagane, stawiam na żadne bądź b. małe doświadczenie w programowaniu takich rozwiązań Nie twierdzę, że pisanie własnego sklepu to zło, sporo się można nauczyć, ale po tym co napisałeś stwierdzam, że nie masz doświadczenia z tematem (i dlaczego z góry zakładasz, że Twoje rozwiązanie będzie "lepsze"... jak nie będzie ).
  4. Skalowanie obrazu na mobilki

    O, a tego nie wiedziałem, czyli najlepiej jakby wspierać oba ratio 16:9 oraz 19,5:9
  5. Szukam grafik do gry

    Często grafik z doświadczeniem myśli zupełnie inaczej ;P Ale dlaczego miałby to robić? Że za darmo? Albo za "procent"? Sorry ale jeżeli już ktoś się zgodził na procent, to teraz staje się tym "doświadczonym" grafikiem co już więcej na procent niczego Ci nie zrobi Żeby zarobić te miliony to IMO trzeba mieć dużo szczęścia. Nawet gry AAA z dużym budżetem na reklamę mogą słabo się sprzedawać, faktor tym większy, im bardziej gra jest "indie" Popytaj się innych grafików w branży o wycenę, bo na cenę może wpływać sporo czynników i zapewne każdy wyceni Ci je inaczej. Może nawet uda Ci się podłapać studenta co dopiero zaczyna w branży, będzie taniej, ale większe ryzyko, że będą to mocne średniaki, chyba, że gość utalentowany ale nie zna cen rynkowych
  6. Skalowanie obrazu na mobilki

    Jeżeli będziesz trzymał się proporcji 16:9 to większość ekranów jest ok, czarne paski pojawiają się tylko na jakichś abominacjach Obsłużenie wszystkich możliwych rozdzielczości jest IMO bardzo trudne, osobiście też próbowałem rozwiązywać ten problem w swoich aplikacjach (nie tylko grach). dlatego nie widzę niczego złego w trzymaniu się ustalonych proporcji, to sporo ułatwia pracę (polecam 16:9, najbardziej popularne). Jeżeli z jakiejś przyczyny takie rozwiązanie Ci nie odpowiada, możesz zawsze rysować UI po współrzędnych ekranowych, np. od prawego dolnego rogu (jeżeli np. pasek życia masz na dole po prawej stronie) a nie standardowo od lewego górnego, pamiętaj też, że na mniejszych ekranach elementy mogą na siebie nachodzić. PS. W Godot jest nawet opcja rozciągania ekranu tak (tryb "2d"), żeby skalowało sprite'y do ustalonych proporcji np. 1280x720 (16:9), tzn. jeżeli miałbym ekran np. retina 3840×2160 to rozciągnie obrazki ale surface (render target) na którym będą rysowane ma oryginalny rozmiar 3840×2160 (chyba, że jest poza proporcją 16:9, to wtedy pojawiają się czarne paski), więc antyaliasing linii, i innych kształtów rysowanych dynamicznie działa poprawnie. A nawet jak sprite będą zeskalowane w dół, to po ich rozciągnięciu na większym ekranie nie będzie tragedii.
  7. Szyfrowanie PHP - > C# - > PHP

    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".
  8. Szyfrowanie PHP - > C# - > PHP

    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.
  9. Szyfrowanie PHP - > C# - > PHP

    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.
  10. Szyfrowanie PHP - > C# - > PHP

    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.
  11. instance_nearest

    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 )
  12. ilość wszystkich instancji w roomie

    Daj zwykłą białą teksturę
  13. Obracające się drzwi 3d

    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();
  14. Porady odnośnie delta time w projekcie.

    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.
  15. Intro obrazkowe+wyświetlający się pod obrazkiem tekst

    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 }
×