Od jakiegoś czasu (chyba powinienem zacząć: dawno, dawno temu ) nosiłem się ze sprawdzeniem ZSPK w TS12, głównie z lenistwa, nie chciało mi się robić iluś tam przejazdów do mapki. Moje chęci przyspieszyło pewne odkrycie związane z małą przebudową torów, otóż zauważyłem, iż mając już stworzoną sesję, kiedy przebudowuje tory, to wywala mi je w kosmos, podobne problemy miał Jamal podczas budowy swojej mapy właśnie przy ZSPK Erniego. Poszedłszy po rozum do głowy, zresztą jak wyżej wspomniałem pchany lenistwem ustawiłem sobie taką ZSPK na mapie uprzednio wywalając sesję (tak, wiem tracimy ustawienia semaforów itp. ale o tym później).
W geodecie wygląda to tak:
Jak widzicie zastosowałem dwie Uniwersalne płyty przejazdowe, a to z racji stosowania moich dróg jednokierunkowych. Obie płyty podłączyłem do jednego Kontrolera przejazdowego (tą akcję miałem już sprawdzoną wcześniej, chyba jeszcze w TRS2004) i to działa.
Oto przykład:
Aha, ciężarówka która nie chce ruszyć po otwarciu rogatek, w końcu ruszyła, musiałem wyłączyć nagrywanie badziewnym programem Action! (nie polecam). Dźwięku też nie ma z powodu ww. programu.
Teraz rodzi się pytanie, czy warto robić nowy ZSPK, czy tylko ten przerobić. IMO problemem w już istniejącym może być tylko ustawienie punktów przyłączania w Kontrolerze i płytach, choć mogę się mylić i po prostu taki psi urok Trainza (wszystkie psy z góry przepraszam )
Aha, zapomniałbym, wszystkie ustawienia takiego przejazdu, jak i semaforów i przemysłu można zrobić tylko w mapie, nie trzeba, a nawet nie radzę tworzyć sesji, która będzie w ostatecznej wersji mapy. Można oczywiście tworzyć sesje testowe, ale po jazdach radzę je wyrzucić. Sesje robimy dopiero po skończeniu mapy.
Ostatnio zmieniony przez drstrach 14-08-2012, 23:12, w całości zmieniany 2 razy
Teraz rodzi się pytanie, czy warto robić nowy ZSPK, czy tylko ten przerobić.
IMO robić.
I tak źródeł nie ma, to raz.
Ten system używa "składu" do zamknięcia przejazdu - to dwa (bez sensu, istnieje jakiś "consist" tylko po to, żeby zamykać przejazd).
Nie wszystkie kombinacje (wielotory i w stacji) działają prawidłowo - to trzy.
Nowa koncepcja opiera się na zamykaniu przejazdu poprzez wewnętrzną komendę przesyłaną z triggera zamykającego lub otwierającego do przejazdu, bez pośrednictwa "pojazdu". Patent z płytą przejazdową zostaje, ale przejazd nie będzie miał "toru", a tylko "drogę". Na ile się wczytałem w skryptologię - to "dasię", nawet obsługę stacji powinno się udać upchnąć. I można dodatkowo przerobić nieco sygnalizę, żeby można było uzależniać też semafory od zamknięcia przejazdu w obrębie stacji (a dokładniej semafor może zamykać przejazd). Do tego oczywiście TOP-y, dzwonki, rogatki, trąbki, pompki i lewarki - stare ZWD i Erniego tez "mają działać"
Nie wszystkie kombinacje (wielotory i w stacji) działają prawidłowo - to trzy.
To fakt, równoczesny lub prawie równoczesny najazd dwóch składów blokował sygnalizację
RBach napisał/a:
nawet obsługę stacji powinno się udać upchnąć.
A w poprzedniej nie działało, ja tam bawiłem się tylko na stacji i IMO było to najlepsze KP jakie znam
Czyli mam rozumieć, że jeśli będzie za sygnalizację odpowiadała komenda z triggera, to będzie też komenda z maszynisty? Zolw się ucieszy
Ale póki co, stara działa w wyższych wersjach i swobodnie można ją stosować.
Czyli mam rozumieć, że jeśli będzie za sygnalizację odpowiadała komenda z triggera, to będzie też komenda z maszynisty? Zolw się ucieszy
Nie bardzo, chyba że kupi sobie 2010 Pod jego TC chodzi to, co jest, a ja poniżej 09 nie będę tego robić. Wystarczy że semafory mam w dwóch wersjach, obłędu idzie dostać. Ewentualnie nowy skrypt spróbuję naskrobać tak, żeby chodził od 2006 do 2549123486
Z własnego doświadczenia, a trochę tych przejazdów zrobiłem, wiem że tak jak wspomnieli przedmówcy ZSPK Erniego wywalało i blokowało się przy większych stacjach (w archaicznym 04 od tego potrafiły powstawać nawet fatal errory). Poza tym nie jestem miłośnikiem skryptowania, a nie oszukujmy się z tym była chwila zabawy.
Jeżeli jest możliwość zrobienia czegoś nowego, na nowsze wersje, w sumie dla potomnych to róbcie. Jeśli wam się chcę. A jeżeli uprościcie skryptowanie przejazdów i, tak jak piszecie, uzależnicie to m.in od semaforów to będziecie wielcy.
Pytanie nasuwa się jedno - skoro będzie to uzależniane od semafora, to rozumiem że tylko od jego wskazania. Co w przypadku gdy semafor taki jest przed przejazdem (co jest mega częste) i skład po przejechaniu wywoła na nim S1? Będzie potrzebne zastosowanie z drugiej strony jakiegoś triggera otwierającego. Tak więc trzebaby uważać właśnie na takie niuanse.
Ale ja się nie znam na skryptologii.
Tak BTW - w 04 skrypty w nadmiarze mega obniżały wydajność TRS'a, jak to ma się do tych TSowskich wersji przykładu 09+?
Jeżeli jest możliwość zrobienia czegoś nowego, na nowsze wersje, w sumie dla potomnych to róbcie. Jeśli wam się chcę. A jeżeli uprościcie skryptowanie przejazdów i, tak jak piszecie, uzależnicie to m.in od semaforów to będziecie wielcy.
Nie wiem, czy to się zaliczy do "uproszczenia", bo konfiguracja będzie prawie identyczna (i tak debilnie prosta): trzeba będzie podać listę triggerów zamykających i otwierających. Konfigurację TOPów i rogatek robi się tak samo - poprzez nazwę. Zmiany bardziej "pod maską".
KGrid napisał/a:
Pytanie nasuwa się jedno - skoro będzie to uzależniane od semafora, to rozumiem że tylko od jego wskazania. Co w przypadku gdy semafor taki jest przed przejazdem (co jest mega częste) i skład po przejechaniu wywoła na nim S1? Będzie potrzebne zastosowanie z drugiej strony jakiegoś triggera otwierającego. Tak więc trzebaby uważać właśnie na takie niuanse.
Nowe pzejazdy muszą mieć jakieś triggery zamykające/otwierające, bo NIE będą połączone z torem "jezdnym". Więc i tak trigger otwierający będzie, semafor zastąpi jedynie trigger zamykający (przejmie jego funkcję). Zależność prędzej zrobię w drugą stronę - nie zamknięty przejazd - nie podasz semafora. Ot, awaria. Wtedy trzeba by było z menu semafora podać ręcznie Sz, jak w prawdziwych urządzeniach
KGrid napisał/a:
Tak BTW - w 04 skrypty w nadmiarze mega obniżały wydajność TRS'a, jak to ma się do tych TSowskich wersji przykładu 09+?
Wiesz, tak naprawdę KAŻDY element (poza statycznymi domkami i drzewkami) ma skrypt. Tylko go "nie widać" z poziomu twórcy.
Robiąc np przejazd - nadajesz mu kind MOCrossing. Ten kind jest jakby "klasą nadrzędną", posiadającą skrypt wyposażony we wszystko, co potrzeba do działania (czyli tzw. zachowanie standardowe, dla przejazdów jest to np te słynne 300m, z których zamyka się przejazd). Więc twórca dodatku-przejazdu, nie chcąc zmieniać zachowania się tegoż, nie pisze DEDYKOWANEGO skryptu, a używa istniejącego (przypisanego wewnętrznie do kind MOCrossing), nawet nieświadomie (gra sama to robi obsługując kind przejazd). Dopiero zmiana tego domyślnego zachowania wymaga własnego skryptu, który zastępuje ten wbudowany, i dopiero ten własny skrypt musi być w postaci pliku z literkami (czyli nasze gs/gse) i jako taki jest widoczny przy przeglądaniu folderu dodatku.
Inny przykład: semafory (Błeee. Znowu ): Robiąc tzw "semafor wbudowany" określasz mu "states", czyli stany, w jakich może się on znajdować (Stój, pomarańczowe, zielone i tak dalej). Do tego do każdego z tych "states" przypisujesz światła, które mają się zapalać. Ponieważ to "wbudowany" semafor - pliku skryptu nie dajesz. To co w takim razie steruje tymi światłami? Co wykrywa pociąg za i przed semaforem? Ano skrypt. Ale ten "wbudowany", przypisany wewnętrznie do kind MOSignal, którego twórca samego semafora na oczy nie widział, ale używa go i konfiguruje, określając właśnie "states" i "aspects"
Może zamulanie 2004 wynikało z kiepskiej obsługi skryptów (oidp to były tam ograniczenia co do przydzielanej pamięci i tak dalej). W TS2010 już tego nie ma, zresztą z powodów podanych wyżej, skryptowanie własnych dodatków to podmiana skryptu. Inna sprawa, że kiepsko napisany skrypt może zamulać, ale ja przynajmniej staram się produkować kod w miarę efektywny
Nie możesz pisać nowych tematów Nie możesz odpowiadać w tematach Nie możesz zmieniać swoich postów Nie możesz usuwać swoich postów Nie możesz głosować w ankietach