[P3t3r]

@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 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]

[Qń]

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]

[Qń]

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]

Qniu, a co pisałem parę postów wyżej. Radkowe zasoby intelektu można wykorzystać do innych, bardziej twórczych projektów . Tak to mamy dysputę o grze pod nazwą "Symulator oświetlenia", dlatego proponuje powoli zwijać ten temat.

[RBach]

[Qń]

@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]

[sawi88]

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ę ?.