AbeStrefa RP jest projektem roleplayowym i symulacją zarządzania zespołem wyścigowym. Stan świata wynika z danych zapisanych w panelu, wyników symulacji oraz decyzji administracji.

• Każda decyzja wykonana i zapisana w panelu może wpływać na dalszy przebieg sezonu.
• Element fabularny nie może nadpisywać stanu systemu, jeśli administracja nie zatwierdziła takiej zmiany.
• W przypadku rozbieżności obowiązuje stan widoczny w bazie i panelu po ostatniej zatwierdzonej korekcie.

Każdy uczestnik korzysta z systemu zgodnie z jego przeznaczeniem.

• Nie wolno świadomie powielać operacji wskutek błędu, odświeżenia lub wielokrotnego kliknięcia.
• Nie wolno obchodzić limitów projektów, budżetu, kontraktów, terminów ani uprawnień.
• Zauważony błąd, który może dać przewagę, należy zgłosić administracji zamiast go wykorzystywać.
• Korzyści uzyskane wskutek oczywistego błędu mogą zostać cofnięte.

Podstawowym źródłem prawdy jest baza danych projektu.

• Screen, wiadomość na Discordzie lub ustne ustalenie nie zastępują zapisu w panelu, jeśli nie zostały później wdrożone.
• Administracja może dokonać korekty, gdy dane zostały zapisane błędnie lub system wykonał operację niezgodnie z założeniem.
• Korekta powinna przywracać stan, który wystąpiłby bez błędu, a nie przyznawać dodatkową korzyść.

Regulamin może być aktualizowany wraz z rozwojem panelu.

• Nowa funkcja może otrzymać dodatkowe zasady po jej wdrożeniu.
• Administracja może doprecyzować niejasną sytuację, jeśli regulamin nie opisuje jej wprost.
• Zmiany mające istotny wpływ na rozgrywkę powinny zostać zakomunikowane uczestnikom.

Każdy manager działa na własnym koncie i w ramach przypisanego zespołu.

• Nie wolno wykonywać operacji w imieniu innego managera bez zgody administracji.
• Dane dostępne w panelu zespołu należy traktować jako dane należące do tego zespołu.
• Zmiana managera zespołu wymaga ingerencji administracji.

Administrator posiada dodatkowe narzędzia służące do prowadzenia sezonu i naprawiania danych.

• Administrator może edytować kalendarz, wyniki, kontrakty i ustawienia świata.
• Administrator może wyczyścić błędnie zapisane wyniki albo poprawić dane historyczne.
• Narzędzia administracyjne nie są elementem przewagi sportowej żadnego zespołu.

Tryb widza pokazuje publiczną część świata bez narzędzi zarządzania.

• W trybie widza nie powinny być dostępne prywatne akcje zespołu ani kontrolki administracyjne.
• Publiczne klasyfikacje, wyniki, kalendarz, newsy i pozostałe sekcje mogą być przeglądane bez wpływania na stan gry.

Operacje rozwojowe objęte blokadą można wykonywać tylko wtedy, gdy okno zarządzania jest otwarte.

• Status okna jest wspólny dla uczestników i sterowany przez administrację.
• Jeśli przycisk jest zablokowany przez zamknięte okno, operacja nie powinna zostać wykonana inną drogą.

Po zamknięciu okna rozwój i akcje objęte blokadą czekają na kolejny okres zarządzania.

• Zamknięcie nie cofa wcześniej rozpoczętych projektów.
• Nie można rozpocząć nowej operacji po zamknięciu tylko dlatego, że gracz pozostawił wcześniej otwartą kartę.

Numer sezonu i rundy w systemie wyznacza działanie projektów, terminów i historii.

• Projekt rozpoczęty w określonej rundzie zachowuje tę rundę jako punkt startowy.
• Runda ukończenia projektu wynika z parametrów zapisanych w momencie rozpoczęcia.
• Zmiana aktualnej rundy przez administrację powinna następować zgodnie z przebiegiem sezonu.

Jeżeli błąd techniczny uniemożliwił wykonanie poprawnej operacji przed terminem, sprawa może zostać zweryfikowana indywidualnie.

• Gracz powinien zgłosić problem możliwie szybko i opisać, jaką operację próbował wykonać.
• Administracja może odtworzyć operację tylko wtedy, gdy da się wiarygodnie potwierdzić, że powinna zostać wykonana przed terminem.

Nazwa, logo, dywizja i pozostałe dane zespołu widoczne w panelu są oficjalnymi danymi świata.

• Zmiany wymagające administracji obowiązują po zapisaniu.
• Logo i identyfikacja wizualna nie wpływają na osiągi sportowe.

Aktualny skład wynika z ważnych aktywnych kontraktów kierowców.

• Kierowca należy sportowo do zespołu wskazanego przez aktywną umowę.
• Sama plotka transferowa ani rozpoczęta negocjacja nie zmieniają składu.

Podpisane kontrakty przyszłego sezonu tworzą przyszły skład zespołu.

• Kierowca może pozostać w obecnym zespole do końca bieżącej umowy mimo podpisanej przyszłej umowy.
• Panel przyszłego składu służy do rozróżnienia obecnego i kolejnego sezonu.

W przypadku rezygnacji managera administracja zabezpiecza ciągłość sezonu.

• Zespół może zostać tymczasowo zamrożony, przejęty lub przekazany nowemu managerowi.
• Dotychczasowe zobowiązania zespołu nie znikają automatycznie wraz ze zmianą managera.

Kontrakt jest wiążący, gdy został poprawnie zapisany i posiada właściwy status dla danego sezonu.

• Umowa określa zespół, okres obowiązywania i wynagrodzenie kierowcy.
• Aktywna umowa dotyczy bieżącego składu, a future_signed przyszłego sezonu.
• Po wygaśnięciu umowy kierowca nie pozostaje automatycznie w zespole bez kolejnego kontraktu.

Przedłużenie jest oficjalne dopiero po zaakceptowaniu negocjacji przedłużeniowej.

• Status negocjacji inny niż accepted nie oznacza podpisanej umowy.
• Kontroferta oznacza, że rozmowy trwają.
• Po zaakceptowaniu system może utworzyć lub aktywować odpowiedni kontrakt przyszłego sezonu.
• Każde zaakceptowane przedłużenie może pojawić się w Aktualnościach jako informacja oficjalna.

Zespół nie może posiadać więcej zakontraktowanych miejsc niż przewiduje struktura składu.

• System może zablokować kolejną umowę, jeśli miejsca na przyszły sezon są już zajęte.
• Błędnie utworzony nadmiarowy kontrakt podlega korekcie administracyjnej.

Historia kontraktów i negocjacji służy do weryfikacji przebiegu rynku.

• Błędny wpis może zostać usunięty przez administratora.
• Korekta nie może zmieniać warunków poprawnie zawartej umowy bez podstawy wynikającej z zasad lub wcześniejszego ustalenia.

Wysłanie oferty lub zapytania rozpoczyna proces, ale nie jest transferem.

• Do czasu akceptacji kierowca pozostaje w swoim dotychczasowym stanie kontraktowym.
• Oferta może zostać zaakceptowana, odrzucona lub skontrowana.

Kontroferta zastępuje pierwotne warunki propozycją wymagającą kolejnej decyzji.

• Nie wolno traktować statusu countered jako potwierdzonego transferu ani przedłużenia.
• Dopiero końcowa akceptacja tworzy skutek kontraktowy.

Transfer staje się oficjalny po domknięciu procesu i zapisaniu nowej umowy.

• Każdy sfinalizowany transfer powinien być traktowany jako informacja oficjalna.
• Oficjalny transfer może automatycznie trafić do Aktualności.
• Sama obecność nazwiska w plotkach lub newsie nie zmienia danych kontraktowych.

Wiążąca przyszła umowa ogranicza możliwość podpisania konkurencyjnej umowy na ten sam sezon.

• Panel może zablokować rozpoczęcie negocjacji, jeśli kierowca ma już zajęty przyszły sezon.
• W razie konfliktu dwóch wpisów pierwszeństwo ma poprawnie zawarta i wcześniej zapisana wiążąca umowa, chyba że administracja stwierdzi błąd.

Plotka transferowa nie jest dowodem trwających rozmów.

• Sekcja Plotki może zawierać informację opartą na realnych negocjacjach.
• Może również zawierać całkowicie zmyślony paddockowy fake news.
• Widz nie otrzymuje informacji, która z tych dwóch sytuacji występuje.
• Do momentu oficjalnego komunikatu wszystkie takie wpisy należy traktować jako niepotwierdzone.

Budżet zespołu jest podstawowym ograniczeniem wszystkich płatnych operacji.

• Koszty projektów, rozbudowy i innych działań są pobierane zgodnie z wartościami panelu.
• Manager odpowiada za pozostawienie środków na planowane działania.
• Operacja, której nie da się poprawnie sfinansować, nie powinna być zatwierdzana.

Koszt widoczny przy projekcie obowiązuje w chwili jego uruchomienia.

• Niepowodzenie projektu nie oznacza automatycznego zwrotu kosztu.
• Jeżeli system pobrał koszt podwójnie przez błąd, administracja może skorygować saldo.

Wynagrodzenia kierowców wynikają z zapisanych kontraktów.

• Przy planowaniu przyszłego sezonu należy uwzględniać przyszłe kontrakty.
• Błędna wartość pensji może zostać poprawiona wyłącznie zgodnie z właściwą umową.

Nieprawidłowe naliczenie może zostać naprawione po sprawdzeniu historii.

• Dotyczy to m.in. podwójnego obciążenia, braku należnego przychodu albo błędnej korekty.
• Naprawa ma przywrócić prawidłowe saldo, a nie tworzyć dodatkową premię.

Każdy zespół posiada przypisaną wersję i wariant umowy sponsorskiej widoczny w panelu.

• Wariant może wpływać na kwotę stałą oraz warunki premii.
• Dla F1 i F2 stosowane są właściwe dla dywizji zestawy zasad.
• Jeżeli zespół ma indywidualnie ustalony wyjątek, obowiązuje zapis widoczny przy tym zespole.

Stała kwota roczna jest bazową wartością wynikającą z umowy.

• Jej wysokość wynika z zapisanej wersji kontraktu.
• Nie należy samodzielnie zmieniać wariantu ani kwoty poza narzędziem przeznaczonym do tego celu.

Premie wynikowe wynikają z warunków przypisanych do umowy i osiągnięć zespołu.

• Warunki należy interpretować zgodnie z opisem widocznym w panelu.
• Premia może być aktualizowana po osiągnięciu warunku.
• Jeśli wartość jest ręcznie zatwierdzana przez administrację, obowiązuje ostatnia zapisana wartość.

Premia sezonowa dotyczy warunków końcowych sezonu.

• Jest rozliczana po ustaleniu końcowej klasyfikacji, jeśli warunek umowy tego wymaga.
• Korekta końcowej klasyfikacji może wymagać ponownego przeliczenia premii.

Osiągi samochodu są opisane zestawem parametrów zapisanych w systemie.

• Zmiany parametrów wynikają z poprawnie ukończonych projektów i korekt administracyjnych.
• Publiczna zakładka Bolidy prezentuje aktualny stan i porównanie dywizji.
• Nie należy wyciągać wartości parametrów z zewnętrznych danych rzeczywistej Formuły 1, jeśli nie są częścią projektu.

Zmiany osiągów mogą być prezentowane historycznie, aby pokazać rozwój zespołu.

• Historia nie zastępuje aktualnego stanu bolidu.
• Błędna historyczna wartość może zostać poprawiona, jeśli wynikała z błędnego projektu.

Projekt można uruchomić, jeśli jest dostępny i spełnione są jego wymagania.

• Przed uruchomieniem gracz powinien sprawdzić koszt, czas, szansę powodzenia i efekt.
• Jeżeli projekt posiada wymagany poprzedni węzeł, musi on zostać ukończony zgodnie z logiką systemu.
• Projekt zapisany jako rozpoczęty jest wiążącą decyzją rozwojową.

Projekt z szansą poniżej 100% może zakończyć się niepowodzeniem.

• Niepowodzenie jest prawidłowym wynikiem mechaniki, jeśli losowanie zostało wykonane poprawnie.
• Koszt nie jest automatycznie zwracany tylko dlatego, że projekt się nie udał.
• Fabryka może zwiększać efektywną szansę sukcesu zgodnie z parametrami panelu.

Każdy projekt posiada rundę rozpoczęcia i wyliczoną rundę ukończenia.

• Efekt projektu nie działa przed ukończeniem.
• Modyfikator fabryki może skracać czas zgodnie z systemem.
• Zmiana aktualnej rundy nie powinna ręcznie zmieniać już zapisanego harmonogramu bez przyczyny.

Zespół może prowadzić tylko liczbę równoległych projektów dozwoloną przez aktualne parametry infrastruktury.

• Do limitu mogą wliczać się projekty obecnego i kolejnego sezonu.
• Nie wolno uruchamiać projektu przez obejście interfejsu, jeśli limit został osiągnięty.

Udany projekt po ukończeniu zmienia odpowiednie parametry samochodu.

• Efekt powinien zostać naliczony jeden raz.
• Podwójne naliczenie wskutek błędu podlega cofnięciu.
• Nieudany projekt powinien pozostać w historii jako nieudany.

Poziom fabryki wpływa na możliwości produkcyjne zespołu.

• Może wpływać na liczbę równoległych projektów, czas produkcji i szansę powodzenia.
• Obowiązują dokładne wartości wyświetlane dla danego poziomu.

Modernizacja wymaga kosztu i czasu określonego w panelu.

• Nowy poziom zaczyna działać dopiero po ukończeniu rozbudowy.
• W czasie modernizacji system może pokazywać cel rozbudowy i rundę ukończenia.
• Nie należy ręcznie przyjmować bonusów wyższego poziomu przed zakończeniem.

Zmiany poziomu infrastruktury są częścią historii zespołu.

• Historia może służyć do sprawdzania, czy dany projekt powinien mieć określony czas lub szansę.
• Błędny status trwającej rozbudowy może zostać naprawiony administracyjnie.

Zespół może inwestować w przygotowanie samochodu na następny sezon, jeśli funkcja jest dostępna.

• Każdy projekt ma wskazany sezon docelowy.
• Projekt następnego sezonu nie poprawia automatycznie bieżącego samochodu.

Projekty przyszłego sezonu mogą neutralizować część wpływu zmian regulacyjnych.

• Wartość neutralizacji wynika z ukończonych projektów danej gałęzi.
• Nie należy sumować efektu projektu, który nie został ukończony pomyślnie.

Rozwój bieżący i przyszły może korzystać ze wspólnego limitu projektów.

• Jeżeli system pokazuje pełne wykorzystanie mocy produkcyjnych, kolejny projekt musi poczekać.
• Rozbudowa fabryki może zmienić ten limit po jej ukończeniu.

Daty, nazwy rund, tory i flagi zapisane w Kalendarzu stanowią oficjalny harmonogram sezonu.

• Administracja może zmienić termin rundy, jeśli wymaga tego organizacja sezonu.
• Po zapisaniu nowego terminu system korzysta z nowej daty do statusu rundy.

System automatycznie wskazuje najbliższą rundę na podstawie czasu.

• Najbliższa przyszła runda jest wyróżniona niebieskim stylem.
• Po minięciu jej terminu kolejna przyszła runda przejmuje status najbliższej.

Rundy, których termin już minął, są oznaczane jako zakończone.

• Zakończona runda otrzymuje czerwone wyróżnienie.
• Sam upływ daty nie tworzy wyników wyścigu — wyniki muszą zostać zapisane i opublikowane.

TOP 3 rundy jest powiązane z opublikowanym wynikiem wyścigu F1.

• Po zapisaniu i opublikowaniu wyników miejsca 1–3 uzupełniają się automatycznie.
• Ponowne zapisanie poprawionych wyników aktualizuje TOP 3.
• Wymazanie wyników wyścigu F1 usuwa powiązane TOP 3.

Administrator zapisuje wyniki właściwej dywizji, rundy i sesji.

• Kierowca powinien być przypisany do prawidłowej pozycji.
• W wyścigu można zapisać punkty odpowiadające rzeczywistemu rozstrzygnięciu symulacji w ramach projektu.
• Wyniki F1 i F2 są od siebie niezależne.

Publiczne klasyfikacje bazują na opublikowanych wynikach wyścigu.

• Zapis roboczy nie powinien wpływać na publiczną klasyfikację, jeśli sesja nie została opublikowana.
• Kwalifikacje i wyścig są oddzielnymi sesjami.

Administrator może wyczyścić całą konkretną sesję przyciskiem „Wymaż wyniki”.

• Operacja usuwa zapisane pozycje i punkty danej sesji.
• Sesja wraca do stanu nieopublikowanego.
• W przypadku wyścigu F1 automatyczne TOP 3 w Kalendarzu również zostaje wyczyszczone.
• Po wymazaniu klasyfikacje przeliczają się bez tej sesji.

Jeżeli wynik został wpisany błędnie, administrator może go poprawić i opublikować ponownie.

• Po ponownym zapisie klasyfikacje kierowców i konstruktorów przeliczają się automatycznie.
• Tabela punktów runda po rundzie również pokazuje poprawioną wartość.
• TOP 3 Kalendarza aktualizuje się zgodnie z poprawionym wyścigiem F1.

Klasyfikacja kierowców jest obliczana z opublikowanych wyścigów.

• System sumuje punkty kierowcy ze wszystkich opublikowanych rund danej dywizji.
• Najwięcej punktów oznacza wyższą pozycję.
• F1 i F2 posiadają osobne klasyfikacje.

Przy równej liczbie punktów decyduje najlepsza pozycja uzyskana w którymkolwiek wyścigu.

• Przykład: kierowca z 0 pkt i najlepszym P11 jest wyżej niż kierowca z 0 pkt i najlepszym P17.
• Jeśli również najlepszy wynik jest identyczny, system stosuje dalszy techniczny tie-break, np. nazwisko, aby zachować stabilną kolejność.

Pod klasyfikacją znajduje się zestawienie punktów zdobytych przez każdego kierowcę w kolejnych rundach.

• Nagłówki rund korzystają z flag Kalendarza.
• Komórka pokazuje punkty zdobyte w konkretnym wyścigu.
• Brak rozegranego lub opublikowanego wyścigu jest oznaczony jako brak danych, a faktyczne 0 pkt pozostaje zerem.
• Po prawej widoczna jest łączna suma sezonu.

Punkty zespołu są sumą punktów jego kierowców uzyskanych w opublikowanych wyścigach.

• Klasyfikacja konstruktorów przelicza się automatycznie po zmianie wyników.
• Punkty są prezentowane w jednej kolumnie przy prawej krawędzi tabeli.

Dwa ostatnie zespoły klasyfikacji konstruktorów F1 są oznaczone jako strefa spadkowa.

• Oznaczenie jest czerwone i dotyczy wyłącznie konstruktorów.
• Klasyfikacja kierowców nie posiada oznaczenia spadkowiczów.
• Ostateczny spadek wynika z końcowej klasyfikacji sezonu.

Dwa najlepsze zespoły klasyfikacji konstruktorów F2 są oznaczone jako strefa awansu.

• Oznaczenie jest zielone i dotyczy wyłącznie konstruktorów.
• Klasyfikacja kierowców nie posiada oznaczenia awansujących.
• Ostateczny awans wynika z końcowej klasyfikacji sezonu.

Jeżeli zespoły mają tyle samo punktów, kolejność powinna być rozstrzygana przez mechanizm klasyfikacji systemu.

• Jeśli pojawi się przypadek wymagający dodatkowego sportowego tie-breaku, administracja może doprecyzować zasadę przed zatwierdzeniem końcowych awansów i spadków.

Każde faktycznie zaakceptowane przedłużenie kontraktu może być publikowane jako oficjalny news.

• Samo istnienie aktywnego kontraktu nie oznacza nowego przedłużenia.
• Negocjacja ze statusem countered lub pending nie może być oznaczona jako oficjalne przedłużenie.

Sfinalizowany transfer jest twardą informacją i może zostać opublikowany jako OFFICIAL lub BREAKING.

• News powinien odpowiadać faktycznie zapisanej zmianie kontraktowej.
• Niepotwierdzone rozmowy pozostają poza kategorią oficjalną.

System może tworzyć newsy z ważnych wydarzeń sportowych, np. zwycięstw.

• Nie każde drobne wydarzenie musi zostać opublikowane.
• Feed ma być wyselekcjonowany i przypominać redakcję świata motorsportu.

Plotki są celowo niepewne i mogą być prawdziwe, częściowo prawdziwe albo całkowicie fałszywe.

• Plotka może bazować na realnie trwającej negocjacji.
• Może też być całkowicie zmyślonym fake newsem.
• Nie wolno traktować plotki jako potwierdzenia kontraktu, transferu lub decyzji technicznej.
• Wpis powinien być oznaczony jako RUMOR, PADDOCK lub NIEPOTWIERDZONE.

Sekcja Tech ma pokazywać ważne wydarzenia rozwojowe, a nie każdy drobny projekt.

• Duży pakiet, kilka znaczących ulepszeń, kosztowny projekt albo wyraźny skok możliwości samochodu mogą stać się newsem.
• Małe rutynowe poprawki nie muszą pojawiać się publicznie.

Publiczny news techniczny nie musi ujawniać pełnych wartości statystyk.

• Zamiast „+2 High Speed” news może opisywać poprawę w szybkich zakrętach lub efektywności aero.
• Dokładne wartości pozostają w panelu zespołu i odpowiednich publicznych zestawieniach, jeśli system je pokazuje.

System może publikować niepotwierdzone informacje o pracach technicznych.

• Plotka może bazować na rzeczywiście rozpoczętym projekcie albo być zmyślona.
• Do czasu ukończenia projektu lub oficjalnego potwierdzenia nie należy traktować jej jako pewnej informacji.

Zakładka Bolidy prezentuje obie dywizje obok siebie w oddzielnych kolumnach.

• F1 znajduje się po lewej, F2 po prawej na szerokich ekranach.
• Każda część korzysta z przypisanego logo dywizji.
• Dane mają charakter informacyjny i aktualizują się wraz ze stanem samochodów.

Karty Bolidów korzystają z półprzezroczystego stylu, jeśli włączone jest tło widza.

• Przezroczystość jest elementem wizualnym i nie zmienia danych.
• Kolory F1, F2 i zespołów pozostają akcentami informacyjnymi.

Dla F1 i F2 prezentowany jest najnowszy opublikowany wyścig.

• TOP 3 korzysta ze zdjęć kierowców i logotypów zespołów.
• Pozycje 4–10 są prezentowane w kolejnych belkach wyników.
• Dane pochodzą z zapisanych wyników projektu.

Starsze rundy pozostają dostępne w historii.

• Rundy są uporządkowane zgodnie z kalendarzem.
• Kwalifikacje i wyścigi można przeglądać jako oddzielne sesje.
• Zmiana historycznego wyniku przez administratora aktualizuje źródłowe dane.

Zakładka Twórcy przedstawia osoby stojące za projektem i historię jego powstania.

• Grafika twórców może być zmieniana przez administratora.
• Zmiana grafiki nie ma wpływu na rozgrywkę.

Patronite służy do dobrowolnego wspierania projektu.

• Kliknięcie karty lub przycisku może prowadzić do zewnętrznego profilu Patronite ustawionego przez administratora.
• Lista aktywnych Patronów ma charakter informacyjny i może być aktualizowana przez administratora.
• Wsparcie Patronite nie powinno samo w sobie zapewniać nieopisanej w zasadach przewagi sportowej.

Nie da się przewidzieć każdej możliwej kombinacji zdarzeń technicznych i sportowych.

• Jeżeli regulamin nie opisuje przypadku, administracja rozstrzyga go zgodnie z logiką istniejących zasad i zasadą równego traktowania.
• Rozstrzygnięcie może później zostać dopisane do regulaminu jako precedens.

Jeśli błąd techniczny zmienił dane, które wpływają na sezon, administracja może odtworzyć prawidłowy stan.

• Korekta może dotyczyć wyników, punktów, kontraktów, finansów, projektów lub kalendarza.
• Jeśli nie da się jednoznacznie odtworzyć stanu, administracja wybiera rozwiązanie minimalizujące niesprawiedliwą przewagę.

Jeżeli ta sama akcja wykonała się dwa razy wskutek błędu, drugi skutek może zostać cofnięty.

• Dotyczy to m.in. kosztu, projektu, premii, kontraktu lub innego zapisu.
• Historia operacji może być użyta do potwierdzenia duplikatu.

Po zamknięciu i zatwierdzeniu sezonu administracja może oznaczyć końcowe klasyfikacje jako ostateczne.

• Późniejsze kosmetyczne poprawki nie powinny zmieniać rozstrzygnięć sportowych bez wykrycia rzeczywistego błędu.
• Awans, spadek i premie sezonowe powinny opierać się na zatwierdzonym końcowym stanie.