Start › Wiki › Steuern und Schmuggelware

Steuern und Schmuggelware

Wie Fraktionssteuer erhoben wird, wie die drei Steuermodelle arbeiten und was ein Verbot in den Claims einer Fraktion wirklich blockiert.

Wo das Geld abgezogen wird

Steuer verschiebt Münzen zwischen Töpfen. Sie erzeugt keine und vernichtet keine: was auf deiner Seite einer Transaktion abgeht, landet in einer Fraktionskasse, und das Hauptbuch verbucht es als Fraktionseinnahme, sodass eine vollständige Nachzählung der Geldmenge weiterhin aufgeht. Eine so gefüllte Kasse bezahlt Claims, Buffs und Ausbauten.

Welche Fraktion den Anteil nimmt, hängt an der Transaktion, nicht daran, wo du gerade stehst. Die Regel lautet "deine eigene Fraktion besteuert dich", und es gibt genau eine festgelegte Ausnahme: den regionalen Shop, wo Land und Markt dem Besitzer gehören.

/pay läuft von Konto zu Konto, nicht von Geldbeutel zu Geldbeutel. Münzen, die lose im Geldbeutel liegen, kannst du also erst senden, wenn du sie mit /bank deposit eingezahlt hast. Die Meldung bei zu wenig Guthaben nennt den vollen Bedarf, und eine Zahlung wird nie teilweise ausgeführt. Wenn du jemandem völlig ohne Steuer und Gebühr Geld geben willst, nimm Bargeld: eine Note abheben und den Gegenstand übergeben.

Die drei Steuermodelle

Jede Fraktion fährt genau eines von drei Modellen. Der Owner wählt es, alle anderen leben darunter, und jedes Mitglied darf nachlesen, welches gerade gilt.

Was eine progressive Staffel wirklich kostet

Stufen sind marginal. Jedes Band einer Auszahlung wird mit seinem eigenen Satz besteuert; die ganze Auszahlung springt nicht auf den Spitzensatz, sobald sie eine Schwelle überschreitet. Die faire Standardstaffel lautet: 0% bis 2.000, dann 5%, ab 8.000 dann 12%, ab 25.000 dann 18%.

Bei einer Auszahlung von 10.000 sind das null auf die ersten 2.000, 5% auf die nächsten 6.000 und 12% auf die letzten 2.000: 540 Münzen, effektiv 5,4%. Dieselbe Staffel nimmt bei 30.000 genau 3.240, effektiv 10,8%. Der effektive Durchschnitt wird anschließend an der Sicherheitsobergrenze gekappt, sodass dich auch eine absurd steile Staffel nicht überbesteuern kann.

Die Voreinstellungen

Fünf benannte Voreinstellungen ersetzen die aktuelle Politik komplett, von der leichtesten Hand bis zu einer steil progressiven Staffel: LAISSEZ_FAIRE, MINIMAL, STANDARD, PROGRESSIVE_FAIR und PROGRESSIVE_STEEP. Der Voreinstellungs-Bildschirm im Steuer-GUI zeigt acht Karten: diese fünf plus drei, die statt eines Satzes ein ganzes Rules-Set anlegen, nämlich Vermögensteuer, Luxussteuer und Kriegsstaffel. Die ausgelieferte Vermögensteuer-Karte nimmt 3% von allem, was das Nettovermögen des Zahlenden über 200.000 hinaus hat.

Der Wechsel zu Rules ist kein Nulltausch

Rules ist eine andere Steuerwelt, und der Unterschied gehört gekannt, bevor ein Owner umsteigt. Der Buff zur Steuersenkung, der Einkommensteuer bei Flat und Progressiv rabattiert, greift unter Rules nicht: die Regeln sind die vollständige Autorität. Auch die Sicherheitsobergrenze ist die von Rules, nicht die von Flat.

Deshalb zeigt das bloße Öffnen der Regelliste bei einer Flat- oder Progressiv-Fraktion nur eine Vorschau des entsprechenden Regelsatzes, die nie gespeichert wird. Die Umstellung landet erst dann auf der Platte, wenn der Owner wirklich etwas bearbeitet. Reines Nachsehen kann also nie stillschweigend ändern, was deine Fraktion dir abnimmt.

Aufbau einer Regel

Eine Rules-Politik ist eine geordnete Liste. Jede Regel verbindet eine Bedingung, die sagt, wann sie greift, mit einem Betrag, der sagt, was sie nimmt. Ein paar Schalter bestimmen, wie sie zwischen den anderen steht.

Was die fünf Aktionen tun

Das Ziel wird modelliert, gespeichert und ausgegeben, doch die Münzen gehen heute auf die eigene Kasse des Handelnden. Zölle zwischen Fraktionen und regionale Stapelung sind noch an keine Geldbewegung gebunden, ein REDIRECT auf eine andere Fraktion ist also eine Zeile auf dem Beleg und keine Überweisung. Lies es als Plan, nicht als Zahlung.

Sind alle Regeln durch, wird die Summe gegen den ursprünglichen Transaktionsbetrag gekappt, nicht gegen das, was ein DEDUCT davon übrig gelassen hat. Genau das unterscheidet eine Obergrenze, die hält, von einer, um die eine geschickte Regelreihenfolge herumläuft.

Was eine Bedingung lesen kann

Bedingungen lesen eine Momentaufnahme der Transaktion und der handelnden Person: Betrag, Transaktionstyp, Fraktionsrang, Geldbeutel, Kontostand und Nettovermögen, Job, Region und Welt, den Gegenstand und seine Kategorie sowie die Wirtschaftskennzahlen der Fraktion wie Inflation, Kaufkraft, Stabilität und Wachstum. Die Wirtschaftskennzahlen liefern neutrale Werte, solange die Wirtschaftssimulation nicht scharf geschaltet ist; eine Regel auf Inflation schläft dann, statt falsch zu feuern.

Ein unbekannter Variablenname löst zu 0 oder zu einer leeren Zeichenkette auf. Ein Tippfehler bringt also nie eine Regel zum Absturz, sondern erzeugt eine Regel, die still nie greift. Genau dafür gibt es den Simulator.

Die Formel-Sandbox und was bei einer kaputten Regel passiert

Ein Betrag kann ein einfacher Satz, eine feste Gebühr oder ein Ausdruck sein. Ausdrücke unterstützen +, -, *, / und % sowie die Funktionen min, max, clamp, floor, ceil und abs. Division und Modulo durch null liefern 0, statt einen Fehler zu werfen. Eine Regel, die durch eine gerade auf null stehende Kennzahl teilt, ergibt also nichts, statt die Auszahlung zu zerlegen.

Der Parser ist bewusst klein und dreifach hart begrenzt, bevor dein Ausdruck überhaupt ausgewertet wird. Bedingungen laufen unter denselben Grenzen.

Jede davon verwandelt eine bösartige Eingabe in einen gemeldeten Parse-Fehler. Genau darum werden Knoten während des Parsens gezählt: eine zu große Quelle wird beim Lesen abgelehnt und nicht erst, nachdem daraus eine Struktur geworden ist, die zu groß zum Durchlaufen wäre.

Eine kaputte Regel reißt nur sich selbst mit

Jede Regel führt den Fehler ihres Betrags und den ihrer Bedingung getrennt. Scheitert eine der beiden Hälften beim Kompilieren, schaltet sich genau diese Regel ab, und der Fehler geht zurück an die Person, die ihn getippt hat. Der Rest des Satzes bleibt unberührt und erhebt weiter. Dieselbe Trennung gilt beim erneuten Laden eines gespeicherten Regelsatzes: eine Regel, die nicht mehr kompiliert, kommt deaktiviert und sichtbar zurück, statt stillschweigend zu verschwinden, und lässt sich also lesen und reparieren.

Zwei Syntaxfallen, die man kennen sollte

Kommas sind innerhalb eines Ausdrucks Argumenttrenner, Tausenderkommas zerstören also eine Bedingung. Schreibe amount > 5000, niemals amount > 5,000. Alles, was das GUI für dich schreibt, ist bereits kommafrei, und die Trennzeichen auf einer Karte sind reine Anzeige.

Listenbedingungen akzeptieren beide Formen: item IN (a, b) und item IN [a, b]. Früher wurde nur die eckige Form geparst, und wer zur naheliegenden Klammer griff, bekam eine Menge, die das Klammerzeichen selbst enthielt: sauber kompiliert und danach nie zutreffend. Eine nicht passende Klammer wie IN [a, b) ist heute ein gemeldeter Parse-Fehler statt einer Regel, die den Rest deiner Bedingung verschluckt.

Der Simulator und die Befehle, die die Politik erklären

Der Simulator beantwortet eine Frage: was würde dieser Regelsatz tatsächlich nehmen? Er schickt eine Transaktion durch dieselbe Auswertung wie die echte Abbuchung, listet jede Regel, die gegriffen hat, mit ihrem Anteil und nennt am Ende den effektiven Satz. Es bewegt sich kein Geld, und nichts wird gespeichert.

Im GUI kannst du auf dem Simulator-Bildschirm den Transaktionstyp durchschalten, den Betrag steppen und wahlweise einen Gegenstand durch die Palette blättern. Im Chat leistet /faction tax test dasselbe ab Elder aufwärts, sodass die Offiziere einer Fraktion eine Politik prüfen können, die sie nicht ändern dürfen.

Die wichtigste Warnung

Wählst du einen Gegenstand gegen einen Transaktionstyp, der im Spiel keinen Gegenstand mitführt, ergänzt die Vorschaukarte eine entsprechende Warnung. Ohne sie würde der Simulator bereitwillig einen plausiblen Abzug von 30% für eine Job-Auszahlung auf eine Cannabis-Knospe zeichnen, und ein Owner baute eine Regel auf Einnahmen, die die Engine nie einziehen kann. Die Warnung ist reine Anzeige. Sie rührt die Rechnung nicht an, also stimmen Karte und Engine weiterhin exakt überein.

Eine zweite Offenlegung aus demselben Grundsatz: ein paar Transaktionstypen lassen sich im Editor auswählen und können nie greifen, weil die dahinterliegenden Geldwege gar keinen Auswertungskontext übergeben. Gehalt und Unternehmensgewinn sind die beiden.

Wer was darf

/faction tax explain wird beantwortet, bevor der Befehl überhaupt deine Fraktion nachschlägt. Wer "was ist Fraktionssteuer?" am dringendsten braucht, überlegt oft gerade, ob er überhaupt einer beitritt, und bekäme sonst nur die Auskunft, er sei in keiner Fraktion. Das GUI arbeitet durchgehend mit Linksklick und hat nirgends eine Texteingabe, sodass auch Bedrock-Spieler jedes Element bedienen können.

Eine einzelne Ware besteuern, und die acht Kategorien

Eine Regel kann eine bestimmte Ware benennen. So legt eine Fraktion einen Luxus- oder Lastersatz auf ein einzelnes Produkt, ohne alles andere anzufassen, was sie besteuert.

Gegenstände werden über einen Schlüsselraum identifiziert, den sich Steuer und Schmuggelware teilen. Ein Blacklight-Custom löst zu seiner Registry-Id auf, etwa bl_cannabis_bud; alles Vanilla zu seinem Namespace-Schlüssel, etwa minecraft:diamond. Schlüssel sind kleingeschrieben und unabhängig von der Stapelgröße, eine Knospe und ein Stapel von 64 tragen also denselben Schlüssel. Eine leere Hand ergibt einen leeren Schlüssel, der auf keine Regel und kein Verbot passt, was für "kein Gegenstand beteiligt" genau richtig ist.

Es gibt drei Formen. item == bl_cannabis_bud für eine Ware, item IN (a, b) für mehrere und item_category == HERB für einen ganzen Korb. Im GUI tippst du davon nichts: Bedingungen, dann Match a specific item, dann die Waren anklicken und übernehmen.

Kräuter werden vor jeder anderen Prüfung am Schlüssel erkannt. Darum rutscht die Cannabis-Knospe nicht in FOOD, obwohl ihr Basisgegenstand essbar ist. Auswahlfenster und lebender Steuerpfad laufen durch denselben Klassifizierer, eine item_category-Regel trifft also genau die Menge, die du beim Bauen gesehen hast.

Der Katalog, aus dem du wählst, führt zuerst die Kräuterkette, dann jeden registrierten Blacklight-Custom, dann rund 45 kuratierte Vanilla-Klassiker. Die Kuratierung ist Absicht: eine vollständige Materialliste wären über tausend Einträge in einem Raster mit 28 Feldern, und die meisten davon werden nie gehandelt. Steuer-Auswahl und Schmuggelware-Editor lesen diesen einen Katalog in derselben Reihenfolge, du kannst also nie etwas besteuern, das du nicht verbieten kannst, und umgekehrt.

Schmuggelware: Verbot ohne Beschlagnahme

Eine Fraktion kann eine Ware innerhalb ihrer eigenen Claims verbieten. Das ist keine Steuer, und es bewegt sich kein Geld: es ist eine Verweigerung. Auf dem Land dieser Fraktion lässt sich der verbotene Gegenstand nicht wie unten beschrieben nutzen; außerhalb ist er wieder ein ganz normaler Gegenstand.

Es wird nie etwas beschlagnahmt, und im ganzen System bewegt sich kein Geld. Jemandem Gegenstände abzunehmen, weil er eine Grenze überschreitet, wäre mühelos als Waffe zu nutzen, denn eine Fraktion könnte einen alltäglichen Gegenstand verbieten und Reisende abfarmen. Das Verbot hier verweigert, mehr nicht.

Ein Verbot gilt für alle auf diesem Land, auch für die eigenen Mitglieder der verbietenden Fraktion, die dieses Gesetz schließlich geschrieben haben, und auch für das Team. An keinem der drei Durchsetzungspunkte gibt es eine Ausnahme. Wer als Teammitglied ein Verbot umgehen muss, hebt es auf, statt es zu ignorieren.

Schmuggelware in der Hand blockiert nie einen Block. Truhen, Türen und Öfen öffnen ganz normal, während ein verbotener Gegenstand in deiner Hand liegt. Ein Verbot zielt darauf, was du mit einem Gegenstand tust, nicht darauf, was du trägst. Ein Rechtsklick auf einen bedienbaren Block öffnet ihn, statt eine Verweigerung für etwas auszugeben, das du nie versucht hast.

Ein nachträgliches Verbot friert ein, statt zu löschen. Angebote, die vor dem Verbot entstanden sind, werden nicht mehr gehandelt statt stillschweigend weiterzulaufen, und die Gegenstände bleiben, wo sie sind.

Die Verbotsliste lesen und bearbeiten

Jedes Mitglied kann die Schmuggelware-Liste seiner Fraktion im Fraktions-Hub lesen, und das Übersichtsbuch zeigt sie ebenfalls. Wer unter einem Gesetz lebt, soll es lesen können. Bearbeiten dürfen Mod und höher, gebunden an dieselbe Befugnis wie das Hinauswerfen, womit die Ordnungskräfte der Fraktion zugleich ihre Gesetzgebung sind.

Der Editor sortiert verbotene Einträge nach vorn, damit das geltende Recht immer auf Seite eins steht, und ein Verbot auf einen Gegenstand, der nicht mehr im gemeinsamen Katalog steht, wird trotzdem angezeigt und lässt sich also immer aufheben. Das Team kann die Durchsetzung serverweit abschalten; die Verbotslisten überstehen das unverändert, nur die Durchsetzung endet.

Obergrenzen, Belege und die Prüfung

Vier Zusagen gelten im ganzen System, und man liest sie besser als Mitglied denn als Owner.

Der Preis, den du siehst, ist der Preis, den du zahlst. Die Steuer steckt immer in der Zahl auf dem Etikett. Unter einer Rules-Politik kann der Satz davon abhängen, wer kauft, deshalb wird das Shop-Etikett über dieselbe Auswertung und denselben Kontext gebildet wie die spätere Abbuchung. Der Beleg gibt anschließend den tatsächlich abgebuchten Betrag wieder, statt nachträglich neu zu rechnen, denn eine zweite Rechnung läse einen bereits belasteten Geldbeutel.

Jede Politik hat eine Obergrenze.

Steuer wird bei jeder Auszahlung benannt. Jede von Spielern verdiente Münze läuft durch einen Trichter mit einer erklärten Steuerentscheidung je Quelle, es gibt also keine steuerfreie Hintertür und keine Sondersteuer in irgendeiner Ecke. 28 Auszahlungsstellen binden ihr Ergebnis, elf Dateien geben den Beleg über einen einzigen Renderer aus. Eine steuerfreie Auszahlung schreibt "keine Steuer" statt einer Null, damit "steuerfrei" lesbar etwas anderes bleibt als "nicht ausgewiesen".

Darin steckt eine Entscheidung zum Datenschutz: der Anteil deiner Fraktion an deiner Auszahlung ist deine Einkommensteuer, und unter einer Rules-Politik lässt sich der Satz daraus ableiten. Server- und fraktionsweite Ankündigungen behalten deshalb die Schlagzeile, und der Steuersatz geht allein an die verdienende Person.

Einkommen und Konsum werden unterschiedlich besteuert. Der Buff zur Steuersenkung greift nur bei Einkommen: Job-Lohn, Verkäufe, Belohnungen aus Expeditionen und Kopfgeldern, Sparzinsen und Dividenden. Konsum und Gebühren zahlen den ungesenkten Satz. Diese Trennung hält auch den Ladenpreis für alle gleich: zwei Mitglieder derselben Fraktion mit unterschiedlichen Buffs sehen dieselbe Zahl am selben Gegenstand, obwohl sich ihre Einkommensteuer unterscheidet.