Pulse Phone

Nie. Gdy działa oxmysql, mysql-async albo ghmattimysql, telefon tworzy swoje tabele przy pierwszym starcie i po każdej aktualizacji sam dodaje nowe tabele, kolumny i indeksy. phone.sql jest dołączony, jeśli twój hosting nie pozwala resource'om tworzyć tabel.

Jeśli inny telefon zostawił tabele o tych samych nazwach, są one przemianowywane na old_<name> zamiast używane ponownie, i nic nie jest usuwane. Mimo to zrób kopię zapasową bazy przed pierwszym startem.

Bez oxmysql, mysql-async albo ghmattimysql telefon zapisuje wszystko w magazynie key/value serwera, który jest trwały, ale nie da się go odpytywać; powyżej około 30 graczy używaj bazy danych. Jeśli resource SQL działa, ale baza nigdy nie odpowiada, telefon nic nie zapisuje, dopóki nie odpowie, i informuje o tym w konsoli.

Skrypty, które wysyłają maile, wiadomości i alerty przez eventy tamtych telefonów, działają dalej. Poradnik importu pokazuje, co się przenosi i co trzeba zmienić.

Skrypty, które komunikują się z telefonem przez eventy, działają dalej bez zmian. Pulse odpowiada na lb-phone:getPhoneNumber, lb-phone:sendMail, lb-phone:sendMessage i lb-phone:notification; qb-phone:server:GetPhoneNumber, qb-phone:server:sendNewMail, qb-phone:server:sendNewMessage i qb-phone:server:sendNotification; npwd:getPhoneNumber, npwd:sendMail, npwd:sendMessage i npwd:notification; oraz na odpowiadające im nazwy qs-smartphone, gcphone, esx_phone, high_phone i roadphone, wszystko po stronie serwera i wbudowane.

Aplikacje zbudowane pod API własnych aplikacji lb-phone działają bez zmian przez resource kompatybilności z zestawu deweloperskiego (poradnik własnych aplikacji, sekcja 11). Skrypt, który wywołuje eksporty innego telefonu, wymaga zmiany jednej linii na exports.phone; odpowiednie wywołania znajdziesz w poradniku eksportów.

Nie. Intercept pokazuje SMS-y wysyłane z i do podsłuchiwanego numeru oraz historię jego połączeń (kto do kogo dzwonił, czy odebrano, ile trwała rozmowa), na żywo i w logu. Dźwięk rozmów nigdy nie jest przechwytywany: resource'y głosowe nie mają kanału tylko do słuchania, na którym telefon mógłby polegać, więc nie udaje, że go ma.

Z obsługiwanym skryptem housingu tylko w domu, który gracz posiada albo do którego ma klucz, łącznie z domami typu shell. Bez skryptu housingu w dowolnym wnętrzu. Możesz to zmienić w config/wifi.lua albo dodać własną regułę przez exports.phone:SetRouterPlacementCheck.

Tak. W rozmowie wideo może brać udział do ośmiu osób, a rozmowa trwa dalej, gdy gospodarz wyjdzie. Połączenia głosowe też pozwalają zawieszać, przełączać i łączyć kilka osób.

pma-voice, mumble-voip, SaltyChat, TokoVOIP i YACA, wykrywane automatycznie. Bez resource'a głosowego połączenia się łączą, ale nie ma dźwięku.

Dźwięk w transmisji Live wymaga pma-voice albo mumble-voip: na SaltyChat, TokoVOIP i YACA Live ma tylko obraz i czat, a widzowie są o tym informowani. Aplikacja Radio nie działa z YACA. Pełna tabela jest w Połączenia, wideo i Live.

Każdy telefon to jeden model, kolorowany z palety, więc wszystkie razem streamują około 21 MB, wcześniej było to około 205 MB.

Resource zawiera plik docs/PERFORMANCE.md, w którym są czasy zapytań zmierzone na bazie danych wypełnionej mniej więcej pół rokiem gry (1200 urządzeń, 1,99 mln wiadomości). Na przykład wczytanie Recents przy starcie trwało 1,5 ms, przy domyślnym buffer pool MariaDB wynoszącym 128 MB. Plik nie podaje, na jakim wydaniu mierzono, a tych czasów nie zmierzono ponownie na 1.4. Twoje wyniki zależą od bazy danych i sprzętu; na dużym serwerze daj MySQL porządny buffer pool.

ESX Legacy, QBCore, Qbox, ox_core, ND Core, TMC i vRP 2 są wykrywane automatycznie. Bez frameworka działa w trybie standalone, przypisując telefony do licencji gracza i z własnym bankiem.

Każdy inny framework, także własny, podłączysz przez własny mostek frameworka: tabelę funkcji w kształcie developers/custom_framework_bridge.lua, ustawioną w configu albo zarejestrowaną z twojego resource'a w Lua lub JS przez exports.phone:RegisterFrameworkBridge. Wymagane jest tylko id postaci.