53049
Hivatalos forum Oktató videók Kép feltöltése JoeDestroy_cucc Oktató vid_HU L_Viper cucc BMS manual_HU 80's Mod HT kisokos BMS Wiki Falcon4exe
-
#51925
Látom tényleg nem érted...
Nem ezen spórol sokat a 2D világ.
Ha egy objektum a 3D világban van, akkor minden másodpercben asszem legalább 8-szor kiszámolja az összes célhoz képest a helyzetét és távolságát, mert ez kell a radar, RWR és eyeball modellezéshez, hogy ki és mit lát és érzékelhet.
A rakéta kinematikát is számolja.
És n+1 mást. Emiatt zuhan be az FPS a reptereknél és ha sok földi egység van. Régen a bubble mérete állítható volt. A FLOT-nál az első nap MAV/TGP kamerával még a bivalyerős hardverek is bezuhantak 10 FPS tájára, ja 10-12 nm helyett 20-ra húzta a földi egységeket. Az átlagos hardverek meg 1-2 FPS is. Emlékszem, amikor a ITO FF3-ra kijött alig nem sokkal az FF4/RV előtt. Felszálltam, semmit nem állítottam és a FLO-nál 3 FP tájára zuhant a játék, mert teliverték egységekkel...
A 2D hadjárat ezt spórolja meg. Nnics semmiféle kinematika és 3D helyez másodpercenként 8-szor és egybek. Egy összevont battalion és fligth értékek vannak és csá. És azt pikk-pakk lehet számolni.
Valahol pislogok, hogy ennyi év Falconozás utána ennyire nem érted a rendszer alapjait sem. -
#51924
mindez elfér pár mb os fileba.
??? Egy átlagos acmi file egy KTO-s hadjárat missionja után 400 MB körül van. Ne hasonlítsuk már a DCS picsaegyszerű missionjait ehhez.
Utoljára szerkesztette: VO101Tom, 2020.05.13. 23:30:14 -
#51923
A 4.33 2MB/sec feltöltést igényelt, és a játékosok fele ezért hagyta abba.
ugy értettem, hogy amikor már te a 3d fülkében ülsz akkorra már a package összes gépe az állohelyen vár, tehát a saját társaid taxizását nem kellene megvárnod, csak azok taxizását látnád akik késöbb fognak felszállni másik package-l.
ugymintha az elöválasztó képernyón a ramp elötti idöben guritaná oda a gépet.
Na várj. Indulásnál tudsz választani ramp startot, texiway-t, aminél külön kiválasztható hogy a pályához közel a gurulóútra tegyen ki, vagy az állóhelyre csak épp mindennel bekapcsolva, vagy a runway, amikor már pályára is állít. Akárhogy indulsz a saját package gépei bent állnak a parkolóhelyen, gurulón vagy a pályán (host lép be 3D be elsőnek), amikor a társad belép, akkor látni, hogy megmozdul a kormánya (szonkronizálja a netkód a kliens és a host között a gép berendezéseit), kiírja, hogy xv a játékba csatlakozott, de iylenkor te nem látod spawnolni a gépeket már most sem. Csak akkor ha utánad valami másik package kerül indulásra. Vagy pvp-ben másik human package indul.
Leszállás után ha kilép a kabinból, akkor azonnal eltűnteti a gépet, de ilyenkor sem kellene taxiznia,lehetne kicsit hosszabb delay az eltűnésre, de ennyi.
Utoljára szerkesztette: VO101Tom, 2020.05.13. 23:22:27 -
#51922
miért ha nem számolodik a 3d model és a particle effect, meg egyébb dolog ami csak a player számára fontos azzal, nem sporolnál erőforrást?
ugyan ugy mint a dcs és a Clod-nál a track file, minden adatot rárol ami ahhoz kell, hogy utána késöbb visszajátszható legyen a teljes akció 3d ben. mindez elfér pár mb os fileba.
tehát ugyan ezt kéne a 3d bubblen kivül is alkalmazni és ezeket az adatokat megosztani multiba, hogy a másik gépen ujra tudja kreálni a rendszer ugyan azt . -
#51921
Látom nem érted. Ha ugyanúgy működne, mint a 3D, akkor 3D világ lenne = 0 erőforrás spórolás. -
#51920
Mem, ugy értettem, hogy amikor már te a 3d fülkében ülsz akkorra már a package összes gépe az állohelyen vár, tehát a saját társaid taxizását nem kellene megvárnod, csak azok taxizását látnád akik késöbb fognak felszállni másik package-l.
ugymintha az elöválasztó képernyón a ramp elötti idöben guritaná oda a gépet.
és az indulás elött ahogy most is ha már felszállt a gép, akkor nem lehet modositani a fegyverzeten igy az sem lenne probléma.
És most mikor már minden lakásban minimum 15/1 es net van, de inkább a 30/5 a jellemzó, nem birná el ha a 2d adatokat át kellene küldeni egymásnak online játékhoz, mikor 98 ban jó ha kilobájtok mentek át kb ugyan az a rendszer azóta
Az idő gyorsítás meg amugy is egy fake dolog, szoval, ott ne is csodálkozzon az ember ha esetleg ez a procedura alatt is gyorsabban pörögne minden a reptéren. -
#51919
ÉS akkor se lenne semmi probléma ha közel van egymáshoz kép player.
Nem az a gond, hoyg a játékos gépe bírja-e, a probléma a host leterheltsége és a netkóddal átküldendő adatmennyiség, mert az nem játékosonként számolódik, hanem a szerveren lévő összes játékos összességére. -
#51918
Az. De legalább szép. Tiszta DCS 
-
#51917
A spawnolást meg meg lehetne ugy oldani, hogy a háttérben ahogy az ATO megtervezte a repüléseket arra az idöpontba kiguritaná az AI az állóhelyre a gépet a hangárbol, vagy a feladat végével miután a játékos kilépett az AI betaxizná a hangárba és ott láthatatlanul tünne el.
És ez mire lenne jó? És miért programoznál ilyesmi? Szerinted az életszerűbb, hogy ha nyitott fedezékből indulsz, akkor hajtóműindítás előtt az AI kitaxizik egyik hangárból az indítóhelyre, ott leállítja a hajtóművet, jön a human pilóta, megcsinálja a cold rampstartot, majd miután leszállt és leállított mindent, akkor az AI újra indít, eltaxizik egy közeli hangárba, csak hogy a spawn és az eltűnés ne legyen ltáható? Ennek semmi értelme, és engem sokkal jobban zavarna, ha a társam leállított gépe a kilépése után hirtelen taxizni kezdene ki tudja hova (én szoktam lenni a host, én mindenki ki és belépését végig szoktam nézni). Arról nem is beszélve, hogy ha ATO-ban valaki változtat, de a gépe már "gurul a starthelyre" akkor ugyanúgy látnád eltűnni a gépeket. vagy gurulás közben átfegyverezni. Szorri, de ennek én semmi értelmét nem látom...
(arról nem is beszélve, hogy ha megvan a feladat, pörgetjük az órát (online pvp esetén a feladat felszállási idejét hozzuk előre) és mindenki gépben ül egy percen belül. Egyszerűen senki nem tököl a 2D térképen addig amíg egy AI kitaxizna ramp start helyre akármilyen hangárból a reptér másik részéről). -
#51916
Pedig ugy kellene müködnie mint az ACMI proginakm hogy ugyan azokat a cselekvéseket kellene megcsinálnia mint 3d-ben,
igy az is elkerülhetö lenne, hogy a bubblen belül random helyeken elökerülne valami , -
#51915
Mert alapvetően más történik. Gyakorlatilag semmi esélyed nincs rá. Egy háttérben futó RTS játékot képzelj el, ahol nincs modellezve semmi fizika. Statisztikai értékek vannak randomizálással nyakonöntve. De mivel nagyon generális a modell pl. még ott sem tudsz több célcsatornás SAM-et modellezni. Egy távolságon belül gyakrabban tüzel a SAM és ennyi.
Nagyon, nagyon, nagyon, nagyon elkent dolog a 2D világ igen sok bajjal. Egy A-10 a 3D világban töredékét nem adja elő, amit 2D-ben. És a Szu-25 meg impotens egy A-10-hez képest. Próbáld ki TE-ben és lelhet pislogni az eredményen. Ezért van az, hogy én limitáltam 1 db 12 gépes alakualtra a hadjáratban a mennyiséget. Mert rohad OP. 3D világban az MI kb. képtelen a gépágyút használni rendesen - már ha tudja a BMS 4.34 nem néztem meg - a 2D-ben egy 4 gépes A-10 kötelék régen 30+ célt kilőtt...
Egy 4 gépes Szu-24 kötelék 8 db AGM-mel ÉS bombákkal meg szart sem .Hiába írtam át a 2D értékeket anni. MIért? Nem tom. Azt talán exe kódolt módosítóval bírt. Tudja a tököm.
Erre is anno felhívtam a figyelmüket. Ha van időd csináld meg a tesztet. ;) -
#51914
ezt a 2d 3d dolgot nem egészen értem, hogy miért nem lehet szinkronba hozni, hogy a bublén kivul is ugyan azt a tevékenység legyen, csak a 3d elemek nélkül.
ÉS akkor se lenne semmi probléma ha közel van egymáshoz kép player., ,,mert mindegyiknek a saját területét számolná, nem pedig egybe olvadna a két rész.
igy egyedül akkor kellen plusz bubblet kapcvcsolna ahogy irtad is az AG radar vagy optikai fegyvereknél aminek a hatótávja nagyobb mint a player alap bubble-ja. -
#51913
Igen, nagyjából ez a helyzet.
Amíg az ATO is mindent közepes magasságon tervez, addig nincs miről beszélni. A double digit SAM simán halomra mészárolja az MI vezette gépeket még SEAD támogatással is, ha képes lenne több célcsatornára.
Nem véletlenül mondom azt, hogy sajnos a játékosok többsége nem fogja fel, hogy mit kérnek és mire akarják felhasználni az egészet. A játék a 80-as éveket tudná a legjobban modellezni, annak is a végét. Amikor már volt MFD, de mutató volt több célcsatornás SAM, de már volt TGP és ARM meg data link is. Csak nem pengeéles és atomtáp SNIPER kéne, hanem a LANTIRN pontos modellezése.
F-15E-vel és F-16C Blk 40/42-vel igen jól el lehet lenni egy 80s hadjáratban.
Utoljára szerkesztette: molnibalage83, 2020.05.13. 21:43:13 -
#51912
A Baltic térkép kb. használhatatlan, ha engem kérdezel.. -
#51911
Dee-Jay az ARM rakéták elleni ellentevékenységre mondta, hogy masszív SEAD esetén ha mindenre indítanának, akkor 10 perc alatt kifogynának a SAM ütegek.
A szimultán célleküzdés viszont a SAM-et támadó AI-t picsázná el nagyon csúnyán. Ezért kell minden változásra az AI-t is felkészíteni. -
#51910
igy egy reptéren 100 nál is kevesebb gépet kellene számolnia
7-800 géppel számol az alap KTO kampány (mellé 11K földi cucc). Ha ezt online pvp-n játszod, azok ezek nagy része valahol valakinek a bubble-jában lenne, amit a hostnak kell managelni. Nem tudom mennyit repkedtél mostanában és milyen gépen, de még 100 db repülőgép is qrvasok a visual bubble-ban. Repülés közben kevésbé lenne vele baj, de reptéren állva nagyon érezni. Múltkor terveztem egy Strike package-t, SEAD-el és ESCORT-al, plusz mellőlünk indult pár másik package, qrva jól nézett ki a 20+ gép indulásnál, de már érezhetően recegősebb volt a gurulás mint általában. Nem volt játszhatatlan, de azt tisztán látni, hogy a JELENLEGI bms engine legszűkebb keresztmetszete a 3D objektumszám (ahogy az pl a Baltic térképen is előjött, qrva szép, de reptéren van 25 fps, levegőben 60+). Ráadásul modern gépekkel, ahol TGP-vel qrva messzire ellátsz, ott a visual bubble is qrva nagy. -
#51909
A saját géped körül repcsiknél kb. 30-40 és talán egyes gépeknél 50 nm bubble van. A földi egységeknél, ami nem SAM ott olyan 10-12.
Viszont az AG raar kurzor köré is tesz egyet, asszem egy 8 mérföldeset.
Ha meg MP van, akkor jön a sakkozgatás, hogy ki mit számol, mert ha egymástól 8 játékos repül 100 mérföldre, akkor aztán hujujj,,,
Utoljára szerkesztette: molnibalage83, 2020.05.13. 21:30:04 -
#51908
3D-ben pont, hogy nem ütné ki az első 10 percben. Konkrétan a szerencsétlen MI-t egy Sz-300PSz is halomra mészárolná...
Lásd itt. És akkor még a 2D világról szó sem volt. Ott fekszik meg igazán. A 2D és 3D világ eredményei köszönőviszonyban sincsenek egymással többnyire. De elviselhető, ha az ember elfogadja, hogy mi a 2D célja.
Igen, az MI a nehéz. -
#51907
7-800 gép? csak azért ,mert máshogy lenne megoldva a spawn, nem hinném, hogy olyan drasztikus lenne.
Nem tudom, hogy most mekkora területet fed le a bubble, de ha meg lehetne oldani, akkor a 3d bubble csak a player gépen lenne x km sugaru körben a többi meg a háttérben számolódna, szinkronizálva a multival.
igy egy reptéren 100 nál is kevesebb gépet kellene számolnia.
A spawnolást meg meg lehetne ugy oldani, hogy a háttérben ahogy az ATO megtervezte a repüléseket arra az idöpontba kiguritaná az AI az állóhelyre a gépet a hangárbol, vagy a feladat végével miután a játékos kilépett az AI betaxizná a hangárba és ott láthatatlanul tünne el.
igy bejöhetne a ground frekvencia is, hogy figyelni kellene a reptéren való mozgást is a földön, ki merre megy, nagyobb élet lenne a reptéren is. Az AI eddig is irányitotta a gépeket felszálláshoz, most "csak" ki kell egésziteni, hogy a kijelölt spawn hangárba vezesse öket.
Igy lenne értelme a hangárt is támadni, mert akkor lehetne kalkulálni azzal, hogy hány gép lenne indulásra kész mikor bombázzás volt.
Ahogy olvasom az infókat az uj FS2020ban is valami hasonló lesz.Ott is 2d-ben reptetik az összes gépet és a playertöl x sugárba a legközelebbi 50 gépet jeleniti csak meg 3d ben.
Igen az AI részen kéne finomitani, hogy változatosabb helyzetekre is tudjon reagálni , de azért igy is sokkal jobb kötelékezni vele mint dcs-ben . -
#51906
Senki nem azt mondja, hogy technikailag lehetetlen lenne megoldani, de Dee-Jay szerint a JELENLEGI bms kóddal ez nagyon odaverne az fps-nek, ha 7-800 gépet ilyen szinten kellene managelni, 3D-ben mozgatni és tárolni minden egyes repülőtéren, és betölteni, ha a játékos a 3D bubble-n belül jut. Ráadásul sok helyen több reptér is van egymáshoz nagyon közel, Sínai térkép Egyiptomi oldalán pl. rendesen navigálni kell köztük, hogy melyikre kell leszállni. Online pvp esetén ez azt jelentené, hogy a szervernek a repterek nagy részén 7/24-ben kellene ezt managelnie. Hogy az új kódban hogy lesz megoldva, azt majd meglátjuk, de kétlem, hogy a jelenlegihez képest ez a rész változna...
Azt én is tudnám értékelni, hogy ha a hangárokat is lehetne pusztítani, ez hatással lenne a reptéren tárolt gépekre, de ehhez pl nem is feltétlen kellene 3D gépeket tárolni benne, csak a hangároknak lenne ilyen dedikált "sérülés flag-je", hogy -1 hangár, -x% gép. De ehhez map engine-be kell beletúrni, alap kódba kellene beletúrni, hadjáratokba és AI-ba kellene beletúrni (AI-nak innentől támadnia kellene a hangárokat is), amivel a JELENLEGI bms kódba már tuti nem retkelnek.
Az oda-vissza taxizásra is lenne más megoldás, hogy a parkolóhelyet csak akkor vonja vissza ha a Flight kikerül az ATO-ból, ne akkor amikor a gépek elindulnak. Ekkor lenne indulási és érkezési helyed is, viszont ha ATO-ban új Flight kerül tervezésre, azt ugyanígy spawnolni kell az állóhelyekre, 3D-ben tuti nem tárolja egy reptér összes bevethető gépét a parkolóhelyeken (főleg az fps miatt).
Meg aztán azt is át kellene gondolni, hogy a játékmenetre milyen hatása lenne ha ezeket az alapvető részeket átalakítják, például a ARM rakéták lelövésére írta Dee-Jay, hogy azt akár holnap is a játékba tudná tenni, hogy Harmokra a SAM ütegek -amelyik képes rá IRL- az tudna indítani, de ennek az lenne a következménye, hogy az AI a hadjárat első 10 percében kiürítené a SAM ütegeket, és onnantól nem lenne mivel lőni. Tehát azzal együtt, hogy technikailag nem nehéz beletenni egy ilyen változást, az qrva nehéz, hogy az AI-t megtanítsa arra, hogy ezt életszerűen használja. És pl egyenlőre még a SAM-ek szimultán célleküzdést és a korlátozott tűzíveket sem tudja a BMS (nekem ez a legfájóbb hiányosság az egész BMS-ben), amik szerintem sokkal fontosabbak lennének, de biztos vagyok benne hogy ezeknél sem az adatbázis átírása a nehéz, hanem az AI-t megtanítani arra, hogy ezeket a változásokat hogyan kezelje, hogyan támadjon ezután.
Utoljára szerkesztette: VO101Tom, 2020.05.13. 20:34:33 -
#51905
Bevallom nem igazánértem a kommented, mert most is így működik, hogy X idővel a felszállás előtt jelennek meg a gépek.
Az FF CE-jen anno az FPS miatt állítható volt, csak ennek pont az a problémája, hogy a grafikai beállításnak hatása van a harcászatra. Kis spawn time = nagyobb immunitás a földön szétbombázás ellen...
A spawn rendszer miatt nincs értelme a hangárokat sem bombázni, amikor valójában ott lennének a gépek. Pedig ez lenne igazán a kívánatos. Vagy akkor össze kéne kötni valahogy a kódban, hogy -1 hangár = - 1 gép
Ha nem lenne spawn modellezés, akkor mindig ott lenne a gép a 3D világban. Multiban előfordulhat, hogy bár egy játékos bubble-ből kiesik egy gép a folyamatos bevetésre járás miatt mindig lesz ember a reptérnél. Akkor hogyan mozgatja az MI a gépet? Egy frame alatt insta megfordítja?
Utoljára szerkesztette: molnibalage83, 2020.05.13. 11:05:05 -
Daniel075 #51904 A gépek most is jó helyre spawnolnak, hangárba vagy hangár elé, az hogy ez random kit érdekel ? leszálláskor vissza tudsz állni a start helyedre. A küldetést befejező "eltűnő" gépeket meg vedd úgy hogy beálltak a hangárba.
Utoljára szerkesztette: Daniel075, 2020.05.13. 10:59:27 -
#51903
Miért ne lehetne spawn, attól, hogy a rendszer menti, hogy melyik állóhelyrül indultál és hova kell érkezni?
A betöltéskor csak azokat a gépeket kellene megjeleniteni aki a te felszállási idöd körül +-10 percel (állitható lenne ). igy redukálódna a megjelenitett gépek száma, de mégse látnál hirtelen eltünö és megjelenö gépet magad körül. amig a levegóben vagy addig is elfoglalhatja bárki a helyed, csak a leszállás idejére kellene felszabaditania.
Meg minek kellene a földi gépek a megforditáshoz? amikor kilépsz automatikusan megfordítja a modellt és legközelebb már a jó pozicióbol indulsz ugyan onnan. hangáron kivul még ezt sem kell, mert ott eleve tudsz indulni ahogy megáltlál.
A való életben sem tudja a pilóta , hogy amikor nincs a gépben akkor ki merre mozgatja a gépet, neki az a lényeg, hogy amikor felszállni kell akkor tudja, hogy hova menjen melyik gép lesz az üvé, a többit a mechanikus megoldja, hogy felszállásra kész állapotban legyen és ki tudjon gurulni az állóhelyról. -
#51902
A fejlesztési oldalról. Játékos oldalról kvázi 0-át.
Ellenben mióta annak fejlesztése földbe állt és az F-16 kiadással is szénné égette magát megdöbbentően sok ex DCS-es bukkant fel a BMS háza táján. Volt egy komment, hogy a BMS számára a DCS F-16 inkább előny volt... :) -
Daniel075 #51901 A BMS-ben gyorsan jönnek mennek az emberek, de a keménymag marad. 
-
#51900
Amíg az egész avionika csak F-16 ra van írva, addig nincs is értelme másik gépet beletenni. A DCS-ben a Hornet nagyon jól meg van csinálva, mármint az avionikának az a része ami már készen van, és ott látni, hogy mennyire teljesen más az egész logikája a gép kezelésének, menüknek, beviteli lehetőségeknek, satöbbinek. Nagyon más, mint az F-16. -
skeleton #51899 Ebből kiderül hogy itt a dcs hornet elvitt sok embert . Szerintem nem is fogják erőltetni a hornet továbbfejlesztését mert a dcs itt előnyben van a kidolgozás minőségét illetően. Most meg hamarosan jön a supercarrier, Nem hiába nem nyúltak már hozzá 3 éve a bms-nél a hornethez. Jobban teszik ha az f-16-ost hozzák még magasabb szintre. A többi repülőgép csak extra de nincs olyan szinten mint az f-16 -
#51898
Érdekes Hornet háttérinfó -
skeleton #51897 Észrevettem egy érdekes dolgot a repülési modelleket böngészve. A hajtómű felpörgési idők nincsenek korrektűl beállítva jópár tipusnál. leginkább az orosz tipusoknál. Nem hiszem hogy a mig-17-es hajtóműve 2-3 mp alatt maximális utánégetésre gyorsulna 
Utoljára szerkesztette: skeleton, 2020.05.12. 21:04:48 -
#51896
Ez igazából adatbázis... -
skeleton #51895 Más a kezelőpanelek elhelyezése, más zavarópanel van, analóg repülésvezérlő panel -
Daniel075 #51894 Hát az f-16a nak biztos nem fogja senki megcsinálni a cockpitjét. Az meg hogy mi a különbség a block 30 és 50 cockpitje között hát én meg nem mondom. -
skeleton #51893 A különböző blokkok műszerfalai nem stimmelnek. ( f-16a, c block 30) és a katapultülés sincs megfelelő helyzetben
-
Daniel075 #51892 Például mi nem jó a pilótafülkében ? 
-
skeleton #51891 Az F-16 pilótafülkéken is kellene dolgozni mert ott is van mit javítani. -
Daniel075 #51890 Inkább a damage modelleken kéne dolgozni, hogy ne lehessen 3 egymás mellet álló tankot egy gbu-12-vel elpusztítani. De mondjuk az se lenne baj ha a battalionok nem csak egymás mellet állnának hanem tudnának más formációkat is. -
#51889
Ebben nem vagyok olyan biztos, most ha 5-6 flight indul egyszerre, már az érezhetően lassítja a játékot. Pl a Baltic térképen feltűnő nagyon, hogy a reptéren van 30 fps, futócsukás után atomstabil 60 (vcync-el). A falcon nagyon régi játék, grafikában/engine-ben sok olyan hibával, amit javítani kellene. Ezért is készül az új engine. -
skeleton #51888 Szerintem ha ésszerű mennyiségű repülőgép lenne egy reptéren akkor az nem lassítaná be a játékot hadjáratnál sem. De ez a mostani spawn rendszer hogy a semmiből megjelennek a repülőgépek ez nem valami realisztikus -
#51887
Nézhetjük onnan is, hogy a hadjárat készítőjének a feladata, hogy értelmes számban tegyen a repülőtérre századokat, vagy a játékosé, ha a mission commanderrel szórakozik, de technikai akadálya annak nincs, ha valaki sok gépet, sok századot akar egy reptérre tenni. -
#51886
Mert valójában az élet is rugalmas. A Sivatagi Vihar alatt volt olyan reptér, ahol annyi gép állt, hogy gurulóutak szélére tették őket.
Kecskeméten is ok, hogy van x db Gripen hangár és a szerelőhangár vagy mi a neve. No de ki tiltja meg, hogy a reptér minden lehetséges helyén, ami nem blokkolja a gépek mozgását képet tárolj? A gyakorlatiasság és háborús időkben a biztonság.
Konkrétan a SV előtt egyesek rémálma az volt, hogy Irak merész húzással megtámadja a reptereket. Olyan sűrűn álltak a gépek, hogy egyeten támadó gép néhány kazettás bombával tucatszám semmisítette meg volna azokat.
A játékban levő repterek a reálisan elképzelhető gépmennyiségre készültek. Kb. ennyi.