7250
Egosoft X4
-
nibron #2446 A jövő a Vulcan-é, mert alapvetően többszálas technikára épül, míg az OpenGL-ek nem. Az openGL-be foltozással került be. A mostani elvárásoknak lassan már nemigen felel meg, viszont a Vulcan-t eleve a mostani és a jövőbeli célokra tervezték. És ami nagyon jó, az AMD-s technológiákra alapozták tudvalevő, hogy az AMD-s GPU-kat sokkal nehezebb optimálisan programozni. Így most lesz egy olyan API ami ezt a terhet is enyhíti. De normális többszálas alkalmazásokat kell írni hozzá. Még nem foglalkoztam a programozásával, de ha csak azt megoldották benne, hogy a szálakból ne kelljen szinkronizálni a MainThread felé a GPU-al való kommunikációnál, hanem közvetlenül lehessen, már rengeteg proceszzoridőt megspórol nekünk. Tehát ha van egy olyan csapat, aki jól elsajátítja a Vulcan működését, és így megfelelő programot ír alá, akkor sokkal többet ki lehet hozni egy adott gépből mintha ugyanazt OpenGL-el csinálták volna. Ezért írtam, hogy a felhasználónak jó, de a többletmunka miatt a fejlesztőnek már nem annyira. Bár ha eljutnak a munka végére, akkor már nekik is, mert sokkal kevesebbet kell majd optimalizálniuk/javítaniuk. De a fejlesztési költségek a grafikus részen jelen pillanatban majdnem háromszorosa mint az OpenGL-nek.
Minden cégnek van folyamatábrája a fejlesztési folyamatokra ami elég bonyolult (a mienk A4-es lapra nyomtatva, majd összeragasztva majdnem 6 méter:)). Amit felvetettél A és B verzió is. Ha átment a "hülyeség szűrőn" nyilván először meg kell állapítani, hogy kihez tartozik, kell-e javítani vagy csak paraméter, stb. Azután prioritást kap a feladat. Mielőtt a programozóhoz kerül meg kell állapítani, hogy külön javítás vagy betudható a mostani feladatai közé és úgy kapja meg. Ha végzett a "nullás teszttel", a tesztelés következik aki vagy átengedi vagy visszadobja vagy közvetlenül a programozónak, vagy feljebb a szervezőknek/tervezőknek. Akik vagy dolgoznak vele, vagy feljebb dobják. Ha kész, még ott builder és kiadásfelelős, ott dől el, hogy melyik kiadásba kerül. Azután a kiadást tesztelni, és ha túlélte az összes visszágat, mehet a felhasználóhoz. De a kiadásból lehet visszalépés a döntéshozók felé is.
SPOILER! Kattints ide a szöveg elolvasásához!Van egy kollégám (eredetileg programozó) akinek a vállalati folyamatszabályozás a szakterülete. Hát elég gyorsan öregszik. Általában amikor kimegy egy céghez kiderül, hogy nem a beosztottakkal van a baj, hanem inkább a középvezetéssel, időnként a felsővezetéssel is. A vezetőkkel ezt elég kíméletlen feladat lenyeletni. Nem egyszer a felmérés után azt mondják, hogy köszönik szépen. De ha megfelelően kezelik a problémát, akkor is kell legalább fél év mire a vezetők és beosztottak is belátják, hogy szervezettebben jobb nekik. A beosztottak eleinte ódzkodnak a "kötöttebb" munkavégzéstől, de amikor látják, hogy sokkal nyugalmasabban/tervezhetőbben dolgoznak, a szabadságok is sokkal jobban tervezhetőek, rugalmasabbak, akkor megszeretik a rendszert. Nem egy dolgozó maradt meg a munkahelyén aki el akart menni, mert nem bírta a káoszt. És az a röhej, hogy ugyanazt csinálja mint régen, csak most már szervezettebben, így sokkal több ideje marad. Nem kell olyan problémákkal foglalkoznia ami nem tartozik rá. Egy csomó cégnél felvesznek egy auditort akinek csak az a feladata, hogy a cégnél betartassa ezt a folyamatot. A szervezettség simán kitermeli a munkabérét. -
Jóózsf István #2445 Az első benyomásom a vulkánról az volt, hogy ...kipróbáltam egy játékot, (Talán a Doom volt...) gondolván úgysem fog menni, mert kevés hozzá a gépem/vga-m. De csodák-csodája hasított, mint a szél! Azóta HISZEK benne! 
Amikor kiderült, hogy az X4 is azzal fog menni, már hirdettem is az igét, hogy; "Nekünk az jó lesz!"
Mondjuk azt az esetet, amikor 100%-on küzd a vga egy "üres" szektorban, pusztán csak azért mert köd van, és közben "330 wattot" fogyaszt... Szóval, ilyenkor nálam is megjelennek a kérdőjelek! (Figyeltem az órán tanár úr! Tudom hogy ezek csak kirakat számok, de valami alapja csak van!)
Közben mégiscsak felkerült a hibalistára a szállítóhajó sztrájkom. Valakinek volt egy hasonló problémája, én meg kapva-kaptam az alkalmon és odabiggyesztettem egy magyarázó videót. Így már ennek is van tikettje!
Persze nem emiatt, de lesz 2.60 béta 3 is, ami alaphangon még két hét pihenés nektek.
Veszettül kíváncsi vagyok, hogy ilyenkor mi történik az ego-nál! Kivételesen nem kritizálni akarom őket, csak érdekelne a menete a dolgoknak.
Ugye kábé két hónapja, nagyjából nyomon követhető, hogy vadul dolgoznak... (Lehet, hogy az előtte levőben mégvadabbul...) Tíz napja van kint a publikus béta 2.60 aminek minden verzióját egy hétig hagyják... Na ezek a számok érdekelnének. Az az egy hét sok, vagy épp kevés? Mi történik az egy hét alatt? Azt látom, hogy két max három nap alatt befut az összes hibajelentés. És aztán?
Úgy képzelem, hogy összeülnek az illetékesek, megvitatják, hogy szerintük mi okozhatja, kipróbálnak néhány változatot a módosítások közül, majd visszadobják nekünk (Béta 2, 3, etc)
"B" verzió, minden egyes hibának megvan a maga embere, nyilván aki készítette azt a részét a játéknak és vagy koordinálta a "bedolgozókat", aki leül, rágyújt, bont egy sört, kicsit sírdogál, hogy már megint nem megy ez a szar, Változtat egy-két értéken és...
Persze a képzelet, főleg az enyém, kissé más utakon jár, mint általában az embereké.
-
nibron #2444 A fejlesztőin semmiképp, mert egyrészt nincs még akkora rutin (egyelőre szinte semmi), másrészt a Vulcan-t programozni sokkal bonyolultabb, úgyhogy a költségek csak nőnek. Viszont sokkal jobban (egészen alacsony szinten) bele lehet turkálni mint az OpenGL-eknél. A felhasználóknak sokkal előnyösebb lesz, mert a többmagos rendszerek támogatottsága GPU és CPU oldalon sokkal rendszerezettebb. A többkártyás grafikából biztos sokkal többet ki lehet majd hozni mint most.
Az, hogy az ego miért tér át azt nem tudom. Logikusan akkor művel ilyen változásokat egy cég, amikor "lyukas órájuk" van. Tehát nagyjából kész vannak. Ilyenkor már csak a javítások vannak, könnyen lehet nyitni egy új branch-et, és abban megcsinálni. De szerintem az ego baromira nincs kész. Pluszban beterhelni a srácokat nem biztos, hogy jó ötlet. De hát nekik kell tudni.
Nem követem az NMS-t, de úgy "tudom" egész jól kikalapálták. Ha ez így van, és lehet egy kicsit hátradőlni, akkor részükről logikus.
Előbb-utóbb mindenkinek érdeke lesz, mert a hardware-k abba az irányba tartanak ami a Vulcan alapja, az OpenGL pedig kifulladni (lassan elbattyog felette az idő) látszik. Elég sok korlát van már benne. -
tomonor #2443 Szerintem ide nem téved olyan "random" látogató, akit ez zavarna. -
TokraFan #2442 Magam részéről nagy érdeklődéssel olvasom mindhárom témában írt hozzászólásaitokat (hardver, szoftver, X3/X4).
Ha másokat zavar (mondjuk nem tudom kit), akkor max. tegyétek Spoiler alá, de nekem személy szerint az sem kell.
Egy kérdés: Vulcan Api-ra vajon miért váltott az Ego? (közben a No man's sky is). Felhasználói oldalon is jelent ez előnyt, vagy inkább fejlesztőin? -
Jóózsf István #2441 Szétoffolni a néma csendet?
Ha peregnének a hozzászólások és zavarnánk másokat, akkor azt mondanám, hogy jah. Per pillanat csak azért lehetünk zavaróak, mert aki benéz és látja, hogy született hozzászólás, joggal hiheti, hogy a játékról beszélünk, és esetleg csalódott lesz!
Sag schon! -
#2440
ha egyszer gépet újítok,piszkálhatlak tanácsokért ?:D -
nibron #2439 Ez a probléma, kizárólag a nép által összeállított PC-kre igaz néhány kivétellel. De a kivétel is inkább a márkásított PC-kre igaz. Előfordul, hogy a legprofibbaknál is beczúszik 1-2 hiba. A szervergépek sokkal alaposabban vannak megtervezve, ott inkább csak olyan probléma fordul elő, hogy a gépet nem a neki kitalált funkcióra használják. Pl. egy Oracle adatbáziskezelésre belőtt gépet, nem lehet webszervernek berakni, vagy adatközponton távoli alkalmazásokat futtatni. A szervereknél ráadásul elég jól működik a vízszintes skálázás, így ha egy webszerver vagy alkalmazásszerver kifullad, simán be lehet rakni mellé másikat. Egészen más világ.
Azért nincs a köztudatban, mert laikus számára feldolgozhatatlan információ. Szakemberek is megszenvednek vele, mert rengeteg infóból kell kiszűrni az adatokat. Egy PC-nél a szóbajöhető processzorok adatlapja (néhány ezer oldalból kell kiszedni pár adatot), az alaplap északi és déli csipjének az adatlapja, a gpu adatlapja, és az összes fontosabb elem adatlapja. Ezekre pl. még a szakmai értékesítőket is képtelenség kiokosítani, marketingesekről pedig már ne is beszéljünk. Ezért ki kellett találni egy olyan rendszert amit a nem szakemberek is "értenek".
Az órajelekbe jobb ha nem megyünk bele. Egyrészt már így is szétoffolunk, másrészt végtelen történet ami állandóan változik. Leírok egy "rövid" nagyon leegyszerűsített történetet, csak a CPU memória viszonylatáról.
SPOILER! Kattints ide a szöveg elolvasásához!Szóval 90-es évek eleje,közepe. CPU a 486/33 vagy 486/66. Ha egyszerűsítünk, akkor az látszik, hogy 1/3-as órajel osztásokat/szorzásokat kell használnunk. Ekkoriban a memória vezérlését teljes egészében a North Bridge látta el. Órajel, interface, mindent. A memóriáknak 3-al osztható órajellel kellett működniük. És ez így jó is volt egészen addig, míg meg nem jelentek a 486/80 és 486/100-as procik. Ugyanis itt már 1/2 volt az osztás/szorzás. És erre is készítettek memóriamodulokat. Megjelentek olyan alaplapok amelyek mindkét procival, memóriamodullal "működtek". De ha procit cseréltél 486/66-ról, 486/100-ra cserélni kellett a memóriát is. Az idősebbek emlékezhetnek rá, hogy ez volt az az időszak amikor baromira oda kellett figyelni mit rakott az ember a gépbe. Ez az órajelmizéria áthúzódott a Pentiumokra is és egészen a Pentium-III-as megjelenéséig tartott. A Pentium-II-esban már bevezette az Intel a teljesítményszabályozó modulokat, így az órajelek sokkal rugalmasabbakká váltak. Igenámde megjelent egy új probléma. Az órajelek oszthatósága elcsúszott egymástól. Még mindig a NB állította elő a memória órajelét a procihoz hangolva, de a memóriacsipek nem azokra az órajelekre készültek. És mivel az SDRAM technológia alap ökölszabálya a megfelelő órajel (később a DDR technológiáknál ez még jobban kiéleződik a burst miatt), a proci viszont szabadon változtatta a működési órajelét, ez látszólag kezelhetetlen lett. Úgy oldották meg, hogy ha a memóriacsip 133 vagy 166 MHz-es, és a proci olyan 2-el osztható frekvenciát követel ami nem osztható 3-al, akkor extra késleltetési ciklusokat iktat be a NB memóriamanagere (ez pedig újabb problémákat eredményezett a RAM-ok frissítésében, de az másik történet). Ezért úgy kellett döntenünk, hogy nem foglalkozunk az alacsonyabb frekikkel, csakis a csúcstartományok az érdekesek, arra választottuk ki a megfelelő alkatrészeket. Tulajdonképpen ez a mai napig tart. Közben nagyon sokat finomítottak a csipgyártók, megpróbálták egyre közelebb hozni egymáshoz az alkatrészeket különböző trükkökkel (pl. dinamikus késleltetés, a forgalomhoz képest sokszoros órajel). Eljutottunk oda, hogy a NB csak simán megcímzi a memóriamodult, és maga a modul mindent elvégez. Saját órajelvezérlése van, frissítés vezérlése, sor-oszlop (RAS/CAS) vezérlése (innentől van értelme a CLx értéknek (hány órajel késleltetés van a RAS és a CAS jel között)). Viszont azzal, hogy szétválasztották a proci és a memória órajelét, megszűnt az automatikus szinkron a két modul közt. A NB-be be kellett rakni egy szinkron egységet. Ez alapvetően késleltetéssel (mivel mindig a proci a gyorsabb) címezte a memóriát, annak órajelére szinkronizálva. Tehát itt mindig azt kellett figyelni mennyivel megy a proci csúcson, és ehhez kellett memóriát választani, és megint csak az oszthatóságot figyelembe venni (ez van még ma is). Ha ez megvan, akkor lehet a memória egyéb adatait nézni, többek között a CL értéket (bár a frissítési adatok fontosabbak). Közben eljutottunk oda, hogy ami már a szerverekben elég régóta megvan, azok bekerüljenek a sima PC-kbe. Az egyik ilyen a Lane típusú adatkezelés. A CPU-MEM viszonylatban a legfontosabb, hogy kivették az NB-t, és most már a proci közvetlen összeköttetésben van a memóriával (GPU-nként szintén). Sőt ha Quad Channel típusú alaplapod van, és olyan proci ami támogatja ezt, akkor 2 db egymástól független Dual Channel van a lapon ami általában 4-10-szeres gyorsulást eredményez. Itt már teljes egészében a proci végzi a szinkronizálásokat, a memóriamodul vezérlőjének ehhez kell alkalmazkodnia. Már rugalmasabban lehet kezelni a dolgot, de ha a maximumra törekszel, akkor elő kell venni az oszthatóságot. Elég széles spektrumban kaphatóak a modulok, egyáltalán nem biztos, hogy a nagyobb frekijű, de azonos CL értéken szereplő modul lesz a jobb. Gyorsabbnak nagy valószínűséggel gyorsabb lesz, de adatforgalomban lazán elmaradhat a kisebb modultól azért mert az a freki nem felel meg a proci működésének. Arra pedig mindig oda kell figyelni, hogy natív frekvenciát kell nézni, az OC egy más világ, általában több kárt okoz mint hasznot. Nem véletlenül tiltott az OC a szerverekben. És nem a technológiai 3000/3200/3400/3600/3800/4000 MHz-es frekikkel kell dolgozni, hanem a natívval ami 1600-2400 MHz-ig terjed általában. Ha jó a natív illesztés akkor jó lesz a technológiai is. Hát nagyon pongyolán kábé ennyi. -
Jóózsf István #2438 Újabb érdekes téma! Hardverek.
Szóval azt mondod, hogy ha megveszem mindenből a legjobbat és az összetevőket csúcson járatom, az jóeséllyel szar lesz? Ezt így elfogadnám ,mert rémlogikus amit az órajelekről mondasz. De akkor miért nincs ez köztudatban? Mennyit számít a végeredményben? Hogyan lehetne arányosítani, mondjuk egy csúcs gép rosszul beállítva és egy közepes koppra belőve viszonylatában? A sima PC-k körében is van jelentősége, vagy inkább a melós gépeknél, szervereknél?
Órajelekbe kicsit részletesebben is belemehetünk. Ezzel kapcsolatban is van aggodalmam. Per pillanat, ha összeraknék egy AMD-s "csúcsgépet" (méjnsztrím teteje), a memória órajeleken és időzítéseken kívül semmihez nem lenne közöm. A processzor annyival megy amennyivel akar!!! A GPU-k is ezt a trendet követik! Már csak az alplap néhány paramétere és a memória marad. -
nibron #2437 Na igen, ez az 1 szál, több szál értelmezés eléggé bonyolult lehet. A háttérszimulációnak is kell lennie egy master szálnak, ami ugye a komplett folyamatokat vezérli. De ugyanez van az eseménykezelésben is. Ott is csak a MainThread-ben tudunk a Windows-al, sőt a saját moduljainkkal kommunikálni. Az általunk létrehozott szálakban nincs eseménykezelés, mégis alapvető szükség, hogy eseményeket küldjünk a MainThread-nek, a Windows-nak, sőt a további szálaknak is. Erre vannak különböző megoldások (pl. a legegyszerűbb a PostThreadMessage API függvény). Az ilyen jellegű eseménykezelést, a háttérszimulációt meg még egy rakás mindent (újabban az UI is szokott ilyen lenni pl. az animációk miatt) úgy kell elképzelni, mint egy szervezeti diagramot. Tehát legfelül az igazgató, alatta néhány helyettes, az alatt a középvezetés és így tovább. Tehát ha azt mondom, hogy ez 1 szálas akkor az nem helyes, de ha azt mondom, hogy 1 szálon fut, akkor elfogadható. 1 példa: a háttérszimuláció vezet 1 npc autót. Egyenesen neki a falnak ahol felrobban. Meg lehet úgy oldani, hogy ezt megírom egy ciklikus szálban, még akár a MainThread-ben. A régi játékok így is csinálták a sokmagos procik, a fejlett oprendszerek és a mostani fejlesztőeszközök előtt. Mert akkor szinte csak ezt lehetett. Most már úgy írjuk meg, hogy az igazgató csak azt tudja, hogy van egy kocsi (vagy inkább sok). A kocsit egyébként az ig.helyettes vezeti és navigál neki az egyik beosztottja. Amikor nekimegy a falnak akkor fel kell robbannia. Ez úgy történik, hogy megszűnik az ig.helyettes az összes beosztottjával együtt, és az igazgató is kihúzza a listából. De előtte elindítunk egy robbanás effekt szálat, mely ha lefut megszünteti saját magát. Ezzel rengeteg kódolástól megkíméljük magunkat, a kód sokkal egyszerűbb (mivel alaposan szét van bontva) így a hibák száma is automatikusan csökken, és tulajdonképpen már írás pillanatában van egy optimalizált kódunk. További előny, hogy az így megírt kis részleteket több helyen fel lehet használni. Pl. csak pár robbanás effektet kell modellezni, programozni ugyanis újrafelhasználható, sőt egyidőben akármennyi robbanást indíthatok el. Az automatikusan megszűnő szálaknál azt sem kell figyelni, hogy vége van-e a robbanásnak, az a szál dolga. Nekünk csak el kell indítanunk. Ebben az esetben sok modult írunk pici újrafelhasználható kódokkal, míg az ágaztatott végrehajtásnál (régi mód) egy hatalmas méretű ciklust (tele hibával és optimalizálatlansággal), abból kiágazó szubrutinokkal. A több modulos programozásnak pedig még van egy überelhetetlen előnye: a csapatmunka. Több programozó dolgozhat rajta szinte egymástól függetlenül és az őket összefogó projektvezetőnek is könnyebb dolga van. Sokkal jobban leosztható a munka. Az architect tervez, a ledaer összefogja a kódolást, a senior kapja a nehezebb részt, és a juniorok is kaphatnak önálló feladatot.
Na most, az előbb levezett példára mondhatjuk azt, hogy a szimuláció 1 szálas, de a végrehajtás valóban többszálas. Az X3-ban is ez a felépítés volt. Volt egy igazgató akinek a leglényegesebb feladata az alkalmazás többi része felé az illesztés volt. Az összes többi alfolyamatként volt megírva. Az egyik helyettes igazgatta az összes NPC objektumot a pályán, egy másik a játékos dolgait, volt egy natív és egy script végrehajtó (amiből később 2 lett a mod-ok miatti nagyon sok script miatt), azután később a tőzsde is külön szálat kapott. A sztori is ide volt beillesztve, ill. ha felvettél egy küldit, akkor az is.
A tesztértékekből külön doktorálni lehetne, ha egyértelműen egy exact dolog lenne. Egyébként az mert ugye gépről beszélünk, de annyi változóval, hogy nyugodtan lehet állítani, hogy emberi léptékkel nézve nem exact. És ezért eléggé nehéz erről jól értekezni. A fejlesztők egyáltalán nem is használják, teljesen már eszközeik vannak ezekre a célokra. A marketing viszont már igen, mert szót kell érteni a néppel, de az számunkra teljesen használhatatlan infó, elég nehezen is tudjuk kezelni. Ha megnézzük, hogy nincs két egyforma gép, a gépek jó 70%-a csak össze van hányva, az alaplapon lévő hardware/monitor chipek a 30-150%-os torzításaik miatt használhatatlanok, a CPU-ban ill. GPU-ban lévő információs modulok erősen feszültség és hőmérséklet függőek, akkor honnan a fenéből lehetne valami pontosabb értéket kiolvasni? Ezek mind csak ilyen tájékoztató jellegű valamik, inkább csak azért vannak, hogy ilyen is legyen. A fejlesztőeszközökhöz léteznek teljesítménybeállító alkalmazások, ezekkel tudjuk megkeresni a sok időt, erőforrást használó rutint. Kódot is ezzel optimalizálunk, mert a teszt futtatásáról egy igen terebélyes statisztikát kapunk, hogy melyik rutint hányszor hívtuk, mennyi idő volt alkalmanként ill. összesen és még millió ilyen jellegű adat. Pl. külön ki tudjuk mutatni, hogy ha egy rutint ugyanazzal a paraméterrel többször hívogattunk és ez alapján el lehet dönteni, hogy jogos, vagy a programozó lusta/figyelmetlen volt felvenni egy változót (tipikus hiba a lassúságra).
Viszont ezek sem hozzák ki azokat a problémákat amik pl. a hardware-ből fakadnak. Nagyon nagy a választék az alkatrészekből, de amikor össze kell raknom egy gépet ez a bőség rögtön összezsugorodik. Egy alaplaphoz memória a közel 100 fajtából, szerencse ha 5-6 jó hozzá. GPU kártya dettó. És Magyarország rettentő jó alkatrész elérhetőséggel rendelkezik pl. a britekkel szemben. A legtöbb gép úgy van összerakva, hogy nem stimmel a lap órajele a memóriáéval vagy a GPU-al. Vagy a GPU a CPU-al. Vagy mindegyik. Ilyenkor bejön a gyilkos késleltetés a szinkronizáláshoz. Ami csak órajelnyi lehet, tehát ha két felfutó élt össze kell szinkronizálni, akkor n darab órajelre van szükség, hogy együtt fussanak fel. A következőnél megint. Egy mai átlagos gép tele van ilyen hibával. Az a szép benne, hogy az üresjáraton nem látszik, terheléskor pedig szidjuk a fejlesztőt, hogy milyen szar programot csinált. Mérni rohadt nehéz, az előbb leírt elemzők viszont kimutatják, hogy bibi van, és akkor már csak egy megfelelő vill.mérnököt kell szerezni aki rendbe hozza a gépet. Hát ez is a fogyasztói társadalom része.
Utoljára szerkesztette: nibron, 2019.09.21. 01:12:15 -
Jóózsf István #2436 Transport Fever 2-t bétatesztelni esetleg valaki??? -
kisiku #2435 Szép napot!
Látom, sok nagy koponya összegyűlt itt! Tetszik! Nagyon tetszik. Bár én ennyire már nem ásom bele magam, felesleges, én csak a fogyasztó vagyok. De valóban, ahogyan korábban is írtam, fenn kell tartani egyfajta "gazdaságot", körforgást, hogy ne legyen a játék unalmas. Emlékszünk? Ugyanez volt az X Rebirth-ben is. A végcél, a végső "termék" az űrhajó. Minden más erre épül. Ha nincs hajó, leáll a gazdaság. Egyébként (sajna) a valóság is ilyen. A Xenon állomások visszaépülése/építése is ezért van, habár különösebb funkciójuk nincsen, kivéve a hajógyáruknak.
Az utóbbi időben egyáltalán nem foglalkoztam a játékkal, időnként benézek ide, nekem most már a valósággal kell foglalkoznom, mivel durván egy hónap múlva már egy másik földrészen fogom napjaimat tengetni.
Én meg türelmesen várok, majd lesz ebből valami, de kicsit félek is, hogy kevesebb időm lesz erre. -
Jóózsf István #2434 Ez annyiban módosult, hogy mire felvettem volna egy videót, hogy bemutassam (Lejelentsem az EGO-nak) A java meggondolta magát, és mégis dolgozni kezdett. De még így is, (Főleg a hajógyárak hajói) maradtak pihenőállásban! -
Jóózsf István #2433 Nnnna! Ezt most vettem észre. Tegnap léptünk 2.60 béta 2-be és valamit nagyon elbaltáztak a srácok. Az összes szállítóhajóm, ami ki van rendelve valamelyik gyárhoz, ÁLL. Konkrétan nem csinál semmit. Dolga lenne, mert raktárat tölthetne, vagy el is adhatna árut, de "NINCS KEDVE" A viselkedés - tevékenység (Behavior) listában semmi parancs! Csak egy általános: "Default behavior: Auto Trade"
Ezen a képen ugyan, az látszik, hogy teljes a lista, amit SZÁLLÍTHATNA ha dolgozna, de ez már csak azért van, mert kivettem és visszaadtam a gyár alkalmazásába. (De ez sem segít a problémán!)
A dolog attól lesz még érdekesebb, hogy az NPC hajók szépen teszik a dolgukat, sőt, el is végzik az én hajóim helyett a munkát. Tulajdonképp ugyanúgy fel vannak töltve az üzemek, ugyanúgy el van szállítva a késztermék...
Attól még ez így nem jó! A franc se akar száz darab ácsorgó hajót bámulni!!! -
Jóózsf István #2432 "háttérszimulációt (amit szintén illik több szálban megírni). "
Ezért kérdeztem, hogy ugyanarról beszélünk-e, amikor több szálat emlegetjük, mert azt tudjuk, hogy az X játékokban a háttérszimuláció egy szálon fut. Ez konkrétan le van írva, vagy ki van mondva. ( már nem emlékszem, hogy olvastam, vagy a jücsübön egy fejlesztő szájából hallottam)
Meg azt is mondod, hogy a rendelkezésükre áll a többszálas megoldás! Akkor miért nem használják?
Az is érdekes, hogy a Ribörsz ebből a szempontból jobb volt, mert ott látszik szépen, hogy a processzor minden SZÁLA (!) szépen félgőzzel dolgozik! Itt már (X4) jóval kiegyensúlyozatlanabb a helyzet! Ezen a videjjón szépen látszik is amiről beszélek. (Jobb oldalt a zöld értékek. Második blokk fentről a processzor szálainak a terheltsége. Bocs a szájbarágásért!) Akkor van terhelve minden szál, amikor valami akció van a képen (18:05 szétrobban egy aszteroida.) Egyébként az látszik, hogy a terheltebb szálak kábé 50%-on a többiek meg 0-20%-on mennek. Hogy miért csak 50, arról vannak elképzeléseim, de most nem mennék bele. Valószínűleg csak a kijelzés lassúsága - pontatlansága miatt mutat csak ennyit
![]()
Ezt csak a játék idejére indítottam el, egy-két percre.
Aki nem ismerné, HWInfo.
Az első oszlop az épp aktuális terhelés a második a valaha mért minimum, a harmadik a maximum a negyedik az átlag.
Szépen látszik, a harmadik oszlopban, hogy az oprendszer teszi a dolgát, mert minden magot járat valamennyi ideig, aztán átteszi egy másikra... Az sajnos szerencsétlen, hogy az aktuális oszlop nem így néz ki játék közben mert a kép készítésére taszkot váltottam. Az ezen a képen jobban látszik.
Szóval: Ha elméletileg meg lehetne írni a játékot jól, és most már az is bebizonyosodott, hogy el is lehet adni jópénzért, akkor miért szopatnak 20 képkockákkal másodpercenként? (ha ráküldöm a SETA-t lemegy 6-8-ig is!
)
-
TokraFan #2431 Na így már minden világos! Köszönöm a részletes választ, már régen is szerettem olvasni az X3 fejlesztési sztorikat tőled! :-D -
nibron #2430 igen, a MultiThread az az 1 process-en (ez az alkalmazás) létrehozott és futtatott több szál. A Windows ún. eseménykezelést használ szinte mindenre, és ezt mindenképpen az ún. MainThread-ben teszi. Ebből a szálból kell minden időigényes feladatot eltakarítani ahhoz, hogy alkalmazás válaszképes maradjon. A bevitel, a grafikai megjelenés meg nagyon sok minden időzítve van az eseménykezeléshez ill. az alkalmazás eseményekkel "kommunikál" egy csomó eszközzel. Ha leterhelem a MainThread-et és ezzel akadályozom az események realtime kezelését, akkor problémák léphetnek fel. Pl. a legegyszerűbb és te is találkoztál már vele sokszor, hogy klikkelsz valamire és nem reagál azonnal. Vagy ugyanez a billentyűvel. Ott valaki berakott egy hosszú folyamatot az eseménykezelésbe, ezért időbe kerül míg átverekedi magát, és végrehajtja az általad kiváltott eseményt. Ezt és az ilyen jellegű a problémákat megfelelő szálkezeléssel lehet javítani, olyannyira, hogyha az összes mag leterhelt, az eseménykezelő még mindig zavartalanul fut. Az ellenkező, 1 szálas esetben akár pár %-os proc.terhelés mellett is ki lehet nyírva az alkalmazás eseménykezelője. És ez még csak az eseménykezelés. A directx-ben nagyrészben kikerüljük az eseménykezelést, mert az nagymennyiségű adatkezelésre nem alkalmas (alapvetően a kernel korlátozott memóriahasználata miatt), itt már inkább a DMA-t használjuk, ehhez viszont mindenképpen kell egy mindentől független kezelő szál. Itt állítjuk be, hogy pl. milyen területeket kell átmozgatni a graf.kártya felé feldolgozásra. A processzor nem várja meg a végrehajtást, a DMA majd szól ha végzett az összessel. A renderelést mindenképpen külön szál(ak)ban kell megírni, mert elég sok processzorműveletet igényel és nem terhelhetjük vele, pl. a háttérszimulációt (amit szintén illik több szálban megírni). És akkor így összejön néhány 10 szál amiket a magokon értelmesen el kell osztani. Itt már azért kapunk rendesen segítséget az op.rendszertől, pl. simán meg lehet olyat is csinálni, hogy amikor egy erőforrás igényesebb algoritmus végzett és ezzel mondjuk nagyjából fel is szabadul az a mag, akkor az op.rendszer úgy "dönt", hogy egy nagyon leterhelt magról átteszi az unatkozóra egy szintén erőforrásigényes szálat. Így gondoskodik a magok minél egyenletesebb elosztásáról. Ez régebben nem így volt, a programozónak kellett odafigyelnie. Akkor nagyon nehéz volt a futást optimalizálni, de most már szinte ki van nyalva a seggünk. Mind a fejlesztőeszközökkel mind az op.rendszerrel.
És hát az egyik legfontosabb. Ha egy többmagos processzoron futtatsz 1db 1 szálas alkalmazást, esélyed sincs, hogy teljesen kihasználd a processzort. Kb. max. 25-30% egy i7-esen. Mert az igaz, hogy az egyik magnak kigúvad a szeme, de a többi unatkozik. Ezért az ilyen alkalmazásnak szét kell osztania a feladatokat részfolyamatokra, hogy a procit optimálisan használja, és így a feldolgozási idő is rövidebb lesz.
Nálunk a cégnél 3 féle ember létezik: a bácsi, a néni és a bubu. A bubu a friss kolléga más néven Dezső. Külső szemlélő részéről furcsa lehet, hogy egy 50-60 év körüli faszi odamegy egy huszonvalahány éveshez és így kezdi: "Sanya bácsi, lenne itt egy kis probléma!" Nálunk lassan már a "Dezső bácsi/néni" is elfogadott lesz, annyira megszokott. Emellett nagyon sokat magázódunk viccből. -
Jóózsf István #2429 Kábé így képzeltem a részvételedet...
Másodszor említed ezt a többszálas technológiát. Ez nem egyezik a általunk is emlegetett többszálas futással?!?!? (Nem értek a programozáshoz. Egyszer megérintett, volt is róla szó, hogy elindulok az úton, de másképp alakult.)
(Pistabá, mi?!?!?!?!?
Mondjuk már megszoktam... Abban a körben ahol mozgok, elég sokat mondják a "bácsit" A távolkeletiek használják a tisztelet kifejezésére. Van amikor csak ennyi a megszólítás: Bácsi figyelj... Szerintem valaki a bevándorlási hivatalban ezt elmondta, hogy ez egy tisztelgő szó és valahogy beégett nekik!)
Jótanács mindenkinek! Ha és amikor, vagy aki játszik a játékkal nézzen rá a bányászhajók drónkészletére, mert lehet, hogy már nincs nekik elegendő, vagy akár egy se!!! Anélkül meg macerás gyűjtögetni. (Elhagyják, lelövik, etc)
Most épp buzgerálják a resuppli lehetőséget így nem tudom eldönteni, hogy ez csak béta hiba, vagy úgy ahogy van nem ér egy kalap szamócát sem a feltöltés utasítás! (én a "B"-re szavazok!)
Utoljára szerkesztette: Jóózsf István, 2019.09.19. 19:58:41 -
nibron #2428 Én csak a Xenonról tudok nyilatkozni. Az egyik játékomban az összes állomásuk el van pusztítva, és a folyamatos elpusztításuk ellenére is lazán grasszálnak a nem Xenon szektorokban. A kiürített vagy volt Xenon szektorokban is csak annyi a különbség, hogy időnként megjelennek páran. De a lényeg az, hogy bizony a semmiből. Amúgy szerintem ez elfogadható egy ilyen típusú játékban. De az X3-al ellentétben eddig még csak meg sem kísérelték újraépíteni valamelyik hajógyárat. Az "S"-ek csak a "Xenon Station"-okat építik rendületlenül. Még akkor is ha állandó patrol van a station területén. Ha feltöltik az építkezéshez a raktárat, akkor újjászületik az állomás. A patrol sajnos nem lövi szét a raktárat. Viszont rengeteg "S"-t kinyírnak, de néhány átjut (ált. 3asával jönnek) és idővel feltöltődik a raktár. Utána már csak a kész állomást támadja a patrol. Elég sokáig tart neki szétlőnie, de kis idő múlva megint újraépül. És így tovább. Ha odamegyek és szétlövöm a raktárat, akkor nyerek egy kis időt, de újból elkezdenek "özönleni" az "S"-ek és újrafeltöltik. És hát tulajdonképpen a semmiből, mivel ha csak az EC-t nézzük, honnan szereznek? Solar Plan-jük már nincs, vásárolni meg ugye senkitől sem tudnak. Mondjuk ezeknek az állomásoknak nem sok szerepük van, de engem speciel rohadtul idegesít, hogy betelepülnek core szektorokba, és nem lehet eltüntetni őket. És hát a logikát sem értem, hogy miért ezeket nyomják, amikor értelemszerűen a gyárakat kellene. Értem én, hogy outpost, de hát ebben a formában nevetséges.
@Pista bá: igen néhányan az egyik külsős csapat, de inkább a beszállító lenne a helyes kifejezés. Természetesen support-al. Alapvetően technológiákat adtunk bele. A nagy tömegű adatok indexelés nélküli nagyon gyors kezelése, a tömeges scriptek natív, és így nagyon gyors futtatása minimális processzor igénnyel akár egyidőben(multithread) technológiák jó pár játékprogramot segítettek már ki, főleg mert először játékcélra lettek fejlesztve (16 éves korom óta fejlesztek játékot ill. a részeit, ez a hobbim is). Az ügyviteli alkalmazás (pl. táblázatkezelés) illetve a mikrokontrolleres környezetekben való alkalmazása csak később jött, Mostanában integrálódunk a neurális hálózatok algoritmusainak felhasználására (élőlény felismerés, környezet felismerés, ilyenek) mikrokontrolleres környezetben, mert piszok nagy igény van rá. Mindenki nagyon sokat dolgozott. Minden forrás, leírás ott van az ego-nál, és tulajdonképpen bármit csinálhatnak vele, csak nem adhatják tovább. Azt kell mondani, hogy az ego fejlesztette a teljes X-et. Csak volt némi külső segítség. De azt meg minden cég igénybe vesz. Mi is elég sok céggel állunk kapcsolatban a fejlesztéseink okán. Sokkal egyszerűbb és költséghatékonyabb megvenni egy technológiát, mint újrafejleszteni és annak részleteire még külön figyelni. Ez egy ilyen szakma. A repülőgépeket sem a Boeing és az Airbus gyártja. Ők szerelik össze és az ő nevük alatt fut, de kis kivétellel nem ők gyártják. Pl. az A380-as futóműhöz szükséges rugókat egy magyar fémipari cég (ők az egyedüli cég a földön akik az előírásoknak/elvárásoknak megfelelően tudják előállítani). A tervezés folyamán is több ezer külső cég vesz részt.
Utoljára szerkesztette: nibron, 2019.09.19. 16:54:27 -
Jóózsf István #2427 Nem feltétlenül. A BIO-kra igaz is lehet! -
mindero #2426 Én csak azt nem értem, hogy a beharangozóban ez volt: az "X4ben nem teremtődnek a hajók, hanem mindegyiket egyedileg gyártják le hajógyárak". Akkor ez egy jó nagy kamu? -
Jóózsf István #2425 Ez elszomorító! Persze, az sem lenne jobb, ha elfáradtak, vagy belefásultak volna, de akkor legalább lenne remény, hogy megrázzák magukat és megcsinálják jól. Akár csak a következő részt. De így, azt kell gondolnom, hogy tulajdonképp nem is képesek rá. Továbbá buktam azt a mondatot is, hogy: "Bezzeg az X3-ban...!" Merthogy az X3-mat tulajdonképp nem is ők csinálták!
Francos franc! A macska rúgja meg!
A láthatatlan világról is csak kellemetlen gondolataim támadnak: Nem reális, nem befolyásolható, és még azt is számolhatja a processzorom. Persze ez buta gondolkodás lenne, hisz mindegy, hogy mit számol, ha egyszer számolnia KELL!
Szóval; Te külsős voltál az Ego-nál? -
tomonor #2424 Kérdeznék: ki vagy te ám végülis? :D
Egosoft-os dev, aki láthatólag tud magyarul, vagy csak 'bennfentes'? -
nibron #2423 Már az X3 peccselései (kb. a 2.30 körül) alatt megváltozott az a management amely a játék fejlesztéséért felelős. Jött 2 faszi aztán még1 akik semmit sem tudtak az előzményekről, és a mítingek során kiderült, hogy nem is érdekelte őket. Nem ismerték a fejlesztőeszközöket és úgy általában semmit. Viszont a hozzánemértést rettentően tudták kompenzálni azzal, hogy nagyon agilisek voltak. És innentől romlott meg eléggé a hangulat. Elkezdtek kivonni a projektből fejlesztőket azzal, hogy ők fogják az új játék gerincét megcsinálni. De alapvetően nem szakmai szempontok döntöttek, hanem inkább ki hogyan nyalt nekik. Kicsit megkeverték a munkaköröket is (ezt legjobban a katonasággal tudnám érzékeltetni: a mai napig az egyik legjobb haverom a Géza volt a főszakács, aki polgári életben esztergályos. Aki a műhelyben a forgácsolásért volt felelős ő viszont festő volt. Ezek után gondolom a szakács volt a festő. Én egyébként elektronikai műszerész végzettséggel voltam az autószerelő leszerelésig). Na most az X3 alapjait többnyire külsős segítséggel írták, a core-t de még a fejlesztő eszközöket is. A belső logikát szinte teljes egészében. Viszont a külsősöket elkezdték kiszorítani, ezért szépen lassan leléptek. Számukra nem okozott gondot, végülis az általuk fejlesztett technológiákat elég sok helyen fel lehet használni. Így jártunk mi is. Nekem pölö teljesen mindegy, hogy játékhoz vagy ügyviteli alkalmazáshoz írok logikát. De ott született meg a natív végrehajtású több thread-es scriptrendszer. Amit még a mai napig is használunk, persze már alaposan átdolgozva (az egyik slágerünk). Vagy az objektumorientált dinamikus adatkezelés (ego ezt pl. még használja ahogy elnézem) amit szintén használunk a mai napig (ezt most kellene átdolgoznom, ha lenne időm rá, mert nagy rá az igény). De az ego elérte azt, hogy ott maradt azokkal akik ott maradtak. Ha csak azt nézzük kik maradtak a koncepciós csapatból már akkor rögtön levágható a helyzet. Közel sem azok akik a szekeret leginkább tolták. És ők ezt tudják magukból kipréselni. Elég nagy rejtély számomra, hogyan tudták pl. a graf.motort így összehozni. Gondolom már érted mi lehet a probléma. A külön csapat mindenkitől függetlenül elkezdte a rebirthöt fejleszteni, a fene se tudja mit vittek át az X3-ból, vagy mit tudtak átvinni.
Pista: A Xenonok sem teremtődtek, hanem ott az M0-ás teremtette meg. Oda kellett mennie a közelbe és csak akkor keletkezett. A Xenonok annyi engedményt kaptak, hogy ők az ellenséges szektorba is telepítettek. Ez kellett is, mert mindenkivel fasírtban vannak, és ha elfoglaltad a szektorukat, csak így tudták visszaszerezni.
Kiirtásról: alapvetően nem a pálya a teljes galaxis, hanem csak az általunk bejárható vagy inkább ismert része. Tehát nem a teljes galaxist látod, hanem csak egy kis részét. Ergo ha "kiirtod" valamelyik fajt, akkor nem az összeset irtottad ki, hanem csak az általad ismert rendszerekből az összeset. Tehát a nem ismert néhány millió rendszerben azért még ott lehetnek. Na onnan jönnek. Egy nincs vége játéknál ezeket a lehetőségeket fenn kell hagyni. Szó volt róla, hogy ha a játékos kiírt egy fajt a pályán, akkor az a "visszacsurgás" helyett inváziós flottával térjen vissza. Végül is akkor már a játékosnak kell annyira pengének lennie, ha sikerült egy fajt teljesen kiirtania. De elég sokat kellett volna programozni, illetve már beálltak a fentebb leírt állapotok, így ez is ment ad acta, többek között a dinamikusan táguló pályával együtt. -
TokraFan #2422 Én azt nem értem, hogy ha az X3 olyan jó volt mint amilyen, akkor miért nem vették azt alapul és építkeztek tovább belőle, kijavítv az X3 hibáit? Bár nem játszom a játékkal, de abból amit írtok, nekem az jön le, hogy a Rebirth-be bróbálnak most utólag beleerőltetni egy kis X3-at, ami hol sikerül, hol meg nem. A team elvileg ugyanaz mint az X3 esetén, vagy tévedek? Ha ezeket a dolgokat már megoldották sokévvel ezelőtt jól, akkor most miért rosszak? -
#2421
én csak belenéztem eddig pár óra erejéig,pár hónapja,de még mindig várom a 4.0t :D -
Jóózsf István #2420 Az újrateremtődést kifejezetten a xenon állomásokra értettem. (X3)
De így sem rossz. Ezeket sem tudtam az X3-ról. Köszönöm.
Mindent összevetve, Kár, hogy ennyire következetlenül történnek dolgok. HA már a témánál vagyunk, akkor például ha egy fajt kiirtunk, akkor legyen kiirtva! (Esetleg bevethetik e Bobby Ewing-os trükköt: Csak álmodtam...)
Így viszont erősen csappan az ember érdeklődése és a lendülete, mivel senki sem szeret hiába "dolgozni". Kiváltképp én! Példát vehetnének bármelyik Fallout-ról! Ott, ha valakit kinyírsz, akkor az ki van nyírva!
Az értelmetlen küzdelem (Úgyis újravarázsolódnak!) nem szórakoztató!
De mintha nem is ezt ígérték volna!?!?! Vagy csak keverem a szektorok birtokbavételével? Mindegy. A lényeg: Kell ennek a játéknak egy gerinc, az szépen megtámaszt és elvezet valahova. Az, hogy hogyan oldjuk meg az odavezető utat, az a mi bajunk! Nem én vagyok ennyire bölcs. Ez az X3. Amit kétszer (vagy háromszor?) is el tudtak adni nekünk. Még csak zúgolódás se volt belőle. Örültünk!
Sokat várok a Split Vendettától. És sokunknak meghatározza majd, hogy folytassa, vagy egyáltalán elkezdje-e a játékot. Itt már nem fog segíteni a hűség, de még a fanatizmus sem!
Baromira kíváncsi vagyok, hogy terveznek-e X5-öt?
-
nibron #2419 Az X3-ban sem teremtődtek csak úgy újra a gyárak. Az adott faj egyik hordozója szépen odabattyogott és kidobta az adott helyre. És az jó eséllyel még csak nem is a régi hely volt. Algoritmus volt rá, hogy telepítéskor mindig vegye figyelembe a jelenlegi helyzetet (rengeteg paramétert figyeltünk, főleg a tőzsde bevezetése után). Pl. ha eredetileg egy Solar Plan volt ott, de időközben a környéken leraktam jó párat, így bőségesen ellátva a környéket, akkor a fegyvergyártáshoz szükséges következő gyártípussal próbálkozott. Ha az sem kellett, akkor vette a következőt és így tovább a csúcs felé. Ha volt mindenből, akkor lerakta a legmagasabb szintű gyárat. De azt is csak akkor ha kellett neki (pl. volt a közelben shipyard vagy equ.dock). A hordozónak is volt kiindulási pontja: ez vagy a shipyard (ahol a gyárakat lehet megvenni), vagy peremszektor ha a fajnak nem volt egyetlen hajógyára sem. De a bepakolt gyár típusát sem változtatta meg. Pl. ha az előbbi példában említett solar plan-el indult el, és mire odaért már felesleges volt az a gyártípus, akkor vagy lerakta (csakazértis), vagy ha tudott ballagott tovább, és akár nem a fajhoz tartozó nem ellenséges szektorban is lerakta a gyárat. Mi ezt mindig úgy teszteltük, hogy ledúrtuk a teljes pályán az összes állomást, visszaállítottuk az eredeti ellenség/barát állapotokat és vártuk, hogy mi történik. Érdekes volt látni, hogy milyen sokféleképpen települnek vissza a fajok.
Az, hogy látod, hogy a hajógyárban éppen gyártanak egy akármit, nem jelent semmit, úgy vettem észre ez inkább csak díszlet. Ha elkészül az a "K", akkor kijön és beáll a csatasorba, de addig jön még 3 a semmiből. -
Jóózsf István #2418 Szépen összeszedted a lényeges tételeket. Valóban az X3-ban mintha "éltek" volna. Ugyan, ott csak simán újrateremtődtek a hajógyárak... Emlékszem ahogy vonultak az Argon terület felé... Nálam két M2-es vigyázott a 101-es szektor kapujára. Nem sokan jöttek keresztül rajtuk!
Itt most láttam ahogy az egyik hajógyárukban épp készült egy "K". Ha nem is semmisülnek meg, de biztos, hogy hatással van az ingatlanjaik elpusztítása a jelenlétükre. A Khaak említésre sem méltó. "Ők" meg az X2-ben voltak nagyon meghatározóak. Sok borsot törtek az orrom alá!
Reménykedjünk... -
nibron #2417 Nekem a játékban már nincs egyetlen xenon szektor sem. Wharf és hajógyár szintén nincs. De xenon hajó bőven van, és ugyanúgy kellemetlenkednek. A jobb felső sarokban leigázták a Teladikat, de hiába nincs már szektoruk ugyanúgy jönnek át a kapun a semmiből. Így azért már látszik a játékon, hogy a xenon bázisokat és a hajók keletkezését/jelenlétét teljesen külön vették a játékban (az X3-ban nem így volt). A szektorokban lévő xenon station-okat is rendületlenül építik újra és újra, rengeteg nyersanyagot hordanak oda, pedig nem is bányásznak és hát ugye EC-t sem tudnak előállítani. Hát a Xenonok már csak ilyenek, ezekkel az apróságokkal nem foglalkoznak :)).
Egyébként már az X3-ban is így volt, de ott úgy lett megoldva a dolog, hogy voltak rejtett szektorok, nem lehetett megtalálni őket, onnan jöttek konvojokban, ha ki lettek már irtva mindenhonnan. Azért a szervezettségük sokkal jobb volt az X3-ban, a konvojok megalkotása és védelme volt az egyik kedvencem. Ott ugrottak be ahol kellett, végigvonultak a "galaxison", közben csak védekeztek ha megtámadták őket, vagy túl közel ment valaki. És amikor elérték a volt szektoraikat megpróbálták újraépíteni a bázisaikat és visszafoglalni a szektort. A fajokkal ugyanez volt. Miután kiirtották őket, a galaxis nem ismert pontjairól ugrottak a peremszektorokba, vonultak, és megpróbálták újjáépíteni magukat. Sőt először csak a felderítők, könnyebb vadászok jöttek.
Az X4-ben a Xenonok elég nyeglék és "csak úgy vannak", ugyanúgy mint a Khaak, utóbbinak jelenleg semmi szerepe sincs a játékban. Annyira, hogy egyetlen bázisukat sem romboltam még le, nem is foglalkozom velük, ha találkozok eggyel csak elmegyek mellette, majd valamelyik állomás leszedi.
A kalózok is faék egyszerűséggel működnek. Véletlenszerűen a kevésbé biztonságosnak tartott szektorokban felszólít már fényévnyi távolságból, azután kb. fél óra múlva odaér és elkezd csipkedni valami szaros puttyogóval, mire én vagy otthagyom a fenébe, vagy néhány lövéssel kivégzem. Egyáltalán nem ellenfelek. Azért az X3-ban ez sokkal jobban meg volt csinálva. Ott pl. inkább csak csapatokban portyáztak. A kalózos küldetések pedig elég jók voltak, ha az ember egy kis mozgalmas lövöldére vágyott.
Úgyhogy attól nem kell félned, hogy nem lesz kire lőnöd. Ez tudatos fejlesztés, csak az X4-ben ez űberbénán lett még megoldva.
Utoljára szerkesztette: nibron, 2019.09.18. 08:27:03 -
Jóózsf István #2416 Egy kis "belső..."
[2.6 Beta 1] Feedback: New Station trade options - Devs on the case.
"Ok thanks guys for the answer, this is really helpful to get a better idea what exactly you want.
We will talk about it inhouse in the next week and then take alook how we continue from there.
It will be nothing for 2.60 and it will be super tight on time for 3.0. Please be patient, the tasklists are really crowded at the moment." -
Jóózsf István #2415 Nem merek játszani, mert a HOP már az utolsó szektorba szorította vissza a "saját Xenonjait". Persze itt van egy kis torpanás, mert a warf-ot és a hajógyárat nem lesz egyszerű törölni! MI lesz velem xenonok nélkül? Kire fogok lődözni?
Ezzel kapcsolatban fel is merül egy kérdés. Elpusztítja őket. Rendben. Kiüríti a szektort, ez ezzel jár! De nem épít oda semmit! (Írhattak volna rá egy skriptet!) Így meg már minek? Elég lenne csak a kapuknál őrt állni, mint ahogy én is tettem még az X3-ban.
Amit mutattam önellátó hajógyár komplexet, ami kifutott az EC-ből... Na annak már a negyedik napelemet biggyesztettem és még mindig nem tud raktárra dolgozni!
Kábé ugyanez a helyzet a grafénnal és a kvantumcsővel!
Akit érdekel; Van eladó bányászhajóm! KB 20 darab! Azzal, hogy megnövelték a kapacitásukat, nálam azt eredményezte, hogy ott álltak sorban a gyárnál, hogy elsüthessék a portékáikat! MIvel én egy tehetős és gondos gazda vagyok, annyi bányászom volt, amennyire szükség volt!
Egyszerűen túl sok lett a duplázás: "Improved mining yield by increasing cargo capacity of mining ships by 100%." Még talán az 50 is túlzás lett volna!??!?! Egyelőre porosodnak egy "csendes sarokban".
-
Jóózsf István #2414 Valaki a béta fórumon megfogalmazta azt, ami tudat alatt zavart, de nem tulajdonítottam neki nagy jelentőséget. Így viszont már nem hagy nyugodni.
A gyáraknál van ugye a Restricted... kapcsoló. Nálam az a helyzet, hogy adok én szívesen, (pézé'!!!) de nem kérek alapanyagot hozzá, mert megtermelem azt is. Namármost, a ribörsz óta, az npc-k képesek áron alul eladni. Magyarán: Hiába húzom le a vételár csúszkát minimumra, akkor is özönlik a refmetál, vagy a szilícium! Apróság, de ha valaki ráfekszik a gazdaság részére a játéknak (mint én) annak bosszantó!
A megoldás: Legyen háromállású a kapcsoló: NEM - csak ELAD - csak VESZ. Et voila!
Másoknak is feltűnt, hogy gyengék a xenonok. Aki le akarja igázni őket, most azonnal iratkozzon fel bétára!
Remélem nem akadékoskodnak sokat a bétások, hogy minél hamarabb túllegyünk rajta. Mert klassz ez a 2.60 de nem hozott semmit. Néhány vicces manőveren kívül amit a nagy hajók követnek el, annak érdekében, hogy ne kavirnyázzanak össze-vissza dokkolás közben. Jamegugye: A gyárak átszervezésén..., mert felborult a termelési egyensúly!
"Szorítsatok"! -
Jóózsf István #2413 Futottatok már ki EC-ből?
Ha valaki azt hitte, hogy csak ahhoz a három termékhez nyúltak, (
Improved balancing and robustness of in-game economy (including prices, volume and production rates of Engine Parts, Hull Parts and Smart Chips).) akkor álomvilágban él! Többek között képtelenség elegendő Fejlett elektronikát gyártani, ami nem egy köztes termék, hanem a hajógyárnak van rá szüksége a hajók összeállításához! 4 üzemegységet építettem a meglévők mellé az önellátó hajógyáramba és még így sem biztos, hogy elég lesz! -
Jóózsf István #2412 Utóirat:
Szőrén-szálán eltűnt Janamából egy "bástyám", amit a Xenon szektor kapujához építettem!
Teljes egészében meghatározhatjuk, hogyan használja ki a gyár a raktárkapacitást: Mennyit termelhet, Mennyit vásárolhat és mennyit adhat el belőle! Egész jó kis ficsőr! (MIután az Automatic... mellől kivettük a pöttyöt, csúszkával állítható az érték.)
Utoljára szerkesztette: Jóózsf István, 2019.09.13. 07:03:41 -
Jóózsf István #2411 Improved Logical Station Overview (added storage allocation, buy/sell limits, module state, production module grouping).
Ezen látszik hogy dolgoztak. Logikusnak is tűnik, hogy ne legyen minden gyáregységnek külön címkéje. Így összevonva számolgatni sem kell gyártási kapacitást...
A nagy hajók mintha céltudatosabban közlekednének. Már-már X3 szintű.
A termelésbe csúnyán belenyúltak. Ami komplexet eddig napokon át reszelgettem, hogy a termelés minden lépcsője egyensúlyban legyen, az most egy merő káosz!
Xenonok mintha gyengélkednének: Több kilőtt Ilonát találtam. Egynél én is részt vettem... Egyértelműen sebezhetőbbek! Gondolom így akarják megoldani, hogy ne kelljen egy VALÓDI M2-es osztályt létrehozniuk! Ha nem, akkor passzolok.
Ezek az első benyomásaim. Majd még megnézek pár dolgot, ha már ilyen hosszú változásjegyzéket készítettek!
Ohhhh! Nem játszottam nagyon régen, épp csak azt felejtettem el, hogy az egéren melyik a tűzgomb! Vagy csak kritikus értéket ért el a szenilitásom!
Utoljára szerkesztette: Jóózsf István, 2019.09.13. 06:40:00 -
Jóózsf István #2410 Csak pár érdekesség:
Improved capital ships docking at stations and movement through gates.
Improved mining yield by increasing cargo capacity of mining ships by 100%. (Ez jótékonyan fog hatni a sebességre is. Van több olyan komplexem, ahol megközelítőleg 10 bányászhajó szolgál...
Fixed ships trying to fly through station geometry in certain situations. Ez meg nehogy visszafelé süljön el. Mondjuk egy végeláthatatlan útkeresésbe torkollva!
Majd referálok. Egyelőre próbálok úrrá lenni az örömömön. Már nagyon kétségbe voltam esve... (És pont tegnap ittam meg a múlthét szerdán hazahozott bor utolját. Pedig most megünnepeltem volna...)
Utoljára szerkesztette: Jóózsf István, 2019.09.12. 16:34:19 -
Jóózsf István #2409 Version 2.60 Beta 1 (363437) - 2019-09-12 (Még én sem olvastam végig!)
SPOILER! Kattints ide a szöveg elolvasásához!
Improved balancing and robustness of in-game economy (including prices, volume and production rates of Engine Parts, Hull Parts and Smart Chips).
Improved Logical Station Overview (added storage allocation, buy/sell limits, module state, production module grouping).
Improved station Info menu (added intermediate wares, filled storage capacities by type).
Improved station-based traders (coordination between traders, selection of stations to trade at, use of cargo that is excess or needed by their station).
Improved pirate behaviour by increasing variety of wares that pirates are interested in.
Improved trader deal selection and cargo space utilisation logic.
Improved automatic resupply by preventing player-owned ships from automatically getting deployables.
Improved ships rearming at resupply ships by only ordering what the resupply ship can build.
Improved upkeep mission priority for ship pilot and station manager vacancies from medium priority to high.
Improved ship combat AI by reducing use of boost to avoid completely draining shields.
Improved ship AI by allowing pilots to target, and be able to destroy, stations that are under construction.
Improved aggressiveness of NPC ships in response to attack when on their way to combat.
Improved range of high-tech wares stocked at most Trading Stations.
Improved long-distance movement to moving objects.
Improved capital ships docking at stations and movement through gates.
Improved build queue processing so newer ships are less likely to jump the queue.
Improved loadouts of small fighters by reducing chances of them using missiles, especially torpedo launchers.
Improved mining yield by increasing cargo capacity of mining ships by 100%.
Improved behaviour of laser towers attacking stations.
Improved station AI by reassigning mining ships told to mine if they no longer need mineable wares when station configuration changes.
Improved carrier combat if carrier has direct subordinates and is directly attacking a target.
Improved ship movement in various situations (including moving through a gate, leaving a local highway in the middle).
Improved travel mode handling while going through gates and into highways.
Improved autopilot travel mode usage.
Improved info menu for station build storage to show amounts and display resources even if build storage currently doesn't have any.
Improved map to allow trade wares without current valid trade offers to be shown on the map.
Improved "ping" effect to be less obtrusive if multiple mission targets are present.
Added ability to assign ships to trade for resources for a station's build storage to assist in station construction.
Added Anchor space for orders AutoTrade, Sector AutoMine, AdvancedAutoMine and Expert AutoMine to the order queue menu.
Added possibility to sell resources and buy products and trade wares.
Added new resource region to Cardinal's Redress to help with Holy Order resource shortage.
Removed Tobii options if no Tobii device is detected.
Fixed stations under construction not being killable when out of sector.
Fixed Xenon asteroid stations not being killable in certain situations.
Fixed target speed matching not working when in relative movement to the target or after having pressed Full Stop.
Fixed destroying pirates that are showing their true colours sometimes resulting in a reputation penalty with the sector's police faction.
Fixed pirates attacking ships even if they are not interested in them.
Fixed pirates sometimes fleeing before attacking after just saying that they will attack.
Fixed space suit not undocking correctly from moving ships.
Fixed fleet auxiliary ships with behaviour to Supply Fleets in a space rather than as part of a fleet not enabling trade offers.
Fixed fleet auxiliary ships not advertising trade offers when subordinate to a station.
Fixed fleet auxiliary ships wanting to dock at themselves to get supplies and repairs.
Fixed resupply orders sometimes resulting in incorrect ammo and units.
Fixed resupply ships told to Get Supplies sometimes trying to purchase more than they can afford.
Fixed Get Supplies order trying to purchase more wares than the ship has cargo space for.
Fixed ships attempting to collect crates with countermeasures although they have no space for them.
Fixed ships being unable to transfer deployables via ware exchange in certain situations.
Fixed ships sometimes fleeing after getting ammunition.
Fixed player-owned ships that need ammo and/or drones in addition to repairs not going to get repairs if they couldn't find a resupply ship that can supply everything they need.
Fixed player-owned ships getting repairs at resupply ships when automatic resupply is Off.
Fixed ships that need ammunition to fight not considering fleet auxiliary ships assigned to supply ships in their sector.
Fixed docked ships given an order to trade or exchange wares with the object they are docked at undocking and docking again.
Fixed ships assigned to mine for stations ignoring blacklist if blacklisted sector is in the same cluster as their station.
Fixed ships pursuing targets to beyond their operational range when not authorised to do so in certain situations.
Fixed various cases of ships trying to do things with objects in other sectors.
Fixed ships getting stuck waiting for an undock clearance that may never come.
Fixed capital ships getting stuck while docking.
Fixed station-based traders sometimes buying at a loss.
Fixed capital ships sometimes moving too close to their targets when attacking.
Fixed capital ships attempting to park at docked fleet auxiliary ships.
Fixed ships trying to fly through station geometry in certain situations.
Fixed incorrect entry movement of ships in Accelerators and, in some cases, Jump Gates.
Fixed carriers ordering subordinates to attack targets that were once hostile when they no longer are.
Fixed wing leaders fighting over orphaned wingmen when taking control of them.
Fixed police ships ignoring illegal wares dropped in lockboxes in response to an inspection.
Fixed ships deciding to open a lockbox when explicitly told not to.
Fixed non-smuggling traders trading wares in areas where those wares are illegal.
Fixed smugglers only trading with non-hostile factions.
Fixed missing restriction for trading with current player ship while docked.
Fixed ships sometimes flying excessively large turns.
Fixed pilots sometimes aborting travel mode without good reason.
Fixed autopilot aborting while still tens of kilometers from the target.
Fixed autopilot aborting when transitioning through a ring highway gate.
Fixed ships entering jump gates and accelerators from the side.
Fixed ships sometimes jumping by many kilometers when the player comes near.
Fixed rare situation that could leave ships docked at wrecked platforms.
Fixed station-based traders selling off existing cargo ignoring faction restriction set on their commander.
Fixed stations missing opportunities to trade with other stations for lack of cargo drones (improves previous fix).
Fixed wharfs and equipment docks not being rebuilt by factions.
Fixed non-factory stations potentially being expanded with production modules.
Fixed blueprints for 8M Standard Dock Area not being obtainable.
Fixed fired NPCs not leaving their post.
Fixed XP gain calculations for combat incorrectly determining force strength of allies and enemies.
Fixed falling through floor when returning from external view.
Fixed problem with re-assigning crew at the ship trader.
Fixed safe deposit box not working if the player has no or little money.
Fixed ware exchange failing if it involves a ship having to dock at another ship.
Fixed guild missions stalling if the mission station was destroyed at certain times.
Fixed money exploit involving build station missions.
Fixed venture platform exploit.
Fixed some cases where dock guidance splines always went through station geometry.
Fixed inactive orders not being greyed out on the map if they are the first order in the queue.
Fixed order queue menu not showing the assignment for fleet auxiliary ships assigned to supply a fleet.
Fixed incorrect map centering when opening it while having a super highway selected.
Fixed "Are you sure?" question in station build menu showing up when closing an empty plot.
Fixed large number of orders breaking the behaviour tab in the map (corrects previous fix).
Fixed selection mismatch in menus with multi-selection when scrolling with keyboard or controller.
Fixed station build menu being unusable due to constant refreshes in certain situations.
Fixed unusable blacklist dropdowns for some resolution and UI scale combinations.
Fixed mission context menu in the map sometimes being cut-off.
Fixed being able to open an invisible menu with Object Info hotkey when HUD and menus are disabled.
Fixed menu crash when restoring a minimised menu.
Fixed menu crash when interacting with the target monitor while it shows a collectible or a crate.
Fixed menu crash in the plot placement section of the map under certain circumstances.
Fixed Radar Display game option not always working correctly.
Fixed Boost Toggle game option not working at all.
Fixed game becoming unresponsive if a ship in a superhighway moves to another ship in a superhighway.
Fixed several performance issues in specific situations.
Fixed several causes of memory leaks.
Fixed several causes of crashes.
-
tomonor #2408 Igen, sajnos mod. Japánul sajnos nem tudok, de úgy illesztették be a cikkbe a modifikált tartalmú képeket, mintha a játék hivatalos része lenne. -
Jóózsf István #2407 Amit linkeltem, annak a cikknek a fordítása...
