@Prangerle_Solutions the bug is fixed, and the example code in my reproduction work as intended.

Ok, then please support it. Sorting vectors in any reliable order is better than the current results. Sort by first coordinate if same then second, if same then third. So the same ordering that they would have if converted to a string first and then sorted by alphanumeric order.

I have done further testing on this and even though the roadway LOD visualizer might have a visual offset for display purposes, it actually affects the physics right now as well. Both on diag and non diag build. So @Tyson this should actually be a bug that needs fixing. Good report. I just stumbled across the same issue on my mods ;)

this task can get an update internally. If intended or not the BI UID now returns in the workbench and local game host etc, but one frame after where it is supposed to be available.
We were told on multiple occasions that the event SCR_BaseGameMode.GetOnPlayerAuditSuccess() would be the first and proper one where the call to GetGame().GetBackendApi().GetPlayerUID(playerId) should return correct data. This is correct on DEDICATED servers but not in WB and SP. There right now I need to do this workaround:

m_pGameMode.GetOnPlayerAuditSuccess().Insert(SomeCallerWrapperFor(WaitForUid));

Some cases appear to be fixed, but there are still issues associated with this issue. Please reopen.

2023-07-17 15:20:42 (UTC) : Version: 0.9.9.38 - Report Successful (Crash GUID: d98af92c-32e4-4a9c-bfdd-30be6eb5b356)

@Geez please reopen, this is still not fixed even in the exp update from today 0.9.9.38

If my exact example is now compile erroring correctly the issue must have been fixed already. In that case this can be resolved yes

coming back to this, I saw the behavior changing with todays 0.9.9.31 update but it is still not working. Instead of "pending to process" it now returns an empty string instead of what the webserver actually serves. Please double-check if the fix was considered merged, if so there must have been a mistake - or if the full fix was not planned to be included yet and the change in behavior was an unintended side effect of something else.

Ok, I will check when 0.9.9 exp drops and let you know if it can be closed or not. Thank you for the investigation.

I have just run this code on 0.9.8.73 and reproduced the error. If this code compiles without error on the current dev build then I guess one of the many fixes made in the mean time to the script-vm maybe fixed it. Please try my example to be sure:

I don't understand why this ticket was resolved. Confusion aside, this is not what I asked for. To make it very clear, the issue is NOT resolved.

Sanity checking with postman shows that webhook.site does not echo by default or anything. Just empty response body. And that triggers the problem, both with POST and PUT and maybe anything that sends a request body?

I am sorry if my bug report was not clear enough. I thought I had given all the required info to reproduce. I make so many tickets here each week that sometimes I don't have time to provide a full reproduction. However here it is ready to copy paste

I feel bad for making you play Messenger here, but I would like to point out to the responsible dev that we need support for in script because we can as he said, have utf8 in the UI, and thus we need to handle utf8 chars that appear in the setter or getter code when interacting with widgets, or things like player names or chat messages that have utf8 characters. Declaring that string myutf8string = "Hällö fröm the öther Sßide こんにちは世界" can not be possible or even worse - is not needed - is not comprehensible for me. If there is no support for it right now then it should be added for sure.

@Geez that I can not quite agree with, given how DayZ has utf8 support because of the launch in China so it supports Chinese utf8 chars. I would be surprised if it was only present in DayZ's engine fork. Please ask for clarification again.
The only possibility of the answer being true ist if the utf8 versions in DayZ are sham and do not actually work/do anything and its just the default WANSI strings operations under the hood.

Update: This is in fact not only a visual bug but also breaks the default intent of new lines in any code following this.

Any update on this? It has been nearly a year and still nothing?

No longer relevant due to refactoring of the system that was completed in 0.9.8.50 @Geez

Resolved already in 0.9.7 I think. So Can be closed too @Geez

Resolved as of 0.9.8.50 with the introduction of ScriptComponent::OnAddedToParent etc. @Geez please close.

Confirmed still an issue in 0.9.8.50