hello guy so has the title said im gettin a var error when im usin the verb iconset.
im using a parent_type to set mob as a other name
here is the code of the verb and where the PLAYER is setting the path to mob


GAME_MOB // here i set GAME_MOB parent to mob
parent_type = /mob
step_size = 8
icon = 'Art/Player.dmi'
// step_x = -16
bound_width = 32
bound_height = 54
bound_x = 16
bound_y = 1
level = 1
iconset = 0

//*thoose code are not in the same page*

PLAYER // here i set the PLAYER parent to GAME_MOB
parent_type = /GAME_MOB

Say(T as text)
var/PLAYER/p = usr
view(p)<<"<small><font color=green>([]): </Font>[html_encode(T)]</Font>"
var/PLAYER/p = usr
var/choice = input("Wich icon you want?")in list("Gold")
if(choice =="Gold")
p.icon = 'Art/Player.dmi'
p.iconset = 1

Problem description:

i can't seem to find the problem
im not getting error from compiler but from the errorlog im getting this when i use the verb

runtime error: undefined variable /mob/var/iconset
proc name: set icon (/mob/verb/set_icon)
source file:,13
usr: (src)
src: Carcanox32 (/mob)
src.loc: the grass (1,1,1) (/turf/grass)
call stack:
Carcanox32 (/mob): set icon()

any help is apreaciate thank you !!
p.icon_set is undefined, because GAME_MOB is /mob/GAME_MOB, and p is /mob. you tried to cast usr as a mob/GAME_MOB/PLAYER, but it isn't actually one of those.

Your runtime error shows this:

src: Carcanox32 (/mob)

To fix this, set your world's default mob to PLAYER:

mob = /PLAYER

Also, I really wouldn't recommend using parent_type like this. It seems to have caused you some confusion.
thank you it work so far. can you sugest me a better way to use path, you right it confused me lol
I generally wouldn't recommend you use parent_type except in cases where you are defining types that shouldn't be used in the same way as their parent type.

/player seems like a reasonable thing to parent_type to /mob.

/enemy seems like a reasonable thing to parent_type to /mob.

The key here, is that when you are defining a parent_type, it does inherit whatever you parent it to. But in the case of a player versus an enemy, you are often making a distinction: This one will be driven by a player, and the other won't. All /mobs can be driven by a player, but sometimes your code might violate that expectation. Keeping /player and /enemy in a separate type tree helps reinforce the difference in expectation.

I use parent_type a lot for specialized types, mostly /objs. For instance, /hud_obj is a special kind of obj that I only ever expect to use as an on-screen object, and as such, it has special rules that go along with that. Parent typing it to /obj, rather than leaving it in the /obj path hierarchy, helps me to think of them as their own thing, rather than as a mutant /obj.

I also do this for /projectile, which is another specialized /obj that comes with continuous motion behaviors, and a fairly complicated initializer --again, just easier to think of themselves as their own thing, than special /objs.

I'd reserve your use of parent_type for situations where you need to conceptualize something as privileged in some way.
thanks you for you time and info!