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.


Wiadomości - AtapiCl

Strony: 1 2 [3] 4
61
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 26 Czerwca 2017, 14:26:57 »
Nie ruszalem na razie, bo to jest raczej trzeciorzedny problem (bierze sie z tego ze ruch kamery w kabinie jest realizowany ze stalym krokiem, by utrzymac ten sam poziom rzucania kamera niezaleznie od FPS, i przy wlaczonej pauzie aktualizacja pozycji kamery nie nastepuje) Zrobie gdy mnie to dostatecznie zirytuje, albo nie bedzie nic pilniejszego na talerzu :d

62
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 25 Czerwca 2017, 20:13:27 »
Lata temu trzeba było zatrąbić, żeby fpsy podskoczyły

63
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 20 Maja 2017, 15:54:56 »
W okolicach Radliczyc wywaliło mnie ze znanym komunikatem.
Zaraz zaraz, komu znanym temu znanym :o  ktory to konkretnie komunikat byl, o braku pamieci czy cos innego?

Nie chcę krakać, ale jakiś czas temu grzecznie się spytałem czy są problemy z exe c➕➕ na Pokeys.
Jak juz kilkukrotnie wspomnialem nie mam dostepu do PoKeys ani zadnego tym podobnego urzadzenia, wiec nie jestem w stanie wykryc lub poprawic problemow w tym obszarze. Musi sie tym zajac osoba ktora taki dostep ma. Zrodla programu sa publicznie dostepne, a dostarczany kod jest dolaczany tak szybko jak jest to mozliwe.

64
Inne niekolejowe / Odp: Train Driver 2
« dnia: 16 Maja 2017, 22:06:13 »
Proponuję powstrzymać się od dalszej dyskusji o sytuacji TD2 na tym forum bo jest to bezcelowe, jutro wstaje forum TD-ka i tam będziemy dyskutować na ten temat, nie róbmy tu śmietnika.

65
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 15 Maja 2017, 15:16:22 »
Tak, opoznienie dziala tak samo dla wszystkich typow -- jesli przetwornica byla z jakiegos powodu wylaczona, to od momentu spelnienia warunkow dla zalaczenia do samego zalaczenia uplynie ConverterStartDelay sekund. W pewnym sensie mozna to traktowac jako (uproszczony) czas potrzebny na pelny rozruch urzadzen.

66
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 09 Maja 2017, 22:37:25 »
OK, znalazla sie przyczyna blednego zachowania w Drawinowie.

Pod sceneria zakopana jest, przyrodzenie wie po co, tarcza manewrowa wdz_tmunvis1_sem_info wyswietlajaca predkosc 0.  AI probuje zatrzymac sie przed nia w odleglosci ok 5 m, ale poniewaz sygnal jest 10 m pod powierzchnia ziemi, w efekcie "przekracza" wyznaczona przez niego linie, i rejestruje "nakazana predkosc na ostatnim semaforze: 0 km/h" no i poslusznie stoi potem do swietej Nigdy.

(poprzednio AI zatrzymywalo sie przed tarcza, bo odleglosc kalkulowana byla tylko na plaszczyznie, bez uwzglednienia roznicy poziomow. Na upartego moge przywrocic poprzedni model kalkulacji, ale to z kolei moze miec negatywne efekty w sytuacjach gdzie faktycznie wystepuje spadek albo wzniesienie terenu, wiec nie wiem czy nalezy)

tl;dr: robic scenerie porzadnie, to beda dzialac porzadnie ;/

67
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 27 Kwietnia 2017, 18:23:13 »
Cytat: tmj
I drugie glupie pytanie, tym razem z "rzeczywistosci": czy w EN57 i pochodnych jest cos takiego jak kurek trojdrogowy? Bo w exe jest to zakodowane tak, ze w przypadku EZT jest on traktowany jak nieistniejacy, mozna pompowac zbiornik pantografu bez jego przelaczenia, i nawet po 'odcieciu' zbiornika glownego powietrze z niego zasila zbiornik pantografu. A ja nie wiem jak ma byc :x

O ile mi wiadomo EN57 ma zawór automatyczny - jeżeli ZG jest pusty to zbiornik pantografów jest od niego odcięty, i można go pompować małą sprężarką, a gdy ciśnienie w ZG, czy tam przewodzie zasilającym, przekroczy ciśnienie zadziałania zaworu, to przestawia się on na zasilanie zbiornika pantografów z głównej instalacji.

68
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 25 Kwietnia 2017, 16:53:36 »
Jesli chodzi o tory 0 dlugosci, to tutaj moja uwaga, ze ostroznie z nimi tj z usuwaniem nich. Jesli autor scenerii bedzie mial uklad torowoy, iz jeden switch styka sie bezporsednio z innym switchem, to wymagany jest tor pomiedzy nimi, nawet o zerowej dlugosci. Jesli tego toru nie bedzie, zrobi sie null track. Chociaz juz chyba w sceneriach, tego typu konstrukcji jest coraz mniej, jednak trzeba miec to na uwadze. Raczej watpie, aby w exe w tym wzgledzie Ra badz ktos inny, usunal ten wymog. Wiec w errors nie jest sytuacja jednoznaczna, bo wypisuje cos, co exe traktuje jako blad, a to akurat jest niezbedne. Dobrze byloby to w exe dla pewnosci sprawdzic (czy jeszcze jest ten wymog).

69
Symulator / Odp: MaSzyna w Unity3D
« dnia: 19 Kwietnia 2017, 13:53:01 »
Postanowiłem samemu zrobić symulator i na nim zarobić, ale zaraz.

Rozumiem, że wszystkie modele są Twojego autorstwa a jeśli nie to autorzy wyrazili zgodę na komercyjne wykorzystanie?

70
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 27 Marca 2017, 14:03:20 »
Nie mam żadnych uwag do 260317. Objechałem kilka scenerii, nic złego się nie dzieje. Oczywiście nie wszystkie pojazdy jestem w stanie sprawdzić. Widzę zmianę na flarach i światłach, nie widzę teraz czarnych kropek a flary nie są przerysowane. Mam prośbę, od dawna przeszkadzało mi sterowanie ruchem kamery w kabinie pojazdu - góra/dół PageUp/PageDown, bo jest skokowo. Jeśli można to poproszę płynne przemieszczanie kamery tak jak jest to w poziomie i tak jak jest to w trybie frefly.

71
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 23 Marca 2017, 22:03:03 »
Jest coś o czym należy wiedzieć, żeby na nowych exe wygenerować sobie plik e3d terenu scenerii? Póki co program się sypie (crashdump w załączeniu), ostatni wpis w logu "saving e3d model..".

72
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 22 Marca 2017, 21:39:40 »
Przy okazji grzebania w kodzie rzucil mi sie w oczy komentarz przy swiatlach punktowych...
// dorobić aureolę!
No to dorobilem. Efekt nawet ok, ale ze kalkulacje robione byly z wykorzystaniem glGet() to wydajnosc na wiekszych stacjach spadla o jakies 25% co, biorac pod uwage ze efekt nie jest az tak dobry, bylo zdecydowanie zbyt wysoka cena. Podpialem wiec skonczone "wirtualne matryce" dla openGL, zeby sie pozbyc odwolan do glGet() i teraz zamiast spadku o 25% mamy jakas ~10% poprawe wydajnosci (bo odciazylo to tez stary kod rysujacy punkty swietle) przy wlaczonych aureolach. Efektow ubocznych byc nie powinno, ale wiadomo jak to jest w praktyce :s

tl,dr: powinno byc troche szybciej, i troche ladniej.

(aureole uzywaja tekstury nazwanej lightglare i umieszczonej w katalogu textures/fx Na ta chwile exe nie pozwala definiowac tekstur dla swiatel punktowych, ani wymiarow aureoli, kiedys moze sie to zmieni)

edit:
aha, aureole uzywaja definicji koloru swiatla punktowego, w rezultacie swiatla semaforow zrobily sie bardziej zolte niz pomaranczowe, bo taki jest kolor zdefiniowany dla punktow w tych komorach. Ktos sie bedzie musial poswiecic i je wreszcie poporawiac :d

73
Może dokończymy zaczęte zadania? Nie to, że bym nie chciał, ale są potrzebniejsze rzeczy do skończenia. Oczywiście według mnie i nie miejcie mi tego za złe. :)

74
Bieżące kolejowe / Odp: Zagadki Kolejowe
« dnia: 16 Marca 2017, 18:34:53 »
Tor na którym odstawia się maszyny torowe zabezpiecza się wykolejnicami. Nic niezwykłego.

75
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 08 Marca 2017, 01:21:14 »
OK, pogrzebalem troche w kodzie, probujac poprawic widzialnosc freespotlights, i znalazla sie ciekawostka, jeszcze z czasow oryginalu...

W kodzie jest cos, co nazywa sie "wspolczynnik odleglosci", i sadzac po wartosci domyslnej (768) i komentarzy, intencja tutaj bylo zwiekszanie zakresu widocznosci na ekranach/oknach wiekszych niz standardowe 1024x768. Tyle ze zamiast tego, zmienna byla uzyta jako sztywny mnoznik, dla zdefiniowanych minimalnego i maksymalnego zakresu widzialnosci, dla kazdego obiektu.

W praktyce oznaczalo to, ze punkty swietlne ze zdefiniowanym minimalnym zakresem widzialnosci 20m nie byly renderowane w ogole, dopoki nie znalazly sie przynajmniej ~500m od kamery :d  Jedyne co renderowalo sie poprawnie, to obiekty ze zdefiniowanym minimalnym zakresem 0.

Z jednej strony, po poprawce wszystko wyswietla sie w zakresach odleglosci takich, jakie zostaly zdefiniowane. Tzn objekt o zakresie 50-1000m widoczny jest w zakresie 50-1000m w oknie o wysokosci 768 pikseli, na wiekszym pojawia sie troche wczesniej i znika troche pozniej. Zaryzykuje opinie, ze swiatla znacznie na tym zyskuja -- te male punkty robia duza roznice.

Z drugiej strony oznacza to, ze do tej pory symulator renderowal takze elementy umieszczone dalej niz ich zdefiniowany 'zakres maksymalny'. Czyli po naprawie na ekranie moze byc widac mniej, niz przedtem. Jest to do skorygowania (zasieg moze byc dynamicznie zwiekszany na podstawie fps) i teoretycznie istnieje w kodzie, ale takze do przejrzenia.

Z trzeciej strony, oprocz poprawionej widocznosci swiatel efektem ubocznym strony drugiej jest dosc zauwazalnie poprawiona wydajnosc -- na Kaliskiej tam, gdzie do tej pory mialem 60-80 fps teraz renderowalo sie 200-250.


76
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 04 Marca 2017, 15:49:47 »
Rozwiazalem to w ten sposob, ze w przypadku takiego porownania do nieistniejacych danych symulator umieszcza wpis w logu errors, na wypadek gdyby byl to faktyczny blad, ale traktuje warunek jako spelniony, w ten sposob zachowujac sie jak stare exe. Na ile moge powiedziec, to przy takiej aranzacji wszystko dziala, udalo mi sie przeprowadzic pociagi w scenariuszu z jednego konca na drugi, w obu kierunkach. Poprawki beda w nastepnym uaktualnieniu. Do czasu gdy Milek skonstruuje komunikacje po tcp powinno wystarczyc.

77
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 23 Lutego 2017, 03:05:13 »
Wywalilem dzisiaj na probe wszystkie pliki .e3d i .dds z instalacji, wrzucilem zamiast tego .t3d i .tga i patrzylem co sie stanie. Wyskoczyl przy okazji jeden blad w ladowaniu plikow, ale po usunieciu wszystkie scenariusze weszly bez wiekszych problemow (sprawdzilem tylko po jednym dla kazdej scenerii, bo za dlugo by trwalo) Wychodzi na to ze 3gb na karcie graficznej na razie wystarcza, nawet dla .tga ;)

Jakbyś miał trajektorię dla słoneczka i księżyca, to też dodaj.
Slonce jest juz wstawione (tzn trajektoria, samego slonca na razie nie rysuje) z ksiezycem na razie sie wstrzymuje, bo chyba jest tez ksiezyc dolaczony do modelu gwiazd ktory jest w symulatorze, a chce podpiac te gwiazdy przy rysowaniu nocy, bo ladne sa. I glupio by bylo, jakby sie dwa ksiezyce zrobily :d   Poprawilem przy okazji troche oswietlenie w nocy (w zalaczniku, Kaliska po zakonczeniu jazdy) i chyby nie jest zle. Ale pare rzeczy musze jeszcze z oswietlenia podpiac z powrotem, wiec uaktualnienia na dzisiaj nie ma jak dobrze pojdzie bedzie jutro. A potem moze bedzie mozna myslec o laczeniu z wersja Milka.

78
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 18 Lutego 2017, 10:06:41 »
Chociaż w mojej ocenie poziom "drugi" powinien być poziomem maksymalnym, bo przy włączonych trzech reflektorach wszystko aż błyszczy. Tutaj musieliby coś powiedzieć maszyniści.
Tak, to jest faktycznie za mocne i zbyt białe światło. Owszem, w rzeczywistości jest tak, że gdy wskazniki są blisko reflektora, to są przebłyszczone światłem. Światło reflektorów powinno być bardziej żółtawe.

79
Bieżące kolejowe / Odp: Pytania o zawód maszynisty
« dnia: 17 Lutego 2017, 22:32:31 »
Po dwóch latach udało się zrobić świadectwo masz., dostałem umowę na 2800 zł co daję z dodatkami, pojedynkami ok2400zł na rękę. (i tak już od dwóch lat ). Czyli jak słyszycie od kogoś że maszynista zarabia 5000zł to albo jeździ już ze 20 lat na maszynie albo robi po 300 godź. w miesiącu.[/color]
To może pomyśl, aby zamienić Przewozy Regionalne na jakiegoś innego przewoźnika?

80
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 17 Lutego 2017, 16:44:14 »
Starter by sie przydal, bo poleganie na zewnetrznych narzedziach nie jest specjalnie profesjonalne ;)  To raczej projekt na dluzsza mete, miedzy innymi dlatego, ze przydaloby sie do niego jakies UI, a tego w exe na razie ani sladu. UI ewentualnie bedzie musialo sie zjawic przy wprowadzaniu edycji scenerii z poziomu exe, wiec starter tez prawdopodobnie moze zmaterializowac sie wtedy.

82
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 14 Lutego 2017, 22:53:34 »
Krzyśku, uważam że nie masz racji. Post Milka to nie było otwarcie dyskusji nad sensem tylko poinformowanie, że on sensu nie widzi i usuwa. Nie widzę tu oznak próby dyskusji. Więc nie ma czego prowadzić.
Milek, nie wiem czy mylisz idee z praktyką, czy nie ale twoje podejście jest ideowe a nie praktyczne. A praktyka mówi, że nasz kod nie aktualizuje używanych bibliotek zbyt często. I jeśli nie masz libów na repo to za jakiś czas możesz nie znaleźć odpowiednich w sieci (znajdź mi lib-y i dll-ki do GTK2.0.1, spróbuj) i zaczną się posty w stylu "chłopaki, podrzućcie mi liba bo skompilować nie mogę".

83
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 02 Lutego 2017, 11:34:40 »
Do spraw, do zrobienia jest sterowanie pociągiem. To co yB wyłuszczył jest dość istotne dla prowadzenia symulacji. Więc trzeba zaprojektować nową architekturę, która uwzględni nowe pojazdy. Może coś takiego:
Pociąg -> Pojazd / Wagon -> Fizyka
Wtedy poszczególne elementy zawierają:
  • Pociąg: zawiera wszystkie pojazdy / wagony, przechowuje rozkład jazdy, przechowuje AI / człowieka dla wszystkich pojazdów, które mają sterowanie (np. podwójna trakcja).
  • Pojazd / Wagon jest dość ciekawą konstrukcją. Z punktu widzenia Pociągu to to jest to samo. Z punktu widzenia Wagonu Pojazd jest pociągiem. Czyli Pojazd jest specyficzną konstrukcją, która przechowuje poszczególne Wagony oraz logikę przekazującą polecenia AI dla poszczególnych Wagonów. Pojazd byłby lepiej napisanym odpowiednikiem obecnego sprzęgu depotowego.
  • Fizyka: zawiera obliczanie zmiennych fizycznych dla danego Wagonu. Np. dla wagonów to może być tylko liczenie sił na sprzęgach oraz układ hamulcowy. Dla części EZT to może być różna fizyka zależnie od posiadania lub nie odpowiednich elementów.
Kwestia umiejscowienia kabiny i miejsca przechwytywania sterowania jest do rozwiązania.

84
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 01 Lutego 2017, 22:24:21 »
Dokleje tylko moj wczesniejszy kawalek z watku c++ zeby nie zginal

Co do grubszych zmian, zastanawiajac sie nad tym, co powinno byc zrobione, wyszla mi nastepujaca lista:

* rozdzielenie symulacji od wizualizacji. Czesc z tego jest juz chyba zrobiona, ale docelowo kompletny uklad torow i lista poruszajacych sie po nich obiektow, obsluga eventow + kalkulacje fizyki dla tych obiektow powinna pracowac praktycznie niezaleznie jako odrebny modul. Stan obiektow symulacji moze byc podawany zainteresowanym sluchaczom, a czy tym sluchaczem jest silnik graficzny (czy wrecz caly klient w systemie multiplayer), przekaznik informacji dla pulpitu, modul kontroli ruchu czy jeszcze cos innego, to juz symulacji nie obchodzi.

* powiazane z powyzszym i opcjonalna, reorganizacja sterowania symulacja na uklad dwustopniowy -- pomijajac siec trakcyjna, stopien pierwszy czyli 'swiat' symulacji zredukowany jest do ukladu torow i uniwersalnych 'punktow sygnalowych' ktore sa zrodlem instrukcji dla AI pojazdow, i z reguly umieszczone sa tam, gdzie znajduja sie fizyczne wskaznikow/sygnalow/itp. Konkretne jakie instrukcje emitowane przez punkty sygnalowe zalezy od stopnia 2-ego, tj. skryptu i/lub modul(ow) spietych z danym punktem. Uprosciloby to tworzenie scenerii -- uklad torow i wskaznikow robiony jest raz, a kontrola sygnalow zajmuje sie juz modul kontrolera, w zaleznosci od otrzymanego scenariusza. I czy tym kontrolerem jest modul AI, czy zywy czlowiek albo nawet kilku, to juz symulacji nie obchodzi.

* opcjonalne, uporzadkowanie zmiennych w glownych klasach. Te wieksze maja cos z 50+ parametrow, wszystko wrzucone na jedna kupe. Trudno dojsc co jest pobierane z plikow konfiguracji, co jest kalkulowane, co nie jest uzywane w ogole. Pogrupowanie tego w sensowne struktury ulatwiloby punkt nastepny

* krytyczne, wprowadzenie zapisu 'swiata' z poziomu symulatora, i wczytywanie tego zapisu. Glownie majace na celu uproszczenie i przyspieszenie edycji scenerii; zamiast zabawy edytorami tekstu, zewnetrznymi narzedziami itp powinno to byc cos, co robisz bezposrednio w programie i "what you see is what you get". Zamiast zgadywac, jak prezentuje sie obiekt umieszczony w scenerii, po prostu mozna to od razu zobaczyc, tak jak i wprowadzane poprawki. W polaczeniu ze zmianami powyzej pozytywnym efektem ubocznym mogloby byc tutaj przyspieszenie ladowania scenariuszy -- program moglby wczytac od razu uklad torow i zestaw pojazdow, a nastepnie doczytac sobie w locie dane potrzebne do wizualizacji.

A tak z zupelnie innej beczki, to ile dobrze pamietam Q zaczal robic jakas wersje kodu z przepisana grafika itp, tylko sie to rozbilo na przepisywaniu fizyki. Skoro fizyka w c++ teraz zaczyna jako tako chodzic, moze daloby sie to jakos polaczyc?

85
Na warsztacie / Planowane zmiany w exe
« dnia: 01 Lutego 2017, 09:17:40 »
Otwieram dyskusję o tym w których miejscach należy zmienić kod oraz jak to zrobić, żeby osiągnąć cele. Na początek szybka lista tego co moim zdaniem wymaga zmian:
  • Rozbicie mover na klasy odpowiadające typom (prądu stałego, asynchrony, diesel, diesel electric, itp) a następnie poszczególnym modelom (obecnie rozróżnienie przez dt_xx). Za tym idą zmiany w parserze plików fiz, bo będzie można wywalić wszystkie niepotrzebne zmienne. Nie mówiąc już, że jakiekolwiek dodanie nowego typu pojazdu będzie łatwiejsze. Z minusów wymaga to zmian w interfejsie do pythona na pobieranie przez skrypt wybranych danych, ale samych ekranów nie jest jeszcze na tyle, żeby nie dało się tego wykonać.
  • Rozbicie Driver na część tylko dla człowieka oraz tylko dla AI, być może AI dla specjalnych okazji jeśli mają być takowe.
  • Implementacja protokołu do wymiany danych z SCS. Wywalenie eventów. Dość trudne, gdyż już teraz na etapie zmian w tabelce dochodzę do kwestii kompatybilności z tym co obecnie można robić, a co będzie możliwe po zmianach. Tu jest pytanie czy tylko naprawić co jest na potrzeby Kaliskiej w obecnej wersji i po prostu zrobić to od nowa, ale wtedy wszystkie scenariusze będą do zrobienia na nowo (chociaż zapewne odtworzenie będzie bardzo łatwe przy pomocy SCS).
  • Serializacja danych w celu zapisu i odtworzenia stanu sesji jest możliwa, szczególnie jeśli porozbijamy monolityczne klasy jak obecnie.

86
Forum / Odp: Nowa zasada do regulaminu.
« dnia: 23 Stycznia 2017, 01:16:35 »
Dotychczas nie zaobserwowano takich zachowań, ponadto sądzę, że używanie "łapek" do wybadania poparcia jakiejś idei może być zasadne. O wiele bardziej zasadne niż oczekiwanie, że kilkadziesiąt aktywnych użytkowników napisze post o treści "Ok". Zawsze pozostaje możliwość przeprowadzenia merytorycznej dyskusji na kilkadziesiąt/-set postów, czego należy się po tej dojrzałej społeczności forum spodziewać.

W mojej ocenie zapis taki byłby zbędny, ograniczałby możliwości korzystania z tej funkcji. Oczywiście nachalne pisanie takich postów uaktywni moderację. Ponadto "łapkowanie" uruchomione jest jedynie testowo.
Cytuj
I tak nikt Cię nie słucha.
Jak widać słucha.

Zamykam.

87
Bieżące Symulatorowe / A może by tak wystarczyło siódemek?
« dnia: 21 Stycznia 2017, 17:21:24 »
Może trochę abstrakcyjna propozycja, ale przydałoby się żeby nowi twórcy ograniczyli produkcję tekstur siódemek, symulator jest już nimi przesycony, łącznie z tym co jeszcze w teście leży mamy już ponad 100 siódemek.
Nie mówię zeby w ogóle nowych nie robić, jakieś wyjątkowe malowania bo po co nam kolejne ICowskie? A druga sprawa, model siódemki jest modelem flagowym i jak zaraz dobijemy do 200 tekstur to nie wiem kto będzie robił aktualizacje repli.
Zapraszam do dyskusji :d

88
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 19 Stycznia 2017, 22:10:05 »
Ja tez bylem kiedys mlody i mialem dobre oczy. ;d

89
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 13 Stycznia 2017, 09:52:37 »
Przy okazji zerknąłem na kod pod kątem kompilacji w VS i jest tam jeszcze troszkę rzeczy do poprawienia
To jest delikatnie powiedziane :)  Zajrzalem tam sobie dzisiaj, i niestety na samym wycieciu parsera sie nie skonczy, sporo tam jeszcze sie paleta ansistringow, borlandowych naglowkow i innych takich. Ale jak juz zaczalem grzebac, to skoncze (chociaz ladnie jeszcze nie bedzie, na to przyjdzie czas pozniej)

90
Na warsztacie / Sterowanie ruchem przez zewnętrzną aplikację
« dnia: 13 Stycznia 2017, 00:48:09 »
Dzień dobry,

Być może niektórzy znają projekt SCS-1 (Symulacyjne Centrum Sterowania), będący interfejsem operatora i systemem zależnościowym współpracującym z symulatorem TD2, imitującym komputerowe urządzenia srk (nie jest to symulator konkretnego typu urządzeń). Program udostępniony jest na forum TD2 jako załącznik dostępny po zalogowaniu, bez zalogowania można przejrzeć ogólne informacje i dokumentację użytkownika: http://td2.info.pl/index.php/topic,100.0.html

Pierwotnie program powstawał z myślą o Maszynie, która również została dostosowana do takiej formy sterowania, choć dotąd nie było to nigdzie szerzej wykorzystywane. W ostatniej wersji uruchomiona została automatyka nastawiania przebiegów, która pozwala na użycie programu w roli systemu samodzielnie sterującego ruchem na scenerii według wczytanego planu przebiegów, z możliwością interwencji użytkownika w proces sterowania. Mamy zatem coś na kształt VD, którego koncepcja przewijała się na forum już dawno temu. Eventy przestają być używane do realizowania logiki sterowania, a stają się warstwą wykonawczą (przynajmniej jeżeli chodzi o srk). Odpadają problemy typu za wczesne przestawienie zwrotnicy spowodowane za długim składem, ruch na scenerii przestaje być sztywny - dodanie pociągu, zmiana kolejności jazd czy miejsca krzyżowania nie stanowi problemu. Rozwiązanie rozwinąć można o kolejną warstwę, nadrzędną w stosunku do SCS-1, która może zarządzać rozkładem jazdy i dynamicznie generować plan przebiegów (jest on odczytywany z dysku cyklicznie). Oczywiście można też wcielić się w rolę dyżurnego ruchu i sterować ręcznie.

W tym wątku przedstawiam przykład scenerii sterowanej w ten sposób, z Maszyną działają praktycznie wszystkie funkcje przewidziane w programie (m.in. nastawianie przebiegów, pip - śledzenie numerów, przejazdy, sbl, ANP). Niezbędne pliki wraz z samym programem zamieszczone są w załączniku. Otwarta pozostaje kwestia dostosowania plików .inc do sterowania przez program - bez zmian plików oraz pewnych zmian w sceneriach nie będzie to możliwe. Pliki .inc zaprezentowane tutaj mają raczej charakter prowizorki.

Ogólne założenia:

  • program SCS-1 uruchamiany jest przed uruchomieniem Maszyny, wybierany jest plik pulpitu, po czym program oczekuje na nawiązanie połączenia, tzn. wywołanie eventu "gotow_<nazwa>" przez Maszynę po uruchomieniu scenerii (na pulpicie przestanie migać białe oznaczenie EU07, pojawi się zielone oraz wyświetlony zostanie właściwy stan zajętości odcinków),
  • SCS-1 łączy się z Maszyną komunikatami międzyprocesowymi WM_COPYDATA, w razie potrzeby możliwe jest zastosowanie dodatkowego ogniwa transmisyjnego i uruchomienie SCS-1 na innym komputerze, z połączeniem TCP/IP (uzyskujemy wtedy namiastkę symulacji sieciowej dyżurny - maszynista; nie wiem jak wygląda temat multiplayera z wieloma maszynistami - czy cokolwiek było w tym kierunku robione?),
  • sterowanie i kontrola odbywa się na zasadzie zdalnego wywoływania eventów typu multiple oraz detekcji ich wykonania w Maszynie (własnych oraz innych, uruchomionych np. eventami torów), ponadto wykrywane są zajętości odcinków izolowanych - są one wymagane w scenerii (działanie komunikacji można podejrzeć w rejestratorze SCS-1 - uwaga: w trybie testowym logi będą trochę inne),
  • z uwagi na nieciągłą komunikację stosowane jest cykliczne kontrolowanie zdalnego wykonywania eventu "gotow_<nazwa>",
  • plik pulpitu SCS-1 zawiera graficzny obraz stacji wraz z danymi niezbędnymi do realizacji zależności, plik ten tworzony jest przy pomocy dołączonego edytora,
  • obsługa programu jest zbliżona do obsługi komputerowego pulpitu nastawczego, z możliwością automatyzacji w pewnym zakresie.

Rzeczy, które wymagają przedyskutowania/przeróbki/dopracowania:

  • brak możliwości sterowania niektórymi obiektami bez modyfikacji plików .inc - zdalnie działają tylko eventy multiple, a niektóre są innych typów (dotyczy większości sygnalizatorów - sterowanie W24, również Sp),
  • generalnie konieczność usunięcia z plików .inc obiektów wszelkich uzależnień od torów, innych semaforów, opóźnień zadziałania itp. - zależności realizuje SCS-1 (dotyczy głównie powiązań sygnalizatorów oraz przejazdów),
  • konieczność usunięcia ze scenerii wszelkich eventów oddzielnie sterujących obiektami, które sterowane i kontrolowane mają być przez SCS-1,
  • konieczność uzupełnienia plików .inc zwrotnic o eventy kontrolujące rozprucia (brak detekcji ewentualnych rozpruć może doprowadzić do nieciekawych efektów),
  • wskazane jest uporządkowanie nazw obiektów oraz sposobu ich nadawania w sceneriach, jak również rozmieszczania odcinków izolowanych i eventów używanych jako czujniki ssp (dokumentacja użytkownika zawiera wytyczne co do nazw obiektów).

Możliwe rozwiązania:

  • adaptacja plików które zamieściłem w załączniku po drobnych poprawkach - część jest nowa, a część stanowi "nakładki" na stare pliki, wszystkie wymagają sprawdzenia - proszę nie traktować ich jak gotowego rozwiązania do stosowania,
  • przygotowanie nowych wersji plików .inc przeznaczonych do zdalnego sterowania z zewnątrz, z uporządkowanymi nazwami eventów, najlepiej o formacie "<obiekt>:<akcja>", podobnie jak przyjęte zostało w TD2 (obecnie zgodne z tą konwencją są tylko eventy "forced+" i "forced-" zwrotnic, pozostałe na ogół używają znaku "_", z kolei zwrotnice i wykolejnice jedynie dodają znak +/-/o/z do nazwy).

Interfejs sterowania używany przez SCS-1 może być wykorzystany również przez inne programy, planuję dostosować kiedyś pod tym kątem symulator ISDR.

Wykaz aktualnie używanych w komunikacji z Maszyną eventów:

a) zwrotnice

  • "<nazwazwr>+", "<nazwazwr>-" - przestawienie do położenia "+", "-"; wykonanie eventu jest traktowane jako kontrola wysterowania, z określonym opóźnieniem przyjmowana jest kontrola położenia końcowego,
  • "<nazwa>:forced+", "<nazwa>:forced-" - event wykonywany w scenerii gdy zwrotnica zostanie rozpruta i przestawiona przez tabor do położenia "+", "-",

b) wykolejnice

  • "<nazwawk>o", "<nazwawk>z" - otwarcie, zamknięcie wykolejnicy, analogicznie jak przestawienie zwrotnicy,

c) sygnalizatory (w tym TOP)

  • "<nazwasygn>_<sygnal>" - wyświetlenie sygnału; wykonanie eventu jest traktowane jako kontrola wysterowania; w miejscu <sygnal> pojawia się nazwa sygnału zapisana małymi literami, lub "wyg" - wygaszenie TOP/semafora sbl (sygnalizator ciemny), dla wyświetlenia Sz używane jest oznaczenie "sz1", dla wskaźników W24 - "w24" i "w24off",

d) przejazdy

  • "<nazwaprzej>_zamykaj", "<nazwaprzej>_otwieraj" - rozpoczęcie zamykania/otwierania; wykonanie eventu jest traktowane jako kontrola wysterowania, natomiast stan zamknięcia/otwarcia przyjmowany jest z pewnym opóźnieniem (za właściwą sekwencję sterowania sygnalizatorami drogowymi, dzwonem i rogatkami odpowiada już sam .inc),
  • "<nazwaprzej>_wj1", "<nazwaprzej>_wj2", "<nazwaprzej>_zw" - w przypadku przejazdu zamykanego czujnikami: wjazd na czujnik zamykający od strony 1, wjazd na czujnik zamykający od strony 2, zjazd ze strefy przejazdu (realizowane jako eventy torów, przy czym "_zw" uruchamiany jest warunkowo po cyklicznym sprawdzaniu stanu toru przez oddzielny plik .inc),

e) odcinki izolowane

  • używany jest oddzielny rodzaj komunikatów, bez wykorzystania eventów.

Zawartość załącznika:

  • SCS.exe - plik programu, jest to nieznacznie zmodyfikowana wersja 2017.01.07 znana użytkownikom TD2 (poprawione zostały funkcje komunikacji z Maszyną; należy wybrać tryb WM_COPYDATA; z uwagi na rozwojowy charakter powiązania z Maszyną wersję tą traktować należy jako roboczą, a nie stabilną),
  • EdytorSCS.exe - edytor pulpitów,
  • dokumentacja/ - dokumentacja użytkownika (ta sama co na forum TD2),
  • scenery/*.inc - nakładki i zmienione wersje plików .inc przystosowane do sterowania z zewnątrz, oryginalne pliki nie są zmieniane/nadpisywane,
  • scenery/anp_test.scn - prosta sceneria przystosowana do sterowania przez SCS-1, zawiera cztery małe posterunki ruchu, jeden przejazd włączany czujnikami, jeden przejazd uzależniony w przebiegach, dwa szlaki jednoodstępowe z ruchem na zasadzie utwierdzania przebiegów oraz jeden szlak z czterostawną, dwukierunkową sbl (uwaga: dla włączenia komunikacji WM_COPYDATA konieczne jest ustawienie multiplayer 1 w eu07.ini),
  • anp_test.scs - plik pulpitu dla powyższej scenerii (możliwe jest również uruchomienie programu w trybie testowym, bez Maszyny/TD2, z zajętościami zadawanymi ręcznie),
  • anp_test.anp - plan przebiegów, po uruchomieniu którego program automatycznie będzie prowadził pociągi z jednego końca scenerii na drugi, realizując krzyżowania w razie potrzeby (po uruchomieniu SCS-1 i następnie Maszyny należy wczytać i uruchomić plan ANP w SCS-1 oraz wprowadzić numery pociągów w SCS-1 - nieparzyste jadą w prawo, parzyste w lewo, zawiera również pewne zautomatyzowane manewry - więcej informacji w komentarzach w pliku).

Działanie niektórych szczegółów dokładniej opisane jest w dokumentacji użytkownika. Powinno ruszyć bez większych problemów, choć nie testowałem tego na standardowych paczkach całościowych - używam własnej, minimalistycznej "dystrybucji" symulatora na potrzeby testów. Proszę o uwagi na temat rozwiązania plików .inc jak i całego programu oraz możliwości jego zastosowania w Maszynie.

Strony: 1 2 [3] 4