PKS

Użytkownicy
  • Zawartość

    18
  • Rejestracja

  • Ostatnia wizyta

Reputacja

4

O PKS

  • Tytuł
    Nowicjusz
  1. Trochę odkop, ale pytano mnie, jak wygląda kwestia modowania gier stworzonych dzięki Unity, Unreal Engine 4 i Torque 3D. Podzielę się z Wami zdobytą wiedzą, może komuś się to przyda. Nie będę tutaj opisywał tych silników, trochę faktów już zamieściłem w tym temacie. Nie jestem informatykiem, żadnego z tych silników nie znam od podszewki –> poniższe informacje mogą nie być do końca zgodne z prawdą. Udanej lektury! 1) Torque3D Strona silnika Download najnowszej wersji - obecnie 3.8 (Windows oraz Linux) Repozytorium z kodem źródłowym silnika Silnik dostępny całkowicie za darmo. Bez żadnych ograniczeń można edytować kod źródłowy, tworzyć i wydawać swoje gry. Nie trzeba się dzielić zyskami z autorami silnika. O modowaniu: w grę wbudowany jest edytor dający szerokie pole do popisu: edycja świata (sceny), terenu, efektów cząsteczkowych (particles), rzek, dróg, materiału przypisanego do danego modelu, generowanie prostych modeli 3d; możliwe różne operacje na plikach, datablockach itd. własny język skryptowy - TorqueScript, pisze się w nim właściwy kod gry. Ogromne znaczenie ma to, że skrypty mogą być edytowane przez użytkownika bez użycia specjalistycznego oprogramowania - wystarczy choćby Notatnik. Nie wymagają kompilacji, wystarczy zapisać zmiany, żeby silnik je "zauważył". Torque3D wczytuje modele 3d (meshe) głównie w formacie .DAE <- modele można tworzyć m. in. w Blenderze, można również edytować już istniejące, dodane do gry. tekstury są zazwyczaj w formacie .DDS -> potrzebny np. Gimp czy Paint .NET, w odróżnieniu od Unity czy Unreal Engine 4, Torque3D podczas tworzenia gry nie zmienia formatu assetów (modeli, tekstur, plików z dźwiękami itd.), wiele rzeczy można edytować dzięki samemu Notatnikowi, Konkluzja: do modowania gier stworzonych dzięki Torque3D wystarczą: Notatnik (choć bardziej polecam Notepad++), Blender, Gimp/Paint .NET <- wszystko za darmo. Schody zaczynają się dopiero, gdy chcemy poprzez skrypt odnieść się do funkcji niezaimplementowanej w kodzie silnika - napisany jest on w C++. Należy wtedy zmodyfikować kod i skompilować silnik na nowo. 2) Unity Podstawowe informacje o silniku są w pierwszym poście. O modowaniu: domyślnie Unity konwertuje wszystkie assety do swojego własnego formatu .assets, co właściwie wyklucza ich edycję po stworzeniu gry. istnieją narzędzia, które potrafią rozpakować pliki .assets i AssetBundle. W języku polskim poczytacie o nich tutaj: KLIK. Dzięki nim możemy uzyskać m. in. tekstury w formacie .DDS, pliki o rozszerzeniu .115 - po zmianie rozszerzenia na .js można je otworzyć w programie Visual Studio lub Notepad++ - mają zapis szesnastkowy, pliki dźwiękowe, modele (meshe), niektóre pliki tekstowe. Prymitywne modowanie mogłoby wyglądać tak: rozpakowujesz plik .assets -> edytujesz konkretną teksturę, dźwięk, model (mesh) czy plik z zapisem szesnastkowym -> zapisujesz plik .assets ze zmienioną zawartością. Teoretycznie możliwe, w praktyce: zmieniony plik .assets i wszystkie składowe muszą mieć dokładnie tę samą nazwę i ten sam rozmiar co pierwotnie (w jednym źródle była informacja, że mogą być też mniejsze od pierwotnych, nigdy większe!). Unity daje możliwość wczytywania określonej zawartości z zewnątrz (z wybranego folderu na dysku lub z serwera). Zawartość ta nie znajduje się w pliku .assets, jej format ani rozszerzenie nie zostają zmienione przez Unity = możliwość późniejszej edycji/podmiany. Za wczytywanie tych plików odpowiada klasa WWW. Dotyczy to: AssetBundles (o tym niżej), plików z dźwiękami (formaty: Ogg, MP3 - aplikacje mobilne, WAV, XM, IT, MOD oraz S3M), plików .bytes, filmików (Ogg Theora), tekstu (kodowanie UTF-8 lub ASCII), tekstur (ale tylko .jpg i .png mogą być wczytywane dzięki klasie WWW). Istnieje szereg dodatków stworzonych przez użytkowników Unity (dostępne w AssetStore), spora część jest za darmo. Umożliwiają one m. in. pracę z plikami .xml, użycie języka skryptowego (np. LUA). Kilka słów o GameObject: Jest to większy element gry, np. postać gracza, pojazd, mapa. Składa się z komponentów, np.: model 3D (mesh), materiały i tekstury, siatka kolizji, dźwięki, skrypty opisujące zachowanie obiektu i inne. Każdy parametr ma szereg właściwości, które ustawia się w edytorze Unity, później korzysta z nich nasza aplikacja. Edytor Unity to uniwersalne narzędzie, umożliwia m. in.: tworzenie sceny, ustawienie kamer i oświetlenia, załadowanie modelu 3d, przypisanie mu odpowiednich materiałów i tekstur, określenie właściwości fizycznych obiektu, stworzenie skryptu i dołączenie go do danego obiektu. Znacznie ułatwia pracę nad własną grą. Najłatwiej jest tworzyć mody, korzystając z edytora Unity lub z własnego (np. wbudowanego w naszą aplikację), który jednak został stworzony dzięki temu silnikowi. Poszczególne assety robisz w swoim ulubionym oprogramowaniu i później łączysz to w całość w edytorze. Wygląda na to, że nie da się (albo będzie to bardzo ciężkie) stworzyć zaawansowanych modów (np. całych map, pojazdów) bez korzystania z edytora Unity. Bez zagłębiania się w tajniki obsługi silnika można zrobić tylko assety wczytywane przez klasę WWW oraz pliki tekstowe (np. .XML). Z myślą o umożliwieniu modowania gier w Unity stworzone zostały AssetBundles. Jest to dodatkowa zawartość gry stworzona po jej wydaniu (bez ingerencji w projekt/kod źródłowy całej gry) – zebrana w całość i „spakowana” w edytorze Unity – umieszczona na dysku twardym lub serwerze. Warto się z tym zapoznać: Obszerny tutorial dotyczący AssetBundles + AssetBundle Manager + dyskusja na forum Dokumentacja AssetBundle Manager i dołączone przykłady mogą stanowić świetną bazę pod grę, do której można robić mody. AssetBundle może zawierać wszystkie rodzaje assetów rozpoznawanych przez Unity – z jednym zastrzeżeniem: Jeżeli moder chce opublikować swoje skrypty, musi stworzyć (zobacz też i to) - nie wiem, jak to po polsku nazwać. Zwykłe dodanie skryptu (bez assembly) sprawi, że kod będzie traktowany jak tekst i nie zostanie wykonany. Dla wygody moderów twórca gry powinien postarać się zaimplementować wszystkie możliwe funkcje w kodzie źródłowym aplikacji – każdy mod miałby przypisany właściwy plik tekstowy z odpowiednimi wartościami różnych parametrów/opcjami. Coś na wzór pliku desc.bs1 znanego z vBusa czy plików .txt z różnymi ustawieniami znanych z projektu PKS 2015.Niedawno wydane zostało narzędzie ułatwiające tworzenie modów opartych na AssetBundles - UMod. Składa się z 2 części – płatnej UMod – potrzebna twórcy gry do wdrożenia obsługi modów i darmowej UMod Exporter – potrzebna twórcom modów. Unity umożliwia również zapisanie danych dotyczących całej sceny w postaci pliku tekstowego - Textual Scene File Format – edycja takich plików możliwa choćby w Notatniku. Nie wiem jednak, czy zmiany dokonane w takim tekście są widoczne w grze zaraz po zapisie i bez konieczności użycia edytora Unity, nie testowałem tego. Kod gry w Unity tworzy się dzięki Javascript lub C#. Można też pisać pluginy w postaci .DLL, które dodadzą nowe funkcjonalności do silnika/gry. Możliwe też tworzenie natywnych pluginów. 3) Unreal Engine 4 Podstawowe informacje o silniku są w pierwszym poście. Dla tych, którzy mieli styczność z Unity, przygotowano bardzo fajne wprowadzenie do Unreal Engine 4 – na zasadzie porównania obu silników i koncepcji programowania w C# (Unity) i czystym C++ (UE4). Grę tworzysz, używając systemu wizualnego skryptowania – Blueprint lub/oraz pisząc kod w C++. Dla porównania: Tworzymy grę od A do Z, korzystając z Blueprintów. Tworzymy grę od A do Z, korzystając z C++. O modowaniu: Sytuacja jest bardzo dynamiczna, wszystko „dostało kopa” po zmianie licencji silnika i udostępnieniu za darmo (pod pewnymi warunkami opisanymi w licencji) całego kodu źródłowego, Twórcy silnika twierdzą, że już podczas tworzenia UE4 myśleli o umożliwieniu użytkownikom modowania powstałych gier. UE4 posiada bardzo rozbudowany edytor. Podobnie jak w Unity – ładujesz stworzone przez siebie modele, tekstury, dźwięki itd., nadajesz im właściwości, przypisujesz odpowiednie akcje – sklejasz wszystko w całość i budujesz grę. W Unity wszystkie assety wykorzystywane przez daną grę (poza tymi wczytywanymi podczas działania aplikacji dzięki klasie WWW i AssetBundles) były pakowane w pliki .assets – np. 2 takie pliki przechowujące wszystko łącznie. UE4 również konwertuje multimedia do swojego własnego formatu - .uasset. Różnica jest taka, że 1 plik .uasset = 1 mesh/tekstura/dźwięk. Edytor UE4 umożliwia wczytanie takiego pliku i eksport do oryginalnego formatu – na pewno dostępny format .fbx dla modeli 3d. Nie wiem, jak z eksportem assetów innego typu. Wniosek: multimedia mogą być edytowane – po eksporcie do pierwotnego formatu – i zapisane po wprowadzeniu zmian jako nowy .uasset. Podczas budowania gry domyślnie wszystkie assety są pakowane – powstają pliki z rozszerzeniem .pak (bardzo podobne do .assets znanych z Unity). W banalny sposób można tego uniknąć – przed rozpoczęciem budowania aplikacji wystarczy odznaczyć opcję „Używaj plików .pak”. Możliwości związane z modowaniem gier powstałych dzięki UE4 bardzo dobrze obrazuje projekt ARK: Survival Evolved. Możecie o tym poczytać tutaj. Tworzysz główną aplikację (grę). Mody wykonane przez użytkowników będą traktowane jak pluginy. [ Tutaj jest prosty tutorial – pokazane krok po kroku, jak dodać mod do swojej gry. Główna aplikacja – gotowy szablon dołączony do silnika (Blueprint FPS Template), do tego mod składający się z 3 elementów – gamemode, mapa, główny bohater (gracz). Repozytorium ] Konieczna jest praca z edytorem Unreal Engine 4 – albo z jego „czystą” (dostarczoną przez producenta) wersją, albo z wersją zmodyfikowaną przez twórcę gry, do której robisz mod. Dzięki temu masz dostęp do wszystkich możliwości UE4. Nie ma żadnego problemu z umieszczaniem skryptów w modach – wszystko dzięki systemowi Blueprint. Jak zapewnia twórca ARK: Survival Evolved: Ważne: Zgodnie z licencją UE4 – gra i mody mogą być udostępniane wszędzie, w każdym miejscu w sieci. Zmodyfikowane: edytor UE4 oraz kod źródłowy silnika mogą być udostępniane TYLKO poprzez odpowiednie serwisy Epic Games – jako gałąź repozytorium GitHub, poprzez Epic Games Launcher, Marketplace itp. Firma zabezpiecza się w ten sposób przed kradzieżą ich rozwiązań. O ile dobrze rozumiem licencję, kod źródłowy gry może być udostępniany, o ile nie zawiera plików wchodzących w skład kodu silnika. Blueprinty mogą być tworzone i modyfikowane bezpośrednio w edytorze UE4. Powstało ciekawe narzędzie łączące Blueprinty ze skryptami napisanymi w LUA - skrypty te można modyfikować w dowolnym edytorze tekstowym, bez korzystania z edytora UE4. Na koniec kilka linków: (film na Youtube) Dział poświęcony modowaniu gier stworzonych dzięki UE4 na forum silnika Szybkie podsumowanie (mój subiektywny ranking): Wg prostoty dodawania modów/edycji assetów: Torque3D >> Unreal Engine 4 > Unity Wg stopnia rozbudowania silnika i jego możliwości: Unreal Engine 4 > Unity >> Torque3D Wg wielkości community (liczby użytkowników) i tworzonych przez nich tutoriali/dodatków: Unity > Unreal Engine 4 > Torque3D Wg liczby obsługiwanych platform: Unreal Engine 4 ~ Unity >>> Torque3D
  2. Interesujesz się grami komputerowymi? Zawsze ciekawiło Cię, jak to wszystko wygląda "od podszewki"? Chciałeś spróbować swoich sił w tworzeniu gier, ale nie wiedziałeś, jak masz się za to zabrać? A może po prostu nie było Cię stać na płacenie miesięcznego abonamentu za silnik z najwyższej półki? W tym miesiącu sporo się zmieniło na rynku gotowych silników. Światło dzienne ujrzało Unity w wersji 5 oraz zmieniono licencję UnrealEngine 4. Samo korzystanie z tych silników jest w pełni bezpłatne. Unity 5: http://unity3d.com/unity/personal-edition Unreal Engine 4: https://www.unrealengine.com/ Są to kompletne silniki, odpowiadające za każdy element gry - grafikę, fizykę, dźwięki, sieć (tryb multiplayer/gra w przeglądarce), skrypty, animacje itd. Ich możliwości są olbrzymie, o czym świadczą choćby dema technologiczne: Dla Unity 5: Dla UnrealEngine 4: Pokaz technologii 2 Interesujące wydają się VideoTutoriale typu "Gotowy przepis na grę - od A do Z, krok po kroku" przygotowane przez producenta danego silnika. Warto zobaczyć, dzięki nim można też sobie porównać te 2 silniki. Unity 5: Tworzymy grę - od A do Z Interesujący wydaje się być Stealth (można sobie włączyć napisy po angielsku) Unreal Engine 4: Tworzymy grę - od A do Z Dla nas, miłośników samochodów, ciekawy może być zwłaszcza ten: Time Attack Racer Kiedy trzeba zapłacić? Unity 5: Jeżeli wydajesz grę wykonaną z użyciem Unity 5 i Twój przychód osiąga STO TYSIĘCY dolarów, musisz kupić wersję Professional - jednorazowa opłata 1500 $ lub miesięczny abonament 75 $. Powiedzmy sobie szczerze - trochę czasu minie, zanim osiągnie się taki przychód (większość nigdy nie dosięgnie tej kwoty), a nawet jeśli się to uda, to jaki problem zapłacić 1500 dolców, jak ma się 100 tysięcy? Unreal Engine 4: Jeżeli w danym kwartale przychód z Twojej gry był mniejszy niż 3 tysiące dolarów, nie płacisz nic. Jeżeli przekroczył tę kwotę, płacisz 5% od przychodu. Plusem korzystania z tego silnika jest dostęp do pełnego kodu źródłowego. Chcesz pobawić się tym oprogramowaniem na własny użytek? Jeśli już wykonasz jakąś grę i będziesz chciał udostępnić ją za darmo lub za niewielką opłatą, nie zapłacisz NIC. Do dzieła! P. S. Celowo umieściłem temat w tym dziale a nie w "Gry komputerowe", ponieważ dotyczy on oprogramowania do tworzenia gier, a nie jakiejś konkretnej gry.
  3. Jako takie prace trwają, jest 3-osobowy zespół. Tworzą kod od zera, co wiąże się z tym, że prace idą dość wolnym tempem -> pamiętaj, że nad vBusem pracują amatorzy, robią to za darmo w czasie wolnym. Ostatnio podrzuciłem im jedno z gotowych rozwiązań, które być może mogłoby przyspieszyć prace (albo i je skomplikować, to oni wiedzą najlepiej, jakich "ficzerów" im potrzeba do tworzenia vBusa). Nie wiem, czy skorzystali z tego gotowego rozwiązania, czy jednak kontynuują pisanie kodu od zera. Po mapach jeździ się samemu, gdyż niewiele osób kwapiło się kiedykolwiek do tego, by wykonywać ruch do map. Kilka map warszawskich jest z ruchem - autobusy, tramwaje, samochody osobowe. Pamiętajmy jednak, że możliwości tego ruchu kończą się na poruszaniu się "kartonowych" pojazdów z określoną szybkością po ścieżkach. Wozy te nie wykazują żadnej "sztucznej inteligencji", nie ma tu nawet czego porównywać z AI w Omsi. Pamiętajmy też, że vBus zawsze miał i ma jeszcze jeden atut, którego niestety nigdy nie udało się w większym stopniu wykorzystać -> otwarty kod źródłowy. Kod Omsi jest zamknięty, tylko m&r software może nad nim pracować. Nad kodem vBusa mogło pracować wiele osób. Zwróćmy też uwagę na dość ciekawe zjawisko: Ludzie wolą tworzyć różne dodatki, narzędzia, mody, czyli de facto: rozwijać produkt niemiecki, za który trzeba zapłacić niż przyczynić się do rozwoju polskiej i darmowej aplikacji, jaką jest vBus. Skoro ktoś potrafi wykonywać wozy, mapy, tworzyć skrypty i zewnętrzne aplikacje do Omsi, to na pewno byłby w stanie robić to samo dla vBusa. Dlaczego zatem zamiast rozwijać coś, co jest nasze, polskie, z otwartym kodem i z dziesięcioletnią tradycją, woli się przyklaskiwać niemieckiemu produktowi, który wykonali zawodowcy w celach zarobkowych? Chętnie wymienia się wszędzie wady vBusa, pisze, że wstyd w to dziś grać, że to kaszana itd. Gdyby ci sami użytkownicy jakieś 5 lat temu wykazali takie zaangażowanie w vBusa, jakie wykazują dziś w Omsi, to vBus nie miałby sobie równych. Wesołych Świąt!
  4. Witam! Postanowiłem poczekać, aż Omsi 2 trafi do polskich sklepów w wersji BOX, dlatego też sam nie mogę przetestować nowej odsłony tego symulatora. Zastanawiam się, czy w nowej wersji zostały dodane różne długo wyczekiwane przeze mnie dodatkowe funkcjonalności. Głównie interesuje mnie, czy: - dołączone "fabrycznie" ( ) pojazdy szynowe są wyposażone w pulpit/deskę rozdzielczą, - jest możliwość "przejęcia" przez użytkownika pojazdu szynowego prowadzonego przez komputer (w Omsi 1 można było przejmować sterowanie nad autobusami, w przypadku pojazdów szynowych nie było to możliwe, pojazd wylatywał ze ścieżki i wydobywał z siebie dziwaczny jazgot), Trochę już rozjaśnił mi ten film prezentujący testy wozu Juliana w Omsi 2: Przede wszystkim widać (na przykład od okolic 20. minuty), że można samodzielnie przestawiać zwrotnice oraz zmienić kierunek jazdy pojazdu (łącznie ze zmianą używanego pantografu). - pasażerowie wsiadają do pojazdów szynowych sterowanych przez komputer (S-Bahn, pociąg), - można sprawić, aby samochody AI miały w dzień włączone światła mijania - albo jeszcze lepiej: czy można zdefiniować, jaki procent tych aut ma mieć włączone światła (w końcu w realu nie wszyscy kierowcy włączają światła, chociaż powinni), - można sprawić, aby na jednej mapie, na której jest kilka linii do wyboru, było dostępnych kilka różnych rodzajów biletów. (Inaczej: Chodzi mi o to, że np. we Wrocławiu mamy linie zwykłe i pospieszne. Bilety na linie pospieszne są nieco droższe od tych na linie zwykłe. Linia pospieszna "A" pokrywa się częściowo z linią 125, która (jak chyba wszyscy wiemy) jest dostępna w Omsi w skróconym przebiegu. Załóżmy, że chcę się przejechać wraz z pasażerami w Omsi 2 linią "A" skróconą do pl. Hirszfelda (no bo dalszego przebiegu na razie nie ma wykonanego). Jeśli pasażer chciałby kupić bilet, niech poprosi o bilet na linię pospieszną, a nie na zwykłą (jak 125). <- o to mi chodzi, czy można zdefiniować różne systemy taryfowe dla jednej mapy w Omsi 2. - czy pojazdy uprzywilejowane faktycznie jadą szybciej, czy inni ich przepuszczają, czy jadą na czerwonym świetle? - czy zrobiono wreszcie jakiś porządek z plikami .hof? Czy można utworzyć dla nich folder globalny, bez konieczności kopiowania wszystkich HOFów do poszczególnych folderów autobusów? To na razie tyle. Posiadacze Omsi 2, wypowiadajcie się P. S. mam nadzieję, że piszę we właściwym temacie.
  5. Witam! Jak w temacie - chciałbym się dowiedzieć, czy ktokolwiek z Was miał styczność z Unreal Development Kit lub\oraz z CryEngine3 SDK. Chodzi mi głównie o próby produkcji własnej gry z wykorzystaniem tych potężnych darmowych silników, a nie jedynie o tworzenie nowych leveli. Będę wdzięczny, jeśli zechcecie opisać swoje doświadczenia.
  6. Już od dawna istnieje możliwość wykonania ruchu ulicznego do map w vBusie. Służy do tego programik o nazwie Ped. Niestety możliwości takiego AI są znikome. Pojazdy AI (w większości "kartonowe") poruszają się po wytyczonych w programie ścieżkach z określoną szybkością - i tyle. Za AI odpowiadają pliki o rozszerzeniu .vt1 oraz .tr1 w folderze maps. Ich nazwa powinna być identyczna z nazwą pliku .ms1. Ja już od kilku lat zastanawiam się, jak mogłaby wyglądać zupełnie nowa odsłona vBusa, wielokrotnie sugerowałem różne rozwiązania na oficjalnym forum tamtego symulatora. Żyjemy w czasach, kiedy szeroko dostępne dla niekomercyjnego użytku stały się gotowe silniki z najwyższej światowej półki, jak na przykład CryEngine3, Unity3D, UDK (określany nieformalnie jako UnrealEngine 3,5). Dziś nie trzeba już marnować czasu na stworzenie kodu, który wyświetli na ekranie kolorowy kwadrat czy wczyta teksturę. Te czasy minęły, przynajmniej moim zdaniem. Wreszcie można skupić się na dodawaniu konkretnych funkcji, które będą potrzebne naszemu projektowi. Wiele osób widzi potrzebę stworzenia vBusa od nowa, ostatnio nawet niektórzy użytkownicy skarżą się już i na Omsi i nie są zachwyceni filmami prezentującymi możliwości Omsi 2 i jego ceną. Nie rozumiem, dlaczego nie można wykorzystać potencjału twórców map, wozów i skryptów dla Omsi i stworzyć wspólnymi siłami nowej wersji darmowego i polskiego symulatora - VirtualBusa. Na pewno byłaby to aplikacja znacznie lepsza technologicznie od Omsi (wystarczy sobie zerknąć choćby na "Features" UDK: http://www.unrealengine.com/en/features/), a dzięki wykorzystaniu gotowego silnika pierwsze efekty prac moglibyśmy zobaczyć już po kilku miesiącach. Ja się za to nie wezmę z prostej przyczyny: mam styczność z prawdziwymi autobusami niemalże codziennie i wiem, że żaden symulator nigdy nie odda wszystkich wrażeń związanych z jazdą "na żywo".
  7. Jak już jesteśmy przy dworcach (PKS i PKP), mam pytanie: Czy planujesz dodać zapowiedzi kursów PKS/pociągów przez megafon? Czy taka funkcjonalność jest w ogóle możliwa w Omsi? Do tej pory nie widziałem (a raczej nie słyszałem ) tego na żadnej mapie. Byłby to niezły bajer.
  8. M@nieK, do niektórych map (np. Usedom) są wykonane takie "podwójne" zapowiedzi. Pierwsza w stylu "Następny przystanek " i kolejna "". Ty decydujesz, kiedy naciśniesz Q i zapowiedź zostanie odtworzona. Jeśli masz na myśli automatyczne odtwarzanie (tak jak w wozie Juliana), to osoba znająca się dobrze na skryptach do Omsi bez żadnego problemu może napisać skrypt, który odtworzy pierwszą zapowiedź po przejechaniu np. 20 metrów od poprzedniego przystanku i następną po przejechaniu np. 60 metrów. Takie "bajery" są jak najbardziej obsługiwane przez obecne wersje Omsi.
  9. @norpo, co przez to rozumiesz? A w obecnej wersji Omsi nie jest to możliwe? Nie dałoby się odpowiednio rozbudować istniejących skryptów? Już w obecnej wersji można sobie utworzyć nowy folder w głównym folderze Omsi, nadać mu nazwę np. Zapowiedzi i zmodyfikować wpis w plikach .osc odpowiedzialnych za IBIS2 z: "Ansagen\" (L.$.act_busstop) $+ na: "..\..\..\Zapowiedzi\" (L.$.act_busstop) $+ Wrzucamy do folderu Zapowiedzi właściwe pliki dźwiękowe i gotowe. Nie wiem, czy można podobnie postąpić z plikami .hof. Chciałem wykonać dla nich jakiś "globalny" folder, wrzucić tam te pliki i tylko w folderze z Mercedesem Juliana zostawić te "dedykowane" dla tego wozu. Niestety nie wiem, czy można coś takiego zrobić i który plik należałoby zmodyfikować.
  10. @erap2, widziałem te screeny, ale nie mogłem znaleźć na oficjalnym niemieckim forum Omsi żadnych informacji od twórców symulatora na temat ich planów co do pojazdów szynowych. Wiem, że przed Omsi wydali oni jakiś dodatek do symulatora kolei, więc interesuje ich też ta tematyka. Widziałem, że w temacie dotyczącym nowości w Omsi 2 jest napisane, że możliwa będzie symulacja wózków trakcyjnych. Czy to oznacza, że będzie możliwe np. wykolejenie pojazdu szynowego i wykonanie wykrzywionych torów, na których będzie "rzucać" wozem? Widzę też, że twórcy rozważają umożliwienie użytkownikowi sterowania tramwajem (tzn. jako taka możliwość prowadzenia już jest, za pomocą klawiatury), więc nie wiem, co konkretnie mieliby dodać/udoskonalić. Wiecie coś na ten temat? Nie wiem, czy jest sens robić teraz mapy z trasami kolejowymi/tramwajowymi, jeżeli w Omsi 2 miałby być nowy system torów i wózków. Na pewno warto popróbować, ale pamiętajcie, że teraz jako taka symulacja jest na bardzo niskim poziomie, gdyż pojazdy nie jadą faktycznie po szynach, tylko poruszają się po ścieżkach. Pojazdy (tramwaje i lokomotywy) też obecnie nie są jeszcze wykonane z taką dokładnością jak autobusy. Właściwie są zrobione tylko "pudła", chyba że przegapiłem jakiś już dostępny wypasiony model. Warto szerzej pogadać o symulacji pojazdów szynowych z twórcami Omsi, ciekawe, jak oni do tego podchodzą.
  11. Julian ma o tyle dobrze, że może swobodnie kontaktować się z twórcami symulatora i przekazywać im różne swoje uwagi/sugestie i prosić ich o pomoc w tworzeniu skryptów/dodawaniu nowych funkcjonalności do swojego tramwaju. Wielu twórców dodatków spoza Niemiec nie ma takiej możliwości (choćby bariera językowa). Już pomijam fakt często niezrozumiałej składni skryptów (byłoby lepiej, gdyby przypominały one C++, ale nie można mieć wszystkiego). Jak widać na filmie, obecnie tram Juliana ma w pełni funkcjonalny tylko pierwszy człon (do pierwszego przegubu). Być może wraz z nową wersją symulatora i obsługą pojazdów przegubowych będzie lepiej. Jeśli ktoś jest zainteresowany tym dodatkiem i dobrze zna język niemiecki, to polecam temat: Tramwaj Juliana - postęp prac Jeśli chodzi o sam model pojazdu szynowego, to uważam, że BR275 dostępny wraz z symulatorem mógłby zostać rozbudowany albo przez twórców Omsi (co byłoby najlepszym rozwiązaniem), albo przez innego twórcę dodatków - jest to pewna "baza", należałoby dodać pulpit, IBIS, ścieżki pasażerów (o ile już nie są one zrobione), ewentualnie siedzenia, "oskryptować" to wszystko i pojazd byłby w pełni funkcjonalny. Na pewno jest już wykonanych wiele bardzo dobrych modeli pojazdów szynowych do MaSzyny czy ATS, które teoretycznie można przerzucić do Omsi. Słyszałem, że Rudiger interesuje się prywatnie transportem szynowym i podobno niektórzy użytkownicy Omsi namawiali go, by nieco rozwinąć możliwości pojazdów szynowych i ich realizm w symulatorze. Ponoć w wersji 2 mają być jakieś nowości z tym związane, ale nie wiem, na czym ma to dokładnie polegać. Być może wśród Was jest ktoś, kto regularnie czyta niemieckie forum symulatora i wie coś na ten temat. Widziałem na screenach, że mają być jakieś nowości, jeśli chodzi o tory kolejowe. (?) Interesuje mnie jeszcze jedna kwestia. W Omsi możemy "przejąć" kontrolę nad pojazdem sterowanym przez AI. Dotyczy to zwłaszcza autobusów. Z menu trzeba wybrać prowadzenie przez użytkownika i zaakceptować. W przypadku pojazdów szynowych to nie działa. Testowałem to na mapie Wehlen (bo tam jest dość ciekawa trasa kolejowa i ogólnie lubię tę mapę i jej klimat), chciałem "przejąć" BR275 i niestety nie jest to możliwe. Nie wiem, co jest tego przyczyną. Początkowo myślałem, że chodzi o to, że chcę prowadzić cały skład, a nie pojedynczy pojazd. Zmodyfikowałem AI list tej mapki, umieściłem tam ścieżkę do pliku .ovh od BR275 (a nie do pliku .zug) i usunąłem w tym pliku połączenie lokomotywy z wagonem. Po odpaleniu Omsi na szynach pojawiła się faktycznie tylko 1 lokomotywa prowadzona przez komputer a nie skład złożony z 6 elementów. Niestety nic to nie dało. Po wybraniu sterowania pojazdem przez użytkownika kamera w wozie zaczyna wariować, słychać jeden wielki jazgot i nie da się ruszyć. Nie wiem, czym jest to spowodowane. Czyżby pojazd w wyniku tego charakterystycznego podskoku "wypadł z szyn" i znalazł się poza ścieżką?
  12. Niestety nie mogę już edytować posta, muszę napisać nowy. Zrobiłem właśnie pewien eksperyment i okazało się, że wystarczy dopisać: [type] 2 w pliku .bus dowolnego autobusu (testowałem na oryginalnych MANach), żeby stał się on dla symulatora pojazdem szynowym i poruszał się po ścieżkach przeznaczonych dla tramwaju/pociągu Dla chcących to przetestować: 1. Otwierasz plik .bus danego modelu, np. MAN_SD85.bus 2. Dopisujesz gdziekolwiek (najlepiej na początku) właśnie to [type] 2 3. Zapisujesz zmiany. 4. Odpalasz Omsi i mapę Grundorf (tę oryginalną, pierwotną wersję). 5. Wybierasz z menu Nowy autobus (jakoś tak ), no i tam wybierasz MANa SD85, stawiasz go na mapie (wybierasz dowolne z 3 proponowanych miejsc, np. Eisendorf Krankenhaus) i pojazd powinien zostać umieszczony na torach kolejowych. Uruchamiasz wóz jak zwykle, wrzucasz bieg i ruszasz. Zauważysz, że pojazd jedzie "po torach" i że nie możesz kręcić kierownicą. Autobus stał się lokomotywą Po co o tym piszę? Być może niektórym przyda się ta wiedza, bo oto okazuje się, że do Omsi można wykonać funkcjonalny tramwaj/pociąg (z pulpitem, IBISem, otwieranymi/zamykanymi drzwiami, z bileterką, ze ścieżkami dla pasażerów) w sposób bardzo zbliżony do tego, w jaki wykonuje się autobusy. I okazuje się, że można taki pojazd stawiać na mapie od razu na torach, wystarczy zamieścić w pliku .bus te dwie linijki prezentowane powyżej.
  13. Witam! Nie wiem, czy dobry dział wybrałem, ale ten wydaje się najbardziej odpowiedni na tego typu temat. Od dłuższego czasu zastanawiam się, w jakim stopniu Omsi w obecnej wersji wspiera pojazdy szynowe. Do niedawna myślałem, że można ich używać jedynie jako pojazdy AI, ale ostatnio zobaczyłem film z prac Juliana nad jego modelem: i przekonałem się, że można tworzyć równie funkcjonalne tramwaje (i pociągi pewnie też) jak autobusy. Pytania do osób bardziej wdrożonych w Omsi i znających nowinki od twórców symulatora: Czy jest/ma być możliwe stworzenie w pełni funkcjonalnego tramwaju/pociągu (lokomotywy) do Omsi? Czy istnieje możliwość udoskonalenia i urealnienia szyn oraz wprowadzenia prawdziwych wózków jadących po tych szynach? Czy coś takiego mogłoby być obsługiwane przez obecną wersję symulatora, gdyby ktoś to porządnie wymodelował w programie 3d? Czy istnieje możliwość wykonania funkcjonalnych zwrotnic tramwajowych/kolejowych, które mogłyby być sterowane przez wirtualnego motorniczego za pomocą "nadajników podczerwieni"? Jak do tej pory mamy pociągi i tramwaje AI, które nie mają funkcjonalnych pulpitów/IBISów, nie mają porządnie wymodelowanego wnętrza. BR275 ma funkcjonalny "wyświetlacz" (obsługuje pliki .hof, kierunki ustawia się "ręcznie" w górnym menu symulatora), można w nim otwierać i zamykać drzwi, ale pasażerowie i tak do niego nie wsiadają. Do tego zdaje się, że pojazdy szynowe nie jadą faktycznie po torach, tylko poruszają się po ścieżkach zdefiniowanych przez twórcę danej mapy w edytorze. Doszedłem też do tego, że użytkownik bez większego problemu może sam zmodyfikować plik .ovh odpowiadający za dany tramwaj/pociąg tak, żeby pojazd był widoczny w menu wyboru pojazdu. Wtedy możemy sami postawić taki pojazd na mapie (działa np. na Grundorfie, Bad Kinzau, Landkreis Wehlen , Breslau), ustawić ręcznie kierunek w BR275 (po uprzednim opracowaniu pliku .hof) i ruszać w drogę (steruje się tak jak autobusem - gaz i hamulec). W niektórych modelach możemy też otwierać i zamykać drzwi. Ważne, żeby taki pojazd miał w swoim pliku .ovh zapis: [type] 2 Zapraszam do dyskusji, gdyż uważam, że Omsi to również znakomita baza do stworzenia symulatora pojazdów szynowych.
  14. Przestudiuj sobie pliki .zug w folderze Trains, tam zestawia się wirtualne składy. Dotyczy to pociągów jak i tramwajów. Polecam też temat: http://omnibussimulator.pl/Temat-Plik-zug-co-oznacza-0-lub-1?pid=57467#pid57467 Ponadto w pliku .ovh jest coś takiego jak: [couple_front]/[couple_back] Fahrzeug-Datei reverse (true/false) Tam określasz, z jakim pojazdem/wagonem domyślnie ma być połączony od przodu/od tyłu dany pojazd. Na przykład: [couple_back] br875.ovh true
  15. P. S. 2 Ad. punktu 4. Gdybyś był zainteresowany "wprawieniem w ruch" tego statycznego Konstala 105Na, to tu jest opis, jak to zrobić: http://omnibussimulator.pl/Temat-Konstal-105na-AI?pid=86188#pid86188 Nie mogę zamieścić paczki z poprawną wersją, bo nie wiem, czy autor wyraziłby zgodę.