I have put up the initial script debugging guide/documentation here
https://community.bistudio.com/wiki/DayZ:Workbench_Script_Debugging

Also not ideal, as historically people did make "optional" mods

Then this can be marked as resolved. Thx for the info there.

After a short test this is what i found out:
To display a Widget in front of the Map Widget it needs to be in a parent Widget next to the Map Widget.
The Map Widget itself needs a priority of at least 1 to let this method work! A value of 0 will not work.
The Widget that should be in front of the Map Widget need a higher priority value then the Map Widget.

Even closing the file and reopening it in fixes the line numbers.

Screen record is probably overkill but any supporting information would be useful. Does script editor restart resolve it? (Or you need to restart entire WB)

yes it is not ideal but better that nothing (breakpoints and see variables values helps a lot)
Did you succeed on using it ?
If yes, did you encounter the issue I report on the github page?
Sadly I'm stuck I and loose so much time becouse not be able to use things like this :(

I know that guide but I seriously hope that that is not the intended way to manage projects in WB

Maybe you can take a look at this : https://github.com/maxkunes/Enscript-Workbench-Project-Setup
I did not succes at setting it up (see issue) but I miss so much this fonctionnality. pls tell me if it works for you.

This is very unlikely to be officially sanctioned. I would rather look at reasons why the things above have to be edited this way / what is stopping you from making your own models and address what we can.

All the mods will have to be loaded, similar to what EqualModRequired does now

If RequiredAddons is not planned, how do you intend server owners to make sure the required mods are loaded for players? If a player loads unallowed mods he will be kicked because of verifySignatures, so that is covered, however, what if I join the server and do not have 2 out of 10 mods loaded.
This could be used to exploit game mechanics by not having certain objects visible in-game, or not being forced to react on certain RPC's sent from the server.

I had this issue, It happens quite regularly. But im not really sure what triggers it. Closing and Opening the file in WB fixes said issue.
If that is not enough info next thing i can offer is screen recording of my session next time i do it to try to narrow it down.

This should be solved by updated licenses, in progress

We will be releasing some modding examples, likely on github, although order largely depends on time constraints of the responsible individuals. The examples will likely start with scripting ones but the request for sample models/commented configs is noted

This one is a bit all over the place, stuff mentioned here might not come at the same time

It does, but you need to have the mod.cpp separated from config.cpp, which makes it annoying to pack. I'll see what's up

Sadly extremely unlikely to be fixed for DayZ as its relatively small thing requiring considerable changes. Forwarded to the Enfusion guys though.

That makes sense. But as long as there is some limitation for "normal" users due to any security aspect or whatever reason, please add an easy way of bypassing that restriction if you are a developer and know what you are doing.

We definitely don't want this in the form of a parameter as that creates barriers for clients downloading the mod, we are currently looking at options of extending the limit or improving the functionality in a way that would allow us to remove it

We haven't encountered this here, do you have some kind of reproduction/rate of how often this happens?

You can render Them above Map widgets. You have to put them on the same parent widget and set the Priority the the other widget higher than the Map Widget. At least that is how I got it fixed

This isn't working in a way that you would expect it to currently, but we are testing solution for this, a little how to guide should be included when its done

Thanks, updated for 1.03

Not really a modding issue, probably something on the side of your configuration - discord and forums are good place to get help with these issues.

No IsInventoryVisible is something different in this regard.

Close the task @rVn, already sorted out.

ok I found what was the problem with sourcetree (max txt file size) but the other questions stay valid :

I do agree that the script log should be reduced in useage and kept for debugging (hence my mods that are made for extended logging info being moved to dedicated systems as the ADM file gets quite busy too). And absolutely there are some mods that spam the file a lot (despite having requested options from modders to be able to turn them off).

AussieCleetus, in my opinion, mod creators should keep amount of stuff logged into script log as low as possible.
Rn some mods from top of Steam Workshop are just bombing these log files with useless debug messages (I guess you know, which mods I'm talking about), and 14 symbols is nothing compared to bloating output generated by these mods.
Besides that, this prefix won't affect client or server performance unless your mod is logging tons of characters, which you shouldn't do anyways.
So, compared to other problems, this is nothing. Rewriting entire logging system just to remove this prefix (which might affect performance even worse, as it will lead to generating 2 strings instead of one) - well, doesn't seem like a good idea
[offtopic] rVn, pls take a look at T136977

How can I see if a file is core game?
Why there is no problem with the other .cpp?
Why can I double damage on heavy attack but can't modify the other attacks on the same file?

From an optimitation standpoint it's just bloat. Though it's a minimal amount per line, it would reduce the amount of data written to the hdd. As more mods start printing to the file it really adds up quite fast. The cycling combats some of the issues but the script log really can get huge fast