On 5/25/21 4:40 AM, jr wrote:
> this looks v promising.  am  a little confused by the sample output posted,
> expected, for example, the four vector types to have (somewhat) related ids.
> 

This is partly because internally the vector types are:

UV_ID_TOKEN, VECTOR_ID_TOKEN, VECTOR_4D_ID_TOKEN and COLOUR_ID_TOKEN.

The token enums are also sometimes also ordered into sections - 
internally called catagories. The VECTOR_ID_TOKEN is in a vector 
category grouping while the others are not for other reasons of parsing 
code I guess. The COLOUR_ID_TOKEN is exempt from the color category too(1).

I think it's because there is, for example, color/colour keywords and so 
to color IDs. I don't think there is a 'vector' keyword, so vector ids 
can be lumped with other generic vector stuff like vcross.

I'm not completely sure of all of it, there isn't a uv keyword, but 
maybe because we have uv_vectors? I don't know.

>> ...
>> In some oddness, there is a MACRO_ID_TOKEN, but it's impossible to
>> evaluate macro names because once they exist the parser attempts to run
>> them. I don't see a way to work around it - excepting maybe via some
>> very messy methods.
...
> testing via 'defined(macroname)'?  (not tried it with macroname as string, but
> maybe Parse_String could help then).

I found a solution using the new to v3.8 global dictionary. You have to 
code macros with the 'global.' prefix...

Supposing I have a macro wrapping id_type():

#macro Mcr_id_type(_id)
     id_type(_id)
#end

so I can create IDs on the fly as in:

#debug concat("float id = ",str(Mcr_id_type(1.2*(1/3)),4,1),"\n")

I can then grab the Mcr_id_type macro's id type number with:

#debug concat("macro = ",str(id_type(global.Mcr_id_type),4,1),"\n")

Bill P.

Post a reply to this message