Beiträge von michael2an

Geschenke auf Origo können nun wieder vom Absender abgeholt werden, wenn diese noch nicht geöffnet worden sind.
Der Server wurde erfolgreich auf die Version 1.20.4 aktualisiert und nun wieder erreichbar.

    der Faktor bei 1024


    https://de.wikipedia.org/wiki/…einheiten#SI-Pr.C3.A4fixe


    1000


    Bei Datenraten (und Festplattengrößen) verwendet man normalerweise die normalen Si-Präfixe.


    Binärpräfixe gemeint und normale Präfixe geschrieben machen einige Computerprogramme. Das ganze ist etwas kompliziert, aber hier ne Zusammenfassung: (macht aber keinen wirklichen Unterschied solange du unter G/Gi bist)
    https://xkcd.com/394/

    Ich bin dagegen. Und grundsätzlich auch gegen alle anderen Kurzformen. Denn:


    - Blickt da irgendwann keiner mehr durch
    - Kannst du dir das ganze dank einiger Makro-Mods doch einfach selbst als Alias7Keybind legen ;)


    Damit hast du den schnellen Zugriff aber andere Spieler werden nicht durch eine noch längere Befehlsliste gestört.

    Die Sicherungen etc. verursachen viel Rechenleistung


    Du kannst Rechenleistung reduzieren, indem du möglichst wenige Kisten aufstellst.


    Allein die Mall hat über 3k Shops, viele mit Doppelkisten. Item Frames hängen auch einige dort. Wir werden ca. 6000 ticking (tile)entities sparen indem das in eine extra Welt ausgelagert wird.


    Kisten sind ein allgemeines Problem. Könnt ihr ja gerne mal an einem Weltdownload durchzählen, ein gößeres Lager hat schnell 1000. Aber ohne genaue Profiling-Daten kann man da nur im trüben fischen was wirklich hilft. Der eine AFK-Spieler kann da doppelt so viel Rechenleistung fressen wie ein normaler und zehn die nur am Spawn rum stehen brauchen fast nichts.

    Oder macht es Spigot abhängig von der Anzahl an Entities, ob welche ausgelassen werden order nicht?


    Ja, die Schranke kann man pro Server einstellen. Die meisten Server reduzieren einfach die globale Anzahl an Entities und damit kommen sie nicht über diese Schranke.


    Kannst du mir bitte den entsprechenden GitHub-Link o.Ä. zum Original- bzw. Forgecode geben? Ich weiß nicht mal unter welchem Pfad diese Klassen zu finden sein sollen.


    0152-Allow-Capping-Tile-Entity-Tick-Time ;)


    Du musst TileEntityBeacon in den Spigot-Code rein laden. Die Commits sind im Endeffekt ein Git-log den du soweit zurückspulen musst, bis du an den ersten Commit kommst mit dem alle Orginal-MC-Dateien in den Quelltext geladen werden (deswegen veröffentliche ich den patch auch nicht: So etwas zu veröffentlichen verstößt eindeutig gegen die MC Eula).


    Ich hatte mir für das ganze ein eigenes Script geschrieben das die ganzen Patches raus zieht und ordentlich, einzeln anwendbar macht. Aber das ist auch schon wieder eingeschlafen seitdem ich den Ansatz von Spongeforge kenne. Der ist deutlich flexibler, moderner und kompatibler.

    Hol dir eine relativ aktuelle MCP-Version (Forge). Dann hier die passenden Methoden-Namen:


    -> World#updateEntities(). Hier die Schleife mit den tickableEntities. Spigot tickt hier immer nur einen Teil der Entities
    -> TileEntity#update(): Inteface
    -> TileEntityBrewingStand#update(): Dauert einfach etwas länger
    -> TileEntityChest#update(): Sinnvoll das ganze Zeug nicht jeden Tick zu prüfen.
    -> TileEntityEnchantmentTable#update(): Bücher drehen ist auch Bonus. Müsste der Server eigentlich gar nicht machen.
    -> MobSpawnerBaseLogic#updateSpwaner(): Das isAnyPlayerInRange() jeden Tick zu prüfen ist auch nicht unbedingt performant.
    -> TileEntityHopper#update(): Ja, macht Sinn nur alle paar Ticks nach neuen Items zu suchen.
    -> TileEntityBeacon#update(): Hier geht das eben schief, wegen dem Modulo. Hier hätte man es anpassen müssen.


    Das passiert, wenn der Profiler sagt: "Das braucht viel Zeit" aber man es dann einfach versucht durch weniger machen zu lösen. Weniger machen bedeutet weniger features. Hätte man es feingranularer gemacht (Hopper nur alle 8 Ticks, MobSpawner nur alle 200-800 (random!), ... hätte es niemanden gestört, weil die TileEntities so lange eh nur däumchen drehen.

    FALLS die update-Methode jeden World-Tick aufgerufen wird.


    Richtig.


    Spigot sieht es als "Optimierung". Ist es eigentlich auch, da dann ein haufen Aufrufe gespart werden. Nur haben sie vergessen, dass der MC-Code davon ausgeht, dass jeden Tick aufgerufen wird.


    Je nach Zahl der geladenen Entities kommst du so z.B. jedes mal zufällig so raus, dass das Beacon alle z.B. 5 Ticks getickt wird. Dann geht es entweder dauerhaft oder gar nicht.


    Spigot ist schon ewig hinterher mit allem möglichen, das System wird irgendwie nur noch durch flicken zusammen gehalten (und dadurch, dass es tausende Server testen und die Fehler melden). Lizenzprobleme gibt es da dann auch noch weil sie komplette Quelltexte in ihr Git laden.


    PS. Performance-Auswirkung: Dass die 30 (?) geladenen Beacon ihre Effekte verteilen kostet fast nichts. Dass die Spieler dann mit Haste arbeiten und viel mehr Block updates produzieren ist das größere Problem :D

    Ich mach das mal als neues Thema, damit es nicht verloren geht...


    Bitte beim nächsten Kompilieren von Spigot einfach als Patch dran laden, dann gehen die Beacons auch wieder "normal".


    Beacon-Effektdauer verlängern


    PS: Lizenz: Ich hab das für den Terraconia-Server raus gesucht. Wenn es andere verwenden wollen bitte bei mir kurz melden. Wenn es die Spigot-Leute in ihren Server-Code einbauen wollen: Nein. (Auch wenn die sich nicht so wirklich viel für Lizenzen interessieren... Trozdem sollen sie ihren Murks selbst flicken oder richtig machen)

    Gibt es das Problem immernoch?


    Die Potions sind immer 180 Ticks (9 Sekunden) aktiv.


    Das Problem ist das auf dem Server Spigot läuft. Spigot nennt das "Performance verbesserung".


    Lösung:
    Such nach diesem Code in der TileEntityBeacon

    Code
    /** * Like the old updateEntity(), except more generic. */ public void update() { if (this.worldObj.getTotalWorldTime() % 80L == 0L) { this.updateBeacon(); } }


    Ändere ihn auf:

    Code
    private long lastUpdate = 0;
    public void update() { 
    long time = this.worldObj.getTotalWorldTime();
    if (lastUpdate + 80L < time) {
    this.updateBeacon();
    lastUpdate = time;
    }
    }


    Dieser Murks ist normalerweise der Gund weshalb ich nen großen Bogen um Spigot mache... Einfach mal was "Optimieren" ohne Ahnung davon zu haben, was man tut.


    PS: Der Code ist mit dem aktuellen MCP. Spigot verwendet ein ewig altes, da heißt die Funktion wahrscheinlich a() oder b() oder so was. Einfach nach der 80 suchen.

    Dadurch würde die Grundstücksanzahl nicht zu schnell steigen


    Abr sie würde genau so steigen. Wieder einfach nur ein Mechanismus der versucht, neuen Spielern den Einstieg in den Markt schwer zu machen.


    Ich glaube die Probleme sind
    - Mieteinnahmen werden aktuell von kleinen Städten eher selten als Einnahmequelle gesehen, eher als Bonus
    - Wir haben einen Mieter-Mangel, weil jeder Mieter haben möchte.


    Mieter sind also so etwas wie "Haustiere" ;-). Wie wäre es, wenn wir den Spieß umdrehen und den Stadthalter für die Mieter an die Staatskasse zahlen lassen? Etwas um die 20ESK/vermietetes GS/Tag. Egal ob der Mieter im Mietrückstand ist oder nicht.


    Vorteile:
    - Wer einfach nur schnell viele Mieter will und billig vermietet zahlt halt drauf
    - Wer unzuverlässige Mieter sucht, die nach 2 Tagen schon wieder weg sind, zahlt auch drauf
    - Man kann weiterhin vermieten so billig man will.


    Nachteil:
    - Langfristige Mieter müssten min. 20ESK/Tag zahlen, damit es lukrativ wird.


    Zusätzlich könnte man die Erträge durch MOT für Stadtbesitzer senken. MOT ist ja eher eine Stütze für Einsteiger, damit sie auf dem Server etwas Zeit verbringen und schneller Fuß fassen können. Stadtbesitzer haben ja stattdessen die Mieteinnahmen als regelmäßiges Einkommen - haben dafür aber keine regelmäßigen Ausgaben.


    Ich bin jedoch immernoch für die Einführung einer allgemeinen Grundsteuer.


    und jetzt werden sich sicherlich hunderte Stadtbesitzer über diesen Beitrag beschweren - aber "Gebt mir Vorteile und den anderen nicht" geht halt nicht gerecht.

    Da gab es nen ganzen Haufen noch früher. z.B. den Vorgänger B (oder woher denkst du hat C seinen namen?). Aber auch Fortran und Lisp. Basic könntes du auch schon gehört haben. Alle sind deutlich früher dran gewesen.