ID:135380
 
I wracked my brain over this for quite a while before Malver poked me, and then it all made sense. Anyhow, to get to the point. I've been messing with call() and hascall(), and I couldn't get it to work properly. The reason why, was that procedures I was trying to call had _'s in their name and call()/hascall() expects _'s to be spaces! I hope its nothing intentional, but if it isn't is there any way to change it?

As it is, it makes the reason they exist a whole of a lot more annoying as soon as you start dealing with procedures that have _'s in them. Right now I have to run through the procedure name string, and convert all _'s to spaces before doing hascall()/call(). While it seems consistent with string / verb / proc behavior, it seems completely out of place and is a huge annoyance when using call()/hascall().

Any word from above on the possibility of changing it so that call(src, "test_something")() works instead of call(src, "test something")() ? Or perhaps both, so _'s are converted internally or something.

Thanks in any case.
Here's the most recent reply to something involving call()/hascall(): ID:248976
I don't particularly like the call() syntax (not just the part you mentioned), since it isn't consistent with the rest of the language. However, I believe that the current behavior is intentional. That variant of call()/hascall() references procs/verbs by name, which is how they would be "expanded" on the client command line. You can confirm this by calling a verb that has "set name = something"; I may be mistaken here.

I know this really doesn't help much but that's what I'm here for.
In response to Tom
Tom wrote:
I don't particularly like the call() syntax (not just the part you mentioned), since it isn't consistent with the rest of the language. However, I believe that the current behavior is intentional. That variant of call()/hascall() references procs/verbs by name, which is how they would be "expanded" on the client command line. You can confirm this by calling a verb that has "set name = something"; I may be mistaken here.

Nope, you are correct. It was Malver that made me aware of it, although from Tenkuu's reply I can see I should've scoured the forums first!

I know this really doesn't help much but that's what I'm here for.

Well, atleast I recieved a response :) I was half expecting it to be fairly annoying to tackle, since it seems more like a side-effect of how expansion and _ vs. ' '(spaces) work in verbs/procs.

I'll stick with the way im doing it now. It's not overly annoying, simply occured to me that it seems like such a common thing to run into when using (has)call() that it should already be doing the converting for you.

What about making call automatically convert any _ (has)call() are passed into a space? That would solve it on the users end, would be done faster than we can using DM, and you wouldn't have to mess with something deep down in the core (Im guessing here, so do correct me if im wrong)
In response to Alathon
Can you show me an example of how you are using call()/hascall()? Could you possibly use the other version of those functions (accessing procs by node-name) instead?
In response to Tom
Tom wrote:
Can you show me an example of how you are using call()/hascall()? Could you possibly use the other version of those functions (accessing procs by node-name) instead?

Sure. Here is a short sample of the code that will probably explain it. It's intended for a system that allows dynamic calling of procedures based on certain input chosen from a list that is also dynamically generated.

template
proc
set_property(property_name, player/P)
if(!property_name || !P || istype(P,/player/)) return OLC_INVALID_SET
var proc_path = "olc set [dd_replacetext(property_name,"_"," ")]"
if(!hascall(src, proc_path))
sendtxt("There is no method of declaration set for [property_name]", P)
return OLC_INVALID_VAR
. = call(src, proc_path)(P)
if(. == OLC_INVALID_VAR)
sendtxt("Procedure([proc_path]) has not been defined yet. ", P)

template/mob
proc
olc_set_name(player/P)
olc_set_desc(player/P)
olc_set_keyword(player/P)
olc_set_path(player/P)

real/proc
olc_set_hitpoints(player/P)
olc_set_base_stamina(player/P)
olc_set_willpower(player/P)
olc_set_base_will(player/P)
olc_set_base_energy(player/P)
olc_set_strength(player/P)
olc_set_agility(player/P)
olc_set_quintessence(player/P)


As you can see, the procedures branch over several children of /template. That's the only reason that accessing them by node-name would be more of an annoyance, a great annoyance in fact.