Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Inne Projekt: skrypt New World Disorder
#41
@McZapkie: tak, obecnie są tylko przedsiębiorstwa. do domów będzie zaraz

@LaChupacabra: No jest to możliwe, trochę brzydko, bo trzeba by było wyszukiwać po prostu nazwę miasta w nazwie przedsiębiorstwa, ale to jest naprawdę potrzebne? Jest jakieś sensowne zastosowanie żeby to było inne miasto niż najbliższe?
#42
(15-10-2016, 13:27)Milek7 napisał(a): @LaChupacabra: No jest to możliwe, trochę brzydko, bo trzeba by było wyszukiwać po prostu nazwę miasta w nazwie przedsiębiorstwa, ale to jest naprawdę potrzebne? Jest jakieś sensowne zastosowanie żeby to było inne miasto niż najbliższe?

Przykład na mojej mapie Polski - Zakłady chemiczne, Huta, Port stoją najbliżej Polic i to właśnie one by korzystały na takim transporcie, a nie Szczecin. Podobnie z miastami typu Łódź (i Pabianice), Poznań (i Luboń/Swarzędz). Ja budując mapę stawiałbym najpierw większe miasta, potem przedsiębiorstwa, a dopiero potem te mniejsze miasta - więc przedsiębiorstwa należałyby do większych miast. Wtedy ta funkcja w skrypcie miałaby sens.
#43
Można by tak zrobić żeby metropolie miały liczone większy mnożnik z przedsiębiorstw.
Nie lepiej było by po prostu oznaczyć te większe miasta jako metropolie?
#44
(15-10-2016, 15:51)Milek7 napisał(a): Można by tak zrobić żeby metropolie miały liczone większy mnożnik z przedsiębiorstw.
Nie lepiej było by po prostu oznaczyć te większe miasta jako metropolie?

Ale ile wtedy miast byłoby branych pod uwagę? W sensie - co jeśli wszystkie przedsiębiorstwa należą do mniejszych miast wokół? Czy opcja metropolii wtedy w ogóle będzie miała znaczenie? Skąd skrypt będzie wiedział jak daleko ma "szukać" "przynależności" do miasta? 20 kratek? 100 kratek?

Przykład - chciałbym, aby na Hucie Dąbrowa Górnicza (w rzeczywistości Huta Katowice) najbardziej korzystały Katowice. Bliżej Katowic jest chyba z 6 miast. Skąd skrypt będzie wiedział, że chodzi właśnie o Katowice?


[Obrazek: Wy7Gv2Nm.png]
#45
(15-10-2016, 17:42)pAter napisał(a): Skąd skrypt będzie wiedział jak daleko ma "szukać" "przynależności" do miasta? 20 kratek? 100 kratek?
Produkcja jest liczona w promieniu 60 kratek (można zmienić) od centrum miasta - im dalej tym mniejszy wpływ. Samo takie rozwiązanie nie byłoby najlepsze przy tego typu scenariuszach, dlatego...

(15-10-2016, 15:51)Milek7 napisał(a): Można by tak zrobić żeby metropolie miały liczone większy mnożnik z przedsiębiorstw.
Nie lepiej było by po prostu oznaczyć te większe miasta jako metropolie?
...można, ale to też nie będzie najlepsze rozwiązanie - zbyt wiele miast wokół w równym, podobnym lub niewłaściwym stopniu będzie korzystało z produkcji jednego zakładu. Przykładowo huta i papiernia Police należą do Szczecina, zaś leżą na mapie niemal w centrum Polic. W takim przypadku mnożnik dla metropolii musiałby wynosić ok. 1,5-2 bez względu na odległość aby skorygować wpływ. Takie ustawienie jednak zdecydowanie za bardzo by ułatwiało rozwój innym miastom na mapie określonym jako metropolie, zwłaszcza na górnym śląsku.
#46
Akurat tu problemem jest sam scenariusz. Jak wiele innych problemów, produkujecie sami zbyt mikolskim podejściem do strategicznych aspektów.
I takie patologiczne scenariusze jak Mapa Polski się często nie pojawiają. Więc należy go olać i zrobić to tak, by pasowało do realiów gry. A tu można zrobić to w prosty i efektywny sposób: zwykły zasięg dla zwykłych miejscowości oraz powiększony zasięg dla metropolii, ale z mniejszym mnożnikiem.
#47
(15-10-2016, 13:27)Milek7 napisał(a): No jest to możliwe, trochę brzydko, bo trzeba by było wyszukiwać po prostu nazwę miasta w nazwie przedsiębiorstwa, ale to jest naprawdę potrzebne? Jest jakieś sensowne zastosowanie żeby to było inne miasto niż najbliższe?
Chyba nie trzeba szukać nazwy miasta w nazwie fabryki, wystarczyłaby chyba funkcja GSTile.GetTownAuthority wywoływana z kafla wskazanego przez GSIndustry.GetLocation ?

Proponuję w ten sposób trzymać się tego, co robi openttd, czyli jak on przyporządkowuje fabrykę do miasta, to niech skrypt też za tym idzie,
raz że ludzie są do tego przyzwyczajeni i łatwo mogą sprawdzić która fabryka daje wkład (a nie liczyć odległość), dwa że ułatwia to życie autorom scenariuszy.

W życiu jest podobnie, np. jak jest elektrownia koło Opola ale należy administracyjnie do jakiejś wioski, to ta wioska dostaje podatki.
#48
(17-10-2016, 01:53)kabexxx napisał(a): Akurat tu problemem jest sam scenariusz. Jak wiele innych problemów, produkujecie sami zbyt mikolskim podejściem do strategicznych aspektów.
I takie patologiczne scenariusze jak Mapa Polski się często nie pojawiają. Więc należy go olać i zrobić to tak, by pasowało do realiów gry. A tu można zrobić to w prosty i efektywny sposób: zwykły zasięg dla zwykłych miejscowości oraz powiększony zasięg dla metropolii, ale z mniejszym mnożnikiem.

Po pierwsze, pomysł skryptu (a może i główna dyskusja, która pociągnęła go dalej) powstał właśnie przy tej mapie Polski, dlatego w ogóle pozwoliłem sobie zabrać głos.

Po drugie, twoje "nie-mikolskie" podejście (cokolwiek to znaczy) nie bierze pod uwagę różnych scenariuszy zdarzeń. Czym nazywasz realia gry? Twoje preferencje? Nie każdy generuje sobie mapę na domyślnych ustawieniach. W jednym przypadku miasta będą blisko siebie, po kilka przedsiębiorstw na miasto, a w drugim będą 3 miasta na dużej mapie, a rzadko rozłożone przedsiębiorstwa poza zakładanym zasięgiem w skrypcie, który jest tu planowany. Jak widzisz, podałeś wspaniały, prosty i przede wszystkim efektywny sposób, nie powiem. Oprócz tego, nie każdy gra na losowych scenariuszach - w pewnych przypadkach zakładane są określone strategie, balans, jeśli chodzi o rozłożenie miast i przedsiębiorstw. Dlatego właśnie pytałem czym ma być zasięg i podałem przykład z mojej mapy.

(17-10-2016, 13:18)McZapkie napisał(a): Proponuję w ten sposób trzymać się tego, co robi openttd, czyli jak on przyporządkowuje fabrykę do miasta, to niech skrypt też za tym idzie,
raz że ludzie są do tego przyzwyczajeni i łatwo mogą sprawdzić która fabryka daje wkład (a nie liczyć odległość), dwa że ułatwia to życie autorom scenariuszy.

Z tym się zgadzam - rozwiązuje to problemy, o których pisałem, a jednocześnie trzyma się mechaniki gry.
#49
(17-10-2016, 13:18)McZapkie napisał(a): Chyba nie trzeba szukać nazwy miasta w nazwie fabryki, wystarczyłaby chyba funkcja GSTile.GetTownAuthority wywoływana z kafla wskazanego przez GSIndustry.GetLocation ?
nie
Kod:
/* static */ TownID ScriptTile::GetTownAuthority(TileIndex tile)
{
    if (!::IsValidTile(tile)) return INVALID_TOWN;

    Town *town = ::ClosestTownFromTile(tile, _settings_game.economy.dist_local_authority);
    if (town == NULL) return INVALID_TOWN;

    return town->index;
}
#50
(17-10-2016, 19:46)Milek7 napisał(a):
(17-10-2016, 13:18)McZapkie napisał(a): Chyba nie trzeba szukać nazwy miasta w nazwie fabryki, wystarczyłaby chyba funkcja GSTile.GetTownAuthority wywoływana z kafla wskazanego przez GSIndustry.GetLocation ?
nie
Dlaczego nie? Zacytowałeś kod gry, ale nie ma znaczenia jak gra to przyporządkowuje, mi chodziło o to,
aby skrypt przyporządkowywał dokładnie tak, jak gra to robi, a nie po swojemu.
I nie ma znaczenia, czy scenariusz edytowany czy losowy, skoro w nazwie fabryki jest miasto, to użytkownik myśli, że ma ona wpływ na to miasto, a obecnie jest czasem robiony w konia, jak w moim przykładzie wyżej.
Tak przy okazji, obecnie w skrypcie w PushIndustry  jest używane GSTile.IsWithinTownInfluence, co jest chyba bez sensu, bo ta funkcja jest do sprawdzania, czy kampania reklamowa w mieście ma wpływ na stację, a nie czy przemysł jest przypisany do miasta:
http://nogo.openttd.org/api/1.6.1/classG...224ed7f22c
#51
(18-10-2016, 12:38)McZapkie napisał(a): Dlaczego nie? Zacytowałeś kod gry, ale nie ma znaczenia jak gra to przyporządkowuje, mi chodziło o to,
aby skrypt przyporządkowywał dokładnie tak, jak gra to robi, a nie po swojemu.
Miałem nadzieję że przeczytasz ten kawałek.
Wkleiłem kod metody GSTile.GetTownAuthority, bo zaproponowałeś żeby użyć jej zamiast wyszukiwania w nazwie, która wyszukuje najbliższe miasto w promieniu _settings_game.economy.dist_local_authority. Czyli nie ma to nic do przypisywania przedsiębiorstw.
(18-10-2016, 12:38)McZapkie napisał(a): Tak przy okazji, obecnie w skrypcie w PushIndustry  jest używane GSTile.IsWithinTownInfluence, co jest chyba bez sensu, bo ta funkcja jest do sprawdzania, czy kampania reklamowa w mieście ma wpływ na stację, a nie czy przemysł jest przypisany do miasta:
http://nogo.openttd.org/api/1.6.1/classG...224ed7f22c
Pewnie masz rację że to nie ma sensu, bo musiałyby być ogromne miasta mające w promiemiu ponad 60 kratek żeby to miało znaczenie, ale w działaniu znowu coś ci się pomyliło.
Kod:
/* static */ bool ScriptTown::IsWithinTownInfluence(TownID town_id, TileIndex tile)
{
    if (!IsValidTown(town_id)) return false;

    const Town *t = ::Town::Get(town_id);
    return ((uint32)GetDistanceSquareToTile(town_id, tile) <= t->cache.squared_town_zone_radius[0]);
}
Sprawdza czy dana kratka jest w zasięgu t->cache.squared_town_zone_radius[0], czyli wielkość miasta uwzględniając rozrost.
#52
Faktycznie, masz rację. No dziwnie ten skrypt zaimplementowali.
#53
(17-10-2016, 17:15)pAter napisał(a): Twoje "nie-mikolskie" podejście (cokolwiek to znaczy) nie bierze pod uwagę różnych scenariuszy zdarzeń. Czym nazywasz realia gry? Twoje preferencje? Nie każdy generuje sobie mapę na domyślnych ustawieniach. W jednym przypadku miasta będą blisko siebie, po kilka przedsiębiorstw na miasto, a w drugim będą 3 miasta na dużej mapie, a rzadko rozłożone przedsiębiorstwa poza zakładanym zasięgiem w skrypcie, który jest tu planowany. Jak widzisz, podałeś wspaniały, prosty i przede wszystkim efektywny sposób, nie powiem. Oprócz tego, nie każdy gra na losowych scenariuszach - w pewnych przypadkach zakładane są określone strategie, balans, jeśli chodzi o rozłożenie miast i przedsiębiorstw. Dlatego właśnie pytałem czym ma być zasięg i podałem przykład z mojej mapy.

W przypadku nierównomierności generowanych przez mapy OpenTTD właśnie chodzi o to, by nie wszystkie regiony miały równe szanse.
Natomiast np. w mapie Polski, chce się rozwijać (niektóre miasta są wstawione z tego powodu), bo są "wybitnie kolejowe", jak to ktoś w tamtym wątku ładnie określił. 
Nie da się zadowolić wszystkich. Jeśli tworzy się niestandardową mapę na niestandardowe zadania, to trzeba się liczyć z tym, że standardowe metody nie zadziałają. 
OpenTTD jest grą pełną uproszczeń i jeśli się chce trzymać realizmu lub, co gorsza, realizmu w pewnych aspektach, nic nie będzie ze sobą grało. Jak we wszystkich utworach kultury, w tym w grach, trzeba się trzymać pewnych konwencji w tych utworach ustalonych.
A jak nie pasuje, to utworzyć własny zestaw.

Jeśli się będzie podpasowywać dodatek pod mapę Polski, to będzie on upośledzony pod względem ogólnego zastosowania.
Wszystkie realistyczne mapy są pod pewnymi względami niestandardowe i nie da się tego dobrze odwzorować. Przecież właśnie do konkretnych krajów jest większość setów i dodatków.
A "mikolskim" podejściem nazywam to, że uznaje się te konwencje za normalne i słuszne. Fajnie, są, ale dla ciebie (mówię tu ogólnie, nie o tobie Wink ), graczu chcący odwzorować szczegóły kolejowe.
I podobne mikolskie podejścia są plagą prawie wszędzie, gdzie mikolska aktywność jest możliwa - na poważniejszych forach (o mikolskich nie mówię, chodzi mi o fora poświęconych komunikacji, miastom, pasjonatom historii, czy aktywistom, albo "ogólnych") czy nawet na Wikipedii, gdzie te tematy żyją własnym życiem, że mimo stwierdzenia niencyklopedyczności tematów np. przystanków kolejowych czy linii kolejowych, albo wciskania każdej stacji kolejowej, bo jest w teorii encyklopedyczna (a powinna mieć jeszcze inne cechy, ale nikt nad tym nie panuje), ale przecież NA PEWNO TO PRAWDA, bo z jakiejś mikolskiej bazy, albo z piątej ręki od konduktora czy zasłyszana z mikolskiego forum, i NAJWAŻNIEJSZA NA ŚWIECIE, bo mikolska.
Dobra, to nieistotne, ale przez lata kontaktów wirtualnych i realnych z mikolami, po prostu takich ludzi nienawidzę, mimo mojej wielkiej tolerancji co do naprawdę, naprawdę różnych ludzi,,,
#54
(09-11-2016, 04:31)kabexxx napisał(a): A jak nie pasuje, to...

To może stwórz swój własny skrypt, taki aby odpowiadał on tobie i tym dostrzeganym przez ciebie konwencjom. Nie wiem czy ty to dostrzegasz kabexxx, ale masz wyjątkowo pretensjonalne podejście. Nie mówię, że w niczym nie masz racji, bo w wielu kwestiach się z tobą zgadzam, ale pisząc takie rzeczy właściwie zamykasz pole do jakiejkolwiek dyskusji. Sam nie wiem czy jest sens tobie pisać argumentami, jeżeli mam później czytać, że są żałosne, absurdalne, a tak w ogóle to piszę same bzdury. Spróbuję...
Co do tych uproszczeń w OTTD zgadzam się z tobą, że nie ma sensu w zaparte dążyć do jak największego realizmu zwłaszcza w jednym elemencie, bo to jest najprostsza droga do katastrofy. Przykładem tego jak zgubne może być takie dążenie są chociażby wczesne ciężarówki w Polroad'zie, które przez swoją realistyczną, niedorzecznie małą ładowność jak na warunki gry stały się kompletnie bezużyteczne. Przykładów można mnożyć bo jest ich trochę wśród dodatków.
Co do sposobu liczenia produkcji w skrypcie, aby przedsiębiorstwa były przypisywane do miast, nie jest to już usilne dążenie na ślepo do "realizmu" lecz chęć poprawienia pewnego elementu, który w przypadku mapy Polski mógłby doprowadzać do pewnych paradoksów. Dodanie warunku "metropolii" też jest jakimś rozwiązaniem, w sumie nie najgorszym i całkiem uniwersalnym, jednak wolałbym to z "przypisem" gdyż daje większą możliwość ustalania, które miasto może bardziej, a które mniej rosnąć - byłoby to przydatne nie tylko w przypadku tego scenariusza.
Jeszcze co do samej mapy Polski... Nie pAter, pomysł skryptu nie powstał w temacie twojej mapy, to co przedstawiłem wtedy to była już któraś z kolei koncepcja tego skryptuWink Ale fakt faktem była i jest ona jednak jedną z głównych inspiracji dla jego powstania, więc... kabexxx, nawet nie marz o tym, że ją zignoruję. Nie znaczy to jednak, że dostosowanie do jednego scenariusza, przedkładam ponad uniwersalność skryptu. Masz uwagi, ciekawe koncepcje? Pisz, ale proszę cię argumentami, nie złością.
#55
Jeszcze raz napiszę najprościej jak się da, bo niektórzy mają problemy z czytaniem: według mnie lepiej byłoby przynależność przedsiębiorstw do miast ustalać tak samo jak to działa w mechanice gry (zgodnie z nazwą miasta w nazwie przedsiębiorstwa), niż na podstawie zasięgu, ponieważ w losowych scenariuszach zasięgi mogą nie obejmować miast (innymi słowy: zasięgi nie będą uniwersalne).

Mapa Polski to tylko taki dodatkowy przykład - problem, który można by było banalnie rozwiązać za pomocą pierwszej metody. Jednocześnie rozwiązałby się problem nieobejmujących zasięgów.

Ale oczywiście troll musi przyjść i się dopieprzyć dla samego flame'u. Do tego posty "tl;dr", które nie wnoszą nic do tematu, zero propozycji, sama krytyka i obrażanie użytkowników.

[Obrazek: kwD8nHim.png] [Obrazek: R35yEb8m.png]

Dla jednej LOSOWO WYGENEROWANEJ MAPY taki zasięg jest duży, a dla innej za mały. Nie chcę mi się więcej tłumaczyć, kto kumaty ten zrozumie.
#56
Hej Milek, jak tam prace nad skryptem? Coś tam drgnęło? Smile
#57
Niestety obecnie nie mam czasu. Może w lutym.
#58
hm, tak sobie pomyślałem że może by coś zrobić. co właściwie zostało do zrobienia? obsługa prądu i przypisywanie przedsiębiorstw do miast? czy coś jeszcze?
#59
Wyjątkowo ciepły ten luty.  Smiley4   Już myślałem, że całkiem zapomniałeś o tym.
Co by było do zrobienia? No właśnie przede wszystkim to przypisywanie przedsiębiorstw do miast i elektryczność. Zostaje też jeszcze kwestia ustawień.
Co do przypisywania przedsiębiorstw najlepsza byłaby metoda łączona, czyli produkcja przedsiębiorstwa przypisanego do miast byłaby liczona x50-100% w zależności od odległości (x50% jeśli powyżej 100 kratek) lub bez tej zależności, zawsze x100%), zaś pozostałe wokół danego miasta liczone byłyby x0-50% (x50% jeśli w centrum miasta; x0% jeśli ponad określoną odległość (domyślnie 20)). Dość istotne jest też aby produkcja przetwórcza bardziej się liczyła od pierwotnej.
Z elektrycznością może będzie nieco prościej. Chociaż sam nie wiem... trochę namotałem. Smiley54  Smiley44
Co do ustawień najbardziej przydatny byłby jakiś parametr zwiększający / zmniejszający szybkość rozwoju miast - obecnie miasta rosną jednak zbyt wolno. Jest ok na serwerach gdzie rozgrywka trwa tydzień lub dłużej, ale w ciągu standardowych 100 lat ciężko jest rozwinąć większe miasto.
Z istotnych ustawień przydałaby się też możliwość wyłączenia poszczególnych elementów, aby nie miały wpływu ani nie były widoczne w panelu miasta. Dotyczy to zwłaszcza Elektryczności i Budownictwa z tego względu, że nie zawsze surowce lub odpowiednie przedsiębiorstwa są dostępne.
No i to tłumaczenie na angielski "Budownictwo" można by było zmienić - myślę, że lepiej będzie pasowało "Buildings".

Ps. Nie wiem jak to jest, ale skrypt NWD jest chyba jedynym, który działa po wczytaniu gry z serwera. RCG i CGL się zacinają. Jedynym minusem jest to, że zdaje się zaczyna działać od nowa i potrzebuje jakiegoś czasu aby zebrać właściwe dane - to też można by było poprawić.
#60
(09-08-2017, 22:39)LaChupacabra napisał(a): Wyjątkowo ciepły ten luty.  Smiley4   Już myślałem, że całkiem zapomniałeś o tym.
no przecież ocieplenie klimatu jest Big Grin. wcześniej jakoś nie miałem czasu, a ostatni miesiąc zająłem się też pociągami, tylko w większym wydaniu, modernizacją symulatora eu07 Tongue

to za jakieś dwa dni zobaczę na to przypisywanie przedsiębiorstw, przetestuje się, a później to z prądem to jeszcze pogadamy.

(09-08-2017, 22:39)LaChupacabra napisał(a): Ps. Nie wiem jak to jest, ale skrypt NWD jest chyba jedynym, który działa po wczytaniu gry z serwera. RCG i CGL się zacinają. Jedynym minusem jest to, że zdaje się zaczyna działać od nowa i potrzebuje jakiegoś czasu aby zebrać właściwe dane - to też można by było poprawić.
tylko problem jest w tym że nie ma za bardzo jak. NWD nie zapisuje nic w zapisie gry i inicjalizuje się za każdym razem od nowa. można zapisywać obecny stan, tyle że skrypt wykonuje się wyłącznie na serwerze i w mapie przesyłanej do klienta nie ma tych danych. jednyne co by to poprawiło to natychmiastowe rozpoczęcie działania po wczytaniu zapisanej wcześniej lokalnie gry, ale za pierwszym razem po ściągnięciu z serwera i tak trzeba wystartować przeliczenia od nowa.


Skocz do:


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