Bug raport - zglaszanie bledow w grze

[marol]

Te 4. punkty to ja z palca wyssałem. Nie zaglądałem do tego kodu i w rzeczywistości może ta kolejność wyglądać inaczej, tak więc rozważania na temat szczegółów możemy sobie darować . Chciałem tylko pokazać wam, w czym tkwi problem.

A jak się to powtórzy kilka razy, to wtedy się tym zajmiemy; na razie szkoda czasu na to.

[Raist]

Albo mozna nadac kazdemu przedmiotowi dodatkowy parametr w stylu aktywny/nieaktywny. Ktos zaczyna proces podnoszenia i algorytm nadaje przedmiotowi status nieaktywny (zablokowany) i juz nikt nie moze go podnoscic. Po zakonczeniu algorytmu spowrotem nastepuje zmiana na aktywny.

[WojD]

To kilka zapytań do bazy - i tez beda kolizje... Chyba rzeczywiście lepiej to teraz zostawic. MySQL jest niezłą bazą - jednak ciągle wiele do zyczenia pozostawia przy tak rozbudowanych systemach. Jak musze pisać zapytania z wielokrotnym sprawdzaniem to tez mnie lekki szlag trafia

[marol]

Albo mozna nadac kazdemu przedmiotowi dodatkowy parametr w stylu aktywny/nieaktywny. Ktos zaczyna proces podnoszenia i algorytm nadaje przedmiotowi status nieaktywny (zablokowany) i juz nikt nie moze go podnoscic. Po zakonczeniu algorytmu spowrotem nastepuje zmiana na aktywny.

Raist, to niczego nie rozwiązuje, bo żeby nadać status 'nieaktywny' trzeba najpierw sprawdzić, czy już ktoś go wcześniej nie nadał. Tak więc można sobie wyobrazić, że między sprawdzeniem, a nadaniem statusu nieaktywnego ktoś inny może też zacząć podnosić i w ten sposób może się zdarzyć, że dwaj gracze będą po sprawdzeniu, a przed zmianą statusu.

Ten błąd to klasyczne zadanie z teorii programowania współbieżnego. Jest na to w miarę proste rozwiązanie, więc nie musicie kombinować. Niezależnie od tego błąd ten na razie nie będzie naprawiany.

[Diabelek]

A tak z ciekawosci - mozesz powiedzec jaki sposob?

[marol]

Jeśli chodzi o ogólne rozwiązanie, to trzeba pogooglać, na przykład tak: "critical section" solution

Jednak w tym przypadku rozwiązanie jest nieklasyczne i opiera się na tym, iż zmiana położenia klucza odbywa się w następujący sposób:

Code: Select all

UPDATE objects SET location=:player_inventory WHERE id=:object_id

Wystarczy zmienić na:

Code: Select all

UPDATE objects SET location=:player_inventory WHERE id=:object_id AND location=:on_the_ground

Nie zostanie jednak ono zastosowane, gdyż rozważamy przeniesienie Cantr na MySQL 4.1 lub wyższe, które wspiera transakcyjność, co całkowice rozwiązuje sprawę bez żadnej pracy z naszej strony.

Wystarczy?

[WojD]

Czemu nie od razu do 5? To już prawdziwa baza jest

[marol]

Czemu nie od razu do 5? To już prawdziwa baza jest

(...) przeniesienie Cantr na MySQL 4.1 lub wyższe (...)

[WojD]

jasne... TNX

[Diabelek]

Mi wystarczy, dziekuje.

[belin]

Jedna z moich postaci znalazla miejsce gdzie dwie drogi prowadzace w jednym kierunku (np. wschodnim) wioda w dwa rozne miejsca... taaa... bug czy tez rozwidlenie po drodze? Nie chce mi sie pojsc i trafic w jakis matrix ;-D
Z planu jaki sobie stworzylem jeden "wchod" sie zgadza, natomiast drugi powinien byc raczej "polnocnym-wschodem".

[Sigvald]

Cos takiego jest zdaje się też na wyspie Davloz-Dervaz. Z davloz woods e dwie drogi są opisane jako kierunek zachodni.

[belin]

No to teraz czekamy na odpowiedz "wiedzacych"

[marol]

Dlaczego dwa miejsca nie miałyby być w tym samym kierunku? Jeśli dzielimy wszystkie możlie kierunki na 16 przedziałów, to czasami zdarza się, że dwa z nich znajdą się w tym samym przedziale.

[Raist]

Dlaczego dwa miejsca nie miałyby być w tym samym kierunku? Jeśli dzielimy wszystkie możlie kierunki na 16 przedziałów, to czasami zdarza się, że dwa z nich znajdą się w tym samym przedziale.

Nie uwazasz ze nazwy drog sa odzwierciedleniem tego co widzi nasza postac patrzac na rozwidlenia? Powinna byc mozliwosc rozroznienia tych 2 kierunkow.