User Details
- User Since
- Jun 21 2015, 9:43 PM (479 w, 6 d)
- Roles
- Administrator
Tue, Aug 20
Jul 30 2024
Can you please also attach your workbench logs of a session (perhaps this exact one in the video). Console.log will be enough.
Jul 12 2024
thank you very much for taking the time to report this. We identified multiple issues regarding this and a fix should be included with one of the next updates. It will be mentioned in the patch notes then.
Jun 27 2024
May 7 2024
Will be added in a future update
Feb 26 2024
Jan 21 2024
@Prangerle_Solutions the bug is fixed, and the example code in my reproduction work as intended.
Sep 12 2023
Sep 6 2023
Aug 14 2023
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.
Aug 10 2023
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 ;)
Aug 7 2023
Aug 3 2023
Aug 2 2023
Jul 27 2023
Jul 21 2023
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));
Jul 20 2023
Jul 17 2023
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)
Jul 16 2023
Jul 13 2023
@Geez please reopen, this is still not fixed even in the exp update from today 0.9.9.38
Jul 10 2023
If my exact example is now compile erroring correctly the issue must have been fixed already. In that case this can be resolved yes
Jun 29 2023
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.
Jun 26 2023
Jun 12 2023
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.
Jun 9 2023
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:
Jun 6 2023
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.
Jun 5 2023
Jun 4 2023
Jun 3 2023
Jun 2 2023
Update: This is in fact not only a visual bug but also breaks the default intent of new lines in any code following this.
May 30 2023
May 29 2023
Any update on this? It has been nearly a year and still nothing?
May 28 2023
May 26 2023
May 24 2023
May 20 2023
May 19 2023
May 18 2023
May 17 2023
May 9 2023
May 6 2023
May 5 2023
May 4 2023
May 3 2023
May 2 2023
May 1 2023
Apr 29 2023
Apr 28 2023
Apr 27 2023
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.