Hozzászólások
Elsődleges fülek
+1000, a "driver crashel ATI alatt brühühü" hisztin a Radeon 9800-am óta csak röhögtem, de a meghajtó köré telepített - és egy ideje már kötelezővé tett - szarok megőrítettek.
Egy hónapja vettem, hirtelen felindulásból:
Nagyon meg vagyok elégedve vele, Assassin's Creed Origins nagyon jól néz ki HDR-ben.
A GShock egy intézmény nagyjából :)
Brutál strapabírók, rengeteg remek fícsörrel.
Aztán van egy ilyenem is:
https://casio.timecenter.hu/casio+orak/g-shock+karorak/GMW-B5000GD-1.ora
Ez pl. pont nem olyan, amit beaterként hordok, de a másikat ütöm-vágom, semmi baja.
Jó a sztori, de tudja, még mi mentette volna meg az életét? Ha nem megy oda :D
Az elég nagy csoda lenne xDDD
A 2060 se lesz meg, az tuti.
Elkezdtem a képregényt és elég mások a karakterek, pl Huighe nem anyámasszony katonája, Butcher jóval kimértebb, Frenchie és Kimiko jó spanok azt kész.
Jóval parasztabb is; még az a kevés, de idegesítő hollywood-i sablon sincs benne.
Bár nekem ez így kicsit overkillnek tűnik.
Hat most pl beszelunk egy csomot reszletesen errol a bugrol (tobbek kozott mert szeretem reszletesen ismertetni a gondolataimat, hatha akadnak zsir otletek masoktol is amire nem gondoltam), de tobbi fejlesztesnel is rakatot irtam, ami elso latasra overkillnek tunhet. Amugy az ilyen jellegu munkadelegalas hasonlo esetekben normalis szokott lenni manapsag szvsz, mintsem mindent egy process-be irni es remelni hogy nem szakad bele. Belegondolva manapsag szinte ott probaljak delegalni a felmerulo melofolyamatokat, ahol csak tudjak. En probaltam vegsosoron realisan effektivre fogni a kerdest, azaz hogy csak ott delegalok ahogy kenyszerulok csomo ok miatt igy eljarni, feleslegesen nem nehezitem magamnak az eletet.
Majd elfelejtettem, de testing konnyuseg szempontjabol is eg es fold kulonbseg kis mikroszervizeket tesztelgetni es javitgani, mintsem egy hatalmas monolitikus, egybefuto kodszeletet. Es fejlesztes szempontjabol is.
Meg némileg ki is veszi a kontrolt a user kezéből
Az felett eleve nincs a felhasznalonak kontrollja (regebben se most sem) hogy sikeres e a kommentkuldes/beagyazas vagy sikertelen. Egyedul az felett van kontrolja hogy meg e nyomja a kommentkuldes gombot, vagy leirja e azt amit.
Ha (tegyuk fel) par percig dekkolni akar az elkuldott kommentje felett, es figyelni szeretne hogy sikerul e a teljes beagyazas, ugyanugy most is megteheti. Es ha ugy alakul sikertelen, editalhatja ennek fejeben nyugodtan a hozzaszolasat. Csak nem kenyszerul ujabban varni ha nem akar, de megteheti.
Ha pl. még processzálódik egy beágyazás, de a user szerkeszti a postot (törli a beágyazandót), az megszakítja a folyamatot? Részletkérdés, de ilyesmi halmazati felelősségeket vízionálok.
A "beagyazas" mint komplett folyamat 2 nagy, egymastol kialakitasban teljesen eltero reszbol all:
1) A kommentkuldesnel az RW szerver elkezd a kulso weboldallal egyezkedni a kello informaciokert APIkon keresztul, vagy sajat kotyvasztasu algoritmussal. Majd ha megkapta a kello adatokat a lepesek folyaman, akkor elmenti azokat az szepen rendszerezve adatbazisba, egy URL-bol generalt ID nev mogott.
2) Ha valamilyen a felhasznalo betolt egy topikot es/vagy kommentet, es abban a beagyazott URL-bol generalt ID megegyezik az adatbazisban eltarolttal, akkor grafikusan formazza es megjeleniti azokat, "beagyazas formaban" ugye.
A szerkesztes igy egyaltalan nem befolyasolja a beagyazas server oldali kimenetet. De abszolut befolyasolja a kimutatott anyag verziojat. Ha pl szerkesztesz es ugy dontesz megis kiveszed a beagyazott anyagot, akkor az sohasem fog latszani. Sarkitva kicsit, de ugy is felfoghatod igy az 1. pontot mint egyfajta cache-ing, a beagyazas kimutatasnak.
De ha valaki mas is be akarja agyazni es mar megvannak a hatter szamitasok, neki sokkal gyorsabban meg fog tortenni, mert nem kell a szeronak 2x ugyanazt elvegeznie.
Inb4: "de mi van akkor ha kitalalja valaki az ID-t es ugy akaratunk ellenere meglatja az elkezdett, majd meggondolt es mutatni nem szandekozott tartalmat, az RW backendrol kezzel lekerve?"
Good luck hasadra(billentyure)csapni es kitalalni egy SHA256 hashelt hosszusagu es custom Base64-ben encode-olt IDt, hogy azzal pont elcsiped az anyagot. :D Egyeduli mukodo modszer hogy birtokaban vagy mar eleve az eredeti linknek. De hogy lekerd az adatokat azzal kapcsolatban az RW backendrol meg hashelni es encode-olnod sem kell az URL-t hozza. Ugy is mukodik a backend, ha direkt linket adsz meg neki, majd o hasheli es encodolja helyetted mielott keresne az adatbazisban. Irtam is az RWMedia backend modul topikjaban reszletesen a mukodesrol. :)
(A load balance-ot általánosabban értettem a késleltetéssel kapcsolatban, amikor a szerver különböző időbeli rendelkezésreállását tekintjük különböző "resource"-nak.)
oh, okes akkor.
De most már értem, miért szükséges aszinkron, köszi a felvilágosítást!
szivesen! Mindig orommel beszelek a technikai megvalositasokrol is, egeszen reszletesen is akar. Orulok hogy erdekel valakit az RW technikai geek oldala is. :)
Aha, értem. Bár nekem ez így kicsit overkillnek tűnik. Meg némileg ki is veszi a kontrolt a user kezéből. Én lehet, hagytam volna úgy, hogy megpróbálja beágyazni, ha nem sikerül, szól a usernek, hogy nem nyert, próbálkozzon újra, ha akar.
Nyilván ez megközelítés kérdése, de szerintem túl sok terhet veszel a válladra (a szerver vállára). Ha pl. még processzálódik egy beágyazás, de a user szerkeszti a postot (törli a beágyazandót), az megszakítja a folyamatot? Részletkérdés, de ilyesmi halmazati felelősségeket vízionálok.
(A load balance-ot általánosabban értettem a késleltetéssel kapcsolatban, amikor a szerver különböző időbeli rendelkezésreállását tekintjük különböző "resource"-nak.)
De most már értem, miért szükséges aszinkron, köszi a felvilágosítást!
The Boys első két évad ledarálva
Sokan említettétek itt a sorozatot, úgyhogy utána néztem és kedvet kaptam hozzá.
Alapvetően nagyon tetszett mind a két évad, az elejétől a végéig pöpec, egyedül
Nekem meg nem, de ettől még elhiszem. Viszont az összes "W10 frissítés elcseszte a gépem!" témából 10-ből kilencszer integrált intelt VGA driver a ludas, amiről természetesen a szemét MicroSoft tehet.
Off: AMD "driver hibák" nagy részét a CC okozza, nem a driver, meg az azzal feltelepülő sok "hasznos" szemét, mint a videórögzítő és társai. Van aki ezért a Fire kártyák CC-jét teszik fel. Viszont én ilyen csontra fagyás videórögzítő miatt, vagy elcsesződő HW videólejátszásba NVidia driverben is belefutottam már. Bár ott is sokan a Studio drivert teszik fel a gamer helyett, gondolom nem ok nélkűl.
Szerintem sokkal jobb lennem ha a Steam lenne PS-re is... :D
Mi indokolja, hogy ennyire ragaszkodunk az aszinkron működéshez?
1) Az hogy kulso szerverekkel kommunikalunk. Itt kozrejatszhat hogy bazi lassu szerverre lepunk, vagy abban az idoben epp leterhelt, bazi lassura, ami hosszu ideig is foghatja a kommunikaciot kommentkuldes utan, feleslegesen.
2) Adott esetben joval hosszabb ideig is futhat egy egy munkafolyamat, mint a maximalis megegedett PHP script futasi ido, pl videoattoltesnel amig minden elintez, lehet tobb percig is. Egy hogy a crashel a folyamat ha tullep az idon es sikertelen lesz a kommentkuldes a beagyazassal egyutt (alapbol az egesz muvelet igy sikertelen lesz), masik hogy percekig fogjuk a kommunikaciot kommentkuldesre nyomas utan, amig el nem keszul az anyag.
3) Memoria igeny. Egy-egy bazi komplex es hosszan felepitett PHP script brutal sok memoriat tud enni, es siman lehet "out of memory error"-t dob adott esetben. Regi RW1.0 kodban amikor probaltam komplexebb vizsgalatokat es muveleteket vegezni, akkor az akkori max megengedett 512mb se volt eleg mert kivagta a biztositekot, es akkor 1 folyamatrol beszelunk csak, amit 1 felhasznalo 1 kommentkuldessel produkal. :) Az RW2.0 koddal igy apro, egymastol teljesen kulonallo folyamatokra bonthattuk a melolepeseket, amelyeknek kulon mind is elegendoen kicsi memoriaigenye van, raadasul amint befejeztek az adott melot, vissza is adjak az elozoleg lefoglalt memoriat, majd a kovetkezo folyamatnak vagy a rendszernek a frissbol lehet valogatnia.
4) Es igen, UX szempontbol a kommentkuldes, mint adott funkcionalitas szempontjabol nem fontosak a felhasznalonak ezek az server-to-server munkakommunikaciok. A felhasznalo egyszeruen a kommentet akarja elkuldeni ha Send-re lep es nem erdekli mi tortenik a hatterben hogy ez megvalosuljon. Nem celja varni a hattermunkak befejezesere, hanem forumozna mihamarabb tovabb. Mindennemu varakozast eleve csak kenyszerbol tesz, mert jobb hijan nincs mas valasztasa ugye.
De ha a késleltetés a lényeg
Ez is, pl a 2. pontnal kiemelten fontos. Es az ebbol addodo kommunikacio feldarabolasa, tobb reszre torese, hogy biztosan ne fussunk ki a maximalis script futasi idobol sem.
Sot most jut eszembe hogy pl ha adott esetben egy nem reszponziv szerora lepunk a beagyazasnal, akkor ahelyett hogy azonnal feladna a probalkozast a rendszer, alszik es var 10-20 masodpercet, majd megprobalja ismet parszor, remelve hogy csak ideiglenes terheles miatt sikertelen a kommunikacio, mivelott vegleg feladna es elkonyvelne elerhetetlennek.
és a szerver load balance
Ez a szempont mondjuk annyira nem fontos (marmint ha proci eroforras elosztas szemponjabol erted), mivel minden lokalis szerver reszre torteno kommunikacio ugyanazon a szerveren van, azaz ugyanazt terheli. Szerintem ez akkor jonne kepbe, ha tobb egymastol fuggetlen szeron dolgoznank. Pl ha kulonbozo mikroservice-ek kulon szerokon is lennenek.
én úgyis inkább megvárnám a post végleges állapotát, nem annyira szükséges, hogy instant visszakapjam a vezérlést.
Igen, de szvsz csak azert, mert abbol indulsz ki hogy turhetoen realis idon belul (pl max par masodperc) visszakapod a kontrollt. Ez, mint irtam a fentiekben, kozel nem mindig valosul meg, kulonbozo vad okok miatt, es rossz esetben percekbe is belenyulhat. Jobb ha nem te mint felhasznalo harcolsz ezekkel a problemakkal, hanem meghagyod hogy intezze feloled a szero ahogy akarja, es jelenjen meg a kello helyen az anyag ha keszen van mindennel.
Egy biztos, a G-Shockokat nem adom, azok maradnak
Fura dolog ez az ízlés. A g-shock órák a megtestesítője annak ami miatt csúnya egy óra számomra.
Nájsz!
Milyen technikával készült?
Az óra szerintem az egyetlen "ékszer", amit egy férfi nyugodt szívvel hordhat magán. Utálom a láncokat, karkötőket és egyebeket, még a jegygyűrűm sem hordom.
Óra viszont jöhet mindig :)
De most 17-nél én is megálltam, racionalizálok, a korábbi impulzusvásárlásokat el fogom adni, szeretném leszorítani a készletet maximum 10-15 alapdarabra. Legyen dresswatch köztük, sportos búvár, beater, stb...
Egy biztos, a G-Shockokat nem adom, azok maradnak <3
Debiben vetítik Interstellart újra moziban, erre vártam évek óta. Bár ez a gagyibb helyi mozi, de így is nagy élmény lesz újra nagyvásznon látni szerintem, be is zsebeltem a jegyeket azonnal <3
Mi indokolja, hogy ennyire ragaszkodunk az aszinkron működéshez?
User szempontból nem annyira fontos szerintem , én úgyis inkább megvárnám a post végleges állapotát, nem annyira szükséges, hogy instant visszakapjam a vezérlést.
De ha a késleltetés a lényeg, és a szerver load balance, az persze más téma.
Ennek természetesen van a másik oldalról is egy kő kemény ellenérve is. Egyik ismerősöm rendszeresen megy túrázni a világ végére, van valami egy milliós csodaórája, de nem értek hozzá, se típust, se márkát nem tudok.
A lényeg, hogy mentek megmászni a Himaláját, volt nála kétfajta barométer is, mert ha odafönt elkapja őket a hóvihar, akkor rip. Szóval egyik sem jelzett gondot. Elindultak felfelé és párszáz méter után a csodaóra elkezdett alarmolni, hogy vihar lesz. A barométerek nem mondtak semmit. Ő azt a döntést hozta, hogy forduljanak vissza, mert legyen inkább safe a dolog. Amikor visszaértek a szállásra befeketedett a hegycsúcskörül az ég és bazi nagy vihar lett. Azt mondta, az óra egyértelműen megmentette az életét.
Elvileg tud még valami olyat is, hogy egyszer használatosan bekapcsol rajta valami vészjelzőt, ami nem függ a mobil hálózati lefedettségtől meg nemtom miktől. Ha azt bekapcsolja, akár az óceán közepén, be tudják mérni és odaküldenek egy csapatot. Ha ezt szükségszerűen elhasználja, azt többször nem lehet aktiválni, de ilyenkor is megmenti nyilván az életedet.
18. szülinapra kaptam egy akkor 18000 Ft-s Casio-t. Azt hordom a mai napig, ütött-kopott-viharvert, de működik. Mutatja az órát a dátumot és van illuminator rajta, amit még néha meg is nyomok, ha sötét van. Majd megörökli a fiam is valahogy így:
Kb pont ugyanígy.
Nagyjából 18-20 éves koromig hordtam órát hébe-hóba, de mindig is zavart egy kicsit. Aztán lett mobilom, ami ugyanúgy meg tudja mondani az időt, (még ha nem is olyan stílusosan,) szóval azóta se hordok órát. Egy ballagásra kapott Tissot pihen a fiókban immár 15 éve. Megpróbáltam jófogáson eladni, de kutyát se érdekelte, vszleg túl régimódi a design, vagy túláraztam, vagy túl népszerű típus volt, és sok belőle a hamisítvány. :)
Több ismerősöm is van, aki ilyesmi százezres órákat birtokol, soha nem szóltam le ezt a hobbijukat. Jól néznek ki az órák és nekem is telne rá, viszont van az agyamban két rossz beidegződés.
Nem szívesen költök arra a minimumnál többet, amit nem használok ki. Időjárás jelzés, szívritmus figyelés, 100m water resist, meg légnyomás mérés meg ki tudja mit tudnak még. Közben arra használom hogy mikor megy a vonat, mikor ér véget a meló, mikor megy a vonat.
A másik, hogy minél kevesebbet tudjanak lerabolni tőlem mezei bicskások az aluljáróban. Nem kell százezres fux, mobil, óra. Mondjuk a 60-80 ezres mobil még belefér, mert sok funkcióját használom napi szinten.
Valami ilyen megoldast otlottem ki, teljes atiras/atdolgozas es ReactPHP kitapasztalas helyett. Low-level modon kezelve a PHP kimutatas puffereket el tudom erni vegsosoron hogy:
- ellenorizni tudom szerver oldalrol hogy megerkezett e az elkuldott szignal, egy nagyon gyorsan kimutatott visszajelzessel.
- ezzel egy idoben el tudom a megszakitas header-eker kuldeni is, igy itt a kapcsolat meg is szakad szintugy gyorsan, es nem fogja le tobbet hosszas gondolkodassal a kliens bongeszot a tovabbi reagalastol.
- de a szerveren a beagyazas script tovabbra is fut a hatterben, es vegzi lassan a kiadott melokat.
- remelhetoleg ez a gyakorlatban great success, az aszinkronos mukodes szimulalasaban. :)
Proof of concept kodban mukodik kivaloan:
Mindjart nekiesek elesben is a RWHttp modulunkba belekodolni.
well 3) megoldas maris kilove. Mielott belekezdtem barmibe is, eszembejutott traceroute-tal megcsekkelni hogy mikent vandorolnak a packetek. Sajnos eredetileg is ugy mukodik ahogy gondoltam is hogy kellene, azaz fuggetlen attol hogy localhost-ot celzok vagy a szerver sajat IP-jet, ki sem megy a halozatba hanem azonnal megismeri es visszairanyitja a szerver sajat magara ezeket a kommunikaciokat. Csak valamiert remeltem hogy lehet megsem nekem van igazam es lehet kikandikal a routerig, potencialisan utkozve a tobbi korulotte levo szerver kommunikaciojaval, aztan ez a localhost-ra celzassal megoldodik konnyen. :/
Hat akkor marad a 1), vagy valami hasonlo trukkos atiras a jelenlegi megoldasrol. Ha szerveren beluli kommunikaciokban is veszhet szignal, akkor tuti a valasz megvarasa nelkuli kapcsolat lekapcsolas a gond az beszelt RWHttp modulban. Azaz potencialisan egy-egy melo kiosztasa pillanataban epp elfoglalt a szero akar a masodpect toredekeig is, akkor kenytelenek vagyunk megvarni a "mostmar szabad vagyok!" valaszt, ha el akarjuk kerulni a szignalvesztest.
Azt hiszem levadasztam a gyokeret a szignal vesztesnek. Az RWHttp (https://rewiredhu.cf/content/kivanalom-rewired-20-rwhttp) modulunk aszinkronos HTTP request funcionalitasaban van.
Teljesen leegyszerusitve roviden ugy mukodik, hogy nyit egy friss kapcsolatot, de amint elkuldte a kello adatokat azonnal be is zarja azt es felszabaditja az eroforrasokat, nem varja meg hogy visszajelezzen a szero hogy "koszi megkaptam es megertettem".
Onmagaban nem kellene hogy problema legyen, de ugy fest lehet annyi kommunikacio van mar a lokalis halozaton is, hogy mire eljut az uzi a legkozelebbi router-ig, es jonne vissza a szerohoz, lehet utkozik valamivel mar es elveszik.
Van par megoldas ennek a kezelesere:
1) A legtisztabb ut a legnehezebb. At kell irnom ezt a megoldast egy joval stabilabban es robosztusabban felallitottra. Pl megtanulom kezelni a ReactPHP-t vagy hasonlo hosszu ideje tesztelt es bevallt aszinkronos library-ket. Azutan irok egy RWn kivuli masodik webszervert, aminek a kizarolagos dolga lesz hogy a weboldalunk mellett csucsuljon a szamitogepen es idozitse, delegalja az RW altal kiosztott beagyazas melokat a memoriaban.
2) Beagyazasnal a szerver 1 szignal/beagyaznivalo munka helyet mit tudom en 2-3at/beagyaznivalo is elkuld egymas utan roviddel. Ezzel amolyan brute force modon emelne sokkal az eselyet hogy ha el is veszik 1-2 valahol, a tobbi ugyanugy folytatja a munkat es remelhetoleg a hiba soha nem jon igy elo. A negativuma hogy minden egyes szignal ujabb kulon process-t nyit, ami igy mind extra memoriat is eszik, amibol viszont nem vesztegethetunk ha nem muszaj, mert szukos. Meg a masik nagy negativuma, hogy ronda megoldas, es csak ragtapasz igazabol a problemara, nem kezeli azt.
3) Megprobalom atirni a kerdeses kodsorokat hogy a server a kiadott utasitasokkal a sajat webcime helyett csak a localhost-ot celozza. A cel ezzel az lenne, hogy elmeletileg igy ki se kelljen mennie a signalnak a lokalis halozatra a routerig, majd vissza a szerverhez. Igy az egesz beszelgetes onmagaban a szerveren belul tortenne, es "nem lenne" mibe utkozzon es igy potencialisan vesszen a signal.
Nyilvan hogy a 3) megoldassal probalkozok szerintem, azutan ha valamiert elverzik ez a ravasz terv is, akkor megyek a joval nehezebb 1)-re. A 2) max ideiglenes mentoov megoldas lehet ha addig is ki kell tartson valami a kozeljovoben, amig meg nem oldom a szitut valamelyik masikkal.
https://www.wired.com/2016/12/the-inside-story-behind-pebbles-demise/
Nagyvonalakban annyi, hogy a tipikus nep leszarja az okosorakat, es csak max a fitness miatt vasarolja oket. Ezt keson vette eszre a Pebble es az Apple is. Probalkoztak Kickstarterrel kesobb is (Pebble Core), majd 13milcsit osszekalapoltak belole, de sohasem szuletett meg a masodik produktum, es csomo ember refundot se kapott. Kickstarter utan meg kerestek friss befektetoket, de senki se mutatott erdeklodest igazan, a kalapolt penz meg hamar elfogyott, foleg ha rakat melosod es fizetnivalod van.
Citizen 740m-ért fel akarta vásárolni őket, de vissza lettek utasítva, majd 2016 év végén 23millióért vásárolta meg őket a Fitbit
Hindsight is 20/20. A Pebble CEO-ja akkor meg nem latta a veget es azt hitte aranybanyan ul, billiardos lesz. Kesobb derult ugye ki hogy igazabol failed produktum es nem nagyon lehet penzt csinalni belole. A Fitbitnek eladassal mar csak mentette ami mentheto volt.
A Pebble Time-ra pedig, ami máig első a Kickstarteren
Onmagaban nem jelent semmit, Ouya is brutal sok penzt kalapolt, de attol meg failed produktum lett, mint vagjuk.
De nem kulonlegesek ebben a Pebble-jek, ez a norma amugy. Legtobb ceg befuccsol es tonkremegy. Az a keves akikrol hallunk hogy bejott nekik, a kivetelek es nem a szabaly. Kismillio dolognak kell hogy osszejojjon a tenyleges sikerhez, termek idozitestol kezdve egy rakat mas. Az Apple-nel is vagod hogy anno majdnem vegleg becsukhattak az ajtot.
Én LG G Watch R-emmel vagyok így több okból: preordereltem, de a launch óta használt watchface-em elvileg 2021 elején megszűnik működni, mert Apple felvásárolta az előrejelzést szolgáltató céget (Dark Sky) és kivezeti az Android klienst és az API-t. (A watchface fejlesztése megszűnt évekkel ezelőtt sajnos.)
A szoftvert nem frissíthetem, mert Google elbaszta erőteljesen, konkrétan naponta legalább 1-2x használt funkciómat kiszedte.
A harmadik, hogy azóta nem láttam hasonlóan jól megoldott kb ütésállóra tervezett órát. Ennek magas, fém karimája van, eléggé sok nyommal már, de a kijelző megvan egyben szépen, köszöni szépen.
Én 4.5 éve tökéletesen elvagyok a Pebble Time-mal. Mikor anno az átkozott Fitbit felvásárolta őket és szemétre hajította a fasza e-ink technológiával együtt az egész termékpalettát (csak a szoftveres platformot akarták), akkor gyorsan vettem egy tartalékot ebay-en. Ha ennek az aksija egyszer megadja magát, lövésem sincs, hogy mit vegyek majd.
Nem tudok ra mit mondani. Anno a 4870 alatt kismillioszor crashelt a driver csak ugy magaban. Talaltam is rola egy kepet eleg gyorsan. :D rwurl=https://i528.photobucket.com/albums/dd323/MackyAlcaz/duck.jpgTokmind1 volt, hogy ujrarakom a rendszert, regi/uj driver. Ez ment megallas nelkul. Kurvara irritalt. Volt egy ido amikor 5 percig nem tudtam egyhuzamban jatszani, mert befosott a driver barmit csinaltam.
Azota nem volt ati kartyam szal szemelyes tapasztalatom nincs. A legutolso ilyen amit tapasztaltam, hogy nem tudtunk haverrel a Groundeddel jatszani mert amd kartyan folyamatosan crashelt a jatek.