Evalling One Level At A Time

[Jason]

Hi there,

It happens all the time that I/we want to fetch information from fields one level at a time. For example, say you embed a ROP in an asset which refers to the top-level parameters for the destination picture name. It would have an expression like:

/obj/explosion_hda/ropnet1/mantra1/picture:

`chs("../explosion_picturename")`

- and the HDA parameter is something like:

/obj/explosion_hda/

/the/path/filename.$F4.exr

If we want to fetch the picture parameter and get the raw string from the HDA, i.e. still maintaining the $F4; any ideas how to do it? If you `chs("ropnet1/mantra1/picture")`, it'll fully eval out the frame number, but if you `chsraw()` it you'll end up with the expression in the picture field.

Does anyone have any tricks or ideas to "chs()" a string with evalling only one level deep?

Cheers!

Jason

PS. We do this kind of thing for 80% of our HDAs; so it'll be super useful to find a decent solution. Perhaps SESI could write an extension to evals() to eval to a certain depth? Or is there another idea or something I'm missing?

[George]

Hi Jason,

I don't think there's currently a generic way to do that elegantly. But it should be fairly easy if you're sure that the expression in mantra1/picture is always of the form `chs("...")`, to use the chsraw to read in the destination reference and then another chsraw to read in the value there... something like this horribly untested chicken scratch:

`chsraw(arg(strreplace(chsraw("ropnet1/mantra1/picture"), '"', ' '), 1))`

... but maybe you were looking for a good answer?

George.

[sibarrick]

This is not something I've every tried, are you say that by doing chsraw at the obj/explosion_hda/ path it evals right down into the rop and actually returns the expression down at the bottom level?

I guess chsop also expands the $F variable?

[Jason]

`chsraw(arg(strreplace(chsraw("ropnet1/mantra1/picture"), '"', ' '), 1))`

... but maybe you were looking for a good answer? 

Heh heh; yep. I tried this but ran into several problems:

set picturename = `chsraw("$rop/picture")`

# try and yank a reference
#
if( `strmatch("?chs(*)?",$picturename)` != 0     )
  echo "seems to be a chs() reference"

  # remove whitespace
  set newfield = `strreplace($picturename,' ','')`

  # chsraw() ignores quotation marks when fetching for unknown reasons, so use the parens
  set newfield = `strreplace($newfield,'(',' ')`
  set newfield = `strreplace($newfield,')',' ')`
  set newfield = `arg($newfield,1)`

  # BROKEN: this doesn't work for parms, only ops
  set newfield = `opfullpathfrom($newfield,$rop)`

  # sigh.
  exit
endif  

It would be nice if parms were actually treated like leaf nodes so that opfullpath and such could work at the parm level. RFE?

Just to illustrate, you would be able to do this and get an answer:

`chs("mantra1/picture/../picture")`

This is a little more awkward than I hoped.

[George]

Hmmm... as a workaround from opfullpathfrom not supporting parms could you do this in your script:

  set old_cwd = `oppwd()`
  opcf $rop
  # get the value you want with `chsraw($newfield)`
  opcf $old_cwd

Still not elegant though... I hear ya.

George.

[Jason]

Thanks George. I'll get back to this when I have a little time to get it to work reliably.

On the general idea mentioned above, is there a godd reason why parms should not be treated as leaf nodes? It seems like it could help certain types of operations - except I suppose it'd be dangerous for recursive traversals of node heirarchies if not implemented carefully.

[thekenny]

oh my.

this is painful

you can do a rindex to the last/ and strlen and all that business and then cut and past the filename.$F4.tif to something else, but it is long and ugly.

the string replace also works, you have to know filename is... the rindex method is more reliable.

just ugly

i feel your pain.

been there.

-k

[George]

On the general idea mentioned above, is there a godd reason why parms should not be treated as leaf nodes? It seems like it could help certain types of operations - except I suppose it'd be dangerous for recursive traversals of node heirarchies if not implemented carefully.

26644[/snapback]

Yeah, I'm usually guilty of wanting to unify everything The things to consider is that a node is not a parm... so you can't generally interchange them. Your example of opfullpathfrom though is a case where they can be interchanged and I tihnk it should probably be fixed for that. I'll submit a Bug

Take care,

George.

[Jason]

Your example of opfullpathfrom though is a case where they can be interchanged and I tihnk it should probably be fixed for that.  I'll submit a Bug

26648[/snapback]

Thanks!

Yeah; I can only think that many places that roll out OTLs with embedded ROPs must run into this and all come up with their own workarounds. Our workaround bypasses the chs() thing altogether by tackling the problem on the backend but it does seem like it needs to be able to be addressed gracefully in the future- in H9 perhaps.

I've also had some pain before trying to chsraw() a field and then attempting to detect whether the string returned it has a backtick in it (i.e. checking for expressions in the parm). It's amazing how awkward this can be do to in Hscript and deserves its own place on the wall in the Hall Of Hscript Insanities. Also something for SESI to keep in mind for H9!

[George]

It's amazing how awkward this can be do to in Hscript and deserves its own place on the wall in the Hall Of Hscript Insanities. Also something for SESI to keep in mind for H9! 

26649[/snapback]

Not to mention how double quotes can seemingly be randomly stripped out, or spaces truncated. Dealing with strings in hscript in general is a pain. In fact I think there's already a bug to that effect: "Strings in hscript are a pain"

George.

[TheUsualAlex]

Not to mention how double quotes can seemingly be randomly stripped out, or spaces truncated.  Dealing with strings in hscript in general is a pain.  In fact I think there's already a bug to that effect: "Strings in hscript are a pain"

George.

26653[/snapback]

hi George!

echo `system("perl -le 'print \"more perl insanity\"'")`