61
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 28 Lutego 2017, 21:15:47 »
Wiem, że można to zrobić inaczej ale chciałem użyć coś co już jest zaimplementowane ;)
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.
A jak nie ma przycisku w kabinie to nie działa- to gdzie jest i dlaczego nie działa :D
Możesz rzucić okiem na http://sigrok.org/api/libserialport/unstable/W sumie można to zaimplementować zamiast bo teraz są osobno metody do uruchamiania, wyłączania i sprawdzania połączenia. Zastanawiam się tylko czy nie wyciągnąć tego do osobnego pliku.
Jeśli dotykać Traina pod kątem sterowania to najlepiej ustalić do czego docelowo chcemy dojść bez rozpiski na poszczególne kroki i potem powolna implementacja małymi krokami.Sterowanie wrzucić do metod i tam zmiany wprowadzać a nie robić bajzel pod przyciskami ;)
Sterowanie umiescilbym na poziomie pociagu, w calosci przy pomocy komend, odpowiednikow biezacych komend rozsylanych po skladzie.Przerabiam właśnie Traina: wciśnięcie przycisku powoduje wywołanie metody a nie wykonanie bezpośrednio kodu. Dzięki temu można wykorzystać te metody do sterowania pojazdem z pulpitu. Wydaje mi się, że w takim wypadku zmiana kamery na np przedział maszynowy nie powinien powodować wyłączenia kabiny i sterowania nią. Można by tutaj dodać CKS do sterowania wyborem kabiny. Moim zdaniem można to zrobić dla czterech przypadków: mamy możliwość wysterowania CKS-a więc mamy załączoną kabinę A, B lub wyłączone sterowanie. Jeżeli nie mamy sterowania z pulpitu lub AI to zostaje pozycja "wszystkie kabiny włączone".
- UART: Tu coś trzeba pewnie wymyślić. Albo znaleźć jakąś wieloplatformową libkę, albo napisać po prostu dwie implementacje pod windowsa i unixy, z tym nie powinno być dużo problemów.Nie wiem czy nie będę musiał przerobić trochę moich wypocin i zrobić osobną klasę do łączenia się przez port szeregowy i osobno wykorzystanie tej komunikacji. Wtedy można dopiero chyba przerabiać na coś bardziej uniwersalnego (wind i unix).
-- dodanie obslugi przez klikniecia na elementy bezposrednio w kabinie.To jest dobry pomysł. Część ludzi będzie zachwycona takimi zmianami.
- zmodyfikować Console::Pressed tak aby oprócz wciśnięcia na klawiaturze sprawdzało też inne urządzenia. (Console::Pressed jest wywoływane z różnych miejsc sprawdzających różne klawisze co klatkę).Właśnie starałem się z tym jakoś wygrać ale nie wyszło więc robię trochę inaczej i chciałbym prosić o przeglądnięcie pomysłu i wypowiedzenie się na jego temat. Jak skończę to dam znać ;)
Jak skończycie przenosić całą MaSzynę na C++ do końca tego roku to zamówię Wam po kracie piwa z dostawą do domu.Trochę spóźnienia mieli chłopaki ale myślę, że i tak zasłużyli!
Zalecałbym na tę okazję rezystancję uziemienia poniżej 10omów.Co masz na myśli? Jak mamy uziom powyżej 10 omów to nie podłączamy iglicy do niego?
Na kranach sie nie znam, wiec nie bede sie wypowiadal, niech to sobie madrzejsi ludzie rozpracuja :)Opracowałem rozwiązanie o którym pisałem. To co było do tej pory powodowało wyjście poza zakres dla kranu FVel6 (minimalna wartość -1, a podać można było -2). Przerobiłem cały kod tak jak pisałem, przekazywanie wartości położenia kranu od 0 do 1 z Console. Dopiero w Train przeliczane jest na położenie kranu w zależności od jego typu. Powinno to ułatwić dodawanie sterowania innymi kranami. Dodałem jeszcze zapis do loga wyliczonej wartości dla kranu. Dzięki temu można na bieżąco podglądać jaka jest wartość ustawiana i jak reaguje kran w symulacji.
Na 170216 zaobserwowałem trzystopniową smugę, w zależności od ilości włączonych reflektorów.Swego czasu Q zrobił trzy osobne smugi do każdego z reflektorów. Na pulpicie są jeszcze magiczne przełączniki przyciemniania reflektorów, które można łatwo wprowadzić ale nie mam pomysłu pod jaką kombinacją klawiszy.