By creating that Turret object (hint: new)

Precisely the same way as you'd write any other mob AI, only it wouldn't move. You'd find something like this in Zilal's Beginner Tutorial (ZBT).

Also: "usr" does not mean "player". Don't confuse them or it'll make you screw something up very badly.

Basically, there's no one best way to do it. With practice coding, you'll eventually start breaking down what you want to do into things you know how to do.

Example: I want a turret that can be placed by the user and will attack nearby enemies.

Execution:

* I want a turret that can be placed by the user...

This part defines that this turret object you're creating is going to be portable. What solutions can we think of here?

One solution I can think of is to have this turret riding around in the player mob.contents for awhile and the player is able to drop the turret where he wants.

Another is you could have some kind of verb the user can use which simply creates it where the user specifies if certain conditions are met.

* ... and will attack nearby enemies.

This part defines the behavior of the turret when it's activated. What solutions can we think of here?

One solution is you could put the turret on a while() loop that contains a sleep() so it comes back every once in awhile to loop again. This loop will have code that regularly generates a list from enemies in view() and fires at the nearest one.

That's actually a bit bloaty because now you've a process for every turret you have in the game. What would be more efficient? Perhaps instead of having turrets scanning for targets constantly, you could code the turf.Enter() proc to broadcast to any turrets in view() that the target is now able to be shot at. That would be a lot more efficient because turrets that are way out in the boonies with no targets in range can sleep without any clock cycles at all.

Don't worry if these solutions didn't jump out at you right away. As you continue to practice, you will have more tools rattling around in your head to be able to come up with solutions like this. Before long, you probably would even be able to come up with way better solutions. The trouble becomes not figuring out how to make the turret, the trouble becomes stopping making better and better turrets long enough to finish the game!

You know, we should probably have a "basic coding practice" sticky at the start of this forum. It wouldn't talk about specifics you'd see in the references, it would talk about the mental mindset establishment for coding. Although, maybe that's too big of a fish to put in one sticky?

Garthor wrote:

Also, Enter() would not be the place to put this, as it should only be used for pathfinding type stuff. Entered() would be more appropriate, but still wrong. mob/Move() is where it would belong.

Right, Entered() is what I meant.

Mob.Move() is not a bad idea, but the difference is minimal. Assuming we're going to use Mob.Move() all the time on the grounds we want turrets to be able to see them, both Mob.Move() and turf.Entered() are called every time the mob moves. So the execution amount would be about the same, except you'd have to put a different/additional kind of type check on Turf.Entered().

Anyway, this is just the same point I was making: there's many ways to skin a cat. Which is right for your game will be up to you with a bigger picture concept of the overall scenario.

Garthor wrote:

The difference is that turf/Entered() is a proc that belongs to turfs, and mob/Move() is a proc that belongs to mobs. Because this is a concept encapsulated by mobs, it makes much, much more sense to put it in mob/Move().

Sure, you could say that turret tracking is all about the mobs. In many cases, you'd be completely right here - define the tracking on the appropriate types of mob and it will be a little more efficient than turf.Entered().

Alternately, you could say that turret tracking is all about the terrain's relationship between the mobs and turrets. Does it, then, mean that it makes a lot more sense to define the turret tracking code on the turf?

Not necessarily. Basically, we're talking about such an abstract concept of non-existing games that it's impossible to derive which scenario we're dealing with. Whichever approach you're more likely to go with will very much depend on what's more important to your game.

This is what I was trying to convey to the original poster: there's many ways to go about this, and how will depend very much on the scenario.

turf/Entered() would be more appropriate, actually, for 2 main reasons:
1) We only want to catch movements into turfs here.
2) More importantly, Entered() as a global solution in every project is more robust; Move() is just one proc that can move an object, but a good programmer may also add others since Move() isn't suitable for all kinds of movements. Those procs would of course trigger Entered() properly. If you override Move(), you don't catch entering-into-turfs that could've been initiated from different moving-procs. Of course, not every project may have those, but if you take into account the possibilities then this is more robust.
As for the object orientism, that's more of a tidiness issue, not a functionality issue like above, but it doesn't really apply since you could easily farm out the code to a movable proc that's called from turf/Entered().