UltraEdit uses a path relative to current working directory. The current working directory is first defined by the "Start In" option of the UltraEdit shortcut, if UltraEdit is started with the shortcut (*.lnk). (In your case it is set to the UltraEdit installation directory.)
There are also 2 options in the general configuration page at section File Handling Items which specify the handling of the current working directory during editing files.
Use default directory from shortcut on initial file open
Use active file directory for file open dialog default
So if you have activated the first of this two options and you have created a shortcut to uedit32.exe with the project directory as "Start In" directory, you can use ctags with relative paths right now.
However the paths in the tag files are actually relative to the directory of the tag file, which could be identical to the project directory, but must not be identical.
So I would suggest, you write a feature request e-mail to IDM and ask for support of UltraEdit/UEStudio for relative paths in tag files. Add my name to the feature request, because I now would like it, too. (I have not known til now, that relative paths are supported by ctags. And while testing it, I saw, that a tag file with relative paths is really better when UltraEdit is forced to open it's dialog for manually choosing the right symbol because the current symbol is defined more than once).
I think, it would not be really difficult for the developers of IDM to implement it, because nothing must be changed on the user interface of UltraEdit/UEStudio. They only have to check, if the file name in the tag file is with an absolute path (second char is a : or the first 2 characters are \\) or not. If not, the path is relative to the directory of the tag file, which UltraEdit/UEStudio already knows and so the correct absolute path can be easily created, indepent of the current working directory.