X4 - Foundations

Nagyon nem erre számítottam, de ez van. (Version 2.60 Beta 5)

Hibák mindig vannak! Még akkor is, amikor azt mondják/juk, hogy; "Ez menjen már ki!" Persze ezek nem annyira szembetűnők. Meg azért azt is számításba kell venni, hogy itt mindannyian hozzászoktunk már kisebb - nagyobb malőrökhöz, így egyfajta immunitással rendelkezünk. Magyarán: "Észre sem vesszük"!
A béta fórum "tele van" olyan "jelenségekkel", amikre egy átlag, vagy figyelmetlenebb ember, nem is gondolná, hogy az hiba.

Hogy szép, vagy sem? Az ízlés részéről hiába is próbálunk beszélgetni. Technikailag: 4K-ban: Gyönyörű! Akkor szoktam sírvvafakadni, amikor valamit felveszek és visszanézem. Mivel a gépem arra már nem alkalmas, hogy 4K-ban rögzítsen. (Ilyenkor minden szál 100%-on izzad!!!!) FHD-ban nagyon más! (Nekem)

Végleges verzió???? Hááát?!?!?! Ezt is kétfelé bonthatjuk, mert technikailag a 3.0-tól már merem ajánlani, de hogy tartalmilag.... Affenetuggggya!

Az X4 eddigi futása alatt programhibával nem találkoztam. Értem ezt úgy, hogy lehet, hogy volt valami kis apróság, de olyan amit megjegyeztem volna olyan nem. Nekem megfelelő gépem van, és szoftveresen sincs széttoszva, a teljesítmény is megfelelő volt. Volt elegendő fps is a hajógyáram közvetlen közelében. Tehát magával a futással, teljesítménnyel meg vagyok elégedve. Kinézet lehetne kicsit jobb is, de elfogadható a jelenlegi (max.-on játszom).
Maga a játék az már teljesen más tészta. Pl. ott vannak a módosítások/tuningok. Mire eljutsz oda, hogy "tuningolj" tulajdonképpen már nincs is rá szükséged. Attól a játékmenettől pedig amivel odáig eljutsz szintén agyfaszt lehet kapni.

Igen,így már értelek és egyet is értek. Az X4-et még nem játszom, csak futottam benne pár kört megjelenés után, de a sok hiba miatt nem rántott be, ezért várok egy közel végleges verziót. Az X3 nekem mai napig az etalon, minden hibájával együtt, és persze mára elavult, de játékélményben nagyon ott volt annak idején.
Utoljára szerkesztette: TokraFan, 2019.10.08. 13:32:12

Aki minden kavics alá benéz? Akkor biztos játszottál a Fallout-okkal! Ha nem, akkor sürgősen kezdd el.
Most én is a New Vegas-al múlatom az időt. Kívülről tudom az egész játékot, (Negyedszer játszom végig) de ugyanolyan csillogó szemmel ülök előtte, mint elsőre! Módosítások és csalás nélkül.

Igen igazad van, de csak "jó/nem jó" alapon nézem. Összességében szerintem tökmindegy miért nem jó (balansz, történet, változatosság, akármi).
A modder szempontjából a legegyszerűbb probléma, ha el van paraméterezve a játék és ezért nem játszható. Ilyenkor csak megfelelően vagy saját szájíz szerint paraméterezni kell, nem kell új dolgokat kitalálni, modellezni, stb. Megfelelően balanszolva pedig kaphatunk egy jó játékot. Ugyanez vonatkozik a történetre, és egyéb tartalmakra.
Ismered az eredeti X3-akat. Ha összehasonlítod pl. az Union vanillat (akár a patch-ek nélkül) az X4 vanillaval, te is érzed a 4-es ürességét, míg a 3-sal jól el lehet lenni.

Akkor félreérthető volt valóban, de szerintem olyan játék nem nagyon van, ami alapból sz*r, de modokkal jó lesz. Inkább olyan van, hogy a játék alapból is jó csak hiányos, vagy itt-ott kitolja a képességeit 1-1 mod.

"Az a meglátásom, hogy ha egy játékhoz kellenek a modok, akkor az jó játék nem lehet."
Kis félreértés történt. Úgy értettem, hogy ha 1 játék mod nélkül nem használható rendesen, akkor az nem jó játék.
Kicsit több mint 200 órát toltam bele, ennyi elég is volt, hogy átnézzem (az a típus vagyok aki minden kavics alá benéz). És sajnos utólag inkább úgy érzem, hogy elvesztegetett idő volt. Nem igazán élveztem, inkább éreztem azt, hogy dolgozom, minthogy játszom. Pedig ez az egyik kedvenc játékategóriám. Természetesen a vanilláról beszélek.
MOD-okat, DLC-ket én is rengeteget használok mindenhol, de közel sem erről szólt a hsz.-em.
Utoljára szerkesztette: nibron, 2019.10.08. 00:25:03

Én, mint PC játékos mindig hatványoznám a játékhoz adott lehetőségeket. Érthető, hogy egy projektnek vannak határai, máskülönben szegény fejlesztők addig fejleszthetnék, amíg csődbe nem megy a cég, melyet a saját produktumuk okozott. Itt jönnek a képbe a modok - hiába adja egy játék meg a A;B;C lehetőségeket, ha én úgy szeretném játszani azt, hogy van 'D' lehetőség, miközben ad egy 'B+' és 'C+' lehetőséget is. Ez nem a fejlesztők hibája, ez az én (és a modderek) "kapzsisága".

Szóval igazából nem osztom a nézeted, legalábbis nem a saját szemszögemből. Lehet, hogy létezik olyan játék, melyet módosítani kellett nagy tételekben a játékosbázisnak, hogy játszhatóvá váljon, de az X játékszéria az alapjába véve nem olyan.

Skyrim. Modok nélkül is jó nagyon jó, de semmi ahhoz képest, amit a modok képesek varázsolni belőle.

Ezzel én így nem tudok egyetérteni. Hogy részben On maradjak, az X3R is alapvetően egy nagyon jó játék volt, de modokkal volt igazán élvezhető. Pl. XTM-el. Vagy ugye az ominózus és alapból eléggé rettenetes complex építés, amit modokkal már egészen kezelhetővé lehetett tenni. Vagy ott volt a később Bonus Pack néven kiadott csomag, amiben szinte minden modnak készült eredetileg. Igazság az, hogy a moddolhatóság szerintem nagyon nagy pozitívum éppen azért, mert a közösség kezébe adja az eszközt arra, hogy saját igényeit képes legyen kielégíteni. A játékosok elvárásait nem minden esetben tudja megvalósítani a fejlesztő, de ha van rá mód, akkor meg tudja valósítani maga a játékos.

Másik példa a Cities:Skylines. Eszméletlenül komoly modok vannak hozzá, melyek funkcióit a játék alapból még a hatvanadik DLC után sem tudta hozni, e ettől még az alapjáték is fantasztikusan jó. Modokkal viszont még sokkal jobb lehet.

"Az a meglátásom, hogy ha egy játékhoz kellenek a modok, akkor az jó játék nem lehet."

Hát akkor ezt nagyon rosszul látod.

Vagy nem ért egyet bizonyos paramétereivel. Esetleg zavarja egy-egy elem, vagy megjelenítés. Nem vagyok nagy módosítgató, de egy-kettő nálam is becsúszik. (Transport Fever-hez több mint 500-at használok, de az más! <#bee1> Közben megnéztem, a módosításokat tartalmazó mappa 743 almappát tartalmaz! Nyilván nem él egyszerre mindegyik...)
X3-ban talán csak egyetlen egy volt: No Fog.: Kivakuzta a szemem amikor seta-val közlekedtem egy-egy ködös szektorban!

Szóval; Csak azért használjátok az "Összefutás" módosítást, mert nem akartok találkozni a végtelen ürességben senkivel?

Azon a kutatás dolgon én is elcsodálkoztam, hogy "Csak ennyi" (Bekapcsolom, várok tíz percet és kész?) Lehetett volna rá küldetést, illetve küldetés sorozatot írni...
Ezzel szemben, a hajók tuningolásához szükséges magas szintű alkatrészek előfordulása felettébb esetleges! Erre is van módosítás, amit szemrebbenés nélkül használok. Traders sell modification parts

Az a meglátásom, hogy ha egy játékhoz kellenek a modok, akkor az jó játék nem lehet. A mod-okra akkor lehet szükség, amikor a játékos már érdemben kitolta a játékot, és 1-1 mod-al új színt lehet a játékba vinni.

Ismerem, de én nem szeretem, hogy nekem kitüntetett szerepem legyen, és miattam teleportálja a galaxis másik feléből a hajókat elém, hogy ne tűnjön az űr üresnek. Az űr üres, és így szeretem, ne miattam legyen kint a semmiben valaki, akinek amúgy semmi keresnivalója ott.

Disable encounters helyett van egy jobb mod, ami megváltoztatja az encounterek dinamikáját attól függően, hogy milyen "szinten" vagy éppen a játékban. Simán "Encounters" a neve.

Jó, hogy ezeket leírtad, ha egyszer majd elkezdek játszani ezzel is végre, akkor nem árt tudni, milyen modokat érdemes feltenni. Az X3 is csak modokkal volt élvezetesen játszható igazából, de a legtöbb ilyen jellegű játéknál is használok modokat, mert néha rengeteget dobnak a játékon.

"It gives all upgrades their full power." Meg azt is írja, hogy a felszerelt modokat már nem módosítja, de úgy néz ki, hogy mégis? <#nemtudom> Sosem aktiváltam ezt a modot kampány közben, nekem minden startnál alapból fent volt...

Egyébként ezen kívül én még összesen két modot használok:
- Disable encounters - Kikapcsolja a hajók eléd teleportálását, amikor a szektor közepétől távol repülsz.
- Research Overhaul - A kutatásokhoz különféle árucikkek is szükségesek, ezeket a PHQ raktárában kell tárolni. A hard verziót használom, egészen megváltoztatja a játék dinamikáját, új feladatot tesz a játékba, nem az van, hogy néhány percen belül kifejlesztesz mindent, hanem gyárkomplexumot kell építeni, hogy először a kutatásokhoz ki tudd termelni a szükséges árukat. A hard verzióban brutálisak a követelmények, de a kutatások brutális előnyöket is adnak, szóval szerintem illő, hogy rohadt nehéz legyen őket kifejleszteni. Nyilván új játék esetén van csak értelme ennek a modnak. Kíváncsi vagyok, hogy a 3.0-ban hogyan alakítják át a kutatást.
Utoljára szerkesztette: Pares, 2019.10.06. 11:50:28

Erre azért nem számítottam: Azt gondoltam, hogy majd innentől kezdve, amikor módosítok egy hajót akkor fog érvényesülni a szerencsejáték mentesség. De nem, mert az eddigieket is átírta teljes értékűekre! Az előbb feltett kérdésemre pedig a válasz: Nem választ! Megkapjuk az összes jellemzőt! Tehát amikor az van, hogy még három változás, akkor az valójában (ennél a módosításnál legalábbis!) NÉGY!

BAKKER! Ha én ezt tudom...!?!?!? (Pedig jártam már nexuséknál. Nem is egyszer!)

Már csak az a kérdés, hogy azoknál a fejlesztéseknél, ahol; Mondjuk a fegyvereknél az egyik sebzés módosításnál ugye van még három, vagy négy jellemző amit szintén elpiszkál, és az egyiket váltogatja, talán így: vagy a hűtést, vagy a lövedék ragadósságágát (bármit is jelentsen ez!!!) Vajon hogy oldja meg a mod?
Nade; Meneten kipróbálom és...

Ez a játék egyetlen olyan része, amit utálok, de szerencsére már a kezdetektől van rá egy egyszerű mod: https://www.nexusmods.com/x4foundations/mods/119

Ezen most javítottak! Igaz, hogy kicsit fura - rendellenes lett a hajók mozgása, de gyorsan dokkolnak és nem közlekednek az állomáson keresztül.

Más: Van egy kis lázadás a játékon belüli hajó módosítások miatt is. Megjegyzem: Nekem sem tetszik. Minap öt rombolón alkalmaztam, majdnem teljes moddolást és-hát, mire végig szerencsejátékoztam, már nem voltam "barátságos"!


The current Ship modding system does to put it subjectively blunt s**k.

Now as the strong language is out of the way here my points and reasoning after 3 hours save scumming attempting to mode weapon damage on a single weapon of a Theseus.

I see the mod system as one of the most promising subsystems with a high satisfaction rate just not as it is now.

The current full RNG method does not fit in a game with the possibility of a player to accumulate hundreds if not thousands of ships there is a complete disconnect between achievable and urgency to interact with it on a broader level beyond the odd Player Hero Ship.

The System as it is now fits a Single entity low object to modify game system like X:Rebirth or all to common garden variety looter shooter or looter in general it does not fit a massive scale game like X4 how it is implemented in the current version.

Alone the fact that the player accumulated countless components over time for modifications more then ever could be of use and still is capable to re-roll just by save scumming removes for once the urgency and actual reward of gathering the components.

The sheer amount of potential objects to modify on a player universe scale is completely daunting and unappealing to carry through.
And the fact that the system final interaction is to push a button to spin the proverbial wheel of RNG is unrewarding.

This and the fact that you have to unlock the HQ to even think about the most basic modifications results in players to not care or even know that it is a possibility.

So my points and i know it could end in a lot of work.

Make basic (green mods) available right from the start.
Allow mods to be crafted before they are installed
Have finished mods as reward option to give players a preview of what is possible
Remove the RNG in the mod process
Replace the variable strength of a mod by spending more resources (not money)
split mods in more meaning full groups like equipment modification and actual ship altering modifications that are visible to the player
Add the option to produce mods to specifications
Add the option to bulk produce mods to specifications
Add the option to add mods to ship build templates
Add a whole new industry branch to the game that is centered around mods (tie in for Crystal mining and Nividium etc.)

Those are just a few things that came to my mind after hours of modding ships.

Changes like this would result in the system to be fully transparent to the player and add another layer of game play to be participated or not to be exploited as a business or not.
Having more avenues of long and short term mechanics can only help the game and the franchise in general.

Of course i don't know how others feel about it or even care but i would love to read any opinion pro or contra as i am of the opinion the system needs changed.

ja és a kedvencem, csak azok az NPC hajók látják az állomásiamat amik be akarnak dokkolni, a többi NPC hajó nem látja, neki mennek többször is mintha nem lenen ott, aztán berágnak és lövik...

Azért elég gáz, hogy a mai napig nem tudják elérni, hogy egymáshoz közelítő eredményt adjanak az IOS/OOS csaták. Jó tudom, hogy merőben más a számítás módja ( majdhogynem renderelt ütközés ellenőrzés vs 20d6 :D :D ), és gondolom, sajnos nem is moddolható...

Ez is érdekes. A béta fórumból van!


ow-attention combat is bugged and needs fixing as it leads to exploints and very different balance between weapons when IS or OOS.

1. Turrets are destroyed in OOS combat way fast. Modding community found from tests out that the damage is being applied in its 100% to turrets first and with 100% accuracy. This renders all ships with destructible turrets useless very quickly. Buffing HP of the turrets does not help with it either, they are destroyed very fast anyway.

2. Another major one - DPS is applied in its full to hull, even if it should be shield-damage only. This makes Ion guns the most damaging weapons in OOS.

3. Smaller one - from my tests i did not find a correlation between damage/accuracy of the weapon and its rotation speed/travel speed. SO that a gun with fast projectile hits the target with the same accuracy as with veeery slow projectile. Can this be clarified if its really not used in calculation?

4. Missiles are not consumed in OOS, this makes ships with missile turrets (i look at you Odysseys) very imbalanced. Limited ammo was though as the biggest drawback of the missile turrets, but without its application they are clearly imbalanced.

This also makes game hard to mod, as any new cool weapon idea I come up with breaks due to mentioned bugs.


Ez ugyan egy másik topik, de...


In the current game Pulse M and L Turrets and Guns are the best all-round weapon of course they sacrifice a lot of damage for almost no heat build up good range great tracking nothing bringing more pulse to a fight can't solve.

Bolt is the second best for Ai better in player hands but there is no L Turret Option.

Shard as turret is useless because of the range as everything you want to shot back at out ranges you but it has merit as front mounted gun and the AoE/splash damage.

Plasma turrets are a hard sell good range bullet speed to slow tracking abysmal Ai has a hard time hitting even stationary targets while on the move point blank as gun tho the bullet speed is still a problem that should be looked into but it is supposed okish to fight big and slow targets.

But look at beams ridicules heath build up even if you game the cool down mechanic and perfectly time the release of the trigger inferior range mediocre to bad damage over time ok tracking for M and L Turrets beams need a range buff bad or a damage increase preferred something in the middle.

7km and 5km Beams with the same dps for L and M or 6km and 5km with a bump in dps either as a mix of better heath management or flat damage.

This is all based on how combat behaves and unites compare to each other.

P.S. what was the reasoning to have the Xenon L Pulse turrets have 3 times the damage of the commonwealth counter part while also having a 1km range advantage yet the M Xenon Pulse turrets is more reasonable and just does 2/3rd of the commonwealth counter part while also benefit from a 1km range advantage?


Túl sok érdekesség van. Nem akarom teleszpojlerezni ezt a fórumot. Jó hogy sokan ugyanúgy látják, ahogy én/mi is... Az Ego is belátja, hogy nem túl kiforrott a fegyver specifikáció.

Nnnu! Már béta 4-nél tartunk. Kicsit belehúztak a srácok, mert menetrend szerint csak csütörtökön kellett volna érkeznie. Biztos randijuk van. Vagy nekünk, a 3.0-val és a vendettával... <#awink>

Hehe, most új hülyeség jött be, az ARGON védelmi hajók kilövöldözik a bázisaim védelmi moduljait....
License kifizetve még építés előtt....bárki hasonlót látott már? Repu maxon

Utoljára szerkesztette: Zsolez76, 2019.10.01. 16:27:54

Version 2.60 Beta 3 (365453) - 2019-09-26

Beta 3 Fixed player being able to change assignments of drones thereby making the drones unrecoverable.
Beta 3 Fixed ship state breaking if player takes over a ship that is in the process of getting repairs or supplies at a fleet auxiliary ship.
Beta 3 Fixed multiple cases that led to defence drones being docked without being collected.
Beta 3 Fixed traders subordinate to a station sometimes all becoming dormant when they get a new manager who was transferred from a different station.
Beta 3 Fixed shipyards and equipment docks occasionally recycling themselves if they have economically non-viable production modules (problem introduced in 2.60).
Beta 3 Fixed recycling of modules sometimes returning incorrect amounts of resources (problem introduced in 2.60).
Beta 3 Fixed ships sometimes not being able to move after undocking (problem introduced in 2.60).
Beta 3 Fixed rare freeze in a certain type of mission.

Írtam egy szép novellát a xenonok kipusztulásáról, hiányáról, harcászati építkezésről, - modorról, anyaghiányról, de egy billentyűkombinácó (Nem tudom reprodukálni!) hatására az egész HUSSS, eltűnt. Költsetek magatoknak egyet!

A directX és a graf.API nem ugyanaz. Az API az alkalmazás és a directX közé ékelődik be (ha nagyon egyszerűsíteni szeretnék). A dx12-ben hiába vannak hi-tech szuper funkciók ha nem használom őket. Amikor az alkalmazásból hívok egy directX függvényt, akkor azt érdemesebb az API-n keresztül meghívni (általában és jól felépített modulrendszernél). Ilyenkor vagy az alkalmazásban használok szálat, vagy rábízom az API-ra. Na ez utóbbiban az OpenGL már jócskán elavult. A Vulcan összetettebb folyamatoknál "dönthet úgy", hogy külön szálat hoz létre a feladathoz. Az OpenGL nem csinál ilyesmit. Illetve van pár foltozás benne, amire nagyon muszáj volt arra csináltak "kikerülő" megoldásokat. A dx12 sem fog külön szálakat létrehozni, ha mondjuk úgy döntök, hogy a frame előállítását, az effektek számítását, és a renderelést is 1 szálra írom. Az OpenGl sem, de a Vulcan-al kicsit beljebb vagyok, mert alapvetően külön kezeli ezeket a "funkciókat" ha tudja. Alapvetően AMD-re írták, míg az OpenGL inkább nVidia párti, ezért az ATI-s játékosok sokkal jobban járnak a Vulcan-al mint az OpenGL-el. Nyers erőben az AMD nem tudja felvenni a harcot az NV-el. Későbbiekben a Vulcan viszont azt is magával hozza, hogy az NV is elmegy az erőforrás elosztás irányába, ami meg ugye az nVidia-s játékosoknak jó. A programozók pedig végre megtanulnak rendesen szálakban gondolkodni és az alapján programozni. kb. 2000 környékén kezdtem el rendszeresen használni (azóta támogatják jobb fejlesztőeszközök), és a mai napig küszködök még a senior programozókkal is. Amikor elveszik a drága egy bonyolultabb folyamatban és megmutatom neki, hogy milyen egyszerűen meg lehet írni egy vagy több külön szálban, akkor bólogat, hogy ja. És a következő esetben szintén csak MainThread-ben gondolkodik. Az AMD-nél ez a szemlélet már szinte nem is működik. Nagyon sok olyan játékprogram van, ami nVidia-n szinte tökéletes, ATI-al pedig közel sem az (szinte az összes C#+Unity kombó), többnyire ez az oka. Ha a fejlesztő a Vulcan-ra lesz kényszerítve, elvileg ez a különbség felejtős lesz.
És, hogy valamennyire a témánál maradjunk, az X4-nél is van ilyen különbség szerintem. Nem próbáltam AMD karival, de nekem GTX1070-el teljesen jó, és elég sok helyen olvastam, hogy AMD-el már nem annyira. A Vulcan el fogja törölni ezeket a különbségeket, de az is csak akkor, ha megfelelően van programozva. Magától ez sem tesz csodát.
Utoljára szerkesztette: nibron, 2019.09.27. 11:35:34

Ez hasznos lehet. És a múltkor rosszul is mondtam!!!


For all NPCs, the only skills that matter are their primary skill and Morale.
The primary skill of pilots and captains is Piloting.
The primary skill of managers is Management.
The primary skill of service personnel is Engineering.
The primary skill of marines is Boarding.

The primary skill of an NPC can be combined with that NPC's morale to form the combined skill of the NPC. The relevance of each particular skill in relation to the NPC's combined skill differs depending on the NPC's current position. The relevance of these skills in determining combined skill is defined in roles.xml and posts.xml.

The various combined skills of the pilots and service personnel crewing a ship can further be combined to form the combined skill of the ship. 70/30 split in favor of the pilot's skill.

Various activities use different skills or combined skills.

As discussed a couple of posts above, the maximum range of trading ships and mining ships subordinate to a station depend on the primary skill of the ship's pilot or the station's manager, whichever is higher. Please do not take this to mean that these are the only activities that use individual skills of individual people, there are more.
Some activities such as deciding whether crew members of a ship might bail only take NPCs' morale into account.
Some activities (very few now) take the combined skill of individual NPCs.
And most activities now use the ship's combined skill.

Értem köszi, de a DX12 nem ezt tudja szintén? Mintha azt olvastam volna, hogy a többszálas adatkezelés és a sokmagos CPU-k esetén a hatékony skálázódás az egyik legfontosabb újítása. Bár az is igaz ha jól tudom, hogy az platform függő, míg a Vulcan elvileg nem az.

Korszak alkotó ötletem támadt! Nyugodtan nyúlja le bárki, annak a híve vagyok, ha valamitől a világ jobb lesz, azt nem szabad pénzért adni!
Tehát: Letöltöttem egy módosítást, ami megnöveli a radar hatósugarát. Klassz! Csak az a baj vele, hogy ezáltal jóval több ojjektum került a "szemünk elé" Vagyis tudomást szerzünk olyanról, amiről eddig fogalmunk sem lehetett!!! Mi következik ebből? Igen. A felére csökkent a képkockák száma és a CPU az "üdvözletét küldi"!

Tehát; Tehát: Be lehetne iktatni egy kapcsolót, ami a radar távolságát szabályozná, akár több lépcsőben. Jelen pillanatban kb 40-50 km-re "látunk" hajóosztálytól függően. De ha mondjuk egy sűrűbb területre érünk, ahol nem kell tartani ellenséges támadástól, ("Miért? Van baráti is?") akkor simán levehetnénk akár 10-20 km-re is, ha meg fürkésszük az ÜRES ŰRT akkor fel lehetne tekerni akár 100-ig is. A játék szalad. Mindenki boldog! Dzsob dan!
Maga a mod így néz ki. Erre szerintem egy jóérzésű programozáshoz értő ember pikk-pakk rittyent egy kapcsolót, akár UI-val együtt is!

<?xml version="1.0" encoding="utf-8"?>
<diff>
<replace sel="//dataset<@class 'ship_s'="'ship_s'">/properties/radar">
<radar range="50000"/>
</replace>
<replace sel="//dataset<@class 'ship_s'="'ship_s'">/properties/statistics/max/radar">
<radar range="50000"/>
</replace>
<replace sel="//dataset<@class 'ship_m'="'ship_m'">/properties/radar">
<radar range="100000"/>
</replace>
<replace sel="//dataset<@class 'ship_m'="'ship_m'">/properties/statistics/max/radar">
<radar range="100000"/>
</replace>
<replace sel="//dataset<@class 'ship_l'="'ship_l'">/properties/radar">
<radar range="250000"/>
</replace>
<replace sel="//dataset<@class 'ship_l'="'ship_l'">/properties/statistics/max/radar">
<radar range="250000"/>
</replace>
<replace sel="//dataset<@class 'ship_xl'="'ship_xl'">/properties/radar">
<radar range="250000"/>
</replace>
<replace sel="//dataset<@class 'ship_xl'="'ship_xl'">/properties/statistics/max/radar">
<radar range="250000"/>
</replace>
</diff>


Most már tapsolhattok. Kérdésekre a sajtósom válaszol!

Utóirat: Ha valaki ezt elő tudja adni angolul, (Tomonor? <#beka3>) Nyugodtan terjessze fel a béta vagy a javaslatok EGOfórumban! Én erre nem vagyok elég képzett!
Utoljára szerkesztette: Jóózsf István, 2019.09.23. 11:20:53

Miért érdekes az előző bejegyzésem?

Van egy tüzépem. Ami semmi mást nem gyárt, csak okostéglát és deszkát (Claytronics, hullpart) Ezekből a játékban lehetetlen eleget gyártani! Így unalmamban elkezdtem fejleszteni a tüzépet. Elég nagy beruházás: Újabb tíz okostégla üzemegységet szerettem volna a meglévő tíz mellé, meg felbiggyesztettem három napelemet is, mert az mostanában divat. Jó sok motyó kell az építkezéshez. Főleg okostégla.
Említettem, hogy mostantól lehet szabályozni a raktárkészletet: Hogy mennyi legyen az adott cikkből egyáltalán, hogy mennyit vásárolhat a gyár, ha annál a szintnél kevesebb van, hogy mennyit adhat el a teljes készletből. Így nem csökken egy bizonyos szint alá. Én gyorsan be is állítottam egy párezres mennyiséget, hogy majd abból fedezem az építkezést manuálisan. Igen ám, de arra nem gondoltak a fejlesztők, hogy én ezt a készletet ki szeretném venni, merthogy a gyár NEKEM SEM ADJA ODA!!!!!! vattafakk???????? Ilyet Dáglesz Edemsz nem tudott volna kitalálni, pedig neki voltak elborult ötletei!
Épphogy kiheverem ezt a sokkot, és látom, hogy érkezik a tüzép egyik hajója, és az építkezés raktárába tart!!!
Az a nyomorult, elment egy NPC céghez DESZKÁÉRT!!!! És akkor ne kapjak agyvérzést!?!?!?!?!

A HOP közben kiirtotta az összes Xenon-t Atiya's Misfortun-ból IS. Ennyit a sebezhetetlen hajógyárról. Emlékszem amikor még csak a szomszédos szektorban próbálkozott..., nekem kellett segíteni leszedni a xenonok bástyáját!
Ha megunom a játékot, összerúgom velük a port. Építek egy gigaflottát ás az írmagjukat is eltüntetem a galaxisból! Szép kihívás lenne!

El is felejtettem újságolni, hogy: Közel 500 óra játék alatt most először láttam, hogy egy általam birtokolt gyár hajója hozott az egyik építkezésemre anyagot!!! Kár, hogy nem volt itthon pezsgő. Talán be is s.ggeltem volna!
Már azt hittem szabályt írtak rá, hogy nem lehet saját magamat ellátni...

Tulajdonképp az én munkahelyemet említetted:

Vietnámi vezetés: Két tulaj. az egyik felsőbbrendűbb mint a másik. Ezt onnan tudjuk, hogy mindig az egyiket baltázzák le!
Mondvacsinált vezetők. "Jó, akkor legyél te a raktárvezető! Te meg a kiszállításért felelsz! És itt a felelszen van a hangsúly! Mert változtatni - fejleszteni azt nem lehet! Ennél fogva minden középvezető szarik az egészbe! Az alkeszok meg vagy ugyanúgy beletörődnek és felveszik a ritmust: Annyira kevés munkát próbálnak elvégezni, amennyit csak tudnak... Vagy azt mondják, hogy erre képtelenek és inkább viszik a hátukon a céget, hátha észreveszik és eszmélnek a tulajok. Persze azoknak akkor sem esik le, amikor eléjük állsz, hogy na ez van! Erre valami fa..ggal visszavágnak. Ami lehet akár több éves malőr is. Vagy egy konkrét példa: "Kim-bácsi! Meg kellene oldani a raktár szellőzését, mert nyáron meg fogunk dögleni! - Az már így van tíz éve. Szokd meg!"
És mindehhez csúnyán alulfizetnek! Tele van a cég kivénhedt alkalmazottakkal, akik ugyan tudnának váltani, de ezer éve itt dolgoznak, megszokták a szart. Tulajdonképp nem jó, de nem is rossz alapon nem mennek el. Ez a két jófej, meg kurvára tudja ezt! Reggelig mesélhetnék.
Most épp két hét fizetetlen szabadságon vagyok, mert a rendes már elfogyott (időarányosan) De jó ez így! Nekem megéri. (Nem fizetéstől fizetésig élek!) Csak azt sajnálom, hogy nem egy hónapra mentem. Bár... <#awink>

Na ez már tényleg off!

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

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!<#awink> 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é. <#awink>

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.

Szerintem ide nem téved olyan "random" látogató, akit ez zavarna.

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?

Szétoffolni a néma csendet? <#awink>
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!

ha egyszer gépet újítok,piszkálhatlak tanácsokért ?:D

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

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

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

Transport Fever 2-t bétatesztelni esetleg valaki???

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

Én meg türelmesen várok, majd lesz ebből valami, de kicsit félek is, hogy kevesebb időm lesz erre.

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!

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