The problem only occurs when someone selects “new image, new layer” in Gmic_qt (which i obviously never do).
Somehow it messes up the script. Probably the list, there’s an image missing, probably wrongly renamed because the order becomes different.
You can still find out where it went wrong by outputting all the variables, images and stored arrays step by step for examination. I forget how G’MIC behaves when you are trying to access an image by name that does not exist. Probably an error. I suppose you can error-proof your image retrieval by using an if-error-do-this logic for now, or temporarily put a notice in the filter GUI text.
Yes i know, i’m using d0 around the bug right now.
It looks like fx_tree is eating an image [BG]?
Here’s what i see :
When using “in place” :
- create an image named BG
- repeat 2 times fx_tree : outputs tree to image 0 each time (why? no idea but i got used to it, that’s how fx_tree works)
At this point BG still exists - name image 0 tree1
- name image 1 tree2
When using “new layer, etc”
- create an image named BG
- repeat 2 times fx_tree : outputs to image 0 but BG disappears the first time, then tree2 replaces tree 1
- name image 0 tree1
- name image 1 tree2 <= fails because there is only image 0 and outputs error
This is knida tricky since i fear fixing behaviour 2 will make bahviour 1 bug instead.
Mods i’ve made show the trees are created in a different position instead of 0,1.
Gotta find the way to create them surely at the same position each time.
Will eventually get it one day 
Just check the code for fx_tree :
fx_tree :
_fx_tree. $* mv. 0 <= moves to 0 heh
if 0$_output_mode k[0] fi <= no idea what this is
Now i know why it is moved to postition 0.
I’ll modify my code to use _fx_tree directly instead and see what happens. Probably more bugs 
It is beneficial to examine filters, commands and macros you are depending on more closely. I never use the GUI wrapper because it is usually meant to give instructions to the GUI preview only. I only use the parts that are relevant to my own command or filter to optimize my own filter and eliminate bugs related to dependencies. Also FYI, if you are not aware, fx_* filters tend to be ancient, so maybe you can find better ways of doing the same thing using modern G’MIC; we will thank you for your contribution. 
Obviously, if this mode is selected, do this (could be GUI-related, or specific to this command—I forget what it is for and have not checked).
Not if you account for not moving [-1] to [0].
Variable $_output_mode is a predefined variable (in the G’MIC-Qt plug-in only), that tells about the value of the “Output Mode” parameter :
$_output_mode==0: In-place.$_output_mode==1: New layer(s).$_output_mode==2: New active layer.$_output_mode==3: New image.
The 0 is added (0$_output_mode) so that when this variable does not exist (e.g. the command is not run from G’MIC-Qt), the test evalues to 0.
2 Likes
Well I just started all this by copying the fx_tree command from gmic_qt. I don’t understand one bit of it’s code so I can’t build on parts of it. That’s my problem.
Yes I know. What I don’t know is the difference between ancient and modern g’mic. I’m still a newcomer, y’know? I used fx_tree because it was there. At some point, I mean at the very end of this script, I will create other trees ( If I can) and put that in a menu, as well as standalone.
But this’ll happen only if I live long enoughto finish this lol. It takes me so much time I wonder how I can keep going. Yesterday I wrote a basic grass generator. I already have some troubles with it, and it made me realize I have to change a lot of things in Underwood’s to make it work with it. Oh well.
@David_Tschumperle thanks that’s very nice to know. Will probably have to use this.
If it came out the wrong way, I apologize. Trying to give you hints, encouragement and confidence to tackle your awesome filter, is all. 
Thanks, it’ sokay, i understand, i’m just explaining the general state of things on my side.
Thanks for support
At least, if people find bugs in my… “filters”, i’m happy since it means that someone is using them. Or at least they’re testing them lol?
Anyway, it seems i fixed it (“new image” is selected below):
AH nvm, there’s still a bug.
No wait!? I used to delete the starting image at the beginning, but it seems to work if i choose “new image or layer” as output, and still delete the starting image. @David_Tschumperle Is that ok?
3 Likes
You throw exceptions: One Association at a Time.
EDIT:
Since an image can belong to at most, one collection at a time, one must be careful with the selections that adorn name. Here is a favorite boo-boo of mine:
=> Fred
b[Alice] 6
The first command puts all images on the list in the collection named Fred. Since I didn’t provide a selection, all images are enrolled in Fred. Blurring all members of collection Alice throws an exception, since the previous command removed all members from Alice, which ceased to exist as a collection.
The input command interprets indices in its selector as target locations for placing new images.
- Positive indices place incoming images before the target image. Example:
input[4]8,8,1,3,[255,120,0]` places an orange image before the fifth image in the list; G’MIC throws an exception if there is no image on the list with that index. - Negative indices place incoming images after the target image. Example:
input[-2,-1] 8,8,1,3,[55,220,30]places two green images after the penultimate and last images on the list, throwing exceptions if these targets do not exist. Observe that wheninputselectors contain multiple indices, then as many copies of the incoming image as needed are placed before, or after, the targets, depending on their signs. - Named collections cited within
-inputselectors provide positive index targets for each image in the collection. This provides the means of inputting an image anywhere on the list. For example:
foo:
yel:=[255,240,0]
grn:=[20,200,60]
purp:=[127,0,255]
16,16,1,3,[$grn]
[-1]x4
-name[-2,-1] Alice
-fill[Alice] [$purp]
-input[Alice] 16,16,1,3,[$yel]'
(a.) places the penultimate and last images on the list in a collection named Alice, (b.) changes the colors of the members of Alice from green to purple, and (c.) inputs and multiplexes a yellow image, copies of which are placed before all images in the Alice collection. This gives rise to a seven item image list with three green [0-2], a yellow[3], a purple [4], a yellow [5], and a final purple [6] sequence.
If you want to have a “peg” image to serve as a target for all subsequent incoming images, name the peg image, thereby putting it in a collection of one, then cite the collection name in the selector of all subsequent input images.
bar:
16,16,1,3,0
[-1]x5
=>.. target
i[target] 16,16,1,3,[255,0,0]
i[target] 16,16,1,3,[0,255,0]
i[target] 16,16,1,3,[0,0,255]
places a red, green, then blue image before the penultimate image in the list (which are otherwise black).
Have fun!
2 Likes
The thing is, the image was not just remapped to another collection, but it was disappearing completely. Obliterated. So there was something else. (Fixed now). (I hope so).
That’s very cool! There are so many useful features in G’mic.
Now i’m wondering if there is a possibility to have the same behaviour with any command? I don’t know, by maybe adding @N (or anything else) to a +command decoration so that the new image is placed at position N ? I know there is a move command (but that shortcut would make code shorter) but i’m just throwing ideas in the air anyway 
Who knows… maybe it’s already possible?
sp , # BTW is there a way to use the "xN" shortcut on sample?
[0]x5
+blur[-1]@2 5 # Goes to position 2
+blur[-1]@0 10 # Goes to 0
Sure, you’d have to remember that the list grows each time you use it.
Okay, i’m not gonna think about this too much, i don’t think anyone would be interested haha. (But i’ll post it anyway)
I find that
+command[img] args mv. pos
is already short enough not to be tempted to add another weird syntax directly in the scripting language to make something similar.
I’ve already got the impression that the G’MIC language is hard enough to learn as it is!
Sorry about that. I’ll remember to forget my ideas next time xD
On another subject, how can i modify my filter for 3.3.5? It still doesn’t work when i select anything other than “in place” , but it works fine for 3.3.6pre.
No, don’t say that, any idea is good to hear.
But I’ve heard a lot about G’MIC being a relatively complicated language to learn, and I’d be more in favor of simplifying the syntax (if it doesn’t lose flexibility), rather than making it more complex.
Sio, If you think there are any really useless features in the language, don’t hesitate to tell me
It’s not possible yet, but I think I’ll keep updating the filters of the 3.3.5 version as long as 3.3.6 is not yet released. I will look at this this afternoon.
I wonder how anyone could tell you this? What is useless for someone may be essential for someone else.
I’d just say that maybe there are obscure features or commands that may be overlooked ( at least by me, i probably fail to see how they work or what i can do with them. Or maybe i just don’t need them atm).
Thanks. Maybe i should stay with the official release too to avoid this.
1 Like
I second @David_Tschumperle. No matter how lame it may seem, ask the question or make the proposal or share the observation.
Laboring in Tutorial Land, as I do, I find it paradoxical that I have forgotten how complicated a language G’MIC is to learn — I’ve become too familiar with too many aspects to appreciate how strange these may appear to newcomers. That’s why questions, suggestions and observations — no matter how naïve they may seem — are really important to someone trying to reconstruct how people go about learning G’MIC. What interior models about the language are they constructing to aid their own understanding? Questions newcomers may pose, as well as suggestions and comments, hint at what those interior models may be. I must confess, that I spend an inordinate amount of time trying to grasp the nature of peoples’ interior models, because that understanding guides how best to write tutorials. So ask away (just leave out the bit about nails. My curiosity has its limits).
1 Like
Believe it or not, usually (99.9% of the time ) i’m not the one to ask questions. Except here i guess!
I suppose it depends on the user’s knowledge of other languages. If G’mic is the first one learned, it’ll probably appear difficult but not strange. But after a lifetime of something else, maybe it’ll seem a bit strange. Myself, i don’t think about this too much. I’d just think : Oh, so that’s how you do this with g’mic…
And as usual, something else:
Has anyone tried to do grass in G’mic? Should i try this in 3d (is it even possible?) :
These take 8-10s to render so it’s kinda slow 
But if i render less blades, it looks ugly and empty. Here it was even duplicated.
Yes, but if there was for instance three different ways of doing the same basic stuff. I would suspect that there’s two too many
That’s the point, version 3.3.5 is actually the current official release!
You couls use eval for this and speed it up massively.