23609
-
#16318
Kongga ale-van van gondom. 25-t kéne vinni a mérnöknek, 18-at tudtam venni tegnap Konga rendszerben tegnap, azóta nincs.
Már háromszor léptem be az utolsó 16 órában.. Van valakinek valami ötlete erre? -
#16317
Vicces bugnak tűnik:
Egy hajó szállíttatása nem számít új dokkolásnak, és ezt úgy néz ki hajónként tárolják :) (legalábbis a lenti sztori alapján - a szereplőket és helyszíneket a személyiségi jogok védelmében megváltoztattuk)
Leszállsz Lave Stationre a Vulture-oddal, egy kiadós lövöldözés után. Vonz az új vilát, ezért felveszed az Asp Exploreredet, és átutazol Coloniára vele. Oda áthívod a Vulturet, majd miután megérkezett átváltasz rá, és elindulsz vadászni.
Sajnos nem vagy túl ügyes, és kipukkasztják a hajódat. Persze van pénzed újra kifizetni, úgyhogy egy szép új, rendberakott Vultureban ébredsz. Lave Stationön, mert az ott szállt le utoljára :)
Utoljára szerkesztette: Dzsini, 2017.04.17. 07:46:23 -
#16316
Akkor asszem mihamarabb be kell szereznem nekem is egy Fer-de-Lance-t, mielőtt megnerfelik, mint a Python-t.
Bár most már van prismatic pajzsom, csak azóta nem nagyon tudtam vele játszani, hogy teszteljem.
Fegyver terén mi az ami neked bejött?
Van készleten Cannon, Fragment Cannon, de most Pulse van a hajón. Beam-et is próbáltam, de valahogy rosszabb lett a hő tényezője az upgrade után. Pedig pont azt akartam csökkenteni vagy legalábbis szinten tartani a sebzési táv növeléséve.
A pajzsot mire érdemes tuningolni? -
elite84 #16315 köszi, jobb vagy mint az inara
és még gyorsabb is
-
#16314
Felicity Farseer: Grade 3 DSS / Grade 3 Sensors
Tiana Fortune: Grade 3 DSS / Grade 5 Sensors
Lori Jameson: Grade 5 DSS / Grade 5 Sensors
Lei Chung: Grade 5 DSS / Grade 5 Sensors
Hera Tani: Grade 5 DSS / Grade 3 Sensors
Bill Turner: Grade 5 DSS / Grade 5 Sensors
Az anyaglisták spoiler mögött, mert hosszú:
Sensors
SPOILER! Kattints ide a szöveg elolvasásához!
Long range scanner
G1 Typical emission range 10% -> 14% Target scan angle -20% -> -10% Mass 39% -> 20%
Iron x1
G2 Typical emission range 20% -> 29% Target scan angle -30% -> -15% Mass 81% -> 39%
Iron x1 Hybrid capacitors x1
G3 Typical emission range 29% -> 45% Target scan angle -40% -> -20% Mass 120% -> 61%
Iron x1 Hybrid capacitors x1 Unexpected emission data x1
G4 Typical emission range 39% -> 61% Target scan angle -50% -> 25% Mass 161% -> 81%
Germanium x1 Electrochemical arrays x1 Decoded emission data x1
G5 Typical emission range 50% -> 75% Target scan angle -61% -> -30% Mass 200% -> 100%
Niobium x1 Polymer capacitors x1 Abnormal compact emissions data x1
Wide angle scanner
G1 Target scan angle 20% -> 40 % Typical emission range -8% -> -5% Power draw 20% -> 10%
Mechanical scrap x1
G2 Target scan angle 40% -> 81% Typical emission range -17% -> -8% Power draw 39% -> 20%
Mechanical scrap x1 Germanium x1
G3 Target scan angle 61% -> 120% Typical emission range -24% -> -12% Power draw 61% -> 29%
Mechanical scrap x1 Germanium x1 Classified scan databanks x1
G4 Target scan angle 81% -> 161% Typical emission range -32% -> -17% Power draw 79% -> 39%
Mechanical equipment x1 Niobium x1 Divergent scan data x1
G5 Target scan angle 100% -> 200% Typical emission range -40% -> -17% Power draw 100% -> 50%
Mechanical components x1 Tin x1 Classified scan fragmentx1
Lightweight scanner
G1 Mass -20% -> -40% Integrity -15% -> -10% Target scan angle -10% -> -5%
Phosphorus x1
G2 Mass -31% -> -50% Integrity -31% -> -20% Target scan angle -15% -> -10%
Salvaged alloys x1 Manganese x1
G3 Mass -40% -> -61% Integrity -45% -> -31% Target scan angle -20% -> -15%
Salvaged alloys x1 Manganese x1 Conductive ceramics x1
G4 Mass -50% -> -70% Integrity -61% -> -40% Target scan angle -25% -> -20%
Conductive components x1 Phase alloys x1 Proto light alloys x1
G5 Mass -61% -> -81% Integrity -75% -> -50% Target scan angle -30% -> -25%
Conductive ceramics x1 Proto light alloys x1 Proto radiolic alloys x1
Discovery scanner
SPOILER! Kattints ide a szöveg elolvasásához!
Long range scanner
G1 Scan range multiplier +20 -> +40 Mass 39% -> 20%
Iron x1
G2 Scan range multiplier +40 -> +80 Mass 79% -> 39%
Iron x1 Hybrid capacitors x1
G3 Scan range multiplier +60 -> +120 Mass 120% -> 61%
Iron x1 Hybrid capacitors x1 Unexpected emission data x1
G4 Scan range multiplier +80 -> +160 Mass 159% -> 79%
Germanium x1 Electrochemical arrays x1 Decoded emission data x1
G5 Scan range multiplier +100 -> +200 Mass 200% -> 100%
Niobium x1 Polymer capacitors x1 Abnormal compact emissions data x1
Wide angle scanner
G1 Scan angle multiplier +20 -> +40 Mass 39% -> 20%
Mechanical scrap x1
G2 Scan angle multiplier +40 -> +80 Mass 79% -> 39%
Mechanical scrap x1 Germanium x1
G3 Scan angle multiplier +60 -> +120 Mass 120% -> 61%
Mechanical scrap x1 Germanium x1 Classified scan databanks x1
G4 Scan angle multiplier +80 -> +160 Mass 159% -> 79%
Mechanical equipment x1 Niobium x1 Divergent scan data x1
G5 Scan angle multiplier +1000 -> +200 Mass 200% -> 100%
Mechanical components x1 Tin x1 Classified scan fragment x1
Fast scanner
G1 Scan rate multiplier +10 -> +40 Mass 39% -> 20%
Phosphorus x1
G2 Scan rate multiplier +20 -> +50 Mass 79% -> 39%
Phosphorus x1 Flawed focus crystals x1
G3 Scan rate multiplier +30 -> +60 Mass 120% -> 61%
Phosphorus x1 Flawed focus crystals x1 Open symmetric keys x1
G4 Scan rate multiplier +40 -> +70 Mass 159% -> 79%
Manganese x1 Focus crystals x1 Atypical encryption archives x1
G5 Scan rate multiplier +50 -> +80 Mass 200% -> 100%
Arsenic x1 Refined focus crystals x1 Adaptive encryptors capture x1
-
elite84 #16313 azt lehet tudni, melyik mérnök foglalkozik a primary senzorral, és mi kell hozzá? -
#16312
#16084 -ben van bemutató, hogy melyik módosítás kb. mit számít. -
#16311
Olvasgattam még a logot:
"Engineers
• New blueprints added
• Manifest/Killwarrant/Wake scanner:
• Long Range
• Wide Angle
• Fast Scan
• Ship primary sensor:
• Light weight
• Long Range
• Wide angle
• Detailed Surface scanner (affects how fast you can basic/detailed scan planets):
• Long Range
• Wide Angle
• Fast Scan"
Van még mit csinálni a felfedező hajóimra :) -
#16310
FDL-el nyomom, Nem izzasztanak meg. Tunningolt mindene, nagyon kemény a pajzsom. Fegyvereket tesztelgetem, mindig cserélem, ahogy kimegyek tankolni.
Most 92%... Még egy óra kb. -
#16309
A külső aszteroida bázisok közül sokat a mélyűrben, akár több ezer fényévre helyezték el, szép ködöknél, hasonló helyeken: itt egy lista. Megaship lista itt van készülőben. Ezeknek az a lényege, hogy folyamatosan tudják mozgatni a rendszerekben, így pl. a hajót uraló frakció ezekkel mozoghat (szállíthatja akár a játékost is, ha bedokkol rá), stb. -
#16308
Ha az a 3 master sidewinder csapatban van, akkor rendesen megszívathatnak.
A Python-omat az Adder-ek szokták szívatni, ha csapatban vannak.
A konda rossz fordulása miatt, meg elég nehéz lelőni őket.
Szóval rendesen kell izzadni a joy-on, hogy adott esetben túléljük a dolgot és ne futamodjunk meg. -
Fenimor #16307 Biztos akarunk mi Járkálni, csak elfáradunk mire megkerülünk egy Anakondát! 
-
#16306
Köszi!
Grindelek még mindig combat rankot, hogy mehessek mérnökhöz. Már 88% az utolsó, de nagyon lassan megy fel.
Utána olvastam, hogy mi lehet a baj és találta megy nagy butaságot.
A rankot darabszám alapján növeli és ezt a darabszámot beszorozza az ellenfeled és a te rangod alapján.
Tehát sokkal gyorsabban mész fel, ha kilősz 3 master sidewinder, mint egy harmless anacondát. Milyen butaság ez már... -
Fenimor #16305 Mega hajót az "Aldebaran" rendszerben "Fisher's Rest" néven lehet fellelni. -
#16304
Hol lehet ezeket megtekinteni? -
Fenimor #16303 Nem vásárolhatóak meg, állomásméretű hajók, csak gyönyörködhetsz bennük. Pl: Aszteroida állomást a "T tauri"rendszerben talász
Utoljára szerkesztette: Fenimor, 2017.04.16. 16:08:58 -
#16302
https://forums.frontier.co.uk/showthread.php/341916-2-3-The-Commanders-Changelog?s=f0daab05f427bbc470e59437ca219074
"• Added 32 asteroid bases in various deep space locations"
Ezek hol vannak?
"• Added Megaships
- Tanker
- Cargo
- Asteroid Miner
- Flight Operations
- Prison Ship
- Science Vessel
- Passenger
- ???
- ???
"
Mik ezek a megahajók? Megvásárolhatóak? -
Fenimor #16301 Off: Most hogy – április 14. és 18. között – ingyenesen kipróbálható a Star Citizen, beélesítettem én is. Rohadtul érződik hogy még csak alpha státuszban van, és itt nem a bogarakara gondolok. Látványorgia korlátok közé szorítva, annyira steril-üres, rohangálok mindenfelé vagy csak röpködök az űrben, ez így ebben formában csak egy tech demo. Várós a játék, de mikor lesz még ebből valami? Mindenesetre egy Braben-Roberts szerelemgyereket megnéznék! (játékértelemben) On:
Utoljára szerkesztette: Fenimor, 2017.04.16. 12:27:03 -
#16300
A roomscale VR (körbesétálós lehetőség, amiről nem túl rég volt szó) előnyei:
SPOILER! Kattints ide a szöveg elolvasásához!![]()
-
#16299
Tök jó :)
-
TokraFan #16298 Kifejezetten élvezem olvasni amiket írsz, mert így némi betekintés lehet nyerni a fejlesztések belső folyamataiba! Én laikusként csak azt látom, hogy bizonyos címeknél, sokkal kisebb stábbal szinte nincs bug a verziók között (jó példa a Subnautica, ami az egyetlen EA játékom egyébként), pedig rendszeresen jönnek a tartalmak, szinte havonta. Máshol meg azt látni, hogy valamit fixálnak, ami hazavág egy másik dolgot, ami addig működött. Azt eddig is sejtettem, hogy ennek oka a nem megfelelően tervezett struktúra lehet...
De így jobban meg lehet érteni, úgyhogy köszi a sok szakmai infót, amit mégcsak OFF-nak sem érzek itt. -
nibron #16297 azért nem próbálják ki mert nincs értelme. a debug és release verzió között csak annyi lehet a különbség, hogy a debugban benne van egy csomó, a teszteléshez/hibakereséshez szükséges információ, logolások, különböző funkciókat figyelő függvények (pl. memórialefoglalások-felszabadítások figyelése a memóriaszivárgás felderítése végett) meg ilyenek. egy rakás, ha nem legtöbb fordítóban teljesen külön konfig van a debug és release verziókra. tehát még az optimalizációs beállításoknak is lehet mást megadni. ami azért hülyeség, mert az optimalizáció alapvetően más kódot eredményez, tehát ha külön-külön állítjuk eleve nem kaphatjuk ugyanazt a kódot. ehhez hozzájön még az is, hogy egy teljes projectet nem ugyanarra a konfigra futtatunk, hanem modulonként külön van, tehát még sokszorozni is lehet a problémát. az ilyenek kiküszöbölésére vannak a kiadásfelelősök (builderek), akiknek az lenne a feladatuk, hogy gondoskodjanak a lefordított kódok konzisztenciájáról. le is lehet ellenőrizni (le is kell), mert a fordítóktól lehet kérni assembly fájlt és ha tudjuk, hogy a két verzió egyezik a debug verzió "szemetétől" eltekintve, akkor tényleg felesleges a release mélyreható tesztelése. ezeket a beállításokat pedig egyszer beállítjuk, és a project életciklusa alatt nemigen változtatjuk. az egy nagyon különleges valami lehet, pl. kiadják a win666-ot, és kompatibilitási gond miatt felül kell vizsgálni a fordító beállításait. természetesen olyankor az ellenőrzést újra és teljeskörűen el kell végezni. -
#16296
Ez volt a kimerítő szakmai válasz az első kérdésemre, köszönöm, így már ezt a részét érte(ni véle)m.
Viszont még mindig nem tudjuk, hogy miért nem ellenőrzik (futtatják le élesben és próbálgatják pár percig) alapszinten a release változatot, amit akárhogyan is de utoljára fordítottak le. (Újra aláhúzva azt hogy eddig minden nagyobb kiadásnál volt ilyen baki, tehát itt szokás van, nem kivétel.)
---------------------------------------------------
Eddig is tudtam hogy teljesen felesleges az interdictor modul (a küldetések célpontjai, ha SC-ban jelennek meg akkor egyszerűen elmennek egy RES-be, és ott le lehet követni őket), de most már az is kiderült hogy a FS wake scanner is az. Történt ugyanis hogy egy kalózvezér kiiktatást éppen a pitonban ülve vállaltam el, ő meg korvettel volt, és első nekifutásra el tudott meneküni amikor 40%-ra lőttem a hullját. De 2 perc múlva újra megjött a "mission objective detected", és kezdődött elölről, neki 100-100% (ezért a pajzs leszedése után nekiboostoltam 2x, így már nem tudott meglépni ehe-ehe...). -
#16295
Végre! Lehet újra elindulok valamerre. -
nibron #16294 én is elég sok early access-el találkozom. de mielőtt pénzt adok rá megnézem, hogy érdemes-e. az early access lényege sem az, hogy bughalmazban tobzódjál, hanem inkább azt a célt szolgálná, hogy kiadás előtt hozzáférhess. esetleg bele tudj szólni a történetbe. tudvalevő, hogy ebben a fázisban nincs például optimalizálva, mert azt kiadás előtt kell egyszer megejteni amikor már összeállt a teljes project. a hibákról csak annyit, hogy olyan fejlesztés nincs ami megengedné a hibákat, sőt egyesek még csak nem is terveznek a hibákkal (pedig igenis kell, mint pl. az építőiparban is), de olyan nincs, hogy hibamentes fejlesztés, ezért kalkulálni kell vele, és a keletkező hibákat a lehető legrövidebb úton javítani kell. ezenkívül ciklikusan vannak javítószakaszok, ahol általában a teljes projectet javítják amennyire lehet (az átfedett funkciók hibáinak itt ki kell derülnie). amikor a tesztelőknek a fejlesztés átadja a projectet, akkor annak elvileg már hibamentesnek kell lennie. ezt hívják nullás tesztnek amit a fejlesztők végeznek. amíg a nullás tesztben ismert hiba van, nem lehet továbbadni. elvileg nem kerülhetne ki a folyamatból hibás kód, ugyanúgy mint a futószalagról lekerülő különböző termékek esetében. és itt nem tehetünk különbséget ea, beta, rtm között. mindegyik kiadásnak ugyanazt a folyamatot kell végigjárnia. miután kiadtuk tulajdonképpen elkezdünk egy új terméket fejleszteni. ugyanúgy mint pl. a bmw esetében: kihoznak egy típust, azután a következőt, és így tovább. a különbség csak annyi, hogy a második típusnál/verziónál már nem kell nulláról kezdenünk. ezért aztán az early access-nél sem elfogadott a bughalmaz. az már más kérdés, hogy könnyebben elfogadjuk.
azon már én is gondolkodtam, hogy david mekkora kárt okoz ennek a projectnek, mert azért azt lássuk be, ahogyan nyilatkozik az egy épkézláb marketingesnek a rémálma. és ha így vesz részt a fejlesztésben illetve a többiek is hasonló kaliberek akkor tényleg örülhetünk, hogy legalább ennyire megy a dolog.:) -
TokraFan #16293 Miért lennék benne? Én egy kész terméket veszek amitől joggal várom, hpgy működjön. De nem bétázok és nem veszek Early Accest sem.
Megjegyzem, én csupán egy felvetésre reagáltam, mely szerint megoldható lenne a fejlesztés sokkal okosabban és lényegesen jobb minőségben is, de véleményem szerint, az általam írottak miatt nem csinálják ezt mégsem úgy, ahogy nibeon kolléga összefoglalta. Még azt is leírtam, hogy tisztán gazdasági szempontból a megoldás zseniális, de ettől még nem ez a jó irány, főleg ha megnézed amit nibron írt és megérted, hogy mennyivel minőségibb módon is lehetne fejleszteni.
Azért az mégis elég szomorú, hogy minden egyes patch után 2 hónapig a játék tele van buggal. Nyilván, ez egy olyan műfaj, ahol bug mindig lesz, de ha költenének rendes szakemberekre, akkor nem a usereknek kéne hibát keresnie hónapokon át. Mindenki jobban járna.
És ami a lényeg: Én nem egy Early Access címért fizettem ahol tudom, hogy nekem kell tesztelnem egy bughalmazt, hanem egy kész termékért, amitől elvárom, hogy működjön és ne nekem kelljen hibát keresni. De főleg ne kelljen minden patch-nél két hónap szünetet tartanom a játékban csak azért, mert Braben nem képes felvenni egy rendes programtervező szakembert. -
nibron #16292 "De úgy is mondhatnám, hogy látod a valóságot, csak nem értem, hogy miért lázadsz, mikor te is benne vagy a kerékben."
tippelnék: lehet nem fekszik neki a birkaeffektus.:)
egyébként szerintem nem lázadás, egyszerű véleménynyilvánítás.
Utoljára szerkesztette: nibron, 2017.04.15. 08:54:18 -
Sir Cryalot #16291 "A 3D-t egy holografikus kivetítő adná, de az még nem elérhető. És mi értelme lenne annak is?"
nem a kijelzőtől 3d egy játék hanem pl. hogy a felületek nem textúrázottak ( na annál kevés 2D meg 2.5D-bb dolog van ) -
#16290
"Minek veszek játékot?" - A játék (úgy általában a kikapcsolódás) a rendelkezésre álló idő szórakozássá, élménnyé konvertálásáról szól. Ez az értelme.*
* - haszonelvű nézetből persze :) -
#16289
Elég rosszul látod a világot.
De úgy is mondhatnám, hogy látod a valóságot, csak nem értem, hogy miért lázadsz, mikor te is benne vagy a kerékben.
Az egész arról szól, hogy kinek, mi és mit ér meg. Kereslet/kínálat.
Egyesek már akkor játszhatnak a játékkal, mikor mások csak csorgatják a nyálukat utána. Az, hogy bugos? Kit érdekel? Ők az elsők. Amellett, hogy azért valamilyen szinten még játszható is a játék.
És adott esetben bekerül a nevük vagy dedikált cuccot kapnak, ami másnak nem lesz. És még sorolhatnám.
De felteheted a kérdést magadnak: Minek veszek játékot?
Hisz az egész csak illúzió, ámítás és ami azt illeti, teljesen értelmetlen is. Csak egy szoftver, amit 2D-ben nézhetünk a monitoron keresztül. És igen, a VR-esek is csak 2D-ben látják, bár lehet 2,5D-nek is nevezni, mert korlátozott mennyiségben, de ott tényleg meg lehet kerülni egy tárgyat. A 3D-t egy holografikus kivetítő adná, de az még nem elérhető. És mi értelme lenne annak is?
Ilyen a világ, ilyenek az emberek. És nem csak a játék terén, mindenben.
Azért csinálják azt az emberek, amit, mert szeretik, vagy ahhoz van kedvük. Az, hogy van e értelme? A kutyát nem érdekli. Éppen ezért nem is kell megkérdőjelezni, mert ezzel csak magadat kérdőjelezed meg. Eleve azzal, hogy játszol. -
TokraFan #16288 "tehát az igaz, hogy egy ilyen fejlesztés többe kerül, mert az ehhez értő szakembereket meg kell fizetni"
Itt van a kutyus elásva...A PC-s játékiparban rájöttek valakik, valamikor, hogy a userek olyan szinten rajongói a játékoknak, hogy bármit le lehet tolni a torkukon, csak meg kell magyarázni. Ebből indult a gondolat, hogy teszteltessük velük a játékot, cserébe még ők fizessenek is érte. Marketing és főleg gazdasági szempontból ez egyébként zseniális, hiszen mint írtad, az automata tesztelés kialakítása költségekkel járna, de még a régi "hivatásos tesztelősdi" is az volt. De minek fizessen ezekért, ha van pár ezer bepalizható ember, akik önként és dalolva fizetnek egy bughalmazaért, amiből ráadásul még nekik kell kigyomlálni a hibákat is? Fdev (vagy az összes többi, aki erre épít), meg hátradől, nézegeti a bankszámlára csordogáló pénzeket ahelyett, hogy kiadásokat eszközölne rendszertervezőkre, teszterekre, majd várja, hogy a userek küldözgessék be a hibákat.
Őszintén? Minek erőltessék meg magukat, ha ilyen szinten hülyére lehet venni emberek ezreit, akik ezt a rendszert még teljes mellszélességgel védik is?? Én sem görcsölnék a helyükben...Az, hogy a többi meg nem tud játszani pár hónapig a bughalmaztól, kit érdekel?
Utoljára szerkesztette: TokraFan, 2017.04.15. 01:26:18 -
#16287
új árucikkek -
nibron #16286 amikor fejlesztenek-tesztelnek akkor ezt egy ún. debug verzión teszik. kiadni viszont a release verziót adják ki. majd az összes fordítóprogramnál rengeteg optimalizációs beállítás létezik. ha ezek nincsenek profi módon beállítva, különböző optimalizált kódot generál debug ill. release verzióknál. így előfordulhat, hogy a release verzióban tulajdonképpen olyan hiba keletkezik, ami a debugban nem. talán ez a leggyakoribb hiba kiadáskor. illik rá odafigyelni, mert rettentő kellemetlen, de viszonylag egyszerűen javítható. mindösszesen egyetlen olyan fószer kell aki alaposan ismeri a fordító beállításait. sajnos a programozók többsége nem ismeri olyan alapossággal a munkaeszközét ahogyan azt te elvárnád.
Utoljára szerkesztette: nibron, 2017.04.14. 16:28:47 -
#16285
Én csak azt nem értem, hogyan tud benne maradni (vagy a béta zárása után 1 perccel keletkezni) egy olyan ordító, szembeötlő stb hiba, mint pl ez a térképen infoablak-elcsúszás? Az teljesen rendben van hogy a kutya nem veszi észre hogy mondjuk... mi is volt?: az egyik spéci rakétacsomag végtelenné és nemfűtővé vált. De mindig van legalább egy olyan böszme nagy hiba, amit KIZÁRT hogy a bétában senki sem vett észre vagy senki sem jelentett. Aztán meg amikor elkészül egy végleges változat, amire azt mondják hogy "na ezt akkor holnap reggel elkezdhetjük felmásolni", ilyenkor tényleg SENKI közülük nem próbálja ki legalább annyira, hogy a legeslegalapvetőbb funkciók rendesen működnek-e?? Állandóan olyanokkal égetik magukat, amik 5... nem is: KETTŐ PERC alatt kiderülnek! 
-
nibron #16284 off:
ügyviteli programot eddig hobbiból és kényszerből csináltam a melóhelyemnek. játékokat ellenben 16 éves korom óta szintén hobbiból. elég jól ismerem a folyamatot, hogyan kell ilyen progikat felépíteni. a jelenlegi munkámban ahogy dolgozunk, azt tulajdonképpen a játékfejlesztések során megélt problémák nyomán kifejlesztett különféle megoldásokkal értük el. mondok egy példát: ha írok egy játékot amit folyamatosan ki kell adnom különböző fázisokban a fejlesztés során, és az egyszerű térképkezelőben minden kiadáskor megjelenik ugyanaz a hiba, akkor talán már éppen itt az ideje, hogy rátegyek a térképkezelőre egy automata hibakeresőt. mondjuk az általad is említett unittest-et éppen az ilyen problémákra/feladatokra találták ki. és abban tökéletesen igazad van, hogy ezek előállítása plusz költség (még talán 2-nél nagyobb is lehet az a szorzó), de akkor azt kérdezném, hogy mennyi az állandó repetitív tesztelés szorzója. és ha már ismered pl. a unitest-et, akkor szintén kérdés, hogy melyiknek nagyobb a hatásfoka? az automatának, vagy az emberi tesztelésnek. különben is az emberi teszteléshez is fel kell állítani egy checklistet amin végig kell haladni, azt is upgradelni kell, stbstbstb. akkor most foglalkozzunk kicsit a költségvetéssel: igazából az előző példában egyetlen probléma van. mégpedig az, hogy az automata tesztelőnek tényleg magas az előállítási költsége. tehát azt kellene csökkenteni valami furmányos módon. mi van akkor ha a unittest-et nem a fejlesztés és tesztelés között írjuk meg, hanem az egész programot úgy tervezzük meg, hogy eleve benne lesz. úgy is magasabb a bekerülési költség, de már sokkal jobb. viszont ha ezzel a technikával tervezel, akkor tudatosan úgy építed fel a fejlesztést, hogy egy programtervezőt helyezel a kódoló fölé. és ilyenkor az történik, hogy a tervező a programozónak sokkal kisebb esélyt hagy a hibák előállítására, a hibák sokkal előbb kiderülnek, és még a javításuk is egyszerűbb. és ezzel az egésszel teljesen automatikusan jön még egy adalék. azzal, hogy sokkal tudatosabban építesz fel egy programot, már eleve kevesebb hibával kell számolnod, főleg a különböző modulok közötti inkonzisztenciában, még a dokumentációid is teljesen rendben lesznek. mind a tervezési mind a programozási doksikra igaz ez. és ezeket már ingyen kapod. akkor el is jutottunk a tudatos és költséghatékony fejlesztésig. és még mindig lehet továbblépni. ha már ilyen pöpec módon építettél fel valamit, akkor elkezdheted használni az osztályokat. aminek az alkalmazása sokkal jobban áttekinthetővé teszi a forráskódot, a polimorfizmussal elérheted, hogy az abstract osztályokból való kezeléssel az összes leszármazottnak egységes interface-t tudsz kialakítani. az objektum zártsággal pedig megvéded az osztályodat, hogy külsőleg beletudjon valami nem odavaló dolog piszkálni. ezek a technikák mind a hatékonyabb és hibamentesebb fejlesztés miatt léteznek. és remekül lehet őket automatán tesztelni, mert eleve erre vannak teremtve. tehát az igaz, hogy egy ilyen fejlesztés többe kerül, mert az ehhez értő szakembereket meg kell fizetni, de az egyáltalán nem igaz, hogy több idő, rossz eredmény stb. sőt a hibák számának, a hibakeresés idejének drasztikus csökkentése miatt a költségeid is jóval kevesebb lesz. és akkor a végcél: a felhasználóid is jóval elégedettebbek lesznek. az nem biztos, hogy jó amikor kiadás után jobb ha a program közelébe sem mész legalább egy hónapig. ha játszani szeretnél, valszeg nem tesztelni szeretnél (nem is a te feladatod), és a játék a játékról szóljon, ne a hibák miatti bosszankodásról. tényleg itt most felmerült bennem a kérdés: ha nem töltöm le frissítést akkor ugye nem is tudok játszani?
tök mindegy, hogy milyen programról beszélünk, még talán az ügyviteli programok is beleférnek, bár az alkalmazásfejlesztés ami ugye a programozás legkönnyebb ágazata, de annak is kell egy fejlesztőrendszer amiben az alkalmazásban felhasznált komponensek vannak.
egyébként mostanság melóügyileg egy arm processzorokon (leginkább cortex-m) futó kernellel foglalatoskodom amihez természetesen tartozik egy teljeskörű gui, network, usb, can és egyéb finomságok. asszem eddigi életem során ez a legkeményebb dió. itt ugye nem lehet osztályokat alkalmazni, hagyományos struktúrált programozással lehet csak megcsinálni, de ide is kellenek az automata tesztelők. a realtime-ot nem is lehet másképp.
a grafikai bugok egy teljesen más kategória. azért sosem szóltam egy szót sem, ha nem sikerült egy textúra a nagy hajtásban, vagy illesztési hiba miatt bevillan valami. de ha van pl. egy ajtó amit nem lehet kinyitni, az sosem grafikai hiba, az a hiba mindig a kódban van, és azt már lehet tesztelni.
asszem röviden ennyi.:))
Utoljára szerkesztette: nibron, 2017.04.14. 14:53:07 -
#16283
Köszi! És a korábbit is köszi! -
#16282
"és automata tesztelést alkalmazunk, mert az sokkal precízebb,"
Ez nem könyvelő szoftver, hanem videójáték. Persze lehet tesztelni automata, lehet tesztelni unit szinten, lehet ezer módon, de akkor kapsz egy Mass Effect Andromeda-t, Assassins Creed Unity-t és társait. Videojátékot nem lehet automatán tesztelni. Mármint bizonyos szintig lehet, de akkor szorozd meg kettővel az előállítás idejét és a befektetett összeget. És akkor ott van még a grafikai bugok tömkelege, ami kódtól úgymond független.
Utoljára szerkesztette: MerlinW, 2017.04.14. 11:39:47 -
#16281
Természetesen megvan a lehetőséged, a Frontier szinte állandóan vesz fel embereket. Senki nem tart vissza, hogy megpróbálj javítani a dolgokon a te tudásoddal és tapasztalatoddal.
Ha viszont nem akarsz, akkor feleslegesen koptatod ezzel a billentyűzeted, mert értelmetlen hangulatkeltés az egész (plusz messziről jött ember...). Ők így csinálják, neked pedig nincs beleszólásod.
Utoljára szerkesztette: Dzsini, 2017.04.14. 11:39:22 -
nibron #16280 "A jelentett és feldolgozott bétás buglista ~1200 tételből áll"
na ez az amitől menten lefosom a bokám.:) beta állapotban ennyi...i? nem semmi csávók imitálják ott a munkát. nem szívesen lennék ott. de ha ott lennék valami vezető beosztásban, lenne jópár beom akik szintén nem szívesen lennének ott. viszont néhány év alatt rendet tudnék tenni.:)
szóval elég kőkorszak lehet ott fejlesztésben-tesztelésben. ma már a mai technikákkal ez már elfogadhatatlan. amúgy a hibákat már nem úgy keressük, hogy halálra teszteljük a dolgokat. az már egyáltalán nem gazdaságos és a hatékonysága is megkérdőjelezhető. inkább a tervezési, fejlesztési fázisban megtervezzük és előállítjuk a tesztelőrutinokat is, és automata tesztelést alkalmazunk, mert az sokkal precízebb, rohadtul nem téved és nem fárad el. a sebességről már ne is beszéljünk. és az már csak hab a tortán, hogy így hibák szempontjából sokkal alaposabban megtervezik a rendszert és így a keletkező hibák száma is jóval kevesebb már a nullás verziónál is. de az tény, hogy ha valaki így csinálja, akkor tényleges munkával kell kitölteni azt a napi 6 órát. -
#16279
Gyorstalpaló Salomé témában:
