Mint ahogy FB-n is írtam, a gond a sok Translate-tel lesz (szerintem). Anno a hivatalos oldalon volt fent ilyen kis szösszenet az építéssel kapcsolatban, ott írta Michelle, hogy a különféle transzformációk terhelik legjobban a gépeket, különösen ha az adott részen van transparent-es rész is (lehet az animációkra értette, de szerintem itt is ez lesz a gond).
Amúgy most olvasom végig, mit írtál a textúrákról is :D Ezek szerint nagy eséllyel lehet, az a gond. 14,8MB elég sok egy modellnek, pláne az openBVE-ben (OMSI-ban használtam 12MB-s képet legnagyobbként, de ott egy 300 méteres panelhez, és hát az OMSI erősebb program, mint az openBVE). Ha ezt 14x vesszük, megvan a gond. Szerintem első közelítésben csökkentsd le a méretüket (nem volna rossz 2 hatvány méretet használni (512, 1024...stb)), az jó eséllyel megoldja a dolgot. Ha nem egészen, még mindig ott marad a translate.
Ez lesz a gond szerintem amit leírtál. Próbáld meg, hogy kép méretén veszel lejebb, mert ezzel tapétázni lehet hátha segít valamit. Befolyásol a textúra méret és befolyásol ebben az esetben a vertex illetve translate, roatation szám is. Talán próbálhatod úgy is mint BVEmetróék, hogy külön szedték az állomásokat nem egybe tölti be hanem külön kiseb nagyobb darabokban, hátha ez is segít.
Van egy kis gubanc. Annyira nem is kicsi. Object wiewerbe nagyon lassan tölti be bikás állomást, a pályába pedig el se jutok oda. Állomásra ugrással nagy sokára sikerül, de oldalra borult szerelvénnyel.
Nem tudom hogy ez a textúrák méretei miatt van-e. A kupola nagy méretű képből van, és összesen 14 darab. 3980*1300 a mérete, és 14.8 mb/darab. A kupola egyébként 14db belülről textúrázott cylinder. A többi textúra nem nagy csak ezek.
Esetleg a sok áthelyezés (translate) miatt. Mert ez utóbbiból van sok. A b3d-ben is sok eltolás van, és az animated fájlban is sok a tologatás.
A kupola sok transparent részt is tartalmaz. Talán ez a baj.
Nincs valakinek ötlete hogy mi húzza le ennyire?
Elsődlegesen megpróbálom a textúrák méretét lecsökkenteni. Talán ez a nagy neki.
Amint az első tengely áthalad a tengelyszámlálón, vörösre vált a jelző. Ha kinézel az első kocsi ablakán, mire Te érsz a jelzőhöz, már vörös lesz. Szóval hülyeség, amit írtál.
openBVE-be zavaró mikor a mozdony elhalad a jelező mellett és vörösre vált holott vannak még mögötte kocsik valóságban ez úgy működik mikor a teljes szerelvény elhaladt akkor vált vörösre a jelző. Ezen lehet változtatni valamit, hogy kicsit élethűbb legyen?
Nem veled szurkálódok, csak kicsit a levegőbe: kár, hogy nem a valóságot adja vissza ez az állomás a képen sem, hanem a DBR (mostmár biztos tudni fogod kikről beszélek :D) fémjelzette vágyálmot, miszerint a felszínre kibuggyanó felépítmények hála a megállóba természetes fény szűrődik le. (A valóság ezzel szemben az, hogy a felépítmény gyakorlatilag kilóg a metrómegállóból, egy kis fény rászűrődik a mozgolépcsőre, ami amúgy is takarja az alatta lévő területet, a metróállomás nagy része meg félhomály. Geniális.)
Anno Ferenc7 még készített pár modellt amit remekül lehet pályákhoz használni, viszont az ő objektumai nem lettek oly módon openBVE-re kompatibilisek, hogy nincsen meg minden oldal az épületnek. Én megcsináltam mindegyik oldalát és textúrákkal láttam el. Ez lett a végeredmény:
Hú, te jó ég, mióta nem írtam itt Indán egy karaktert sem... De gondolom a túlnyomó többségetek már úgyis tudja, hogy a FB-s OpenBVE Hungarian Centrum csoportban továbbra is aktívan folytatom BVE-s tevékenységeimet.
Mint látjuk, a mi drága jó Tibink nemrégiben nagyon szépen rákapott a Budapest DBR projekt témára, és ahogyan alkot, az bizony nagyon magas színvonalt képez, Bvemetro-magasságokba helyezve a mércét, szóval állítom, hogy érdemes lesz rá várni! :)
Én az itteni szünet megkezdése óta nem sokat változtattam az általam megkezdett pályán, habár tegnapelőtt éjjel jó pár órát rászántam, hogy a való életben működő automatikához a szimulátor korlátaihoz képest a lehető legközelebb hozzam az MI általi vezetést. Így tehát ahogy a valóságban is, az ajtók a játékos beavatkozása nélkül nyílnak/záródnak, a vonat az állomásról meginduláskor először csak ~35 km/h-ig gyorsít, majd csak egy kis idő után gyorsít ismét rá a menetrend betartásához szükséges sebességre, az állomásra érkezés előtt pedig le is lassít ~35 km/h-ra, és csak a peron mellé éréskor kezd el ismét fékezni megállásig.
A megoldást videóra is vettem a frissített pálya kiadásakor, ha valakit érdekel, itt megnézheti, hogyan is néz ki a gyakorlatban, amit itt leírtam: https://www.youtube.com/watch?v=ey1UUVzsBGs
Hát ez így nem biztos hogy jó, mert hogy a mod-nak két paraméter kell ( Mod[a,b] )
Az mod osztója hiányzik a képletből, a kétobjektumos váltakozáshoz meg szerintem amúgyis kell a 2-vel való osztás, így különbözteti meg a páros és páratlan kimenetelt.
Ha a VALAMI-t elhagyjuk a szorzással együtt ( [time,2] ), akkor 1 mp-ként villog.
Ha a VALAMI=2 (azaz [time*2,2] ), akkor 0,5 mp-ként villog. Ha a VALAMI=4 (azaz [time*4,2] ), akkor 0,25 mp-ként villog, és így tovább. A VALAMI minél nagyobb értéke a villogás sűrűségét növeli.
A TÁVOLSÁG helyére beírod, hány méternél kell közelebb érni, hogy elkezdjen villogni, a VALAMI helyére pedig írsz egy kicsi számot (1-2 körül), ezzel szabályozva, milyen gyorsan villog. A többit értelemszerűen írd át.
A feltétel lehet sántít, pályán nem néztem meg, de elvileg jónak kéne lennie.
Megpróbálkoztam a pályakonvertálással, de nálam valami nem stimmel, beállítottam mindent a leírtak szerint, elindítottam, és utána lefagy a program, többszöri nekifutás után is ezt csinálja, ezért szeretnék kérni valamit. Ha valamelyikőtöknek van/vannak Hmmsim-hez konvertált pályátok, kérlek küldjétek el nekem a scaniamad kukac gmail pont com-ra. Az alappályán kívül 3-at sikerült megszereznem: 2-es villamos, MÁV 120a, Sellye-Pécs.
