Ocena wątku:
  • 1 głosów - średnia: 5
  • 1
  • 2
  • 3
  • 4
  • 5
Inne [GS] Think globally, act locally
#1
Na bazie istniejącego (ale zbugowanego) skryptu Town_and_Industry_Control-3.1 zrobiłem nowy, który:
  • uzależnia ilość tworzonego w czasie gry nowego przemysłu od ogólnej sytuacji ekonomicznej na mapie;
  • uzależnia wzrost miast od ilości pasażerów/poczty, a dla średnich miast również towarów/żywności, dla jeszcze większych opcjonalnie paliwa i materiałów budowlanych. Sytuacja ekonomiczna ma też pewien niewielki wpływ na wzrost miast.
  • Indeks opisujący sytuację ekonomiczną zależy od ilości obsługiwanego przemysłu, ilości obsługiwanych miast oraz od czasu gry.


Skrypt w naturalny sposób pozwala ograniczyć ilość niepotrzebnego przemysłu zaśmiecającego mapę. Jeśli jedno z 2 kryteriów jest spełnione: dobra ogólna sytuacja ekonomiczna lub ilość obsługiwanego przemysłu większa niż ileś procent w ustawieniach skryptu, to nowy przemysł jest budowany.

Skrypt ogranicza też proste granie wyłącznie pasażerami wymagając łańcuchów produkcji towarowej  do wzrostu większych miast.

Polecam na serwery, zamiast twardego blokowania budowy przemysłu.
Wrzuciłem wersje 4 na banany.
#2
Trzy podstawowe uwagi:
1. Dlaczego zawsze musisz zmieniać nazwę dodatku na listach? Raz jest Think globally, Act locally, a zaraz potem Act locally, Think globally. Tak samo z wąskotorówkami, fixem i chyba jeszcze innymi... Dlaczego zmuszasz graczy, aby za każdym razem musieli domyślać się jaką to tym razem nazwę wymyśliłeś? Ja na liście mam niemal 800 wersji różnych dodatków (celowo mam widoczne wszystkie) - wyszukanie wśród nich czegoś nowego, nie wiadomo jak nazwanego jest karkołomne. Dlaczego tylko w przypadku twoich dodatków po ich ściągnięciu niemal za każdym razem muszę używać wyszukiwarki? Sory za krytykę, ale musiałem się trochę wyżyć.
2. W przypadku skryptów ściągnięcie nowej wersji - w odróżnieniu od zwykłych newGRF - zastępuje poprzednią, czyli ją kasuje (to wkurza jeszcze bardziej, ale w tym już nie ma twojej winy). A jak pewnie nie raz zauważyłeś, nie zawsze nowe oznacza lepsze. I co najważniejsze, bardzo wątpię w to, aby można było zaktualizować skrypt w istniejącej grze (offline), co może oznaczać, że w przypadku ściągnięcia nowej wersji skryptu, starsze save'y staną się niegrywalne. Dlatego mam taką prośbę, aby nowe wersje skryptu były publikowane jako oddzielne dodatki tak jak jest to np. z firs'ami 1, 2 i 3.
3. Skrypt nie działa dobrze, w zasadzie jest niegrywalny.
Po pierwsze: Żywność, towary, a dalej materiały i paliwa trzeba dostarczać niemal non stop - skrypt bierze pod uwagę dostawy ze zdecydowanie zbyt krótkiego okresu. To na pewno nie jest ostatni miesiąc, a zaledwie kilka ostatnich dni! Dla dobrego działania to jednak nie powinien być tylko ostatni miesiąc, ale średnia z co najmniej 3 miesięcy lub nawet roku - duże statki nie pływają zbyt często. W "dejlengowej" wersji pewnie mógłby pozostać miesiąc dla obliczeń. To jednak nie może być identyczny mechanizm co dla obliczeń pasażerów - tam pasażerowie, nawet gdy nie są transportowani, nadal pojawiają się na stacji i ocena transportu tak szybko się nie zmienia.
Po drugie: Zawiesza się. Niżej przykład z transportem pasażerów i poczty. Wcześniej miałem problem z bazowym T&IC, gdzie pomimo obsługi wszystkich przedsiębiorstw nic nowego już nie powstało.

[Obrazek: 695TGAL_zawiecha.png]

Inne uwagi:
4. Szybkość rozwoju miast w dalszym ciągu zależy od ilości obsługiwanych stacji - 6 przystanków i basta! I nie ważne, że wiocha ma 50 mieszkańców, ma być 6 przystanków!
4b. Lepiej i ciekawiej by było, gdyby szybkość zależała od procentu tych dostaw. I aby od samego początku byłyby brane pod uwagę dostawy wszystkich ładunków - nie trzeba by było wszystkiego dostarczać, ale można.
4c. Wtedy można by było pomyśleć o rozdzieleniu (choćby opcjonalnym) żywności + towarów oraz paliwa + materiałów na osobne kategorie. RCG opcjonalnie je łączy.
4d. Myślę że ciekawiej i sensowniej też będzie, jeśli dostawy będą pokazane ilościowo jak w RCG albo CB (dostarczone/wymagane/(zgromadzone/średnia dostaw)) a nie procentowo. W NWD są procenty, ale to dlatego, że nie jest to tak wprost liczone; z resztą tam też kategorie są inaczej nazwane (handel, budownictwo, komunikacja). Tutaj natomiast wymagane są konkretne ilości, ale ile to jest 10% paliwa albo 20% żywności?
4d. Transport pasażerów i poczty lepiej, aby pozostał podawany w procentach - tu dość łatwo można dojść o co chodzi - z tym, że maksymalnie nie powinno wychodzić więcej niż 100%. Czyli (a/A+b/B)/2 lub (a+b)/(A+B)/2 (bez mnożników dla poczty czy pasażerów) - pierwsza metoda równoważy znaczenie poczty, druga je umniejsza.

Obecna wersja skryptu (4):

[Obrazek: 987Skrypt_TGAL_wersja_4.png]

Wersja opierająca obliczenia rozwoju miasta na wartości dostaw w dłuższym okresie (miesiąc dla wydłużonego czasu gry, kwartał/rok dla standardowej gry). Graficznie słabo czytelny, ale to można poprawić.

[Obrazek: 405Skrypt_TGAL_wersja_red.png]

Wersja opierająca obliczenia na stanie zmagazynowanych ładunków - dostawy ubywają co miesiąc o określony procent i/lub liczbę. Trzy wersje kolorystyczne poprawiające czytelność. Druga zawiera kolory z wykresu stawek.

[Obrazek: 460Skrypt_TGAL_wersja_zma.png]


5. Wymagany domyślny procent obsługi przedsiębiorstw (35%) to jakiś był żart w przypadku FIRS'a - nie zmieniłeś go. Kiedy na jakiejkolwiek mapie widziałeś, aby był obsługiwany aż tak wysoki ich odsetek? Takie ustawienie w praktyce oznacza, że nowe przedsiębiorstwa w ogóle nie powstaną, poza tymi sponsorowanymi.
5b. Myślisz, że dałoby się zrobić podział dla tych przedsiębiorstw? Tak, aby np. obsługa 20% hut dawała zielone światło dla budowy nowej?
6. Wątpię, ale może jest taka możliwość, aby do poszczególnych ustawień, jak jest w przypadku zwykłych newGRF, dodać objaśnienia? Jeśli nie, można by było je jednak dodać jako fake'owe opcje - o wiele lepsze to niż szukanie wyjaśnienia w "read me", gdzie z resztą użyto fatalnej czcionki.
7. Nigdzie nie dałeś informacji z jakimi dodatkami przemysłowymi skrypt współpracuje. Na pewno z FIRS'em 3 i na pewno nie ze standardowym przemysłem.

8. Zanim dodasz nową, poprawioną wersję patrz pkt.2. Wrzuć ją tutaj czy gdziekolwiek, aby można było przetestować wcześniej jak co działa.
#3
Z procentami to popsułem, bo towary są inaczej liczone niż pasażerowie/poczta - ci są od razu liczeni przez openttd względem wielkości miasta, a towary jako szt/t, zapomniałem to przeliczyć.
Co do 35% obsługiwanego przemysłu, to oczywiste że jest to ustawienie dla standardowego przemysłu,
z trudem udało się uzyskać tyle dla FIRS Steeltown, dla FIRS Extreme musi być mniej.
Skrypt działa z każdym dodatkiem, jeśli nie ma paliwa i budowlanych, to można dać zero.
Po to jest menu konfiguracyjne.
Jeśli chodzi o częstotliwość dostaw, to moim zdaniem jest dobrze, że nie można sobie spamować miasta raz na 3 miesiące wielkim statkiem.
Można zrobić transfer i rozwozić dostawczakami? Można Smile

Co rozumiesz przez "zawieszanie się"? Z tego co wiem, miasto nie rośnie jak są stacje tuz przy etykiecie stacji, może o ten bug chodzi?

Model wzrostu poprzez standard openttd (ilość przystanków) z limitowaniem tego zależnym od ilości dostarczanych towarów jest moim zdaniem lepszy niż skrypty które skalują wzrost tylko ilością towarów (mała miejscowość nie powinna rosnąć 1/dzień tylko dlatego że została zaspamowana towarami).
#4
(26-11-2017, 11:39)McZapkie napisał(a): Co do 35% obsługiwanego przemysłu...

Optymalne myślę, że byłoby coś między 10 a 20%. Dla firsopodobnych przemysłów to nadal sporo, ale jakiś kompromis ze standardem raczej musi być.

(26-11-2017, 11:39)McZapkie napisał(a): Co rozumiesz przez "zawieszanie się"? Z tego co wiem, miasto nie rośnie jak są stacje tuz przy etykiecie stacji, może o ten bug chodzi?

Miałeś na myśli przystanki obok etykiety miasta? One spowalniają, ale nie wstrzymują rozwoju. Tutaj skrypt całkiem przestał rozwijać miasto. Znalazłem jednak przyczynę: skrypt nie pokazywał właściwego powodu braku rozwoju. Raz mi pokazywał że pasażerów nie wożę, choć ocena powinna przekraczać 130 / 10, innym razem, że paliwa/materiałów dostarczam za mało, choć jeszcze niedawno pokazywało ponad 300%.

Przed "zawieszeniem się" skryptu
[Obrazek: 836TGAL_przed_zawiech_.png]

Tu brakuje mu pasażerów, choć co innego można wyliczyć samemu
[Obrazek: 695TGAL_zawiecha.png]

A tu niby materiałów nie dostarczam
[Obrazek: 603TGAL_zawiecha_2.png]

Jak później zauważyłem, powodem była stacja odbierająca żywność, która przestała ją akceptować - po rozszerzeniu zasięgu tak, aby obejmowała sklep, wszystko zaczęło znów działać. W każdym bądź razie to jest ewidentnie zły sposób informacji. Powinny być widoczne zawsze wszystkie kategorie, a nie jedna, gdy czegoś brakuje, w dodatku wybrana jakby losowo...

(26-11-2017, 11:39)McZapkie napisał(a): Jeśli chodzi o częstotliwość dostaw, to moim zdaniem jest dobrze, że nie można sobie spamować miasta raz na 3 miesiące wielkim statkiem.
Można zrobić transfer i rozwozić dostawczakami? Można Smile

...Losowo te brakujące dostawy wybierane nie są, powodem takich niezrozumiałych zmian jest właśnie ten nonsensownie krótki okres dla obliczeń dostaw. To jest zaledwie 7 dni! To jest chore! Ty piszesz coś o spamowaniu? Że to niby ma temu zapobiegać? Ten skrypt zachęca, a wręcz wymaga spamowania! Na każde miasto - nawet te mniejsze -  aby móc je rozwijać, będziesz miał po kilkadziesiąt ciężarówek. Na takim efekcie ci zależy? Już sam czas rozładunku i wyjazdu ze stacji dla nawet krótkiego składu jest dłuższy.

(26-11-2017, 11:39)McZapkie napisał(a): Model wzrostu poprzez standard openttd (ilość przystanków) z limitowaniem tego zależnym od ilości dostarczanych towarów jest moim zdaniem lepszy niż skrypty które skalują wzrost tylko ilością towarów (mała miejscowość nie powinna rosnąć 1/dzień tylko dlatego że została zaspamowana towarami).

I wcale nie musi. Ani w NWD ani RCG nie da się momentalnie rozdmuchać miasta.
W NWD do każdej, nawet najmniejszej wioski możesz zawieźć co chcesz i będzie to miało wpływ na rozwój, co wcale nie oznacza, że przy nawet gigantycznych dostawach miasto będzie rosło jak szaloneWink To jest to samo tempo co w standardzie, tylko tam warunek ilości stacji został zastąpiony bardziej sensownym.
W twoim skrypcie myślałem właśnie o czymś podobnym: zamiast "6 stacji", 6, czy tam 5 innych warunków. Dla każdego z ładunków można wtedy dać odpowiedni mnożnik, aby miał większy lub mniejszy wpływ na rozwój - takie ustawienie jest w skrypcie Real Growth, które moim zdaniem jest bardzo przydatne.
#5
Ja nie bardzo umiem w ten squirrel, z tymi opisami to jest tak, że chyba tylko jeden tekst można do miasta dołożyć, więc aby ten tekst opisywał różne sytuacje, muszą być jakieś straszne drabinki z warunkami.
Próbowałem podpatrywać jak inni to robią, al kompletnie nie rozumiem co tam jest namotane.
Będę powolutku coś montował swojego.
Może zrobić tak, że do pewnego rozmiaru wpływ ma tylko ilość pax/mail na zasadzie rośnie w stylu openttd/nie rośnie, a powyżej tgo rozmiaru trzeba dostarczać inne towary, których ilość, tak jak w RCG (ale także globalny indeks ekonomiczny) warunkuje szybszy lub wolniejszy wzrost.
#6
(27-11-2017, 02:47)McZapkie napisał(a): (...) muszą być jakieś straszne drabinki z warunkami.
Próbowałem podpatrywać jak inni to robią, al kompletnie nie rozumiem co tam jest namotane.

Niestety, ale nie będę mógł ci tutaj pomóc, dla mnie to gorzej wygląda niż chińszczyzna.Sad
Szczytem moich umiejętności programowania była podmiana przypisanych ładunków w RCG i dość karkołomna, choć w miarę udana zmiana opisu w oknie opowieści, wraz z dodaniem strony z zasadami gry na serwerze.Smile

(27-11-2017, 02:47)McZapkie napisał(a): Może zrobić tak, że do pewnego rozmiaru wpływ ma tylko ilość pax/mail na zasadzie rośnie w stylu openttd/nie rośnie, a powyżej tgo rozmiaru trzeba dostarczać inne towary, których ilość, tak jak w RCG  (ale także globalny indeks ekonomiczny) warunkuje szybszy lub wolniejszy wzrost.

Też tak może być, choć fajnie jest jak dostawy innych ładunków też wpływają na rozwój nawet niewielkich miejscowości.
Najważniejsze jest jednak (mówimy jeszcze o tym skrypcie?) wydłużenie tego okresu dla obliczeń dostaw. Przy wydłużonym czasie gry może to być nawet niezauważalne, ale w przypadku standardowej gry działa to naprawdę źle.

A tak apropo nowych skryptów... Dla mnie najciekawszy jest jednak NWD.Smile Gdyby był ukończony, to nie wiem co lepszego / ciekawszego można by było zrobić.

Jedno z pierwszych założeń jak miał wyglądać
[Obrazek: 870NWD_Ocena_miasta.bmp]

Z tych istotnych rzeczy wiele już nie zostało, ale jakby miał zawierać te wszystkie założenia, o których napisałem...

Jakbyś chciał coś wykorzystać albo podziałać coś z tym skryptem, ja nie mam nic przeciwko. Dwa rozwiązania są w nim szczególnie ciekawe. Liczenie produkcji okolicznych przedsiębiorstw - jak zauważyłeś wymaga to jednak pewnej zmiany. Miał być też dodany mnożnik dla produkcji przetwórczej. Drugim elementem jest podział komunikacji na tą miejską i międzymiastową, dzięki czemu spreading stacji i rozdzielenie komunikacji wcale nie jest z tym skryptem takie opłacalne.Smile
#7
Pograłem sobie na mapie Polski pod JGR i muszę przyznać rację, nawet przy spowolnieniu x4 te 7 dni to za mało. Samego odświeżania nie chcę zmieniać, bo straci się informację o zmianach, ale wprowadzę coś w rodzaju średniej kroczącej, tzn wskaźniki będą średnią z bieżącej wartości i poprzedniej.
Jeśli więc co miesiąc przybędzie 160 jednostek, to zamiast 0, 160, 0, 0 0, 160, 0, 0, 0, 160,,... będzie 0, 80, 40, 20, 10, 85, 43, 21, 11, 85, ...

Co do rośnięcia miast, to zapomniałem zupełnie, że używam JGR, gdzie jest patch pozwalający na zdefiniowanie wagi, jak na wzrost miasta wpływa ilość pasażerów i poczty, a jak wpływa standardowy mechanizm 5 przystanków. Dlatego nie widziałem problemu w tym, że wzrost był kontrolowany przez openttd, bo liczyła się zarówno ilość przystanków jak i miesięczny procent pasażerów i poczty. Takie coś ma jak najbardziej sens, ilość przystanków powinna wpływać na rozwój miasta, ale ilość towaru również, a tego w oryginalnym openttd brak. Trzeba będzie dorobić jakąś opcję do zmiany tego.

NWD nie podejmuję się kontynuować z powodów podanych poprzednio: grzebanie w cudzym kodzie wymaga znacznie większej znajomości kodu niż pisanie własnego Smile
#8
(29-11-2017, 15:56))McZapkie napisał(a): (...) wprowadzę coś w rodzaju średniej kroczącej, tzn wskaźniki będą średnią z bieżącej wartości i poprzedniej.
Jeśli więc co miesiąc przybędzie 160 jednostek, to zamiast 0, 160, 0, 0 0, 160, 0, 0, 0, 160,,... będzie 0, 80, 40, 20, 10, 85, 43, 21, 11, 85, ...

No, to już ciekawy kierunek.Smile Z tym, że jeśli dasz samą średnią, to i tak bardzo szybko będzie ta wartość malała. Dostawy raz w miesiącu, nawet 4 krotnie większego ładunku niż wymagany, powodowałoby, że i tak przez pół miesiąca miasto by nie rosło (o ile w ogóle by rosło). Dlatego myślę, że dobrze by było do tego dodać mnożnik spowalniający odpowiednio ten spadek.
Dobrze by było też, gdyby ten mnożnik był ustawialny, dzięki czemu dałoby się dostosować skrypt np. do szybkości gry.


Mnożnik mógłby wynosić domyślnie coś między 1,5 a 1,8. Przy ustawieniu poniżej ok.1,689 dostawy nie magazynują się; przy wartości 2 nie ubywają.
Można by było też ewentualnie dodać wartość stałą o jaką zawsze ubywałoby ładunku, wtedy "stan magazynów" szybciej by się zerował, maksymalny mnożnik mógłby wynieść wtedy 2, ale nie wiem czy jest sens to komplikować.

[Obrazek: 485Skrypt_TGAL_mno_nik_1.png]

Ustawienie można by było nazwać np. "Szybkość ubywania dostaw" albo "Tempo konsumpcji dostaw przez miasto". Wartość w ustawieniu © najlepiej gdyby wynosiła między 1 (0 - jeśli będzie określony stały ubytek) a 100. Wtedy wartość mnożnika wynosiłaby: C = (200 - c) / 100

Niżej pliki z arkuszem kalkulacyjnym gdybyś sam się chciał pobawić. Ogólnie w arkuszach kalkulacyjnych bawię się dość rzadko, w dodatku robiłem to w Open Office (który za wiele nie ma wspólnego ze słowem intuicja), więc może to tak trochę dziwnie działać.


Załączone pliki
.rar   OTTD - Skrypt TGAL - mnoznik v1.1 OO.rar (Rozmiar: 16.81 KB / Pobrań: 104)
.rar   OTTD - Skrypt TGAL - mnoznik v1.1 MS.rar (Rozmiar: 4.56 KB / Pobrań: 52)
#9
Nowa wersja 6 skryptu w załączniku.

Metoda kontroli wzrostu miasta jest teraz nastepująca:
poniżej 5k mieszkańców, jeśli próg transportu pass+poczty jest przekroczony,
to rośnie zgodnie z regułami openttd.
Powyżej 5k, przekroczenie minimalnego progu pass+mail nadal jest warunkiem sin equa non jakiegokolwiek wzrostu miasta, ale zaczynają się też liczyć ilości innych towarów
(dobra konsumpcyjne takie jak food, good, beer, petr, watr, gold itp).
Jest to bardziej miękkie, tzn jeśli ilość towarów jest mniejsza niż wymagany limit, to nadal miasto ma szansę rosnąć, ale wolniej. Teoretycznie można samymi pass+mail zrobić wzrost, ale muszą to być b. duże ilości (w pzypadku ECS doliczają się też na tym etapie turyści), ponieważ waga pass+mail jest 10x mniejsza niż towarów.
Powyżej 10k podobnie jak powyżej, ale z największą wagą liczą się towary przemysłowe (węgiel, ropa, pojazdy, supply, ziarno, owoce, papier).

Szybkość wzrostu miasta jest średnią kroczącą, co wygładza efekt dostarczania "impulsów" towarów.
Ponadto czas odświeżania skryptu, standardowo 7 dni, można sobie wydłużyć,
ale nie polecam, lepiej zmienić strategię i np. zamiast dostarczać duże transporty żywności, wspierać lokalny przemysł dostarczając doń surowce i sukcesywnie produkować żywność na miejscu.
Obecnie skrypt testowany jest na PlExp na mapie Polski pAtera.


Załączone pliki
.gz   Think_globally_act_locally-6.tar.gz (Rozmiar: 17.05 KB / Pobrań: 78)
#10
(03-12-2017, 14:56)McZapkie napisał(a): Szybkość wzrostu miasta jest średnią kroczącą (...)

Myślałem, że zrobisz to względem samych dostaw - lepiej by było widać, czego jest mało dostarczane, a czego dużo. Tutaj raz może być bardzo dużo, za chwilę w ogóle nic: pisze 0/XX%, a miasto rośnie.  Ale ok, tak też działa dobrze.

Nie wiem czy zauważyłeś, ale ten wskaźnik szybkości rozwoju (i inne) zmienia się w trakcie pauzy.

(03-12-2017, 14:56)McZapkie napisał(a): Ponadto czas odświeżania skryptu, standardowo 7 dni, można sobie wydłużyć,
ale nie polecam, lepiej zmienić strategię i np. zamiast dostarczać duże transporty żywności, wspierać lokalny przemysł dostarczając doń surowce i sukcesywnie produkować żywność na miejscu.

Tak czy inaczej, lepiej jest produkować na miejscu ze względu na rozwój przemysłu - dostawę surowców, co też ma wpływ na rozwój w tym skrypcie.

Co do samego czasu, wydłużając ten okres nie zwiększa się wymagana ilość ładunków, przez co ocena dostaw rośnie. Można to skorygować zwiększając wszystkie pozostałe ustawienia, ale lepiej gdyby skrypt automatycznie mnożył również te wartości.


(03-12-2017, 14:56)McZapkie napisał(a): (...) dobra konsumpcyjne takie jak food, good, beer, petr, watr, gold itp.

O materiałach budowlanych zapomniałeśWink Nigdzie nie są liczone. Owoce, ale tylko te dostarczane do sklepów, też mogłyby być brane pod uwagę.

(03-12-2017, 14:56)McZapkie napisał(a): poniżej 5k mieszkańców, jeśli próg transportu pass+poczty jest przekroczony,
to rośnie zgodnie z regułami openttd.
Powyżej 5k, przekroczenie minimalnego progu pass+mail nadal jest warunkiem sin equa non jakiegokolwiek wzrostu miasta, ale zaczynają się też liczyć ilości innych towarów.

Te małe miasta, poniżej 200-300 mieszkańców, produkujące po 1 pasażerze, w ogóle nie powinny mieć wymaganego progu transportu mieszkańców (chyba).

Myślę, że mogłoby być przydatne ustawienie dla tych progów, od których wymagane są kolejne rodzaje dostaw. Choć te obecne ustawienia (5000/10000) są dość uniwersalne.


To co mnie jeszcze gryzie, to  nadal czytelność informacji w panelu miasta. Przydałoby się dodać kolor albo kategoriom ładunków, albo podawanym wartościom. Jeśli chcesz zostać przy obecnym sposobie podawania dostaw (wartości bezwzględne w ostatnim okresie) lepszy będzie ten pierwszy sposób. Jeśli dałbyś np. średnią z dłuższego okresu, mogłyby być wartości w kolorze.
No i jeszcze kwestia tych procentów dostaw. Sory, ale ja nadal nie wiem ile to jest te 20%  Smiley44


No i... szybkości rozwoju. Dobrze by było gdyby choćby ogólne ustawienie szybkości rozwoju miast w samej grze wpływało na ten fakt. Obecnie dość ciężko jest uzyskać szybszy rozwój - to jest dobre dla gry z wydłużonym czasem, ale dla standardowej rozgrywki może okazać się za wolne.
#11
Cytat:Myślałem, że zrobisz to względem samych dostaw - lepiej by było widać, czego jest mało dostarczane, a czego dużo.

To wymagałoby stworzenia struktury danych globalnych dla każdego miasta, nie wiem jak to zrobić i czy nie obciążałoby to skryptu.
Ponadto chwilowe informacje dają lepszą informację odnośnie konkretnych dostaw.
Zastanawiam się jeszcze nad dodaniem parametru ważonej średniej - duży parametr dałby większe wygładzenie średniego wzrostu.
Co do procentów dostaw towarów, to liczone są względem rozmiaru miasta: 5000 * transport/(10+town_population).
Co do pauzy to muszę zerknąć, być może trzeba będzie po wybudzeniu skryptu sprawdzać czy jest pauza i nic nie robić jak jest.

Dobry pomysł z małymi miastami, można pomyśleć o nowej kategorii pomiędzy bardzo małymi a tymi do 5k mieszkańców.

Nie bardzo wiem jak sprawdzać parametry typu szybkość wzrostu, jest coś takiego jak GSGameSettings.GetValue ale nie wiem jak to działa.
Może lepiej dać parametr skryptu który to kontroluje?

Mam jeszcze jeden pomysł, trochę taki z boku.
Swego czasu robiłem patch który umożliwia generację subsydiów również gdy jest włączone cargodist. Małe szanse aby ten patch znalazł się w oficjalnej wersji, ale subsydia można też generować poprzez skrypt.
Pomyślałem, że można by generować subsydia do transportu pasażerskiego z danego miasta (które ma HQ oraz dostawę towarów powyżej progu) do innego losowego miasta (ale w odróżnieniu od oryginalnego mechanizmu, bez limitu 70 kratek oraz niezależnie od istniejącej obsługi).
W przypadku dobrej ogólnej ekonomii subsydia mogłyby też być generowane między dwoma zupełnie losowymi miastami.
W ten sposób promowało by się duże rozwinięte sieci cargodist (bo nie trzeba by budować nowych linii, zawsze coś by "wpadło" do sieci).

Materiały budowlane są liczone (w wersji z załącznika, bo na serwerze jest ciut wcześniejsza gdzie o nich zapomniałem).
Owoce są liczone, ale jako surowce, w kategorii industrial resources, dla miast >10k.
Nie widzę opcji dających możliwość rozróżnienia, czy owoce są do tego czy innego przemysłu dostarczane.

Zastanawiam się nad zrobieniem 3 kategorii:
consumer goods (to co obecnie)
industrial supplies (ensp, fmsp, mnsp, fert, vehi, stel etc, copr, papr, glas, rfpr, wdpr)
industrial resources (coal, _oil, grain etc, frut, lvst, wood),
z tym że miasto między 5k i 10k brałoby pod uwagę obydwie kategorie łączone, a miasto powyżej 40k oddzielnie,
z większą wagą dla tej ostatniej.
#12
(04-12-2017, 14:30)McZapkie napisał(a): Zastanawiam się jeszcze nad dodaniem parametru ważonej średniej - duży parametr dałby większe wygładzenie średniego wzrostu.
Co do procentów dostaw towarów, to liczone są względem rozmiaru miasta: 5000 * transport/(10+town_population).
(...)
Ponadto chwilowe informacje dają lepszą informację odnośnie konkretnych dostaw.

Nie jestem przekonany co do słuszności tej drogi. Te procenty to dla mnie zło wcielone - no, nie są one przyjazne. Raz pokaże 300%, zaraz potem 0%, następnie 20% - patrzysz i nie wiesz czy jest ok, czy nie. Musisz się przyglądać i de facto samemu wyliczać średnią. Znacznie lepiej jest pewnie z wydłużonym czasem rozgrywki lub wydłużonym samym tym okresem, wtedy wynik już bardziej zbliżony jest do średniej. Nadal jednak uważam, że średnia z wybranego okresu albo wersja z "ubytkiem" byłaby najlepsza, ale podawanie takiego wyniku bezwzględnych ilości dostaw w danym okresie też nie jest złe, z tym, że ten okres lepiej aby wynosił pełny miesiąc (obliczenia / podsumowanie 1-go każdego miesiąca), albo co kwartał, tak jak obliczane są wyniki firmy (obliczenia w konkretne 4 dni w roku).

Cytat:-Szybkość wzrostu miasta jest średnią kroczącą (...)
 -Myślałem, że zrobisz to względem samych dostaw
-To wymagałoby stworzenia struktury danych globalnych dla każdego miasta, nie wiem jak to zrobić i czy nie obciążałoby to skryptu.

Nie wiem jak to dokładnie działa, ale do tego wystarczyła by tylko jedna dodatkowa dana: zawierająca jeszcze bieżący (za chwilę poprzedni) wynik dostaw.

(r - C) x D + S = R

r - poprzedni wynik
C - stały ilościowy ubytek ładunku (np. 1/10 x populacja miasta)
D - ubytek procentowy ładunku (aby w małych miastach nie gromadziły się jego tysiące; np. 0,7)
S - aktualne dostawy
R- nowy wynik dla dalszych obliczeń


(04-12-2017, 14:30)McZapkie napisał(a): Nie bardzo wiem jak sprawdzać parametry typu szybkość wzrostu, jest coś takiego jak GSGameSettings.GetValue ale nie wiem jak to działa.
Może lepiej dać parametr skryptu który to kontroluje?

Tak też mogłoby być.


(04-12-2017, 14:30)McZapkie napisał(a): Swego czasu robiłem patch który umożliwia generację subsydiów również gdy jest włączone cargodist. Małe szanse aby ten patch znalazł się w oficjalnej wersji, ale subsydia można też generować poprzez skrypt.
Pomyślałem, że można by generować subsydia do transportu pasażerskiego z danego miasta (które ma HQ oraz dostawę towarów powyżej progu) do innego losowego miasta (ale w odróżnieniu od oryginalnego mechanizmu, bez limitu 70 kratek oraz niezależnie od istniejącej obsługi).
W przypadku dobrej ogólnej ekonomii subsydia mogłyby też być generowane między dwoma zupełnie losowymi miastami.
W ten sposób promowało by się duże rozwinięte sieci cargodist (bo nie trzeba by budować nowych linii, zawsze coś by "wpadło" do sieci).

Co do takiego wspierania rozbudowy sieci połączeń pasażerskich jestem sceptycznie nastawiony. Nadal najlepiej będzie budować rozdzielne połączenia - to w zasadzie niczego nie zmieni w tym temacie. Jakiś czas temu pisałem o modyfikacji oceny stacji (oceny transportu pasażerów i poczty), gdzie ta zależałaby w głównej mierze od ilości połączonych miast i ilości stacji - tego ominąć by się nie dało: tutaj spreading stacji i wożenie wszystkich pasażerów ze stacji A do B byłoby nieopłacalne względem rozbudowy sieci.

Natomiast w kwestii transportu ładunków przemysłowych, jeśli te subsydia mogłyby mieć znacznie dłuższy czas niż standardowo i mogły dotyczyć nie tylko tych blisko położonych względem siebie przedsiębiorstw... byłoby to genialne! Takie subsydia byłyby w takim wypadku już w zasadzie kontraktami. W połączeniu ze znacznie obniżonymi stawkami za transport mogłoby być naprawdę ciekawie.Smile


(04-12-2017, 14:30)McZapkie napisał(a): Materiały budowlane są liczone

Faktycznie, musiał mnie zmylić ten szybko zmieniający się wynik: 0,0,0,0,6289,0,0,0,0.... Wink


(04-12-2017, 14:30)McZapkie napisał(a): Nie widzę opcji dających możliwość rozróżnienia, czy owoce są do tego czy innego przemysłu dostarczane.

Z pewnością jest taka możliwość. W NWD o ile się nie mylę właśnie tak jest, że ich dostawa do sklepów wpływa na handel, ale już do browaru nie. Podobnie jest z materiałami budowlanymi, których dostawa do spółek ma większy wpływ na budownictwo niż dostawa do sklepów. Tak samo dostawa pasażerów do hoteli ma również niewielki wpływ na handel. Piszę to tak w ramach "ciekawostki zawodowej", bo to w sumie jest coś co fajnie gdyby było, ale konieczne nie jest.


(04-12-2017, 14:30)McZapkie napisał(a): Zastanawiam się nad zrobieniem 3 kategorii:
consumer goods (to co obecnie)
industrial supplies (ensp, fmsp, mnsp, fert, vehi, stel etc, copr, papr, glas, rfpr, wdpr)
industrial resources (coal, _oil, grain etc, frut, lvst, wood),
z tym że miasto między 5k i 10k brałoby pod uwagę obydwie kategorie łączone, a miasto powyżej 40k oddzielnie,
z większą wagą dla tej ostatniej.

Jak uważasz. Może być, choć ta ostatnia kategoria to raczej od 20k mogłaby się zaczynać.
Mi jednak bardziej podobałby się taki bardziej sprecyzowany i czytelny podział:
Pasażerowie i poczta
-Żywność (+owoce do sklepów)
-Dobra konsumenckie (towary, alkohol, paliwo)
-Materiały budowlane
-Surowce przemysłowe
-Produkty przemysłowe

Dlaczego tak, a nie jako połączone? Bo zarówno żywność jak i materiały budowlane są często pomijane. Zwłaszcza wsparcia produkcji tego pierwszego, rzadko kiedy ktoś się podejmuje. W zasadzie byłoby to jedynie rozdzielenie kategorii dóbr konsumenckich na trzy części, które byłyby sumowane, ewentualnie z jakimś niewielkim mnożnikiem między nimi.

Co do czytelności zrobiłem nowe tłumaczenie na polski i zmieniłem wersję angielską. Coś gdzieś jednak chyba musisz wkleić do skryptu, bo po wpisaniu polskich znaków, zawiesza się - zostawiłem litery łacińskie.

[Obrazek: 587TGAL_kolory_w_mie_cie.png]


.rar   TGAL - lang.rar (Rozmiar: 1.03 KB / Pobrań: 17)

Nie wiem gdzie jest jakaś lista dostępnych kolorów i od czego to zależy. Z tego co zauważyłem jest jeszcze {BROWN}, {BLUE} i {PURPLE}.

Miałbym tutaj jeszcze taką sugestioprośbę: Czy mógłbyś zrobić tak, aby nowe kategorie mogły pojawiać się na dole listy a nie u góry? Wszędzie tak jest i tak by było chyba lepiej też dla innych(?).

Heh... apropo tych subsydiów i innych epokowych rozwiązań... Zapytam jeszcze raz: jest możliwe, aby skrypt włączał i wyłączał na zmianę co określony czas wzrost drzew?Smile
#13
Cytat:Co do takiego wspierania rozbudowy sieci połączeń pasażerskich jestem sceptycznie nastawiony. Nadal najlepiej będzie budować rozdzielne połączenia

Wcale nie. Jeśli masz połączone wszystkie miasta ze wszystkimi, to jakiekolwiek subsydium będzie wygenerowane, to je "złapiesz", a jeśli tylko N/2 par, to mała szansa na losowe złapanie akurat takiej pary. Oczywiście ilość pasażerów będzie mała przy sieci, ale zawsze to coś, taki gratisowy przychód, zwłaszcza gdy w miarę często się zdarza.

Niestety nie ma opcji aby wydłużyć subsydium, 12 miesięcy jest zakodowane na twardo.

Co do kolejności kategorii, to próbowałem ale niezbyt to działa.

Co do wzrostu drzew - chyba tylko przez zmianę ustawień, ale nie wiem jak to działa, podobnie jak odczyt ustawień.

EDIT: wolałbym ogólne kategorie, niż rozbijanie na drobne, z tego powodu że:
1. chciałbym by skrypt działał w możliwie każdej ekonomii, ogólna kategoria zabezpiecza szerokie spektrum towarów
2. przy podejściu "impulsowym", logiczne jest, że opłaca się jak najwięcej różnorodnych towarów pchać, bo w lepszym stopniu zabezpiecza to ciągłość całkowitych dostaw powyżej progu.

EDIT: co zamiast %? Tony? A co ze skrzynkami które ważą pół tony albo licho wie ile sobie ktoś umyślił?
#14
Wrzuciłem na Banany wersję 7 skryptu.

Obecnie fazy rozwoju miast są następujące:
poniżej 25 miasto samo rośnie
poniżej 250 miasto rośnie jak w standardzie
poniżej 2500 miasto rośnie jak w standardzie pod warunkiem przekroczenia progu pasażerów
poniżej 5000 j.w. ale z progiem pasażerów i poczty, a w klimacie nieumiarkowanym również żywności (niezależnie od położenia)
poniżej 10000 oprócz przekroczenia tych progów, szybkość wzrostu zależy od ilości pasażerów i poczty
poniżej 20000 jw. ale szybkość zależy też (z większą wagą) od ilości dóbr konsumpcyjnych 
powyżej: j.w. ale z większa wagą również od surowców i środków produkcji.

Ponadto dobrze utrzymywane miasto ma bonus: szansę na wygenerowanie subsydiów pasażerskich do innego miasta, niezależnie od tego, czy te miasta są już obsługiwane i niezależnie od ustawień cargodista.
#15
Widzę, że wprowadziłeś dość sporo zmian. Nie wiem jednak czy publikowanie takiej mocno testowej wersji było dobrym pomysłem. Jak na wersję "gotową" jest w niej zbyt wiele niedoróbek. Chodzi głównie o ustawienia domyślne, ale nie tylko.

Pomysł, aby najmniejsze miasta same się rozwijały jest moim zdaniem ok, choć bywa tak, że nie jest to zawsze oczekiwane. To, że dobra konsumenckie wymagane są, a właściwie: wpływają na rozwój miast dopiero powyżej 10 000, jest słabe - rozwój samą pasażerką i pocztą jest nie tylko zbyt łatwy ale i nudny, w dodatku sam transport towarów jest sztuczny, bo pozbawiony celu. Dobrze by było, aby te progi były ustawialne. Nie bardzo mi się też podoba to, że trzeba wozić i pocztę, i pasażerów, a nie spełnienie któregoś z tych warunków, nawet pomimo minimalnego niedoboru, wstrzymuje rozwój. Wcześniej, gdy była to jedna kategoria, było moim zdaniem lepiej. Teraz łączenie tego przy wartościach jednostkowych nie byłoby dobre, ale można by było zrobić ewentualnie tak, aby spełnienie jednego warunku dawało 1/2 szybkości rozwoju.  

Co do domyślnych ustawień:

(08-12-2017, 04:47)McZapkie napisał(a): poniżej 10000 oprócz przekroczenia tych progów, szybkość wzrostu zależy od ilości pasażerów i poczty

-Nie wiem czy ma to jakikolwiek wpływ, bo domyślne wymagania są tak niskie, że bylejaka komunikacja wypełnia normę w 10 000%. Miasto liczące 40 000 mieszkańców wymaga dostarczenia 80 pasażerów i tyle samo poczty - to raczej powinno być coś na poziomie 2000 i 300
-Wymagania dla pasażerów i poczty są na tym samym poziomie - powinny zawierać albo stały mnożnik między sobą: coś między 6 a 7, albo powinny osobno odnosić się do produkcji miasta zamiast populacji, wtedy 20% jako wartość domyślna, w przypadku miasta z 40k mieszkańców będzie oznaczało wymóg transportu ok. 2500 i 350.
-Tytuł ustawienia dla passmail'ów i wartość wymaga zmiany - obecnie 10 oznacza de facto 0,5% od wartości liczebności populacji

(08-12-2017, 04:47)McZapkie napisał(a): poniżej 20000 jw. ale szybkość zależy też (z większą wagą) od ilości dóbr konsumpcyjnych  
powyżej: j.w. ale z większa wagą również od surowców i środków produkcji.

-Wymagania dla dostawy dóbr i surowców także są na śmiesznie niskim poziomie
-Trzeba wielokrotnie przekroczyć wymagany pułap dostaw, aby miasto rozwijało się szybko
-Domyślne liczenie dostaw co 7 dni wymaga spamowania pojazdami
-Dostawy wielu z edit: niemal wszystkich surowców nie są liczone w ostatniej z kategorii. M.in. zboża, buraków, śmieci, piasku, kamieni, ropy, metalu itd.


Co myślisz o tym, aby każda z kategorii miała swój oddzielny (ustawialny) wpływ na rozwój? Smile

P - mnożnik wpływu dostaw pasażerów
M - mnożnik wpływu dostaw poczty
F - mnożnik wpływu dostaw żywności
G - mnożnik wpływu dostaw towarów
B - mnożnik wpływu dostaw materiałów budowlanych
R - mnożnik wpływu dostaw surowców przemysłowych
S - mnożnik wpływu dostaw produktów przemysłowych

p,m,f,g,b,r,s - wynik dostaw (x ≥ 100% = 1 - dostawy większe niż wymagane nie przyśpieszałyby wzrostu)

X - mnożnik tempa wzrostu miasta (0,2 - nie rośnie; 1 - rośnie z maksymalną szybkością)


Np. jeśli miasto ma:
25-1000 - wpływ na jego rozwój ma jedynie transport pasażerów i poczty
Pp+Mm / P+M = X
1000-5000 - dochodzą kolejne kategorie, równoważne z pocztą i pasażerami lub nie w zależności od ustawień
Pp+Mm+Ff+Gg+Bb / P+M+F+G+B = X
5000-...
Pp+Mm+Ff+Gg+Bb+Rr+Ss / P+M+F+G+B+R+S = X

(05-12-2017, 03:27)McZapkie napisał(a): Co do kolejności kategorii, to próbowałem ale niezbyt to działa.

Przy takim układzie jaki udało ci się zrobić, to już nie będzie wcale potrzebneSmile Co najwyżej można by było dać jakieś inne kolory kategorii - tak sobie marudzę.

(05-12-2017, 03:27)McZapkie napisał(a): Niestety nie ma opcji aby wydłużyć subsydium, 12 miesięcy jest zakodowane na twardo.

No to klops.Sad Te 12 miesięcy coś jeszcze może znaczą z JGR'em, ale w zwykłej grze szkoda zachodu.

(05-12-2017, 03:27)McZapkie napisał(a): Co do wzrostu drzew - chyba tylko przez zmianę ustawień, ale nie wiem jak to działa, podobnie jak odczyt ustawień.

Szczerze powiedziawszy, możliwość spowolnienia/zamrożenia wzrostu drzew obok modyfikacji oceny stacji tak, aby liczone były połączenia i czegoś co mogłoby nazywać się "Shipping lane.grf" to ficzery, których chyba najbardziej mi brakuje w tej grze Smiley62 .

(05-12-2017, 03:27)McZapkie napisał(a): EDIT: wolałbym ogólne kategorie, niż rozbijanie na drobne, z tego powodu że:
1. chciałbym by skrypt działał w możliwie każdej ekonomii, ogólna kategoria zabezpiecza szerokie spektrum towarów
2. przy podejściu "impulsowym", logiczne jest, że opłaca się jak najwięcej różnorodnych towarów pchać, bo w lepszym stopniu zabezpiecza to ciągłość całkowitych dostaw powyżej progu.

1. Ale z większą ilością kategorii skrypt byłby bardziej kolorowyWink Poza tym nie lubię marnować żywności, a w grze prawie nikt się nią nie zajmuje.Sad Te dodatkowe kategorie można opcjonalnie połączyć, tak jak to jest np. w skrypcie RCG.
2. To marne podejście i jeśli znalazłbyś sposób aby to zastąpić "ubytkiem" albo "średnią", byłoby o wiele lepiej. Co daje częste odświeżanie, poza pogarszaniem czytelności, napisałem wyżej.

(05-12-2017, 03:27)McZapkie napisał(a): EDIT: co zamiast %? Tony? A co ze skrzynkami które ważą pół tony albo licho wie ile sobie ktoś umyślił?

Nic. Inne skrypty mają podane "ilość dostarczona/ilość wymagana" i nic więcej, i to w zupełności wystarcza - bardzo łatwo można się domyślić o co chodzi. Units / jednostek brzmi strasznie technicznie i jest zwyczajnie zbędne.
#16
Trochę jesteś niekonsekwentny, raz narzekasz na za wysokie progi, a raz za niskie (a można je sobie zmieniać).
Fakt, że próg dla pasażerów <2500 można sobie darować, zamiast tego brać ilość pasażerów i poczty jako szybkość wzrostu miasta. ale oddzielny próg dla poczty i pasażerów jest pożądany z 2 powodów:
1. aby nie dało się rozwijać miasta samymi pasażerami/pocztą
2. aby dało się łatwo zatrzymać rozwój miasta w celu np. przebudowy stacji.

Ps. zauważyłem sporego buga, niektórej wielkości miasta nie rosną.
#17
(09-12-2017, 18:33)McZapkie napisał(a): Trochę jesteś niekonsekwentny, raz narzekasz na za wysokie progi, a raz za niskie (a można je sobie zmieniać).

Wymagana ilość obsługiwanych przedsiębiorstw, która była bezsensownie duża a wymagana ilość dostarczanych ładunków do miasta, która jest bezsensownie mała to kompletnie różne rzeczy, więc gdzie tu niekonsekwencja?
Nie wkurzałyby cię dodatki, których domyślne ustawienia są dobrane z przypadku i psują balans gry? Na dokładkę te wartości jak i tytuły w panelu ustawień kłócą się z tym co widać w trakcie gry, przez co samodzielne ustalenie właściwych wartości jest męczące i czasochłonne.


(09-12-2017, 18:33)McZapkie napisał(a): oddzielny próg dla poczty i pasażerów jest pożądany z 2 powodów:
1. aby nie dało się rozwijać miasta samymi pasażerami/pocztą
2. aby dało się łatwo zatrzymać rozwój miasta w celu np. przebudowy stacji.

1. Do tego masz jeszcze żywność, towary, materiały budowlane itd. One podobnie jak pasażerowie i poczta (oddzielnie lub razem) mogą być wymagane od samego początku jako jeden z 4,5,6,7.. elementów wpływających na rozwój miasta w równym stopniu lub odpowiednio wyższym/niższym - wymóg dostarczania różnorodnych towarów jest o wiele ciekawszy niż budowa kuriozalnej, jak na wielkość miasteczka, liczby przystanków (zawsze 6), aby rosło szybko. Ocenę dostaw wszystkich kategorii (każda ograniczona do 100% / 1,00 bez względu na nadmiar dostaw) sumujesz, dzielisz przez ilość kategorii i masz współczynnik dla tempa rozwoju miasta. Poniżej pewnej wartości tego współczynnika miasto nie rośnie.
1'. Rozwijanie miasta samą pocztą i pasażerami jest ułomnie proste, zwłaszcza przy tych domyślnych ustawieniach, i zwyczajnie nudne.
2. Naprawdę problem z sufitu, aż ręce opadają. Smiley26  Blinksmiley  A jaki to niby wielki problem wykupić teren pod budowę tej stacji, że aż trzeba wstrzymywać rozwój całego miasta na ten czas??? A co jeśli inni gracze nie mają zamiaru wstrzymywać z tego powodu swoich połączeń? A co jeśli JGR pod twoją nieobecność przebuduje sobie jedyną drogę, którą dostarczałeś pocztę do miasta?


(09-12-2017, 18:33)McZapkie napisał(a): Ps. zauważyłem sporego buga, niektórej wielkości miasta nie rosną.

Z tego co ja zauważyłem, blokuje się obliczanie dostaw "impulsowych" liczonych co określony czas - dostawy żywności, które są liczone co miesiąc działają ok.

[Obrazek: 486TGAL_bug_rozwoju.png]

[Obrazek: 469TGAL_bug_rozwoju_2.png]

Inny istotny bug jest z liczeniem dostaw surowców i produktów przemysłowych. Z tego co zauważyłem jedynie węgiel, ryby, zboże i żywiec są brane pod uwagę, dostawy całej reszty ładunków skrypt nie widzi.
#18
Nowa wersja 9 na serwerze i bananach. Wrzucam na banany, aby przekryć te poprzednie mocno zbugowane. Wiem że nie powinienem tego był wrzucać, ale jak już zrobiłem to niech będzie wersja działająca w miarę niż zupełnie.

Reguły wzrostu są następujące:
<25 samo rośnie
<250 rośnie standardowo
<2500 rośnie zależnie od ilości pass+mail
<5000 j.w. z minimalnym progiem oddzielnym dla pass i mail
<10000 j.w. z dużą wagą towarów
>10000 j.w. z dużą wagą środków produkcji

Próg pass/mail jest moim zdaniem bardzo dobrym pomysłem, raz że nie nie rozwinie się większego miasta wyłącznie pasażerami,
dwa że pozwala na zablokowanie rozwoju przy jednoczesnym ruchu pasażerskim, nie tylko na potrzeby przebudowy,
ale również gdy się ma ustalone przepływy pasażerów i nie chce się tego zmieniać.
Argumenty o innym graczu dostarczającym pocztę są wydumane, piszę to co piszę, bo testuję to na serwerze.
Tak samo odnośnie subsydiów - nie wiem czy one coś pomagają, zobaczy się gdy się porówna wyniki z i bez.


Cytat:Inny istotny bug jest z liczeniem dostaw surowców i produktów przemysłowych. Z tego co zauważyłem jedynie węgiel, ryby, zboże i żywiec są brane pod uwagę, dostawy całej reszty ładunków skrypt nie widzi.
Nie wiem czy to bug, czy feature, w założeniu nie miały to być wszystkie ładunki, tylko wybrane: środki produkcji oraz surowce energetyczne i żywnościowe, w miarę uniwersalna i obejmująca większość setów przemysłowych.

Obecnie są to:
COAL, _OIL, ENSP, MNSP, FMSP, VEHI, PAPR, STEL, COPR, GRAI, CERE, WHEA, MAIZ, LVST, FISH, FRUT, YETI,
a dobra konsumpcyjne to:
FOOD, GOOD, BEER, WATR, PETR, BDMT, GOLD, VALU, DIAM.
Jeśli któreś z powyższych nie działa, daj znać.
W skrypcie jest takie nieużywane okienko z "gazetką",  możę tam te informacje umieścić?
#19
(11-12-2017, 15:21)McZapkie napisał(a): Nowa wersja 9 na serwerze i bananach...

Relax - jak to zwykł mawiać pewien chorwacki dentysta przed wyrwaniem zęba - tragedii nie ma.Wink W grach nowa wersja zastępuje poprzednią. Przynajmniej tym razem. Może zaznacz w opisie przy kolejnej aktualizacji, że jest to jeszcze wersja testowa skryptu? Jak ktoś pobierze i wyjdą jakieś błędy, to przynajmniej się nie zrazi do niego.

Tym razem wymóg ogranicza się do jednej dodatkowej kategorii poza pocztą i pasażerami - albo dobra konsumenckie albo surowce. I tym razem brak dostaw blokuje rozwój.
Dla mnie to jest krok wstecz - im więcej kategorii, tym jest ciekawiej.

Mnożnik poczta/pasażerowie - dobrze, że go dałeś, ale te 1:3 nie sprawdzi się, gdy ktoś będzie chciał podnieść ten domyślny, nadal dość symboliczny wymóg. To powinno być 1:6 lub 1:7 - taka jest różnica w ilościach obu "towarów" jakie produkują miasta, albo może to być wartość od procentu tej produkcji miasta.

(11-12-2017, 15:21)McZapkie napisał(a): Reguły wzrostu są następujące:
<25 samo rośnie
<250 rośnie standardowo
<2500 rośnie zależnie od ilości pass+mail
<5000 j.w. z minimalnym progiem oddzielnym dla pass i mail
<10000 j.w. z dużą wagą towarów
>10000 j.w. z dużą wagą środków produkcji

[Obrazek: 590TGAL_x_paspaxpaspax_et.png]

Ten wymóg dostaw pasażerów i poczty poniżej 5000 mieszkańców lepiej sobie darować - dziwnie to wygląda: dwa razy wymagane jest to samo.

Ja bym zrobił tak:
<250 j.w.
>250 warunek pass+mail
>1000 j.w. + wpływ dostaw towarów (rozdzielnie żywność, towary i m.bud. - opcjonalnie jako jedno)
>5000 j.w. + wpływ dostaw surowce i produkty przemysłowe

W klimacie tropikalnym i arktycznym wymóg dla dostaw żywności mógłby być wyższy. Można go zwiększyć, ale za tym idą też większe dostawy dóbr a z tym jest pewien problem...

Po pierwsze: nadal wydłużenie okresu "rozliczeniowego" nie wiąże się ze zwiększeniem wymaganej ilości dostaw - nadal uważam, że ta impulsowa metoda nie jest najlepsza, lepiej już wygląda ta, którą użyłeś dla pasażerów czy żywności. Tam przynajmniej okres nie ulega zmianie - miesiąc jest najbardziej uniwersalny.
Po drugie: ...no, nie podoba mi się ta metoda i już nie wiem po co to piszę, ale.. powiedzmy, że wymagana jest dostawa 19 jednostek, a dopiero przy dostawie grubo powyżej 1000 miasto rozwija się z maksymalną prędkością. Aby to sensownie wyglądało - jak już koniecznie chcesz zachować tą metodę - powinieneś dać chociaż jakiś mnożnik dla tej pokazywanej wartości wymaganej (x20? da to 380 zamiast 19), a w ustawieniach jakoś inaczej to nazwać (mnożnik?) - obecnie i tak ja nie widzę tutaj żadnego "procentowego" związku między ustawieniem (10) a wartością wymaganą (19 / 9063). Nagmatwane jest to okrutnie.

Małe wymagania (10) - wzrost co 15 dni
[Obrazek: 285TGAL_x_ma_e_wymagania_.png]
Duże wymagania (100) - wzrost co 29 dni
[Obrazek: 932TGAL_x_du_e_wymagania_.png]
Dostawy ponad x100 większe niż wymagane - dopiero maksymalne tempo rozwoju
[Obrazek: 787TGAL_x_maksymalny_rozw.png]


(11-12-2017, 15:21)McZapkie napisał(a): Argumenty o innym graczu dostarczającym pocztę są wydumane, piszę to co piszę, bo testuję to na serwerze.

To zagraj na serwerze mapy Polski.Wink Dla mnie on jest głównym punktem odniesienia. Podobnie na singlu - z AI sobie nie pogadasz Smiley4

(11-12-2017, 15:21)McZapkie napisał(a): Próg pass/mail jest moim zdaniem bardzo dobrym pomysłem, raz że nie nie rozwinie się większego miasta wyłącznie pasażerami,
dwa że pozwala na zablokowanie rozwoju przy jednoczesnym ruchu pasażerskim, nie tylko na potrzeby przebudowy,
ale również gdy się ma ustalone przepływy pasażerów i nie chce się tego zmieniać.

Ten warunek transportu poczty prawie niczego nie utrudnia - dwa przystanki w mieście, dwie ciężarówki i temat zamknięty. Rzeczywiści może to być dobre rozwiązanie gdy chcesz wstrzymać dalszy rozwój miasta, ale jako samo warunkowanie rozwoju jest nudne. Co innego jest z żywnością, towarami, czy materiałami budowlanymi - tutaj tak prosto nie jest, a przez to jest też ciekawiej. Gdy jest więcej graczy, każdy może zająć się inną dziedziną i wspólnie rozwijać miasto(a). Tutaj też mogłaby działać blokada, chociaż... lepiej gdyby dostawy takich trudniejszych w pozyskaniu ładunków działały na zasadzie wpływu.

(11-12-2017, 15:21)McZapkie napisał(a): Tak samo odnośnie subsydiów - nie wiem czy one coś pomagają, zobaczy się gdy się porówna wyniki z i bez.

Na pewno nie zaszkodzą.Smile Ale dostrzegalnej różnicy nie będzie.

(11-12-2017, 15:21)McZapkie napisał(a):
Cytat:Inny istotny bug jest z liczeniem dostaw surowców i produktów przemysłowych.
Nie wiem czy to bug, czy feature...

Dla mnie to jest bardziej bug. Jeśli jest taka możliwość, lepiej gdybyś przypisał wszystkie ładunki obecne w grze. Inaczej będzie to takie wróżenie z fusów i "zabawa" w interpretowanie co autor miał na myśli - zrobisz rozbudowaną sieć dostaw ładunków np. do huty szkła i nic z tego nie będzie liczone. Dlaczego np. taka produkcja szkła nie może rozwijać miasta, a przetwórstwo ryb tak?
Wszystkiego nie sprawdzałem, ale nadal nie działa Ropa i Metal.

(11-12-2017, 15:21)McZapkie napisał(a): W skrypcie jest takie nieużywane okienko z "gazetką",  możę tam te informacje umieścić?

Z pewnością byłoby to przydatne. Tylko proszę cię, nie używaj takich skrótów, bo to niczego nie wyjaśni.Wink

Ps. A co z polską wersją językową? Wiesz dlaczego nie mogłem użyć polskich znaków?
#20
Cytat:Tym razem wymóg ogranicza się do jednej dodatkowej kategorii poza pocztą i pasażerami - albo dobra konsumenckie albo surowce.

Nie nie, po prostu wywalało mi jakiś błąd gdy wyświetlałem obydwie kategorie, więc pokazana jest tylko jedna, ale liczą się obydwie. Poprawię to później.

Słuszna uwaga co do progu poczty, przy ogólnym 40% progu zaczyna być problem.

Cytat:obecnie i tak ja nie widzę tutaj żadnego "procentowego" związku między ustawieniem (10) a wartością wymaganą (19)

Ustawienie jest w procentach, a 19 to ilość ton/tydzień i ona się zmienia wraz ze wzrostem miasta.

Tygodniowego dostarczania dóbr konsumpcyjnych będę bronił, bo to dobry pomysł stawiający pewne wymagania graczowi
(trzeba kombinować z autami, które wreszcie się do czegoś przydają, a nie tylko "płyną statki z bananami"),
natomiast masz rację że surowce przemysłowe  powinny mieć dłuższy okres rozliczeniowy.
Postaram się to zmienić.

Co do testowania: musisz ustawienie "wygładzania średniej" ustawić na zero, inaczej trudno dyskutować nad tym czy miasto się rozwija 15 czy 20 dni, jeśli to średnia z poprzedniej historii. Ponadto pasażerowie/poczta też się liczą, tylko z mniejszą wagą. Więc w Twoim przykładzie (dwa pierwsze) pasażerowie byli znacznie powyżej progu, co zaciemnia sytuację

Cytat:nadal nie działa Ropa i Metal.

Dziwne. Może gra rolę umiejscowienie fabryki (local authority) ?

Co do tłumaczenia, to pewnie zamieszane z kodowaniem polskich liter, zazwyczaj używam translator.openttdcoop.org który to załatwia za mnie.


Skocz do:


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