i went to use GetItemPropertyInteger() and was disappointed to find out that it crashes the server.
looking into it, i found out that this function uses the same hook method used to get effect integers… the problem is the hook hasn’t been initialised yet (and prb shouldn’t be, given that itemproperties are NOT truly effects, technically speaking), so the function ends up trying to indirect through a null pointer. i surmise the same will happen for all of the GetItemPropertyXXX functions.
has anyone ever used this function successfully? …and if so, and you happen have a working patch, could i get a copy? please?
i noticed that @niv was the last one to modify this file. maybe he’ll have some insights and/or newer source. does anyone know if he still monitors these boards?
frankly, it would be faster for me to write a whole new set of routines to replace the broken ones. but if there’s been further dev since 2015 that might’ve already solved this problem, it’d save me some time.
I never used that particular function back in the day but itemprop in nwscript is indeed an effect with the type: const int EFFECT_TRUETYPE_ITEMPROPERTY = 91;
The below is Lua, it shows how the item property values are mapped to itemprop effect integers (as of diamond edition). I forget all the functions available in nwscript, but unless you’re wanting to set integers yourself which is difficult given these effects are generated internally, the function doesn’t seem very compelling.
-- Sets the item property effect values directly.
function Itemprop:SetValues(type, subtype, cost, cost_val, param1, param1_val, chance)
subtype = subtype or -1
cost = cost or -1
cost_val = cost_val or -1
param1 = param1 or -1
param1_val = param1_val or -1
chance = chance or 100
self:SetInt(0, type)
self:SetInt(1, subtype)
self:SetInt(2, cost)
self:SetInt(3, cost_val)
self:SetInt(4, param1)
self:SetInt(5, param1_val)
self:SetInt(6, 1)
self:SetInt(7, chance) -- Chance
self:SetInt(8, 1) -- Useable
end
well, yes, this is the issue, not money. i actually own ee, i bought it when it first came out, along w/the other person i develop with. during the many years since ee first appearaed, we’ve thrown around the idea of migrating to it from diamond several times. frankly, it just isn’t feasible – for a number of reasons, but the most important of which is that, indeed, it would take ‘that much work’ to migrate.
yes, the structures are the same. the bug comes from the fact that the itemprop structure hook is never initialised because, even though they seem to use the same structures, the entry points for initialising effects and itemprops are different, and in nwnx_structs it’s the effects that have been hooked.
that’s the use case, yes.
we don’t [currently] use nwnx_lua, but your approach is promising. do you actually already use this lua function for this functionality, or are you modeling the functionality in lua here in this thread for demonstration purposes?
I think you’d be better off just hooking CVirtualMachine::StackPushEngineStructure yourself, given your use case then. The original rational for the hook as it is was performance, maybe Acaos still reads the Higher Ground forums?
The example I gave was from my NWNX Solstice project which used LuaJIT… In context, itemprops. I used it in production on my server, but it would take far more work to revive and integrate. I.e. there are now only ideas there, not solutions.
the problem is the hook hasn’t been initialised yet (and prb shouldn’t be, given that itemproperties are NOT truly effects, technically speaking), so the function ends up trying to indirect through a null pointer. i surmise the same will happen for all of the