Why can't you write programs like this? Do you understand?

Because there must be enough source features to create the plane from (least 3).
PNT1[1..12] is one input feature. Split it up: PNT1[1], PNT1[2], PNT1[3..PNT1.NUMHITS]

I don't think it worked

It will be painful, but try 

CONSTR/PLANE,BF,PNT1[1], PNT1[2], PNT1[3], PNT1[4], PNT1[5], PNT1[6], PNT1[7], PNT1[8], PNT1[9],PNT1[10], PNT1[11], PNT1[12]

To see if it will even work at all.

Brother, of course that's possible

What if you did this? Sorry I keep asking you to test things, I don't have a way to test this.

PNT1[PNT1[1]..PNT1[12]]

Cool, very nice

Brother, I must give you a thumbs up

 Neil Challinor or Don Ruggieri 

Was there a change to how loops work in 2024.1? In Henniger's example, he is using 2023.2 and can construct the plane like this

CONSTR/PLANE,BF,PNT1[1..V_COUNT],,

But for yunyan, he had to do it like this in 2024.1, as the other methods suggested to him by users here did not work. He also tested it in his own 2017, and the previous method worked, you can see screenshots above.

CONSTR/PLANE,BF,PNT1[PNT1[1]..PNT1[V_COUNT]],,

Are we doing something wrong? Or is this the new way?

Focused on yonyan.tang's original syntax -

PLN1 =FEAT/PLANE,CARTESIAN,TRIANGLE,NO,LEAST_SQR
THEO/<0,0,0>,<0,0,1>
ACTL/<0,0,0>,<0,0,1>
CONSTR/PLANE,BF,PNT1[1..24],,
OUTLIER_REMOVAL/OFF,3
FILTER/OFF,WAVELENGTH=0

I can only say at the moment that this seemed to be fine from 2016 through 2023.2.  Starting with 2024.1 the function seems to work, no errors, but the line is red in the edit window.    I'll see if I can find the reason for this, but Neil Challinor might have an easier time with that.  I do know that a lot of work was done to improve this type of feature handling in the recent versions but not sure how it related to existing functionalities

When you tried that in 2024.1 does it actually change the theoretical and actual value? His stayed at 0,0,0. I imagine it did not as your example using his syntax is also 0,0,0

you are correct, it does not change, evidence that it does not actually work.  We'll get more information on this

Well, I revisited this today, on a CMM, on the front of the part (ZX plane) and it does seem to work quite well.  We will try to learn why it shows in red but these tests look good -

I had one of the developers check and the CONSTR/PLANE,BF,PNT1{1..24],, syntax does work correctly, even though it is red in the edit window.  The syntax is being incorrectly flagged as invalid as a side effect of another change we made recently.  This will be corrected for the next release (2025.1) and considered for service pack inclusion if possible.

I had one of the developers check and the CONSTR/PLANE,BF,PNT1{1..24],, syntax does work correctly, even though it is red in the edit window.  The syntax is being incorrectly flagged as invalid as a side effect of another change we made recently.  This will be corrected for the next release (2025.1) and considered for service pack inclusion if possible.

If it is not correctly calculating the X, Y Z, and vector of the feature when typing this in, and it puts the text in red, it is not actually working is it? Is the temporary method until further notice the one I posted above?

As Don Ruggieri said in his most recent comment, and as I also stated, this is working correctly.  We just have a bug that incorrectly turns the edit window text red.  You can see from Don's screenshot that PLN1 contains all the hits.  Another way to verify this is to open the status window and then put the cursor on the feature in the edit window - the status window will display a summary, listing the number of points being used for that feature.

When the user above did his construction as shown in the original post, the THEO and ACTL XYZ values are still <0, 0, 0> They do not change to reflect this working correctly. 

When he did it using the method I suggested, his THEO and ACTL values displayed correctly. <45.077, 102.231, 0>

I am familiar with F9'ing the feature and seeing the features listed in the construction, but I just wanted to make sure that this is actually calculating. Don also stated that the values did not change, and could be evidence that is not actually working.

I just wanted to verify with you that the values are actually calculating despite the text flagging red and values staying 0, 0, 0 that this is actually working. Is it calculating the XYZ in the background and not being displayed properly? If so, that's fine. Just something we will have to be careful with, as seeing 0, 0, 0 could be worrisome.

Edit: I did not see Don's edit to his comment, sorry Neil. I'll try this when I can. I do not know why the other user's values did not change. Do you see any reason for why his values did not change until he tried a different method? I don't see any typos.

From what I can make out, the THEO values should be zero because the points are in a radial pattern around the alignment origin.  In Don's screenshot, you can see that we replicated this (we did it on a YMINUS plane rather than ZPLUS but the principle is the same).  Don ran our program on his machine and confirmed that the MEAS values updated with each run...

I can confirm that the points in the loop are calculated correctly. To check this, I inserted a layer evaluation into the loop. In the protocol, the theoretical values ​​are correct. I also don't get any red color in the constructed plane in 2024.2 (release ) - Build #161.

Hope this information will help.