//You can use these defines to get the typepath of the currently running proc/verb (yes procs + verbs are objects)
to_chat(world, THIS_PROC_TYPE_STR) //You can only output the string versions
Will print: "/mob/living/carbon/human/death" (you can optionally embed it in a string with () (eg: the _WITH_ARGS defines) to make it look nicer)
#define THIS_PROC_TYPE .....
#define THIS_PROC_TYPE_STR "[THIS_PROC_TYPE]" //Because you can only obtain a string of THIS_PROC_TYPE using "", and it's nice to just +/+= strings
#define THIS_PROC_TYPE_STR_WITH_ARGS "[THIS_PROC_TYPE]([args.Join(",")])"
#define THIS_PROC_TYPE_WEIRD ...... //This one is WEIRD, in some cases (When used in certain defines? (eg: ASSERT)) THIS_PROC_TYPE will fail to work, but THIS_PROC_TYPE_WEIRD will work instead
#define THIS_PROC_TYPE_WEIRD_STR "[THIS_PROC_TYPE_WEIRD]" //Included for completeness
#define THIS_PROC_TYPE_WEIRD_STR_WITH_ARGS "[THIS_PROC_TYPE_WEIRD]([args.Join(",")])" //Ditto
The above is my "weaponised" form of this strange oddity, that sort of allows you to use it without going insane. The real oddity here however is the actual dots themselves.
I'll preface this by apologising, this will get quite ramble-y, it's essentially me just doing a mental dump of all I know about the topic, sorry!
I'm sure people have encountered this before, but there's a dot variable (.) available in every proc and verb that is automatically returned by the proc/verb if no other value is returned, you can even assign to it if you want:
. = A + B
world << add(5, 2) //this is 7, as you'd expect
However, here's where it gets interesting there's not JUST a single dot.
Now, some of my memory on this is fuzzy (we actually discovered this 5 months ago but I forgot to make an issue/bug/help thread) so some of this might be slightly wrong, I do have notes at home though so I can correct this in a few hours:
If you do two dots, '..' you get a compiler error.
If you do three dots, '...' it compiles, but you get a runtime error when attempting to output it (god knows what it is).
4 dots is also a compiler error, I believe.
Everything after 5/6 dots is just errors.
Now 5 dots, 5 dots is actually really cool behavior.
If you were in a proc, and you did:
You'd be greeted by '/atom', src's type here.
But if you instead did:
You'd get '/atom/proc/stupid_name_to_illustrate_a_point', you'd actually get the proc's type.
This is actually understandable, since procs and verbs are objects, but I don't believe their actual types are available to use in code in any other way (besides hand writing them, eg for call()()), yet you can obtain something like a typepath (I've not done much with it besides put it in a string) using this method.
Except it's weird. As my excerpt above says, you can't obtain a string version of this 'procpath' any other way except for using string embedding ("[something_to_embed]"), something like ..... + "" doesn't work, and throws either a runtime or a compiler error, I can't remember at the moment.
If you don't put it in a string, you can't output it, or you'll get a runtime too.
There are also situations (I've had it occur in defines, mostly) where 5 dots doesn't return the 'procpath' and instead throws an error.
In these situations, if you actually do 6 dots instead of 5, it magically starts working again.
But what if you use 6 dots all the time? It throws an error outside of these weird contexts!
There's a lot of bizarre code here, if I had to rationalise the 5 dots I'd say it's the dot variable (henceforth: DOT) AND the dot operator mixed, to form DOT.DOT.DOT which I *guess* makes sense, though that doesn't explain why it breaks in other contexts, and why 6 dots takes over it's 'role' in those contexts (6 dots would be DOT.DOT.DOT. following that logic, which shouldn't work?)
Really this post is a cry for help! I'm hoping lummox will be able to shed some light, because this is baffling/really interesting, but I'm also wondering if others with 'extensive' knowledge of DM (Ter, Kaichao, etc.) have encountered it before.
tl;dr what on earth is the compiler doing here.