ID:2049133
 
(See the best response by Lummox JR.)
I'm running into a weird issue where making a class that derives from atom causes a bad loc error when creating something of said class with a null loc, but changing the class to derive from obj doesn't seem to care.

And I'm not really sure why.

Basically the only thing I need from atom over datum are the Click() procs, as there's not even the concept of a map in what I'm working on, so having to lug around more completely unnecessary variables is kind of blegh. So I'm wondering if there's a way to bypass this bad loc error using atom, or if I'm just stuck using obj instead.
Best response
Arctangent wrote:
I'm running into a weird issue where making a class that derives from atom causes a bad loc error when creating something of said class with a null loc, but changing the class to derive from obj doesn't seem to care.

And I'm not really sure why.

Basically the only thing I need from atom over datum are the Click() procs, as there's not even the concept of a map in what I'm working on, so having to lug around more completely unnecessary variables is kind of blegh. So I'm wondering if there's a way to bypass this bad loc error using atom, or if I'm just stuck using obj instead.

You can't derive classes from /atom or /atom/movable directly. If you set parent_type = /atom/movable, the compiler basically makes it an obj and weird things can happen.

But if your object isn't meant to be displayed like an atom, then I'm really not sure why you'd need to borrow Click().
Your problem could be that it is derived from /atom and not /atom/movable.

Both /turfs and /areas are types of /atom and they both handle loc completely different than the other types.

Whereas /obj and /mob (subtypes of /atom/movable) handle loc in the same way, they are either on a turf or within another /atom/movable or have loc = null.

So if you want to minimize its inheritance you could have it inherit from /atom/movable, though the reference suggests only using /obj or /mob if you want to create one of this type in your game.
Inheriting directly from /atom/movable is dangerous and is not supported; to whatever extent it works, it's a bad idea.
In response to Lummox JR
Lummox JR wrote:
You can't derive classes from /atom or /atom/movable directly. If you set parent_type = /atom/movable, the compiler basically makes it an obj and weird things can happen.

But if your object isn't meant to be displayed like an atom, then I'm really not sure why you'd need to borrow Click().

Ah, that makes sense.

As for why Click() is needed, it's because I'm still using info tabs.
In response to Arctangent
Arctangent wrote:
As for why Click() is needed, it's because I'm still using info tabs.

For that you'll definitely want an obj. I suppose you could do an area instead, but I think obj makes way more sense semantically.