Linux docs

[Matt]

Unfortunately these long lines in the quotes are being clipped in the forum "light theme", but they are fine in the dark theme. I should be able to fix that.

[WAS]

Annnnd you don't see the problem here? You are requiring Linux paths (or it saves in the nodes folder) so it's not really just setting a filename. It's the location of the file and name... Additionally, for some strange reason they're separate commands which could be the same command, just looking for special names or not. If special names use for image types go ahead and output.

This functionality would make sense if you were setting and output path, than -fn and -xfn

Also my output is set to D:\Terragen\Output. Same for the general settings you'd think projects would draw off of.

[WAS]

It's just not very linux-y software you'd be paying for and kinda rudimentary bash scripty you get headaches over.

[WAS]

And again, the commands docs show single-use examples. So it looks like -o and -ox are switches, you use either or. As they both are doing essentially the same thing... one just uses a special name. Which is redundant to begin with, but also confusing in docs.

[WAS]

The redundancy in the commands could easily be shortened to something like

Code Select Expand

./terragen -p /home/was/Terragen/Projects/Background_Galaxy.tgd -exit -r -f 42 -o /home/was/Terragen/out/ -fn Background_Animation.IMAGETYPE.%04d.tif
For the main render, it would simply omit ".IMAGETYPE" from the filename.

Considering extra outputs, in a commercial setting (and even me trying to play with them) should be common-place the node could be smarter, and the docs more condensed.

It could go further and not even need the IMAGETYPE unless someone wants a custom defined naming convention, and add the image type before MIME type.

[Matt]

Yes, I suppose it could. The use of -o and -ox is a legacy holdover from before render elements were supported. There was only alpha. Two filenames were needed in the UI, and each of them was overridden with its own switch.

It hasn't been changed because it would break backward compatibility. But we could replace them both with a new switch with a different name.

Regarding the Linux paths and "not seeing the problem", I'm afraid I don't understand your question.

[WAS]

Regarding the Linux paths and "not seeing the problem", I'm afraid I don't understand your question.

That's chalking up to the linux docs and redundancy. The docs give a single-case example using "-o". Than goes on to state

Code Select Expand

-o <filename>

Set the renderer's output image filename to <filename> before rendering.
...


-ox <filename>

Set the renderer's "extra output images" filename to <filename> before rendering.

...

"to <filename>"

It makes it seem like this is a either or switch to use one flag at a time, really. And then no example of usage is given so it's left to the users interpretation.

I'd never assume I'd have to define the whole path and filename twice, for basically the same thing. Lmao I'd assume things be smarter.

And as far as legacy support, that's entirely understandable. But perhaps just release a "legacy" renderer node for those systems. Buuuut being based off peoples managers or even custom scripts; it isn't a end-of-the-world scenario and they should all immediately know what to change in their custom systems.

[Matt]

Maintaining multiple executables for legacy syntax is a bit drastic, but I'll take the syntax change requests into consideration.

[WAS]

Maintaining multiple executables for legacy syntax is a bit drastic, but I'll take the syntax change requests into consideration.

Yeah, that's why I noted that the people handling these nodes will know what to change when reviewing change logs, since it's almost certain they manually set up either a manager or script, so probably not even needed [legacy thingy]. People could roll out the changes easily enough.

But I do think the arguments could be better handled. If anything the docs more clear. The impression I got, over re-reading it over a dozen times, it didn't dawn on me that you'd want the full path and name twice as two separate flags.  Maybe I'm dumb, or maybe I'm used to other linux docs being more explicit.

[WAS]

It'd also be cool if TG was just installable and had a manual. So query it would be as simple as "man terragen". Especially helpful when remote, saving from opening browsers or carying a copy of the docs, or CDing dirs to get to docs, and back, or multiple screens/sessions, etc.

Maybe a "./terragen docs" command and just tail the docs, for a addition in a pinch.

Since this intended for automated environments and thus likely SSH rather than a console within a desktop.