Pokaż wiadomości
Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.
Tak, korzystam prawie codziennie z dostępnych materiałów. Przydaje się :) A to czego nie pokrywają (pewnie coś zmieniało się w czasie), muszę uzupełniać czytaniem źródeł exe.Jak przeczytasz coś nowego to dopisz na Wiki, niech ta dokumentacja żyje bo ja ostatnio nie mam czasu ani weny na szamynę :)
Nie chciałbyś Ty, żeby wyszło takie narzędzie, ale myślę, że większość społeczności ma odmienne zdanie.No OK, nie widzę przeciwwskazań, żeby powstawały super trasy, zrobione przez ludzi w dwie godziny, po wcześniejszych dwóch godzinach zapoznawania się z edytorem. Być może jest to możliwe — ja poświęciłem kilkanaście tysięcy godzin na tworzenie edytora oraz tras w nim, a nadal nie umiem tego robić dobrze. Chyba jedynie nie chciałbym, żeby taki edytor plansz do gry był uznawany za główne narzędzie do tworzenia tras do symulatora. Ale być może zbytnio i niepotrzebnie zasugerowałem się, że ktoś chce zrobić jakiś faktyczny symulator czegoś, a nie grę o pociągach.
Naprawdę w nosie mam, czy jest zrobiona porządnie krzywa przejściowa (pozdrawiam nadgorliwców z TD2), czy inne rzeczy i pewnie większość młodzieży też (widać po FB jaka średnia wieku komentuje). Na to i tak w większości przypadków nikt nie będzie zwracał uwagi, tylko jeździł i cieszył się z całości scenerii.Ja widzę różnicę pomiędzy jazdą po łuku z krzywą przejściową, a łukiem, gdzie jej nie ma. Gdyby w MaSzynie była lepsza fizyka bujania kabiną (której nie zdążyłem zrobić), to brak krzywej przejściowej byłby dla wszystkich oczywisty i zauważalny. Jeśli komuś nie zależy na realizmie symulacji, to równie dobrze może pograć w Timberborn, tam się łatwo plansze edytuje i na ile oglądałem (bo jeszcze nie zdążyłem zagrać), bardziej wciąga niż pociągi — polecam.
Za to można się latami "podniecać" cudownym narzędziem, który pozwala ułożyć tory co do mm jak w rzeczywistości, generatorem terenu co do centymetrów, a efektu w postaci finalnych scenerii od kilku, może i nawet kilkunastu lat brak.Tory zostały ułożone około 2013 roku, kolej piaskowa, prawie całe dolnośląskie, trasa z Katowic do Herbów, z Łodzi do Torunia... Ale się symulacja sypała i pociągi wariowały, więc nie było sensu tego udostępniać (tzn. np. autor miał wątpliwości, a ja nie nalegałem). A potem zostałem uznany za hamującego rozwój sabotażystę, zarzucono mi, że chcę produkować komercyjne pulpity i następnie pobierać opłaty za lepszą wersję MaSzyny. W końcu się udało wyprowadzić kod MaSzyny poza licencję MaSzyny, dzięki czemu podobno MaSzyna "zaczęła się rozwijać zgodnie z oczekiwaniami użytkowników". No i było 8 lat na to, żeby udowodnić mi, jak bardzo się myliłem. Nikomu nie broniłem zrobić wspaniałego edytora i robić trasy nim. Ba, nadal można to robić, ja chętnie zapoznam się z efektami.
No i może mam trochę skrzywienie, bo ciągle przed oczami mam to:No to w pewnym sensie zostałem wywołany do tablicy (chyba nikogo więcej z tamtej ekipy tu nie ma oprócz matek__9292), bo między innymi ja brałem w tym udział. Założenia były jakie były, wyszło z tego co wyszło.
I bardzo bym nie chciał, żeby powstała kolejna odsłona tak niesamowitego narzędzia do edycji... ;)
Jeżeli ogarnięcie edytora będzie zajmowało godzinę-dwie, a nie wiele dni/tygodni, to już samo w sobie może przynieść duże oszczędności czasu na przyszłość. A na pewno użytkownikowi końcowemu będzie się bardziej chciało.Nie każdy będzie miał tyle czasu, a proponowanie jedynie narzędzi dla prawdziwych elit i robienia tylko i wyłącznie superrealistycznych tras na najwyższym poziomie w tempie 1km/1000 godzin będzie działać na szkodę symulatora, bo większość ludzi się odbije.Jak ktoś nie ma czasu, to po co mu symulator? Można pograć w Bobry, podobno fajna gra. ;) I własne plansze też można robić, nie jest to bardzo wymagające. Większość ludzi chyba już się odbiła. I raczej nie przeze mnie, bo przez ostatnie 8 lat się nie wtrącałem. Każdy mógł robić, co tylko chciał i zachwycić innych swoją własną wizją rozwoju.
Nie no, nie idźmy w tą stronę. Co bym sobie wyobrażał to liczne kontekstualne podpowiedzi (np. opisy obiektów, gdzie co się stawia, itp.), a co z tym użytkownik zrobi to już jego sprawa. Jakieś ważniejsze/podstawowe wyciągi z zasad projektowania linii kolejowych. Coś a'la http://www.kontrakt-bhp.com.pl/paul/projektowanie/ (swoją drogą - bardzo polecam), ale zintegrowane w edytor i częściowo zautomatyzowane (np. kalkulator prędkości na torze o zadanym promieniu).Dlaczego twierdzisz, że to jest złe? Poza oczywiście faktem, że to nie doczekało się światła dziennego.To nie jest złe, to jest edytor plansz do gry. Nie wymaga od użytkownika żadnej wiedzy o budownictwie kolejowym ani odniesień do rzeczywistości. Po prostu klikasz i po chwili możesz mieć własne Bizonowo. W dalszej kolejności można by dodać losowe wstawianie wskaźników i lokomotywy sterowane strzałkami.
Z mojego punktu widzenia, kwestie terenu i układania torów zostały dawno rozwiązane i nie ma potrzeby się nad nimi pochylać.Z mojego nie. Brakuje intuicyjności, wszystko jest tępe do obsługi i wymaga szkoleń i kursów, co sam zresztą widzisz, bo sam takie kursy również organizujesz. Nie każdy będzie miał tyle czasu, a proponowanie jedynie narzędzi dla prawdziwych elit i robienia tylko i wyłącznie superrealistycznych tras na najwyższym poziomie w tempie 1km/1000 godzin będzie działać na szkodę symulatora, bo większość ludzi się odbije.
No i może mam trochę skrzywienie, bo ciągle przed oczami mam to:Dlaczego twierdzisz, że to jest złe? Poza oczywiście faktem, że to nie doczekało się światła dziennego.
I bardzo bym nie chciał, żeby powstała kolejna odsłona tak niesamowitego narzędzia do edycji... ;)
Mnie chodzi o to, że proste fixy (oraz review) idzie zrobić właśnie na tekście, plus do tego tekst jest scm-friendly.Kto miałby to robić? Chociaż ja mogę mieć skrzywione postrzeganie, bo patrzę głównie na geometrię torów. Ostatnio wypłynęła sytuacja z Całkowem, gdzie była zepsuta geometria na moście (chyba od początku istnienia tej scenerii). Zaproponowanie korekty zajęło mi dosyć dużo czasu, a mam 15 lat doświadczenia w układaniu torów... Są scenerie, na których drzewa wchodzą w tory... Wystarczy zaobserwować w scenerii, ustalić orientacyjnie pozycję, wczytać scenerię do Rainsted i odszukać obiekt do przesunięcia (edytor SCM podaje nazwę pliku i linijkę wpisu). I mimo to nie ma kto poprawić, zaglądając do plików tekstowych — za duży próg wejścia. Ponieważ dla mnie poprawienie niektórych rzeczy jest trywialne, wolałbym aby powstała możliwość zrobienia zrzutu ekranu, zaznaczenia na nim czegoś oraz opisania, co jest źle i dlaczego, a następnie wysłania tego na serwer. Gdyby taki system istniał, to następnie osoba odpowiedzialna za dany fragment poprawiałaby to albo argumentowała za innym rozwiązaniem, po zapoznaniu się z sytuacją. Ja w Linii 61 (którą głównie naciągałem na mapy, a której wygląd i funkcjonalność teoretycznie były już dopracowane wcześniej) wiem o istnieniu całej masy różnych błędów — tylko po co mam poprawiać rzeczy, na które nikt nie zwraca uwagi? Wszyscy już scenerię objechali w 2007 roku, to po co coś w niej poprawiać? "Nie poprawiajmy starych, tylko róbmy nowe." — z tych samych niedopracowanych cegiełek, które nie zachowują spójności i są źródłem błędów... Aż mi się przypominają czasy samoobracających się wskaźników W27...
Ladując scn/inc do edytora nie wiem co jest foliage, a co terenem. Mogę tylko odróżnić node triangles od reszty, i je ewentualnie połączyć dla tych samych deklaracji materiału. A i tu może być deklaracja inline, albo przez .mat.To jest dopiero początek zamieszania... Dlatego ja mam cały algorytm "heurystyczny", który przy wczytywaniu SCN próbuje zgadywać, co jest czym. Co jest drzewem, co semaforem, a co słupkiem (czasami to się myli i muszę dodać wyjątek, gdy zauważę). Swego czasu powstał katalog obiektów, w którym do plików INC dopisane są kategorie. Nie jest to dopracowane, ponieważ nikomu się nie chciało zrobić z tym porządku... Co gorsza, nie są unormowane kąty wstawienia niektórych obiektów, np. niektórych wskaźników We, półbramek, więc dodatkowo trzeba skąd wiedzieć, które obiekty są odwrotnie, niż by się mogło wydawać na podstawie innych obiektów tego typu. A jeszcze jest kwestia przesunięcia w pionie, z czym też bywa różnie.
Ogólnie widać 20 lat długu technicznego.No tak to jest, jak się dorabia shadery, zamiast zacząć od uporządkowania podstawowych elementów składowych, żeby miały jakiś sens i były solidną bazą. Potem już nie ma nikogo odpowiedzialnego i czekamy, aż ktoś ostatni zgasi światło.
Grzebanie w uszkodzonej binarce to w praktyce oznacza koniec - porzucenie lokalnych zmian i przywrócenie poprzedniej wersji.Format RSF ma strukturę bazy danych, która jest pokłosiem moich doświadczeń z uszkodzonymi dyskami. Podstawowy rekord danych ma 128 bajtów, na jego początku 4 bajty określają sposób interpretacji pozostałych 124. Teoretycznie odzyskanie danych z uszkodzonego dysku pozwala odtworzyć zawartość RSF, nawet jeśli została zagubiona kolejność sektorów — będzie brakować tylko tych obiektów, których odczytanie nie było możliwe. No ale obecnie chyba dyski się mniej uszkadzają. Efektem poniekąd ubocznym jest możliwość sklejenia dwóch plików RSF razem przy użyciu bardzo prostych narzędzi (np. COPY /B).
Ja się nie wypowiem w kwesti adaptacji RSF w EXE.Chodziło mi tylko o to, że format RSF był projektowany z myślą o zastąpieniu nim formatu SCN, dzięki czemu odpadłyby operacje, które są wykonywane podczas wczytywania oraz po wczytaniu. W efekcie sceneria by się wczytywała szybciej i kawałkami, przez co można by dynamicznie doczytywać fragmenty podczas jazdy. Przez ostatnie 8 lat nie zaproponowano alternatywnego rozwiązania w tym zakresie. Zastanawiałem się nad zrobieniem wczytywania RSF do MaSzyny, miało to służyć początkowo jako podgląd 3D do edytora RSF. Ale póki co mam inne zajęcia i w dającym się przewidzieć czasie się za to nie zabiorę. Sens używania formatu tekstowego zanegowałem w 2008 roku, po próbach ustawienia profilu pionowego na scenerii "PMPPW".
Sam edytor powinien pracować na plikach tekstowych, które są przyjazne dla człowieka i VCS typu Git.Jako że integrowałem klony scenerii przy użyciu SVN, jak również robiłem na plikach tekstowych inne operacje (obracanie scenerii "Kaliska", dzielenie dużych scenerii na mniejsze fragmenty), to mogę powiedzieć, że format tekstowy robi więcej problemów niż daje korzyści. Główne problemy to brak powiązań pomiędzy obiektami, literówki prowadzące do uszkodzeń obiektów, setki zmian widocznych w systemach śledzenia po drobnych korektach obiektów (np. nieznaczna korekta promienia łuku zmienia kilkanaście odcinków torów oraz kilkadziesiąt słupów i przęseł sieci trakcyjnej). Śledzenie zmian w scenerii przy użyciu SVN jest absurdem. O ile jeszcze byłem w stanie przejrzeć z uwagą 200 zmian, to już przy ilościach idących w kilkanaście tysięcy zmian dopatrzenie się błędu i skorygowanie go na poziomie systemu śledzenia wersji jest nierealne. Obecnie ograniczam śledzenie wersji do przeglądania torów (zmiany geometrii, nazw, przypisanie sygnalizacji), oraz sygnalizacji (zmiany nazw obiektów oraz połączeń), natomiast sieć trakcyjną czy otoczenie weryfikuję wyłącznie wizualnie (może oprócz łączenia sieci na granicy komórek).
Przy okazji - czy podtorze generuje Rainsted? Scala je z rzeźbą terenu?Częściowo tak. Tzn. obecnie istnieje możliwość wczytania punktów wysokościowych (domyślnie NMT-100 albo istniejących trójkątów scenerii, np. fikcyjnych) i modelowania przekrojów poprzecznych podtorza pomiędzy linią niwelety (w uproszczeniu: poziom szyn) a terenem wyznaczonym z tych punktów. Mając przekroje podtorza można je zszyć z trójkątami terenu (z NMT-100) albo ścianami lasu, których dolna krawędź jest ustawiania wg punktów wysokościowych (lub trójkątów terenu).
Problem jest taki, że dokumentacja formatu RSF nie jest dostępna publicznie.To nie jest problem rzeczywiście istniejący. O dokumentację formatu RSF nikt nigdy nie pytał. Coś tam na ten temat pisałem, ale wobec totalnego braku zainteresowania nie chciało mi się wytwarzać bezużytecznych materiałów. Zwłaszcza, że ciągle dopracowywałem szczegóły i pewne rzeczy się zmieniały. Planowałem w 2015 roku wczytywanie z RSF do MaSzyny, po czym ktoś uznał, że nie warto tego robić i nie napotkałem na dyskusję, czemu taka decyzja i co zostało zaproponowane w zamian. Po 8 latach widać, że raczej nic.
Uważam, że każdy edytor powinien mieć swój własny format pliku projektu, a import projektów z innych edytorów opcjonalny i potencjalnie stratny. Zawsze znajdzie się coś, czego format nie obsługuje, a chcemy zapisywać. Na przykład komentarze w sceneriach.OK, zróbcie sobie sami, co chcecie. Zawsze można od nowa rozwiązywać problemy, które już zostały dawno rozwiązane. Tylko zróbcie więcej, niż obiecywacze, którzy na bazie hejtu na mnie zebrali popularność w 2015 roku i następnie jakoś w nieustalonych okolicznościach zniknęli. Ja mogę poczekać na gotowe. RSF obsługuje komentarze przy konwersji danych z SCN, aczkolwiek ich przydatność uważam za znikomą. W ramach Rainsted mam zrobiony system obsługi notatek do scenerii, w którym można do wskazanego miejsca przyczepić plik z opisem, a następnie dodawać w nim kolejne uwagi (np. postęp prac). System ten miał jeszcze współpracować z serwerem i zgłaszaniem błędów przez stronę internetową, ale to jest na razie zawieszone i na razie nie wiem, czy kiedyś dokończę. Format RSF ma również opcje rozbudowy i jeśli "czegoś nie obsługuje", to istnieją algorytmy, jak coś dodać, aby nie zepsuć.
- Oddzielny manager dodatków.Nie wiem, czy nie odbiłoby się to negatywnie na prędkość szukania plików, kiedy mamy dużo addonów. Chociaż w sumie symulator na starcie mógłby skanować cały folder addons. A jak rozwiązywane by były kolizje w nazwach?
- Rozważyć, czy exe nie powinien dodatkowo obsługiwać nowych ścieżek do addonsów (w schemacie addons/<id>/<wszystkie pliki dodatku>)
- Website z dodatkami (właściwie indeks, content mógłby leżeć gdziekolwiek)Z tym gdziekolwiek bym się nie zapędzał, bo pliki hostowane gdziekolwiek lubią po jakimś czasie znikać.
- Jedno docelowe repozytorium dla exeW sumie poniekąd mamy, ale jest to zdecydowanie zbyt słabo rozpowszechniona wiedza - branch sim z githuba Milka7 (https://github.com/Milek7/maszyna/tree/sim).
- Wyznaczyć cele makro (żeby wiedzieć co warto, a czego nie warto robić z exe)W tej chwili to najlepiej solidnie posprzątać i zoptymalizować program tak, by wycisnąć więcej wydajności (prace nad tym są prowadzone, patrz co napisał @MichauSto na mattermoście).
- Wyznaczyć więcej osób do review i mergowania PRObawiam się, że Milek będzie stanowczo przeciw. W końcu jego stanowisko to albo on, albo nikt.
- Usprawnić cykl wydawniczy (dev buildy, stable buildy, release branche do testow i stabilizacji) - ten punkt ma zabezpieczyć przed wejściem na stable nieewidentnych baboliW sumie i tak mało kto podmienia exe, chociaż jeśli paczkowe miałyby być generowane automatycznie, to nie jest głupi pomysł.
Ad. 2Jestem otwarty na dyskusje.
Co wracam do exe, to rozbijam się o nieustalony coding standards i nieprzeformatowany kod, co utrudnia merge / rozwiązywanie konfliktów. Mam też uwagę, że źródła są prawie płasko w jednym katalogu - przydałby się sensowniejszy podział na podkatalogi (zrobiłem próbę czegoś takiego - kompiluje się, a lata się po plikach wygodniej). Przed zaproszeniem większej liczby osób warto byłoby to ogarnąć.
Prosty edytor, z prostymi funkcjami de facto stworzy (ewentualnie na amen zabetonuje już istniejący) standard maszynowych scenerii- prostych, płaskich naleśników z mało realnym układem torowym. Chyba jestem trochę rozpieszczony Bieszczadami albo nową L61, ale moim zdaniem, to właśnie powinien być nowy standard. Pozornie głupia rzecz, jaką jest profil pionowy, diametralnie zmienia przyjemność z prowadzenia pociągu. Nie nadrobi się tego ciekawą dekoracją.Z jednej strony tak, jednak z drugiej skomplikowanie narzędzi jest obecnie zbyt duże, żeby początkujące osoby miały jakąkolwiek szansę się wykazać. Wymaganie od nowicjusza stworzenia trasy realnej z profilem pionowym i wiernie odwzorowanym otoczeniem to jak wymaganie od pierwszoklasisty obliczania całek. Nie każdy musi jeździć sceneriami z "piaskownicy". Nie każdy będzie miał też talent. Ale prosty edytor może takie talenty odkryć, na przykład wśród osób, które obecnie nie mają konta na forum.
Rainsted być może jest skomplikowany, mój kontakt z jego funkcjami edycyjnymi jest skromny. Ale to skomplikowanie daje możliwości. Blender tudzież Gimp też są skomplikowane, też właściwie użyte dają super efekty, jednak nie ma tutaj głosów, aby pierwszego zastąpić chociażby jakimś Sketchup-em a drugiego windowsowym Paintem.
edytor F11 jest banalnie prosty i nie ma tutaj mowy o żadnym learning curve. Wejść i zacząć się nim bawić może każdy, a kwestią do wyuczenia po prostu jest to, jak dekorować, żeby było ładnie.No to lecimy. Wiem, że trochę prowokuję, ale chcę pokazać, dlaczego wciąż garstka osób będzie się od tego edytora odbijać.
Jak wyżej: niwelety z hektometrami i załomami, linie kierunkowe, oraz parametry łuku określające krzywe przejściowe i przechyłki. Importując scny do Ry tracimy praktycznie najważniejsze dane.
Dzięki. Wiem już więcej i już rozumiem ideę. Rainsted pełni rolę nie tyle edytora SCN, co generatora SCN (Rainsted edytuje swoje pliki).
EDIT: Pytanie pomocnicze - czy niwelety z hektometrami, albo linie kierunkowe, są potrzebne dla dróg i rzek? Oglądałem video, gdzie robiona jest droga i twórca musi ręcznie nastawiać odcinkom drogi jakieś kody szesnastkowe, nastawiać tekstury i korygować wysokość na przechyłce, bo się asfalt źle renderuje. Nie jest to przekombinowane?
Temat nie osiągalny. Rainsted korzysta ze swojego formatu plików roboczych.Dzięki za informacje. Czyli Rainsted nie potrafi otwierać SCN? Bo próbowałem to robić i nie udało mi się.
Jeśli chodzi o odcinki to opieram się na strukturze https://wiki.eu07.pl/index.php/Obiekt_node::track
Wiem już, że Rainsted ma swoje pliki robocze.
Czy w tych plikach roboczych Rainsteda zawarte są informacje, których nie ma już w node::track, a które są Wam potrzebne do pracy ze scenerią? Jakiś przykład?
Wygląda na to, że ustawienia yes/no już nie są aktualne i wraz z nowymi funkcjami, które finalnie trafiły do exe Milka (niestety nie ma go w aktualizacji 22.11) zmieniło się sterowanie z eu07.ini.
- UART- rozbudowa o nowe parametry (zachowana kompatybilność wsteczna- obsługiwane po wykryciu),
3 Polubienia
uartfeature main|scnd|train|local|radiovolume|radiochannelWyłączenie danej funkcji odbywa się poprzez usunięcie wpisu znajdującego się między pionowymi liniami. Nie będzie zatem wstecznej kompatybilności bo zmienił się zupełnie sposób konfigurowania zarówno dotychczasowych jak i dwóch nowych funkcji.Czy na potencjometry dajecie jakieś filtry lowpass? Może jakiś kondensator? Np. wartości 1uF? Bo sieje mi na inne wtyki Analog Input.To nie jest "sianie" tylko pojemności na wejściu ADC, już za mux-em. Chodzi o to, że w większości uC masz jeden przetwornik ADC i multiplexer. Aby wykonać poprawny pomiar należałoby najpierw zrobić presampling do masy lub długo poczekać na przeładowanie się pojemności (długi czas próbkowania).