Ponieważ OGNF pozwala na wprowadzenie nowego rodzaju ruchu (póki co nazwanego "custom"), chciałem zapytać jaki on powinien być. Przypominam, że do tej pory, dostępne są następujące rodzaje ruchu:
* 1 Tracked,
* 2 Half Tracked,
* 3 Wheeled,
* 4 Leg,
* 5 Towed,
* 6 Air,
* 7 Deep Naval,
* 8 Coastal,
* 9 All Terrain,
* 10 Amphibious,
* 11 Naval,
* 12 Mountain (Leg)
Zastanawiając się jaki mógłby być ten trzynasty wymyśliłem dwie propozycje:
a) Alpine - dla komandosów - mogliby wchodzić na niedostępne dotąd heksy "Escarpement" (urwisko)
b) Hovering - poduszkowiec - mógłby poruszać się bez ograniczeń po wodzie i dowolnym płaskim terenie, ale bez wzgórz i gór.
Wadą pierwszego jest jego minimalne wykorzystanie (niewiele map ma heksy urwiska)
Wadą drugiego - dostępność tylko dla współczesnych jednostek.
Jakieś głosy - lub inne propozycje?
* 7 Deep Naval,
* 8 Coastal,
* 10 Amphibious
Tych trzech rodzajów ruchu to chyba nie było w starych formatach?
Domyślam się, że ten 13 rodzaj ruchu zdefiniujesz w efilu w lokalnych plikach konfiguracyjnych.
Nie wiem, jak Luis podejdzie do nowej wersji plików pozwalających stworzyć narodowe wersje gry, czy na przykład lokalne pliki rekonfiguracyjne w EFILU , będą mogły istnieć w dwóch wersjach językowych (do opcjonalnego wyboru). Jeżeli będzie tak jak do tej pory, czyli będą tylko w jednej wersji, to wydaje się, że wskazane byłoby używać w Efilu polskich nazw, czyli np: "alpejski" "poduszkowy" itp.
Niestety, takie postępowanie ma wady i zalety. Umożliwi poprawne funkcjonowanie spolszczenia, ale nie będzie pasowało dla tych którzy zechcą grać w wersji anglojęzycznej i na odwrót jeżeli w efilu użyjesz nazw angielskich.
CytatTych trzech rodzajów ruchu to chyba nie było w starych formatach?
Całe zycie były... Jeszcze nawet w PG2 :)
Cytat: Gustlik w Wrzesień 22, 2012, 01:11:27 AM
Jakieś głosy - lub inne propozycje?
Może: po śniegu?
Mnie podoba się Alpine ale jak napisałeś - wada mało terenów z heksami "Escarpement" (urwisko).
Rozumiem, że nie da się np. połączyć właściwość Alpine z ułatwieniami w poruszaniu się po śniegu?
Podoba mi się pomysł Gustlika z tym Alpine, ale pomysł z tym poruszaniem się po śniegu jest też ciekawy. Moje subiektywne odczucie jest takie że jednostki takie jak narciarze nie wyróżniają się jeżeli chodzi o prędkość poruszania w zimie.
CytatMoże: po śniegu?
W GRZE NIE MA TRERENU: "SNOW" (śnieg). Do tej pory śnieg był tworzony sztucznie, na mapach zimowych wstawiano teren SAND (piach), a nazwy heksów zmieniano na SNOW, ale w istocie był to teren SAND. W tej sytuacji narciarze równie dobrze spisywaliby się....w Afryce.
Wiem. Nie miałem na myśli terenu typu SAND, a zachowanie po opadach śniegu.
Choć zdaję sobie sprawę, że Movement dotyczy jedynie typów terenu.
Słuchajcie, słuchajcie, słuchajcie!!!
:bullhorn :bullhorn :bullhorn
Właśnie otrzymałem maila od Luisa, który stwierdza co następuje:
Okazało się, że jest miejsce ZARÓWNO na nowy ruch jak i na nowy teren.
Czyli można zdefiniować teren "Snow" i ruch "Ski"
Jest tylko jeden problem - z uwagi na ograniczenia gry - ten ruch musi się
na razie nazywać "Custom", niezależnie od tego, co miałby naprawdę oznaczać.
I druga sprawa - jak pisał derwiszx - ruch jednostek niekolejowych po heksach
z torami nie musi być zdefiniowany tak samo jak po drodze. tory mogą mieć osobne
wartości ruchu dla pojazdów i ludzi.
Tylko w sytuacji, gdy na tym samym heksie są tory i droga - jednostki niekolejowe,
będą się poruszać jak po drodze.
I
Cytatdruga sprawa - jak pisał derwiszx - ruch jednostek niekolejowych po heksach
z torami nie musi być zdefiniowany tak samo jak po drodze. tory mogą mieć osobne
wartości ruchu dla pojazdów i ludzi.
Cieszy mnie to bardzo. Podejrzewałem, że taka mozliwość istnieje przy wykorzystaniu lokalnych plików z katalogu Efila redefiniujących wybrane koszty ruchu.
Dzięki takiej modyfikacji ruch kolejowy zyska na znaczeniu, zwłaszcza gdy kolej będzie przebiegać w trudnym terenie i obok nie będzie jakiejś alternatywnej autostrady.
Na razie musze sobie poradzić z modyfikacja TERRAIN.TXT, bo się przesunęły linie i się wszystko rozjechało... Kaszana....
OK - opanowałem sytuację. Jest tam jednak jedna zagwozdka - ten nowy rodzaj terenu musi iść "poprzez" STRINGS_EFILE, którego ja dotąd nie używałem.... W przeciwnym razie będzie się wyświetlał jako: "CUSTOM"
Masz na myśli Strings_Efile.txt z katalogu Efila? Obejrzyj sobie analogiczny plik z Efila Composite. Nie musisz mogyfikować wszystkich sekcji.
Dobrze by było, żeby modyfikowane sekcje były spolonizowane według wzoru ze spolszczenia.
Tak - już to mam i nawet działa.
No cóż - jutro sie zajmę określaniem ruchu, bo akurat mam "wolną" niedzielę. Choć dłubanie w takich plikach przypomina mi zabawy domorosłego chemika. Mam nadzieję, że nie wysadzę wszystkiego w powietrze....
Oj tam, nie będzie źle, to tylko stringi :P.
Jak już zrobisz te modyfikacje to je potestuję.
Chwilkę sobie pograłem pierwszy scenariusz testowej - tam gdzie pod Zamościem masz pociągi i musze powiedzieć, że jest różnica, nawet bez zmiany parametrów ruchu.
Twoje obserwacje mogły wynikać z tego, że na starych mapach, niektórzy autorzy traktowali linie kolejowe jak drogi przez co, po dodaniu teraz torów, heksy takie uzyskały podwójną wartość: rail+roads.
Nauczka jaką dostałem jest taka, że trzeba bezwzględnie usuwać drogi z map gdzie użyto ich zastępczo w linii torów.
Co innego gdy heks ma rzeczywiście narysowaną drogę obok torów.
Jak sobie wrzucisz pierwszy scenariusz testowej, to tam jest to łatwo zaobserwować, dlatego, że na prawo od Zamościa drogi i tory leżą równolegle, ale o heks od siebie, więc wystarczy wziąć z Zamościa dwa bataliony Wehrmachtu na rowerach (mov. wheeled) i urządzić im wyścigi. Jedni po torach - ale na rowerach, drudzy powyżej nich - po drodze. Różnica będzie wyraźna.
A to śnieg nie jest teraz jako odmiana każdego terenu? Po co dodatkowy teren śnieg?
Nie - dotąd nie było takiego terenu.
Trochę eksperymentowałem na tym pierwszym scenariuszu.
Rzeczywiście, artylerię z zaprzęgiem konnym opłacało się wrzucić na pociąg. Ale mając do wyboru artylerię core i aux (położoną nieco bliżej Hrubieszowa) dysponujące lepszym transportem (półgąsienicowym) z pobieżnych obliczeń wyszło mi, że teoretycznie ekonomiczniej jest wysłać jednostkę takiej artylerii przy pomocy ich własnego transportu. I nawet nie trzeba w tym wypadku korzystać z torów, czy tez położonej równolegle do nich drogi. Można skorzystać ze "scieżki " położonej na otwartym terenie (clear). A wąskie gardło kolei, o którym również wspominałem i tak ogranicza realne zastosowanie tego środka transportu do jednej jednostki (pozostałe prawdopodobnie dotrą za późno). Na pewno transport "kolarzy" i zaprzęgów może być opłacalny, ale akurat w tym scenariuszu widzę korzystniejsze opcje odsieczy dla Hrubieszowa. Jeżeli transport koleją nie daje wyraźnego zysku czasowego (przynajmniej 1 czy 2 kolejek) to raczej zawsze wybiorę transport alternatywny, gdyż w jego trakcie taka artyleria może walczyć.
Przyznaję, że jeszcze nie zdążyłem zagrać tego scenariusza do końca. Na razie eksperymentuje na nim nowe możliwości OG :). Nie wiem jeszcze jaka taktyka będzie akurat w tym scenariuszu najkorzystniejsza. Póki co wydaje mi się, że do Hrubieszowa trzeba dostarczyć jakąś jednostkę core (chociażby po to żeby zdobywała heksy w tamtej okolicy :D. Być może, opłaci się taką jednostkę wysłać koleją, tego nie wiem ale raczej skłonny jestem wysłać odsiecz w sposób standardowy.
Raczej nie wysyłałbym auxowej artylerii (tej z zaprzęgiem a transport kolejowy właśnie tej jednostki byłby najbardziej opłacalny jeśli brać pod uwagę porównanie z transportem własnym ) ona dobrze stoi i od razu może wziąć udział w walkach
Grzebię dosyć metodycznie i sprawdzam wszystkie możliwe warianty jakie tylko przyjdą mi do głowy. Jeżeli opracujesz nowe koszty ruchu po terenie zajętym przez tory to będzie to nowy materiał do eksperymentowania :P.
CytatJak sobie wrzucisz pierwszy scenariusz testowej, to tam jest to łatwo zaobserwować, dlatego, że na prawo od Zamościa drogi i tory leżą równolegle, ale o heks od siebie, więc wystarczy wziąć z Zamościa dwa bataliony Wehrmachtu na rowerach (mov. wheeled) i urządzić im wyścigi. Jedni po torach - ale na rowerach, drudzy powyżej nich - po drodze. Różnica będzie wyraźna.
Potwierdzam. Ruch kołowy (wheeled) jest dosyc specyficzny na terenie clear ma koszt dwukrotnie wyzszy niż na drogach.
W tym przypadku linia kolejowa w większości biegnie po terenie clear i prawdopodobnie stąd tak duże różnice.
Zrobiłem inny wyścig kolarzy. ;)
Jeden oddział załadowałem do pociągu, a drugi puściłem w trasę po drodze biegnącej równolegle do kolei.
Do przedostatniej stacji kolejowej obydwa oddziały dotarły równocześnie (chodzi mi nie tyle o fizyczne dotarcie do celu ale o osiągnięcie gotowości bojowej, dla transportu kolejowego ta chwila nadchodzi po doliczeniu kolejki na wyładowanie.
W tym przypadku nie było zdecydowanej korzyści z transportu kolejowego. A transport drogą miał takie zalety, ze jednostka po drodze dokonywała rozpoznania i w każdej chwili mogła włączyć się do walki.
Zapewne gdy projektowałeś ten scenariusz miałeś na uwadze, ze koleją będzie transportowana artyleria (być może ta z konnym zaprzęgiem). Na moje "oko" to Hrubieszów najbardziej oczekuje na odsiecz artyleryjską :D, jakieś inne jednostki tez by się przydały ale najbardziej dodatkowa artyleria, Z odsieczą stosunkowo szybko może przybyć recon i jakaś piechota na oplu :D, A artyleria, tak jak pisałem wydaje się, ze na transporterach dotrze w podobnym czasie jak gdyby korzystała z kolei a może nawet o kolejkę szybciej.
Ale od tego są testy, żeby takie rzeczy dokładnie sprawdzić.
Nie wiem czy to w tym wątku powinienem to pisac czy raczej w wątku poswięconym tej kampanii,
Zrobiłem dokładniejsze testy.
Artyleria AUX U34 (transporter) startująca z okolic Krynic dociera z odsieczą do Hrubieszowa w 5 turze ( w tej turze mogę oddac strzał do przeciwnika)
Piechota U17 (Opel Blitz) z okolic Zamościa jadąc trasą z obejściem rzeki pod Łabuniami a później torem również nawiązuje kontakt ogniowy pod Zamościem w 5 kolejce.
Artyleria U14 jadąc tą sama trasą co U17 zajmuje pozycję w mojej 5 kolejce i w 5 kolejce może wspierać przed atakami AI, pierwszy strzał do celu odda w 6 kolejce.
Pociąg z artylerią U4 (tą z zaprzęgiem) dociera do końcowej stacji w 5 kolejce, w 6 kolejce rozładowuje się z transportu, i może wspierać przed atakami AI. Pierwszy strzał do celu odda w 7 kolejce.
Z tymi alternatywnymi drogami nie byłoby tak łatwo przynajmniej dla oddziałów core spod Zamościa gdyby nie było prostego obejścia rzeki pod Łabuniami. Jakieś bagna między lasem a rzeką i już efektywność Opla i transporterów by spadła.
Inna sprawa z korpusem AUX spod Krynic, on w każdym przypadku dotrze do Zamościa przed pociągiem, chyba żeby zburzyć most w Łaszczowie i utrudnić korpusowi dostęp do linii kolejowej.
Ale czy takie utrudnienia miałyby sens? Obawiam się, że raczej nie. Odsiecz koleją i tak przybywa zbyt późno. Mogłaby przybyć nawet tak późno jak przybywa gdyby przybywała w odpowiedniej sile, ale mała przepustowość pozwala na przesłanie jedynie jednej jednostki na turę. To stanowczo zbyt mało aby uznać transport kolejowy za przydatny w tym konkretnym scenariuszu.
P.S.
Z uwagi na drogę biegnąca obok torów i dużo terenów clear w okolicach toru, kolei niewiele pomogłoby podniesienie kosztu ruchu po torach dla innych typów transportu.
CytatJeżeli opracujesz nowe koszty ruchu po terenie zajętym przez tory to będzie to nowy materiał do eksperymentowania
Sprawdziłem - niestety - nie da się. Jednostki niekolejowe na torach przyjmują koszt ruchu terenu bazowego. Dla nich tory po prostu nie istnieją. Ruch po torach można modyfikować tylko dla różnych rodzajów pociągów. Z tym że przecież nie ma pociągów typu "halftrack", czy "wheeled" - więc ta sekcja jest raczej martwa. Myślałem, że jest inaczej...
No to szkoda. W takim razie takie rzeczy można obchodzić poprzez modyfikację terenu na którym poprowadzone maja być tory.
CytatSprawdziłem - niestety - nie da się. Jednostki niekolejowe na torach przyjmują koszt ruchu terenu bazowego
Masz rację.
Pobawilem się plikami terrain.txt i strings_efile.txt (dosyć długo).
Niestety nie udało mi się redefiniować ruchu jednostek niekolejowych po heksach z torami.
Prawdopodobnie tylko Luis może tu pomóc. Po prostu tory powinny funkcjonować na tej samej zasadzie jak drogi. Naniesione na mapę powinny zmieniać teren bazowy na swój własny a nie tak jak to się dzieje obecnie przyjmować właściwości od terenu bazowego.
Cytattory powinny funkcjonować na tej samej zasadzie jak drogi. Naniesione na mapę powinny zmieniać teren bazowy na swój własny a nie tak jak to się dzieje obecnie przyjmować właściwości od terenu bazowego.
Ale dowcip polaga na tym, że one właśnie FUNKCJONUJĄ tak jak drogi, tyle, że 99% jednostek może poruszać się po drogach, a po torach - nie. Gdyby odwrócić te proporcje i 99% jednostek było kolejowych, to one też nie reagowałyby na drogi, tak jak drogowe nie reagują na tory.
Nie widać tego także i z tego powodu, że z dróg można zjechać, bo taka jest natura ruchu kołowego - a z torów nie.
Czyli wychodzi tu moja niewiedza, dot . technicznych aspektów.
Nie wiem jak powstają drogi na mapie. Czy jeżeli chcesz narysować nowa drogę musisz najpierw odpowiednio przygotować podłoże czy po prostu zaznaczasz drogę i od razu heksy pod nią zamiast swoich bazowych właściwości przyjmują własciwości terenu "droga" (chodzi mi tu o koszty ruchu).
Wyobrażałem jak to moze wyglądać z punktu widzenia programu:
jednostka poruszająca się przypisanym dla niej rodzajem ruchu ma wjechać na heks o właściwościach terenu (droga, kolej, las itp). A koszt ruchu brany jest właśnie z plików konfiguracyjnych i gdzie jest ściśle zdefiniowany przez dwa wspomniane parametry: rodzaj terenu, tryb ruchu plus trzeci parametr warunki pogodowe.
Ale pliki konfiguracyjne widzę, że koszty ruchu na drodze można redefiniować a na kolei nie da się, I że teren o nazwie Rail na mapie nie ma jednolitego(dla danego rodzaju ruchu kosztu tak jak jest to w przypadku drogi. Wprost przeciwnie, koszt ruchu na terenie Rail jest taki jak koszt ruchu na podłożu na którym położone są tory.
No ale, w sumie na razie nie muszę wiedzieć jak jest w rzeczywistości. Na razie wystarcza mi informacja, ze nie da się regulować kosztów ruchu na kolei w analogiczny sposób jak na innych rodzajach terenu.
CytatNie wiem jak powstają drogi na mapie. Czy jeżeli chcesz narysować nowa drogę musisz najpierw odpowiednio przygotować podłoże czy po prostu zaznaczasz drogę i od razu heksy pod nią zamiast swoich bazowych właściwości przyjmują własciwości terenu "droga"
Nie musisz nic przygotowywać - na dowolnym heksie zaznaczasz drogę i wartość ruchu przez taki heks liczy się jak droga
CytatAle pliki konfiguracyjne widzę, że koszty ruchu na drodze można redefiniować a na kolei nie da się,
Da się, tylko że tę modyfikację zareagują WYŁĄCZNIE JEDNOSTKI KOLEJOWE. A tych jest niewiele.
Podobnie jak na modyfikację wartości drogowych zareagują WYŁACZNIE JEDNOSTKI DROGOWE (tyle że ich jest 99,9%)
Pozorna nielogiczność wynika wyłącznie z przytłaczającej większości jednostek drogowych.
Po drogach porusza się wiele rodzajów trakcji (kołowa, gąsienicowa, piesza), a po torach tylko jedna.
Dla mnie to jest chyba zbyt skomplikowane ;)
CytatDa się, tylko że tę modyfikację zareagują WYŁĄCZNIE JEDNOSTKI KOLEJOWE. A tych jest niewiele.
Podobnie jak na modyfikację wartości drogowych zareagują WYŁACZNIE JEDNOSTKI DROGOWE (tyle że ich jest 99,9%)
Przyjmuję do wiadomości, że jest tak jak napisałeś. Ale trudno mi to pojąć. Bo z tego co piszesz to chyba wynika, ze tereny "Road" i "Rail" egzystują w tej grze na tej samej zasadzie jednak różnej od pozostałych rodzajów terenu. Dobrze kombinuję?
Jeżeli tak, to dlaczego nie mamy w tabelkach z kosztem ruchu kosztu na terenie Rail a mamy koszt na terenie Road?
Dla przykładu można porównać tabelkę kosztów dla jednostki kolejowej (pociąg) i dla jednostki drogowej (kolarze). Zrzuty ekranu w załączniku.
Mamy tam razem z innymi rodzajami terenu " teren " "when using trains" co jest trochę niekonsekwentne gdyż to jest raczej tryb ruchu (movement method) a nie rodzaj terenu. Natomiast nie mamy rodzaju terenu RAILS.
Jak na moja głowę to jest zbyt skomplikowane.
Na zdrowy rozum to wraz z wprowadzeniem ruchu kolejowego do Terrain powinien być dodany nowy teren Rails)którego na razie nie dodano) , a do movement method "train" (który istotnie jest dodany) i wszystko by było proste i jasne. I może niepotrzebny byłby rozdział jednostek na kolejowe i drogowe. Chociaż z drugiej strony, programista jakoś musiał uwzględnić fakt , że jednostki kolejowe mogą poruszać się tylko po torach i pewnie z tego faktu wynikają te wszystkie komplikacje.
W sumie to najważniejsze w tym wszystkim jest to aby można było zgodnie z upodobaniami ustawić koszt ruchu na terenie zajmowanym przez tory, tak by był on zależny od rodzaju ruchu.
I tu raczej nie masz dla mnie dobrych wieści. W w tej chwili możesz ustawić tylko koszt ruchu dla jednostek kolejowych w tym dla transportu kolejowego ("when using trains" ) natomiast koszt ruchu dla pozostałych rodzajów ruchu odpowiada kosztowi dla rodzaju podłoża na którym położono tory czyli jest zmienny w ramach tego samego rodzaju ruchu (movement method) i i tego nie da się zmienić bez ingerencji w rodzaj podłoża (trzeba by projektować nową mapę).
[załącznik usunięty przez administratora]
Cytatbez ingerencji w rodzaj podłoża (trzeba by projektować nową mapę).
No więc właśnie że nie...
W nowych formatach pliki xscn zapisują także dane mapy, więc na potrzeby jednego scenariusza, możesz dowolnie zmodyfikować heksy - ich wartości, drogi i tory - przy pomocy Suite. Oczywiście dane mapy w bazie map pozostaną
bez zmian, więc autor się nie obrazi...
Przed wczoraj kiedy przeglądałem pliki konfiguracyjne z Efila Composite natknąłem się w pliku terrain.txt na taką oto linię:
Cytat[nfv 1] required if new terrain/movement methods are defined
W nowych plikach umieszczonych w folderze sample tej linii nie znalazłem. Ale troszeczkę z nia eksperymentowałem tyle, ze robił się spory bałagan.
Dzisiaj na forum JP Panzers ktoś poruszył tę sprawę i pojawiła się odpowiedź Luisa.
http://www.panzercentral.com/forum/viewtopic.php?f=132&p=705904#p705904 (http://www.panzercentral.com/forum/viewtopic.php?f=132&p=705904#p705904)
Cytat: lguzmanNo, it is required to read rail and helo regarding movement cost table
Should be placed before first entry of terrain/movement cost table.
Czy Twoim zdaniem umieszczenie tej linii w terain.txt mogłoby w czymś pomóc?
No i dlatego o mało mi się nie wykrzaczyła gra... Ta linia jest potrzebna, żeby dodatkowe tereny i ruchy w ogóle zadziałały!
Bez tej linii wszystkie wartości ruchu są wymieszane. Też jej nie miałem - dopiero Luis mi przysłał.
W razie jakby co - dołączam do postu. To jest TERRAIN.TXT osobiście skorygowany przez Jego Magnificencję Luisa.
[załącznik usunięty przez administratora]
Teraz to działa, tylko że chyba niewiele się zmieniło jeśli chodzi o teren Rails.
Nadal takiego terenu nie ma w tabelce kosztów mimo, ze Rails pojawił się w terrain.txt a więc teoretycznie istnieje mozliwość dowolnego ustawienia kosztów ruchu po terenie Rails dla każdego rodzaju ruchu.
Cytat* Rails ....
1,1,1 *Tracked
1,1,1 *Half Tracked
1,1,1 *Wheeled
1,1,1 *Leg
1,1,1 *towed
1,1,1 *Air
255,255,255 *Deep Naval
255,255,255 *Coastal
1,1,1 *All Terrain
1,1,1 *Amphibious
255,255,255 *Naval
1,1,1 *Mountain (Leg)
1,1,1 *Rail
1,1,1 *Helo
255,255,255 *Custom
W sumie to nadal nie rozumiem dlaczego po zmodyfikowaniu kosztu ruchu po terenie rails dla ruchu kołowego na 5 nic sie nie zmienia. Kolarze nadal jeżdza po Rails przyjmujac koszt ruchu po terenie bazowym. Więc po co jest ta sekcja *Rails w pliku Terrain.txt. ?
* Rails ....
1,1,1 *Tracked
1,1,1 *Half Tracked
5,1,1 *Wheeled
1,1,1 *Leg
1,1,1 *towed
1,1,1 *Air
255,255,255 *Deep Naval
255,255,255 *Coastal
1,1,1 *All Terrain
1,1,1 *Amphibious
255,255,255 *Naval
1,1,1 *Mountain (Leg)
1,1,1 *Rail
1,1,1 *Helo
255,255,255 *Custom
EDIT
Hmm, wygląda na to, ze ta sekcja w pliku terrain.txt jest sobie a muzom. Zmiany jej parametrów nie maja żadnego wpływu na poruszanie sie po heksach oznaczonych jako teren Rails. Jedyny wyjątek stanowi linia: 1,1,1 *Rail w której możemy zdefiniować koszt ruchu dla pociągu i innych pojazdów kolejowych które mogą poruszać się jedynie po torach. Ale przecież tego akurat kosztu nie chcemy modyfikować. Bo tak jak jest jest dobrze (1,1,1).
P.S.
A może w Suite jest jakis specjalny teren "Rails" który można podłozyć tam gdzie w przyszłości będzie nałozona grafika torów? Wtedy być może ta sekcja by zadziałała i dla innych rodzajów ruchu.
Moim zdaniem, najprostszym rozwiązaniem byloby gdyby nałozenie na mapę torów automatycznie zmieniało każdy rodzaj terenu z wyłączeniem drogi na Rails.
Wtedy tam gdzie kolej krzyżuje się z droga byłyby przejazdy. A na pozostałych heksach kolejowych obowiązywałyby koszty ruchu właściwe dla Rails.
CytatHmm, wygląda na to, ze ta sekcja w pliku terrain.txt jest sobie a muzom. Zmiany jej parametrów nie maja żadnego wpływu na poruszanie sie po heksach oznaczonych jako teren Rails. Jedyny wyjątek stanowi linia: 1,1,1 *Rail
Bo tylko "Rail" może wjechać na tory.
Pisząc "tory" - mam na myśli fizycznie szyny, a nie heks z torami (czyli jazdę po podkładach)
Ale wyobraźmy sobie, że ktoś wymyśli, że "Wheeled" może korzystać z torów (notabene - były takie drezyny zrobione z "Żuka" i "Warszawy") i wtedy tabela zacznie działać w kolejnej linii. Tylko, że to trzeba by odkodować w exe.
Jak już grzebać w exe to rozsądniej byłoby po prostu stworzyc teren Rails (mam na myśli podłoże przywiązane do torów a nie tory) :P.
P.S.
Wspominałeś, że poruszałeś z Luisem ten temat. Czy on nie widzi potrzeby wprowadzenia możliwości regulacji kosztów ruchu na terenie kolei również dla innych niż kolejowy rodzajów ruchu?
Sposób zastępczy czyli dawanie jako podkładu którejś z istniejących nawierzchni na przykład lasu czy wertepów jest bardzo naciągany nie tylko z powodów leksykalnych ale głównie dlatego, ze koszty ruchu po terenie Rails miałyby całkiem odmienną statystkę dla różnych rodzajów ruchu w odróżnieniu od wymienionych rodzajów terenu. Na przykład piechurzy i czołgi mogliby po torach poruszać się jak po drodze, a rowerzyści i transport kołowy jak po wertepach a terenowy i półgąsienicowy jeszcze inaczej.