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
-
#50564
Na, hát akkor 20. szülinapot F4.
-
#50563
VGA-t meg max 40%osan. szoval , valahogy ezen lehetne még fejleszteni , hogy vagy részletesebb grafikai elemekkel növelni a VGA kihasználását azonos FPS mellett.
Vagy növelni a sebességet a jelenlegi grafikai részletesség mellett, hogy a VGA-ra átmozgatni több elemet , hogy több számitás maradjon a CPU-nak a nem grafikai részhez. -
#50562
ha esetleg én nyernék, akkor az enyémet is megihatod, nem iszok sört ... se. -
#50561
Meg is kérdeztem, hogy akkor melyik a nagy nap. :)
Morzsa nem lesz. Eddig sem volt, nem is lesz. Egy sörbe fogadok.
-
#50560
ugy néz ki a mai nap van a 20. évforduló
vagy csak a kommentelö szerint.
DE mindenesetre akkor a napokban figyelni kell, hogy hátha valami kis morzsát dobnak a népnek ez alkalombol a fejlesztők. -
#50559
Sajnos azt, hogy legyen afféle "szegélye" a Falcon 4 szövegnek nem tudom megoldani. Az eredetit is elég viccesen oldom meg, Vegas belső trükkjével. Ez most PS-ben készült felirat és textúrával és a többi van Vegasban. Picit próbálom az árnyékot csökkenteni, csak akkor a fény olyan erős, hogy elnyomja a textúrát. -
#50558
ez nem rossz, csak nem kellene olyan nagy homályositás vagy árnyék a szélekre, mert a 4-esbol alig marad valami látható a végén -
#50557
Pár effekt kimaradt.
-
#50556
Akkor biztosan nem, 1998 december, de attól függ, hogy hol és milyen időzónát nézel dec 11/12. A wikin 12-e van a FalconEpopee doksiban 11.
@Repvez
Ez milyen?
-
#50555
A Falcon 4.0 nem 1998 Jan. 1-jén jelent meg? -
#50554
Megpróbálom, de sajnos a Vegasban nem tudok textúrát adni a felületnek és a bump map korlátai is megvannak. -
#50553
Ez jó hír. Legalább nincs nagyon messze. -
#50552
egy kis fémes hatást kaphat a falcon felirat.
Ja , de ha nem is sikerül kiadni az évfordulora, legalább azt tudjuk, hogy nem kell sokat várni rá, ha olyan állapotba van, hogy ezen gndolkodtak, akkor max 1-2 honap ha valamit még le akarnak tesztelni vagy javitani. -
#50551
Infóm van. Röviden, jól sejtettem, tényleg a 20. évfordulóra tervezték a 4.34-et, de valószínűleg nem fog összejönni. -
#50550
Az intro végén, ha ez lenne ez jobban nézne ki? Vagy esetleg máshogyan fémes felület?
![]()
Utoljára szerkesztette: molnibalage83, 2018.11.28. 00:58:36 -
#50549
Mást is jelenthet, mert ez 3rd party helyszínen készült.
Ha tippelnem kéne, hogy az F4.0 20 éves kiadásának évfordulóján készülnek valamire, de eddig soha nem kötötték magukat semmiféle ünnephez vagy új évhez. When it is done, oszt csók.
Utoljára szerkesztette: molnibalage83, 2018.11.24. 00:25:33 -
#50548
vagy karácsony vagy valamikor az uj év elején ugy néz ki , hogy jön az uj kiadás?
Legalábbis az elejtett szavakbol nekem az jon le, a videohoz mellékelt szovegbe csak annyit irt, hogy ugy néz ki ez a video lesz az utolso ilyen missziojuk a 4.33al és a végén a videonak van egy felirat, hogy , köszöni, hogy megnéztük ezt a hosszu bemutatót, de a java csak jövöre jön, de nem fog dátumot irni kacsintós smilival
-
#50547
Kihasználják a közösség erőforrásait is.
A bepillantás dolgot ezerszer lerágtuk már.
Egyébként meg van, én hoztam létre. Nem tegnapelőtt, majdnem 7 éve. Itt Innen kerültek be a dispenser változtatások, ide került a SAM fejlesztés, az AAM tesztek és a battalion változtatáshoz szükséges anyag.
Engedik a brainstormingot.
-
#50546
Pont az ilyen esetekre mondtam, mindig, hogyha a falcon fejlesztők engednének egy kis bepillantást vagy irányt a fejlesztésbe vagy csak egyszerüen kihasználnák a közösség eröforrásait akkor több dolgot ki tudnának javitani vagy pontossabb adatokra cserélni.
miért nem lehet egy olyan topicrész ahol kategorizálva be lehetne irni a fegyverekre tipusokra jellemző adatokat vagy a megvalósitásra lehetséges modokat.
senki nem kötelezné a fejlesztőket , hogy felhasználják vagy, hogy beletegyék, de ha épp ugy adódik akkor ott az adat és esetleg olyan infót technikát postolnak ami hasznos lehetne.
A brainstormingot miért nem engedik a forum keretei megengednék , sok részre bontani a témákat, hogy ne keveredjen össze a tartalom a felesleges dolgokkal.
igy aki nem ért a programozáshoz, de van szabadideje , hogy felkutasson forrásokat azzal is sokat segithet.. -
#50545
Volt erre próbálkozás, de nem volt komoly reakció a belépési szándékra. Ma meg már nem is tudom, hogy akarnám-e. Az, hogy a MOD-omat F4B-vel átszabtam és működött, az egy dolog. Nem biztos, hogy az a módszer elfogadható lenne a core BMS4 fejlesztésben is. A szomorú igazság az, hogy egy rakás dolgot elfelejtettem már, hogy mit és hogyan csináltam, újra kéne tanulni.
(Ez videózás terén is igaz. Van olyan ősrégi FF videó, amiben egy két kamera jelenetet nem is tudom, hogy hogyan sikerült összehozni, csak sejtésem van róla.)
Külsősként azért bekerültek anyagaim. Pl. a chaff-flare módosítások és az én adatszolgáltatásomból lettek az új SAM modellek és figyeltek arra, hogy az SHORAD működjön mozgás közben is ami totálisan el volt tolva a 4.32-ben és nem működtek.
Dee-Jay többször írt levelet, hogy akkor a battalion roster és role score terén miket csinátlam a modban. Elmagyaráztam. Meg összeraktam ezt. Ez alapján várható, hogy ha nem is a 4.34-ben, de valamikor lesz komolyabb változás.
Az IR terén beszélgettem Dee-Jay-jel. Valójában az MI néha szarik az IR modellező értékekre és szétbarmolt ezt-azt a kód. Azt kijavították már, most jött el az a pillanat, hogy az IR modellező értékek változtatásán sőt, új modellen is el lehet gondolkodni, mert tudják már, hogy most már jó. A fejlettebb modell kapcsán csak annyit mondott, hogy ő aztán megcsinálná, és kacsintva mondta, hogy akár U1-ben, ki tudja.
A szimultán SAM célleküzdésre és sok más kérdésemre azt mondta, hogy azok sajnos sokkal nehezebb dolgok. Ebből sajnos nekem továbbra is az jön le, hogy a '80s környezeten túl nem jó a BMS4. Borzalmasan egyenlőtlen a SEAD vs SAM képesség és az ARH vs SARH korszak közötti szakadék. Arról nem is beszélve, hogy az Sz-300 és Buk család sok célcsatornája és anti-arm képessége sehol, ahogy a Tor-é sem.
Ez így nagyon, de nagyon nem balanszolt környezet. És ez csak a 3D világ. Senkinek nincs ötlete sem arra, hogy a 2D világban ezen dolgok hogyan lennének megvalósíthatóak. A Falconban a 2D és 3D világ között sokszor iszonyatos különbségek vannak. Ezt én egyébként el tudom fogadni, mert én globális random generált környezetként tekintek elsősorban a hadjáratra és másodsorban jön az, hogy egyes dolgoknak hosszútávú következménye is van. -
#50544
Külsős modderek helyzete mindig is ez volt. Miért nem léptél be a BMS csapatba, akkor az alapjátékot lehetne kalapálnod, nem külsős mod-okat, amit ki tudja egyáltalán mennyien használnak utána... -
#50543
A Falcon esetén sem az szab gátat, hogy leprogramozzák az egyes dolgokat, hanem visszamenőleg mi legyen az adatbázissal. Mert az új 3D modellek úgy készültek, hogy azokon a kerékforgás és lánctalp mozgatása működni fog. (Tudtommal.) Ok. És mi legyen a tonnányi régi modellel? A kivételt is le kell programozni és a DB-vel összelinkelni vagy a kódban - ez szar, mert ha DB-ben turkálsz, akkor szétcsúszik az egész - vagy a DB kiegészítése szükséges. Ezért van az, hogy egy rakás új dat fájl is van a 4.33-ban a 4.32-höz képest vagy meglevő dat fájlokban új sorok.
Én meg ezért léptem ki a F4 moddolásból. Mire befejezek egy modot kijön a köv major version ---> kuka az egész. Nekem ehhez már se időm se türelmem. Sajnos ez az átka annak, ha egy 20+ éves felépítésű játékot kalapál az ember. Egy MiG-21-est lehet a vétlenségig pimpelni, akkor sem lesz olyan a burkolat alatt, mint egy F-35 ami egészen más elvek szerint készült.
Utoljára szerkesztette: molnibalage83, 2018.11.19. 08:11:23 -
#50542
A számítógép nem ismeri magától a fizikát. Bármilyen egyszerűnek tűnő dolgot akarsz szimulálni, az azért problémás mindig, mert ezeket a fizikai szimulációkat valós időben, vagy közel valós időben kell számolnia, másodpercenként több alkalommal frissítve. Ez rengeteg proci időt visz el.
CloDnál tudok egy példát mondani, igaz, ez nem kifejezetten mozgáshoz tartozó szimuláció volt, hanem hanghoz. Az egyik programozónk rájött, hogy a CloD-ban nem voltak limitálva az egy időben hallhajó hangforrások maximális számai. Ez egy pancser programozási hiba, talán nem gondolták fontosnak, nem tudjuk, de a lényeg, hogy mégis benne maradt. Többek közt ez azt okozta, hogy amikor egy repülőgép áthúzott egy nagy kötelék bombázó között, akkor az összes közelben lévő bombázó hangját számolta, nem csak a legközelebbi 8-10-et. Ráadásul ezt még megtetézték azzal, hogy a hangforrások mozgásából keletkező doppler hullámhossz torzulást másodpercenként (!) 60 alkalommal számolta újra a program. Nyilván hangforrásonként. Ez a két dolog együtt azt okozta, hogy a mindenkori proci leterhelés felét (!) a hang számolása vitte el, ha sok gép volt egy helyen. A hangforrások le lettek normális értékre húzva, és most már csak másodpercenként 5 vagy 10 alkalommal változik a hangmagasság, ha elhúzol egy gép mellett. És az a vicc, hogy nem csak rengeteg fps-t spóroltunk meg ezzel, de soha senkinek nem tűnt fel, hogy a hangokban egyáltalán változott volna valami.
Sajnos a fizikai szimulációk nagy hátránya, hogy rengeteg prociidőt visznek el, és nincsenek tekintettel a terhelésre sem. Az újabb game engine-ek (UE4) például már tudnak olyat, hogy ha proci terehlés nagyon felugrik, akkor egyszerűsít a fizikai modellezésen. Ami papíron jól hangzik, de gyakorlatban ekkor szoktak egyből glitch-elni, hibázni a szimulációban lévő dolgok.
Utoljára szerkesztette: VO101Tom, 2018.11.19. 02:32:33 -
#50541
A Falcon esetén így működik, nézd meg a vadászgépek kerekét. Mivel ez ennyire egyszerűbb ennél elbaszottabb modellezés csak az lenne, ha állandó forgási sebességet állítanának be, tehát nem fognak.
Folyamatosan nem létező problémákat hoztál fel. -
#50540
Nem, inkább te nem érted, hogy mit szeretnék mondani, de nehéz elmagyarázni.
És megint más ha mást gondolnak egy egy szóról emberek mint amit eredetileg én.
Neked ha leírom, hogy fizika akkor egyből az ugrik be, hogy súrlódási együtthatótól kezdve a bogárpiszokig mindent leszimuláljanak.
Nekem meg annyit, hogy ami a valóságban forog az forogjon és ne csak úgy tűnjön.De érdekes, hogy Tomnak sikerül megérteni és példákon keresztül még meg is magyarázni azt amit nem tudok a hátteréről.
Míg Neked bár szintén fogalmad sincs róla ,de hülyének próbálsz beállítani ,hogy nem értem a dolgokat.
Amiket felsoroltál mindennel tisztába vagyok ,de ahogy Tom is írta, nem mindig így működik ahogy leírtad, úgyhogy te sem érted.
-
#50539
Én úgy látom most sem érted...
1. A Falcon esetén egyszerű, mert csak vízszintes síkok vannak, nincs valódi terep.
2. A járművek mozgási sebessége ismert.
3. A geometriai méretek is.
1+2+3 = annyit kell csinálni, hogy a haladási sebesség a talajhoz képest az legyen kerületi sebesség a lánctalp vagy kerék mozgatásánál, aztán a többi elemnél geometriai kényszer van az egyetlen mozgó elemhez, abból számolnak.
Az Outerra szintű engine és land based sim az egészen más, mert ott bizony talajmodellezés van, súrlódási együttható, azzal számolnak valódi hajtóerő, hogy mi és hogyan mozog.
A nagy semmin rugózol. -
#50538
Egy lánctalpat szemenként lemodellezni, és a láncszemek mozgását egyenként számolni hidd el, hogy se nem egyszerűbb, se nem kerül kevesebb erőforrásba, mint trextúrából megoldani, pláne ha olyan dologról van szó, mint egy lánctalp egy repszimbe, ami kb huszad rendű dolog.
-
#50537
pont ez az, hogy néha a matek és a fizika hiányzik a dolgokbol és inkább oldják meg optikai csalódások modjával.
Ez ami furcsa néha.
-
#50536
Ez matematika és fizika, kényszerek és leíró függvények és egyszerűsítő absztrakciók. Az, hogy mivel és hogyan programozod le azt már más tészta.
Azért jobb, mert kevésbé erőforrás igényesebb kb. minden esetben. Nincs valódi fizika a legtöbb szimulátorban földi egységeknél kivéve a szárazföldi szimulátoroknál.
Utoljára szerkesztette: molnibalage83, 2018.11.18. 19:22:08 -
#50535
igen, mert nem ismerem a programozást (sajnos) igy csak arról az oldalról tudom a problémákat megközeliteni amit a valóságban tapasztalok és igy is oldanám meg .
De mindig örülök amikor érthetően példákkal bemutatva valaki elmagyarázza, hogy még mit hogy lehet.
Mindamellett még mindig nem értem miért jobb egy mesterségesen kreált megoldást kitalálni egy problémára, mint ami a valóságban tesz? -
#50534
Az egész kommentedet nem értem. Most akkor elromlik valami vagy sem...? -
#50533
Repvez, szerintem most nagyon másfelé jársz, mint ahogy ezek működnek, nem is tudom pontosan hol kezdjem. Az fps-nek semmi köze ahhoz, hogy melyik animáció milyen sebességgel játszódik le, a video szerkesztő programok szokták bizonyos animációkat frame számhoz mérni, de ez egy játék, itt a képkockák számának semmi jelentősége*. Az animáció az idő alapú. Van egy kerék a modellen (a kerekeket nem szokták textúrából animálni, ha nem statikus modellek, akkor azok tényleg forognak, mert az egyszerűbb), annak a keréknek van egy átmérője, ami egyértelműen megadja a kerületét. Ez meghatározza, hogy ha a játékban a modell mondjuk 10km/h-val halad, akkor mekkora szögelfordulással kell a keréknek forognia, hogy a talajon az ne csússzon el. Ezeket az értékeket egyszer kell a játéknak megadni, ami a 3D modell installálásakor megtörténik, onnantól az engine számolja, hogy ha azt mozgatja X sebességgel, akkor Y szögelfordulással forgatja a kerekeket is. Meg lehet adni neki melyik tengert forgassa ha a kerék kanyarodik, meg kell neki adni a tengelyek pontos helyét (Hook-al vagy Pivot-al), és ezzel több dolgod nincs, a játék engine csinálja a többit.
A lánctalp láncszemeinek mozgását oldották meg másképp, például a CloDban úgy, hogy a lánc UV-ja menetirányban csempézhető, és az alap láncszem textúrát 1/3 mértékben offseteli (eltolja) mindkét irányba. Ebből lesz egy 3 frame-es animációd, amikor a lánctalp látszólag elcsúszik a felületen. Hogy melyik után melyiket tölti be, és milyen sebességgel váltja őket, az az installálás után már megint az engine feladata. De ezt is csak egyszer kell jól beállítani, utána a modell teljesen jól fog mozogni.
Pl nézd meg ezt, rögtön az elejétől. Ott a tank lánctalpja nem mozog, az a 3D modell, ami a láncszemeket mutatja, az egy teljesen statikus "gyűrű", ami végigfut a kerekek alatt és felett. A futó görgők azok forognak, azzal a sebességgel amit a kerületük meghatároz.
https://www.youtube.com/watch?v=t6xGuqK42TU
Szerintem ez teljesen jó anim akármilyen játékhoz, nem igazán értem milyen problémákat goldolsz, hogy ezzel lenne bármikor.
*FPS játékokban van olyan, hogy a frame-ekkel van összekötve pl az egér mintavételi freki, off a nagyobb fps finomabb egérmozgást is eredményez, de annak sincs semmi köze az animációkhoz. -
#50532
most komolyan mindent szó szerint értesz és nem tudsz elvonatkoztatni ,hogy ez csak egy példa volt, ha 56fpst irok akkor meg az lett volna, hogy az honnan jött?
Amúgy meg régen ez volt a max crt monitor frissitési freki ezért a 75. -
#50531
Mi ez a 75 FPS...? -
#50530
igen ugy gondoltam, hogy miért nem egyszerübb azt ugy megcsinálni , hogy ami forog az forogjon ami nem azt nem, de igy hogy csak a texturával trükköznek azt elöbb utobb kibukik, hogy valami nem jó és utána nehezebb javitani.
Mert amikor készitik akkor arra gondolnak, hogy mire lenne olyan gép aminél ez elöjöhet már senki nem használja, erre itt van a falcon ami még 20 év után is használunk és mondjuk amit ugy terveztek , hogy max 75 fpsig még jó,de fölötte már a frissitési frekvencia vagy egyéb más idözitéshez kapcsolódó dolog meg elromlik , és most meg 160fpsel játszol vele és nem érted, hogy miért nem jó.
Viszont ha ugy csináloo, hogy eleve forogjon akkor mindegy, hogy mit csinálsz az akor is frogni fog évk mulva is.
Nem azt akartam, hogy minden apró részlet ugy legyen mint a valóságban, de az alapmozgásokat legalább ugy kezelje. -
#50529
Arra gondolt, hogy a kerekek csak úgy forognak mindig azonos sebességgel attól függetlenül, hogy pl. mennyire gyorsan mozognak. Tehát a talaj-jármű interakció vagy legalább a jármű sebességéből jön. A legHC-b megközelítés meg a szárazföldi szim, ahol elvileg a valós fizikai motor számolja ki a csúszástól kezdve mindent.
Ez meg a működő változat. Asszem ez már méltó lesz az eseményhez.
-
#50528
Nem értem, hogy mire gondolsz ezzel a "valós dolgokkal". A számítógépnek mindent számolnia kell, olyan nincs, hogy bedobsz egy akármit és akkor az majd úgy működik magától mint a valóságban tenné. Vannak programok, amikben a gyakorlatban talán így néz ki, de hidd el a háttérben ott is rengeteg dolgot számol az az engine amivel épp dolgozol.
Ha fizikai szimulációt húzol be a játékba, az a proci idő borzalmas nagy részét elviszi, realtime játékoknál ezért van MINDEN hülyére egyszerűsítve, ami nem feltétlen fontos. Fizikai szimuláció kell a repüléshez, de qrvára semmi szükség egy lánctalphoz. Azt majd animálják textúrából.
Persze lehet, hogy vannak játékok, amik pl láncszemenként lemodellezték a lánctalpat, csontokat adnak hozzá, és azt animálják, de ott valszeg ez egy elég fontos része a játéknak (tankszimulátorok pl). Viszont ők spórolhatnak az aerodinamikai modellezésen, meteorológiai jellemzőkön, fegyverek mennyiségén meg eleve a bejárható térkép méretén.
A minden apróságra ráhúzott fizikai modellezés pl tök jól működhet a renderelt filmeknél, ahol van arra idő és számolási kapacitás, hogy egy egyperces jelenetet hetekig számoljanak a munkaállomások. Ott az számít, hogy jól és hihetően nézzen ki, az nem szempont, hogy normális fps-el fusson. -
#50527
Sikerült hang nélkül renderelni... -
#50526
Egy kis gyurmázás után még inkább hasonló lett az eredetihez.
Utoljára szerkesztette: molnibalage83, 2018.11.18. 13:31:11 -
#50525
Én sem ugy gondoltam, csak ha valaki vette az affinitást, hogy átirja akkor ahhoz kello idö állt rendelkezésére, hogy jó eséllyel végezzen az utólsó nagy javitás ota.
A mobiltelefonra van egy alkalmazás a Trinus VR , abban van egy ilyen menüpont, hogy ki lehet választani, hogy 3d vagy fake3d modon dolgozzon, az utobbit olyanoknál érdemes ha olyan játékot probálsz aminek nincs nativ vr támogatottsága, pl meg lehetett oldani a cod4 meg hasonlo korabeli játékokkal is a 3d nézetet, pedig azoknak még hirböl sem volt ilyen támogatottságuk, igy értem.
DE a falconnál valahogy még igy sem sikerül stereo képet alkotni hozzá.
A kerékmozgásnál meg azért irtam, mert én mindig abbol indulok ki, hogy a valós dolgokat könnyebb lenne beletenni, minthogy kitalálni egy olyan dolgot ami csak ugy néz ki mintha közbe meg nem. mert mig az elöbbinél lehet, hogy hosszadalmasabb elkésziteni, de könnyebb a hibákat és a helyes müködést ellenörizni, mint egy mesterségesen teremtett helyzetet aminél nem várt hibák jöhetnek elö.
