ELITE: Dangerous

Biztos akarunk mi Járkálni, csak elfáradunk mire megkerülünk egy Anakondát! <#nyes>

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

Mega hajót az "Aldebaran" rendszerben "Fisher's Rest" néven lehet fellelni.

Hol lehet ezeket megtekinteni?

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

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?

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

A roomscale VR (körbesétálós lehetőség, amiről nem túl rég volt szó) előnyei:

Spoiler (katt a megjelenítéshez)

Tök jó 😊

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.

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.

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...).

Végre! Lehet újra elindulok valamerre.

é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.😊

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.

"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

"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 )

"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 😊

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.

"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

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

É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! <#miaz><#fejvakaras>

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

Köszi! És a korábbit is köszi!

"é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

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

"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.

Gyorstalpaló Salomé témában:

Az FDev belül sokat tesztel, ha az aktuális frissítés eljut odáig, hogy nagyjából funkcióteljes (ez hosszú idő, a Multicrew első, házon belül működő változatait pl. 2016 elején már látták a Lave Radiosok, mikor a Frontiernél jártak látogatóban, ez még az Engineers megjelenése előtt volt), és nem omlik össze szíre-szóra, akkor megnyitják a bétát, és jön a hibakeresés nagy időszaka. Igen, vannak, akiknek ez "csak" egy korai játéklehetőség, de sokan, akik szeretik a játékot azért bétáznak, hogy megtalálják a hibákat, és még több örömük legyen benne. Ez is a fejlesztők és a játék támogatásának egy formája.

Amíg nem veszel tevékenyen részt a bétában, addig nem lehetsz 100%-ban meggyőződve arról, hogy a többiek észrevesznek minden hibát (feltételezve azt, hogy te észreveszel majd mindent, amit a többiek nem).
Vagy megbízol bennük, és akkor nincs igazán más út, hogy elfogadod azt, hogy nem feltétlenül találnak meg minden hibát, és jelenhetnek meg újabb hibák minden egyes lépés során, és nem mindig sikerül minden jelentett hibát teljesen elhárítani a bétaidőszak során.

Pont ezért kérdeztem, mert nem vagyok meggyőződve hogy most akkor mi is van! Várunk, oszt majd csak javulgatnak a dolgok.

Ha te meg vagy győződve arról, hogy nem jelentette senki, akkor két eshetőség van: vagy az összes bétázó tojt rá / nem vette észre (1000 másikat viszont igen), vagy most került be, mikor kieresztették a publikus szerverre.
Válaszd ki, hogy te melyikben szeretnél hinni, és tégy úgy 😊

Következő alkalommal pedig csatlakozz a bétázók sorához, és akkor még egy plusz szempár lesz, aki segíthet nekik keresni a hibákat a végleges változat megjelenése előtt.

Nem hinném hogy a lentebb említett hibák az élesítés előtti szakaszban képződtek volna, ahhoz nem túl bagatell dolgokról van szó.

A jelentett és feldolgozott bétás buglista ~1200 tételből áll, megnézheted a Frontier fórumokat, ott vannak a (mostanra lezárt) bétás topicok.

Emellett mindig vannak olyanok, amik a legutolsó béta és az élesítés közötti időszakban alakulnak ki.
Utoljára szerkesztette: Dzsini, 2017.04.14. 08:16:27

A béta teszterek nem jelezték ezen hibákat? (vagy pont letojják az illetékesek) Én úgy tudtam hogy azért van a béta hogy kijavítsák a talált bugokat az élesítés előtt. Most majd jönnek a kisebb tapaszok ahogy az lenni szokott és 1-2 hónap múlva beáll a lelki béke. Csak akkor minek a béta?

Még egy kis segítség felfedezőknek:

Spoiler (katt a megjelenítéshez)

Bolygóraszállásnál is végig ocsmányak a textúrák, két lépéssel lemaradva finomítja, végig tompa, elmosódott kontúrokat kell nézni.

egyre több az ilyen online fps-esés report topic a hálón, bár nem ugyanúgy jelentkezik mindenkinél. Általánosságban viszont elmondható, hogy az openhez köthető. Lehet h ideje lenne Fdevnek áttérni a P2P networkingről....

ismét komoly tesztelés lehetett frontieréknél. remélem kapnak jó magas prémiumot is. úgy értem, hogy jó magasra rakják.

Vele nem használtuk közösen a hajókat. Másik taggal igen, mindkettőjük eltünt az online térből, örökre... de csak számomra, ők látnak...A többi tagot látom, mint eddig.

amigás idők??? legszebb időszak volt...

Akkor ha jól értem ez még csak nem is a multi-crew móka, hanem elég az hogy egy barát-listás kolléga szintén openben legyen?? Nem lehet hogy csak akkor kezdődik ez a viselkedés, ha legalább egyszer közösen használjuk egymás hajóját?

Nem a szidás miatt 😊 Komolyan hasznos szerintem benne, ahogy jelentitek, hogy épp ki hol van és mit tapasztal.

pedig nem is szidtunk senkit....😊 sajnos a fő baj h addig pl. én nem játszhatok nemhogy együtt, de még egy időben sem a haverommal, mert nem cseszek ki vele, hogy fél fps-el játsszon. olyan, mintha 1 gépünk lenne....😊
Utoljára szerkesztette: gyurmak, 2017.04.13. 20:39:19

Ez igencsak érdekes 😊 És nagyon hasznos, hogy így mindenestül ment a supporthoz (kár, hogy a beszédet nem fogják érteni valószínűleg) <#eljen>

Egy bámulatos bug, ami eléggé ellehetetleníti a multit bizonyos esetekben:
A friend commanderek egy része eltűnik az online játékosok, közül, hiába online vannak, a főmenüben, játékban is offline a státuszuk, de csak néhány commander felé, tehát semmilyen formában nem lehet velük kommunikálni, játszani. Ez egyirányú, a másik játékosnak online-t mutat. Ez is idegesítő, de itt a lényeg:
A láthatatlan, "B" játékos FPS-e (igen, a VGA FPS-e) lefeleződik, ha a másik, "A" játékos belép!!! Ha kilép visszamegy eredeti értékre. Solo módban nincs ilyen. csináltunk videót, 1:50-től a lényeg. supportnak küldve, kíváncsi vok mi lesz a válasz....:

Spoiler (katt a megjelenítéshez)

Utoljára szerkesztette: gyurmak, 2017.04.13. 20:30:25

asszem en is kihajozom majd..

Egy kis gyors pénz, kb. 200 fényévre Soltól:

Spoiler (katt a megjelenítéshez)

10 terraformálható + 1 földszerű
Utoljára szerkesztette: Dzsini, 2017.04.13. 17:33:48

na ez nice!

A 2.3-al megnövelt felfedezési díjakra frissített felfedezési segédlet:

Spoiler (katt a megjelenítéshez)

A terraformálható égitestek kifizetését elég masszívan megnövelték 😊