Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Inne Projekt: skrypt New World Disorder
#1
Ostatnio przy okazji pojawienia się nowego przemysłu (FIRS) na Mapie Polski autorstwa pAtera, padła propozycja dodania do niej skryptu, który zmieniłby okrutnie prostą zasadę "sześciu stacji", która w grze decyduje o szybkości rozwoju miast (napisałem o niej już tutaj, tutaj, tutaj i tutaj), na taką, która dodawała by większego realizmu, nie była tak banalna i nadawałaby znaczenie dostawom żywności, towarów, czy materiałów budowlanych.
Jest już kilka skryptów, które zostały zbudowane na podobnych założeniach. Przetestowałem wszystkie te, które mogłyby być warte uwagi: Real Growth, City Controller, Renewed City Growth, Balanced City Growth, City Growth Limiter oraz City Buildier (ich opis pod kątem tego scenariusza znajdziecie >tutaj<). Wyszło jednak na to, że każdy z dostępnych miał jakieś mniejsze albo większe mankamenty. A to miasta rosły zbyt łatwo lub zbyt szybko, a to bezwzględnie domagały się dostarczania wszystkich produktów wymagając przez to od gracza, aby zajmował się wszystkim. Pojawiały się też inne problemy, ale już mniejsza o to.
Ostatnim ze skryptów, który zaprezentowałem w opisie był...
(04-02-2016, 02:00)LaChupacabra napisał(a): New World Disorder
[Obrazek: 79407_Skrypt_New_World_Di.png]
O nim napiszę kiedy indziejWink Na razie mam po dziurki w nosie wszelkich skryptów...

Ten skrypt tak naprawdę nigdy nie istniał, zaś grafika panelu miasta jest tylko kolażem zrobionym w Paint'cieSmile Liczby w nim ukazane nie są jednak przypadkowe. Ta grafika powstała z pomysłu, no i przede wszystkim po to, aby być może kogoś, kto potrafiłby napisać odpowiedni kod, nią zainspirować. U mnie niestety cienko w tej kwestii. Nie jest to jeszcze w 100% przemyślane, nawet nie wiem czy wszystkie z założeń są możliwe do zrealizowania. Zamieściłem to jednak ze względu na presję jaką zaczął wywierać na mnie Milek7, z którym poruszyłem wcześniej ten tematSmile

Aby nie wyrywać postów z innego tematu (Mapa Polski pAtera):
(04-02-2016, 21:01)LaChupacabra napisał(a):
Milek7 napisał(a):A ten NWD, to prawdziwy czy tylko makieta?
Ten NWD to skrypt, o którym Ci mówiłem. To już jego trzecia lub czwarta wersja. Na razie jest zapisany w programie Paint w formacie PNG - wymagałby "jedynie" odpowiedniej konwersji do NUT'sa.Smiley29
Mógłbym go dokładnie opisać, jak by miał działać, wszelkie zależności, co z czego wynika i dlaczego, ale już ktoś inny musiałby te wszystkie teorie przerobić na kodSmile

Heh... miałem nadzieję odpocząć od tej całej skryptologii.

(06-02-2016, 16:00)Milek7 napisał(a): Zaczynam prace nad NWD Tongue
EDIT: Jest postęp
http://openttd-polska.pl/attachment.php?aid=745

Ponieważ ruszyły już pierwsze prace nad skryptem, a młody Frankenstein zaczął się niemrawo, ale jednak poruszać, postanowiłem założyć nowy wątek, który będzie poświęcony dalszym pracom nad nim. Kto wie, może urosną mu jeszcze ręce i nogi...Smile

A więc...

Na razie jedynie z grubsza zarysuję założenia:
1. Głównym założeniem skryptu jest swoboda w sposobie rozwoju miast, aby nie było konieczności budowania całych wielkich sieci przemysłowych tylko po to, by miasta mogły się rozwijać.
2. "Wzrost miasta" byłby jedynie informacją o ile miasto zmieniło swoją populację. Ale! Wskaźnik lepiej aby był średnią z ostatnich 12, może nawet 24 miesięcy. W ciągu miesiąca populacja pomimo szybkiego wzrostu często się chwilowo kurczy - to byłoby niekiedy nawet bardzo mylące.
3. Bezrobocie wyznaczałoby tempo rozwoju miasta. Maksymalny jego poziom oznaczałby brak rozwoju miasta - byłby ustawialny i de facto oznaczał poziom trudności. Na poziom bezrobocia wpływ miałyby wszystkie pozostałe elementy. Ich znaczenie byłoby ustawialne.
A1. Komunikacja miejska - te 49% oznaczałoby, że właśnie taki procent spośród "wyprodukowanych" przez miasto pasażerów i poczty zostało przetransportowanych (liczone razem). Podobnie liczone jak w skrypcie CGL z tym, że tutaj jest to wpływ a nie blokada. Oczekiwany procent transportu byłby ustawialny w parametrach. Im bliżej wskaźnik byłby tej wartości tym większy wpływ na redukcję bezrobocia. Przekroczenie wyznaczonej wartości dalej zmniejszałoby bezrobocie, ale już w coraz mniejszym stopniu.
A2. Komunikacja międzymiastowa - 28 z 327, czyli 8,5% oznaczałoby ilość miast względem ich ogólnej liczby, z którymi dane miasto ma aktywne połączenia (ocena połączenia). Wszystkie niezbędne dane powinny być dostępne, pytanie tylko czy skrypt jest w stanie je odczytać.
A2'. Alternatywne rozwiązanie - jeśli powyższe okazałoby się niemożliwe lub zbyt trudne - aby podział na rodzaje komunikacji miał sens, wymagałoby określenia dla dostarczanych pasażerów/poczty faktu pochodzenia z innego miasta, albo odległości stacji z jakiej przybyli.
B1 i 2. Prąd - Byłyby dostępne cztery ustawienia. W pierwszych dwóch byłoby one dedykowane do konkretnych setów: istnieje WIRES, który transportuje prąd, i dobrze by było taką funkcję przypisać też Wired'owi. Automatycznie przestawiane do B3 jeśli dodatki nie są włączone.
B3. W tym ustawieniu produkcja prądu byłaby wirtualna. Jej poziom zależałby od dostaw węgla do najbliższej elektrowni oraz/lub tej przypisanej do miasta. Automatyczne przestawienie do B4 jeśli nie ma setów zawierających elektrownie.
B4. Produkcja prądu nie byłaby brana pod uwagę.
C. Przemysł - jego poziom zależałby od wielkości produkcji przedsiębiorstw przypisanych do miasta lub tych w określonym zasięgu. Produkty rolne miałyby obniżone znaczenie, zaś te przetworzone, zwłaszcza podwójnie miałyby odpowiednio wyższe.
D. Handel - zależałby od ilości dostaw towarów, żywności i materiałów budowlanych (ale tylko do sklepów przemysłowych).
E. Budownictwo - zależałoby od ilości dostaw materiałów budowlanych zwłaszcza do spółek budowlanych. Te dostarczane do sklepów miałyby obniżone znaczenie.
4. Miasta nie powinny w ogóle wymierać, albo mieć opcję zamrożenia tej funkcji. Gdyby miały wymierać, najlepiej aby odbywało się to na zasadzie podmiany większego budynku na mniejszy.
5. Skrypt powinien być możliwie jak najbardziej przejrzysty i zrozumiały - dobór odpowiedniego układu, kolorów, stworzenie opisu w oknie opowieści. Przy okazji, jeśli jest to możliwe, dobrze by było dodać "na wierzchu" widok oceny firmy w mieście.
6. Można pomyśleć o dodaniu funkcji podatku - coś podobnego funkcjonuje w zmodyfikowanym skrypcie RCG na serwerze ttdistas.es
7. Okres "rozliczeniowy" powinien być dłuższy niż jeden miesiąc. Te zielone wartości (jedna czerwona) powinny być średnią miesięcznych dostaw z dłuższego okresu np. 3 lub 6 miesięcy, aby pojedyncza kumulacja dostaw lub ich brak w jednym miesiącu nie stanowiły od razu oceny dla całego elementu. Ten okres dobrze gdyby był ustawialny w parametrach np.1-24.
W przypadku Handlu i Budownictwa zamiast okresu rozliczeniowego, ocena mogła by bazować nie na ilościach dostarczonych, ale zmagazynowanych (ustalone byłoby ich zużycie) - tutaj takie rozwiązanie chyba byłoby nawet bardziej adekwatne.
#2
A2 - Liczenie miast jest naprawdę konieczne? Ilość pasażerów w komunikacji miejskiej i międzymiastowej nie wystarczy? Jest to możliwe do zrobienia, ale trochę się martwię o wydajność. Teraz iteruję po każdej stacji w mieście, sprawdzam planowany przez cargodista towar, i w zależności czy towar pochodzi od stacji w tym samym mieście zalicza to do miejskiej albo międzymiastowej.
Żeby liczyć miasta musiałbym jeszcze stacje opakować w obiekty, w każdym zapisać listę miast, i jeszcze w obiekcie miasta przechowywać listę innych połączonych miast. Przeszukiwanie po tych obiektach może być dosyć wolne, szczególnie jak będzie dużo stacji, więc wolałbym tego uniknąć.
#3
Liczenie miast odbywa się w 'Neighbours are important' i z tego co wiem, nie było to trywialne pod względem wydajności.
Niektóre skrypty po prostu pauzują grę, gdy się nie wyrabiają z obliczeniami. Moim zdaniem ilość pasażerów miejscowych (stacje tego samego miasta) i zamiejscowych (z innego miasta) powinna wystarczyć.
Dałbym natomiast inne ograniczenie - aby liczyć również ilość pasażerów wyjeżdżających, mała różnica daje wiekszy bonus.
zapobiegnie to 'wampirowaniu' pasażerów z innych miast (jednokierunkowy transfer z wielu przystanków na stację i spam pociągami miasta rozwijanego).
#4
A2 - Z tym liczeniem miast chodzi przede wszystkim o to, aby uzasadnić tworzenie realistycznych sieci połączeń. Obecnie działanie cargodista kompletnie zniechęca do takiej budowy, bo mi większą sieć się stworzy, tym gorzej się zarabia. Bez tego, proste połączenie miast w pary w większości przypadków będzie rozwiązywało cały problem. Uzasadnione byłoby też włączanie do sieci nie tylko największych miast, ale również tych małych - może nie jest to szczególnie realistyczny powód dla samego rozwoju miast, ale chodzi o to, aby nie tylko budowanie sieci przemysłowych było jakimś wyzwaniem logistycznym, ale też transport pasażerski.
Wydajność rozwiązania, a jeszcze bardziej jego niezawodność, jest w sumie nawet bardzo ważna, ale nie wiem czy aż tak bardzo byłoby to obciążające np. w porównaniu do pathfindera. On działa cały czas, zaś obliczenia dla skryptu byłyby robione raz w miesiącu. Dodatkowo, nie muszą być przecież robione obliczenia dla wszystkich miast jednocześnie. Ostatecznie można by było sobie to darować, ale szkoda by było.
#5
(07-02-2016, 19:47)McZapkie napisał(a): Liczenie miast odbywa się w 'Neighbours are important' i z tego co wiem, nie było to trywialne pod względem wydajności.
Niektóre skrypty po prostu pauzują grę, gdy się nie wyrabiają z obliczeniami. Moim zdaniem ilość pasażerów miejscowych (stacje tego samego miasta) i zamiejscowych (z innego miasta) powinna wystarczyć.
Dałbym natomiast inne ograniczenie - aby liczyć również ilość pasażerów wyjeżdżających, mała różnica daje wiekszy bonus.
zapobiegnie to 'wampirowaniu' pasażerów z innych miast (jednokierunkowy transfer z wielu przystanków na stację i spam pociągami miasta rozwijanego).
Nie sprawdzałem 'Neighbours are important', ale wydaje mi się, że to tylko ustawia bonus w zalezności od odległości pobliskich miast. A tutaj trzeba by było w uproszczeniu (dla każdego miasta):
--utwórz pustą listę odwiedzonych miast
--dla każdej stacji:
----pobierz planowany przez cargodista transport na inne stacje
----dla każdej odczytanej stacji:
------wyszukaj stację w liście stacji miasta, jeśli tak to dodaj to transportu miejscowego
------jeżeli nie, to wyszukaj w liście mapowanie stacji na miasto
------wyszukaj w liście obecnie odwiedzonych miast tego miasta, jak nie ma to dodaj i zwiększ licznik

PS: A zresztą, co ja się będę zastanawiał, zrobię i się okaże Tongue
PS2: Upss, zapomniałem że trzeba też uwzględniać stacje pośrednie, więc trzeba to robić rekurencyjnie. Narazie to liczenie miast chyba sobie odpuszczę.
#6
Jedyne co mogę napisać to... powodzeniaSmile

(Dodałem punkt 7.)
#7
(07-02-2016, 11:09)LaChupacabra napisał(a): A1. Komunikacja miejska - te 49% oznaczałoby, że właśnie taki procent spośród "wyprodukowanych" przez miasto pasażerów i poczty zostało przetransportowanych (liczone razem). Podobnie liczone jak w skrypcie CGL z tym, że tutaj jest to wpływ a nie blokada. Oczekiwany procent transportu byłby ustawialny w parametrach. Im bliżej wskaźnik byłby tej wartości tym większy wpływ na redukcję bezrobocia. Przekroczenie wyznaczonej wartości dalej zmniejszałoby bezrobocie, ale już w coraz mniejszym stopniu.
A2. Komunikacja międzymiastowa - 28 z 327, czyli 8,5% oznaczałoby ilość miast względem ich ogólnej liczby, z którymi dane miasto ma aktywne połączenia (ocena połączenia). Wszystkie niezbędne dane powinny być dostępne, pytanie tylko czy skrypt jest w stanie je odczytać.
A2'. Alternatywne rozwiązanie - jeśli powyższe okazałoby się niemożliwe lub zbyt trudne - aby podział na rodzaje komunikacji miał sens, wymagałoby określenia dla dostarczanych pasażerów/poczty faktu pochodzenia z innego miasta, albo odległości stacji z jakiej przybyli.
B1 i 2. Prąd - Byłyby dostępne cztery ustawienia. W pierwszych dwóch byłoby one dedykowane do konkretnych setów: istnieje WIRES, który transportuje prąd, i dobrze by było taką funkcję przypisać też Wired'owi. Automatycznie przestawiane do B3 jeśli dodatki nie są włączone.
B3. W tym ustawieniu produkcja prądu byłaby wirtualna. Jej poziom zależałby od dostaw węgla do najbliższej elektrowni oraz/lub tej przypisanej do miasta. Automatyczne przestawienie do B4 jeśli nie ma setów zawierających elektrownie.
B4. Produkcja prądu nie byłaby brana pod uwagę.
C. Przemysł - jego poziom zależałby od wielkości produkcji przedsiębiorstw przypisanych do miasta lub tych w określonym zasięgu. Produkty rolne miałyby obniżone znaczenie, zaś te przetworzone, zwłaszcza podwójnie miałyby odpowiednio wyższe.
D. Handel - zależałby od ilości dostaw towarów, żywności i materiałów budowlanych (ale tylko do sklepów przemysłowych).
E. Budownictwo - zależałoby od ilości dostaw materiałów budowlanych zwłaszcza do spółek budowlanych. Te dostarczane do sklepów miałyby obniżone znaczenie.
Konkrety jakieś potrzeba, w szczególności co do górnej granicy parametrów
A1 - ok, można policzyć wyprodukowanych pasażerów i pocztę
A2 - jak już wcześniej mówiłem, nie da się sensownie liczyć miast, więc jest tylko liczba pasażerów którzy przyjechali z innego miasta. ile ich musi być?
B - ok, nie ma problemu
C - można odczytać wielkość produkcji, ale jaką przyjąć wartość maksymalną?
D - to samo, można odczytać dostawy, ale jaką przyjąć wartość maksymalną?
E - to samo
#8
(24-02-2016, 20:11)Milek7 napisał(a): Konkrety jakieś potrzeba, w szczególności co do górnej granicy parametrów
A1 - ok, można policzyć wyprodukowanych pasażerów i pocztę
A2 - jak już wcześniej mówiłem, nie da się sensownie liczyć miast, więc jest tylko liczba pasażerów którzy przyjechali z innego miasta. ile ich musi być?
B - ok, nie ma problemu
C - można odczytać wielkość produkcji, ale jaką przyjąć wartość maksymalną?
D - to samo, można odczytać dostawy, ale jaką przyjąć wartość maksymalną?
E - to samo
No to mnie trochę zmartwiłeś, bo to w sumie było jedno ze sztandarowych założeń tego tego skryptuSad Nie wiem czy naprawdę nie da się tego jakoś obliczyć. Na przykład w panelu stacji jest informacja o źródle skąd przybywają np. pasażerowie, więc może jednak byłaby na to jakaś szansa. Co prawda są to stacje, ale te jak pisałeś da się, lub nawet są przypisane do konkretnych miast? No ale też chyba dość ważne, aby nie było to zbyt zawiłe.
Te ilości pasażerów, no cóż, średnio mi się to podoba, ale jeśli nie będzie możliwe liczenie miast, w ostateczności też może być.
Tutaj jednak rodzi się pytanie: jaki rodzaj rozwoju byś zastosował? No i tak właściwie to powinienem zapytać jak to w ogóle działa?? Mondruję się tutaj, a tak naprawdę to tej podstawy nawet nie znam. Chodzi o konkrety, jak to jest liczone. Na przykład w przypadku tego "liniowego" rozwoju, czy te np. co 16 dni oznacza, że co taki czas dodawany jest nowy element miasta, czy to tylko informacja poglądowa?? Ogólnie myślałem o czymś takim, aby spełnienie wszystkich warunków oznaczało maksymalne tempo wzrostu o ustalony procent populacji co miesiąc - im większe miasta tym ten maksymalny procent byłby mniejszy. Mniejsza o założenia, napisz może lepiej jak to działa, lub może działać. Bez tego trochę ciężko jest mi napisać jakieś konkrety.

[Obrazek: 533_r_d_o.png]
#9
Jeszcze się dziś przyglądnę temu liczeniu miast, ale wątpię że coś wymyślę.
Co do sposobu rozwoju:
a) Można użyć wbudowanego w grę "Miasto rośnie co x dni". wtedy co taki okres podejmowana jest próba dobudowy czegoś do miasta.
b) Można tamten parametr ustawić na 0, a wzrost miasta wymuszać ręcznie funkcją GSTown.ExpandTown dobudowywującą do miasta określoną ilość domów.
Ale mniejsza z tym, wystarczy żeby algorytm obliczył o ile % miesięcznie miasto ma rosnąć.

Teraz mam po prostu liczby, ile przetransportowano pasażerów komunikacją miejską, międzymiastową, ile przemysł wytwarza towarów, ile dostarcza się do sklepów i ile do spółek budowlanych. Żeby obliczyć % spełnienia warunku, trzeba przyjąć jakieś sensowne górne wartości. Na tym kolażu wpisałeś np. że do przemysłu potrzeba 563, ale jak tą wartość obliczyć?

Jeszcze jest problem związany z pokazywaniem danych. Na kolażu pokazałeś 36 wartości (9 linijek po: kolor, procent, obecna wartość, wartość wymagana). Nie da się wyświetlić w zwykłym openttd więcej niż 20 wartości, do tego potrzeba by było spatchowanej gry.
#10
Myślę, że z tej funkcji GSTown.ExpandTown byli by ludzie. Łatwiej chyba będzie przełożyć ten określony procent na rzeczywisty wzrost(?). Jest tutaj jednak kilka "ale". Na pewno korzysta z niej Real Growth i City Controler, ale tam też pokazywany jest wzrost co ileś dni - tak by było ok, choć najlepiej by było zastąpić tą linię samą informacją o procentowym wzroście, no ale nie wiem czy to w ogóle możliwe bez zmiany w grze. Nie jestem pewien, ale RCG i BCG chyba też na tym się opierają. Przy czym BCG w panelu miasta ciągle pokazuje "Miasto nie rośnie" - to jest dość mylące. Tam jest też taki problem, że budynki są dodawane, ale już nie są podmieniane na inne/większe. Być może właśnie dlatego w tych pozostałych skryptach miasta "wymierają", aby zrobić miejsce dla większych budynków.
Pytanie czy funkcja ta przy dodawaniu/podmianie budynku uwzględnia jego wielkość (liczbę mieszkańców)? Pomyślałem, że ten procentowy wzrost mógłby określać rzeczywisty wzrost zamiast informować o nim już po fakcie co początkowo zakładałem. Chodzi o to, aby procent ten dotyczył populacji a nie samej liczby dodanych/zmienionych budynków/elementów.

Co do konkretnych danych będę musiał jeszcze raz to przemyśleć. Z tymi 20 wartościami będzie trochę problem, bo wychodzi na to, że z czegoś trzeba będzie zrezygnować. No ale ok, coś się wymyśli. Nie wiem czy da radę, ale postaram się jeszcze jutro to wszystko opisać. Pytanie tylko, czy dwa różne kolory w jednej linii to dwie wartości czy jedna (np. linia z "bezrobociem", "wzrostem miasta" albo z "przemysłem")?
#11
Przepraszam, że się "wtrancam" ale obecna/wymagana wartość nieco zaciemnia ogląd zbyt dużą liczbą cyferek.
Można zrezygnować, a nawet trzeba - wtedy zmieści się w 20.
Może występować jedynie procent i gdzieniegdzie kolor.
Bezrobocie oraz Wzrost miasta mają po dwie wartości (% i jego kolor)
Przemysł ma 4 wartości (liczba obecna + jej kolor i liczba wymagana + jej kolor)
#12
@Emisja
Bardzo dobrze, że się wtrancaszSmile Takie i inne uwagi jak najbardziej są przydatne. Chodzi też o to, aby ten skrypt był jak najbardziej czytelny i zrozumiały nie tylko dla starych wyjadaczy i tych którzy go tworzyli.
Co do tych ciemnych liczb, miały być one taką dodatkową informacją, aby wiadomo było z czego w ogóle wynika ta procentowa ocena. Dodatkowo myślałem, aby stworzyć opis zależności w rozwoju miast, co oznaczają poszczególne liczby i od czego zależą w oknie opowieści (ikona książki w interface'ie), tak jak to jest w skrypcie Renewed City Growth. Bez tego dla części graczy może to być mniej zrozumiałe. No ale nie wiem, może rzeczywiście nie jest to aż tak bardzo potrzebne. Wieczorem postaram się wrzucić zaktualizowaną wersję założeń z bardziej szczegółowym ich opisem.
#13
Jednak zajęło mi to trochę więcej czasu... Musiałem jeszcze raz przemyśleć działanie i wpływ wszystkich elementów. Jest tego trochę. Najbardziej złożone są komunikacja i energia elektryczna. Nie wiem czy nie trzeba będzie tego jakoś uprościć.
Ogólnie wygląda to tak, że skrypt składa się z sześciu bazowych elementów, którymi są: Przemysł, Handel, Budownictwo, Komunikacja miejska, Komunikacja międzymiastowa i Energia elektryczna, oraz z części głównej (Bezrobocie), która łączy wyniki z nich uzyskane i na ich podstawie oblicza tempo wzrostu miast. Każdy z tych elementów domyślnie może dawać taką samą liczbę punktów. Dodatkowo prawie każdy element ma możliwość modyfikacji jego znaczenia. Te wszystkie wartości zsumowane i pomnożone modyfikatorami, a następnie podzielone przez również zsumowaną i pomnożoną wartość wymaganą dają wynik określający wspomniane tempo. Mam nadzieję, że w miarę czytelnie to wszystko niżej rozpisałem. Wszystkich wzorów nie napisałem, z resztą nie wiem jak one mogą być zapisane, ale myślę, że są wszystkie potrzebne informacje. Smiley43  Jakby czegoś brakowało, to dopiszę.

******************************************************************************************************************************
Przemysł - produkcja przypisanych do miasta przedsiębiorstw
Wymagane: 200 jednostek / 1000 mieszkańców (dla poziomu trudności 100%)
Do wartości wymaganej po roku gry jednorazowo dodawana by była aktualna wartość produkcji - inaczej wszystkie miasta będą same rosły Edit: można, ale to nie jest konieczne.
Produkty przetworzone liczone są x3 Edit. x2 da lepszy balans
Produkty rolne x1/2
Produkty wydobywcze x1
Dodatkowo można dać bonus dla towarów przetransportowanych (wynosiłby ten sam procent)

Jeśli produkcja wynosi 100% wymaganej - dodane zostaje do oceny bezrobocia 100 punktów (wartość "P")
Nadwyżka powyżej 100% jest liczona jako pierwiastek x3 - np. jeśli produkcja wynosi 500/100 czyli 500%, to do oceny bezrobocia dodane zostanie 160 punktów - chodzi o to, aby miasta mogły rozwijać się na jednej ale nie jedynej gałęzi gospodarki.
Wartość produkcji powinna być średnią z ostatnich 3 miesięcy.
Ustawienia:
W parametrach powinna być opcja modyfikująca znaczenie tego elementu - może być procentowo lub słownie z ustalonym procentem (podanym w nawiasie)
Jeśli procentowo, wartość domyślna powinna wynosić 100%. Zakres 0-200% (ustawienie stanowić będzie wartość ZP dla dalszych obliczeń). Jeśli ustawione zostanie 0% ten element nie będzie wyświetlany, ale nie będzie brany pod uwagę. Jeśli ustawione zostanie 200%, to produkcja na poziomie 100% da 200 punktów (wartość P)
Jeśli słownie, powinno być przynajmniej pięć możliwości wyboru znaczenia: Brak (0%), Małe (50%), Normalne (100%), Duże (150%), Bardzo duże (200%)

Handel - wielkość dostawy określonych towarów do miasta lub miejskich przedsiębiorstw
W parametrach skryptu powinna być opcja włączająca liczenie dostaw tylko do przedsiębiorstw miejskich (tak jest w Real Growth). Chodzi tu m.in. o możliwość dodania setu przedsiębiorstw z ograniczoną akceptacją oraz możliwość określenia miejsc gdzie dokładniej mają być dostarczane.
Wymagane: 100 jednostek / 1000 mieszkańców
Dostawy towarów oraz paliwa byłyby liczone x1
Dostawy żywności x2
Dostawy poczty x1/4
Dostawy materiałów budowlanych x1
J.w. Wartość dostaw powinna być średnią z ostatnich 3 miesięcy.

J.w.
Jeśli dostawy towarów wynoszą 100% wymaganych - dodane zostaje do oceny bezrobocia 100 punktów (wartość H)
Nadwyżka powyżej 100% jest liczona jako pierwiastek x3 - np. jeśli dostawy wynoszą 500/100 czyli 500%, to do oceny bezrobocia dodane zostanie 160 punktów
Ustawienia znaczenia jak dla przemysłu (wartość ZH)

Budownictwo - dostawy materiałów budowlanych (np. cegły, cement, stal, szkło dla ECS).
Wymagane: 50 jednostek / 1000 mieszkańców
Liczone byłyby konkretne towary przypisane do danego setu dostarczane do konkretnych przedsiębiorstw.
Jeśli nie byłoby dostępnych przypisanych ustawieniu towarów, element ten nie byłby ani liczony ani pokazywany - tak działa skrypt RCG, gdzie można wybrać dowolne ustawienie np. FIRS dla dowolnego setu przedsiębiorstw, ale przykładowo dla standardowego przemysłu nigdy nie wyświetli się wymóg dostaw produktów przetworzonych.

Obliczenia i ustawienia j.w. - 100% = 100 punktów (wartość B oraz ZB dla dalszych obliczeń)

******************************************************************************************************************************
Komunikacja

Miejska - ilość przetransportowanych pasażerów oraz poczty "wyprodukowanych" przez miasto.
Wersja 1 (rozwinięta)
Tutaj wynik byłby ograniczony, jeśli więcej niż 50% trafiało na stacje w innym mieście.
Np. jeśli wszyscy pasażerowie i poczta (powiedzmy 70%) są transportowani wyłącznie do innego miasta, ocena transportu miejskiego wyniesie 0%. Natomiast jeśli tylko 20% z nich trafi na inne miejskie stacje (może być tylko przesiadka) ocena wyniesie 70% x 20/50 = 28%. Jeśli będzie to więcej niż 50% ocena nie uległaby zmianie i wynosiła 70%.
Tak jak wyżej 100% = 100 punktów (wartości C i ZC) - ten element przy domyślnych ustawieniach miałby najmniejsze znaczenie dla rozwoju - to by było zbyt proste.
Pokazywany wynik: Uzyskany wynik na poziomie 80% pokazywany byłby jako 100%, czyli powinien być mnożony x 1,25, ale nie powinien wynosić więcej niż 100. To ze względu na to, że prawie niemożliwe jest przetransportowanie wyższego odsetka pasażerów i poczty. Wynika to głównie z oceny stacji, która zwykle to uniemożliwia.

Wersja 2 (uproszczona)
Tutaj wprost procent określałby wyłącznie ilość przetransportowanych pasażerów i poczty "wyprodukowanych" przez miasto. Nazywanie tego komunikacją miejską nie będzie w jednak tym wypadku zbyt trafne, bo równie dobrze ci wszyscy pasażerowie / poczta mogą być wywożeni z miasta.
100% = 100 punktów.

Wersja 3 - post nr 15

Międzymiastowa
Wersja 1 - ilość miast, z którymi istnieje obsługiwane połączenie względem łącznej liczby miast.
Z tego co widać w panelu stacji, możliwe jest określenie celu transportu, którym są stacje (te są przypisane do miast).
Dodatkowo, czego nie widać, każde połączenie jest osobno oceniane, a więc liczone byłyby tylko te połączenia, których średnia ocena jest co najmniej marna.
Pytanie tylko czy da się wydobyć te informacje i czy obliczenia nie będą powodowały lagów.
Ocena 100% będzie dotyczyła komunikacji łączącej 20 miejscowości (ustawialne w parametrach). Tutaj inaczej niż w reszcie punktów wartość powyżej 100% byłaby jedynie dzielona przez 3, ale maksymalna ilość punktów byłaby ograniczona do 300 (przy znaczeniu tej komunikacji na poziomie 100%). Czyli połączenie np. 100 miast da 233 punkty (wartość I).
Ilość przetransportowanych pasażerów/poczty nie miała by żadnego znaczenia - łączenie dużej ilości miast i zapewnianie połączeniom odpowiedniej oceny jest znacznie większym wyzwaniem. Co najważniejsze taki sposób oceny nadaje sens Cargodist'owi.
Ustawienia:
Znaczenia - jak dla poprzednich elementów (wartość ZI)
Ilości połączonych miast dla oceny 100%. Zakres: 0-1000, domyślnie: 20

Wersja 2 - ilość dostarczonych do miasta pasażerów i poczty z innych miast oraz tych zabranych z miasta.
Na ocenę 100% składałoby się w równych proporcjach wypełnienie dwóch warunków:
1. Dostarczenie do miasta 1/2 tego co ono "produkuje" - 50% oceny
2. Przetransportowanie poza miasto co najmniej 1/2 jego pasażerów+poczty - 50% oceny
Ocena 100% byłaby maksymalną wartością dającą 100 punktów (wartość I oraz ZI)

Wersja 3 - post nr 15

******************************************************************************************************************************
Energia elektryczna
Tutaj obliczenia powinny być zależne od wyboru podstawowego ustawienia dla tego elementu:
1. Nie uwzględniaj elektryczności - brak wpływu, no i obliczeń
2. Tylko produkcja energii elektrycznej - dostawy węgla do elektrowni byłyby odnotowywane jako produkcja i dostawa elektryczności do miast przypisanych do elektrowni
3. Produkcja i transport energii elektrycznej (WIRES.grf) - wyprodukowany prąd trzeba dostarczyć do trafostacji, aby dostawa była odnotowana
4. Wired? - w tej chwili nie ma takiej funkcji, więc na razie odpada.
Znaczenie:
Same dostawy/produkcja prądu nie rozwijałaby miasta. Jednak brak dostaw ograniczałby wpływ przemysłu, handlu oraz budownictwa na rozwój.
Zapotrzebowanie (ogólnie):
Do określonej wielkości miasta dostawy nie byłyby potrzebne. Wielkość ta powinna być ustawialna w parametrach 1-1 000 000, domyślnie 10 000.
Do wartości domyślnej poziom dostaw energii wynosiłby 100%. Od 10 000 wzwyż dostawy własne stopniowo by malały - wynosiłyby 70%.
Tz. miasto z 20k mieszkańców miałoby zaopatrzenie na poziomie 85%, z 30k mieszkańców: 80%, z 40k mieszkańców: 77% itd.
Rozdział energii:
Tutaj rodzi się pewien istotny problem - przypisywanie elektrowni / trafostacji do miast. Co zrobić gdy jest 200 miast i tylko 20 elektrowni? Produkcja  czy dostarczanie prądu dla każdego z miast z osobna była by zbyt zajmująca, a to się kłuci z podstawowym założeniem tego skryptu. Wydaje mi się, że najlepiej by było uzależnić procent dostaw od odległości miasta od źródła prądu - gdy odległość ta wynosi 50% długości + szerokości mapy, wielkość dostaw otrzymuje 50 punktów, jeśli 80% - 20. (tak byłoby przypisywane każde miasto do każdej elektrowni / trafostacji). Następnie przydział prądu wynosiłby 100/50 dzielone przez sumę ocen każdego z miast. Dla przykładu: Jeśli byłaby jedna elektrownia i cztery miasta z ocenami 5, 20, 30, 80, to do pierwszego trafiałoby 5/135 produkcji / dostaw, do drugiego 20/135, trzeciego 30/135 i czwartego 80/135. Pytanie czy takie przypisanie jest możliwe i czy nie byłoby zbyt zajmujące jeśli chodzi o kodowanie jak i obliczenia w trakcie gry. Tutaj dobrze by było też ograniczyć maksymalną liczbę elektrowni / trafostacji na mapie, aby ograniczyć ilość obliczeń - to powinno być możliwe, podobne możliwości mają co najmniej trzy skrypty m.in. City Buildier oraz Industy Constructor. Znacznie prostszym rozwiązaniem byłoby liczenie produkcji i zapotrzebowania globalnie, ale to już nie będzie to i nie wiem czy byłby wtedy w ogóle sens dodawania elektryczności.
Można jednak dać w parametrach możliwość wyboru rozdziału dostaw - Dostawy energii elektrycznej do miast: 1. Do każdego miasta osobno, 2. Rozdział w zależności od dystansu (domyślnie) 3. Globalnie - wszystkie miasta liczone jako jeden odbiorca
W przypadku pierwszego ustawienia, dobrze by było dać też opcję automatycznej budowy elektrowni / trafostacji dla miasta, które osiągnie domyślną wielkość (10 000). Tz. tylko z tym ustawieniem by ona działała.
Zapotrzebowanie (wartości):
*Dla ustawienia drugiego - tylko produkcja.
Domyślnie miasta wymagałoby dostawy 20 ton węgla /20kl ropy na każde 1000 mieszkańców.
Poza mieszkańcami, również przemysł, handel oraz budownictwo wymagają dostaw prądu: każda 1 jednostka zwiększa zapotrzebowanie o 0,1% czyli też wymagane jest 10 ton na każde 1000 jednostek produkcji/ handlu/ budownictwa.
Ponieważ warunki w grze, ilość miast i wielkości produkcji bywają różne, wartości wymagane powinny być ustawialne w parametrach (1-1000%)
*Dla ustawienia trzeciego - produkcja i transport (WIRES)
Tutaj dość mocno ograniczona jest produkcja prądu w elektrowniach - mogą przetworzyć na prąd maksymalnie 1000 ton węgla co daje 18 000 kWh na elektrownie. Przyjąłbym, że 100k miasto wymaga zaopatrzenia dwóch elektrowni. Czyli wymagane dostawy wynosiłyby 360kWh na 1000 mieszkańców. Tak jak wyżej przemysł, handel i budownictwo zwiększają zapotrzebowanie.
100% i więcej zaopatrzenia w dostawy prądu dawałoby 100 pkt. (Wartości E i ZE) Tutaj nie byłoby modyfikacji znaczenia.
Ustawienia (podsumowanie):
1. Energia elektryczna: Nie uwzględniaj elektryczności / Tylko produkcja energii elektrycznej (domyślne) / Produkcja i transport energii elektrycznej (WIRES.grf)
2. Wielkość miast wymagających dostaw prądu: 1-1 000 000; domyślnie 10 000
3. Rozdział energii elektrycznej: Do każdego miasta osobno / Rozdział w zależności od dystansu (domyślnie) / Globalnie - wszystkie miasta liczone jako jeden odbiorca
4. Wybuduj elektrownie / trafostację dla każdego miasta wymagającego dostaw prądu: Tak / Nie (domyślnie)
5. Wymagane dostawy prądu: 1-1000%; domyślnie 100% (ustawienie zmieniające wymagane dostawy 20t węgla / 360kWh prądu)

******************************************************************************************************************************
******************************************************************************************************************************

Bezrobocie / Wzrost miasta
No i w końcu sedno sprawy. Wszystkie powyższe elementy składają się na poziom bezrobocia w mieście, ten z kolei jest ściśle powiązany z tempem wzrostu miasta. Ze względu na ograniczenie ilości danych trzeba by było wybrać tylko jedną z danych. Mi bardziej odpowiada stopa bezrobocia.
Obliczenia:

Dane:
P - wartość produkcji przedsiębiorstw (0-n)
H - wartość dostaw dóbr (0-n)
B - wartość dostaw materiałów budowlanych (0-n)
C - wartość komunikacji miejskiej (0-100)
I - wartość komunikacji międzymiastowej (0-300)
E - wartość dostaw energii (70-100)

ZP - znaczenie produkcji przedsiębiorstw (0-200)
ZH - znaczenie dostaw dóbr (0-200)
ZB - znaczenie dostaw materiałów budowlanych (0-200)
ZC - znaczenie komunikacji miejskiej (0-200)
ZI - znaczenie komunikacji międzymiastowej (0-200)

"Wzór":
Wartość wymagana dla maksymalnego tempa wzrostu miasta / minimalnego bezrobocia:
ZP+ZH+ZB+ZC+ZI x 100 = B

Wartość uzyskana:
(PxZP + HxZH + BxZB) x E/100 + CxZC + IxZI = A

Wartość tempa wzrostu miasta / bezrobocia
A/B = C

Jeśli C wynosi 1 lub więcej, bezrobocie wynosi 0% / miasto rozwija się w maksymalnym tempie (wartość S)
Jeśli C równa się 0, bezrobocie wynosi 40%
Jeśli C wynosi 0,25 (wartość N) lub mniej, miasto nie rośnie

Parametry skryptu decydujące o szybkości wzrostu miast:
Maksymalne tempo rozwoju miast (S) - domyślnie co 1 dzień
Minimalne tempo rozwoju (M) - domyślnie co 200 dni
Poziom bezrobocia, przy którym miasto przestaje rosnąć (N) - domyślnie 0,25 (w ustawieniach pokazane jako 30% (40% x (1-N)) )

Nowe grafiki, pełną listę ważnych ustawień oraz listę kolorów postaram się jutro dodać. Dzisiaj już nie da rady. Smiley62
#14
Widok okna z ustawieniami parametrów skryptu i niżej (chyba) pełny opis do tego.

[Obrazek: 963NWD_ustawienia_skryptu.png]

xxxxxxxxxxxxxxxxxx: Używane sety przedsiębiorstw (lub Ustawienia przedsiębiorstw): - takie elementy nie dawałyby żadnego wyboru ani funkcji, one służyłyby jedynie jako rozdzielniki dla grup ustawień poprawiające czytelność i zrozumienie.

Główny set przedsiębiorstw (lista) - do ustawień przypisane by były ID ładunków i przedsiębiorstw branych pod uwagę przy obliczeniach. Nie jestem jednak tutaj do końca pewien czy jest to niezbędne. Dla przykładu sety pojazdów/ pociągów np. PKP albo Polroad dla każdego z przemysłów ma zawsze odpowiednio dobrane ładunki. W każdym bądź razie niżej chyba pełna lista obecnie dostępnych setów:
-Standard: klimat umiarkowany
-Standard: klimat arktyczny
-Standard: klimat tropikalny
-Standard: klimat zabawkowy
-FIRS: ekonomia Firs
-FIRS: klimat umiarkowany
-FIRS: klimat arktyczny
-FIRS: klimat tropikalny
-FIRS: jądro ciemności
-ECS
-Auzind
-Manpower
-Manual Industries
-Open GFX+
-Open GFX Mars
-Pikka's Basic Industries
-SPI 1.1
-Wasteland
-YETI
Jeśli trzeba będzie przypisać odpowiednie ID towarów i przedsiębiorstw do każdego z ustawień, mogę to zrobić, tylko musiałbym wiedzieć gdzie to jest zapisane. Kiedyś trafiłem na stronę z tymi danymi, ale już nie pamiętam gdzie to było, no i nie wiem czy były tam opisy do wszystkich setów.

Oddzielnie byłyby włączane dodatki, które dodają przedsiębiorstwa mogące działać razem z powyższymi głównymi setami. Oczywiście nie ma sensu ich dodawać jeśli nie dodają innych ładunków lub przedsiębiorstw o odmiennej identyfikacji.
ECSext: tak / NIE
Obóz drwali: tak / NIE
Pre-Industrial era houses: tak / NIE
SUM: tak / NIE
WIRES: tak / NIE

xxxxxxxxxxxxxxxxxx: Tempo rozwoju miast i poziom trudności:
Maksymalny poziom bezrobocia: 40% (niezmienne - informacja ułatwia ustawienie reszty)
Poziom bezrobocia, poniżej którego miasto rośnie: 30% (1-40%)
Minimalne tempo rozwoju miast (co ile dni): 200 (1-10000)
Maksymalne tempo rozwoju miast (co ile dni): 1 (1-10000)
Poziom trudności: 100% (1-1000%) - ogólny mnożnik dla wszystkich wymaganych dostaw
Z powyższymi ustawieniami mogłoby być dość trudne wyliczenie właściwego wzrostu miast i pokazywanego poziomu bezrobocia. Dlatego lepiej byłoby zastosować takie:
Minimalna ocena dostaw, powyżej której miasto rośnie: 10% (0-50%) - wartość C=0,1 (0-0,5)
Ocena dostaw, przy której miasto rozwijać się będzie w maksymalnym tempie: 100% (50-100) - wartość C = 1 (0,5-1)

xxxxxxxxxxxxxxxxxx: Ustawienia wpływu na rozwój miast:
Przemysł: TAK / nie (jeśli nie, wpływ wynosi 0%)
Wpływ przemysłu: 100% (1-200%)
Oczekiwana wielkość produkcji (na 1000 mieszkańców): 100 (1-1000)
Znaczenie produkcji rolniczej: 0,5 (0,1 - 5,0)
Znaczenie produkcji wydobywczej: 1,0 (0,1 - 5,0)
Znaczenie produkcji przetwórczej: 2,0 (0,1 - 5,0)

Handel: TAK / nie (jeśli nie, wpływ wynosi 0%)
Wpływ handlu: 100% (1-200%)
Oczekiwana wielkość dostaw dóbr (na 1000 mieszkańców): 40 (1-1000)
Znaczenie dostaw towarów: 1,0 (0,1 - 5,0) - alkohol i paliwo zaliczane by były do towarów
Znaczenie dostaw żywności: 2,0 (0,1 - 5,0) - w tym woda
Znaczenie dostaw poczty: 0,2 (0,1 - 5,0)
Znaczenie dostaw materiałów budowlanych: 0,5 (0,1 - 5,0)
Licz tylko ładunki dostarczone do miejskich przedsiębiorstw (np. sklepy): forma wyboru z list jest celowa
-Tak (domyślnie)
-Nie

Budownictwo: TAK / nie (jeśli nie, wpływ wynosi 0%; tak samo gdy set przedsiębiorstw nie wytwarza materiałów budowlanych)
Wpływ budownictwa: 100% (1-200%)
Oczekiwana wielkość dostaw materiałów budowlanych (na 1000 mieszkańców): 20 (1-1000)

Komunikacja miejska: TAK / nie
Wpływ komunikacji miejskiej: 100% (1-200%)

Komunikacja międzymiastowa: TAK / nie
Wpływ komunikacji międzymiastowej: 100% (1-200%)
Oczekiwana liczba połączonych miast (1-1000 lub wszystkie): 20 (1-1000; 1001 = wszystkie)
Połączenie jest liczone jeśli jego ocena wynosi co najmniej: 30% (1-100%)

Energia elektryczna: TAK / nie
Dostarczanie prądu:
-Tylko produkcja energii elektrycznej
-Produkcja i transport energii elektrycznej (WIRES.grf)
Rozdział energii elektrycznej:
-Do każdego miasta osobno
-Rozdział w zależności od dystansu (domyślnie)
-Globalnie - wszystkie miasta liczone jako jeden odbiorca
Wybuduj elektrownie / trafostację dla każdego miasta wymagającego dostaw prądu:
-Tak
-Nie (domyślnie)
Wymagane dostawy węgla do elektrowni lub prądu (domyślnie 20t / 360kWh na 1000 mieszkańców): 100% (1-1000%)
Dostawy własne małych miast: 90% (0-100%)
Dostawy własne dużych miast (powyżej określonej populacji): 70% (0-100%)
Populacja dużych miast: 10 000 (1-1 000 000)

xxxxxxxxxxxxxxxxxx: Podatki:
Najprawdopodobniej możliwe jest dodanie takiej możliwości poprzez skrypt. Podobnie działa zmodyfikowany RCG na serwerach ttdistas.es, ale też np. CashDrainGS
Podatek, podobnie jak to działa w pewnym patchu, co rok (np. w lutym) zabierałby z konta firmy określony procent jego stanu. Przy czym tutaj zamiast okresu nieopodatkowanego byłaby dodana kwota wolna od podatku, gdzie dopiero od nadwyżki od tej kwoty pobierany byłby podatek. Można też dać podatek od dochodu naliczany np. co kwartał. Oczywiście przy naliczaniu podatku powinna pojawiać się odpowiednia informacja. Po co one w ogóle?

Włącz podatki: TAK / nie
Stan posiadania wolny od podatku (funty): 1 000 000 (0 - 1 000 000 000)
Podatek od posiadania: 5% (0-100%)
Dochód kwartalny wolny od podatku (funty): 100 000 (0 - 1 000 000 000)
Podatek od dochodu: 10% (0-100%)

xxxxxxxxxxxxxxxxxx: Subsydia:
To również jest możliwe, choć nie jestem na 100% pewien czy w takiej formie. Miasta dodatkowo płaciłyby za dostawę brakujących towarów, bądź usługi transportowe - im towar bardziej deficytowy, tym więcej. Nie wiem czy skrypt może zmieniać stawki za transport. Jeśli nie, dobrze by było wtedy stworzyć dodatek, który by to umożliwiał. Przy mocno obniżonych stawkach, gra diametralnie zmieniłaby swoje oblicze. Firmy zaczęły by się specjalizować w danym transporcie, bo to by się zaczęło opłacać. Nikt by się na siłę nie pchał w pasażerkę, bo ta bardzo szybko wyczerpałaby dofinansowanie. Tak samo byłoby z dostawami towarów - po prostu opłacało by się dostarczanie ich do wielu miast a nie upychanie biliozyliardów haksaton towarów do jednej niewielkiej mieściny, tylko dlatego... bo jest daleko. Tutaj często irytujący i quasi-realistyczny cargodist - zwłaszcza towarowy - straciłby sens istnienia. Zastąpiłaby go logiczna zasada popytu i podaży.

Dodatkowe dofinansowanie transportu towarów deficytowych: TAK / nie
Mnożnik wielkości dofinansowania: 1,0 (0,1 - 10)
Za dostawę surowców do przedsiębiorstw: 100 (0-10 000) - liczone w funtach za dostarczenie jednej jednostki ładunku (węgiel, ruda żelaza, ropa, zboże itp.)
Za dostawę przetworzonych surowców do przedsiębiorstw: 200 (0-10 000) - dostawy m.in. stali, chemikaliów, szkła, maszyn itp.
Za dostawę dóbr do miast: 300 (0-10 000) - w tym paliwa oraz alkoholu
Za dostawę żywności do miast: 500 (0-10 000)
Za dostawę prądu / węgla do elektrowni: 100 (0-10 000)
Za obsługę transportu miejskiego: 10 (0-10 000) - liczone za jednego przetransportowanego pasażera/pocztę z jednej stacji miejskiej na drugą
Za obsługę transportu międzymiastowego: 50 (0-10 000) - j.w. ale ze stacji innego miasta.
Dofinansowanie wynosi 0, jeśli wymagane dostawy są większe niż: 100% (0-100%)
Redukcja bazowych stawek za transport: -70% (0-100%)
#15
Heh... koncepcja ewoluuje, więc jeszcze trochę namieszam i pokomplikuję, aby zbyt łatwo nie było.Wink
1. Można użyć jeszcze innego i chyba prostszego sposobu liczenia oceny dla komunikacji miejskiej i międzymiastowej, gdyby te wcześniejsze okazały się zbyt problematyczne.
Otóż:
Komunikacja miejska (rozwinięcie pomysłu Milka)
miejskie stacje > miejskie stacje
Liczy się liczba pasażerów i poczty dostarczonych lub przeładowanych (liczone x0,5) na stacje należące do miasta zabranych z innych miejskich stacji bez względu na pochodzenie.
Dostawy dla oceny 100% wynosiłyby również 100% tego co produkuje miasto. Czyli dla Wrocławia z kolażu byłoby to 4345. Ocena wyższa byłaby możliwa, ale wyższa wartość punktów byłaby liczona tak jak dla przemysłu, handlu i budownictwa, czyli nadwyżka ponad 100 byłaby pierwiastkowana a następnie mnożona x3. Z tego samego powodu, aby nie można było osiągnąć pełnego tempa rozwoju tylko jednym elementem. Tutaj też byłoby tylko jedno ustawienie.

Komunikacja międzymiastowa (bez liczenia połączonych miast)
stacje poza miastem > miejskie stacje
Liczba dostarczonych lub przeładowanych (liczone x0,5) na stacje miasta pasażerów i poczty pochodzących ze stacji do niego nienależących. W domyślnym ustawieniu oczekiwane dostawy wynosiłyby 20% wielkości produkcji samego miasta, czyli dla Wrocławia z populacją nieco ponad 11k byłoby to 869. Takie dostawy dawały by ocenę 100% i 100 punktów dla dalszych obliczeń. Dostarczenie większych ilości tak jak w poprzednim przypadku podnosiłoby tą ocenę w ograniczonym stopniu. Czyli np. jeśli dostarczone zostałoby 10 000 pasażerów i poczty, co stanowiłoby 1150% wartości oczekiwanej, ocena wyniosłaby 197% co też dawałoby 197 punktów.
Tutaj ustawialne byłoby oczywiście znaczenie oraz "Oczekiwany transport pasażerów i poczty między miastami" - domyślnie 20% z zakresu 1-200%
Jeśli dałoby radę w prosty sposób liczyć pasażerów i pocztę wywożonych z miasta na inne stacje, to też dobrze gdyby byli brani pod uwagę. Wtedy domyślna wartość mogłaby wynosić 30%.

Jeszcze prościej:
Komunikacja (jako jeden element)
Liczony byłby procent przetransportowanych pasażerów i poczty - tak jak w skrypcie CC tyle, że liczone razem: jaki procent tyle punktów
Dodatkowo: łączna liczba dostarczonych pasażerów i poczty: Oczekiwane dostawy to domyślnie 10% populacji. Zapewnienie ich daje dodatkowe 100 punktów, wyższe wartości liczone jak w dla innych elementów. Ustawiale: wpływ i oczekiwana wielkość dostaw.
Jako jeden element z tego względu, że takiego liczenia nie da się już sensownie podzielić i nazwać komunikacją miejską i międzymiastową. Ewentualnie można przedstawić jako "Transport pasażerów i poczty miasta: procent" i "Transport pasażerów i poczty łącznie: aktualna / oczekiwana".

2. Wprowadziłem kilka zmian w szczegółowym opisie założeń oraz ustawień - są zaznaczone kolorem.
Najistotniejsze są w sposobie ustawień tempa wzrostu. Szukałem wzoru do obliczeń tempa wzrostu i wskaźnika poziomu bezrobocia z uzyskanego wyniku dostaw (wartość C: 0-1), no i nieco się przejechałem na tej koncepcji ustawień - uzyskanie odpowiednich wyników byłoby zbyt skomplikowane, przynajmniej dla mnie. Niżej umieściłem wykres zależności co powinny dawać odpowiednie dostawy.
Wskaźnik bezrobocia jest liniowy więc jego uzyskanie nie powinno stanowić problemu. Trochę gorzej jest z wartością tempa rozwoju miasta - na wykresie jest mocno degresywna. Chodzi o to, aby dostawy w wysokości 50%, co i tak nie jest bardzo proste, nie oznaczały wzrostu w tempie zaledwie co 100 dni. Wg tego wykresu dawałyby wzrost co 22 dni. Wiem, że taką krzywą da się zapisać równaniem, ale nic mi teraz nie przychodzi do głowy. W ustawieniach nie byłoby wyboru poziomu bezrobocia, powyżej którego miasta by nie rosły - ten byłby stały (30%) tak jak maksymalny (40%). Zmienne pozostałyby minimalne i maksymalne tempo wzrostu. Istotnym w takim wypadku byłoby ustawienie minimalnych dostaw, powyżej których miasto rośnie - domyślnie 10% (z zakresu 0-50) czyli wartość C z obliczeń musiałaby wynosić 0,1 - wtedy miasto rośnie w minimalnym ustalonym tempie. Drugim dodanym ustawieniem byłby parametr zmniejszający wymaganą dostawę (wartość C) dla maksymalnego tempa wzrostu.
Poza tym jest kilka innych bardziej szczegółowych poprawek niektórych wartości.

Niżej dwa przykładowe okna miast z ograniczoną ilością danych (jest 19, chyba że coś źle liczę). Wartości są raczej przypadkowe, choć w zależności od ustawień byłyby jak najbardziej realne.
Pod spodem zestaw użytych kolorów. Obok jest paleta DOS, o ile się nie mylę, z kodami kolorów.
Jeszcze niżej wspomniany wykres.
[Obrazek: 373NWD_panele_miasta_kolo.png]
#16
Wersja v0.1.0:
- brak obsługi prądu
- brak obsługi dofinansowań i podatków
- obliczanie komunikacji przy użyciu wersji 1 z postu #13
- brak menu z konfiguracją
- liniowy wzrost miasta (nie tak jak docelowo z krzywą)

- coś działa Smile

Konfiguracja w pliku config.nut:
W tabeli TransportCargo ustawione są mnożniki dla obliczeń komunikacji.
Do prawidłowego działania obliczeń przemysłu, handlu i budownictwa należy uzupełnić mnożniki IndustryMultipier (przemysł), TradeCargoMultipier (handel) oraz BuildCargoMultipier (budownictwo). W pierwszym przypadku dotyczy to towarów produkowanych, a w pozostałych dwóch towarów dostarczanych. Towary produkowane domyślnie mają mnożnik 1, towary dostarczane (dla handlu i budownictwa) nie będą naliczane bez ustawienia mnożnika. Nazwy towarów zależą od użytego seta, np. dla FIRS: http://bundles.openttdcoop.org/firs/rele...rence.html (kolumna Label)
Parametr IndustryDistance to odległość w której przedsiębiorstwa będą przypisywane do danego miasta.

.zip   NWD.zip (Rozmiar: 4.24 KB / Pobrań: 40)

Wersja v0.1.1:
- poprawki błędów
- TradeCargoMultipier oraz BuildCargoMultipier już skonfigurowane dla FIRS

.zip   NWD101.zip (Rozmiar: 4.28 KB / Pobrań: 42)

Wersja v0.1.2:
- poprawnienie obliczania dystansu przedsiębiorstw od miasta
- zmieniona domyślna maksymalna odległość przedsiębiorstwa od miasta (parametr IndustryDistance, domyślnie 60)
- przypisywanie stacji do miasta również ze względu na dystans (parametr StationDistance, domyślnie 20)

.zip   NWD102.zip (Rozmiar: 4.31 KB / Pobrań: 47)
#17
Da radę wrzucić to na "banany"? Spróbowalibyśmy przetestować to na serwerze.
#18
Można by, ale po co?
Wystarczy że ściągniesz skrypt na serwer i ustawisz w konfiguracji. Skrypty wykonują się na serwerze, klient ich nie pobiera i nic o nich nie wie.
#19
Ciekawy byłby na tym skrypcie serwer z budowaniem miasta.
#20
Hej Milek. Jeszcze trochę potestowałem skrypt na twoim serwerze i offline, no i znalazłem parę elementów do zmiany poza tymi, o których wspomniałeś. A więc:
1. Miasta nie rosną dzięki samemu transportowi pasażerów, nawet gdy bezrobocie wynosi 0% - dla małego wzrostu powinien wystarczyć jeden element np. tylko komunikacja miejska. Tymczasem konieczny jest choć minimalny rozwój przemysłu bądź handlu. Niekiedy może to bardzo komplikować grę, choć zachowanie w opcjach takiego warunku też byłoby przydatne. Np. gdy twórca scenariusza chce, aby jakieś miasto/miasta trudniej się rozwijały, takie rozwiązanie będzie ok. Ale co jeśli ktoś chce budować wyłącznie sieć pasażerską?
2. Oceny dla dostaw powyżej 100% nie są redukowane (?) - zbyt łatwo można rozwijać miasto tylko jednym elementem. Powyżej 100% ocena powinna być pierwiastkowana i mnożona x3, czyli zamiast np. 500% byłoby wtedy 160%, albo zamiast 43 609% "zaledwie" 725%. (samo dzielenie nadwyżki niewiele daje w przypadku dużych wartości). Ewentualnie może być tak, że wyświetlany będzie rzeczywisty procent dostaw, ale jego wpływ w przypadku tak kosmicznych wartości nie będzie aż tak duży.
3. Produkcje wysypisk w przypadku FIRS'a nie powinny być brane pod uwagę albo w jedynie bardzo niewielkim stopniu np. x0,1. Ten parametr powinien być jednak ustawialny w opcjach, choćby na wypadek gdyby któryś z twórców setu poszedł po rozum do głowy i te produkcje w końcu ograniczył.
4. W "Komunikacji międzymiastowej" nie jest brana pod uwagę liczba połączonych miast. Trochę szkoda, ale w sumie chyba inaczej będzie można rozwiązać "problem" cargodista (dodatek zmieniający sposób oceny stacji(?) - im więcej miast w "rozkładzie" stacji tym wyższa jej ocena i większa liczba przybywających na nią pasażerów i poczty), więc tak by mogło zostać.
5. Pasażerowie przejeżdżający przez miasto w "Komunikacji międzymiastowej" są źle liczeni - W założeniu (post #15) pasażerowie >przesiadający się< mieli być liczeni x0,5, tutaj natomiast liczeni tak są nawet ci, którzy jedynie przez stację przejeżdżają. W sumie można by z tego fjuczera zrezygnować - tacy pasażerowie będą jeszcze liczeni w komunikacji miejskiej jeśli będą przesiadać się na inną stację, więc nie ma sensu aby z tego powodu naliczany był podwójny "bonus".
6. Dostarczanie pasażerów do hoteli wpływa na wielkość handlu - może tak być, ale nie powinno aż w tak dużym stopniu.
7. To liczenie przemysłu wg odległości ma zdecydowanie zalety - miasta sąsiednie również się rozwijają - ale ma też wady, z tego samego powodu. Myślę, że lepszym rozwiązaniem byłoby liczenie przemysłu wg przypisania do konkretnych miast i ewentualnie dodatkowo w mniejszym stopniu wg odległości od przedsiębiorstwa. Przy czym dobrze gdyby wpływ przedsiębiorstwa malał wraz ze wzrostem odległości, ale to już mniej istotne (taki sposób liczenia wpływu najlepiej by się sprawdził w przypadku elektryczności - im dalej od elektrowni/trafostacji, tym mniejsze dostawy prądu). Ogólnie chodzi m.in. o to, aby np. taki Sochaczew nie dogonił wielkością Warszawy.
8. Niektóre miasta pomimo ogromnych dostaw i zerowego bezrobocia nie chcą się rozwijać. Nie wiem dlaczego. Jedno z takich miast (pokazane na screenie) po pewnym czasie zaczęło się jednak rozwijać jakiś czas po tym, jak postawiłem obok przetwórnie odpadów. Ale to mogła być inna kwestia.
9. Miasta ufundowane również nie rozwijają się.
10. Zdaje się, że skrypt wykonuje pierwsze obliczenia dopiero po 3 miesiącach od rozpoczęcia gry. Gdyby zaczynał już po 1 miesiącu byłoby lepiej, ale to już jest w sumie detal.

Niżej dwa screeny obrazujące większość z opisanych problemów.
[Obrazek: 232NWD_test_Frindingham_r.png]

[Obrazek: 501NWD_test_Frindingham_r.png]


Skocz do:


Użytkownicy przeglądający ten wątek: 1 gości