Zbroja, która ponosi uszkodzenia w trakcie walki 25691 106

O temacie

Autor pawbuj

Zaczęty 25.03.2013 roku

Wyświetleń 25691

Odpowiedzi 106

inż. Avallach

inż. Avallach

Administrator
posty7661
Propsy5239
NagrodyV
ProfesjaProgramista
  • Administrator
Av mam nadzieję, że ci to coś mówi  :lol2:  
Spoiler

Mówi :D
Jeśli założyć że pierwszy screen pokazuje sytuację w której perception nie powinien się odpalać, a drugi taką w której powinien, to rozwiązanie jest dość proste - wystarczy sprawdzać czy other nie jest pusty.
Warunek
if (Hlp_GetInstanceID(other) != -1)powinien załatwić sprawę.

Ewentualnie możesz go odwrócić, tzn po prostu na początku perceptiona dać
if (Hlp_GetInstanceID(other) == -1) { return ; };A dalej już zostawić normalny kod.

Swoją drogą tak dawno nie robiłem nic z Daedalusem że zapomniałem jak są tam obsługiwane nulle i null pointer exception. Przypomni ktoś? :D

Adanos

Adanos

Administrator
Szara eminencja
posty5204
Propsy3870
ProfesjaProgramista
  • Administrator
  • Szara eminencja

Adanos
Administrator

Zbroja, która ponosi uszkodzenia w trakcie walki
#81 2013-04-04, 18:00(Ostatnia zmiana: 2013-04-04, 18:04)
Null to 0, nie -1.

Przy nullach po prostu wywala z gry.

gothic1210
  • Gość
01001110 01101111 01110011 01111010 00100000 01101011 01110101 01110010 01110111 01100001
Nie działa. To znacz nie odejmuje, gdy blokujemy na sucho, ale gdy jesteśmy w trakcie walki (npc z wyciągniętą bronią biegnie w naszym kierunku) i zablokujemy ("na sucho" tyle, że w trakcie walki) to dalej odejmuje. Do tego ten Perc nie działa, gdy go dodamy do Startup lub skrypty PC_Hero! A wcześniej działał tyle, że tak jak ci mówiłem "przerywał działanie" (sprawdziłem to wtedy i przeciwnicy mieli odpowiedni typ obrażeń), więc dodałem go do wyzwalacza.
 

inż. Avallach

inż. Avallach

Administrator
posty7661
Propsy5239
NagrodyV
ProfesjaProgramista
  • Administrator
No to musisz znaleźć gdzie jest nadpisywany. O ile pamiętam była funkcja która na czas walki faktycznie zmieniała perceptiony.
Weź jeszcze wywal tamte printy i zamiast nich daj print(IntToString(Npc_GetBodyState(hero)));Aha, takie coś:
if ((Npc_GetBodyState(hero) != BS_PARADE) Prawie nigdy nie zadziała, bo bodystate to pole bitowe. Musisz sprawdzać konkretny bit a nie sumę. Robi to np C_BodyStateContains.

@Adanos: z tego co było na screenie gothic1210a, akurat funkcja Hlp_GetInstanceID kiedy jakoa argument poda się nulla, zwraca -1, a nie 0. Zresztą potwierdza to fakt iż jak napisał, ten warunek blokuje odejmowanie, ale tylko poza walką.
Chodziło mi o to czy da się znullować zmienną lub sprawdzić czy jest ona nullem (zgaduję że do tego drugiego może posłużyć właśnie Hlp_GetInstanceID).

gothic1210
  • Gość
Zastosowałem ten nowy warunek (!C_BodyStateContains(hero, BS_PARADE))  i niestety teraz znowu blok "na sucho" jest zbugowany. Co do tego printa to gdy blokujemy wyświetla liczbę 96304.
A co do tego nadpisywania to może to być spowodowane percami z ZS_Attack?
 

inż. Avallach

inż. Avallach

Administrator
posty7661
Propsy5239
NagrodyV
ProfesjaProgramista
  • Administrator
Jeśli dobrze sprawdzam, to ta liczba oznacza że jedynym aktywnym body statem jest ten o numerze 16, czyli BS_MOBINTERACT_INTERRUPT. Nieźle ten Goticzek zabugowany, przy próbie blokowania postać twierdzi że została zaatakowana, do tego zaprzecza żeby próbowała w ogóle blokować :lol2:
Chyba nic więcej się z tym nie zdziała, zostaje ostatnie rozwiązanie, czyli żeby śledzić hp bohatera.

Czyli:
var int lastHeroHP;
func void zs_heroassessdamage ()
{
if (hero.attribute[0] == lastHeroHP) { return; };
lastHeroHP = hero.attribute[0];

// ... dalszy ciąg skryptu ... ///

}
Do tego od razu licząc różnicę mógłbyś uzależnić straty wytrzymałości od ilości otrzymanych obrażeń. Byłyby wliczane co prawda obrażenia także od innych źródeł (mordercze jeżyny, tonięcie, upadki), ale to chyba nie jest taka wielka przeszkoda.

gothic1210
  • Gość
Działa! Propsy się należą. Odjęło tylko raz przy pierwszym blokowaniu. Potem juz przez dalszą grę tak się nie działo. Myślę, że da się to przeżyć. Tylko teraz co zrobić z tym zapisywaniem zużycia, bo ono się resetuje przy wczytaniu sejwa.
 

pawbuj

pawbuj

Użytkownicy
posty1625
Propsy135
ProfesjaSkrypter
  • Użytkownicy
Działa! Propsy się należą. Odjęło tylko raz przy pierwszym blokowaniu. Potem juz przez dalszą grę tak się nie działo. Myślę, że da się to przeżyć. Tylko teraz co zrobić z tym zapisywaniem zużycia, bo ono się resetuje przy wczytaniu sejwa.
nie pozostaje nic innego jak tylko zmienna. Jednak jeżeli chcesz modyfikowac ochronę to musisz tworzyć kolejne zbroje.

Av, nazwa funkcji zs_assessherodmagae musi taka pozostać, czy może być dowolna i czy  liczy się tylko warunek?

dobra zrobiłem. czy możesz opisać nieco działanie tego warunku?
 

inż. Avallach

inż. Avallach

Administrator
posty7661
Propsy5239
NagrodyV
ProfesjaProgramista
  • Administrator
Nazwa dowolna, byleby taka jaką podasz w Npc_PercEnable.
Co do działania warunku to zdawało mi się że jest on banalnie prosty :D  Proponuję tylko po namyśle troszkę go zmienić:
var int lastHeroHP;
func void zs_heroassessdamage ()
{
if (hero.attribute[0] == lastHeroHP) { return; }
else if (hero.attribute[0] > lastHeroHP) { lastHeroHP = hero.attribute[0]; return; }
lastHeroHP = hero.attribute[0];

// ... dalszy ciąg skryptu ... ///

}
Dzięki temu nie będzie się niepotrzebnie wywoływało kiedy się... poleczy, a potem dla jaj zrobi blok przed niczym.

Sprawdzamy czy hero ma co równo tyle życia co kiedy sprawdzaliśmy ostatnio. Jak ma, to olewamy sprawę, bo to znaczy że nic się nie stało i trolluje skryptera robiąc bloki przed niczym (co za pajac) (returnem wychodzimy z funkcji).
Jak ma więcej hp niż miał, to znaczy że się poleczył, a potem zrobił ten blok dla zabawy. Też wychodzimy z funkcji, ale najpierw sobie zapisujemy te jego nowe hp.
Jak ma mniej niż ostatnio, to uznajemy że naprawdę ktoś go obił. Zapisujemy sobie jego aktualne życie i przechodzimy do dalszej części funkcji, czyli m.in. psucia zbroi.

Sposób nie jest idealny - nie zadziała kiedy gracz najpierw się poleczy, a potem oberwie, ale za ilość punktów mniejszą niż się poleczył. Ale to raczej niezauważalne, zresztą nie powinien mieć o coś takiego pretensji.

Skoro Gothic nie zapamiętuje parametrów przedmiotów, to faktycznie dla każdej psującej się zbroi trzeba zrobić osobną zmienną i modyfikować odpowiednią z nich. Ewentualnie możnaby wykorzystać trick z identyfikatorami obiektów (ostrzegam że będzie się on wydawał dość dziwny, ale jak chcecie to mogę opisać). Wymagałby tylko żeby wszystkie zbroje były w jednym pliku i żeby na stałe ustalić która będzie na jego początku i która na końcu (te pomiędzy bez znaczenia).

//edit: aha, no ale że takie rozwiązanie będzie pamiętało nie konkretną instancję, a jedynie identyfikator, to wszystkie egzemplarze zbroi o danym identyfikatorze będą się psuć jednakowo. Także wymagałoby to założenia że bohater będzie miał tylko po jednym egzemplarzu z każdej.

pawbuj

pawbuj

Użytkownicy
posty1625
Propsy135
ProfesjaSkrypter
  • Użytkownicy
Nazwa dowolna, byleby taka jaką podasz w Npc_PercEnable.
Co do działania warunku to zdawało mi się że jest on banalnie prosty :D  Proponuję tylko po namyśle troszkę go zmienić:
var int lastHeroHP;
func void zs_heroassessdamage ()
{
if (hero.attribute[0] == lastHeroHP) { return; }
else if (hero.attribute[0] > lastHeroHP) { lastHeroHP = hero.attribute[0]; return; }
lastHeroHP = hero.attribute[0];

// ... dalszy ciąg skryptu ... ///

}

czy jest możliwość modyfikacji tego skryptu do wyświetlania ilości otrzymanych obrażeń?

trochę poza tematem: brakuje na forum porządnego tutka na temat tricków z vobami (insertowanie, usuwanie, przemieszczanie jako npc).
 

inż. Avallach

inż. Avallach

Administrator
posty7661
Propsy5239
NagrodyV
ProfesjaProgramista
  • Administrator
Noo tak, tylko nie będzie to uwzględniało zmian hp pochodzących ze źródeł innych niż zranienia, więc czasami pierwszy cios w walce będzie wyświetlał złą wartość (następne już poprawną, chyba że w trakcie gracz się poleczy).
var int lastHeroHP;
func void zs_heroassessdamage ()
{
   if (hero.attribute[0] < lastHeroHP)
   {
      print (IntToString(lastHeroHP - hero.attribute[0]));
      lastHeroHP = hero.attribute[0];
   }
}

Co do tego co piszesz o vobach, kiedyś planowałem taki prosty system który używałby po prostu nowych, prawie pustych mds'ów z ustawionym statycznym meshem. Efektem byłby przykładowo "potwór" (c_npc) w kształcie wózka, który miałby ustawioną rutynę "jazdy" po torach (z waypointami). Do tego wystarczyłoby mu wyłączyć AI i możliwość nacelowywania / ranienia (dość proste).

pawbuj

pawbuj

Użytkownicy
posty1625
Propsy135
ProfesjaSkrypter
  • Użytkownicy
funkcja wywoływna jest zs_attack, jednak nie działa w przypadku ataków monsterów, nie wiem czemu. func void ZS_Attack ()
{
PrintDebugNpc (PD_ZS_FRAME, "ZS_Attack" );
C_ZSInit ();

PrintGlobals (PD_ZS_FRAME);
Npc_PercEnable   (self, PERC_ASSESSMURDER, B_CombatAssessMurder );
Npc_PercEnable   (self, PERC_ASSESSDEFEAT, B_CombatAssessDefeat );
Npc_PercEnable   (self, PERC_ASSESSDAMAGE, B_CombatReactToDamage );
Npc_PercEnable   (hero, PERC_ASSESSDAMAGE, pancerz );
Npc_PercEnable   (self, PERC_ASSESSSURPRISE , ZS_AssessSurprise );
Npc_PercEnable   (self, PERC_ASSESSMAGIC, B_AssessMagic );
Npc_PercEnable (self, PERC_ASSESSREMOVEWEAPON , B_CombatRemoveWeapon );
Npc_PercEnable (self, PERC_ASSESSENTERROOM , B_CombatAssessEnterRoom );
Npc_PercEnable (self, PERC_CATCHTHIEF , B_CombatCatchThief );
   
 


Sawik

Sawik

Moderator działu
Rebel
posty4772
Propsy3197
ProfesjaNierób
  • Moderator działu
  • Rebel
[ramka]
func void ZS_Attack ()
{   
   PrintDebugNpc      (PD_ZS_FRAME, ZS_Attack );      
   C_ZSInit         ();

   PrintGlobals      (PD_ZS_FRAME);
   Npc_PercEnable     (self,   PERC_ASSESSMURDER,         B_CombatAssessMurder   );   
   Npc_PercEnable     (self,   PERC_ASSESSDEFEAT,         B_CombatAssessDefeat   );
   Npc_PercEnable     (self,   PERC_ASSESSDAMAGE,         B_CombatReactToDamage   );
   Npc_PercEnable     (hero,   PERC_ASSESSDAMAGE,                     pancerz   );
   Npc_PercEnable     (self,    PERC_ASSESSSURPRISE   ,      ZS_AssessSurprise      );
   Npc_PercEnable     (self,    PERC_ASSESSMAGIC,         B_AssessMagic         );         
   Npc_PercEnable      (self,   PERC_ASSESSREMOVEWEAPON   ,   B_CombatRemoveWeapon   );
   Npc_PercEnable      (self,   PERC_ASSESSENTERROOM   ,   B_CombatAssessEnterRoom   );
   Npc_PercEnable      (self,   PERC_CATCHTHIEF         ,   B_CombatCatchThief      );
[/ramka]
O to mu chyba chodzi.
 
Życzę wam seksu analnego po stronie biernej.
Dropbox +500 mb na start
LowPoly
Wykonanie modelu niskopoligonowego to sztuka kompromisu. Nie jest to jedynie uproszczenie modelu wysokopoligonowego, ale głęboka modyfikacja oraz podejmowanie decyzji często zmieniających wygląd pierwotny obiektu, tak by przy najmniejszej ilości trójkątów uzyskać jak najwierniej odwzorowany kształt oryginału. Nie można też zapomnieć o tym iż musi nadal wyglądać przekonywająco i tak balansować by uzyskać efekt optymalny.

Podstawowym założeniem jest, że model nie powinien mieć zbędnych, niewidocznych dla gracza detali włączonych w geometrie. Większość obiektów jakie znajdują się w grze powinna prezentować się najlepiej z odległości około 3-5 metrów. Wszelkie detale, które zanikają, wydają się płaskie lub zlewają się z bryłą modelu należy uznać za zbędne i pozostawić je na normal mapie.

Fakt, iż gracz będzie w stanie podejść bliżej do obiektu i zobaczyć go z mniejszej niż 3m odległości nie powinno stanowić większego problemu, gdyż większą rolę odgrywają wtedy tekstury oraz dodatkowy detal zależny od materiału obiektu. To właśnie kompromis między wydajnością, a szczegółowością otoczenia.

Detal, którego nie widać z 3-5 metrów nie powinnien istnieć w geometrii modelu.
Krawędzie znajdujące się blisko siebie, które zlewają się z większej odległości należy uprościć do wspólnej płaszczyzny

pawbuj

pawbuj

Użytkownicy
posty1625
Propsy135
ProfesjaSkrypter
  • Użytkownicy
 


pawbuj

pawbuj

Użytkownicy
posty1625
Propsy135
ProfesjaSkrypter
  • Użytkownicy
Nie, bo nie zrozumiałem twojego zdania.
w każdym świecie mamy jakieś potwory , które mają funkcję ataku. dodaję perceptiona assessdamage dla bohatera do zs_attack , ale tylko sporadycznie działa w przypadku ataku monsterów.
 


pawbuj

pawbuj

Użytkownicy
posty1625
Propsy135
ProfesjaSkrypter
  • Użytkownicy
Bo później ten perception może być u bohatera znowu nadpisywany. To dość złożony system.
ale dla ludzi działa.
 

Sawik

Sawik

Moderator działu
Rebel
posty4772
Propsy3197
ProfesjaNierób
  • Moderator działu
  • Rebel
Bo później ten perception może być u bohatera znowu nadpisywany. To dość złożony system.
ale dla ludzi działa.
ZS_MM_ATTACK.
Potwory mają osobny ZS.
 
Życzę wam seksu analnego po stronie biernej.
Dropbox +500 mb na start
LowPoly
Wykonanie modelu niskopoligonowego to sztuka kompromisu. Nie jest to jedynie uproszczenie modelu wysokopoligonowego, ale głęboka modyfikacja oraz podejmowanie decyzji często zmieniających wygląd pierwotny obiektu, tak by przy najmniejszej ilości trójkątów uzyskać jak najwierniej odwzorowany kształt oryginału. Nie można też zapomnieć o tym iż musi nadal wyglądać przekonywająco i tak balansować by uzyskać efekt optymalny.

Podstawowym założeniem jest, że model nie powinien mieć zbędnych, niewidocznych dla gracza detali włączonych w geometrie. Większość obiektów jakie znajdują się w grze powinna prezentować się najlepiej z odległości około 3-5 metrów. Wszelkie detale, które zanikają, wydają się płaskie lub zlewają się z bryłą modelu należy uznać za zbędne i pozostawić je na normal mapie.

Fakt, iż gracz będzie w stanie podejść bliżej do obiektu i zobaczyć go z mniejszej niż 3m odległości nie powinno stanowić większego problemu, gdyż większą rolę odgrywają wtedy tekstury oraz dodatkowy detal zależny od materiału obiektu. To właśnie kompromis między wydajnością, a szczegółowością otoczenia.

Detal, którego nie widać z 3-5 metrów nie powinnien istnieć w geometrii modelu.
Krawędzie znajdujące się blisko siebie, które zlewają się z większej odległości należy uprościć do wspólnej płaszczyzny


0 użytkowników i 1 Gość przegląda ten wątek.
0 użytkowników
Do góry