Posts by red51

You can't get existing UI elements directly, but you can still add UI elements to existing elements You'll have to use the Internals class for this. By default you'd use the Player.addUIElement() method to add the element to a player screen. This method also has an overload which accepts a UITarget, but this only supports a few, pre-defined targets.

However, if you want to add a UI element to an arbitrary existing element, you should use the Internals.addUIElementToPlayer() method instead to add the element to the player screen. Just provide the path of the target element as parameter Example:

UIElement myElement = new UIElement();
myElement.setSize(16, 16, false);
myElement.style.backgroundColor.set(1f, 0f, 0f, 1f);
Internals.addUIElementToPlayer(player, myElement, "HudLayer/hudContainer/statusContainer/statusBarContainer/locationLabelContainer/locationLabel");

But the location label is a tricky UI element... not sure if you will get satisfying results when attaching childs to it...

Wenn ich das richtig sehe sind es derzeit 90 Sekunden, bis die Blutung von alleine stoppt

Eigentlich sollte der "Nass-Zustand" des Spielers keinen Einfluss auf Blutungen (oder andere Statuseffekte haben)... ich konnte es zumindest selbst nicht auf Anhieb reproduzieren (habe Blutung erst durch eine Bärenfalle verursacht, dann durch einen Kaktus)

I'm happy to hear the workaround worked But I'd also suggest to change that once the new API is available

Actually this had been on our to-do list for a long time already, but it will finally be added with the next update

Das ist merkwürdig Ich konnte das bei mir leider nicht reproduzieren... passierte das im Singleplayer oder Multiplayer? Verwendest du ggf. Plugins?

Gewollt ist es auf jeden Fall nicht... was aber normal ist, ist dass die Blutung nach einer bestimmten Zeit von alleine wieder aufhört.

Thanks for your feedback! More clothes, including exclusive female clothes (skirts, dresses etc), are actually in the works We've prepared tons of new clothes, but unfortunately I can't say for sure which of them will make it into the upcoming update...

Sorry for the late response! But it's seems you're playing the Java version? Otherwise the "commons.jar" file is not the correct one (it's a file from the Java version)... If you're playing the new version, the "definitions.db" file is located under "Data/StreamingAssets"

I see The next update will have a new, optional "instant" parameter for the "setStatus()" method: if set to true, the new status will be set immediately (no animation, not getting blocked etc), and if you set it to false, the game will smoothly open the door (plays the animation and the door will also be blocked by obstacles) But calling "setStatus()" through the API will always work with the next update, even if the door is locked.

Thanks for the suggestion! Honestly I have no idea why there is apparently no event for item placement But I will put this on my to-do list. Not sure though if they will make it into the next update

Guter Hinweis, das werde ich mit dem kommenden Update ändern

Actually the texture scale has no impact on performance None of the settings in the building menu (that's opened by holding c) really affect performance. Only the total number of pieces used have an impact on performance (although this is typically only getting relevant if you use hundreds of thousands of pieces, for example)

Sorry for my late response! If you can't open the inventory or chat, it indicates that there is most likely a bandwidth/throughput issue If there are too many queued packets, it might prevent the game from receiving/processing other packets (typically resulting in delays for chat messages, cannot open inventory etc).

Being close to another player shouldn't result in considerably more packets... player sync is indeed based on the distance to a player (i.e the closer you are to another server, the more frequently you will receive sync packets), but that should never cause such an issue... but the game doesn't distinguish between admins or regular players

Do you maybe use any plugins?

One thing you could try is to enter the networkstats console command when this issue occurs. If it has a high number of queued packets, it indicates that it's a clientside issue. However, if this number is always 0 (or around 0), it's probably a serverside issue (i.e the server can't keep up sending all the packets). The networkstats command also provides information about the packet loss (a high number, especially a two-digit number indicates that too many packets get lost, resulting in a slow re-request). The ping also plays a major role (ping + packet loss have a huge impact on the total throughput).

Feel free to send a report when this issue occurs (but first enter the networkstats command a few times, so the report contains this information)

Good point! I will change it with the next update

It's probably indeed debatable whether or not the lantern should be a "Torch"... but considering the candle also has the "Torch" type, it's probably best to do the same for the lantern.

For the tent or shelter, I'm not sure if we should use the "Bed" type or just add a new "Tent" type...I'll think about it^^

For the tent or shelter, it's probably best if we add a new "Tent" type (so you can distinguish whether this sets the primary or secondary spawn point)^^

Yes, you can still change the stack sizes in the definitions db Which ones did you actually change?

Just keep in mind that stack sizes are stored as signed 16 bit value, i.e the highest possible value is 32,767

Being able to change the speed will be possible with the next update

About the color, actually you can already change it by painting the light, as mentioned by krazmuze - this will affect the light color

Quote from Nr1Dane

And set regular lights to blink/flash and set/change the interval.

The perfect solution for this would be the future power system But there had been also some considerations for adding some pre-defined light animations. Unfortunately I can't say much about that yet, but it's on my radar

Yeah, unfortunately doors cannot be opened if they're locked... it might work if you first set the "info" to 0, then change the status, then re-assign the old info value, but that's not a good solution...

But I can change the behaviour with the next update, so the API will always be able to open doors, even if they're locked

//edit: just a small question: is it also important that the door plays the open animation (and also get blocked by obstacles)? Or would you like to forcefully set the new status (without animation, just force the door to be fully opened instantly, for example)?

Vielen Dank! Keine Sorge, dein Beitrag war absolut nachvollziehbar (und habe ich keinesfalls als "nervig" interpretiert, im Gegenteil, du hast das sehr freundlich formuliert)

Das Steam-Forum ist leider nicht immer das Gelbe vom Ei (und erinnert vom Funktionsumfang eher an Foren aus den frühen 2000er Jahren), aber da tummeln sich automatisch die allermeisten User. Trotzdem ist es nicht meine Absicht, das Forum hier zu vernachlässigen, du musst dich also nicht unbedingt zu Steam zwingen Wir müssen dieses unbedingt etwas neu strukturieren, da momentan Content der Java-Version und der neuen Version zu sehr durchmischt ist... aber das wird schon

Yes, but it's unfortunately not very intuitive...

The "locked" state is currently stored in the info field of the object, so if you want to check if a door or chest is locked, just check if the info is not 0, e.g:

ObjectElement o = ...;

//Check if object is a door
if (o.getDefinition().type == Objects.Type.Door) {
    //Check if door is locked
    if (o.getInfo() > 0) {
        //DOOR IS LOCKED
    }
}

Quote from reydelreyes

Und wieder ein monat fast vorbei und nirgendwo eine info zu finden ob nun das update wieder verschoben wird 😅

Ungewissheit is einfach das schlimmste 🙈

Tut mir Leid für die Ungewissheit, das ist durchaus nachvollziehbar, leider habe ich nur im Steam-Forum einen Hinweis hinterlassen, ich hätte hier im Forum ebenfalls eine Info schreiben sollen Ich versuche das Update auf jeden Fall weiterhin so schnell wie möglich fertig zu bekommen. Leider musste ich vorherige Woche unerwartet ins Krankenhaus, sodass ich in der Zeit nicht am Update arbeiten konnte... auch diese Woche standen einige Untersuchungen an, sodass ich mich tendenziell eher auf das (Steam-)Forum konzentriert habe.

Ich habe zwar versprochen, dass das Update diesen Monat erscheint, aber es könnte sich leider geringfügig verzögern

Um aber wenigstens nicht mit ganz leeren Händen dazustehen habe ich zumindest ein paar neue Screenshots zu den kommenden POI's auf der Roadmap gepostet

I'm sorry to hear about the crashes Unfortunately there are currently a few NVIDIA users facing similar crashes. It only affects NVIDIA cards (but only some NVIDIA users are affected at all)... some users managed to fix it by updating (or downgrading) to a different driver. It's hard to tell if it's rather a driver bug (triggered under certain circumstances only) or a Unity bug... probably it's a mix of both. But you're definitely not the only one who runs into this issue.

We're updating to the latest engine version with the next update, hopefully this improves the situation. But if you still run into this issue after the update, please let me know! Sorry for not having more positive news atm