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.
Jednak jak dotąd nie było nikogo chętnego, żeby to dokończyć albo zrobić jakoś lepiej. Tak więc rozjazdy w MaSzynie wyglądają badziewnie, niezależnie od tego, jakby tego nie ustawiać.
Gdzie można znaleźć taki głos, jaki jest użyty w plikach w sounds/sip?W domu youBy'a :)
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... ;)
Tak. Co gorsza, jest to robione na wczesnym etapie parsera, więc w czasie wczytania nie jest nijak wiadomo, że dane obiekty są zgrupowane np. w ramach semafora (chyba że ktoś to jakoś przerobił ostatnio). W efekcie edycja na poziomie MaSzyny nie jest w stanie wyprodukować zestawu danych, który można by zapisać i ponownie wczytać. A przynajmniej format nie jest... jakby to powiedzieć... odwracalny?Teraz jest jeszcze gorzej, bo jakiś czas temu doszło losowanie includów, więc zawartości docelowej nie da się już nawet przewidzieć. Ale przydaje się czasem, więc optuję za wprowadzeniem takiej możliwości również do nowego formatu modeli.
- 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ąć.
b) z jakiegoś powodu nie możemy materiału wykorzystać, więc... po co mieć działy z materiałami, których nie da się wykorzystać? I tak są bezużyteczne.Zawsze można próbować jeszcze załatwić zgodę, zamiast niszczyć czyjąś pracę nad np. konwersją modelu.
Jak ktoś robi coś tylko dlatego żeby mieć głupi napis przy nicku, to smutne to jest.A ja uważam, że ten napis to jednak trochę szpanu daje i satysfakcję z jego posiadania. No i na pierwszy rzut oka wiadomo, kto zrobił coś więcej dla projektu.
Od strony technicznej, docelowo najprawdopodobniej postawiony zostałby interfejs do gita, i zostałyby utworzone repozytoria:Czy drobne zmiany takie jak poprawienie literówki w skrypcie czy wrzucenie nowych/aktualizacja czcionek do wyświetlaczy także automatycznie tworzyłaby ticket w teście dodatków, i musiałbym czekać na aprobatę X osób? Z jednej strony skompletowanie wszystkiego jako jeden pull request ułatwiałoby instalację dodatków (patrz dźwięki Fordana), z drugiej wymuszałoby kompletność implementacji (plus dyskusje czy dać jako losowane czy zastąpić), z trzeciej nie trzeba by było tworzyć struktur katalogowych i mieć pewność, że wszystko leci w konkretne miejsce.
[...]
Zmiany mogłyby być proponowane przez każdego użytkownika utworzeniem pull request, po aprobacie N członków zespołu byłby automatycznie mergowane.