gnysek

2. Trzeba to zaprogramować Albo poszukać gotowego rozszerzenia

Jak piszą w dokumentacji do polecenia buffer_create - "pamiętaj aby usunąć z pamięci", więc tak, siedzi tam ciągle i nie ma garbage collectora. Garbage collector w GMie jest na instancje z niezaznaczonym persistent i tablice.

Może musisz ponownie aktywować licencję bo zgubiło.

Ja myślalem, że ten sklep już powstał, to miało być dwa dni pisania Ale ostatnie zdanie Threefa mówi wszystko w temacie na temat skomplikowania sprawy.

Ale przepraszam, myślisz, ze kto mi zleca zadania, programista? Pfff. Zadania zleca klient, który zaprogramować, to potrafi najwyżej pralkę. I ja wszystko robię tak, jak on chce i jak wg. jego wizji ma to wyglądać, a nie ja wg. mojej wizji. Jak wrzucam 30 różnych skryptów śledzących, obrazków, google tag managerów, facebook pikseli i chuj wie czego jeszcze, to nie dla tego, że programista uważa, że tak jest lepiej, tylko dla tego, ze przyszedł MARKETINGOWIEC i SPECJALISTA OD SPRZEDAŻY i on takie gówna każe wklejać. Także jest dokładnie na odwrót niż myślisz, bo programiści to są leniwe istoty i robią na skróty, a same formularze i proces sprzedaży upraszczaliby jak się da. Dla mnie wystarczą dwa statusy zamówienia - "oczekujące" i "zrealizowane", ale pan właściciel sklepu potrzebuje 50, a potem sam się w tym gubi. A to okienko tutaj, a to newsletter tam, a to bannerek w tym miejscu, a to pierdoła w tamtym. Każdy sklep ma naprawdę inne wymagania i robienie projektu już pod dwa wymaga, żeby pisać modułowo. I tak się to rozrasta potem. Zapytałeś co musisz wiedzieć przed robieniem sklepu, my, z doświadczeniem mówimy, że na takie coś nie ma się co porywać, bo to jest za duży projekt, i to nie dla tego, że piszemy sklepy na gotowcach, tylko dla tego, że w ogóle mamy doświadczenie w programowaniu (którego Ty w ogóle nie masz, skoro mylisz bezpieczeństwo sklepu z używaniem PDO), albo twierdzisz, że coś da się napisać w godzinę, skoro nawet zrobienie HTMLa i CSSa dla niektórych rzeczy zajmie dłużej, żeby coś się prawidłowo wyświetlało. Owszem, jak chcesz to próbuj, ja jednak nadal będę twierdził, że użycie gotowca jest szybsze, niż pisanie samemu. Ja bym się tego nie podjął, bo żeby zrobić coś uniwersalnego, dla więcej niż jednej osoby wiem, że musiałbym spędzić chyba z kilka lat, żeby to napisać. Jeśli jednak ktoś o sklepach mówi CMS, no to w sumie wszystko mówi na temat poziomu rozmowy i tego, ze nie rozumie faktów które przytaczamy. Żaden z systemów sklepowych, Magento, Presta, Sylius, WooCommerce, OpenCart, ZenCard czy X-Card nie jest CMSem. Część z nich posiada moduł CMS, część z nich działa pod CMSami, ale żaden nie jest. Jedyne z czym się zgodzę, to że prowadzenie sklepu niestety jest drogie i fajnie minimalizować koszty, ale właśnie skorzystanie z gotowca kosztuje w sumie 0zł. I naprawdę sporo da się wyklikać, bez programowania i jestem pewien, że jakbyś powiedział czego potrzebujesz, to większość tych funkcji jest bez wtyczek. Martwisz się też co w momencie, gdy sklep ma aktualizacje. No cóż, to patrzysz co zaktualizowali, jeśli trzeba to poprawiasz kod (chociaż jak poprawka dotyczy jedynie bezpieczeństwa, to jeśli musisz coś poprawić to sam miałeś błąd bezpieczeństwa) i tyle. Nie wrzucasz przecież poprawki na żywca na serwer na pałę. A co do argumentów, że znajomi mają mnóstwo malware itp. - no cóż, jak nie potrafią skonfigurować dobrze serwera, to mają. U mnie klienci nigdy nie mieli z tym problemu, bo zawsze chociażby zmieniamy ścieżkę do panelu admina, blokujemy ją pod konkretne IP, dodajemy htpassword czy nawet wymagamy konkretnego ciasteczka w przeglądarce najpierw. I to są akurat rzeczy do zrobienia w godzinę. Jestem też ciekaw tych faktur. Generujesz fakturę, wtedy wysyłasz ją księgowej i jak będzie zła to poprawisz? Coś chyba tutaj jest nie tak, przecież jak user już pobrał fakturę, to po ptakach. A jak ją sobie wpiszę w KPiR to co, potem mi się skarbówka przywali, bo nie umiałeś dobrze faktury wygenerować? Nie mniej, czekam na pierwsze efekty, na pewno podpowiemy co jest źle i ostrzeżemy przed jakimś fatalnym błędem, zanim pakujesz się w maliny. Pamiętaj tylko, że od początku ostrzegaliśmy, że na maliny w ogóle masz nie iść

10 lat piszę sklepy internetowe, zrobiłem ich ponad 50, piszę czasem sam bramki do nowych systemów, czy systemy dostaw, a ten mi mówi, ze to kilka linijek... to nie jest tak, ze ja je piszę pod jakiś system, dlatego zajmują mnóstwo kodu, to jest tak, że się nie da krócej, bo ja już znam system i wiem gdzie oszukać i czego nie muszę zrobić, byle to działało. Jak mówię - nie masz nawet pojęcia za co się bierzesz, albo w ogóle nie chcesz 90% funkcjonalności sklepu, które są przydatne MARKETINGOWO i dla SPRZEDAWCY a nie dla programisty. Sporo rzeczy przyspiesza prace, jak da się je zobaczyć w panelu admina (status zamówienia, numery paczek, status płatności) ale rozumiem, wolisz je sprawdzać osobno. I bez odpowiedniego flow dla klienta. Pytanie czy robisz prawdziwy sklep, czy tylko mikro-sklepik na dwóch klientów rocznie.

Czy jesteś w stanie zminimalizowac projekt (oczywiście na kopii) do 1-2 obiektów i podesłać go nam, zebysmy sprawdzili (i upewnić się, ze dalej się psuje)? Inaczej chyba na nic nie wpadnę. Czasem usuwając rzeczy okaże się, ze się magicznie naprawia i znajdziesz problem

Ale tylko w momencie tych czynności, czy np. 5 minut później też? Bo ja bym obstawiał, ze mruga, bo się przełączasz i że tak robią wszystkie gry. Co do mrugania między levelami które widziałem, to strzelam, że masz różne rozdzielczości w roomach, dlatego mruga. Sprawdź też, czy gdzieś kodem nie zmieniasz rozdzielczości/rozmiaru view/pozycji okna w step, może dla tego mruga. Ja generalnie nie kojarzę takich problemów w 1.x za czasów gdy pracowałem w YoYoGames.

Śmiałem się długo, no ale odpiszę xxxxD Nie wiesz nic o programowaniu w takim razie no ale kto te etapy programuje co? wiesz chociaż jaki jest standard branżowy w e-commerce? buahahahahahaahah tutaj to się już turlałem srogo po podłodze. To przepraszam kto implementuje obsługę bramek płatności? Jak myślisz, ze to działa? Przecież musisz wypuścić ze sklepu klienta do bramki z kwotą i numerem zamówienia, a potem sprawdzić, czy już opłacił. Ja Ci powiem - z doświadczenia, taki kod bramki (gdzie numer karty/przelew robimy po stronie bramki a w sklepie nie pobieramy żadnych danych) to jest kilkadziesiąt plików kodu po kilkaset linijek. I nikt tego nie napisał w tydzień. Paczkomaty czy DHLa też rozumiem w godzinkę rozpykasz, chociaż dużym firmom zajmuje to koło miesiąca. Tu znowu śmiechłem. Niedawno odkryliśmy w jednym z systemów, że można ręcznie zedytować ukryty input z ilością sztuk i wpisać 0,1, dzięki czemu kupisz wszystko za 10% ceny. To nie jest SQL injection. Powinno dać Ci do myślenia, dlaczego gotowe sklepy internetowe mają tak dużo plików i są tak wielkie, a nie na 2000 linijek. Serio. Jak chcesz sprzedawać 5 rzeczy, to nie baw się w Presty, tylko wordpresik + woocommerce. Zresztą nie wiem co aż tak bardzo chcesz zmieniać w gotowcach. Pewnie połowę rzeczy da się tam wyklikać tylko nie wiesz Próbuj, chętnie zobaczę za tydzień co masz Mogę nawet zrobić review i pokazać wszystkie dziury, bo pewnie bez problemu je znajdę, z zamkniętym jednym okiem. Powiedz, jakie to braki ma Presta? Mogę zaproponować Magento, ale to jest dopiero kombajn.

Najlepsze, że pory dnia to jest po prostu surface na którym maluję kolor, a potem ustawiam tryb na bm_subtract i rysuję ten surface na wierzchu wszystkiego. Więc żeby zrobić efekt światła, wystarczy namalować coś z białym gradientem na tym samym surface. Shaderami pewnie by to było bardziej optymalne, ale wtedy rysowanie "światła" nie byłoby już tak proste. Więc obecny sposób jest o wiele szybszy.

Co Ty za farmazony tutaj pitolisz? Chociaż zajrzałeś w dokumentację Presty? Możesz sobie nadpisać każdą klasę i każdy moduł, dodawać wtyczki, odpalać eventy (hooks). Robię sklepy internetowe od 10 lat w dużo większych systemach i nigdy nie było problemu z nadpisaniem czegoś - chociaż nie powiem, jest to pracochłonne, ale i tak na pewno mniej niż napisanie oryginalnego kodu. Jak nie masz kontroli nad kodem, jak presta jest otwartoźródłowa? Możesz z tym kodem zrobić wszystko. Zresztą, nawet wersje premium systemów sklepowych które znam pozwalają nadpisać wszystko, tylko nie można ich publicznie udostępniać (np. na githubie) w wersji premium. Pisanie własnego sklepu skoro masz takie zerowe pojęcie o innych systemach, to proszenie się o kłopoty. Tak naprawdę to nawet nie masz zapewne pojęcia jakie etapy zamówienia wyróżniamy, jak powinna wyglądać kolejność przetwarzania koszyka i masz zerowe pojęcie o metodach dostaw/płatności, a będziesz musiał napisać wtyczki do tego od zera, bo większość firm daje wtyczki właśnie do gotowych sklepów. Zresztą, otwierając sklep pamiętaj też o tym, czego wymaga od Ciebie prawo, już poza programowaniem. Zwłaszcza, jak zostawisz dziurę w swoim systemie.

Na razie grafiki robię sam, ale ostatecznie bez grafika na bank się nie obejdzie:

Nigdy nie korzystaliśmy z phpBB na GMCLANie, strona główna jest autorstwa Ranmy, 100% Ostatnio nawet przymierzałem się do modyfikacji kolorystycznej Boostrapa4, co by pasowała do frontu, no ale to daleka pieśń na razie

Nawet jakby była dokumentacja konkretnej wtyczki to i tak trzeba by pewnie zaktualizować, jak to zmiany w oprogramowaniu.

Najlepiej to chyba po prostu z dokumentacji https://devdocs.prestashop.com/1.7/modules/

No te programy są w sumie do siebie mocno niepodobne. Może i 90% składni się nie zmieniło, ale system layerów, inne IDE i zmiana działania paru rzeczy jeszcze w GMS 1.x, to jest większa różnica.

sleep zatrzymuje całą grę grę. Jeśli chcesz odczekać, musisz dać (np. w create) alarm, 3 sekundy to jest 3*game_speed; Zatem np. alarm[0] = 3 * 60; i wtedy w evencie Alarm0 robisz kod odpowiedzialnu za wybuch. Dodanie alarmu w step, będzie go ustawiało ciągle na początkową wartośc i nie będzie sie odliczać, wiec step/draw odradzam. Btw. sleep() nie jest dostępne w GMS 2.x, ani nawet w 1.x, używasz zatem niewspieranego od 8 lat 8.1 ?

A to jest dalej projekt poboczny i pracujesz jeszcze nad czymś innym ? Pamiętam jak przy którymś piwie w Wawie mówiłem "we rób to Bonfire, to dobra gra będzie", a Ty nie miałeś przekonania i uważałeś to raczej za taki test i trochę zabawę konwencją, że za mało osób by w to grało wiec się nie opłaca dalej robić, gdzieś tam nawet przewijała się wizja wskrzeszenia Magi 2 (chyba nawet Gracjana albo Kasia robiły testowo grafikę jednej z postaci jak kojarzę, tego potwora skalnego? to już tak dawno, że mogłem pomylić). Zresztą, pewnie gdybyś nawet wskrzeszał Magi 2 to pewnie by dziś dostało zupełnie nowy tytuł No i w sumie Bonfire jest takim trochę Magi, tylko czary są zamienione na bardziej przyziemne sposoby atakowania (chociaż część by pod czary podciągnął). Oby to był czarny koń Twoich produkcji i też okazał się niemałym hitem, mimo tego początkowego braku przekonania

Każdy w innym języku programowania i ustawić, zeby się eksportowały tylko na jedną platformę. Generalnie w -uj roboty.

Bo GM ma jeszcze tę opcję keep aspect ratio i wtedy i tak dociąga rozdzielczość - ale myślisz dobrze, 720p powinno styknąć. Zresztą jeśli masz telefon z 1080, to narysuj sobie grafikę w 720p i przerzuć jako plik PNG na telefon i zobacz, czy jakość jest satysfakcjonująca. Typowa galeria telefonu zrobi to samo co GM z interpolacją.

Pięknie to wygląda, sam robię teraz grę w podobnym stylu graficznym (chociaż mniej kanciatą i trochę niżej osadzona kamera - coś jak w pokemonach). Zdecydowanie jedna z najlepszych gier zaprezentowanych na GMCLANie (w TOP10 na pewno, może nawet w TOP5, ale przez te 18 lat może o czymś zapomniałem :P).

Świetnie wyglądają wszelakie interfejsy, świetny font, daje klimacik. Zaskakujące jest to, jak mało zmienił się ekran bitwy od czasów dema w które grałem 2014: 2020: Btw. byłem święcie przekonany, że ten pierwszy screen był co najwyżej z 2017-2018, a nie 2014, to już naprawdę tyle lat? Gdzie ten czas spierdzielił...

Nie bardzo rozumiem. Chcesz rysować grafiki 1,5 raza większe jeśli będzie 1080p niż 720p ?Ja raczej myślałem, że te same, tylko obszar ekranu większy. Tworzysz niepotrzebnie problemy

RAM obciąża liczba załadowanych danych, a więc spritów, kodu itp., a nie rozdzielczość. Ona obciąża procesor. Jak zrobisz w 720p i ekran będzie w 1080 to i tak samo przeskaluje, także to już twój wybór

Zapisywanie w katalogu roboczym (domyślnie po prostu bez podawania ścieżki) działa na bodaj wszystkich platformach. Co do chmury - to działa chyba tylko na androidzie. https://help.yoyogames.com/hc/en-us/articles/360003087452-Android-Google-Cloud-Saving. Co do iOS - nie wiem, może wystarczy jakieś API.