Launcher w Maszynie

[Jeżyk]

Witam.

Może za bardzo wychodzę w przód(możecie uznać mój pomysł za niepotrzebna pierdołę), ale co powiecie aby w maszynie pojawił się taki launcher jak w niektórych grach, który by sam pobierał i instalował aktualizację(łatkę na błędy), czy jakieś dodatki typu nowy lok, sceneria. Aktualnie to albo samemu trzeba to robić albo pobrać nową pc, na którą trzeba czekać rok. Raczej ułatwiło by to niezaawansowanym użytkownikom posiadanie najlepszej wersji zwłaszcza, że niektórzy nie odwiedzają forum z publikacjami.

Kłopot w tym kto by mógł takie coś zrobić i jakby to działało, potrzebny by był wtedy jakiś serwer najlepiej 24/h z którym launcher by się łączył, no i jakiś programista który by to wykonał bo co do grafiki to całością mogę zająć się ja.
Można też wbudować coś takiego w obecny starter(zdaję sobie sprawę, że coś takiego istnieje, ale nie wiem czy spełnia swą funkcję) i zająć się zrobieniem jakieś ładnej grafiki do startera...

Co o tym myślicie?

[mikol]

A to co jest w Rainstedzie i pyta się czy zainstalować aktualną wersję to co?

[Balaclava]

Jemu chodzi o dodatki typu lokomotywy, scenerie itp.

[mikol]

Faktycznie. Zagapiłem się, przepraszam.

Raczej ułatwiło by to niezaawansowanym użytkownikom posiadanie najlepszej wersji zwłaszcza, że niektórzy nie odwiedzają forum z publikacjami.

A wziąłeś pod uwagę fakt, iż taki serwer na dodatki posiada duża ilość gier, które nie posiadają swojego forum? Bez obrazy, pomysł jest ciekawy ale po co naprzykrzać się komuś na siłę z pobieraniem dodatków? Jak sam wspomniałeś, mamy genialne forum i genialny (to nie sarkazmy) dział na nim o nazwie Publikacje. Użytkownik Symulatora, jeśli chce mieć dany dodatek wejdzie sobie i pobierze z Publikacji. Jeśli nie chce - nie pobierze.
Czy tak trudno jest pobrać najnowszą wersję Symulatora z Publikacji? Uważam, że nie ma potrzeby zmuszać nikogo do pobierania dodatku.

[SKP]

Rainsted z założenia miał pełnić taką funkcję: http://eu07.pl/forum/index.php/topic,6252.msg63023.html#msg63023. W Rainstedzie jest nawet zakładka Instalator.

[Ra]

Mi przestało specjalnie zależeć na dopracowaniu instalatora gdy zająłem się edytorem, a potem poprawkami w EU07.EXE. Jest jakiś problem organizacyjny z przygotowaniem paczek do automatycznego instalowania. Mimo iż maksymalnie przygotowałem automat do zbierania informacji o plikach, nadal są zaległości z 2010 roku:
http://eu07.rainsted.com/archives/

Nadal jestem otwarty na propozycje, jak by to można było zrobić lepiej. Moje propozycje się nie przyjęły i nie cieszą się zainteresowaniem.

[libertyn89]

Wysłałem kiedyś swoje propozycje Ra, ale tak jak wspomniał zajął się edytorem i EXE. W załączniku zrzut ekranu z tego co wtedy zaproponowałem [zdaję sobie sprawę, że grafika nie porywa, a sama koncepcja swoje latka już ma :)]. Jakby ktoś był zainteresowany mogę udostępnić opis.

[Jeżyk]

Sam raczej zielony jestem w programistycznych sprawach, ale zawsze gdyby ktoś się porwał na takie coś to mogę testować(doświadczenie z otwartych betatestów sc2) i pomóc albo zrobić całą potrzebną grafikę, także w 3d oraz krótkie "GIFowe" animacje.

[Ra]

Z programowaniem nie ma problemu, potrzebny jest raczej szczegółowy opis, jak ma to działać i jak wyglądać.
  Dodano: 08 Sierpnia 2012, 18:25:02 No i ja byłbym za tym, żeby zamiast wydawania paczek całościowych były by paczki aktualizacyjne, pobierane automatycznie. Wtedy paczka całościowa powstawała by jako złożenie aktualizacji. PC2009 powstała po to, by wprowadzić tekstury DDS, w PC2010 miał być powrót do TGA, a w PC2011 pojawiły się pliki E3D zamiast T3D. Zmiany te były dosyć radykalne i miały wpływ na większość plików w paczce, a obecnie nie ma pilnej potrzeby na wydanie nowej paczki całościowej. Poważniejsze zagadnienia typu zmiana struktury katalogowej, użycie terenu E3D, czy podział scenerii na komórki wymagają jeszcze pracy. Strukturę katalogową w paczce można w miarę szybko zmienić, większym problemem jest dostosowanie do niej scenerii w formacie MAX i RSF, a także udostępnienie narzędzia do konwersji scenerii dostępnych poza oficjalną paczką.

[Szycha441]

Ale wtedy użytkownik symulatora byłby uzależniony od internetu. W obecnej sytuacji idziemy np. do kolegi, pobieramy dodatek, który jest potrzebny i sami go instalujemy. Gdyby taki luncher wszedł w życie myślę, że było by to tylko na rękę tym co są podłączeni do neta. A nie każdy użytkownik go ma. Więc trzeba się zastanowić dobrze nad ewentualnym wcieleniem takiego pomysłu.

[Jeżyk]

W takim razie ja przedstawię moją ideę dotyczącą startera. Dodam, że okno było by otwierane nie okienkowo ale na cały pulpit. Niestety niektóre rzeczy potrzebowały by "modernizację" exe.

W załączniku układ głównego menu na przykładowa rozdzielczość monitora 1280x1024.

Każdy inny element ma swój kolor:

Zielony - elementy głównego menu

START - wybieramy scenerię(pokaże się info o scn oraz dostępne składy)> skład( pokaże się info o pogodzie, czasie, zadaniach itp) - nie będzie wyboru exe, a w polu info nie będzie żadnego info o wersji

SERWER RUCHU - obecnie nie będzie możliwości wyboru no chyba że powstanie;)

USTAWIENIA - podobny wygląd jak teraz tylko poukładane w kategoriach - dźwięk | grafika | sterowanie(możliwa zmiana klawiszologi wg. gustu | gra(wybór poziomu zaawansowania - obecnie "prosty , normalny, specjalny" i inne pierdoły które jeszcze się wymyśli)

DODATKI - taki updater - łączył by się w celu aktualizacji

TABOR - po katalogowane jak w ustawieniach wszelkie rzeczy od taboru np. jak w rainstedzie "tabor posiadany" , "składy" itp.

AUTORZY - krótkie info o autorach

WYJŚCIE - zamyka program

Pomarańczowy - minimalizuje program do paska w win i otwiera wybrana opcję...

POMOC - przenosi na stronę www pomocy.

FORUM - przenosi na stronę www forum.

EDYTOR - otwiera edytor map(taki jak teraz).

Szary - z elementami nie można nic zrobić...

Czerwony - pasek ładowania sceneri - zakładam, że po wybraniu scn i kliknięci przycisku start ładowała by się ona w tle a jej postęp wyświetlony był by na pasku, po załadowaniu w miejscu paska pojawił się by przycisk "wejście do symulacji" odpalał by on eventy (shift+1...) a nas przenosił do symulacji.

Ciemno zielony - wszelakie info o exe, starterze itp.

Biały - w tym miejscu były by różne zdjęcia kolei co chwili się zmieniające w płynnym przejściu(pojawianiu się, zanikaniu), w zaznaczonym miejscu było by info na ich temat np. jaka stacja... oglądane np podczas ładowania scn.


Oczywiście wszelkie rzeczy są do zmiany i ustalenia.

[Szycha441]

Idea super tylko nie możemy uzależnić naszego smyka od internetu.

[Ra]

Ja mam internet stacjonarny od 10 lat, więc w obecnych czasach jest to raczej standard. Ostatnio sobie kupiłem Railworks 3 Train Simulator 2012 za 2.99 euro i chociaż poraża brakiem związku drutów ze słupami, ograniczonym sterowaniem i słabym działaniem hamulców przy niskich prędkościach, to nie daje się uruchomić bez wcześniejszego zalogowania na Steam.

[Jeżyk]

To jak twój kolega ma internet niech on zaktualizuje symka a potem ci nagra na dysk. Zresztą nikt nie powiedział, że to ma być online aby grać nie trzeba neta.

[Szycha441]

No też prawda. Ale niech większość użytkowników się wypowie i wtedy można zadecydować ewentualnie. :)

[matikolejarz]

Proszę bardzo. Ja jestem jak najbardziej za. Mam tylko propozycję: aby była opcja, żeby użytkownik sam mógł zdecydować czy program ma aktualizować symka.

[Jeżyk]

Proszę bardzo. Ja jestem jak najbardziej za. Mam tylko propozycję: aby była opcja, żeby użytkownik sam mógł zdecydować czy program ma aktualizować symka.

Właśnie takie opcje będą w ustawienia>gra...

[mikol]

Mam tylko propozycję: aby była opcja, żeby użytkownik sam mógł zdecydować czy program ma aktualizować symka.

ale co powiecie aby w maszynie pojawił się taki launcher jak w niektórych grach, który by sam pobierał i instalował aktualizację(łatkę na błędy), czy jakieś dodatki typu nowy lok, sceneria.

Wyjaśnij, jaki jest sens tworzenia opcji czy chce, czy nie chce dodatku? To narzędzie ma nam automatycznie instalować dodatki a nie za naszym pozwoleniem.

[SKP]

@Ra, Ty tu jesteś od projektowania algorytmów, ale pozwolę sobie napisać jak ja to widzę.
1. Na serwerze znajduje się plik XML, jest w nim zawarta nazwa Paczki Całościowej (właściwie to wersja) oraz nazwy, wersje i linki do dodatków opublikowanych po wydaniu paczki. Wersje dodatków można "spisywać" z linku do nich. Oczywiście byłyby one grupowane wg typów:
>scenerie
 -całe scenerie
 -dodatki do scenerii (ale tak większe, których użytkownicy nie będą musieli wstawiać ręcznie)
 -scenariusze
>pojazdy
 -tekstury
 -kabiny
 -pojazdy z kabiną
 -pojazdy bez kabiny
>inne dodatki (można wymyślić jeszcze inne kategorie, ale to teraz nieważne)
2. Na komputerze znajduje się plik XML o niemalże identycznej składni, z tym że zawierający aktualnie zainstalowane dodatki. Dodatki mogą być też znakowane czy został pobrany i zainstalowany pomyślnie, czy pobieranie zostało anulowane oraz czy użytkownik zażyczył sobie, by Instalator o tym nie wspominał.
3. Przy uruchomieniu programu aplikacja pobiera plik XML z serwera, sprawdza jego wersję i jeśli znajdują się w nim dodatki, których nie ma w lokalnym XML, pobiera te dodatki (pierw pyta użytkownika czy ten tego chce). Po pobraniu, w lokalnym XML dopisuje dodatek i zmienia parametr na "Pobrany" (mogą to być parametry liczbowe).
4. Program sprawdza czy dodatek został poprawnie rozpakowany i jeśli tak, to zmienia parametr w lokalnym XML na "Zainstalowany".
5. Zawartością serwerowego pliku XML można zarządzać z poziomu przeglądarki. Można zrobić skrypt w PHP (coś jak obecny upload), z którego mogliby korzystać tylko użytkownicy z rangą. Pozostali użytkownicy mogą po zakończonych testach poprosić kogoś, kto ma dostęp do skryptu o wrzucenie informacji o dodatku do XMLa na serwerze.


Co do interfejsu graficznego, byłbym raczej za maksymalnie minimalistycznym wyglądem. Jedynie lista zainstalowanych plików i lista plików sugerowanych do zainstalowania. Byłaby możliwość pobrania dodatków, których nie posiadamy, oznaczenia brakującego dodatku jako już pobranego (np. ręcznie wgranego) lub pobranie bez instalacji (czyli taka wersja dla tych, którzy nie ma internetu).


Plik mógłby też być napisany w innym języku niż XML (np. YAML), a zarządzać nim można by było np. z poziomu aplikacji, a nie przeglądarki. Mógłby mieć też inne parametry lub dodatkowe opcje. To jednak tylko sposób wykonania i zrobisz wg własnego uznania.


Przedstawiłem, moim zdaniem, jeden z najprostszych do zrealizowania pomysłów. Nie wymaga on specjalnego katalogowania paczek ani wykonywania dodatkowych, skomplikowanych operacji przez program. Plik XML nie zajmuje też dużo miejsca, a sposobów realizacji mojego pomysłu jest wiele. Co o tym myślisz Ra, czy można to zrealizować, czy może pomysł z góry jest skazany na porażkę? Jeśli tak, to dlaczego? Może któryś z punktów napisałem tak, że tylko ja to rozumiem, proszę więc o napisanie co jest niezrozumiałe. Być może nie wszystko jest idealne, część pomysłów mógłbyś udoskonalić.


@7play4game, wydaje mi się, że zrealizowanie tego o czym mówisz będzie niemożliwe. Starter nie może pokazywać stanu ładowania scenerii przez EU07.EXE, bo to dwa inne, działające prawie niezależnie programy.

[mikol]

XML jest najpopularniejszym obecnie uniwersalnym językiem przeznaczonym do reprezentowania danych. Składnia YAML-a jest bardziej przejrzysta dla człowieka, ponieważ struktura dokumentu określona jest znakami nowej linii i wcięciami, a nie znacznikami otwierającymi i zamykającymi. YAML, podobnie jak XML, ma strukturę drzewa uporządkowanego, ale ponadto obsługuje kolekcje już na poziomie języka. Żaden z tych formatów nie udostępnia bogatego mechanizmu reprezentacji dużych ilości danych w postaci binarnej.

[SKP]

Wikipedię wszyscy umiemy czytać.

[Ra]

To mogę z góry powiedzieć, że nie wyjdzie:

Czerwony - pasek ładowania sceneri - zakładam, że po wybraniu scn i kliknięci przycisku start ładowała by się ona w tle a jej postęp wyświetlony był by na pasku, po załadowaniu w miejscu paska pojawił się by przycisk "wejście do symulacji" odpalał by on eventy (shift+1...) a nas przenosił do symulacji.

Nie ma możliwości określenia postępu ładowania, przyczyny są dwie. Po pierwsze, pliki mogą zawierać include, które może się wczytywać dowolnie długo. Trzeba by zrobić bazę danych zawierającą czas wczytywania każdego pliku i kalibrować ją jeszcze zależnie od egzemplarza komputera. Po drugie, aby pasek się aktualizował podczas wczytywania, trzeba zrobić obsługę wątków, a z praktyki wiem, że jak coś działa dobrze bez wątków, to po użyciu wątków może się kopać w bliżej nieokreślonym miejscu. Po trzecie, zamiast grzebać nad paskami, wolałbym zrobić wczytywanie binarne, a wtedy pasek nie będzie miał żadnego sensu.

Biały - w tym miejscu były by różne zdjęcia kolei co chwili się zmieniające w płynnym przejściu(pojawianiu się, zanikaniu), w zaznaczonym miejscu było by info na ich temat np. jaka stacja... oglądane np podczas ładowania scn.

To też by musiało być zrobione na wątkach. A robiąc już wątki w kodzie, to lepiej wczytać plik binarny scenerii, a następnie w czasie rzeczywistym doczytywać modele i tekstury, by pojawiały się w miarę wczytywania.

Ponadto obecnie Symulator i Rainsted to są dwa oddzielne programy i nie mam żadnej intencji, by je łączyć.

[Jeżyk]

Wyjaśnij, jaki jest sens tworzenia opcji czy chce, czy nie chce dodatku? To narzędzie ma nam automatycznie instalować dodatki a nie za naszym pozwoleniem.

Ale ten pomysł cały czas ewoluuje, to była jedna idea a teraz jest nieco inna, zresztą jeżeli ktoś niema internetu to taka opcja się przyda ewentualnie nie będzie grał na najnowszej wersji.

@skp Napisałem, że może to wymagać zmiany exe. W najgorszym razie wyleci pasek ładowania.

@Ra Tylko, że tło nie musi działać tylko podczas ładowania, najlepiej aby zmieniało się cały czas...

[libertyn89]

@SKP, to co zaproponowałeś niewiele różni się od obecnego systemu (który tylko wymaga dopracowania interfejsu Instalatora, bo obecny nie jest zbytnio intuicyjny oraz nie przystaje chociażby do podziału DDS/TGA [co można zmienić np. tak jak na screenie, który pokazałem wyżej]). Obecnie przecież nie da się zainstalować dwa razy tego samego dodatku, bo jak wybierzesz go na liście paczek (obojętnie w jakiej kategorii to Instaluj i Pobierz nie będą aktywne).

Problemem obecnego Instalatora jest tylko to, że nie są tworzone skrypty instalacyjne i nikt tego nie używa.

[Tolein]

Nie wiem czy jest jakikolwiek sens aktualizowania "na siłę".
I raczej nie należy dawać wyboru na zasadzie opcji w ustawieniach, tylko po prostu klikamy update, wybieramy co chcemy zaktualizować i wtedy się aktualizuje.
Być może ktoś ma internet stały, być może ktoś nie ma, różnie można tutaj polemizować, ale po co mam czekać np. pół godziny na pobranie nowych modeli i tekstur czegoś, albo jakiejś scenerii, jeśli nie chcę z niej korzystać.
Ja myślę, że sensownie byłoby zamiast "dodatki" zrobić "aktualizacja" i tam wyświetlać listę rzeczy dostępnych do pobrania, lub zaktualizowania (jeśli mamy starszą wersję jakiegoś modelu, tekstury, scenerii, etc). Wtedy można by sobie spokojnie zaznaczyć co chcielibyśmy, a czego nie chcemy pobrać/zaktualizować, kliknąć "aktualizuj" i jazda.
Co więcej, warto wziąć pod uwagę jakąś hierarchę, czyli np. mamy listę taboru, a po wybraniu jakiejś pozycji wyświetlałaby się lista dostępnych tekstur. Wchodzenie w głębsze detale, jak dźwięki, czy inne tego typu, uważam za niepotrzebne, bo z założenia chyba ma ten launcher być idioto-odporny i działać niezależnie od wiedzy/umiejętności użytkownika, a jeśli ktoś chce sobie podmieniać dźwięki taboru, to raczej wie jak to zrobić bez pomocy launchera, tak samo jakiekolwiek dalsze zagłębianie się w scenerie jest oznaką braku zaufania dla twórców. Skoro "wypuszczają" jakiś produkt, to jest to chyba kompletne dzieło i o ile ktoś chce sobie podmienić np. teksturę podsypki, to znów - jest to raczej zabawa dla zaawansowanych - powinien więc wiedzieć jak sobie z tym poradzić bez launchera. Innymi słowy do wyboru jedynie rzeczy które istnieją równolegle wobec siebie, jednocześnie będąc oficjalnymi dodatkami (wszak jeden lok może mieć różne tekstury, np. tekstury dziewiątek i husarzy na euro), a reszta tylko w zakresie wyboru - chcę / nie chcę.

[ryba825]

Jestem za aktualizacjami on-line.

Automatyczne aktualizacje nie znaczą tyle samo co "w tle", mogą one pytać się użytkownika, czy chce sprawdzić, czy jest dostępna nowa wersji i czy chce zaktualizować. Automatyczne znaczy: użytkownik nie ingeruje w zmiany na plikach.

[Ra]

1. Na serwerze znajduje się plik XML, jest w nim zawarta nazwa Paczki Całościowej (właściwie to wersja) oraz nazwy, wersje i linki do dodatków opublikowanych po wydaniu paczki. Wersje dodatków można "spisywać" z linku do nich. Oczywiście byłyby one grupowane wg typów: (...)

No mniej więcej tak jest teraz, tylko jest to plik INI. Pozwala on również rozpoznać paczkę o dowolnej nazwie, ponieważ zawiera ciągi znaków opisujące znane paczki (np. 259U-00443718-71587B90).
http://eu07.rainsted.com/update1/install.ini

2. Na komputerze znajduje się plik XML o niemalże identycznej składni, z tym że zawierający aktualnie zainstalowane dodatki. Dodatki mogą być też znakowane czy został pobrany i zainstalowany pomyślnie, czy pobieranie zostało anulowane oraz czy użytkownik zażyczył sobie, by Instalator o tym nie wspominał.

Obecnie do każdej paczki potrzebny jest plik (też INI) z listą zawartości (nazwy, długości, CRC). Porównując zawartość pliku z zawartością dysku można stwierdzić, czy paczka jest zainstalowana. Aczkolwiek wystarczy ręcznie zmodyfikować jakiś plik i to będzie przesłanka do wykrycia niepełnego zainstalowania paczki. Wątpię, czy jest sens oznaczać jako jednobitową flagę zainstalowany/niezainstalowany, bo z plikami może różnie być. Np. komputer może się zresetować podczas rozpakowywania. Plik INI może też zawierać zależności, czyli np. Instalator dociągnąć inną paczkę i wypakować z niej choćby jeden plik - tak jest teraz w przypadku Lxd2, której paczka nie zawiera jednego z dźwięków.

3. Przy uruchomieniu programu aplikacja pobiera plik XML z serwera, sprawdza jego wersję i jeśli znajdują się w nim dodatki, których nie ma w lokalnym XML, pobiera te dodatki (pierw pyta użytkownika czy ten tego chce). Po pobraniu, w lokalnym XML dopisuje dodatek i zmienia parametr na "Pobrany" (mogą to być parametry liczbowe).

Prawie tak jest, tylko trzeba wejść w Instalator i nacisnąć przycisk, by pobrać ten plik. Po wybraniu dodatku można pobrać plik instalacyjny (R_I), w którym jest opis, linki do obrazków oraz lista plików z długościami i sumami CRC.

5. Zawartością serwerowego pliku XML można zarządzać z poziomu przeglądarki. Można zrobić skrypt w PHP (coś jak obecny upload), z którego mogliby korzystać tylko użytkownicy z rangą. Pozostali użytkownicy mogą po zakończonych testach poprosić kogoś, kto ma dostęp do skryptu o wrzucenie informacji o dodatku do XMLa na serwerze.

To jest do dopracowania...

Przedstawiłem, moim zdaniem, jeden z najprostszych do zrealizowania pomysłów. Nie wymaga on specjalnego katalogowania paczek ani wykonywania dodatkowych, skomplikowanych operacji przez program.

Katalogowanie paczek jest po to, żeby można było znaleźć plik o pewnej nazwie. Być może po wydaniu 3 ostatnich paczek całościowych niektóre problemy stały się mniej istotne (np. paczki dodatków rozrzucone na różnych serwerach, o nazwach luźno związanych z zawartością, różne nazwy tych samych paczek, różne sposoby spakowania tych samych plików), ale nadal istnieją np. scenerie pozapaczkowe (chociażby SDR), do uruchomienia których potrzebne będą dodatkowe pliki, niekoniecznie obecne w PC.

[SKP]

Szczerze mówiąc, myślałem że do tej pory działało to w zupełnie inny sposób.

Porównując zawartość pliku z zawartością dysku można stwierdzić, czy paczka jest zainstalowana.

To nie trwa zbyt długo? Nie lepiej założyć, że użytkownik nie usunął żadnego pliku, a dodatek ma wszystkie potrzebne pliki? Czasy, w których użytkownicy ręcznie kompletowali paczki i jak wspomniałeś do działania X był potrzebny Y, a do działania Y, Z dawno minęły. Obecnie jedynie w scenariuszach wymaga się posiadania niektórych pojazdów, ale można założyć, że user je też posiada.


Z resztą coraz bardziej mi się zdaje, że wymyśliłeś jak na razie najlepszy sposób na działania Instalatora, ale problemem jest brak współpracy programu z TD. Zakładając, że program byłby wykończony (w końcu sam mechanizm jest, wystarczy poprzesuwać przyciski i zmienić trochę wygląd), można by było rozbudować Upload - dodać nowy przedrostek, który wysyłałby paczkę na serwer, a jednocześnie dopisywał odpowiednie dane do INI, krótko mówiąc "załatwiałby wszystkie formalności".

[ryba825]

To nie trwa zbyt długo? Nie lepiej założyć, że użytkownik nie usunął żadnego pliku, a dodatek ma wszystkie potrzebne pliki? Czasy, w których użytkownicy ręcznie kompletowali paczki i jak wspomniałeś do działania X był potrzebny Y, a do działania Y, Z dawno minęły. Obecnie jedynie w scenariuszach wymaga się posiadania niektórych pojazdów, ale można założyć, że user je też posiada.

Lepiej sprawdzić, czy są wszystkie pliki poprawne, uniknie się wielu problemów z działaniem symulatora, bo plik się zepsuł, wyparował.

[SKP]

Sam się nie zepsuje ani nie wyparuje. Jak ktoś go zepsuł, to niech cierpi ;)
EDIT: Ja jestem miłośnikiem najprostszych rozwiązań będących wręcz na granicy prowizorki. Wiem, że nie są one idealne ;)