Placing a wrapper class Actor between the base and derived classes was not that clever after all. I wanted to give Opener and Container ability to some object types through Actor, but as usual when something may seem like a good solution it turns out to have unexpected problems.
The problem with Actor was that it didn't know about derived classes. In actions like opening something there is more involved than just the component data of Opener class. Different openers act different ways. So the rewrite is about removing Actor and moving Opener and Container classes as components of derived objects. With that approach you can't avoid copying code of virtual functions. Good thing is that the code is short, because of functionality of component classes. And more importantly you get to write individual opening code for each object type, checking out things that belong to the derived class.
Like for instance there are doors and sewers, both openers. But sewer is really a different thing, because the lid can be missing! So, using virtual Open() for both door and sewer have same type of code for Opener section, but there are special things that only certain object types have. Also, when you have virtual Open() it's going to be easier to handle, because you can use the base class handle for opening action.
I think the cost of using virtual functions is not that bad when compared to difficulties that follow with extra class in middle of the class hierarchy. I believe the rewrite can be done during this weekend, so it's not going be that hard, even though it is kind of a big change to the game object system.