Context: From some of your comments, it seems like you're dealing with what's basically a desktop application running on JavaScript, so this is mostly written in that light (that is, the scenario is not Web-MVC).
"I have seen in various places that “if you can’t put your models onanother application and the controller of that application callmethods from this model inside another controller, then your probablydoing it wrong.” These are experienced and respected developers makingthis point."
[...]
"Meaning the exact same logic [that was previously in] my controller [now resides] in my Model.Yet some say this is wrong, app logic should be in the controller, mymodels are now only suited to the monopoly game" [emphasis by the answerer]
So, the point that is being made shouldn't be taken too literally, cause what's meant by "another application" is a bit more technical than it appears.
It's absolutely fine that your domain model is only suited for making monopoly games. Remember, you're not making some general-purpose programmable environment (that's what programming languages exist for), you are making a monopoly game.
Being able to use that in a "different application" means that you have arranged things in a way that allows you to take that code without dragging the controller/UI stuff along with it (and, potentially, any other externalities, like a database) - and make another monopoly game application (perhaps with better graphics). So, it's the ability to just extract the very core that encodes the logic of the monopoly game (note: not necessarily easy to achieve, you have to think it through, and it might take several iterations). That core doesn't have to be functional by itself (doesn't have to be runnable out of the box), it just needs to capture within itself the rules of the monopoly game, and allow you to "plug in" (or build around it) different components (such as a GUI) that together with it make a complete application.
It doesn't mean that you are able to make any game whatsoever. Now, you could redesign your model/implementation so that it's more general in nature, so that it's able to support several different types of monopoly-like board games, but that's just domain modeling (you're re-conceptualizing the core problem itself). It's a separate issue from the MVC separation of concerns.
"So if that’s the case, that would imply all my logic is done within acontroller"
In light of the above, this is not the implication. Your non-UI application logic (business logic) should be on the model side of things (this could be a rich domain model, services and data structures, or some combination of the two).
One way to think about is that, you should, in theory, be able to take that and attach a differently conceptualized UI to it (say, terminal-based, instead of a GUI) - think of that as a "different application" as an initial approximation.
"E.g. if property is for sale the create a popup box asking if userwants to buy property? Achieving that is hard if my logic is in themodel !"
Now, note that what's discussed above doesn't mean that you should make your domain objects magic black boxes that do everything, and somehow shoehorn UI logic in there as well.
You'd still call and orchestrate stuff from the controller, you'd just be calling higher level methods on the domain objects (or services) themselves, instead of manipulating every detail on the spot. If implemented correctly, your controller code would end up being simpler, and you'd almost be able to read the method calls in it as if it were a list of bullet points - a list of high level steps describing the purpose of the method, rather than a wall of generic program instructions that you need to make sense of when you come back to the code 3 months later.
E.g. you wouldn't ask your model to create a popup, you'd create a popup in the controller (or in whatever UI code is responsible for that), and pass a domain object to the popup so that it calls methods on it (like buy(...)) it or get information from it (e.g., you'd call getPropertyDescription(...), and populate the fields with what that returns), or something along those lines (in an actual application, the logic might be a bit more involved, but the basic idea is the same).
Also remember that you can (manually or via a DI container) inject polymorphic objects and/or lambdas into some of your domain objects. E.g. an application-level domain object can accept, as a parameter to a method, an object or a lambda that allows it to send over the result of some calculation when the method computes it. You can pass it (or inject) code that takes in some data and updates something in the UI - the object doesn't know anything about the UI because it's just passing a computation result, and the handler comes from an external source.
