RealFlow Official Forum

Hi,
i'm in the process of setting up a central script repository for our workgroup. Scripts live in a folder on the fileserver and from there we add them to a user toolbar through the 'Add Script From File' dialoge. This works fine until we want to do changes to the script files. They don't seem to be re-read from the central location, there seems to be a local copy. And not only doesn't it re-read, it even tries to overwrite the centralized script with the local copy when opening the 'Organize Commands' dialoge. Is this the intended behaviour? Any suggestions how to deal with it?

Kind Regards,
Moritz.

Hi Moritz,

I believe that is the expected behaviour.
It won´t update within your open RealFlow sessions unless you do a New or Reload, or even reopen RealFlow.
We will review this process to see if we can improve it somehow in the future.

Cheers,

g-)

Hi,
and thank you for your answer. What you describe sounds perfectly fine. If there's a way to manually refresh e.g. by restarting Realflow, that'd be perfect. The problem i see is that it doesn't refresh even after restarting Realflow. It shows what appears to me as a local copy of the script, actually 'remembering' an old version of the script. So in order to refresh i have to delete it from the Realflow interface and reload it. Even worse, when i do changes to the central script, the local copy tries to overwrite the one in the central repository when opening the 'Organize Commands' dialoge.

Kind Regards,
Moritz.

Hi Moritz,

What OS are you using?
Are you also trying to share the commandsOrganizer.dat?

g-)

Hi there.
And thanks again for your help. Now sharing "commandsOrganizer.dat" as well and it seems to work as expected.

Kind Regards,
Moritz

Hi Moritz,

Glad to hear that is working.

g-)

This looks like a good place to post my question about having a shop wide commandsOrganizer.dat file.
Is there an environment variable to set where to look for the commandsOrganizer.dat so that it doesn't default to the one located in the user/home/ directory?
This seems to be the easiest way to add custom tools without needing to put scripts in the software install scripts path. (Which isn't an option in our pipeline.)
I found a few environment variables...but none change this path in the prefs. Any thoughts would be greatly appreciated.
Thanks so much.

Hey Ben,

I don't remember if there is a variable for that. Let us check. Meanwhile, keep in mind you can place the Organizer.dat in any place you want in the network, and then changing the path where you have the Organizer.dat in the preferences for each RealFlow you have installed.

luisM.

This would do the trick, but how do I change the path for the commandOrganizer.dat file on a system wide install?
Or how do I 'share' this file system wide in a way that doesn't involve copying it to everyone's home directory.

Currently it looks in the net/homes/user directory for this...Which is why we are looking for a global variable to set this. Our system setup is [realflowSoftwareInstall] [customScripts(Must be separate)] > user runs realflow command in shell which sources and sets env variables. We need to set it to source the commandOrganizer.dat file from the [customScripts] part of our file system by default without any input from a first time user.
Any help would be hugely appreciated.
Thanks
~Ben

I wanted to post to follow up to let you know that we have finally gotten around to setting up things with the new commands organizer environment variable.
This works great! Thanks so much for putting that in there.
A bit of a follow up, was I imagining it, or was there talk about moving the commandsOrganizer.dat to a different file format...maybe a non-binary one.
It would be great to have it editable and also not compiled for specific versions whenever possible.
We had a bit of hair pulling when we tried to use a commandsOrganizer.dat file that I had made in 2013.0.1.132 in our 2013.1.2.152 install.
Would be great to not have to re-create this file whenever we update to one of you awesome new versions.
But that said, thanks again for getting this rolling.
~Ben