Posts by red51

    Direkt anhalten kannst du die Zeit leider nicht, allerdings kannst du sie beliebig verlangsamen - so sehr, dass es quasi einem Stillstand gleichkommt ;)


    Wenn die Änderungen dauerhaft sein sollen (gelten ohnehin nur im Singleplayer) kannst du wie @lenko schon sagt die config.properties Datei im Spielverzeichnis öffnen und "game_time_speed" auf eine höhere Zahl stellen (der Wert gibt an, wieviele Realtime-Sekunden eine Ingame-Minute dauert - wenn du zB 60 einträgst, vergeht die Zeit im Spiel genauso schnell wie in der Wirklichkeit - wenn du es noch langsamer haben willst, trage einfach einen höheren Wert ein, zB 999999) sowie "game_weather_enabled" auf false setzen. Speichere die Änderungen, und starte das Spiel erneut. Jetzt sollte die Zeit wesentlich langsamer vergehen und auch das Wetter ändert sich nicht mehr (mit dem "weather <name> 1" Befehl kannst du nun selber ein Wetter setzen, zB "default" für Standardwetter, "rain" für Regen, "clear" für schönes Wetter usw - das gilt aber jeweils nur für die aktuelle Session).



    Für die Zeit-Geschwindigkeit gibt es alternativ auch einen temporären Konsolen-Befehl (d.h. nach einem Neustart wird das automatisch wieder zurückgesetzt). Gebe dafür einfach "settimespeed <wert>" in die Konsole ein.

    Generell teleportiert dich der "gotospawn" Befehl zu deinem letzten Spawnpunkt zurück. Mit "setspawn" wird lediglich der Standard-Spawn umgestellt, falls du aber zwischenzeitlich in einem Bett oder Zelt o.ä. geschlafen hast, dann liegt dort dein neuer Spawnpunkt. Am "Standard-Spawnpunkt" landet man nur, wenn man in keinem Bett o. Zelt geschlafen hat (oder diese bereits wieder abgebaut wurden), oder wenn man zum ersten Mal auf den Server connected.


    Wenn aber momentan ein anderer Spawnpunkt als der Standardspawn hinterlegt ist, dann sorgt ein Bug dafür, dass man mit dem "gotospawn" Befehl zwar zu dieser Position teleport wird, sich aber extrem weit oben in der Luft befindet... das Problem wird auf jeden Fall mit dem nächsten Update behoben ;)

    Das Player-Objekt erhält eine neue Funktion, um ein "raw" Map Tile anzufordern. Dazu kannst du die X und Y Koordinaten angeben (so, wie auch die Map Tiles beim Client unterteilt sind) sowie einen optionalen MD5 Hash. Zusätzlich definierst du noch einen Callback, welcher aufgerufen wird, sobald entweder alle Bytes des Map Tiles auf den Server übertragen wurden (i.d.R. müssen die Map-Tiles auf mehrere Pakete aufgeteilt werden).


    Der Funktionskopf sieht in der API so aus: Player.requestMapTileRaw(int x, int y, String controlHash, Callback<byte[]> callback)


    Also "controlHash" kann wie gesagt entweder ein MD5 Hash des komprimierten byte[] angegeben werden, oder null wenn keine Hash-Prüfung stattfinden soll.


    Das byte[], welches an das Callback übergeben wird, ist entweder null (wenn das Map Tile beim Client nicht existiert oder wenn die Checksumme identisch ist), oder es handelt sich um die komprimierten Map Tile Daten.


    Im Code würde das zB so aussehen:

    @red51 dazu möchte jetzt was fragen und zwar wieso wird das so gehandhabt.

    Der Grund dafür ist primär, dass verhindert werden soll, dass Tiere oder auch Gegner bspw. in Städten spawnen. Grundsätzlich sollen neue Tiere nur in der "Wildnis" spawnen, nicht aber irgendwo mitten in einer Stadt o.ä. Aber auch das Handling des Spawns zwischen (von Hand geschaffener) Gebäude wäre etwas schwierig. Außerdem wird so deutlich die Chance verringert, dass Tiere dort spawnen, wo sie nicht spawnen sollen (zB in einem umzäunten Gebiet). Und zuletzt bekommt der Spieler so die Möglichkeit, Einfluss darauf zu nehmen, wo Tiere spawnen können und wo nicht.


    wenn ich bei den hessenstrolchen zb schaue ist die welt weitläufig sehr weitläufig, da sind gebiete zwischen, die von punkt a zu punkt b. nur durchgewandert wurden um den nächsten bereich zu claimen.

    Die Einschränkung betrifft nur bebaute Chunks, also die Chunks, die tatsächlich schonmal von einem Spieler verändert wurden. Jeder Chunk ist 16x16 Blöcke breit, d.h. in den meisten Fällen sind auch zwischen zwei POIs trotzdem noch viele "unbebaute" Chunks vorhanden. Wenn ein Spieler nur durch ein Gebiet gereist ist, können dort später immernoch Tiere (re)spawnen. Lediglich in den Chunks, die der Spieler auf seiner Reise verändert hat (da also Löcher gebuddelt oder Blöcke platziert hat o.ä), werden keine neuen NPCs mehr spawnen.
    Zugegebenermaßen werden auf einem großen Server mit einer alten Welt irgendwo im Zentrum kaum noch unbebaute Chunks sein, hier wird es also kaum (oder gar nicht) zu Respawns kommen, aber ich weiß nicht, ob das nicht vielleicht wünschenswert ist (sonst wäre es ja auch nervig, wenn im Spawn-Gebiet des Servers [vmtl. irgendwo in der Innenstadt] ständig neue Bären spawnen würden) ;)


    Wirklich abgerundet werden NPCs wohl erst später, wenn auch Tierzucht implementiert ist. Dann hat der Spieler eigentlich alle Mittel zur Hand, um gezielt die Tierpopulation irgendwo anzukurbeln.


    das erzeugt sogesehen eine relativ leere welt wo sich die population an tieren nicht in gänze ergibt.
    wäre es nicht irgendwo für die belebtheit und abwechslung der welt sinnvoller, wenn die bereiche die lange nicht besucht wurden, durch die neuen hinzugefügten populationen an mensch und tier ergäntzt würden?

    Es wäre tatsächlich gar nicht so schlecht, wenn das Spawnverhalten davon abhängig ist, wann ein Chunk zuletzt besucht wurde. Denn hier muss ich zugeben, dass es dann auch in einer Innenstadt sinnvoll wäre, wenn dort irgendwann wieder Tiere auftauchen falls dort länger kein Mensch mehr war. Man müsste das natürlich zusätzlich mit der "ist-Chunk-unbebaut"-Prüfung verbinden, denn sonst würden vmtl. unterm Strich kaum noch Tiere spawnen (d.h. Tiere würden dann spawnen, wenn ein Chunk entweder unbebaut ist, oder wenn seit sagen wir mal 1 Woche kein Spieler mehr in der Nähe war).


    Aber leider gibt es dabei ein Problem, denn um zu prüfen, wann ein Chunk zuletzt besucht wurde, müssten wir zusätzliche Daten speichern, was wiederum eine Weltkonvertierung nötig machen würde. Ich möchte das so gut es geht vermeiden, zumindest solange, bis Änderungen stattfinden, die ohnehin eine Weltkonvertierung nötig machen. Weltkonvertierungen sind leider generell ein heikles Thema... beim letzten Mal, als ich mal "so nebenbei" ein neues Dungeon eingebaut habe (Pyramiden), gab es viele Probleme mit alten Welten, die nur mit sehr viel Aufwand und vielen schlaflosen Nächten gerettet werden konnten :whistling:


    Ich behalte das aber trotzdem mal im Hinterkopf. Irgendwann müssen neue Biome und Dungeons usw. ins Spiel kommen, diese machen ohnehin eine Weltkonvertierung nötig (oder erfordern gar, eine neue Welt zu erstellen). Wir versuchen, alle diese kritischen Updates in ein einziges, großes Update zu packen. Hier könnte dieses "erweiterte Respawnverhalten" ggf. mit berücksichtigt werden :)

    The setting server_lan_mode is set to true in this case, this indicates Steam that this is only a LAN server (so it won't show up in the public server list). In addition to that, the server_ip is set to your local ip (192.168.0.10), therefore the server only binds to the LAN ip (and is only accessible in your local network).


    Make sure to set server_lan_mode to false and remove the LAN ip from the server_ip field. If you're running the server on your local machine, just keep the server_ip field blank, then the server binds to all addresses ;)

    As @Stager83 mentioned, spacing is indeed very important. If there is a wrong spacing or indenting, the permission file cannot be loaded.


    According to the log output, the default, architect and resident permissions could not be loaded.
    In the default.permissions, the "chatcolor" in the first line is wrong, and there is a space missing in line 14 (between "maxupload:" and "20") ;)


    In the resident.permissions file, the "allow" in line 16 does not belong there (more precisely, it looks like the "commands" block is missing).


    Fixing the wrong indenting of "- itemgive" in the architect.permissions as described in your last post should indeed fix this permission. Although there is no need for the "- itemgive" line if the next line contains a wildcard (*): the asterisk basically means "all commands", so in this case, it allows all commands. If you want to disable all commands but the "itemgive" command, you could write the "deny" block first containing a wildcard, followed by the "allow" block only containing the "itemgive" entry:

    Code
    commands:
    deny:
    - *
    allow:
    - itemgive

    I'm sorry I didn't reply earlier to this topic :/ Unfortunately it's tricky to provide a "clean" way to access the game GUI... the best way would be if the various vanilla GUI elements (e.g. HUD elements) would be treated as "GuiElements" (similar to the custom GUI elements you create through the API), so you could manipulate them or retrieve their information (position, size etc). Unfortunately the server has no information about the GUI, so it cannot provide the default information (position etc) about these elements...


    Probably we'll just add a new type of GUI object which only has setters. Although we still need a proper way to identify paritcular GUI elements (e.g. the block id label, or the health bar) through the API :|


    The next update will introduce an "Internals" class which provides access to some internal server classes, objects and methods. Maybe we could put a dirty method there to modify at least the position, size and visibility of a particular vanilla element...

    Sorry, dass ich erst so spät antworte! Das ganze ist leider etwas schwierig... momentan gibts nur "normale" Chunks in der API, aber noch keine "ChunkAdditions" (bzw. genau gesagt die Art von Chunks, die Objekte, Vegetation und Constructions enthält). Aus den bestehenden Chunks kann man nur auslesen, wie das Terrain beschaffen ist und ob und welche Blöcke verbaut sind.


    Auf die Schnelle haben wir da leider keine Lösung :( Aber mit dem nächsten Update wirds in der API zumindest eine Internals Klasse geben, welche direkten Zugriff auf manche Serverdaten und -funktionen bietet, so also auch die "internen" Chunk-Daten. Damit könnte man auslesen, ob ein bestimmter Chunk bspw. Objekte oder Bauelemente enthält. Bei Bedarf kann ich nach dem Update auch ein Beispiel-Codeschnipsel dazu posten ;)

    Sorry für die späte Antwort! Ich habe zwar noch etwas Sorge mit der Funktion, aber ich denke wir können sie im nächsten Update trotzdem als experimentelles Feature mit reinpacken. Die Daten werden dann 1:1 als komprimiertes byte[] übertragen, also quasi exakt so, wie die MapTiles beim User gespeichert sind (allerdings werden wir Funktionen anbieten, um dieses byte[] zumindest in ein BufferedImage umzuwandeln) ;)

    Unter der [F3] Info findet Mann ja auch so nützliche angaben wie:

    Zumindest die Infos "indoor" und "incave" könnten wir mit reinpacken ;) Die Wasserangaben sind etwas schwieriger, mal schauen ob wir da auf die Schnelle was machen können


    Allerdings beim Essen und Trinken Event bin ich mir nicht sicher, wie viel Aufwand das ist.

    So ein Event war mal geplant, aber ich bin mir nicht sicher, ob das im nächsten Update drin sein wird...


    Aber wenn dann die eigenen Items da sind, würde ich gern mal sowas wie Tränke machen

    Die Custom Items werden so aufgebaut sein, dass du (optional) eine eigene Routine schreiben kannst, welche ausgeführt wird, wenn das Item benutzt wird (so ähnlich wie jetzt schon die Callbacks funktionieren). So könntest du dem Item bspw. eine der Trink-Animationen zuweisen, und bei Benutzung zB definieren, dass der Spieler volles Leben erhalten soll, oder plötzlich fliegen kann oder was auch immer ^^

    Türen lassen sich nicht richtig öffnen, am Türknopf geht gar nichts, sondern Tür öffnet sich an der anderen Seite, aber das Symbol zum Öffnen lässt sich
    schwer finden

    Ich denke das hängt mit der ursprünglichen Anvisier-Problematik zusammen. Das sollte mit dem kommenden Update endgültig behoben sein ;)


    müssen denn einzelne spieler wieder ihre welten konvertieren ?????

    Nein, das wird nicht nötig sein ^^ Tiere und Gegner werden aber nur in den Chunks (re)spawnen, die noch nicht bebaut wurden.

    Aber wie sieht es mit Spielern aus die Rising World nicht über Steam gekauft haben

    Auch die Standalone-Spieler haben eine eigene UID. Der einfachste Weg, daran zu kommen, ist wenn der betreffende Spieler dir seine UID mitteilt (er findet sie bei sich im Hauptmenü oben rechts, via Rechtsklick kann er sie in die Zwischenablage kopieren). Ansonsten bliebe nur, in die Welt-Datenbank (in der Tabelle "Player") zu schauen, welche UID der entsprechende Spieler hat.


    Nun denn ... es ist jetzt Ende Februar und morgen Anfang März ... also stellt sich mir die Frage, wo bleibt der Coutdown und wie lang ist der überhaupt?

    Das Update ist in der finalen Phase ;) Ein paar Tage vor dem Update werde ich einen kleinen Banner im Forum platzieren, der das genaue Datum mitteilt. Ich gehe stark davon aus, dass das Update zw. dem 11. und 15. März kommen wird. Definitiv aber im März.


    Desweiteren ist es leider so, dass nicht immer der angezeigte Name eines Online Spielers funktioniert, sondern nur die Steam ID. Natürlich kann die ID auch kopiert werden, aber warum funktioniert ein Name manchmal und ein anderes Mal überhaupt nicht? Player not found usw. Es handelt sich dabei um ganz normal geschriebene Namen ohne kryptische Zeichen.

    Hmm... normalerweise sollte ein und derselbe Name immer gleich gut (oder schlecht) erkannt werden 8| Tritt das ggf. nur mit bestimmten Namen auf? Ist zu dem Zeitpunkt noch ein weiterer Spieler online, der evtl. ähnlich heißt?

    Well, unfortunately the skull temple really pushes the game to its limit :/ It consists of more than 30k skulls and bones, and it gets quite "expensive" (in terms of performance) to generate and render so many skulls in a small space...
    I'm afraid there isn't much you can do about it... you could try to assign more RAM to the game (by setting the launch option in Steam +memory 4096 4096), but I'm not sure if this really helps (since there isn't much free RAM left anyway).

    Leider werden .mtl Dateien nicht unterstützt. Du müsstest in dem Fall also die Texturen über ein ImageInformation Objekt zuweisen. Der OBJ-Importer versucht zwar automatisch eine MTL Datei zu laden, aber das kannst du eigentlich ignorieren ;)
    Auch die Stack Trace Ausgabe war eher zu Debug-Zwecken drin, die wird im nächsten Update entfernt sein. Aber die dürfte eigentlich keine Probleme bereiten.


    Oder wurde keine BoundingInformation generiert?

    Oh, ja das kann an steilen Hängen leider tatsächlich manchmal passieren. Es wirkt dann so, als würde man bergab rennen, aber tatsächlich "fällt" man - was dann manchmal auch unerwartet viel Fallschaden bringen kann, je nach Distanz =O


    Um die fehlenden Items zurückzubekommen kannst du die Konsole öffnen (mit Druck auf die Taste ^) und folgendes eingeben:


    item ore 64 -105Ein Stack Golderz
    item ore 64 -102Ein Stack Kupfererz
    item pickaxe 1Spitzhacke
    item axe 1Axt
    item hoe 1Hacke
    item rake 1Harke
    item sledgehammer 1Vorschlaghammer
    item sickle 1Sichel
    item scythe 1Sense
    item saplingbirch 88x Birkensetzlinge (meinst du einen anderen Baum?)
    item fishingrod 1Angel
    item map 1Karte
    clothing ponchoPoncho
    clothing soxSocken^^
    item bow2 1Jagdbogen (ansonsten "bow3" für den Schwarzbogen)



    Falls was fehlt, sag einfach Bescheid ^^


    Um zum Unterschlupf zurückzukehren, kannst du gotospawn in die Konsole eingeben, sofern du schonmal darin geschlafen hast (durch das Schlafen darin wird der Spawnpunkt nämlich aktualisiert, sodass du auch beim Tod dort neu spawnst). Ansonsten wird es leider etwas schwieriger, den Ort wiederzufinden (falls du ihn auf der Karte nicht wiederfindest). Du kannst aber den Befehl findbase objects eingeben, um zumindest den Chunk zu finden, wo die meisten Objekte (zB der Unterschlupf) verbaut sind (ansonsten geht auch findbase constructions für den Chunk mit den meisten Bauelementen, oder findbase blocks für den Chunk mit den meisten Blöcken).
    Dort werden X und Z Koordinaten ausgegeben, diese kannst du in der Konsole mit dem Befehl goto X Z verwenden (also X und Z entsprechend durch die Koordinaten ersetzen). Aktiviere vorher am besten den Flugmodus (F2, muss ggf. vorher in den Optionen aktiviert werden) ;)

    Hmm... normalerweise sollten so kleine Höhenunterschiede eigentlich keinen Schaden anrichten, es sei denn, man hatte zuvor ein gebrochenes Bein und trägt derzeit eine Beinschiene. Bis der Bruch verheilt ist (so lange wird unten rechts noch das Knochen-Symbol angezeigt), reagiert man auch auf kleine Höhenunterschiede sehr empfindlich. Wenn die Beinschiene bricht, ist einerseits das Bein wieder gebrochen, und man bekommt etwas Schaden zugefügt (allerdings dürfte das nur dann zum Tode führen, wenn die Gesundheit generell sehr niedrig ist).


    Leider ist es im Nachhinein schwer zu sagen, was in dem Fall genau passiert ist... beim Tod kannst du aber für eine bestimmte Zeit zu deiner Leiche zurückkehren, und die Gegenstände daraus entnehmen. Ansonsten könntest du in den Einstellungen noch ein Häkchen bei "Inventar behalten" setzen. Dann verlierst du deine Gegenstände beim Tod nicht, sondern spawnst wieder mit ihnen. Im Nachhinein kannst du deine Gegenstände damit aber leider nicht wieder zurückholen...


    Da deine Leiche zwischenzeitlich auf jeden Fall schon despawnt ist, könntest du deine Gegenstände nur noch mithilfe von Commands (der item Command) zurückholen oder kurzfristig mit dem Creative-Mode (wie @Avanar erwähnt hat, indem du gm 1 in die Konsole eingibst - dort kannst du dann auf alle Werkbänke zugreifen und kostenlos die Items craften). Wenn du mir grob sagst, welche Items du verloren hast, kann ich dir gerne die nötigen item-Commands mitteilen ;)


    Die Map bleibt aber übrigens bestehen, wie @Sir Prising schon vermutet. Nur das Item verschwindet natürlich. Doch wenn du jetzt eine neue Map craftest, dann siehst du auch weiterhin alle Bereiche, die zuvor schonmal aufgedeckt wurden. Es erscheint übrigens bis zum Restart auch ein Icon auf der Map, welches deine Todesstelle markiert - damit kann die Leiche ggf. etwas leichter gefunden werden.

    Unfortunately the "invulnerable" permission does not cover fall damage or damage from traps etc. at the moment... there is a separate "nofalldamage" permission available though, which prevents the player from taking fall damage, but probably it makes sense to change the "invulnerable" permission as well (to cover all types of damage). We will change it with the next update ;)

    According to @yahgiggle (the creator of this plugin), the Object Protection plugin is supposed to replace the Door plugin - AFAIK there have been some issues in the Door Protection plugin, maybe that's the reason why it isn't working properly in this case?