Hackybench
Module: hackybench.lua
Overview
The Hackybench module is a thin 4-line specialization of the Bench module. It inherits from Bench via inherit("Bench") and redefines Use as an empty stub โ the file body is literally just the inherit() call plus one empty function.
Inheritance
- Inherits from:
Bench - Imports: none
Instance pattern
Neither Hackybench nor Bench follows the per-instance/uGuid pattern. Bench.lua (checked directly) defines only QueryRepair, QueryActiveUse, SuperUse, Use, and MakeUpright โ five plain functions, no OnActivate, no Awake, no Create, no setmetatable, no tInstance registry, and no inherit() of its own. Hackybench adds nothing on top except overriding Use. Both modules are stateless โ there is no per-instance state to track at all.
Functions
Use(aiguid, floatval)
Overrides Bench.Use. Empty body in both Hackybench and Bench โ this override doesnโt actually change behavior, since the base implementation was already a no-op.
Inherited from Bench (not redefined here): QueryRepair(intVal) (returns "MakeUpright" if intVal == 1, else ""), QueryActiveUse(intVal) (returns "SuperUse" if intVal == 1, else ""), SuperUse (floatval, aiguid) (empty stub), and MakeUpright(objectguid, aiguid) (empty stub).
Events
No events at all. Neither Hackybench.lua nor Bench.lua contains a single Event.* reference โ no Event.Create, no Event.ObjectHibernation, nothing. The previous version of this page claimed Event.ObjectHibernation/OnUse wiring โinherited from Bench,โ but Bench has no such wiring to inherit; that claim did not check out against source.
Notes for modders
- This module is a placeholder/template โ every function it defines or inherits from
Benchis either an empty stub or a trivial string lookup. There is no observed engine hookup (activation, hibernation, or use-trigger event) anywhere in this two-file chain. - To extend this module, override
Usewith custom logic; be aware youโre starting from nothing; the base classes provide no scaffolding to build on. QueryActiveUse/QueryRepairstring returns ("SuperUse","MakeUpright") look like theyโre meant to be read by an external/native dispatcher (likely by name, to decide which function to call next), but no call site for that dispatch was found in the decompiled corpus โ canโt confirm the mechanism from static reading alone.