Hi,

In ROP Geometry Output, the output files should be pad zero (like all output files ) but I can't seem to make it work.

C:/temp/filename.`padzero(4,@wedgeindex)`.bgeo.sc

isn't working, it just gives me non-padded files on disk.

I recall this issue coming up in 17.5 beta, but no amount of Googling or searching the docs for ‘pad’ or ‘leading’ gives me the answer

Is this a bug that padzero() isn't working? Or am I missing something that the docs aren't coughing up?

18.5.351 Py 3 Win 10

Cheers,

Peter B

Hah hah found it, of all places, in the FindFiles demo file Sticky Note.

@wedgeindex:4

I could not for the life of me find that in the docs…

Ah but it doesn't work either c:/some/file.`@wedgeindex:4`.bgeo.sc outputs non-padded digits

Are you able to attach an example file? It seems to be working as expected for me in both cases. Both $HIP/geo/$HIPNAME.$OS.`padzero(4, @wedgeindex)`.$F4.bgeo.sc and $HIP/geo/$HIPNAME.$OS.`@wedgeindex:4`.$F4.bgeo.sc produce file paths 4 digits in the frame and wedge index component.

OK, I'll send it to Support and let them know to send it to you, it's a prod file

I've sent the file, but it appears to be a bug with the PDG Service, if I turn that off and use just regular local scheduler, I get padded zero files.

Since PDG service is about 1 million* times faster than not using it, I will live without padded filenames until it's fixed

Cheers,

Peter B

*give or take

Actually, this might be a red herring. After restarting Houdini I get padded zeros with the Service.

However, it looks like I have to restart Houdini (or maybe just the Service) when I change expressions on (at minimum) ROP Geometry TOPs.

I'm getting a fairly persistent issue across the board where I change an expression like: c:/some/file/filename.`@someattrib`.bgeo.sc to c:/some/file/filename.`@somenewattrib`.bgeo.sc but when I delete the disk files, and dirty the node, and then recook, it still writes out the “someattrib” version, not the new name.

So the padzero may have been a symptom of this bug.

If I can reproduce I will, but I'm curious if the Service actually tries to hang on to the HIP file and not reload it and maybe it's missing a ‘dirty’ of the HIP file itself? I'm guessing wildly of course…

Cheers,
Pete rB

Hi Peter,

You are correct that this is a bug with the service not reloading the HIP file after its been changed. We will get a fix in for this.

Oh cool, glad it's fixable! Also glad I'm not going crazy with the parms not updating