FORUM PTT -

NOWE - Lampy Grabash-a modyfikacja
P3t3r - 11-02-2013, 21:28
:
@RBach, a nie dałoby się tak, że jeśli nie wstawimy reguły to światła się zapalają defaultowo-trainzowo, czy jak mają w skrypcie napisane? Poza tym obecnie np. mamy regułę od zegarów i jakoś nie ma płaczu ;-) . Czemu tak nalegam na ten tryb domyślny? Bo chciałbym również pograć na obecnie wydanych mapach a przestawianie x-tysięcy lamp na x-dziesiąt map - dziękuję, pogram w bierki :mrgreen: Tym sposobem po prostu wgrywamy nowe lampy, wstawiamy regułę i ilość nam nie straszna.

To grupowe przestawianie dotyczy lamp wcześniej ustawionych na jakiś konkretny tryb odbioru, czy świeżo wstawionych na mapę? Jeśli to drugie - pierwszego akapitu nie było.

@Ryszard, to są luźne propozycje, niczego nie narzucam, niczego nie wymagam.
RBach - 11-02-2013, 21:59
:
P3t3r napisał/a:
@RBach, a nie dałoby się tak, że jeśli nie wstawimy reguły to światła się zapalają defaultowo-trainzowo, czy jak mają w skrypcie napisane?


Cały czas o tym piszę.

P3t3r napisał/a:
Poza tym obecnie np. mamy regułę od zegarów i jakoś nie ma płaczu ;-)


Ile jest map (wydanych) z działającymi zegarami?

P3t3r napisał/a:

Czemu tak nalegam na ten tryb domyślny? Bo chciałbym również pograć na obecnie wydanych mapach a przestawianie x-tysięcy lamp na x-dziesiąt map - dziękuję, pogram w bierki :mrgreen: Tym sposobem po prostu wgrywamy nowe lampy, wstawiamy regułę i ilość nam nie straszna.


A czy ja pisałem, że tak się nie da? Cały czas piszę, że MOŻNA, ale domyślnie będzie "po staremu", czyli kontrola przez skrypt samej lampy, właśnie ze względu ma użykowników chcących po prostu lampy powstawiać i mieć. Będzie można wstawić regułę i z jej poziomu przestawić WSZYSTKIE lampy na mapie na sterowanie Regułą. Tylko co z tymi, które będą już ustawione i skonfigurowane np pod ręczne sterowanie z kontrolera? One też się mają przestawić? Na pewno nie zrobię psikusa autorom map, w postaci konieczności ustawiania na nowo już skonfigurowanych lamp. Ale tak, jak to w tym wpisie opisałem - jest do zrobienia bez problemu.

I nie ma obawy, że update "na gotowo" coś każe zmieniać. Nie. Wgrasz nowe - będą nowe opcje, ale nie rozwalając map.

P3t3r napisał/a:

Jeśli to drugie - pierwszego akapitu nie było.


No właśnie :-)

Jedna rzecz, którą będę przypominał przy każdym takim temacie:

Nie dopuszczę (nigdy), żeby dodatki "pojedyncze" wymagały czegokolwiek dodatkowego do zadziałania, jeśli mogą działać bez tego. Oczywiście nie dotyczy to rzeczy, które z założenia miały pracować w zestawie - jak np przejazdy. Ale np do semaforów nie jest potrzebna reguła ani komenda, a jedynie konfiguracja samego semafora. Tak samo będzie w lampach - reguła nie może stać się WYMOGIEM a jedynie rozszerzeniem (zegary też można napisać tak, żeby Reguła ZWD nie była potrzebna). I jeśli jakikolwiek pomysł będzie do tego prowadził, to będzie odrzucany. Nie chcę doprowadzić do tego, żeby zbudowanie prostej mapki wymagało 5 lat studiów inżynierskich i 10 lat studiów "forumowych". Pewne dodatki wymagają nieco wiedzy, ale ta konieczność wynika z samego ich charakteru - nie da się użyć semafora, nie znając podstaw sygnalizacji. Lampa ma świecić w nocy zaraz po postawieniu. A wszelkie sterowania, reguły itd mogą być jedynie rozszerzeniem i "gadżetem". Nieprzypadkowo cały system kontroli lamp jest ustawiony domyślnie na AUTO.
O tym "użytkowniku z Trainzem spod choinki" pisałem pół żartem i ironicznie, ale to jest rzecz, o której nie możemy zapominać: W tą GRĘ grają także ludzie spoza forum, spoza naszego grona. Nie tworzą dzieł sztuki w stylu Jamala czy Kilana. I nie chcą się uczyć 300-stronicowej instrukcji, żeby mieć FAJNĄ lampę, bo fajna to ma skrypt z NASA i manual na 300 stron a te bez skryptu są dużo mniej fajne. W sygnalizie nie wymagamy przecież ustawiania wszystkiego, wystarczy jedno pole - i działa, podaje czerwone/zielone, nawet ciapong się zatrzymuje. W lampach - jak przyjdzie noc, to się zapala. I już. A jak się nie zapali, to taki "spod choinki" nie będzie ich używał, nie spyta się, bo na naszym forum za takie pytania dostaje się warny... I koło się zamyka, za trudne dodatki wylatują z obiegu.

Mi "się chce" i zazwyczaj umiem takie rzeczy napisać/wymodelować, ale nie może być tak, że w pogoni za "pragnieniami jednego usera" z prostego dodatku robi się prom kosmiczny z procedurą startową na 5 dni.
Mam nadzieję, że wyjaśniłem wystarczająco :-) O "palcu" i odgryzaniu ręki napisał Ricardo, więc nie będę powtarzał tego samego :mrgreen:
Qń - 12-02-2013, 07:24
:
Jeżeli dobrze rozumiem to każda lampa ma w sobie skrypt z wątkiem (thread) lub innym mechanizmem typu handlerowego który co 10 sekund sprawdza aktualny czas na mapie?
RBach - 12-02-2013, 11:16
:
Qń napisał/a:
Jeżeli dobrze rozumiem to każda lampa ma w sobie skrypt z wątkiem (thread) lub innym mechanizmem typu handlerowego który co 10 sekund sprawdza aktualny czas na mapie?


Coś w tym stylu. Innego sensownego pomysłu na autonomię, zachowując możliwość kontroli z zewnątrz po przełączeniu, nie miałem. Niestety w trainzach nie ma wbudowanego żadnego mechanizmu, który cyklicznie wysyłałby cokolwiek, co można wykorzystać do użycia odświeżania. Można ewentualnie zrobić PostMessage do samego siebie z opóźnieniem 10 sekund, ale nie wiem, czy to by było lepsze rozwiązanie. Można też użyć reguły ZWD albo własnej - ale o wadach tego rozwiązania rozpisywałem się powyżej. Jestem otwarty na propozycje :-)
Qń - 12-02-2013, 12:00
:
Nie obraź się Radek ale to co Zrobiłeś, to po prostu sabotaż na dowolnej mapie :-)
Wstawiamy na mapę 200 latarni ulicznych (czyli całkiem niewiele) i procesor zamiast zajmować się wieloma istotnymi, z punktu widzenia gracza, elementami rozgrywki cały czas przelicza czy już włączyć latarnie czy jeszcze nie. Skórka za wyprawkę!
To jest kompletnie bez sensu. Oskryptować w Trainzie można praktycznie wszystko ... natomiast rozsądnie jest nie robić tego dla zbyt wielu rzeczy.
Często widzę dodatki robione w zupełnym oderwaniu od kontekstu gry. Robiąc dodatek twórca nie myśli jaką rolę przyjdzie mu pełnić na mapie, z jakiej odległości będzie oglądany, na ile może być istotnym i skupiającym obiektem w otoczeniu. Skupia się na maksymalnie dokładnym odwzorowaniu rzeczywistego obiektu. To jest podejście dobre dla modelarza H0, natomiast w wirtualnym świecie Trainza musi skończyć się porażką. I chociaż najczęściej widać to w siatkach i rozmiarach tekstur modeli, to podobny mechanizm dotyczy też skryptów.
Najtrudniejsza rola modelarza to nie przygotowanie tekstur, zrobienie siatki czy napisanie skryptu. Najważniejsze jest obranie właściwej koncepcji modelu, tak żeby powstało coś dobrze wpasowującego się w mapę, zarówno wizualnie jak i wydajnościowo. Właśnie ten kompromis pomiędzy sprzecznymi ograniczeniami jest wyznacznikiem udanego modelu.

Koniec kazania

Jeżeli chodzi o te nieszczęsne lampy. Rzeczywiście w TRSie zapalają się o nijakiej porze.
Gdybym ja miał to jakoś poprawiać to pewnie kombinowałbym z jakimś sterownikiem ukrytym w dodatku scenery który poprzez Router uruchamiałby oświetlenie.
Czyli lampa ma skrypt (to już niestety jest minus całego rozwiązania) z dwoma handlerami i czeka na informację włącz/wyłącz od sterownika. Sterownik jest jeden i to on sprawdza czas (tutaj też można pokombinować z handlerami i np. zapalić się mają o 20, po sprawdzeniu czasu wychodzi, że jest 19, to następne sprawdzenie czasu uruchamiane handlerem wyznaczamy na za 55 minut. Oczywiście częstotliwość próbkowania zwiększa się przy malejącej różnicy czasu. Alternatywnie trzeba pomyśleć o wątku z jakąś umiarkowaną częstotliwością próbkowania - w końcu dokładność zapalenia lamp może być +-10 minut, a nie sekund!). Jeżeli chcemy zrobić latarnie uruchamiane o różnych porach, to można spróbować pewnej modyfikacji. Latarnia ma do wyboru opcje A,B albo C (domyślnie A). Kontroler ma opcje: A -> zapal -> podaj godzinę, zgaś -> podaj godzinę; B -> zapal -> podaj godzinę itd. Czyli kontroler wysyła informację routerem "SLat" "AZ"/"SLat" "AW"; "SLat" "BZ"/"SLat" "BW";"SLat" "CZ"/"SLat" "CW" i steruje grupami latarni z wybraną opcją A/B/C. W ten sposób mamy z jednej strony możliwość oddzielnego sterowania grupami (czyli prawie indywidualnie) z drugiej nie musimy konfigurować każdej latarni z osobna (bo domyślnie zadziała profil sterownika A). A przecież nie powiecie mi, że 3 opcje do wyboru to mało. W warunkach mapy to spokojnie wystarczy.
To oczywiście tylko luźny pomysł na szybko. Do takich tematów trzeba podejść "sprytnie" bo inaczej wyjdzie gniot.

P.S.: A tak w ogóle, to mam wątpliwości czy warto inwestować zasoby komputera w ręczne sterowanie światłami. Znam ciekawsze zajęcia dla procesora.
ryszard - 12-02-2013, 12:49
:
Qniu, a co pisałem parę postów wyżej. Radkowe zasoby intelektu można wykorzystać do innych, bardziej twórczych projektów :-P . Tak to mamy dysputę o grze pod nazwą "Symulator oświetlenia", dlatego proponuje powoli zwijać ten temat.
RBach - 12-02-2013, 13:22
:
Qń napisał/a:
Nie obraź się Radek ale to co Zrobiłeś, to po prostu sabotaż na dowolnej mapie :-)


Wiem :-) Podobnie jak wiem o wszystkim, co pisałeś poniżej, ale teraz to mam emo-focha z przytupem i idę płakać do kąta :mrgreen: :-)

Qń napisał/a:
Gdybym ja miał to jakoś poprawiać to pewnie kombinowałbym z jakimś sterownikiem ukrytym w dodatku scenery który poprzez Router uruchamiałby oświetlenie.


Ja myślałem (a Peter to napisał w wątku) o regule do sesji. Zasada działania - identyczna.


Qń napisał/a:
Czyli lampa ma skrypt (to już niestety jest minus całego rozwiązania) z dwoma handlerami i czeka na informację włącz/wyłącz od sterownika.


Czyli dokładnie tak, jak zachowuje się obecna lampa przełaczona w tryb pracy "z rozdzielni". Thread lata w pętli
Kod:
while (!tryb)
, gdzie tryb==0 to "samoczynność. Zmiana trybu ubija thread.

Qń napisał/a:
Sterownik jest jeden i to on sprawdza czas (tutaj też można pokombinować z handlerami i np. zapalić się mają o 20, po sprawdzeniu czasu wychodzi, że jest 19, to następne sprawdzenie czasu uruchamiane handlerem wyznaczamy na za 55 minut.


Dokładniej - mogłaby być reguła pełniąca rolę "zegara matki". Sterowniki (rozdzielnie) są - więc można:
- w lampie "świeżo wstawionej" czułość jest tylko na regułę
- w lampie skonfigurowanej na sterownik: w sterowniku możemy określić, czy lampy zapalają się w/g "matki", czy włączamy je ręcznie.

Qń napisał/a:
To oczywiście tylko luźny pomysł na szybko. Do takich tematów trzeba podejść "sprytnie" bo inaczej wyjdzie gniot.


Dlatego ciągnę dyskusję :-) Pomysł z kontrolą "czymś zewnętrznym" istniał od początku. Do zrobienia pozostaje kwestia: "co zrobić, gdy user wstawia na mapę same lampy" - bo w takim przypadku tylko istniejący patent (niekoniecznie thread!) zadziała. Inne rozwiązania wymagają czegokolwiek poza lampami. Ewentualnie lampa "głupia bez skryptu" z widokiem nocnym.

Qń napisał/a:
P.S.: A tak w ogóle, to mam wątpliwości czy warto inwestować zasoby komputera w ręczne sterowanie światłami. Znam ciekawsze zajęcia dla procesora.


A z tym to do Rzułfia proszę :-)
Ja tylko udostępniam pewne rozwiązania (nie zawsze optymalne, ale chętnie słucham innych i się uczę), a inni implementują je (lub nie) do swoich dodatków :-) Ja również znam ciekawsze zajęcia dla procesora, ale lamp mamy taki wybór, że jedna wersja "full HD windows 8" nie zaszkodzi. Zawsze można używać wbudowanych i robić mapki "po angielsku" :mrgreen:
Qń - 12-02-2013, 14:26
:
@RBach: Ty Popełniasz jeden podstawowy błąd. Próbujesz zrobić coś co będzie uniwersalne czyli ktoś wstawi same lampy to dobrze, wstawi lampy z kontrolerem to też dobrze. Efekt jest taki, że do prostej rzeczy będą skomplikowane skrypty z setkami linijek do obsługiwania wariantu takiego, innego itd. To jest bez sensu i nigdy dobrze działać nie będzie! To jest podejście informatyka który tworzy program o którym tak do końca nie wie kto i do czego będzie go stosował. To w TRSie się nie sprawdza. Tutaj trzeba robić prosto i prymitywnie. Przerabiałem to już na skryptach do taboru. Czyli chcesz mieć wypasione lampy to musisz zastosować kontroler + paczkę lamp takich i takich.
A co do wydajności i udostępniania różnych rzeczy, to często lepiej zachować pewne rozwiązania w fazie prototypów. Po prostu znaczna część użytkowników nie orientuje się, że taki błahy bajer może mieć znaczące konsekwencje. A jeżeli się takie rzeczy już udostępnia należy grubą czcionką wypisywać informację o skutkach ubocznych.

P.S.: W tej sytuacji nadawanie lampom o tak zupełnie odmiennych cechach użytkowych tych samych kuidów co oryginalne lampy Grabasha jest bez sensu. Lepiej zrobić to jako nowy projekt.
RBach - 12-02-2013, 15:01
:
Qń napisał/a:
@RBach: Ty Popełniasz jeden podstawowy błąd.


Nie. Robię to dla siebie, ewentualnie na prośbę innych, z jasno określonymi założeniami. Jeśli ktoś uważa, że to jest be i do dup.y, to po prostu niech nie używa. Doskonale wiem, co piszę i że niektóre rzeczy nie są przykładem efektywności, ale taki był zamysł. Jeśli nie mam pomysłu - to piszę wprost i wprost proszę o propozycje. Lampy robi Fatys, więc jak stwierdzi, że skrypt jest bez sensu, to go wywali. Co do threadu - masz rację, ale bardzo proszę, nie używaj sformułowań typu "podstawowy błąd", skoro nie znasz założeń projektu. Założeniem MIAŁA być uniwersalność - i jest. Nawet kosztem mniejszej wydajności. Jeśli byłoby zamówienie na lampy tylko do kontrolera, to by powstały. Było zamówienie na "kombajn" - to powstał. Proste. Więc zamiast "wytykać błędy", skupmy się może na sposobach rozwiązania problemu threadu, albo najzwyczajniej w świecie skończmy temat :-)
sawi88 - 14-03-2019, 21:46
:
Odgrzewam trochę temat niczym kotlety, ale czy mógłby mi ktoś wyjaśnić w łopatologiczny sposób jak dodać snopy (żółte i białe) w lampach Fatysa pracujących z systemem ?. Niby było coś o ich usuwaniu w temacie ale jak to zrobić w drugą stronę ?.