civ.org.pl forums > Space4x - Space Empires V - Diaspora > Problemy techniczne
Zmień język na polski. Switch to English.

Print This Topic        Mark Topic as Unread 

civ.org.pl forums > Strategie Kosmiczne 4X > Space Empires V - Diaspora
Poster
Message    
PAwleus
Status: Hero

Posts: 2327
Registered: Mar 24, 2009
IP: Logged
Re: Problemy techniczne [post #101]

Merthenie, pewnie już to zauważyłeś, ale gdyby nie, to zapomniałeś chyba jeszcze w ostatnim patchu o tym, że po wynalezieniu nierasowej kolonizacji (w Diasporze - planet skalistych) znika też rasowy moduł kolonizacyjny, co powoduje niestety podobny problem z obsolete jak powodowało wynalezienie Universal Colonization - odłożyłbym jednak jego poprawienie do znalezienia większej ilości błędów, aby to łatanie nie było zbyt częste.

Jun 25, 2011 at 10:29

Print
Merthen
Status: Moderator

Posts: 5146
Registered: Aug 25, 2008
IP: Logged
Re: Problemy techniczne [post #102]

Niestety pośpiech nie popłaca - zrobiłem duży błąd.
Przy generowaniu tury wyskoczył mi komunikat ze plr Cezara jest niewłaściwy więc postanowiłem usunąć plr z PBW2. Z niewiadomych powodów nacisnąłem kick zamiast x, a ze serwer nie zapytał o potwierdzenie to Cezara został usunięty z gry.
Wysłałem mu meila z prośba o dołączenie i wysłanie prawidłowego plr.

Przepraszam Cezara za moją akcję.

[Edited by Merthen on Jul 03, 2011 at 10:06]

Jul 03, 2011 at 09:57

Print
Ceasar Of Rome
Status: Moderator

Posts: 3040
Registered: Aug 09, 2008
IP: Logged
Re: Problemy techniczne [post #103]

no wiesz co Merthenie, zapłacę ci za ostatnia dostawe spirytu ale weź przyjmij moje ponowne zgłoszenie :P

_________________________________
Ceasar Trade List

Jul 03, 2011 at 10:48
Gadu-Gadu: 8840735
XFire Ceasar4Rome
Print
Merthen
Status: Moderator

Posts: 5146
Registered: Aug 25, 2008
IP: Logged
Re: Problemy techniczne [post #104]

Już przyjąłem, jeszcze raz przepraszam.

Jul 03, 2011 at 11:26

Print
Merthen
Status: Moderator

Posts: 5146
Registered: Aug 25, 2008
IP: Logged
Re: Problemy techniczne [post #105]

Quote:
PAwleus wrote:
No więc tak, mamy oczywiście wszystkie podstawowe funkcje rachunkowe i funkcję pseudolosową Sys_Get_Random_Long, a także Sys_Get_Hex_Distance_Between_Sectors do otrzymania dystansu między sektorami. Dla gracza z traitem Ancient Race, czyli w Diasporze, można użyć Sys_Get_List_Of_Visible_Space_Objects_In_Sector do wylistowania określonych typów obiektów w danym sektorze, więc wystarczy jej użyć dla każdego sektora odległego od docelowego sektora skoku o nie więcej niż 10 heksów w danym systemie, aby znaleźć najbliższy obiekt, który zaburza skok i zbadać czy w sektorze do którego skok zostanie dokonany jest obiekt powodujący że skok zakończy się zniszczeniem statku dokonującego go.

Czyli przy każdy okręcie próbującym skoku trzeba zrobić:
Zbudować pętle w którym sprawdzam każdy sektor docelowego systemu - czyli pętla musi się wykonać około 500 razy.
W każdym przebiegu pętli sprawdzić za pomocą Sys_Get_Hex_Distance_Between_Sectors czy sektor znajduję się w odległości mniejszej niż 10 pól od miejsca skoku. Jeżeli tak sprawdzić za pomocą Sys_Get_List_Of_Visible_Space_Objects_In_Sector czy jest tam obiekt astronomiczny. Potem sprawdzić czy jest ob bliżej niż uprzednio znalezione jeżeli tak ustawić go jako obiekt główny.
Po skończeniu pętli pod zmienną: obiekt główny znajdujemy najbliższy obiekt astronomiczny. Sprawdzamy jak jest odległy (lub odczytujemy jeżeli to zapisaliśmy) i losujemy efekt skoku. Po czym go obsługujemy.
Możemy spróbować to zoptymalizować poprzez zmniejszane przebiegów pętli za pomocą ograniczania obszarów przeszukiwań ale to też kosztuje pracy przez engine.
Zobacz ile trzeba zrobić aby określić jeden skok gdyż brakuje funkcji listującej wszystkie obiekty w danym systemie.

Quote:
PAwleus wrote:
Jeśli jednak chcielibyśmy zrobić skrypt uniwersalny, także dla graczy nie-ancient, to trzeba byłoby trochę go skomplikować, gdyż nie można użyć ostatniej funkcji (gracze ci mogą nie znać obiektów astronomicznych w docelowym systemie). W takim skrypcie trzeba byłoby wylistować wszystkie obiekty danych typów w kwadrancie za pomocą Sys_Get_List_Of_Space_Objects_Of_Type, a następnie używając Sys_Get_Space_Object_System_Location oznaczać spośród nich obiekty z docelowego systemu lub nawet od razu przy pomocy Sys_Get_Space_Object_Sector_Location oznaczać spośród nich obiekty, które są odległe od docelowego sektora o nie więcej niż 10 heksów w danym systemie, znajdując najbliższy zakłócający skok..

I to trzeba zrobić przy każdy skoku każdego okrętu...


Quote:
PAwleus wrote:
Merthenie, pewnie już to zauważyłeś, ale gdyby nie, to zapomniałeś chyba jeszcze w ostatnim patchu o tym, że po wynalezieniu nierasowej kolonizacji (w Diasporze - planet skalistych) znika też rasowy moduł kolonizacyjny, co powoduje niestety podobny problem z obsolete jak powodowało wynalezienie Universal Colonization - odłożyłbym jednak jego poprawienie do znalezienia większej ilości błędów, aby to łatanie nie było zbyt częste.

Zauważyłem ale nie chce tego zmieniać bez przetestowania, a na to cały czas nie mam czasu.

[Edited by Merthen on Jul 03, 2011 at 12:28]
Jul 03, 2011 at 12:28

Print
PAwleus
Status: Hero

Posts: 2327
Registered: Mar 24, 2009
IP: Logged
Re: Problemy techniczne [post #106]

Ja to widzę, Merthenie, tyle że nie wydaje mi się to dużo. Przede wszystkim nie przesadzaj z tymi 500 bo tylko 487 razy i, jak zauważyłeś, można to ograniczyć przez zawężenie obszaru przeszukiwań (w końcu mając współrzędne docelowego dosyć łatwo jest wyeliminować współrzędne sektorów na pewno będących dalej niż 10 heksów od niego - w zasadzie do określania odległości wcale nie jest potrzebna podana przeze mnie funkcja, choć bardzo to upraszcza). Według mnie nie jest to dużo, gdyż okrętów realizujących oddzielny skok w czasie jednej tury wcale nie musi być dużo. W Diasporze to wątpię żeby do końca gry Adi przekroczył liczbę 20 oddzielnych skoków na turę, ale nawet jeśli miałby ich robić 100 to nadal, wydaje mi się, nie zauważyłbyś wydłużenia generowania tury, gdyż to bitwy są głównym winowajcą. Przecież, o ile się orientuję, to skrypty AI już dokonują znacznie bardziej skomplikowanych rzeczy i w znacznie większej ilości. Zdaję sobie sprawę, że "ziarnko do ziarnka..." i że żeby ulepszyć AI będzie trzeba wprowadzić mu analizę etapów ruchu (podobnie jak czynią to ludzie), co jeszcze wydłuży czas generacji tury, ale nawet w Ultimate Mod można znacznie ograniczyć liczebność oddzielnych skoków, poprzez uczynienie silnika skokowego na tyle dużym (i odpowiednio drogim) że zmieści się tylko na największe statki (taki też musiałby być statek eksploracyjny, o ile warp-pointy byłyby wyeliminowane z gry), a reszta będzie musiała bazować na tymczasowym punkcie skokowym wytworzonym przez niego (podobnie jak w B5) lub na Stargate-ach realizowanych przez oddzielny skrypt (statek skokowy musiałby dokonać skoku razem z towarzyszącymi mu statkami, a Stargate nie i w dodatku skoki pomiędzy Stargate-ami byłyby precyzyjne i bezpieczne). W ten sposób obciążenie engine byłoby znikome, w porównaniu do tego potrzebnego dla dobrego AI. Mogę się oczywiście mylić, ale dlatego właśnie chciałem żeby wypróbować to w ograniczony sposób w Diasporze, na co możemy nie mieć już dużo czasu, gdyż gra może się wcześniej niż się spodziewaliśmy skończyć.

Po zastanowieniu to wydaje mi się że nawet w Ultimate Mod można byłoby użyć tylko skryptu używającego Sys_Get_List_Of_Visible_Space_Objects_In_Sector - większe obiekty jak planety i gwiazdy przecież już uczyniliśmy widocznymi dla wszystkich w Diasporze, a przecież żeby chociaż spróbować skoku do danego systemu to już wcześniej system musi być widziany przez gracza (w jakiś sposób musi on np. aktywować Sys_Set_Have_Seen_System dla danego systemu). Pozostałe obiekty astronomiczne nie będą po prostu brane pod uwagę przy analizach odległości, a dopiero po dokonaniu skoku będzie sprawdzane tą samą funkcją czy jest w nim jakiś obiekt astronomiczny, który już wtedy stał się widoczny dla gracza (pozostaje tylko przetestować czy rzeczywiście się staje widoczny już w chwilę po realizacji Sys_Set_Space_Object_Position czy też dopiero w następnej turze) - te małe obiekty będą przeszkadzały przez niszczenie pojazdów dokokujących skoku tylko wtedy gdy znajdą się w tym samym sektorze już po dokonaniu skoku. Co myślisz o takim uproszczeniu?

Przy okazji, to byłem zszokowany, że zrobiłeś silnik skokowy tak małym w Diasporze - spodziewałem się że na małych jednostkach to już oprócz niego niewiele się zmieści

Jul 04, 2011 at 21:26

Print
PAwleus
Status: Hero

Posts: 2327
Registered: Mar 24, 2009
IP: Logged
Re: Problemy techniczne [post #107]

Chciałem potestować metody walki z Missiles i wygląda na to, że jest z nimi dodatkowy problem, znacznie większy niż drobna ale dokuczliwa niedogodność braku ikonki statusu: nie ma jak spowodować żeby były czynnie atakowane podczas bitwy (ani oczywiście określić sposób ataku), gdyż ich nazwa nie występuje w Target Type Order And Settings i nie widzę możliwości zmiany tego, przynajmniej w Diasporze. W Atenie, jeśli chcesz utrzymania ich obecności, jedyny sposób przy pomocy którego chyba da się załatwić tę sprawę to wykorzystać Weapon Platforms, porzucając ich obecną funkcjonalność (jak widzisz w Diasporze nikt z nich nie korzysta, a gdyby to robił to generalnie byłby to błąd, choć są sytuacje w których mogą być one przydatne - dla nich stworzyłbym specjalny rodzaj wielkich i nieruchawych Troops, na których można byłoby zmieścić broń strzelającą w kosmos, a także porządny pancerz i i duże zbiorniki na zapasy). Zrobiłbym to w ten sposób, że obecnym Missiles przyporządkowałbym nazwę Drones, a obecnym Drones - Weapon Platforms. W ten sposób chyba da się załatwić wszystkie problemy z Missiles (oczywiście będzie trzeba też zmodyfikować ikonki statusu) i nie stworzy się nowych (z wyjątkiem może konieczności drobnej modyfikacji shipsetów i tego, że nie da się już odróżnić ikonką statusu normalnych Troops od wielkich, ale przynajmniej te wielkie Troops będzie można selektywnie atakować w walce naziemnej jeśli ustawi się priorytet ataku najsilniejszego przeciwnika).

Trzeba byłoby też się przyjrzeć ich balansowi, gdyż obecnie wydają mi się potwornie mordercze (wbrew intuicji 1 Missile może zniszczyć kilka statków), ale mogę się mylić, ze względu na brak możliwości dokładnego przetestowania ich gdy mogą być czynnie atakowane.

[Edited by PAwleus on Jul 05, 2011 at 22:16]

Jul 05, 2011 at 22:04

Print
PAwleus
Status: Hero

Posts: 2327
Registered: Mar 24, 2009
IP: Logged
Re: Problemy techniczne [post #108]

Objawił się mało znaczący bug SEV: linia "Vehicle Portrait Default := [%EmpireName%]_Portrait_Carrier.bmp" przy Strike Carrier w VehicleSizes.txt jest z jakiegoś powodu uparcie ignorowana przez grę (patrzę na nią i patrzę, ale linia wygląda mi na poprawną), a skoro w Vaygr brak jest *strikecarrier.bmp i *lightcarrier.bmp to w oknie Log przy logu o uzyskaniu poziomu technologicznego Strike Carrier wyskakuje komunikat o niemożliwości znalezienia *strikecarrier.bmp - łatwo jednak to naprawić przez stworzenie tego pliku w katalogu Vaygr, choć przecież Default powinien sprawę załatwić, tak jak to robi w innych miejscach, w których, jak już wcześniej wykazały testy, jest wszystko w porządku. Tylko chyba tego nie przetestowałem...

Jul 18, 2011 at 23:15

Print
PAwleus
Status: Hero

Posts: 2327
Registered: Mar 24, 2009
IP: Logged
Re: Problemy techniczne [post #109]

Jest błąd w Ability 3 Amount 1 Formula do Small Jacketed-Photon Engines - pomiędzy 300 i + nie ma odstępu. Nie ma pośpiechu w poprawianiu tego, chyba że ktoś zamierza wkrótce z tych silników korzystać (ja nie).

Jul 19, 2011 at 19:56

Print
PAwleus
Status: Hero

Posts: 2327
Registered: Mar 24, 2009
IP: Logged
Re: Problemy techniczne [post #110]

Nazbierało się trochę tych postów pod rząd - mam nadzieję, że nie zginą w tłoku, który same tworzą Łączyłbym je ze sobą, ale obawiam się, że wtedy te nowe dodatki nieprędko zostałbyby zauważone.

Merthenie, nie wiem jakie masz dalsze intencje w sprawie Missiles w Atenie, ale jeśli chodzi o Diasporę to czy carriery nie powinny mieć także dodanego Missile Launcher do wymagania przynajmniej 30% tonażu? W każdym razie albo opis do Ability 2 przy carrierach powinien być zmieniony np. na: "Strike Carriers still launch a unit every [%Amount2%] milliseconds during combat even if all unit launchers are destroyed." albo kadłub carrierów powinien służyć tylko myśliwcom i mieć zakaz innych launcherów dla units.

[Edited by PAwleus on Jul 27, 2011 at 15:00]

Jul 24, 2011 at 20:48

Print
Merthen
Status: Moderator

Posts: 5146
Registered: Aug 25, 2008
IP: Logged
Re: Problemy techniczne [post #111]

Quote:
PAwleus wrote:
Merthenie, pewnie już to zauważyłeś, ale gdyby nie, to zapomniałeś chyba jeszcze w ostatnim patchu o tym, że po wynalezieniu nierasowej kolonizacji (w Diasporze - planet skalistych) znika też rasowy moduł kolonizacyjny, co powoduje niestety podobny problem z obsolete jak powodowało wynalezienie Universal Colonization - odłożyłbym jednak jego poprawienie do znalezienia większej ilości błędów, aby to łatanie nie było zbyt częste.

Zostanie poprawione w najbliższym patchu

Quote:
PAwleus wrote:
Ja to widzę, Merthenie, tyle że nie wydaje mi się to dużo. Przede wszystkim nie przesadzaj z tymi 500 bo tylko 487 razy i, jak zauważyłeś, można to ograniczyć przez zawężenie obszaru przeszukiwań (w końcu mając współrzędne docelowego dosyć łatwo jest wyeliminować współrzędne sektorów na pewno będących dalej niż 10 heksów od niego - w zasadzie do określania odległości wcale nie jest potrzebna podana przeze mnie funkcja, choć bardzo to upraszcza). Według mnie nie jest to dużo, gdyż okrętów realizujących oddzielny skok w czasie jednej tury wcale nie musi być dużo. W Diasporze to wątpię żeby do końca gry Adi przekroczył liczbę 20 oddzielnych skoków na turę, ale nawet jeśli miałby ich robić 100 to nadal, wydaje mi się, nie zauważyłbyś wydłużenia generowania tury, gdyż to bitwy są głównym winowajcą.

Częściowo się z Tobą zgadzam ale nadal nie podoba mi się ręczne obliczanie przez gracza czy miejsce skoku jest oddalone powyżej 10 tur od każdego obiektu astronomicznego.
Ale do wszystkiego trzeba poodchodzić małymi kroczkami. Proponuje na początek zmienić tak skrypt skoku aby blokował możliwość wylądowania na jakimkolwiek obiekcie astronomicznym czy to jest planet czy też warp. Później zastanowimy się nad następnym krokiem.

Quote:
PAwleus wrote:
Przecież, o ile się orientuję, to skrypty AI już dokonują znacznie bardziej skomplikowanych rzeczy i w znacznie większej ilości. Zdaję sobie sprawę, że "ziarnko do ziarnka..." i że żeby ulepszyć AI będzie trzeba wprowadzić mu analizę etapów ruchu (podobnie jak czynią to ludzie),
co jeszcze wydłuży czas generacji tury, ale nawet w Ultimate Mod można znacznie ograniczyć liczebność oddzielnych skoków, poprzez uczynienie silnika skokowego na tyle dużym (i odpowiednio drogim) że zmieści się tylko na największe statki (taki też musiałby być statek eksploracyjny, o ile warp-pointy byłyby wyeliminowane z gry), a reszta będzie musiała bazować na tymczasowym punkcie skokowym wytworzonym przez niego (podobnie jak w B5) lub na Stargate-ach realizowanych przez oddzielny skrypt (statek skokowy musiałby dokonać skoku razem z towarzyszącymi mu statkami, a Stargate nie i w dodatku skoki pomiędzy Stargate-ami byłyby precyzyjne i bezpieczne). W ten sposób obciążenie engine byłoby znikome, w porównaniu do tego potrzebnego dla dobrego AI.

To już bardziej zaawansowany projekty do przedyskutowania przy tworzeniu Ultimate Mod.

Quote:
PAwleus wrote:
Mogę się oczywiście mylić, ale dlatego właśnie chciałem żeby wypróbować to w ograniczony sposób w Diasporze, na co możemy nie mieć już dużo czasu, gdyż gra może się wcześniej niż się spodziewaliśmy skończyć.

A to niby czemu ?

Quote:
PAwleus wrote:
Po zastanowieniu to wydaje mi się że nawet w Ultimate Mod można byłoby użyć tylko skryptu używającego Sys_Get_List_Of_Visible_Space_Objects_In_Sector - większe obiekty jak planety i gwiazdy przecież już uczyniliśmy widocznymi dla wszystkich w Diasporze, a przecież żeby chociaż spróbować skoku do danego systemu to już wcześniej system musi być widziany przez gracza (w jakiś sposób musi on np. aktywować Sys_Set_Have_Seen_System dla danego systemu). Pozostałe obiekty astronomiczne nie będą po prostu brane pod uwagę przy analizach odległości, a dopiero po dokonaniu skoku będzie sprawdzane tą samą funkcją czy jest w nim jakiś obiekt astronomiczny, który już wtedy stał się widoczny dla gracza (pozostaje tylko przetestować czy rzeczywiście się staje widoczny już w chwilę po realizacji Sys_Set_Space_Object_Position czy też dopiero w następnej turze) - te małe obiekty będą przeszkadzały przez niszczenie pojazdów dokokujących skoku tylko wtedy gdy znajdą się w tym samym sektorze już po dokonaniu skoku. Co myślisz o takim uproszczeniu?

Ciekawe podejście i po sprawdzenie ze da się aktywować funkcje Sys_Set_Have_Seen_System dla nieznanych systemów warte przetestowania.

Quote:
PAwleus wrote:
Przy okazji, to byłem zszokowany, że zrobiłeś silnik skokowy tak małym w Diasporze - spodziewałem się że na małych jednostkach to już oprócz niego niewiele się zmieści

Moim zamiarem było umożliwić skok zwiadowcą obcym bez utraty ich wyposażenia jak na zaawansowaną rasę przystało .

Quote:
PAwleus wrote:
Chciałem potestować metody walki z Missiles i wygląda na to, że jest z nimi dodatkowy problem, znacznie większy niż drobna ale dokuczliwa niedogodność braku ikonki statusu: nie ma jak spowodować żeby były czynnie atakowane podczas bitwy (ani oczywiście określić sposób ataku), gdyż ich nazwa nie występuje w Target Type Order And Settings i nie widzę możliwości zmiany tego, przynajmniej w Diasporze.

To rzeczywiście problem, który odkryłem jakiś czas temu przy symulacjach z jastrzębiami. Niestety dla Diapsory nie znalazłem rozwiązania.

Quote:
PAwleus wrote:
W Atenie, jeśli chcesz utrzymania ich obecności, jedyny sposób przy pomocy którego chyba da się załatwić tę sprawę to wykorzystać Weapon Platforms, porzucając ich obecną funkcjonalność (jak widzisz w Diasporze nikt z nich nie korzysta, a gdyby to robił to generalnie byłby to błąd, choć są sytuacje w których mogą być one przydatne - dla nich stworzyłbym specjalny rodzaj wielkich i nieruchawych Troops, na których można byłoby zmieścić broń strzelającą w kosmos, a także porządny pancerz i i duże zbiorniki na zapasy). Zrobiłbym to w ten sposób, że obecnym Missiles przyporządkowałbym nazwę Drones, a obecnym Drones - Weapon Platforms. W ten sposób chyba da się załatwić wszystkie problemy z Missiles (oczywiście będzie trzeba też zmodyfikować ikonki statusu) i nie stworzy się nowych (z wyjątkiem może konieczności drobnej modyfikacji shipsetów i tego, że nie da się już odróżnić ikonką statusu normalnych Troops od wielkich, ale przynajmniej te wielkie Troops będzie można selektywnie atakować w walce naziemnej jeśli ustawi się priorytet ataku najsilniejszego przeciwnika).

Ja chce trochę inaczej w Atenie podejść do tego problemu. Chce całkowicie zlikwidować jednostkę
drones i zastąpić ja missiles tak jak proponujesz ale nie likwidować Weapon Platforms. Chce dodać do shipsetu zautomatyzowany statek o nazwie probe, który przejmie role drones. Może straci się w ten sposób możliwość ich produkcji bez stoczni ale za to zyska kilka nowych możliwości oraz zlikwiduje bug z zaopatrzeniem. Taki statek dostanie kilka nowych cech niedostępnych innym okrętom.
Uważam ze żadne jednostka nie powinna umieć samodzielnie opuszczać system.

Quote:
PAwleus wrote:
Trzeba byłoby też się przyjrzeć ich balansowi, gdyż obecnie wydają mi się potwornie mordercze (wbrew intuicji 1 Missile może zniszczyć kilka statków), ale mogę się mylić, ze względu na brak możliwości dokładnego przetestowania ich gdy mogą być czynnie atakowane.

Tak samo mordercze okazują się Jastrzębie OZRR które nie posiadając ładunku wybuchowego mogą zniszczyć kilka okrętów. Stanowczo balans dla niektórych komponentów musi zostać przeprowadzony.
Quote:
PAwleus wrote:
Objawił się mało znaczący bug SEV: linia "Vehicle Portrait Default := [%EmpireName%]_Portrait_Carrier.bmp" przy Strike Carrier w VehicleSizes.txt jest z jakiegoś powodu uparcie ignorowana przez grę (patrzę na nią i patrzę, ale linia wygląda mi na poprawną), a skoro w Vaygr brak jest *strikecarrier.bmp i *lightcarrier.bmp to w oknie Log przy logu o uzyskaniu poziomu technologicznego Strike Carrier wyskakuje komunikat o niemożliwości znalezienia *strikecarrier.bmp - łatwo jednak to naprawić przez stworzenie tego pliku w katalogu Vaygr, choć przecież Default powinien sprawę załatwić, tak jak to robi w innych miejscach, w których, jak już wcześniej wykazały testy, jest wszystko w porządku. Tylko chyba tego nie przetestowałem...

U mnie w Vaygr jest plik Vaygr_Portrait_strikecarrier.bmp tego pliku nie może znaleźć?

Quote:
PAwleus wrote:
Jest błąd w Ability 3 Amount 1 Formula do Small Jacketed-Photon Engines - pomiędzy 300 i + nie ma odstępu. Nie ma pośpiechu w poprawianiu tego, chyba że ktoś zamierza wkrótce z tych silników korzystać (ja nie).

Zostanie poprawione w najbliższym patchu

Quote:
PAwleus wrote:
Merthenie, nie wiem jakie masz dalsze intencje w sprawie Missiles w Atenie, ale jeśli chodzi o Diasporę to czy carriery nie powinny mieć także dodanego Missile Launcher do wymagania przynajmniej 30% tonażu? W każdym razie albo opis do Ability 2 przy carrierach powinien być zmieniony np. na: "Strike Carriers still launch a unit every [%Amount2%] milliseconds during combat even if all unit launchers are destroyed." albo kadłub carrierów powinien służyć tylko myśliwcom i mieć zakaz innych launcherów dla units.

Dodam wymaganie Missile Launcher dla carrierów w najbliższym patchu

Quote:
PAwleus wrote:
No to jak będzie z tymi carrierami? Chętnie zbudowałbym specjalizowany Missile Carrier (dałeś nawet taki Design Type) na bazie kadłuba carriera, ale obecnie jest to niemożliwe. Nic nie odpowiedziałeś na mój post więc nie wiem czego oczekiwać - jeśli nie będzie łatki poprawiającej  to zadowolę się skromniejszym na bazie frachtowca, ale chciałbym wiedzieć już teraz. W zasadzie to może nawet byłoby lepiej gdyby kadłuby carrierów były wyłącznie dla myśliwców - moglibyśmy je wreszcie nazywać po polsku lotniskowcami

W Diasporze lepiej aby carriery miały wliczone i myśliwce i pociski. Co do Ateny to nie jestem zdecydowany na razie uczyłem AI tworzyć projekty Battlestar w których oprócz ciężkiej broni znajduje się myśliwce i missiles. To tak z sentymentów dla jednego z lepszych seriali SF
Jul 28, 2011 at 12:49

Print
PAwleus
Status: Hero

Posts: 2327
Registered: Mar 24, 2009
IP: Logged
Re: Problemy techniczne [post #112]

Quote:
Merthen wrote:
Częściowo się z Tobą zgadzam ale nadal nie podoba mi się ręczne obliczanie przez gracza czy miejsce skoku jest oddalone powyżej 10 tur od każdego obiektu astronomicznego.
Ale do wszystkiego trzeba poodchodzić małymi kroczkami. Proponuje na początek zmienić tak skrypt skoku aby blokował możliwość wylądowania na jakimkolwiek obiekcie astronomicznym czy to jest planet czy też warp. Później zastanowimy się nad następnym krokiem.


Odnośnie skryptu to lepiej byłoby gdyby niszczył okręt a nie blokował mu możliwość skoku - za błędy nawigacyjne powinno się płacić No i nie zapominaj o odejmowaniu znaczącej ilości supplies za skok - taka możliwość musi kosztować

Nadal nie rozumiem jednak, Merthenie, w którym miejscu wydaje Ci się że gracz byłby zmuszony do ręcznego obliczania dystansu w związku z bezpieczeństwem skoku (pomijam to, że nawet obecnie, aby dobrze grać, jest zmuszany do podobnych obliczeń bardzo często). Różnica pomiędzy 5 a 10 heksów miałaby dramatyczne konsekwencje, ale tą różnicę akurat standardowy umysł ludzki z łatwością dostrzega na pierwszy rzut oka, więc gracz nie musi nic ręcznie obliczać. Może wydaje Ci się że problem pojawia się przy rozważaniu czy odległość to właściwie 11, 10 czy 9 heksów, gdyż z tym standardowy, niewyćwiczony w tym kierunku, umysł ludzki ma na pierwszy rzut oka kłopot. Tyle że mimo tego iż przy 11 skok byłby całkowicie bezpieczny, a przy 10 i nawet bardziej przy 9 - nie, to jednak ciągle byłoby to na tyle niewielkie zagrożenie że gracz, któremu nie chce się tego oceniać dokładnie mógłby to zaniedbać. Większe różnice w zagrożeniu będą między 6, 5 a 4 - te liczby są jednak na tyle małe, że już na pierwszy rzut oka widać że jest to np. 5 a nie 4, wydaje mi się że nawet dla niewyćwiczonego, specjalnie w tym kierunku, umysłu. Jaki widzisz w tym kłopot dla gracza?

Quote:
Merthen wrote:
Quote:
PAwleus wrote:
Mogę się oczywiście mylić, ale dlatego właśnie chciałem żeby wypróbować to w ograniczony sposób w Diasporze, na co możemy nie mieć już dużo czasu, gdyż gra może się wcześniej niż się spodziewaliśmy skończyć.

A to niby czemu ?


Nie będę przecież zdradzał, ale akurat Ty to już chyba wiesz czemu

Quote:
Merthen wrote:
Quote:
PAwleus wrote:
Po zastanowieniu to wydaje mi się że nawet w Ultimate Mod można byłoby użyć tylko skryptu używającego Sys_Get_List_Of_Visible_Space_Objects_In_Sector - większe obiekty jak planety i gwiazdy przecież już uczyniliśmy widocznymi dla wszystkich w Diasporze, a przecież żeby chociaż spróbować skoku do danego systemu to już wcześniej system musi być widziany przez gracza (w jakiś sposób musi on np. aktywować Sys_Set_Have_Seen_System dla danego systemu). Pozostałe obiekty astronomiczne nie będą po prostu brane pod uwagę przy analizach odległości, a dopiero po dokonaniu skoku będzie sprawdzane tą samą funkcją czy jest w nim jakiś obiekt astronomiczny, który już wtedy stał się widoczny dla gracza (pozostaje tylko przetestować czy rzeczywiście się staje widoczny już w chwilę po realizacji Sys_Set_Space_Object_Position czy też dopiero w następnej turze) - te małe obiekty będą przeszkadzały przez niszczenie pojazdów dokokujących skoku tylko wtedy gdy znajdą się w tym samym sektorze już po dokonaniu skoku. Co myślisz o takim uproszczeniu?

Ciekawe podejście i po sprawdzenie ze da się aktywować funkcje Sys_Set_Have_Seen_System dla nieznanych systemów warte przetestowania.


Stosowanie tej funkcji zostało już chyba wystarczająco przetestowane w skryptach zrobionych przez edge1218, do których dałem Ci kiedyś link - była tam użyta właśnie do wykrywania zupełnie nieznanych systemów w określonym promieniu od facility lub komponentu należącego do gracza. Co zostaje do przetestowania to napisałem w nawiasie.

Quote:
Merthen wrote:
Ja chce trochę inaczej w Atenie podejść do tego problemu. Chce całkowicie zlikwidować jednostkę drones i zastąpić ja missiles tak jak proponujesz ale nie likwidować Weapon Platforms. Chce dodać do shipsetu zautomatyzowany statek o nazwie probe, który przejmie role drones. Może straci się w ten sposób możliwość ich produkcji bez stoczni ale za to zyska kilka nowych możliwości oraz zlikwiduje bug z zaopatrzeniem. Taki statek dostanie kilka nowych cech niedostępnych innym okrętom.
Uważam ze żadne jednostka nie powinna umieć samodzielnie opuszczać system.


Świetnie! Widzę w tym same zalety Chyba moja pogarda dla Weapon Platforms mnie zaślepiła że nie zauważyłem tej możliwości Oczywiście masz raczej na myśli to, że zlikwidujesz Missiles a dronom obetniesz możliwość przejścia przez W-P i je znacznie przyspieszysz. Warto byłoby w tym miejscu wprowadzić specjalizowane silniki dla dron (tak jak w przypadku myśliwców byłoby to symboliczne pokazanie że nie mogą one pokonywać W-P) i to może nawet dwa rodzaje - jeden o bardzo dużym ciągu i spalaniu paliwa dla dron w funkcji Missile, a drugi o mniejszym ciągu i spalaniu paliwa dla dron z bronią działającą na odległość (w ten sposób łatwiej byłoby zachować balans) posiadających bardziej zaawansowaną i droższą, ale bardziej wrażliwą na przeciążenia, jednostkę sterującą (dla umieszczenia takiej broni byłaby wymagana ta jednostka, a ona skolei eliminowałaby z projektu mocniejsze silniki.

Quote:
Merthen wrote:
Quote:
PAwleus wrote:
Trzeba byłoby też się przyjrzeć ich balansowi, gdyż obecnie wydają mi się potwornie mordercze (wbrew intuicji 1 Missile może zniszczyć kilka statków), ale mogę się mylić, ze względu na brak możliwości dokładnego przetestowania ich gdy mogą być czynnie atakowane.

Tak samo mordercze okazują się Jastrzębie OZRR które nie posiadając ładunku wybuchowego mogą zniszczyć kilka okrętów. Stanowczo balans dla niektórych komponentów musi zostać przeprowadzony.


To akurat dość łatwo byłoby w Atenie zrobić. Już kiedyś zwracałem uwagę że głowice dla dron są zbyt słabe w porównaniu do min, więc jest dodatkowy powód żeby je znacząco polepszyć, a jak najbardziej ograniczyć im ilość pancerza lub wprowadzić dedykowany pancerz dla dron, albo nawet pozwolić im tylko na small armor.

Quote:
Merthen wrote:
U mnie w Vaygr jest plik Vaygr_Portrait_strikecarrier.bmp tego pliku nie może znaleźć?


A to ciekawostka... A skąd się w Twoim Vaygr wziął ten plik? Jesteś pewien że masz właściwą wersję katalogu Vaygr? W takim razie być może to nie jest błąd SEV a po prostu różnica w plikach w stosunku do hosta. Tyle że jeśli to nie błąd to ten plik w shipsecie Vaygr jest zbędny, gdyż niepotrzebnie powiela *carrier.bmp

Właśnie sprawdziłem i to jednak nie jest błąd - daj znać czy skasujesz *strikecarrier.bmp z Vaygr to i ja wtedy go skasuję (inni go chyba nie mają, a nawet jeśli tak to nie będą mieli z tym problemu, ale sprawdź czy masz taką samą wersję Vaygr jak ta którą przesłałeś innym graczom, bo mogą być też inne różnice, no i może prześlij mi link do tej wersji żebym i ja sobie sprawdził - gdzieś podziałem maila w którym go dawałeś)

Quote:
Merthen wrote:
W Diasporze lepiej aby carriery miały wliczone i myśliwce i pociski. Co do Ateny to nie jestem zdecydowany na razie uczyłem AI tworzyć projekty Battlestar w których oprócz ciężkiej broni znajduje się myśliwce i missiles. To tak z sentymentów dla jednego z lepszych seriali SF

Nie chodzi o to żeby im zabronić, ale żeby wyrzutnie dron nie liczyły się do wymaganego tonażu.

[Edited by PAwleus on Jul 28, 2011 at 17:02]
Jul 28, 2011 at 17:02

Print
Merthen
Status: Moderator

Posts: 5146
Registered: Aug 25, 2008
IP: Logged
Re: Problemy techniczne [post #113]

Quote:
PAwleus wrote:
Odnośnie skryptu to lepiej byłoby gdyby niszczył okręt a nie blokował mu możliwość skoku - za błędy nawigacyjne powinno się płacić No i nie zapominaj o odejmowaniu znaczącej ilości supplies za skok - taka możliwość musi kosztować

Obcy nie robią błędów a o Diasporę mi teraz chodzi.

Quote:
PAwleus wrote:
Nadal nie rozumiem jednak, Merthenie, w którym miejscu wydaje Ci się że gracz byłby zmuszony do ręcznego obliczania dystansu w związku z bezpieczeństwem skoku (pomijam to, że nawet obecnie, aby dobrze grać, jest zmuszany do podobnych obliczeń bardzo często). Różnica pomiędzy 5 a 10 heksów miałaby dramatyczne konsekwencje, ale tą różnicę akurat standardowy umysł ludzki z łatwością dostrzega na pierwszy rzut oka, więc gracz nie musi nic ręcznie obliczać. Może wydaje Ci się że problem pojawia się przy rozważaniu czy odległość to właściwie 11, 10 czy 9 heksów, gdyż z tym standardowy, niewyćwiczony w tym kierunku, umysł ludzki ma na pierwszy rzut oka kłopot. Tyle że mimo tego iż przy 11 skok byłby całkowicie bezpieczny, a przy 10 i nawet bardziej przy 9 - nie, to jednak ciągle byłoby to na tyle niewielkie zagrożenie że gracz, któremu nie chce się tego oceniać dokładnie mógłby to zaniedbać. Większe różnice w zagrożeniu będą między 6, 5 a 4 - te liczby są jednak na tyle małe, że już na pierwszy rzut oka widać że jest to np. 5 a nie 4, wydaje mi się że nawet dla niewyćwiczonego, specjalnie w tym kierunku, umysłu. Jaki widzisz w tym kłopot dla gracza?

Teoretycznie widzę tu kłopot dla siebie , ale cóż zobaczymy jak to wyjdzie w praktyce.

Quote:
PAwleus wrote:
Stosowanie tej funkcji zostało już chyba wystarczająco przetestowane w skryptach zrobionych przez edge1218, do których dałem Ci kiedyś link - była tam użyta właśnie do wykrywania zupełnie nieznanych systemów w określonym promieniu od facility lub komponentu należącego do gracza. Co zostaje do przetestowania to napisałem w nawiasie.

Faktycznie zapomniałem o tym. W takim razie sprawa zostaje otwarta dla testów.

Quote:
PAwleus wrote:
Świetnie! Widzę w tym same zalety Chyba moja pogarda dla Weapon Platforms mnie zaślepiła że nie zauważyłem tej możliwości Oczywiście masz raczej na myśli to, że zlikwidujesz Missiles a dronom obetniesz możliwość przejścia przez W-P i je znacznie przyspieszysz. Warto byłoby w tym miejscu wprowadzić specjalizowane silniki dla dron (tak jak w przypadku myśliwców byłoby to symboliczne pokazanie że nie mogą one pokonywać W-P) i to może nawet dwa rodzaje - jeden o bardzo dużym ciągu i spalaniu paliwa dla dron w funkcji Missile, a drugi o mniejszym ciągu i spalaniu paliwa dla dron z bronią działającą na odległość (w ten sposób łatwiej byłoby zachować balans) posiadających bardziej zaawansowaną i droższą, ale bardziej wrażliwą na przeciążenia, jednostkę sterującą (dla umieszczenia takiej broni byłaby wymagana ta jednostka, a ona skolei eliminowałaby z projektu mocniejsze silniki.

Z silnikami to dobry pomysł i na pewno go zastosuje w Atenie. Tak samo chce dodać kilka osobnych komponentów dla Probe.


Quote:
PAwleus wrote:
To akurat dość łatwo byłoby w Atenie zrobić. Już kiedyś zwracałem uwagę że głowice dla dron są zbyt słabe w porównaniu do min, więc jest dodatkowy powód żeby je znacząco polepszyć, a jak najbardziej ograniczyć im ilość pancerza lub wprowadzić dedykowany pancerz dla dron, albo nawet pozwolić im tylko na small armor.

Dobrze byłoby tak zrobić ze głowica wybuchowy dla missiles zadaje więcej uszkodzeń niż wynosi wytrzymałość pancerza o tej samej masie. Wtedy wstawianie samego pancerza przestanie być opłacalne.

Quote:
PAwleus wrote:
A to ciekawostka... A skąd się w Twoim Vaygr wziął ten plik? Jesteś pewien że masz właściwą wersję katalogu Vaygr? W takim razie być może to nie jest błąd SEV a po prostu różnica w plikach w stosunku do hosta. Tyle że jeśli to nie błąd to ten plik w shipsecie Vaygr jest zbędny, gdyż niepotrzebnie powiela *carrier.bmp

Właśnie sprawdziłem i to jednak nie jest błąd - daj znać czy skasujesz *strikecarrier.bmp z Vaygr to i ja wtedy go skasuję (inni go chyba nie mają, a nawet jeśli tak to nie będą mieli z tym problemu, ale sprawdź czy masz taką samą wersję Vaygr jak ta którą przesłałeś innym graczom, bo mogą być też inne różnice, no i może prześlij mi link do tej wersji żebym i ja sobie sprawdził - gdzieś podziałem maila w którym go dawałeś)


Najprawdopodobniej o to chodzi. Wersja Diaspory z Vaygr znajduje się tutaj:
http://www.merthen.pl/index.php?strona=diaspora
Mogę plik skasować przy następnej turze.

Quote:
PAwleus wrote:
Quote:
Merthen wrote:
W Diasporze lepiej aby carriery miały wliczone i myśliwce i pociski. Co do Ateny to nie jestem zdecydowany na razie uczyłem AI tworzyć projekty Battlestar w których oprócz ciężkiej broni znajduje się myśliwce i missiles. To tak z sentymentów dla jednego z lepszych seriali SF

Nie chodzi o to żeby im zabronić, ale żeby wyrzutnie dron nie liczyły się do wymaganego tonażu.


Przy nowym podejściu do dron można tak zrobić.
Jul 28, 2011 at 22:14

Print
PAwleus
Status: Hero

Posts: 2327
Registered: Mar 24, 2009
IP: Logged
Re: Problemy techniczne [post #114]

Czy to tylko u mnie czy też jest jakiś problem ze spaceempires.net? Od wczoraj nie mogę wejść ani do nich ani na PBW2, więc nie mogę ściągnąć tury do zrobienia, mimo iż otrzymałem maila że jest już wygenerowana - mógłbyś Merthenie umieścić ją u siebie?

A tak przy okazji, udało się komuś podejrzeć raporty z bitew otrzymane od innego imperium (tzn. obejrzeć ich bitwy)?

[Edited by PAwleus on Aug 21, 2011 at 22:21]

Aug 21, 2011 at 22:18

Print
Ziro
Status: Elite

Posts: 777
Registered: Feb 14, 2009
IP: Logged
Re: Problemy techniczne [post #115]

Mi też nie chce strona działać, co do raportów jak 2-3 tury temu sprawdzałem udało mi się je odpalić, ale ostatnich nie podglądałem, tylko wynik odczytywałem.

_________________________________
Hitori ni nareba fuan ni obieteita kedo

LastFM

Aug 21, 2011 at 22:24
Gadu-Gadu: 7994773
Print
Ceasar Of Rome
Status: Moderator

Posts: 3040
Registered: Aug 09, 2008
IP: Logged
Re: Problemy techniczne [post #116]

to moze ta ture "wygenerujemy" recznie ?

_________________________________
Ceasar Trade List

Aug 21, 2011 at 22:43
Gadu-Gadu: 8840735
XFire Ceasar4Rome
Print
Merthen
Status: Moderator

Posts: 5146
Registered: Aug 25, 2008
IP: Logged
Re: Problemy techniczne [post #117]

turę wyśle Wam meilem.

P.S.
Swoje bitwy oglądam.

[Edited by Merthen on Aug 21, 2011 at 22:56]

Aug 21, 2011 at 22:56

Print
PAwleus
Status: Hero

Posts: 2327
Registered: Mar 24, 2009
IP: Logged
Re: Problemy techniczne [post #118]

Mailem może nie pójść u wszystkich - podejrzewam że razem z combatreplay ma ponad 20MB

Nie chodzi mi o swoje bitwy tylko o czyjeś (OZRR otrzymuje od Konfederacji raporty z bitew) - ja Twoich z Ikrod nie mogłem obejrzeć.

[Edited by PAwleus on Aug 21, 2011 at 23:00]

Aug 21, 2011 at 22:58

Print
Merthen
Status: Moderator

Posts: 5146
Registered: Aug 25, 2008
IP: Logged
Re: Problemy techniczne [post #119]

meil będzie miał link do tury

savegame jak się właduję na moją stronę to wyśle.

Innych nie widzę.

Aug 21, 2011 at 23:01

Print
PAwleus
Status: Hero

Posts: 2327
Registered: Mar 24, 2009
IP: Logged
Re: Problemy techniczne [post #120]

Popatrz pośród bitew z poprzedniej tury

Aug 21, 2011 at 23:04

Print
Merthen
Status: Moderator

Posts: 5146
Registered: Aug 25, 2008
IP: Logged
Re: Problemy techniczne [post #121]

Zerknę później . Link wysłany.

Aug 21, 2011 at 23:07

Print
PAwleus
Status: Hero

Posts: 2327
Registered: Mar 24, 2009
IP: Logged
Re: Problemy techniczne [post #122]

Dzięki, Merthenie, a runnersan wkrótce pozna decyzję Konfederacji

Aug 22, 2011 at 00:20

Print
Ceasar Of Rome
Status: Moderator

Posts: 3040
Registered: Aug 09, 2008
IP: Logged
Re: Problemy techniczne [post #123]

strona wróciła do żywych

_________________________________
Ceasar Trade List

Aug 22, 2011 at 16:32
Gadu-Gadu: 8840735
XFire Ceasar4Rome
Print
^ Początek strony ^
Pages: 1 2 [3]



Username: Password: Lost your password?

tForum version b0.94.1.2 (© 2003 tForumDevTeam)

The comments published here represent only the personal opinions of the respective users. civ.org.pl and it's staff is not held responsible for the contents of the posts.

Publikowane komentarze są prywatnymi opiniami użytkowników portalu. Portal civ.org.pl ani jego redakcja nie ponosi odpowiedzialności za treść opinii.


hosted by artserwis.pl - praca, konkursy, portfolia dla twórców.