gui/mod-manager improvements

[ong-yinggao98]

• Fixes Mod Manager does not automatically update vanilla mods dfhack#4799
• Fixes gui/mod-manager should be able to automatically apply mods to the Object Testing Arena dfhack#4402

Requires DFHack/dfhack#5500

The manager also notifies users when a version of a vanilla module in their preset has been changed. This way they should know to update the preset to avoid the popup in future. Since mod manager no longer gives a hoot about the vanilla module versions, an entirely vanilla preset for 51.13 should theoretically also be backwards compatible with an older version.

TODO

• Mod Manager is duplicating mods to both inactive and active lists. dfhack#3746 Too much for this PR, I'll likely tackle it next time.

[ab9rf]

I suspect the reason why fields.src_dir[i].value:startswith('data/vanilla') does not work is because fields.src_dir[i].value is a C++ string (being accessed via proxy), not a Lua string, and so the Lua method startswith (which is defined for Lua strings but not for C++ strings) doesn't work.

[ong-yinggao98]

I suspect the reason why fields.src_dir[i].value:startswith('data/vanilla') does not work is because fields.src_dir[i].value is a C++ string (being accessed via proxy), not a Lua string, and so the Lua method startswith (which is defined for Lua strings but not for C++ strings) doesn't work.

Interesting, but in that case why does it work in script-manager.lua::get_active_mods()? It seems to call startswith just fine and the target seems to also be a C++ string.

-- local ol = df.global.world.object_loader
        local path = ol.object_load_order_src_dir[idx].value
        table.insert(mods, {
            id=ol.object_load_order_id[idx].value,
            name=ol.object_load_order_name[idx].value,
            version=ol.object_load_order_displayed_version[idx].value,
            numeric_version=ol.object_load_order_numeric_version[idx],
            path=path,
            vanilla=path:startswith('data/vanilla/'), -- windows also uses forward slashes
        })

[SilasD]

maybe forcing it into a Lua string would work? untested code.

tostring(fields.src_dir[i].value):startswith('data/vanilla')

Edit: Your comment in gui/mod-manager.lua shows this code:
from_fields.src_dir[i].startswith('data/vanilla')
That doesn't work the same as this edited code:
from_fields.src_dir[i]:startswith('data/vanilla')
The . was changed to :, to comply with Lua's object-oriented style string functions.

[ab9rf]

Interesting, but in that case why does it work in script-manager.lua::get_active_mods()? It seems to call startswith just fine and the target seems to also be a C++ string.

-- local ol = df.global.world.object_loader
        local path = ol.object_load_order_src_dir[idx].value
        table.insert(mods, {
            id=ol.object_load_order_id[idx].value,
            name=ol.object_load_order_name[idx].value,
            version=ol.object_load_order_displayed_version[idx].value,
            numeric_version=ol.object_load_order_numeric_version[idx],
            path=path,
            vanilla=path:startswith('data/vanilla/'), -- windows also uses forward slashes
        })

Because local path = ol.object_load_order_src_dir[idx].value results in it being converted from a C++ string to a Lua string, and so path:startswith is looking for that named method on a Lua string.

This is an artifact of how our C++ object proxying into Lua works. When you directly "read" from a C++ string in order to use its value as a Lua value, the proxy handler automatically converts it into a Lua string. However, when you call a method directly on an object, this doesn't happen: instead, the metatable of the C++ proxy object is consulted, and as there is no startswith method in the C++ string proxy object metatable, the method call fails.

It might be an idea to "chain" the Lua string metatable onto the C++ string proxy metatable, but I'm not at all sure how to go about doing this. Will require considerable thought.

Copying the proxy object into a local variable before calling the method should provide a workaround since the C++ proxy object will be converted to a Lua object at that time.

[ong-yinggao98]

I haven't tried SilasD's suggestion, but ab9rf's works like a charm.