63331
qK0ZIKA.jpgHivatalos Honlap | Hivatalos Fórum | Aerosoft | OMSI 2 Steam-en | OMSI SDK | OMSI+
Spoiler használat | Linkek beillesztése | Videó beszúrása | Képek beszúrása

OMSI The Bus Simulator 1 & 2 Topik


SZABÁLYZAT

Warez, vagy OMSI-hoz szorosan nem kapcsolódó témában látogass el ide:
OMSI 1 & 2 OFF, WAREZ TOPIC

  • Ikarusfan
    #61498
    Videó a troliról (persze ebben a videóban se úsztam meg a pirosat):

  • Ikarusfan
    #61497
    Ilyen kidolgozott kb ezen a pályán is a felsővezeték (talán még jobban is :D )
  • wollnerd #61496
    Usti nad Laben? :) [Az a kedvenc pályám amúgy.] Nagyon hangulatos pálya az.
    Divadlo és Sibiřská között van felsővezeték is. :)
  • Ikarusfan
    #61495
    Valami mindenképp, mert képeken elég nehéz visszaadni a hangját, de ez a pálya elég gagyi ehhez.
  • Norbesz23
    #61494
    Videó is lesz majd róla?
  • bajusza
    #61493
    szép járgány, gratula.
  • Ikarusfan
    #61492
    Tudom, előbb a villamos, most meg ez...


    Utoljára szerkesztette: Ikarusfan, 2017.07.12. 21:04:03
  • Ikarusfan
    #61491
    Geri kiegészítése alapján még annyit hozzátennék, hogy a antrieb_i_achse nevű csoda a híd áttétele. Ezt változtatva a fokozatok egymáshoz képest maradnak ugyanott, de az egész jelleggörbéje a járműnek elkenődik - ez is ha kisebb érték, akkor nagyobb sebesség, de kisebb gyorsulás lesz a vége, ha nagyobb, akkor meg jobb gyorsulás és kisebb száguldás.
  • Geri556
    #61490
    Azt azért hozzátenném, hogy a valóságban az összes városban használatos automata váltónak egyforma áttételei vannak, a hídtól függ a végsebesség.
  • Peti134
    #61489
    Köszönöm!
  • Ikarusfan
    #61488
    Áttételi viszony. És mivel fordulatszám/fordulatszám, ezért nincs mértékegysége.
    Minél nagyobb, annál kisebb lesz a végsebesség, viszont annál nagyobb a nyomaték, ergo jobban gyorsul. Ebből következik, hogy minél nagyobb a fokozat, annál kisebb ez a viszony.
  • Peti134
    #61487
    Üdvözlet!
    A váltószkript állítgatással kapcsolatban lenne a következő kérdésem:
    Ezek az [...]_ratio dolgok mivel vannak összefüggésben pontosan, illetve miféle mértékegység alapján működik?
  • Ikarusfan
    #61486
    Igen, nekem is eszembe jutott, hogy lehetne megállót lerakni az ilyen helyekre, és ezeknek a bemondása lenne a hang, de egy teszem azt épülő pályán nem ez az ideális megoldás.

    A sorompó a jármű közeledésével működik az OMSI-ban? És az működik bármilyen járművel, vagy csak vasúti járművel?
  • nemeza
    #61485
    Ahogy a (fény)sorompó is működik, szerintem meg. :)
    Az mindegy, hogy valamit mozgatni szeretnél, vagy hangot játszol le, a lényeg, hogy legyen trigger.

    Menetrend szerint közlekedő jármű esetén, ha a tárgy az útvonala mellett van, akkor scriptes trükközéssel is megoldható - lásd futár és más "GPS"-es társai
  • Ikarusfan
    #61484
    Igen, azt tudom, hogy lehet tereptárgyakhoz is plugin-t írni, csak ezt nem látom át én se, hogy hogyan kommunikálna. A GPS-es utastájékoztatók is ugye a megállókat érzékelik csupán, az meg nekem annyira nem játszik.
  • LnD
    #61483
    Pályaépítéshez is ugyanúgy lehet scripteket írni. A kérdés, hogy hogyan érzékelné a pálya a busz elhaladását (vagy fordítva).
    Utoljára szerkesztette: LnD, 2017.07.09. 19:27:32
  • Ikarusfan
    #61482
    Köszönöm a választ!

    Lenne egy elborultabb kérdésem is. Az megoldható, hogy a pálya egy adott pontján amikor elhalad ott a busz, megszólaljon egy hang? Tehát alapból nem szól, és ha elmész ott, akkor egy szimpla hangot lejátszik. Nem tudom, lehetséges ilyen scriptet írni egy scenery-hez, esetleg hogy a jármű játsszon le egy hangot egy külső hatás miatt?
  • nemeza
    #61481
    Tökéletes megoldás!
  • LnD
    #61480
    A triggert inkább ilyen kapcsolós, "beindítós" dolgokra használják, ez, mivel egy ismétlődő folyamat / folyamatos dolog (gondolom) így makróba tedd.
    Írhatsz neki egy totál újat is, vagy beteheted egy másikba is.
    Ha újat írsz akkor azt valahol be kell töltsd: (M.L.akármi)

    cockpit.osc-ben pl.:
    {macro:cockpit_frame} alatt van betöltve egy csomó makró, akár itt is betölthetsz egy újat (ezt a cockpit_frame makrót meg a main.osc-ben tölti be automatikusan).

    majd beírod a makrót magát:
    {macro:akármi}
    (L.L.Velocity) 0 >
    {if}
    1 (S.L.valami)
    {else}
    0 (S.L.valami)
    {endif}
    {end}

    Ha valamelyik már létező macro frame-be teszed, akkor a {macro:akármi} és {end} nem kell.
  • Ikarusfan
    #61479
    Tudom alantas dolog ilyet kérni, de valaki rá tudna erősen vezetni arra, hogyan kell egy olyan triggert (vagy változót) script-elni, ami akkor igaz, ha a jármű sebessége nullánál nagyobb?

    Ha jól sejtem, olyasmi jellegű lesz, hogy:

    sebesség 0 >
    {if}
    1 saját_változó
    {else}
    0 saját_változó

    Aztán lehet alapjaiban rossz amire gondolok (nem tudom, ezt még frame-be is vagy valami trigger-be is kéne tenni?). A végső célom az lenne, hogy egy jármű egy bizonyos hangot akkor hallasson, amikor mozog (meg ha gázt is ad az ember, de azt az M_wheel-es volcurve-vel lehet összehozni eddigi tapasztalataim szerint). Éppen ezért örülnék, ha valaki el tudná mondani, az adott script részletet mindegy-e melyik osc-be másolom, és mit kell írnom és melyik varlist fájlba ehhez.
  • Skinner_11
    #61478
    Azért gyorsabb a DDS mert olyan módon van tárolva, amit a videókártya/grafikus feldolgozó egység egyből tud használni és memóriába tölteni, nem kell átalakítania előtte.
  • Ikarusfan
    #61477
    És gondolom ez az oka annak is, miért kéne jobban futnia a DDS kiterjesztéssel, ugye? Hiszen abban alapból lehet mipmap-eket előállítani.
  • 242p1
    #61476
    Mikor a játékban megjelenik egy textúra a 3D megjelenítő a textúrákból mipmapokat generál, ami egy leméretezett másolata az eredeti textúrának. Minden mipmap oldalhossza egy 2-es hatvánnyival kisebb mint a felette lévő, például egy 1024x512-es textúra (2^10x2^9) mipmapjai 512x256 (2^9x2^8), 256x128 (2^8x2^7), 128x64, 64x32, 32x16, 16x8, 8x4, 4x2, 2x1. Ezt egyrészt textúra élsimításra használja keverve az eredeti és a csökkentett kép pixeleinek színértékeit, ezért nem pixelesen jelenik meg pl. a 256x256-os gyári macskakő textúra, másrészt ha messziről, vagy kis méretben látszik egy textúra akkor nem az eredetit jeleníti meg, hanem csak egy mipmapját, mivel kevesebb pixel jelenik meg, gyorsul a renderelési folyamat. A modern videokártyák és renderelő szoftverek támogatják a nem kettő hatványos textúrát és mipmap-et is, ilyenkor az oldalhossz feléhez legközelebb eső egész szám lesz a következő mipmap szint oldalhossza. Az OMSI az elég régi DirectX9-et használja, ami csak korlátozottan támogatja a nem kettő hatványos textúrákat, ez esetben a textúrának csak 1 mipmap szintje van, ami azt jelenti, hogy sok esetben feleslegesen nagy textúrát kell renderelni.
  • Peti134
    #61475
    A bitek számával kapcsolatos dolog elvileg, régen a lassabb processzorok/memóriakezelés miatt állítólag volt jelentősége, mostanra elvileg nincs, úgy tűnik ez alól kivétel ha valami olyan szarul van megírva mint az OMSI játékmotorja... Egyébként én is csak futólag hallottam róla, úgyhogy lehet hülyeséget írtam.
  • Ikarusfan
    #61474
    Egyébként tényleg, ennek a kettő hatvány dolognak mi a számítástechnikai alapja?
  • 242p1
    #61473
    Ami fontos még, hogy a textúrák oldalhossza 2 hatványa legyen, bizonyos programok (pl. Railworks) nem is eszik meg másmilyet. Szczeczin és Belgrád is azért fut pocsékul, mert random méretű (és ráadásul .jpg) textúrákat használnak az egyedi objektumaik. Én is próbáltam a DDS-t, buszon csak a fő textúrákat cseréltem arra, de nálam ~2 FPS-el kevesebb volt, mint TGA-val.
  • Skinner_11
    #61472
    Én nem teljesen ezt tapasztaltam. Akár a Microsoft alapú repülőszimulátoroknál, sőt a legtöbb DirectX 9 alapú játéknal a drawcall-ok számítanak. Egy drawcall egy megadott mennyiségű poligon és ahhoz a hozzárendelt texúra. Tehát nem feltétlen gond, ha sok a poligon, a lényeg az, hogy a lehető legkevesebb textúrafájl legyen használva. A másik dolog az, hogy milyen formátumot használ az ember. A .png nem játékokhoz lett kitalálva, ahogy a jpg sem... Lehet, hogy az OMSI kezeli ezeket, de érdemesebb tga-t használni. És bár csak "kísérleti módon" támogatja a dds-t a szimulátor, de én azt részesítem előnyben. Az összes modern game engine azt használja, mivel a videókártya dekódolja, így mindegyiknél gyorsabb mint amiket eddig felsoroltam. Persze ha nem integrált VGA-n futtatjuk az OMSI-t
  • spy803
    #61471
    Juhhu!
  • Ikarusfan
    #61470
    Befejeztem az 5-ös villamos vágányzatát:

  • Ikarusfan
    #61469
    Meg kell találni az aranyközéputat. Rondább modellekkel, de nagyobb, élesebb textúrákkal lehet (tapasztalataim szerint) a legjobb hatást elérni. Ezen kívül minél kevesebb textúrát kell használnia egy adott modellnek (ezt nem vettem figyelembe egy-két helyen, ott tényleg nem fut olyan jól), onanntól kezdve lehet szép eredményt is elérni fps tekintetében.
  • gumikacsa
    #61468
    Kár, hogy ilyen ronda kinézettel is erőmű kell a játékhoz. Pedig durva jó játék lenne.
    Anno azért hagytam abba a Gyöngyös-Eger-Heves vonalakat, mert ha olyan minőségben szerettem volna elkészíteni ahogy nekem is tetszik, attól már behalt a játék...
  • bajusza
    #61467
    alakul ez szépen, csak így tovább!
  • Ikarusfan
    #61466
    Időközben haladgatok szépen lassan a retro pályával is:

  • 242p1
    #61465
    Zsír, köszi :) ! Eredetileg úgy volt a szkript, hogy ha a 7 és 8 gombbal felkapcsolt világítás van felkapcsolva csak akkor kap értéket az AI_Interiorlight, de ha minhárom fel van kapcsolva, akkor már nem. Átírtam úgy, hogy bármelyik kettőt felkapcsolva jó.
  • LnD
    #61464
    (S.L.AI_Interiorlight) változó alapján panaszkodnak az utasok.
  • 242p1
    #61463
    Sziasztok! Ide még nem írtam, de a gsmmedia kihalt, úgyhogy ott nem is próbálkozom. Van ugye a fizetős 280-as add-on, azt kezdtem el feljavítani (hangok redes vágása, cserélése, ajtókapcsolók gyári működése, overdrive-os váltó, új lépéshangok), viszont van egy olyan probléma, hogy a fények szkriptjét eléggé elcseszték, emiatt az utasok panaszkodnak a kivilágított buszon, hogy sötét van. Megnéztem a scriptet, eredetileg a lights_beleuchtung_oberdeck és -||-unterdeck nem kapnak értéket (utóbbi nincs is eredetileg benne) ,ha kap is, csak addig, míg nincs másik beltéri fény felkapcsolva, mivel többek közt ezt a változót használják a lightmapokhoz, azok meg mások ha különböző fények világítanak. Maguk az utastéri lámpák többek közt a lights_beleuchtung_oberdeck_lamp nevű változóra voltak kötve. Átírtam a scriptet, a lightmapok saját változókat használnak, a két alap lights_beleuchtung_oberdeck és unterdeck pedig csak a saját kapcsolóitól függ és működik is rendesen+ a megfelelő utastéri lámpákat is ezekre kötöttem. A műszerfalon is csináltam egy-egy kontrollfényt, hogy lássam valóban kap-e értéket a két változó (igen), viszont az utasok továbbra is panaszkodnak a sötétre. Mi alapján nézi az OMSI, hogy elég világos van-e? Eddig úgy tudtam, hogy elég ha a lights_beleuchtung_oberdeck és unterdeck kap értéket, de ezek szerint nem...
  • Skinner_11
    #61462
    Igen. Létezik is pár alternatív ai-emberke pack, pl. ez, de ha jól tudom humans.txt nem cfg a fájlkiterjesztés.
  • matec1996
    #61461
    Sziasztok valaki nem tudja esetleg, hogy a Ikarus 395 mikor jelenik meg? Vagy esetleg van-e valami új busz?
  • Ikarusfan
    #61460
    Azt lehet befolyásolni, hogy milyen emberek legyenek egy pályán? Ami a maps/valami/humans.cfg-ben van, az erre való?
  • Edmond14
    #61459
    Köszönöm szépen!