37057
Digital Combat Series: World
A DCS World megszületésével a DCS sorozat egyetlen közös magra építve, egy felületről lesz elérhető. Az eddig egyenként telepíthető DCS részek helyett egyetlen közös felületről lesz elérhető, így sokkal könnyebben lehet váltani az egyes kiegészítők között, egyszerűbb és könnyebb lesz a frissítés is. A DCS World folyamatos frissítésekkel, a grafikus rendszer, az AI egységek, AI logika, effektek, stb. együtt fejlődik. Minden ami a szimuláción kívüli repülhető gép, térkép vagy más fizetős tartalom. A jelenlegi DCS World még béta verziós, nem végleges. Az első kiadás ingyen tartalmazza a Flaming Cliffs 2-ből származó repülhető Szuhoj Szu-25T Frogfoot típust.(THX by Sanyo)
*-------*
Nem jogtiszta játék letöltésében, telepítésében és használatában nem tudunk és nem is akarunk segíteni.
Az ilyen jellegű hozzászólások válaszolatlanul lesznek, vagy minden további értesítés nélkül törlésre kerülnek.
HUNAF nyílt facebook csoport KATT IDE!
DCS OFFICIAL fórum KATT IDE!
A DCS HuNAF weoldala KATT IDE!
Szimulátor történelem KATT IDE!
-
#29279
Csak ez a rejtély benne nekem, hogy ha megy a gá, akkor miért nem megy rakétával...? Relatív sebesség és helyzet fontos a mindkettőnél Matt "dumája" alapján.
Az AAM-eknél én csak rendre olvasom, hogy mindig FM hibákat javítanak. Hogy mi cseszi szét az adatokat két patch között az soha nem értettem...
Az AIM-120 SL-en 5 km-nél M0.9 táján azonos sebességgel tényleg ennyire kicsi. Azt nézd meg, hogy mekkora a rakéta által lerepült távolság és akkor mindjárt rájössz, hogy mi a gond. El sem éri a M3.0 szinte a rakéta sebessége és M1.3-nál lényegében már nem közeledik a rakéta és manőverezési tartalék semmi. Tényleg ennyire össze tud menni a kinematikai hatótáv magasságtól, aspektustól és indítási sebességdift figyelembe véve.
R-77-re indítási távolság ábrázolva.
![]()
Ez valószínűleg M0.9 cél és indító sebességnél van 0/180 fokos aspektussal. (R-23-ra ilyen sebesség mellett készült, meg minden másra, mert ez a jó viszonyítási alap.
Tehát ez nem azt mutatja, hogy mennyit repül a rakéta, hanem az indítás pillanatában a távolságot. A SAM HMZ nagyon más. A HTKA-s Haditechnikai összefoglalóban ezért kapott külön fejezetet a téma. 5 km alatti az indítási távolság távolodó és azonos irányba repülő cél ellen.
Nagyon nem mindegy, hogy a cél megteszi azt a szívességet, hogy a rakéta felé repül vagy elfele attól. Az AIM-54 max. indjtási távolsága 204 km volt, az indítási ponttól meg "csak" 134 km-re volt a találat és a cél magasan repült.
Utoljára szerkesztette: molnibalage83, 2018.10.12. 11:50:23 -
#29278
A GÁ-s légiharccal semmi gond nincsen, amit lelősz, az le van lőve.
A rakétákkal vannak problémák:
- egyfelől némelyik hatótávja, hogy úgy mondjam, gyanúsan kicsi (a 120-as földközelben hátulról nem ér utol egy menekülő célt 3 nmről, PvP-ben körülbelül 6-8 körül kezd veszélyes lenni alacsonyan. Magasabban persze azért jóval messzebből is veszélyes.) - persze sosem lőttünk élesben AMRAAM-ot, tudja fene, hogy mennyire van ez a valóságtól. Amióta a Hornet van 20-25 nm-ről ai vadászt simán lekapja.
- másfelől sokszor könnyen eldobnak célt (pl. földháttérben forduló célt amikor a 90 fokos iránykülönbséghez ér, sokszor ott leves). Persze megint az, hogy gyanús, de tudja fene.
- közelségi gyújtó issue. Példa amúgy van rá, de azért olyan nagyon-nagyon kardinálisnak nem mondanám, hullanak a gépek azért rendesen. Amikor először kötelékeztem a nekem szánt AIM-7-el azt hittem feature, csak hát a valóságnál azért kicsit gyakrabban fordul elő, néha pedig már-már vicces szintre halmozódik. Pl.
De megint az, hogy vannak ilyen bugok, néha fel is húznak, de ettől még azért nem ez az általános. Csak erről csinánal videót meg posztot, nem arról, hogy 20-ból 19 alkalommal, ha az R-73 odakerül ahova kell, akkor gond nélkül elrontja a cél napját. -
sakkay #29277 Érdekes dolog ez, nemtom' a technikai hátteret, de mindent pontosan oda megy ahova lövöd-volt, hogy iszonyat messziről szedtem le gépet gépágyúval-szerencsém volt. Szóval normálisan meg van csinálva a sérülés, nem az a probléma. A gond a rakétával lehet. -
#29276
Meg a #29267-re.
Örülök, hogy nem nekem kellett mondani. De ezek után akkor a DCS-ben a gépágyús légiharc is ennyire pontos multiban? Vagy, ha azt megoldották, akkor a rakétát nem? -
Krokoliszk #29275 Viszont a rakéták felettébb ügyesek abban, hogy amikor egymás után indítod őket, a közelségi gyújtóval egymás közelébe érve megsemmisítsék saját magukat 
Utoljára szerkesztette: Krokoliszk, 2018.10.12. 09:08:34 -
TomStorm #29274 Na Hornet+Persian map megvéve.
A Helikoptert még nem vettem mert nem tudok dönteni:)
Szerver létrehozás Multira.Ugye megadok mindent bal oldalon(max játékos létszám stb.) de a jobb oldalon mit kell megadni?
Valamiért nem engedi -
#29273
Szarnak rá telibe, mert a kisebbséget érdekli ez. Én meg ilyenek miatt mondom azt, hogy mindig van valami, ami odavág az élménynek. -
#29272
Igen, sok furcsaság van benne. Lehet, hogy a rakétás légi harcnál távolabb van az indító fél, ezért ritkábban frissíti a célpont pozícióját, mint amikor gun range-ben vagy. Passz. De valami valamiért nem okés. Wags azt ne próbálja beadni, hogy ennél jobb nem lehet az internet miatt, mert az BS.
Utoljára szerkesztette: VO101Tom, 2018.10.11. 19:00:51 -
#29271
Na jó, de ha nem ezzel van a gond, akkor? Tényleg képtelenek annyit beleprogramozni a játékba, hogy ha a rakéta x méternél közelebb van a célhoz, akkor robban? Ez azért nem tűnik túl bonyolultnak, megkockáztatom, hogy pár sornyi kódnál nem több - bár csak tippelek. Amúgy a kliensekkel itt sincs gond, gunnal ha valakit eltalálsz, az el van találva. -
#29270
:D :D Hát igen... lehetne lövöldözni a nagy semmit. Amúgy meg tök szánalmas ez a magyarázkodás, memagyarázás - csinálják meg és jó napot. -
#29269
Na igen, most képzeld el a CloD-ot, ha ott is random 90-100 métert tévesztene, hogy épp hol az ellenség. Hogy tudnál egy 10 méter fesztávolságú gépet egyáltalán meglőni, ha 10x nagyobb távolságon belül bárhol lehetne? Már 15 éve Il-2 alatt is méterre pontosan lehetett tudni, hogy épp ki hol van. Egyébként ezért látszott, hogy néha "úszkálnak" a levegőben, mert az utolsó ismert irány és sebesség alapján ők mindig kipótolja a kieső időt, és ha netkódban nagyobb változást kapott, akkor nagyobbat helyesbít. De akkor sincs olyan, hogy ne tudná, hogy hol van két gép egymáshoz képest. -
#29268
Wágner úr mikor válaszolt pont arra, amiről szó volt? Sose'.. -
#29267
A Ralfis videóra adott Wags válasz erre a kis filmre nem igazán jó. Ez igaz lehet akkor, amikor nagy szögben, eltérő irányból közelítene a rakéta, ott lehet értelme arról beszélni, hogy pont abban a tizedmásodpercben húzott el, amikor az adatcsomag épp nem ért oda. De a lenti kisfilmen ilyenről szó sincs, jóval tovább tolta az orrát a másik seggébe, míg egy normális adatcsomag oda-vissza megjárja a szervert (100-as ping esetén tizedmásodpercenként 1x). Azt mondjuk nem tudom, hogy egyáltalán a gép és rakéta pozícióját milyen gyakran frissíti a netkód, ami lehet sokkal ritkább, mint egy ping oda-vissza útja.
Arról meg ne is beszéljünk, hogy név nélkül a tudjukmelyik szimulátorban miért nincsenek ilyen bajok? Pedig az internet és a szerver-kliens közötti időeltolódás ott is létező jelenség, valami trükkje csak van (például gyakoribb mintavételezés a rakéta és gép pozíciójáról, esetleg eltárolt pozíció, hogy ha kell később robban kicsivel, de felrobban ha valamikor elég közel volt)? Valamilyen trükkje csak van, hogy mások ezt meg tudják oldani, nem csak széttárják a kezüket, hogy "technikailag ennyi lehetséges". :/ -
#29266
És a miért. 1. komment by wags.
Amúgy marha idegesítő, az tény. -
#29265
Teljesen igazad van, ezt már rég rendbe kellett volna tenni Elvileg a Hornet hoz átdolgozott fegyverzetet, remélhetően utána rendbe teszik a többit is.
A közelségi gyújtók nem működésének mi lehet az oka, azt csak ők tudják. Lehet, hogy benne van valami véletlen faktor is, hogy legyen "játékélmény", vagy egyszerűen szar a logika, ami alapján nézi, hogy a közelben ki van (valóságban ezek a gyújtók működése és felépítése is rengeteg féle lehet). Fragmenteket nem szokták egyenként számolni (grafikai effekteket vegyük teljesen külön, azoknak nem sok közük van a tényleges sérülésmodellhez), hanem a robbanási ponttól kifelé haladva egy csökkenő százalékos értékkel valószínűsítik, hogy a repeszek az oda bejutó hitboxokat eltalálták volna vagy sem. Amikor ilyen több száz repesz több száz hitbox találkozását kellene valós időben számolni, másodpercenként 10-20 alkalommal, az azért érezhetően leterhelé bármelyik processzort. Ezért egyszerűsítenek, mint bármilyen játékban. -
Krokoliszk #29264 Nekem felfoghatatlan, hogy ilyeneket miért nem updateltek már régóta amikor gyakorlatilag ez a magja az egész játéknak.. mi a francra jó egy combat sim, ha a legkritikusabb harci része atom bugos vagy egyszerűen nincs implementálva?
A gépeknek a kiterjedtsége biztosan van számolva szal szerintem arra nem tartana sokba írni egy logikát, ami a rakétától nézi, hogy a gépnek van-e olyan legközelebbi pontja (ami nem a pilóta feje :D) aztán ha az közel van akkor valamilyen közelítéssel abba az irányba robbanjon. A fragmentálás nem tudom, megoldott-e, ez talán nehezebb lehet, meg hogy abbaz irányba repüljön, de aztán felőlem egység sugarú gömbben is robbanhat, baromira mindegy..
Értem, hogy nem lehet mindent patentre modellezni, de akkor legalább miért nem raknak mögé valami olyat, ami minden butaságával együtt legalább nagyjából közelíti a valóságot.. -
#29263
Igen, nekem régi rinyám, hogy a DCS rakéta modellezése mennyire fosch. Amraam főleg. Emlékszem, hány olyan képet láttam már, hogy a kabinból a rakéta oldalán lévő serial szám is leolvasható volt, persze a gyújtó az nem működött. -
Krokoliszk #29262 A proximety valahogy a pilóta fejétől van számolva, meg szerintem nem minden irányból működik. Elég gyakran van olyan, hogy a kabin mellett repülnek el rakéták, vagy akár még a gépen is keresztül mennek. A másik nagy hiba, hogy az ARH-knak nincs semmi memóriája, sokszor elég a másodperc töredékéig a notchba kerülni, egy laza U fordulóval is simán kukázhatóak még 2-3 G-vel is ami röhely.
Meg amikor notchon keresztül rádfordul és nincs semmilyen TWS memória a gépben és kukázza a tracket és üres a radarkép, mert a kitartott Gs fordulót cold-hot aspect között marha nehéz extrapolálni 2 másodpercre..
Mondjuk a boresight az utóbbit orvosolja, csak az sok mindent limitál. :)
Utoljára szerkesztette: Krokoliszk, 2018.10.11. 13:58:24 -
#29261
Közelségi gyújtó sehol? -
#29260
DCS rakéta modellezés. Qrvajó. Ja, nem
https://clips.twitch.tv/ColdbloodedPolishedNightingaleEagleEye -
wolfhgb #29259 Az a megatalkodott spermahader! :) -
Solt #29258 Árpád apánk tehet róla! :D -
wolfhgb #29257 Na tessek, mameg mit muveltel Hercegszanton Zsotiiii!!! :)
![]()
-
#29256
EDe nyugodtan elmehet a picsába. -
#29255
Köszi! -
gantus68 #29254 Na kiderült. Az összes ED modulban megváltoztatták a keybind-et. Ezért szavaztatták a (l)(j)úzereket, hogy milyen hotas-t használnak. A mentések visszatöltése sem működik. A 3rd party, pl. RAZBAM nem érintett. De legalább egy mapping-ot adtak volna. -
#29253
Boldogot
Utoljára szerkesztette: repvez, 2018.10.10. 20:57:14 -
#29252
Kössz Tom! -
#29251
A jó múltkorában jártam hasonlóan és először csak kamilláztam, hogy most miért nem működnek a beállított dolgok.
-
#29250
Boldog szülinapot Leon! -
#29249
Gondolhatod, hogy Edéék és teljes rokonságuk számára voltak szubtrópusi övezeti programajánlataim egész télre, miután először azt hittem, megint a joy szaraxik, elkalibrálódott valamelyik tengely (csinált már ilyet), DCSből kilép, reboot (úgyis várakozott egy WIndows update), joystick kihúz-bedug, eszközökben lecsekkolva minden OK, DCS megint elindít, másik géppel ugyanez.
Nyilván, pont a MiG-29-nél nem rakták oda a trimmet…
-
gantus68 #29248 hornet, nws nem működik nekem, úgy azért elég nehéz felszállni. -
#29247
Na én ettől kapok agyfaszt nem a mikrolagtól... utálom, amikor belepiszkálnak a beállításokba. -
#29246
Elvileg a mai béta update-ben kijött a MiG-29 új FM-je
...és másnál is beletúrtak a billentyűzet/joystick beállításokba? Nálam minden gépnél rákerült a trim a POV hat-re alapértelmezetten, ami eddig a kabinban körbenézés volt.
Oké hogy béta, de azért írhatnák legalább a changelogban, hogy helóka, az update belenyúl a gomb/tengely stb. leosztásodba, nézd át mielőtt küldetést indítasz, vagy valami...
Utoljára szerkesztette: sure, 2018.10.10. 18:37:02 -
Solt #29245 Üdv Urak!
Ha esetleg valakit, vagy valakinek az ismerősét érintheti a dolog,
SPOILER! Kattints ide a szöveg elolvasásához!AUTÓBUSZVEZETŐT keresünk!
A Smart Bus Kft. budapesti telephelyére (Óbuda / XIII.-kerület) 1 fő autóbuszvezető kollégát keres 20 fős Mercedes Sprinter autóbuszra.
Amit kínálunk,
- bejelentett munkaviszony
- nettó 1300.-Forintos kezdő órabér egyedi óraelszámolás alapján
- fix munkák egész évben (idegenforgalom / dolgozói járatok)
- AETR szabályok betartásával történő munkavégzés
- családias légkör
Amit a fentiekért cserébe kérünk,
- pontos, megbízható, a szakma iránti alázattal történő munkavégzés
- igényes megjelenés
- érvényes „D” kategóriás jogosítvány
- GKI kártya
- érvényes PÁV II.
- EÜ alkalmasság (102-s kód)
Ami előnyt jelent,
- alapfokú angol vagy német nyelvismeret
- többéves szakmai gyakorlat
- budapesti helyismeret
- III. / XIII. kerületi lakhely
A jelentkezéseket írásban várjuk a [email protected] email címen!
Köszönöm! -
Solt #29244 Abban a pillanatban, hogy nincs meg a 99%-s GPU kihasználtságod CPU limitbe ütköztél. Ez lehet szoftveres, illetve lehet hardveres. Lehet még vegyes limit is, de nem akarom tovább bonyolítani. Szoftveres esetén azt látod amit felvázoltál (alacsony CPU terhelés), hardveres esetén kb ezt,
![]()
Ez egyébként DCS 2.5 alatt készült egy 4770K-l amin kikapcsoltam a HT-t.
Ami szöveget bemásoltam az attól releváns, hogy taglalja mitől lesz szoftveres limit DX11 alatt,
"a feldolgozás még mindig egyetlen processzorszálra van korlátozva(!), amin a DirectX 11-ben bevezetett deferred context funkció sem segít sokat, mert rendkívül sok szinkronizáció szükséges ahhoz, hogy a program egyáltalán fusson."
"a fejlesztők is inkább manuális többszálúsítást próbálnak(!!) megvalósítani, ami persze sokkal több időbe kerül, de legalább hatékonyabban fut, mint egy deferred context implementáció, mivel a mai driverek tartalmaznak különféle hackeket a többmagos processzorok erejének hasznosítására."
Tehát amit látsz, hogy több mag dolgozik az mind a driveres és fejlesztői varászlások eredménye, de ez messze van a normális több szálas kihasználástól. Ez a videó jól szemlélteti ezt,
Szemléltetésnek jó még az ArmA 3 mert ott csúszkával lehet állítani a látótávot. Felmész egy magas pontra, elnézel egy város felé és elkezded felhúzni a látótávot. Amikor a GPU kihasználtság elkezd csökkenni, akkor érünk el a szoftveres limithez... ilyenkor már annyi rajzolási parancs (draw call) érkezik amit a DX11 a felépítéséből adódóan nem bír kezelni. Ezek a határok erősebb CPU-l kitolhatóak, de az a plusz 10-20% CPU erő nem hoz annyit érdemben a konyhára, mert hulla mindegy, hogy 30 FPS-d van vagy 36.
Tehát amikor leesik nálad az FPS (pl "rákezdett a földi harc") és a GPU kihasználtság (alacsony CPU kihasználtság mellett), akkor abban a pillanatban túl sok rajzolási parancs, fizikai + AI számítás érkezik. A szimulátorok (főleg repülés) ugye itt vannak hátrányban, mert magas a látótáv (sok a rajzolási parancs), van "valós" fizika és az AI sem annyira hülye mint egy átlag játékban, csak ugye ez mind többlet számítás, ami már sok(k) a DX11-nek.*
Mivel azonban hardveres oldalról a géped jóval több számítást tudna elvégezni mint amennyit maga a DX11 elbír, ezért nem a géped a szűk keresztmetszet, hanem maga a DX11 felépítése, ami alkalmatlan arra, hogy valódi többszálas feldolgozás történjen. Próbálj meg ideiglenesen alacsonyabb Visible Range értékkel repülni, látni fogod, hogy nő a GPU kihasználtságod, mert a kevesebb rajzolási parancs miatt csökken az API terhelése. (Természetesen kikapcsolt V-Sync mellett, mert ugye minden tesztet így végzünk!) Ha nagyon leegyszerűsítve akarok fogalmazni, akkor olyan ez mint egy tölcsér... amíg annyit töltesz bele ami alul ki tud folyni addig nincs gond, ha többet, akkor jönnek a problémák...
A Mantle ajnározása azért van, mert drasztikusan kitolható vele ennek a szoftveres túlterhelésnek, limitnek a határa, magyarul jobban kihasználhatóak a hardverek képességei. Ezt az AMD arra szánta, hogy felhívja a figyelmet arra, hogy konzolon a jóval gyengébb hardveres komponensek mellett milyen komoly eredményeket lehet felmutatni. Plusz azért is jól jött nekik, mert a saját hardvereik jobb teljesítményt hoznak a DX12 / Vulkan API-k alatt mint DX11 alatt... a driveres rétegük érzékenyebb erre a szoftveres limitre mint a konkurenciáé.
Egyébként ha az AMD nem áll elő a Mantle-l, akkor a DX12 nagy valószínűséggel még mindig a fiókban pihenne, a Vulkan pedig sehol nem lenne... utóbbinak konkrétan a java része Mantle kód, szabványosítva a Khronos Group által, de az előbbinek egy része is Mantel másolat. :)
*A DX11 korlátai természetesen a képességek, szándék, ráfordított idő és pénz arányában függenek a fejlesztőktől is. Nyilván jobb eredmény érhető el akkor, ha a fentiek közül minden stimmel, lásd például a GTA V-t.
Utoljára szerkesztette: Solt, 2018.10.10. 12:52:20 -
gantus68 #29243 +1 dolog jutott eszembe, bezavarhat a 'mirror' is, érdemes azt is kikapcsolni.
A 29180-ban egy abszolút minimumot írtam le, ami nálam bevált ez alapján: Optimisation guide
A táblázatban benne vannak a különböző beállítások fps-re gyakorolt hatásai, ez alapján a shadows/terrain shadows a global cocpkit illumination az msaa/ssaa fps killer. Nálam is 1070-el inkább a gpu terhelődött, mint a cpu. 4k-ban esélytelen a shadows-t bekapcsolnom, még low-ban is elkezd microlaggolni.
-
#29242
Lehet már késő van, nem értem miben releváns ez ahhoz amiről beszéltünk? 2013-as cikk ajnározza a Mantle-t, meg hogy mennyire szar a Dx11 hozzá képest. Ok. Amit jósol, hogy AMD majd jól sakkot ad mindenkinek... nos, ez nem jött be, mondjuk AMD jól elvan a konzolokkal, PC-s piac talán nem is olyan fontos nekik már. Vulkan köszöni, elvan, de nincs az az áttörés, amit a cikk jósolt (vagy inkább remélt).
Közben megnéztem MSI afterburnerral szálankénti terhelést, 1. mag sosem ment 40% fölé, a többi meg maradt olyan 5-15%-on. Szép egyenletesen mind a nyolc szál. Egyik sem volt kiakadva, egyik sem terhelődött más ütemben mint a többi. Teszt közben a GPU terhelés volt 98% körül, néha leesett és akkor jöttek az akadások. Két alkalommal megállt az egész olyan 1-2 másodpercre is, valszeg ott kellett valamit winyóról töltenie. Amikor rákezdett a földi harc, akkor jöttek a rendszeres apróbb akadások is. Sakkay teszküldijében, amikor 100 földi cucc csépeli egymást, ott olyan egyenletesen jöttek az akadások, mintha egy metronom kattogna :) Akárhogy nézem, ez nekem nem CPU-nak tűnik, sokkal inkább GPU a bottleneck. 1080, 1080TI-vel tuti jobban futna. Nem? -
Solt #29241 A szoftveres limit esetén gyakorlatilag "mindegy" milyen CPU-d van, mert nem a CPU képességei jelentik a korlátot, hanem a szoftveres háttér (DX11),
A DirectX és OpenGL API-kra épülő alkalmazások esetében a feldolgozás még mindig egyetlen processzorszálra van korlátozva, amin a DirectX 11-ben bevezetett deferred context funkció sem segít sokat, mert rendkívül sok szinkronizáció szükséges ahhoz, hogy a program egyáltalán fusson. Ráadásul az NVIDIA implementációjában a szinkronizációhoz a grafikus driver egy processzormagot teljesen lefoglal a parancslista kezelésére, ami két maggal rendelkező processzorok esetében nem kedvező. Az AMD és az Intel pont ezért kerüli a parancslista implementálását, mert nem minden szempontból előnyös, ráadásul a fejlesztők is inkább manuális többszálúsítást próbálnak megvalósítani, ami persze sokkal több időbe kerül, de legalább hatékonyabban fut, mint egy deferred context implementáció, mivel a mai driverek tartalmaznak különféle hackeket a többmagos processzorok erejének hasznosítására. A helyzet azonban az, hogy az így nyert sebesség az egyszálú feldolgozáshoz képest nem túl nagy, viszont ettől függetlenül rengeteg optimalizálást igényel. Ezt a nagyobb stúdiók megteszik, de aránytalanul sok a befektetett munka pár százalékos gyorsulásért. A Mantle eltérő működése azonban technikailag lineáris skálázást tesz lehetővé, ráadásul tényleg rengeteg szál futhat párhuzamosan. Ez a jövő szempontjából még kedvezőbb, mivel ha a mai nyolcmagos processzorok után esetleg lesznek 10-12-16 magos opciók, akkor abból a DirectX leképző tulajdonképpen nem profitál, miközben a Mantle kód folyamatosan gyorsul.
LINK
-
#29240
Ja, hogy a régi gépek feljavítására gondolsz. Igen, azokhoz aktualizálni kellene ezeket mapokat, amit még nem csináltak meg.
