"basically, I want my item system and inventory system to work 100% like runescape."
Why not aspire to be better? If people want to play Runescape, they know where it is...
"you could use something like java's/c++ instanceof opperator"
This is exactly why virtual dispatching was invented. So you don't have to look at the types of the objects. You create an interface for doing this and your object types implement it and then you simply call through the interface.
Rule of OO design; if you're using instanceof or dynamic casts or similar monkey business, you've gone wrong in your OO design somewhere. You must find the error and either describe it accurately in the documentation or fix the problem.
Your abstract object needs to specify a way to populate a list of possible command names and actions; probably takes a pointer/ref to the object instance instance (the language object which represents the game object which is of this game type). The names are displayed. When the user picks one, the action is executed. It's probably going to be some simple interface like Java's Runnable or a C++ function object taking no parameters. (The object to apply the work to is encoded i the function object by the menu item factory)
The actual game-object-type classes implement this interface, providing suitably configured command objects as the second part of their pair.
This way, later, when you tire of implementing objects in a hard programming language you can start doing them in softer ones.. like say Lua, and writing the list populator so it fills in command names and Lua function objects and the just dynamically load lumps of Lua instead of having a build/debug cycle.
This also allows objects to change their command structures depending on the world around them. If you're in a suitably magical place, 'wield' becomes an option for the wand. If you're near a river 'deploy' becomes an option for the canoe. That sort of thing.
And since just copying another game is dull, we can think of improvements...
Provide importance ordering on the commands, and now you can float different commands to the top of the display lists (so now the appearance of 'wield' is more obvious to a player).
If you allow things to return non-executable commands, the menu for 'hat' can contain a non-selectable option saying 'already wearing a hat'. And if you remove that hat, this object will change that to a 'wear' command which does work. Now the player knows why an option might become available.