Make Tile and Actor separate subclasses of MHObject

[StLoch]

There has been some confusion over 'What is a Tile? What is an MHObject?' This arose because Tiles were changed to no longer be MHObjects, but people still wanted to be able to handle Tiles and MHObjected similarly. To this end, MHObject should be split down into MHObject and MHActor. MHActor will contain the bulk of what MHObject currently does and assume the role of the base class of typical objects created by the DSL.

[StLoch]

I'm not actually sure what MHObject will do, but people insisted on it previously, and it might prove to be useful in the future. I do think we should discuss the idea that Tiles and MHActors can be selected at the same time in the game, though. I can't think of a time when I'd legitimately want both and I don't want to have to "narrow my selection" every time I highlight shit just because I only want to interact with the dwarves or something. I'm thinking whether or not we select tiles or dwarves should actually be context sensitive: if you just told a bunch of dwarves to mine, the next selection should probably be on Tiles instead of Actors; If the user is holding 'command' when they drag, select Tiles instead of Actors; etc...

[StLoch]

Oh, and just to be clear, we need MHObject/MHActor (c++) and Object/Actor (ruby).

[datalurkur]

I wasn't under the impression we'd be giving dwarves specific orders. I had imagined you would select a group of tiles and click "mine these tiles", rather than selecting dwarves, telling them they're about to mine, and then selecting the tiles to be mined.

Selecting areas of tiles is useful for other reasons as well, such as designating zones (dump zones, stockpiles, guard posts, etc).

[StLoch]

No you're right. It was a bad example. The point holds, though. Lets say you select dwarves to assign them to a military squad or something, instead. I still don't want to be selecting dwarves and tiles in the same go.

[datalurkur]

Sure. My thoughts were that you will mostly be selecting one or the other, in which case we can set a default. Here's how I imagine this will work: 1) Select an area of stuff 2) Filter the selection automatically either using a default type or intelligent logic to determine what the user was trying to select 3) In selection context menus, add the option to filter by a different type, instead

So, basically we collect everything that the user might possibly want to select and then make an intelligent decision. This way, we retain the ability to be flexible but get rid of an annoying step for the most common cases. Sound good?

[StLoch]

Yeah, that sounds reasonable!

[datalurkur]

This has been done for a while, now.