It looks like variable "description" in mod.cpp does not work.
I think problem is somewhere near 5_mission/gui/newui/modsmenu/modsmenudetailedentry.c
Only Livonia DLC description works and also is localized.
It looks like variable "description" in mod.cpp does not work.
I think problem is somewhere near 5_mission/gui/newui/modsmenu/modsmenudetailedentry.c
Only Livonia DLC description works and also is localized.
-start game with mods installed
-click to mods
-look to descriptions
I used template from https://community.bistudio.com/wiki/DayZ:Modding_Structure and there is variable "overview", but in code I see "description".
Please update wiki, there is also need add overview entry into config.cpp of mod, then will start this feature. Also regarding localization there are need update of wiki. Use strings like $STR_yourmodname_overview and add it to stringtable.csv. Then everything started working.
You can close this ticket when will be wiki updated :-)
In 1.14, every mod which is not a DLC displays the default widget text, a rather unimaginative W, instead of the actual description.
I tried to make sense of the code I get via "extract game data" to try and find out if I can maybe fix whatever is going on here with a mod but I couldn't find any obvious issue within the script.
But I did realize while searching through the extracted data that all getters in ModStructure return m_ModName which apart from the obvious spelling mistakes like GetModToltip() makes me think that whatever this was once supposed to be is not actually used in the game and should probably be removed.
I then came across a call to m_Data.GetOverview() in ModsMenuDetailedEntry.LoadData() where m_Data is an instance of ModInfo. This function apparently doesn't return the value from mod.cpp as it's supposed to do.
ModInfo contains proto native owned string GetOverview(); which I'm assuming means that this function is baked into the actual game executable or something.
For now, I came up with this workaround to replace the broken description with a fallback string so that people using my mod see something which makes more sense:
modded class ModsMenuDetailedEntry extends ScriptedWidgetEventHandler { protected Widget m_Detail; protected RichTextWidget m_Description; protected ModInfo m_Data; override void LoadData() { super.LoadData(); string description = m_Data.GetOverview(); if (description != "") { m_Description.SetText(description); } else { m_Description.SetText("Description not available"); } } }
Looking at ModInfo.GetTooltip(), that one doesn't seem to return anything but an empty string either.
I guess we could say that ModInfo appears to have some issues in general.
That is not quite true. What magic sauce did @InclementDab use so that his mods have their overviews properly shown in the main menu?
Both of these mods' mod.cpp files use stringtable.csv string references. For example:
overview = "$STR_EDITOR_DESCRIPTION";
🤔
Yes, the strings need to be localized via the stringtable.csv.
mod.cpp:
... name = "$STR_EXAMPLE_MODNAME"; author = "$STR_EXAMPLE_AUTHOR"; tooltip = "$STR_EXAMPLE_MODNAME"; overview = "$STR_EXAMPLE_OVERVIEW";
with the corresponding entries in the string table and it works just fine.
There is no mention of a string table neither in the Modding Basics nor the Modding Structure wiki pages. How are mod creators supposed to know that it exists?
Now that you mentioned it's existence, I was able to find an incomplete example in the DayZ-Samples GitHub repository which merely demonstrates the structure of the stringtable.csv, but not how the translations within are actually referenced within the code or where this file needs to be placed in a mod's filesystem structure.
The comments by @Hunterz also implied that localization is merely an optional thing which is nice to add, not a requirement. Seeing the huge amount of mods without a working description, it should be obvious that almost nobody sees this as a requirement at this point.
Anyway, I consider W a horrible and not helpful fallback value which doesn't give mod creators any hint what's wrong and I doubt that it's supposed to work this way. This is at least a design flaw which IMO needs to be addressed.