Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Cargodist dla pasażerów - taki sobie pomysł...
#1
Disclaimer: Zdaję sobie sprawę, że wątek może wyglądać na kolejny z cyklu "zbierzmy się i zróbcie" ale prosiłbym o wyrozumiałość. Niestety nie jestem w stanie ocenić, czy pomysł jest realny ani jakiego nakładu środków wymagałaby realizacja - moja wiedza programistyczna jest zbyt niska :Smile Poniższe jest czystą teorią. Jeśli tego nie da się zrobić to zamykamy temat.

OK, do rzeczy:

Jak wiadomo, największym zastrzeżeniem dotyczącym cargodist jest fakt, że faworyzuje on połączenia bezpośrednie w stosunku do rozbudowanej sieci połączeń, co stanowi niejako zaprzeczenie idei budowy systemu transportowego i realizmu. Nie patrzyłem w "bebechy" i nie wiem, jak to jest zrobione od strony kodu ale czy nie spróbować nieco innego podejścia do odwzorowania ruchu pasażerów po świecie gry. Mianowicie:

1. W momencie generowania nowego pasażera (zakładam, że jest to proces uruchamiany raz na ileś tam "tików" gry) pierwszym krokiem byłoby wylosowanie jak daleko pasażer chce jechać. Rozkład prawdopodobieństwa mógłby być konfigurowalny i przykładowo wyglądać tak: Długi dystans: 20%, Średni dystans:30%, Krótki dystans: 50%. Wynik tej operacji warunkuje kolejne. Z puntu widzenia mechaniki gry każdy pasażer byłby tym samym typem "towaru", opisywany algorytm warunkowałby tylko przypisanie mu stacji docelowej.
2. Pasażer długodystansowy szuka ("szuka" tzn. oczywiście algorytm przelicza) miejsca docelowego w odległości powyżej X kratek (parametr do skonfigurowania). Przez miejsce docelowe rozumiem obiekt (dom, przemysł), który przyjmuje pasażerów. Jeśli taki obiekt istnieje, sprawdzane jest, czy znajduje się on w zasięgu stacji gracza. Jeśli tak - generowany jest pasażer z określoną stacją docelową (analogicznie jak w cargodist). Jeśli nie - pasażer nie powstaje
2. Pasażer średniodystansowy szuka miejsca docelowego w odległości od Y do X kratek (do skonfigurowania), reszta jak wyżej.
3. Pasażer krótkodystansowy szuka miejsca w odległości poniżej Y kratek

Co daje taki algorytm? Przede wszystkim:
1. Im rozleglejsza sieć tym więcej pasażerów bo zwiększa się prawdopodobieństwo, że generowany pasażer "znajdzie" połączenie do miejsca docelowego
2. Transport lokalny nie konkuruje z długodystansowym, ponieważ pasażerowie na każdy typ trasy są generowani niezależnie
3. Większy realizm:
- preferowana będzie szeroka sieć, zamiast połączeń bezpośrednich bo kluczem będzie zapewnienie pokrycia jak największego obszaru.
- transport lokalny będzie się w końcu się wysycał (bo tylko ok. 50% pasażerów będzie "chciało" jechać na krótki dystans), zmuszając gracza do rozbudowy połączeń na większe odległości aby wykorzystać potencjał w pasażerach średnio- i -długodystansowych.

Co sądzicie? :Smile Tak, jak pisałem, nie mam pojęcia czy to jest wykonalne i jakim nakładem pracy. Chętnie poznam opinię osób, bardziej oblatanych w programowaniu Smile
#2
Taki patch był swego czasu napisany, nazywa się cargodest Smile
https://wiki.openttd.org/Passenger_and_c...stinations
Ale był trochę za bardzo realistyczny i się nie przyjął Wink
#3
(18-07-2017, 17:20)McZapkie napisał(a): Taki patch był swego czasu napisany, nazywa się cargodest Smile
https://wiki.openttd.org/Passenger_and_c...stinations
Ale był trochę za bardzo realistyczny i się nie przyjął Wink

A szkodaSad

(18-07-2017, 15:36)FrontierPharmacist napisał(a): Co sądzicie? Smile

Kierunek dobry, metoda jednak mogłaby być lepsza (duże miasta generują po kilkaset pasażerów dziennie - obliczenie celu dla każdego nowego z osobna byłoby bardzo zajmujące), ale mniejsza z tym, bo w sumie jak widać gotowe rozwiązanie już jest i się tylko kurzy. Też myślałem o zmianie w tym temacie. To jest wkurzające, że rozbudowywanie sieci połączeń zamiast podnosić zyski, zmniejsza je. Ale to jest kwestia nie tylko wyznaczania celu, ale też formy płatności - tylko za dostarczonych pasażerów do ostatecznego celu i (prawie) bez względu na długość przebytej drogi. Z tego ostatniego warunku potrafią wyjść nie małe absurdy, bo cargodist dla wyboru drogi aż nadto docenia szybkość pojazdów, jakby w ogóle nie oceniając czasu podróży, przez co na dużej mapie świata, z Gdańska do Gdyni najwięcej pasażerów będzie chciało podróżować przez... Singapur samolotem, z przesiadką, niż bezpośrednio wolnym autobusem, którym czas podróży i tak jest nieporównywalnie krótszy. Oczywiście za lot absurdalnie długą trasą nie otrzymuje się większych pieniędzy niż za transport autobusem. Moim zdaniem płatność powinna następować zawsze, bez względu czy to jest przesiadka, czy stacja docelowa. Natomiast co do odległości, płatność powinna być za jej realną długość, a jeżeli jest za długa, to ilość chętnych pasażerów powinna odpowiednio maleć, aby bardziej opłacalne było budowanie krótkich tras.

Pewnym rozwiązaniem, które miało nadawać sens budowie rozległych połączeń miał być skrypt NWD. I pomimo, że Milkowi nie udało się w 100% zrealizować założeń skryptu, to i tak w pewnym stopniu spełnia to zadanie - miasta szybciej się rozwijają, gdy mają zapewnioną zarówno komunikację miejską jak i międzymiastową (najlepiej, gdy jest to jedna sieć), zyskują też miasta, przez które przebiega jakaś trasa lub linia kolejowa z większym przepływem pasażerów. Dzięki temu budową ordynarnie prostych połączeń A-B nie da się zbytnio rozbudować miast.

Kolejnym alternatywnym pomysłem, który nie daje mi spokoju, a który być może jest całkiem realny do wykonania i również nie wymagający zmian w samej grze, jest modyfikacja samej oceny transportu pasażerów na stacjach, tak, aby głównym kryterium była ilość połączonych miast względem ilości istniejących (z uwzględnieniem ich populacji). Wtedy im bardziej rozległa sieć połączeń, im większą część populacji łączy, tym wyższa ocena stacji a tym samym większa ilość pojawiających się pasażerów - efekt moim zdaniem całkiem realistyczny. Takie rozwiązanie sprawiłoby, że transport pasażerów czy też poczty, a nawet towarów czy innych ładunków byłby o wiele ciekawszym wyzwaniem.
#4
(18-07-2017, 17:20)McZapkie napisał(a): Taki patch był swego czasu napisany, nazywa się cargodest Smile
https://wiki.openttd.org/Passenger_and_c...stinations
Ale był trochę za bardzo realistyczny i się nie przyjął Wink
Hmm... Ale ja prawdę mówiąc nie widzę, jaka jest różnica w stosunku do Cargodist, jeśli chodzi o wybór miejsca docelowego. (Routing algorithm rozumiem. Destination algorithm nie jest opisany... ). Owszem, zasady liczenia trasy są chyba inne ale suma summarum nadal izolowane połączenie A-B będzie preferowane bo wobec braku wyboru pasażerowie będą z niego korzystać (i za nie płacić), zamiast rozpływać się po odnogach i zapychać sieć transferem.
#5
(19-07-2017, 13:38)FrontierPharmacist napisał(a):
(18-07-2017, 17:20)McZapkie napisał(a): Taki patch był swego czasu napisany, nazywa się cargodest Smile
https://wiki.openttd.org/Passenger_and_c...stinations
Ale był trochę za bardzo realistyczny i się nie przyjął Wink
Hmm... Ale ja prawdę mówiąc nie widzę, jaka jest różnica w stosunku do Cargodist, jeśli chodzi o wybór miejsca docelowego. (Routing algorithm rozumiem. Destination algorithm nie jest opisany... ). Owszem, zasady liczenia trasy są chyba inne ale suma summarum nadal izolowane połączenie A-B będzie preferowane bo wobec braku wyboru pasażerowie będą z niego korzystać (i za nie płacić), zamiast rozpływać się po odnogach i zapychać sieć transferem.

No właśnie nie. W cargodist pax/towary są generowane między stacją produkującą a podlinkowaną stacją przyjmującą.
W cargodest są generowane między stacją produkującą a dowolnym *kaflem* przyjmującym.
Czyli przykładowo masz stację w mieście A połączoną ze stacją w mieście B i mieście C, cargodist rozdysponuje pasażerów między tymi stacjami,
cargodest wygeneruje również pasażerów chcących dojechać z A do przedmieść A (które są poza zasięgiem stacji A), do miasta D itp. obszarów na których nie ma komunikacji.
Inny przykład - masz linie wiozącą węgiel z kopalni w A do elektrowni B. Jeśli w mieście C istnieje elektrownia, to część węgla w A będzie wymagała przewiezienia do C i trzeba tam będzie wybudować linię, aby nie zalegał.
Po prostu hardcore.
#6
A nie chciałoby Ci się skompilować klienta z tym patchem i wrzucić na FTP? Może bym się w to pobawił ale samodzielna kompilacja jest poza moim zasięgiem... Może jest to warte przetestowaniu na experimentalu?

Jeśli faktycznie jest tak, jak piszesz to aż dziw, że to się nie przyjęło... Mnie Cargodist bardzo się podobał, póki nie zrozumiałem, że właściwie jest to trochę "pic na wodę". Tu wygląda na to, że mamy dużo lepsze rozwiązanie (przynajmniej dla pasażerów bo dla towarów to faktycznie może być cieżko...)
#7
Dla mnie to rozwiązanie wygląda słabo. Bo nie da się zrobić dojazdu do każdego budynku na mapie, a zalegający pasażerowie (czy towary) choćby zmniejszają ocenę stacji.

W dodatku można przejrzeć jak wygląda rozwój sieci na przykładzie serii CiM, gdzie pasażerowie są prawdziwi, mają swoje domy, miejsca pracy i inne cele podróży i rozwój połączeń nie odbiega znacznie od tego przy obecnym Cargodist.
#8
Cargodest to dosyć stary patch i z nowymi wersjami się nie kompiluje bez znacznych przeróbek. Niepopularność tego wynikała właśnie z tego co pisał kabexxx, plus niekompatybilność z ECS.
Patch miałby może większy sens, gdyby był przy generowaniu towaru losowany przewóz do potencjalnego odbiorcy, i tylko jeśli jest możliwy do realizacji to towar fizycznie się pojawia. Wtedy połączenie A-B wygeneruje mniejszy ruch niż np. A-B-C-D, a jednocześnie brak będzie "spamu" na stacjach.
#9
(19-07-2017, 15:26)kabexxx napisał(a): W dodatku można przejrzeć jak wygląda rozwój sieci na przykładzie serii CiM, gdzie pasażerowie są prawdziwi, mają swoje domy, miejsca pracy i inne cele podróży i rozwój połączeń nie odbiega znacznie od tego przy obecnym Cargodist.
Odbiega to tyle, że w CiM jeśli masz linię z punktu A do B a pasażer chce się dostać do C (np w drugim końcu miasta) to z Twojej linii nie skorzysta i nie zarobisz. Celem gry jest zatem mieć rozległą sieć połączeń aby obsłużyć jak największy obszar i stworzyć jak najwięcej możliwości przesiadek.

W Cargodist tak długo jak masz linię z A do B to wszyscy możliwi pasażerowie będą z tej trasy korzystać i nikomu nie przyjdzie do głowy jechać do C. Lepiej jest zatem stworzyć 2 oddzielne trasy A-B i C-D, bo wtedy na każdym etapie zarabiasz (tak długo jak nie dasz ludziom wyboru, każda stacja docelowa ich zadowoli), zamiast dawać pasażerom szansę przesiadek, bo wtedy pieniądze dostajesz tylko po dowiezieniu pasażerów na stację przeznaczenia. Nie ma to wiele wspólnego z rzeczywistością.


Cytat:Patch miałby może większy sens, gdyby był przy generowaniu towaru losowany przewóz do potencjalnego odbiorcy, i tylko jeśli jest możliwy do realizacji to towar fizycznie się pojawia. Wtedy połączenie A-B wygeneruje mniejszy ruch niż np. A-B-C-D, a jednocześnie brak będzie "spamu" na stacjach.


Właśnie coś takiego postulowałem :Smile Żeby pasażer pojawiał się dopiero, jak algorytm stwierdzi dostępność połączenia (zakładamy, że pasażer, który wie, że nie dojedzie pociągiem tam gdzie chce w ogóle nie idzie na stację a nie koczuje na dworcu aż kolej wybuduje linię)
#10
W CIM pod względem płatności jest taka różnica, ze po prostu tam pasażer płaci na początku i ma większą ofertę biletów, a tu na końcu. Uproszczenie, ale o to w OpenTTD chodzi.
Co do życia ludzi tam - no tak, ale wypadkowo działa podobnie. Na ogół nie ma wielkich eksplozji pasażerów po polepszeniu oferty z danego przystanku, ale jakieś wzrosty są i to może pojść w poczet uproszczeń w OpenTTD.
Nie rozumiem, po co macie takie ciśnienie na realizm w grze, która w ogóle go przypomina?
To kiedy będzie np. lament na kanciaste zakręty? Big Grin
#11
(20-07-2017, 09:02)kabexxx napisał(a): Nie rozumiem, po co macie takie ciśnienie na realizm w grze, która w ogóle go przypomina?
Szatan nas opętał.

Generalnie Cargodist na pewno jest krokiem naprzód w stosunku do "waniliowego" TTD - tam pasażerom było zupełnie wszystko jedno, gdzie pojadą. Idealny jednak nie jest, właśnie z powodów opisanych powyżej - rozbudowa sieci dzieli generowanych pasażerów zamiast dodawać nowych. Pewnie jakbym nie wiedział jak to działa to nadal bym się świetnie bawił Smile Ale niestety wiem i trochę czar prysł...
#12
(20-07-2017, 11:45)FrontierPharmacist napisał(a):
(20-07-2017, 09:02)kabexxx napisał(a): Nie rozumiem, po co macie takie ciśnienie na realizm w grze, która w ogóle go przypomina?
Szatan nas opętał.

Generalnie Cargodist na pewno jest krokiem naprzód w stosunku do "waniliowego" TTD - tam pasażerom było zupełnie wszystko jedno, gdzie pojadą. Idealny jednak nie jest, właśnie z powodów opisanych powyżej - rozbudowa sieci dzieli generowanych pasażerów zamiast dodawać nowych. Pewnie jakbym nie wiedział jak to działa to nadal bym się świetnie bawił Smile Ale niestety wiem i trochę czar prysł...

Tak długo jak nie będzie w OpenTTD typowych, citybuilderowych destynacji "dom->praca->dom" czy "dom->zakupy->dom" to wożenie pasażerów wciąż nie będzie zbytnio różniło się od wożenia węgla. Nawet z cargodist. 
Podróże nie maja głębszego sensu, ot, pasażerowie robią sobie wycieczki krajoznawcze.
#13
(20-07-2017, 11:45)FrontierPharmacist napisał(a): Generalnie Cargodist na pewno jest krokiem naprzód w stosunku do "waniliowego" TTD - tam pasażerom było zupełnie wszystko jedno, gdzie pojadą. Idealny jednak nie jest, właśnie z powodów opisanych powyżej - rozbudowa sieci dzieli generowanych pasażerów zamiast dodawać nowych.
To nie jest tak do końca, że lepiej jest mieć oddzielne relacje A-B C-D zamiast grafu A-B-C-D, ponieważ cargodist dzięki ruchowi lokalnemu pozwala na podniesienie oceny stacji i uniknięcie strat wskutek długiego oczekiwania na pasażerów.

Co do cargodest, to postaram się to skompilować po wakacjach i przetestować. W sierpniu wyłączam serwer bo wyjeżdżam oglądać zaćmienie słońca.
#14
Jeju, tak OpenTTD działa i ma działać. Z wybrokatowanym CargoDistem nie będzie to ta sama gra, poza tym to nie jest symulator realizmu. O to chodzi, że pasażerowie mają być wożeni tak a nie inaczej. Zresztą, gdyby tak zrobić, jak w grach typu CiM, to OTTD musiałby zabierać dobry gigabajt czy dwa RAM-u podczas gry.

Aha, i
Cytat:preferowana będzie szeroka sieć, zamiast połączeń bezpośrednich bo kluczem będzie zapewnienie pokrycia jak największego obszaru.
W realnym świecie SĄ preferowane połączenia bezpośrednie. Dlatego w komunikacji miejskiej jest dużo relacji skrętnych czy podróżni na pół kraju wolą sobie wykombinować jazdę pociągiem wykonującym nawet 1-2 kursy na dobę, niż się ciągle przesiadać.

Dlatego przewiduję, że to zły pomysł.
1. Macie złe pojęcie realizmu
2. Potworki mające "zwiększyć realizm" to ni pies, ni wydra.

Jak z ECS czy FIRS-em, jaki to realizm, jak trzeba się tego uczyć godzinami?
#15
(20-07-2017, 21:18)kabexxx napisał(a): W realnym świecie SĄ preferowane połączenia bezpośrednie. Dlatego w komunikacji miejskiej jest dużo relacji skrętnych czy podróżni na pół kraju wolą sobie wykombinować jazdę pociągiem wykonującym nawet 1-2 kursy na dobę, niż się ciągle przesiadać.
Masz pod domem linię autobusową, którą można dojechać do kina. W związku z tym Ty i Twoi sąsiedzi przez całe życie jeździcie wyłącznie do kina. Dopiero jak po 5 latach ZTM dobuduje Wam kolejne linie to przekonujecie się, że można chcieć iść również do teatru i na basen (wcześniej jazda do kina spełniała 100% Waszych potrzeb transportowych" Smile

(20-07-2017, 21:18)kabexxx napisał(a): Jeju, tak OpenTTD działa i ma działać. Z wybrokatowanym CargoDistem nie będzie to ta sama gra, poza tym to nie jest symulator realizmu. O to chodzi, że pasażerowie mają być wożeni tak a nie inaczej.
Zaletą gier open source jest to, że można je (w ramach posiadanych umiejętności) dowolnie modyfikować. Jeśli Tobie obecny model odpowiada to ok. Ja mam zastrzeżenia i jak widać nie jestem odosobniony, dlatego rozmawiamy. Wpływu na rozwój oficjalnego OTTD to nie ma żadnego. Co najwyżej mogę liczyć na patcha/skrypt.
BTW - tak samo można by powiedzieć o domyślnym mechanizmie rozwoju miast - stawiasz 5 stacji, puszczasz busa i miasto rośnie jak szalone- tak działa OTTD. Dlatego właśnie powstały rozmaite skrypty.

(20-07-2017, 21:18)kabexxx napisał(a): 2. Potworki mające "zwiększyć realizm" to ni pies, ni wydra.
Jak z ECS czy FIRS-em, jaki to realizm, jak trzeba się tego uczyć godzinami?
Dlatego są one opcjonalne. Nie musisz z nich korzystać.
#16
Róbta se co chceta.
Tylko nie wkładaj mi w usta tego, czego nie powiedziałem.

A nie ja gadam rzeczy typy "krok do tyłu naprzód" w kontekście Cargodesta. Ale ty już napisałeś, że jest krokiem naprzód. Czemu najpierw wychwalasz, jakby miał być lepszy od obecnego stanu, a potem kłamiesz, że chodzi tylko o wybór?
#17
(24-07-2017, 08:02)kabexxx napisał(a): Czemu najpierw wychwalasz, jakby miał być lepszy od obecnego stanu, a potem kłamiesz, że chodzi tylko o wybór?
Noo, powiem Ci, Bracie, że chyba wykryłeś grubą aferę. Z tego może być skandal na pół Europy. Już widzę te jutrzejsze nagłówki "FrontierPharmacist kłamał w sprawie cargodest". W to mogą być zamieszane osoby w najwyższych kręgach władzy. Myślę, że możemy się spodziewać kolejnej komisji śledczej Smile
#18
(24-07-2017, 08:02)kabexxx napisał(a): Róbta se co chceta.
Tylko nie wkładaj mi w usta tego, czego nie powiedziałem.
A nie ja gadam rzeczy typy "krok do tyłu naprzód" w kontekście Cargodesta. Ale ty już napisałeś, że jest krokiem naprzód. Czemu najpierw wychwalasz, jakby miał być lepszy od obecnego stanu, a potem kłamiesz, że chodzi tylko o wybór?

Czytam to już chyba dziesiąty raz, analizuję i za chiny nie rozumiem o co ci chodzi.  Smiley13
Zdaje mi się, że znowu piszesz, mondrujesz się na jakieś tematy mikolskich "relacji skrętnych" - cokolwiek to znaczy - a tak na dobrą sprawę chyba w ogóle nie wiesz w czym rzecz.

Jeszcze raz pisząc w skrócie: To jak obecnie dzieli pasażerów czy inne ładunki cargodist, dla każdego bardziej spostrzegawczego gracza jest demotywujące, bo im bardziej rozbudujesz swoją sieć połączeń, tym mniejsze będziesz generował dochody. To nie jest uproszczenie, tylko absurd, z którym warto by było coś zrobić. Co do twoich preferencji, martwić się raczej nie musisz, bo nawet jeśli jakieś bardziej istotne zmiany zostałyby wprowadzone do gry, to najpewniej pojawiłyby się one jako opcja do wyboru. Zaś co do metody wyznaczania celu podróży, metoda z CIM na pewno odpada - są o wiele prostsze metody i na dobrą sprawę wcale nie trzeba by było wprowadzać jakichś wielkich zmian. Nie wiem nawet Zapkie, czy nie prościej by było zamiast kompilować Cargodest'a, wprowadzić te kilka zmian?

A wracając jeszcze do alternatywnych metod; jest w ogóle możliwe bez modyfikowania gry, aby ocena stacji była zależna od ilości połączeń / ilości połączonych miast???
#19
(25-07-2017, 01:24)LaChupacabra napisał(a): A wracając jeszcze do alternatywnych metod; jest w ogóle możliwe bez modyfikowania gry, aby ocena stacji była zależna od ilości połączeń / ilości połączonych miast???
Bez patcha to niemożliwe, z poziomu newgrf mozna definiować tylko wpływ takich eventów jak prędkość/wiek pojazdów, ilość towaru, czas od ostatniej wizyty pojazdu itp, i definiuje się to dla towaru a nie stacji.

Odnośnie pomysłu na ulepszenie cargodist, to wpadłem na takie coś, aby zamiast tworzyć destynacje między kaflami gry jak w cargodest (co generowało mnóstwo połączeń i zapychało procesor), po prostu generować próby połączenia między daną stacją a losowo wybraną inną stacją (akceptującą dany towar). Jeśli dane połączenie jest możliwe, to zostanie zrealizowane, jeśli nie, to towar będzie zalegał na stacji.

W ten sposób, gdy są tylko dwie stacje A-B, to działa to dokładnie jak standardowy openttd. Ale jak są oddzielone od siebie dwie pary A-B i C-D, to część towaru z A będzie chciała jechać do D, co jest niemożliwe, więc będzie zalegać (albo opcjonalnie będzie usuwana) - w każdym razie obniży to produkcję towaru w A.
#20
(28-07-2017, 13:57)McZapkie napisał(a): Odnośnie pomysłu na ulepszenie cargodist, to wpadłem na takie coś, aby zamiast tworzyć destynacje między kaflami gry jak w cargodest (co generowało mnóstwo połączeń i zapychało procesor), po prostu generować próby połączenia między daną stacją a losowo wybraną inną stacją (akceptującą dany towar). Jeśli dane połączenie jest możliwe, to zostanie zrealizowane, jeśli nie, to towar będzie zalegał na stacji.

W ten sposób, gdy są tylko dwie stacje A-B, to działa to dokładnie jak standardowy openttd. Ale jak są oddzielone od siebie dwie pary A-B i C-D, to część towaru z A będzie chciała jechać do D, co jest niemożliwe, więc będzie zalegać (albo opcjonalnie będzie usuwana) - w każdym razie obniży to produkcję towaru w A.
Ale tu dalej mamy problem, że więcej stacji = podział towaru = mniejsze zyski. Ponadto zablokuje to możliwość budowy w różnych częściach mapy na raz - jeśli będziesz miał np. izolowaną trasę kopalnia-> elektrownia to utworzenie drugiej takiej izolowanej trasy w drugim końcu mapy spowoduje podzielenie towaru w obu kopalniach - trochę bez sensu.

Może jeśli nie kafel to szukajmy "nadawców" i "odbiorców" na liście przemysłów/miast - być może będzie to szybsze? Dla towarów to by chyba wystarczyło. Dla pasażerów można by w pierwszej kolejności wylosować miasto a w drugiej (jeśli w pierwszym etapie uda się wyszukać podłączone miasto) wylosować już konkretny budynek - nie znam się ale na chłopski rozum wydaje mi się to szybsze niż skanowanie całej mapy w poszukiwaniu kafla, który przyjmuje konkretne cargo.

Nadal uważam też, że towar lub pasażer, który nie znalazł drogi do miejsca przeznaczenia powinien w ogóle nie powstawać - tylko wtedy zapobiegniemy dzieleniu i sprawimy, że większa sieć = więcej chętnych.


Skocz do:


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