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 - Milek7

Strony: [1] 2 3 ... 30
1
Myślę że to sprawa do rozważenia. Nie upieram się przy obecnym rozwiązaniu, jak uważacie że to coś poprawi kondycję projektu to można przenieść czat na Discord.

2
WWW / Odp: Projekt nowej strony głównej
« dnia: 29 Stycznia 2024, 00:28:24 »
Co do strony, wieczorem podeślę pliki, aczkolwiek jest to póki co tylko przykład strony głównej tylko w HTML i CSS, nie ma jeszcze integracji z bazą danych ani podstron.
Bez baz danych, później problemy z utrzymaniem tego. Najlepiej coś statycznie generowanego, np. tutaj testowałem przeniesienie obecnej strony na Hugo: http://stuff.eu07.pl/hugo-test/ http://stuff.eu07.pl/hugo-test/eu07-site.zip
Wrzuciłoby się to na gita i bot po każdym commicie wrzucał wygenerowane pliki na serwer.

3
Wydzielam wątek, bo ta dyskusja zdecydowanie odbiegła od celu uszczegółowienia planowanych zmian.

4
Cytuj
2.2 każda osoba w komisji ma głos, którego może użyć, niezależnie od brania udziału w zmianie
Dlatego uwzględniłem, że jeżeli autor zmiany jest członkiem komisji to wlicza się automatycznie. Bo raczej nie powinno być sytuacji, w której ktoś zgłasza zmianę i jednocześnie jej nie akceptuje. Ale to szczegół techniczny.
Cytuj
4.2.1b - w przypadku odmowy, zostają uprawnienia ukryte, do czegoś jeszcze się do czegoś przydadzą te uprawnienia?
Pisałem już w tym wątku o tym, że działy zamknięte chcę zlikwidować. Przez jakiś okres przejściowy (np. rok) te uprawnienia będą jeszcze umożliwiać wgląd do tych działów.
Cytuj
z czego trzeba zdefiniować "nieaktywność" i mimo wszystko musi być awaryjna opcja do usuwania osób za np. łamanie zasad czy coś w ten deseń.
Nieaktywność w kontekście działań członka komisji, czyli prawdopodobnie udział w głosowaniach. Jeżeli ktoś złamie zasady to może wyłapać bana od moderacji (6.2)
Cytuj
Nie do końca wynika to z kontekstu, także proszę o uzupełnienie informacji:
Tym kontekstem jest pierwszy post tego wątku. Tak, zastępuje rangi, likwiduje działy zamknięte (z okresem przejściowym), zastępuje test dodatków, osoby spoza komisji będą mogły dodawać komentarze odnośnie proponowanych zmian (i oczywiście zgłaszać swoje zmiany).
Cytuj
Jeszcze uważam, że wymaga to doprecyzowania - co z kwestią małych poprawek na repo czy innymi nieznacznymi duperelami, typu poprawka parametru w .fiz czy coś w tym guście? Też musi czekać tydzień i być głosowane pod komisją?
Zgodnie z tą samą procedurą, ale niekoniecznie to musi trwać tydzień - według obecnych propozycji jeżeli masz 3 akceptacje (i brak wymaganej liczby wet do rozpoczęcia głosowania) to 24h.
Cytuj
Bardziej zastanawiam się, jak od strony systemowej zostanie zrobione składanie wniosku przez 3 osoby jednocześnie.
Może być tak jak pisałeś, utworzenie wniosku przez jedną osobę i dołączenie do niego jeszcze dwóch osób rozpoczynało by procedurę głosowania. Nie widzę tu problemu.
Cytuj
Jak będzie wyglądać rozwiązywanie konfliktów (np. dwie zmiany w tym samym kawałku kodu utworzone przez różnych użytkowników)?
Pewnie ta zatwierdzona jako druga musiałaby być odrzucona z prośbą poprawy do autora.

5
Spodziewałem że odniosę się od razu do większej ilości komentarzy, ale w takim razie odnośnie tego co jest:

2.2. a), chociaż jak mogłoby to działać, jeśli dodatek ma wielu autorów? automatyczny głos wrzucającego dodatek, czy wszyscy współautorzy jako jeden głos, aby wyeliminować wpływ współautorów dodatku na głosowanie?
Myślę że automatyczny głos wrzucającego dodatek. Liczenie współautorów jako jeden może powodować jakieś dziwne ruchy, żeby "oficjalnie" dodatek nie miał współautorów tylko po to żeby doliczyć dodatkowe głosy. Myślę że przejrzyściej jak każdy członek komisji ma głos liczony tak samo niezależnie czy akurat brał udział w danej zmianie.
Cytuj
4.2.1. b), aczkolwiek ile obecnie mamy osób z ukrytą rangą? jedną? dwie? Myślę, że to można załatwić na poziomie rozmowy indywidualnej.
Niestety to nie jest takie proste, wcześniejsza praktyka była inna i był zwyczaj zostawiania ukrytych uprawnień. Obecnie jest kilkadziesiąt takich kont (najczęściej jest to połączenie rangi Zasłużony + ukryta deweloperska, chociaż nie we wszystkich przypadkach).
Cytuj
4.3. b), aczkolwiek nie jestem pewien, jak miałoby to działać. Na wniosek trzech członków, czyli ktoś musi założyć projekt wniosku, a następnie dwie osoby zagłosować, żeby był wniosek trzech członków, żeby zacząć głosowanie? Trochę nie ma to sensu.
Coś w tym rodzaju. Dlaczego bez sensu? Założenie było takie, żeby wymagać wniosku kilku osób żeby nie było możliwości nadmiernego tworzenia głosowań (a ponieważ proponowałem też brak wymagań kworum w głosowaniach, nie można ich po prostu ignorować). Konsekwencją byłoby też to, że autorzy wniosku byliby jawni, a samo głosowanie jest tajne.
Można zastosować wariant z głosowaniem na wniosek kandydata, ale dla takich głosowań trzeba dodać wymóg kworum.
Cytuj
5. b), choć uważam że na exe za wcześnie. Moja propozycja to utworzenie oddzielnego komitetu do exe, większość osób ocenia dodatki a z exe nie mają nic wspólnego, więc aprobowaliby zmiany, co dopuszczałoby babole w kodzie.
Cóż, trzeba się zastanowić czy mamy tyle ludzi żeby stworzyć oddzielny komitet do exe. Ja mam co do tego wątpliwości. Myślę że można oczekiwać że członkowie komisji nie będą bezrefleksyjnie akceptować zmian o których nie mają pojęcia. Dodatkowo przecież efekty zmian będą łatwo widoczne, więc zawsze można je wycofać w tej samej procedurze. A zostawienie obecnego stanu jako osobny komponent daje ryzyko rozłamów gałęziowych (wstawmy inne exe, bo tam jest nowa funkcja), jak i zależy od (nie)aktywności autorów tych gałęzi.
Cytuj
6.3. Skąd liczba 6?
To taka liczba na oko. Proponowałem wniosek o dodanie przez 3 członków, więc minimum poniżej 4, plus 2 zapasu.

6
Pomoc doraźna / Odp: MaSzyna 23.07 problemy.
« dnia: 18 Grudnia 2023, 17:00:41 »
https://wiki.eu07.pl/websvn/log.php?repname=pctga&path=%2Fscenery%2Fzs2cbi.inc

Przepychanie się tu kto powinien coś był zrobić i wziąć odpowiedzialność jest zupełnie bezproduktywne. Przy sposobie działania tego eventowego makaronu, ręczne zapanowanie nad wszystkimi interakcjami zmian jest raczej nierealne. Zastanawiam się nad zebraniem warunków końcowych (pozycji pociągów) dla każdego scenariusza i na serwerze automatyczne sprawdzanie zgodności po symulacji każdego scenariusza po każdej zmianie w kodzie/na repo. To niestety też ma swoje problemy, bo jak wtedy traktować scenariusze z eventami losowymi, część nie jest dostosowana żeby pojazdem graczem jechał bot, a zdaje się że niektóre próbują zmieniać działanie w zależności od tego czy jedzie gracz czy bot.

8
Bieżące Symulatorowe / Odp: Potencjalne zmiany w zarządzaniu projektem
« dnia: 26 Września 2023, 22:09:11 »
Kilka wariantów propozycji. Moje preferencje zaznaczyłem pogrubieniem ale to nic wiążącego, zapraszam do dyskusji (również innych możliwości których tu nie przestawiłem).

Gdy w dalszej części mowa o moderacji, to chodzi o moderację i administrację.

1. Nazewnictwo: zespół/rada/komitet/komisja?

2. Sposób akceptacji zmian na repozytorium:
a) głosowanie całego zespołu
b) akceptacja 3 osób, zatwierdzenie natychmiastowo po osiągnięciu wymaganej ilości
c) akceptacja 3 osób, zatwierdzenie 24h po ostatniej akceptacji, do tego czasu możliwość zgłaszania wet, po trzech wetach zmiana poddawana pod głosowanie

Wariant a) dawałby duże opóźnienia, bo głosowania powinny być wystarczająco długie (rzędu np. 2 tygodni) żeby każdy mógł się wypowiedzieć. b) daje szybkie efekty ale łatwo o wojnę edycyjną między małymi ale aktywnymi obozami. c) jest w miarę szybkie ale w przypadku konfliktów zmiana idzie pod głosowanie.

2.1. W przypadku 2b i 2c:
a) brak wpływu moderacji na proces akceptacji
b) jeżeli w czasie kilku dni pomimo zabezpieczeń proceduralnych występuje wojna edycyjna (np. wprowadzenie zmiany, tydzień później revert tego samego) moderacja może zdecydować o poddaniu zmiany pod głosowanie.

2.2. W przypadku 2b i 2c:
a) wliczanie autora zmian jako jedną akceptację (jeżeli jest członkiem zespołu)
b) wymaganie 3 akceptacji nie wliczając autora zmian

a) wydaje się tu bardziej logiczne, bo nie daje sztucznej korzyści przy przepuszczaniu zmian przez inną osobę

3. Sposób głosowania:
3.1.
a) tajne
b) jawne

3.2. Wymagana większość:
a) >50%
b) >60%
c) >66%

3.3. Wymagane kworum:
a) 0%
b) 33%
c) 50%

3.4. Okres głosowania:
a) 1 tydzień
b) 2 tygodnie
c) miesiąc

Myślę że wymaganie kworum nie jest potrzebne żeby nie tworzyć impasu w przypadku małej aktywności, a 2 tygodnie to wystarczający okres żeby wszyscy aktywni członkowie się wypowiedzieli.

4. Skład zespołu:
4.1. Ilość miejsc:
a) stała
b) zmienna

4.2. Początkowy skład:
a) obecni użytkownicy z rangą główną (coś około 40)
b) inny wybór przez moderację

4.2.1. Co z obecnymi użytkownikami z ukrytą rangą
a) nic, zdejmujemy dostęp
b) w ciągu 30 dni od wprowadzenia zmian możliwość dołączenia do zespołu na wniosek zainteresowanego

4.3. Sposób nominacji nowych członków
a) na wniosek kandydata
b) na wniosek 3 obecnych członków

4.4. Sposób akceptacji nowych członków:
Jeżeli 4.1a, konieczny wybór między wieloma kandydatami, niestety tu wchodzimy w skomplikowaną dyskusję o systemach wyborczych: FPTP, IRV, Concordet, STAR, coś innego?
Jeżeli 4.2b, wystarcza zwykłe głosowanie o akceptację, warianty takie same jak w punkcie 3., moje preferencje takie same z wyjątkiem 3.1a

4.5. Sposób usuwania członków:
a) na wniosek 3 obecnych członków, później głosowanie tak samo jak przy dodawaniu
b) automatyczne po 3 miesiącach nieaktywności

Myślę że nie ma tu potrzeby procedury na usuwanie osób, niepotrzebne pole do konfliktów. Automatyczne usuwanie po nieaktywności powinno być wystarczające.

5. Sposób procedowania zmian w exe
a) import wybranego exe jako gotowego elementu
b) przeniesienie repozytorium exe i procedowanie zmian w kodzie tak samo jak zmiany w repozytorium

Liczę że przeniesienie rozwoju exe bliżej pozostałej części projektu zmniejszy rozbicie gałęzi do jakiego się obecnie zmierza.

6.1. Moderacja nie ma wpływu merytorycznego na podejmowane decyzje, może przystąpić jako członek na zasadach ogólnych.
6.2. Niezależnie od powyższego moderacja pilnuje przestrzegania regulaminu i może banować za nieodpowiednie zachowanie.
6.3. Jeżeli liczba członków spadnie poniżej 6, moderacja mianuje dodatkowych członków według własnej decyzji

9
Symulator / Odp: GUI symulatora - jak zwiększyć rozmiar tekstu?
« dnia: 14 Września 2023, 22:11:44 »
Idealnych rozwiązań tu nie ma, ale spróbuj tym pokręcić:
ui.fontsize 13
ui.scale 1.0

10
Bieżące Symulatorowe / Odp: Potencjalne zmiany w zarządzaniu projektem
« dnia: 14 Września 2023, 16:31:10 »
Addon manager, dla ułatwienia sprawy, mógłby być oddzielnym programem, który byłby w paczce. Natomiast problem z dodatkami jest taki, że ich instalacja jest względnie prosta, ale ich pliki mieszają się z bazowymi. Łatwo też o konflikty. Wolałbym pokombinować żeby addonsy miały swoje subfoldery np. w addons/ czy mods/, choć to wymagałoby sporych zmian w exe i nie wiem jak bardzo byłoby możliwe.
Mam do skończenia na kiedyś: https://github.com/Milek7/maszyna/tree/vfs
Centralizacja wszystkich dostępów do plików przez klasę ivfsstream, czytanie plików ze skompresowanego archiwum (eu07vfs jako niezależna biblioteka w C, bo archiwa musiałyby też otwierane przez zewnętrzne narzędzia i startery), do zrobienia została obsługa otwierania wielu archiwów dodatków jako overlay na poprzednie.

11
Pomoc doraźna / Odp: MaSzyna 23.07 problemy.
« dnia: 12 Sierpnia 2023, 01:48:12 »
Nie szukajcie dziury w całym. Pozycja w instalatorze "Pliki wykonywalne i zależności" ściąga odpowiednie exe.

12
Pomoc doraźna / Odp: MaSzyna 23.07 problemy.
« dnia: 11 Sierpnia 2023, 17:06:59 »
U mnie występuje problem braku/nie wyświetlania się tekstury bezchmurnego nieba na wszystkich sceneriach i torze doświadczalnym, załączam screena jak to wygląda i przekopiowany teks panelu ładowania może to coś pomoże
Starting MaSzyna rail vehicle simulator (release: EU07 (cmake), (unknown) (committed at 2023-01-13T20:46:35Z))To nie jest wersja z paczki.

13
Side note: development branch is currently at https://github.com/Milek7/maszyna/tree/sim. Main repository is not always kept up to date, sorry about that. I updated it now.

Back to topic: I'm not sure, I didn't seen this error before. Did you setup python directories using virtualenv?

14
Nigdzie nie powiedziałem że tak nie będzie
Napisałeś że nie chcesz aprobaty X osób, żeby poprawić 5 pikseli na teksturze. Więc chcesz mieć dostęp i możliwość wprowadzania zmian na repozytorium samemu, bo jak inaczej? Osoby bez stanowiska tego przecież mieć nie będą, więc dla równości wszyscy powinni wprowadzać zmiany zgodnie z procedurą.

Jak będziesz to ty, bo w końcu zaczniesz wchodzić tu częściej niż raz w miesiącu, to powiedzmy, że przeżyjemy.
Nie zanosi się na to. Ale istnieje takie pojęcie jak samorząd, o czym jest ten wątek.

Nie udajmy że ranga i dostęp do repozytorium to jakiś zaszczyt, który ma motywować ludzi. Trzeba zminimalizować próg wejścia do projektu, usunąć ukryte działy służące do kiszenia zasobów, i przy okazji usunąć specjalne stanowiska z większym dostępem, żeby zmniejszyć ilość awantur. To projekt potrzebuje ludzi, a nie ludzie projektu.

15
Uważam też, że dodaje to jakby nie patrzeć trochę satysfakcji, że się wyróżniasz, że coś realnie robisz dla symulatora, i tak, brak absolutnie niczego w tym stylu może być po prostu demotywujące dla nowych twórców.
Jak to ma komuś pomóc, to można zrobić jakiś licznik punktów, gwiazdek, eurogąbek czy czego tam, ale to byłoby za zaakceptowane zmiany na repozytorium, a nie za zasiadanie w radzie.

To ja tutaj byłbym na nie, że musisz mieć aprobatę X osób, żeby poprawić 5 pikseli na teksturze
Nowy zainteresowany użytkownik miałby takie same możliwości wprowadzania zmian jak każdy inny - a nie że jest jakaś uprzywilejowana grupa, której procedura nie dotyczy.

Słowem podsumowania, co do zaorania działów niepublicznych jestem na nie
Istnienie działów niepublicznych wymaga istnienia uprzywilejowanej grupy która ma do nich dostęp. Moim zdaniem to negatywny czynnik ograniczający możliwości udziału w projekcie nowym użytkownikom.

Dalej uważam, że mimo że temat przeorany, to potrzebujemy drugiego człowieka w administracji, żeby była opcja B w sytuacjach awaryjnych.
Jest 5 administratorów którzy logowali się w ciągu ostatniego roku. Czyli: zmian nie chcesz, ale chcesz kolejnego administratora, który ma wszystko uzdrowić. Aha.

16
Czy drobne zmiany takie jak poprawienie literówki w skrypcie czy wrzucenie nowych/aktualizacja czcionek do wyświetlacz
Tak, wszystkie zmiany przechodziłyby tą samą procedurę.

Mam nadzieję, że interfejs nie będzie tak toporny w użytkowaniu jak bugtracker, gdyż strasznie ciężko się z niego korzysta (i dlatego tam nie wchodzę).
Prawdopodobnie Gitea/Forgejo. Ewentualnie GitLab, ale ze względu na jego ociężałość i złożoność raczej bym nie chciał, byłby bardziej zajmujący dla administracji.
Bugtracker zostałby też przeniesiony w to samo miejsce.

17
Od strony technicznej, docelowo najprawdopodobniej postawiony zostałby interfejs do gita, i zostałyby utworzone repozytoria:
- strony głównej eu07.pl (zostałaby przeniesiona na generator hugo, zmiana plików aktualizowałaby treść strony)
- posty na mediach społecznościowych (dodawanie pliku oznaczałoby nowy post, który zostałby dodany przez wyznaczone osoby (lub automatycznie, ale nie sprawdzałem jeszcze czy to jest możliwe))
- repozytorium symulatora (w tym celu repozytorium zostałoby zmigrowane do gita, oraz zostałby postawiony serwer git-as-svn żeby dalej dało się korzystać z narzędzi svn)
- repozytorium exe (zostałoby przeniesione z mojego githuba, na którym jest obecnie aktualna gałąź)
Zmiany mogłyby być proponowane przez każdego użytkownika utworzeniem pull request, po aprobacie N członków zespołu byłby automatycznie mergowane.

18
za to można wstawić rzeczy do dokończenia
Równie dobrze rzeczy do dokończenia mogą wisieć publicznie. Przecież wiele jest niedokończonych rzeczy w działach takich jak Na warsztacie, i nie ma z tego powodu problemu.

Taka mała sugestia - te rzeczy nie bez powodu siedzą w zamkniętych działach, modele niedokończone, materiały, które w założeniu miały być udostępnione małej ilości osób - to wszystko w mojej subiektywnej opinii nie powinno być dostępne dla każdego, jest to po prostu głupie.
Co znaczy "udostępnione małej ilości osób"? Możliwości są dwie:
a) mamy zgodę na wykorzystanie danych materiałów, więc równie dobrze może wisieć w publicznym dziale, kiszenie w zamkniętym nic tu nie pomaga
b) z jakiegoś powodu nie możemy materiału wykorzystać, więc... po co mieć działy z materiałami, których nie da się wykorzystać? I tak są bezużyteczne.

Przecież to brzmi jak zaprzeczenie testu dodatków dla wszystkich, żeby testowali, skoro i tak ktoś z wyznaczonej grupy musi to przejrzeć i zatwierdzić.
Czym niby różni obecny się test dodatków od tego? Ostateczna decyzja przecież należy do tego kto wgrywa dodatek na repozytorium. Jasne, jest zasada że zgłoszone błędy muszą być poprawione, ale jak ktoś zgłosi, że piksel powinien mieć kolor 342534 zamiast 342635 to nikt nie będzie wstrzymywał dodatku z tego powodu, tylko zostanie wrzucony na repo mimo że teoretycznie był zgłoszony błąd. Moja propozycja ma na celu uregulowanie tego przejrzystymi zasadami: jest aprobata N osób - zmiana jest akceptowana. Żeby było jasne: ten system zastępowałby obecny test dodatków, po prostu trafiałyby tam wszystkie zmiany, zarówno nowe dodatki jak i zmiany które obecnie są robione na repozytorium bezpośrednio przez osoby z dostępem; w zasadzie byłoby to rozszerzeniem zakresu testu dodatków.

Brakiem benefitów czy nawet głupiego napisu przy nicku?
Jak ktoś robi coś tylko dlatego żeby mieć głupi napis przy nicku, to smutne to jest.

a potem ktoś coś odwali i będzie jak TK, który nie może orzekać, bo nie ma odpowiedniej liczby osób do głosowania XD
Dlatego liczę na dyskusję w jaki sposób miałoby to dokładnie działać - "będzie jak TK" niewiele tu wnosi. Administracja cały czas pozostanie, ale podejmowanie działań przez nią to jedynie ostateczność gdy system zawiedzie. Trzeba tak stworzyć procedury żeby zminimalizować to ryzyko.

No, to jeszcze uwalić moją robotę, żeby dbać o stronę na FB, bo tak xD
Chodzi o to żeby nie było specjalnych stanowisk, tylko wszystko przechodziło tą samą ścieżkę: dowolny użytkownik (również ty...) może napisać post, gdy uzyska aprobatę zespołu to jest dodawany.

Z upublicznieniem Wydziału Promocji bym się wstrzymał, ponieważ wiele lat temu w kilku wątkach podawaliśmy tam różne dane, które niekoniecznie powinny być publiczne: imiona, nazwiska, numery telefonów, maile, adresy, numery rachunków bankowych itd.
Nie chodzi mi o upublicznienie działów, tylko bardziej likwidację. Wyciągniecie przydatnych treści po to żeby nic nie zginęło w sytuacji: mamy zgodę na wykorzystanie materiałów, nie ma przeszkód żeby je wykorzystywać, ale zostały wrzucone do ukrytego działu. Wypisałem wszystkie działy, w praktyce pewnie z promocji, webmasterów, promotorów nie będzie nic do wyciągnięcia.

Jest repozytorium, do którego nie ma uprawnień każdy, ale każdy może stworzyć pull request i po testach i sprawdzeniu przez doświadczonych programistów dana zmiana zostaje zaakceptwoana
Właśnie coś w rodzaju pull requestów mam na myśli, z uregulowanymi zasadami zatwierdzania.

Niemniej nie jestem fanem tego pomysłu, bo wydaje mi się to dodawaniem zbędnej biurokracji. System zatwierdzania postów jednak popieram
Osób upoważnionych do dodawania postów może być więcej (wyznaczonych przez administrację/moderację), ale chodzi o to że byłaby to funkcja jedynie techniczna, po prostu wstawiane byłyby posty które zostałyby zatwierdzone przez zespół.

o, to jeszcze nie dość, że mamy radę, to ta rada nawet jak wyda jakąś decyzję, to nie może jej sama wykonać, tylko łaskawie czekać XD
Rada decyduje merytorycznie, i sama zarządza swoim składem. Końcowe wrzucenie na repozytorium to tak jak wyżej jedynie czynność techniczna, administracja/moderacja może wyznaczyć więcej osób w celu usprawnienia procesu.

19
Forum / Odp: Czy leci z nami pilot 2
« dnia: 09 Sierpnia 2023, 04:48:20 »

20
Bieżące Symulatorowe / Potencjalne zmiany w zarządzaniu projektem
« dnia: 09 Sierpnia 2023, 04:48:04 »
Ten post jest odpowiedzią na powracające wciąż żądania, żeby przyznać innej osobie stanowisko administratora. Jest to prezentowane przez część osób aktywnych w projekcie jako panaceum na wszelkie problemy z którymi od dłuższego czasu boryka się projekt MaSzyny w sferze zarządzania.

Faktem jest, że w ostatnim okresie część członków administracji zrezygnowała ze stanowiska, a moja aktywność jest niewielka. Nie jestem jednak skłonny nominować nowych administratorów, zarówno ze względu na ostatnie doświadczenia z przyznawaniem dostępów osobom które nadwyrężyły nasze zaufanie, jak i moje przekonanie że żonglowanie rangami nie wprowadzi realnej zmiany jakościowej.

Podnosi się argument że nowa administracja miałaby ożywić projekt, jednak w jaki sposób miałoby się to wydarzyć? Przecież nie jest wymagane aprobata od administratora, żeby poprawiać błędy, tworzyć nową zawartość czy wprowadzać zmiany w exe.

W celu uregulowania tej sytuacji, chciałbym zaproponować pewne zmiany w funkcjonowaniu projektu. Niezmiennie od początku mojej aktywności jestem przeciwnikiem specjalnych stanowisk, ukrytych działów, limitu postów w działach, czy innych rozwiązań ograniczających transparentność (i co za tym idzie, ilość afer związanych z dostępem do ukrytej treści i wycieków stamtąd) jak i uniemożliwiających pełne zaangażowania nowych osób bez zbędnych przeszkód.

Proponuję więc:
- Zlikwidowanie działów niepublicznych (deweloperów, betatesterów, repozytorium, promocji, webmasterów, promotorów). Nie pełnią one istotnej funkcji, poza możliwością bycia punktem niezdrowych konfliktów. Należałoby tu zrobić przegląd zawartych w nich treści i wyciągniecie tego co możemy wykorzystać (są odpowiednie zgody itd.) do działów publicznych. Reszty, skoro i tak nie można wykorzystać niech zostanie jedynie w czeluściach archiwum serwera, bez ogólnego dostępu.
- Utworzenie zespołu składającego się z kilkunastu osób z doświadczeniem w projekcie, którego głównym zadaniem byłaby akceptacja zmian wprowadzanych na repozytorium symulatora. Nie wiązałoby się to z żadnymi dodatkowymi benefitami czy dostępem.
- Wprowadzenie przejrzystej procedury wprowadzania zmian na repozytorium, w formie zbliżonej do obecnego testu dodatków. Zmiany wymagałaby akceptacji przez powyższy zespół, np. przez aprobatę N jego członków.
- Zespół mógłby w jakiś sposób dodawać nowych członków, np. przez nominację przez N jego członków i następnie głosowanie większością.
- Dodawanie treści na mediach społecznościowych również przechodziłoby proces aprobaty tak samo jak dla zmian repo, zaakceptowany post wstawiany byłby na platformę przez administrację/moderację, ale to byłaby czynność jedynie techniczna.
- Aktualizacji repozytorium po zaakceptowaniu zmian dokonywałaby również administracja, moderacja i wyznaczone przez nią osoby, ale to byłaby czynność jedynie techniczna. Docelowo powinno zostać opracowane narzędzia które to zautomatyzują.
- Wprowadzony zostałby stały cykl wydawniczy paczki, w którym terminy byłyby ściśle określone, np. miesięczne czy kwartalne. Zawierałyby stan repozytorium na dany dzień, bez osobnej fazy wydawniczej, testów, przesuwania terminów bo coś się nie załapało, itd. Publikacją paczki zajmowała by się administracja i moderacja (w obecnej sytuacji pewnie ja), do momentu przygotowania narzędzi które będą to robić automatycznie.
- Administracja i wyznaczeni przez nich moderatorzy czuwaliby nad zachowaniem kultury wypowiedzi. Zasadniczym wyzwaniem jest niedopuszczenie do eskalacji wszelkich dymów i zatrzymanie ich na samym początku. Jeżeli regulamin jest w tych kwestiach niewystarczająco jasny, może warto wprowadzić dodatkowy CoC.

Oczywiście to tylko wstępny zarys propozycji. Jeżeli opinia społeczności byłaby pozytywna, to trzeba przygotować uszczegółowione zasady, w szczególności w zakresie sposobu akceptacji, głosowania/aprobaty N osób, sposobu nominacji nowych członków, sposobu wyboru początkowych członków zespołu itd. Zachęcam do propozycji w tym zakresie.

21
Publikacje / MaSzyna 23.07
« dnia: 08 Sierpnia 2023, 20:09:38 »

Zapraszamy do zapoznania się z najnowszym wydaniem Symulatora "MaSzyna" - MaSzyna 23.07!

Paczka może być zainstalowana oddzielnie lub jako patch do wersji 23.04.
Pobierz instalator
NIE należy instalować paczki do folderów systemowych, takich jak Program Files!
Wymagane wolne miejsce na dysku do procesu aktualizacji z wersji 23.04: 6 GiB.
Wymagane wolne miejsce na dysku do procesu czystej instalacji: 68 GiB.

Instalacja manualna:
Torrent: https://stuff.eu07.pl/maszyna-r8639.zip.torrent
Aktualizacja: http://eupack.milek.dev/maszyna-diff-r8639-r8720.zip
Wymagane pliki dla exe: https://eu07.pl/userfiles/22158/m2304_exefiles_common.zip
Pliki wykonywalne dla systemu 64 bit:
https://eu07.pl/userfiles/22158/m2203_exelibs_win64.zip
https://eu07.pl/userfiles/22158/m2203_python_win64.zip
https://eu07.pl/userfiles/22158/m2307_exe_win64.zip
Pliki wykonywalne dla systemu 32 bit:
https://eu07.pl/userfiles/22158/m2203_exelibs_win32.zip
https://eu07.pl/userfiles/22158/m2203_python_win32.zip
https://eu07.pl/userfiles/22158/m2307_exe_win32.zip
Starter (od @szczawik): https://eu07.pl/userfiles/7492/starter230613t.zip
Rainsted: https://eu07.pl/userfiles/22158/rainsted.zip
Dodatkowe pliki dla twórców: https://eu07.pl/userfiles/22158/placeholdery_nodebank.zip

Biblioteki MSVC2008:
64 bit: https://download.microsoft.com/download/5/D/8/5D8C65CB-C849-4025-8E95-C3966CAFD8AE/vcredist_x64.exe
32 bit: https://download.microsoft.com/download/5/D/8/5D8C65CB-C849-4025-8E95-C3966CAFD8AE/vcredist_x86.exe
Biblioteki MSVC2015+:
64 bit: https://aka.ms/vs/17/release/vc_redist.x64.exe
32 bit: https://aka.ms/vs/17/release/vc_redist.x86.exe
Biblioteki UCRT (tylko dla systemów starszych niż Windows 10 nieposiadających aktualizacji Universal CRT):
64 bit: https://milek7.pl/.stuff/eu07exe/ucrt64.7z
32 bit: https://milek7.pl/.stuff/eu07exe/ucrt86.7z

22
Pomoc w tworzeniu / Odp: Zapowiedzi Ivony
« dnia: 08 Sierpnia 2023, 16:32:20 »
Można z Amazon Polly wygenerować, tam nie ma ograniczeń licencyjnych.

23
Najnowsza jest ta gałąź: https://github.com/Milek7/maszyna/tree/sim
Żadne zmiany w kodzie nie powinny być potrzebne.
Do działania oczywiście potrzebna jest paczka, najlepiej po prostu ściągnąć to co jest wyszczególnione w publikacjach: maszyna-r8639.zip oraz m2304_exefiles_common.zip Reszta wypisanych plików jest zależna od systemu więc się nie przyda.
Należy pamiętać że dla pełnej wydajności należy kompilować z -DCMAKE_BUILD_TYPE=Release
Python powinien mieć w katalogu paczki katalog virtualenv z zainstalowanym pillow:
virtualenv2 linuxpython64
source linuxpython64/bin/activate
pip2 install pillow
Z wyłączonym pythonem po prostu nie będą działać ekrany w pojazdach. (da się go wyłączyć przy kompilacji jak i wpisem w ini)
W zasadzie głównym problemem pełnego wsparcia innych platform jest brak starterów. A jak już się używa startera przez Wine, to w zasadzie równie dobrze można uruchomić przez Wine wszystko.
Można usunąć z ini wpis z domyślną scenerią, wtedy exe uruchamia wbudowany interfejs wyboru scenerii, ale jest on obecnie dosyć podstawowy w porównaniu do innych.
Na MacOS też można uruchomić, ale z tamtejszą obsługę OpenGL bywa różnie. (np. z moich doświadczeń renderer shaderowy miał mocne problemy wydajnościowe na M1)

24
Publikacje / MaSzyna 23.04
« dnia: 23 Kwietnia 2023, 17:00:56 »

Zapraszamy do zapoznania się z najnowszym wydaniem Symulatora "MaSzyna" - MaSzyna 23.04!

Jest to samodzielna paczka i należy ją zainstalować do pustego folderu.
Pobierz instalator
NIE należy instalować paczki do folderów systemowych, takich jak Program Files!
Wymagane miejsce na dysku do procesu instalacji: 62 GiB

Instalacja manualna:
Torrent: https://stuff.eu07.pl/maszyna-r8639.zip.torrent
Wymagane pliki dla exe: https://eu07.pl/userfiles/22158/m2304_exefiles_common.zip
Pliki wykonywalne dla systemu 64 bit:
https://eu07.pl/userfiles/22158/m2203_exelibs_win64.zip
https://eu07.pl/userfiles/22158/m2203_python_win64.zip
https://eu07.pl/userfiles/22158/m2304_exe_win64.zip
Pliki wykonywalne dla systemu 32 bit:
https://eu07.pl/userfiles/22158/m2203_exelibs_win32.zip
https://eu07.pl/userfiles/22158/m2203_python_win32.zip
https://eu07.pl/userfiles/22158/m2304_exe_win32.zip
Starter (od @szczawik): https://eu07.pl/userfiles/7492/starter230321.zip
Rainsted: https://eu07.pl/userfiles/22158/rainsted.zip
Dodatkowe pliki dla twórców: https://eu07.pl/userfiles/22158/placeholdery_nodebank.zip

Biblioteki MSVC2008:
64 bit: https://download.microsoft.com/download/5/D/8/5D8C65CB-C849-4025-8E95-C3966CAFD8AE/vcredist_x64.exe
32 bit: https://download.microsoft.com/download/5/D/8/5D8C65CB-C849-4025-8E95-C3966CAFD8AE/vcredist_x86.exe
Biblioteki MSVC2015+:
64 bit: https://aka.ms/vs/17/release/vc_redist.x64.exe
32 bit: https://aka.ms/vs/17/release/vc_redist.x86.exe
Biblioteki UCRT (tylko dla systemów starszych niż Windows 10 nieposiadających aktualizacji Universal CRT):
64 bit: https://milek7.pl/.stuff/eu07exe/ucrt64.7z
32 bit: https://milek7.pl/.stuff/eu07exe/ucrt86.7z

25
Najbardziej to bym chciał, żeby Maszyna działała na każdej karcie graficznej, a nie tylko na NVidii :P
Na jakich nie działa?

26
Pomoc w tworzeniu / Odp: Aktualny stan renderera
« dnia: 18 Lutego 2023, 19:36:52 »
Stąd moje pytanie, gdzie znajdują się aktualne źródła do symulatora, linki w wątku "Zrodla symulatora" wyglądają na dawno nie aktualizowane, najświeższe submity sprzed pół roku, reszta po kilka lat wstecz.
Tutaj są źródła co idą do paczek: https://github.com/Milek7/maszyna/tree/sim
Przy wydaniu paczki czasem merguję na główne repo, jak nie zapomnę.
1. brakuje cullingu- renderowane są obiekty poza ekranem
Zależy na co patrzeć, duże obiekty jako takie powinny być, np. niewidoczne pojazdy się nie renderują. Jeżeli chodzi o np. o niewidoczne elementy kabiny, no to tak, nie ma cullingu.
3. w passie dla cieni ręcznie discardowane są fragmenty co uniemożliwia GPU earlyZ!
Musi być dla alpha clipu. Nie wydaje mi się żeby to było znaczące wydajnościowo.
2. w 3 passie jest robiona jakaś dziwna kopia ramki (jeszcze nie odkryłem po co to się tu znajduje :>)
Hm, doprecyzuj o co chodzi.

Największą bolączką jest jednowątkowe renderowanie z osobnym drawcallem dla każdego submodelu.

27
Na warsztacie / Odp: Pomysły na rozwój exe
« dnia: 18 Lutego 2023, 16:15:29 »
Sama zmiana nazw dla samej zmiany nazw, raczej mnie martwi. Polecam robić bardziej zlokalizowane commity, np. dodanie nowego ficzera, lub kompleksowy refactoring wybranego modułu (nie tylko zmiany nazw), a nie zaczynać od zmian nazw rozrzuconych po całym projekcie. Łatwiej wtedy przeanalizować takie zmiany, i nie generuje aż tylu niepotrzebnych problemów przy mergowaniu.

28
Symulator / Odp: Pomoc z Ekranem zewnętrznym EN57AL
« dnia: 05 Listopada 2022, 19:40:39 »
python.displaywindows yes // włącznik funkcji
python.viewport dynamic/pkp/e186_v2/traxx_renderer Generic_PnP_Monitor:1024,1080 1024 600 0.12 0.18 1.81 2.4 // konfiguracja ekranu, dostępne nazwy monitora są w logu przy uruchamianiu, dalej wielkość okna, offset, skala tekstury

// optymalne ustawienia zależą od sterownika opengl i fazy księżyca
//python.sharectx no // wyłączenie współdzielenia kontekstu gl z głównym oknem
//python.vsync no // wyłączenie vsync w oknach dodatkowych
//python.fpslimit 5 // jeżeli vsync=no to ustawić limit tutaj
//python.threadedupload no // wyłączenie wysyłania tekstury na główny kontekst na dodatkowym wątku
//python.uploadmain no // wyłączenie wysyłania tekstury na główny kontekst jeżeli nie potrzeba mieć ekranu w oknie symulacji, można zastosować jeżeli sharectx=no

29
Bocznica / Odp: Demokratyczne głosowanie nad składem osobowym moderacji
« dnia: 30 Października 2022, 20:05:27 »
Zakazy 23.

30
Pomoc doraźna / Odp: Maszyna w 4k
« dnia: 21 Września 2022, 17:55:51 »
Tego wpisu w ogóle nie powinno domyślnie być. Starter jest nadgorliwy, czy zły plik w paczce?

Strony: [1] 2 3 ... 30