[Issue (/ Feature Suggestion?)] Conflict w/ Wiremod Tool Base Class

[Brittank88]

Hello Zet0rz!

First of all, amazing addon, thank you for bringing to Garry's Mod something else I love to play.

After speaking with a Wiremod project admin about why Wiremod-style holographic previews for non-Wiremod tools were appearing (refer to below), they had a quick glance at the nZU code to find that the way that tools are being registered (which I know is described by #35) means that nZU actually mistakenly references Wiremod's stool base class rather than GMod's stool base class. Consequently, the preview hologram mechanic is inherited by nZU's tools.

A demonstration of the issue:

A snippet of what Divran (the project admin) said about why this conflict is occurring:

On to the related feature suggestion part:

You know, a holographic placement preview similar to Wiremod's system would actually be awesome and very useful however not in this state where I have a translucent barrel blocking my vision when I try to place spawners and barricades. Maybe it's something to consider? Though if it's too difficult or time-consuming to implement then I totally understand that development is not easy.

Anyways, thanks for your time and I look forward to a resolution!

[Divran]

I believe the correct way to solve the issue is something like this

First, place the following in any default gmod tool file (lua/weapons/gmod_tool/any.lua) to preserve the references to these objects

nzu.TOOL = TOOL
nzu.ToolObj = ToolObj

then, later, in the nzu.RegisterTool function, use this reference instead of attempting to get a new one for instance, replace the following

    local stool = weapons.GetStored("gmod_tool")
    if stool then
        local _,any = next(stool.Tool)
        if any then
            local ToolObj = getmetatable(any)
            if ToolObj then
                local o = ToolObj:Create()

with

local o = nzu.ToolObj:Create()

and also replace the following

                stool.Tool[mode] = o

with

nzu.TOOL.Tool[mode] = o

This fix was based on how wire's custom tool object works. However, keep in mind I did not make wire's custom tool object so my understanding of how it works probably isn't perfect, and I have not even opened gmod to try this solution to see if it actually works. It's possible that TOOL and/or ToolObj are invalidated (ie set to NULL), which would break this solution.

For reference, here's how wire's tool object works. First, in a regular tool file, this code is run: https://github.com/wiremod/wire/blob/master/lua/weapons/gmod_tool/stools/wire_adv.lua#L4-L7

Then, in tool_loader, the metatable ToolObj reference is preserved here https://github.com/wiremod/wire/blob/master/lua/wire/tool_loader.lua#L22 and tools are created and saved here https://github.com/wiremod/wire/blob/master/lua/wire/tool_loader.lua#L467-L501

however keep in mind that wire doesn't try to load tools at a later time. It loads all tools instantly, so it could be that this solution won't work for your use case.

Either way, hope this helped.

[Brittank88]

Wow! Thank you Divran for going to all this effort to see this issue through.

Hopefully this helps Zet0rz resolve this issue, and implement a (potentially) better way of handling custom tools as a bonus!

[Divran]

eh, it wasn't that much effort, I didn't even bother launching gmod hah