@DIR 45
@WRAP 1
@STEP

@X => 1 and @y => 63 which is what I would expect from a 45 degree step from 0,0. :man_shrugging:

For 45 degree movements, yes.

I’m for this change. I wonder what @tehn and others think.

i’m for this change-- is there a key combo for the old behavior that would work? i think shift-enter is taken?

Yes, shift enter is insert, shifting lower values down.

I wonder if it needs a dedicated keystroke seeing as you can <Enter>, <Down Arrow>.

edit: Alt-enter and Ctrl-enter are available

agreed, let’s just skip the dedicated keystroke. it seemed good for rapid bulk entry of a sequence, but i doubt the down arrow introduces much friction. we can always revisit this

3 Likes

As promised, here is 2.1.0-rc2:

teletype-2.1.0-rc2.zip (484.8 KB)

Changes:

  • Added EVERY, SKIP, OTHER, and SYNC
  • SHIFT-2 in tracker mode will now toggle @SHOW
  • Tracker data entry
    • Enter no longer moves selected cell down
    • [ and ] now behave the same in entry and nav mode, wrapping instead of bumping
    • [ and ] no longer show values exceeding INT16_MAX or INT16_MIN (bugfix)
5 Likes

Two questions / thoughts regarding the new turtle OP:

@SPEED - get/set speed in 1/100 of a cell per second, default 100

It is 1/100 of a cell per step, isn’t it? I think I prefer it over being time correlated.


To make the the movement more predictable with @DIR @SPEED @STEP I use a line

@X @X; @Y @Y

to round the internal fractional position to its actual grid position on every step. How about an operator that does this - like @FIX (or @SIT since it is a turtle)?

It also practically rounds the 360 degrees to the 8 possible directions in a two dimensional grid and you don’t have to calculate direction changes to 45 degree steps anymore which saves even more resources and makes the scripts less complex.

Playing with higher uneven speed values is much fun when it is paired with predictability if you want that.

Life is a bit better with turtles!

:star_struck:

1 Like

Yeah, you’re right. 1/100 of a cell per step.

I guess you could look at it that way, but I still wonder if you you would prefer @MOVE 1 1 for a predictable 135 degree step. I think that would also eliminate complexity.

I’m glad that you’re finding value in all these new features!

I guess you could look at it that way, but I still wonder if you you would prefer @MOVE 1 1 for a predictable 135 degree step. I think that would also eliminate complexity.

Hm, but how would I do something like SCRIPT 1 moving the turtle forwards and SCRIPT 2 changing the direction then? It would need two variables changing between -1, 0, 1 in a meaningful manor. Plus scaling them when you’d like speed changes.

True, but it would be completely predictable. I’m not sure that @DIR 45; @STEP ever will be due to the cheapo sin() implementation plus rounding errors.

edit: Plus, you have a logical selection for variables in X and Y.

True, but it would be completely predictable. I’m not sure that @DIR 45; @STEP ever will be due to the cheapo sin() implementation plus rounding errors.

Okay, I stay with @X @X; @Y @Y then - don’t know much about mathematic completenesses but it seems at least pretty predictable. Maybe I am just feeling uncomfortable with things not being where they seem to be…

edit: Plus, you have a logical selection for variables in X and Y.

I don’t understand this?

Yeah, if you align yourself with the center of the cell you’ll get predictable results.

As to X and Y variables being a logical selection, @MOVE takes two offsets, an X offset and a Y offset. It would be easier to think about

@MOVE X Y

than

@MOVE A B

Blockquote

As to X and Y variables being a logical selection, @MOVE takes two offsets, an X offset and a Y offset. It would be easier to think about

@MOVE X Y
than

@MOVE A B

Hm, I am afraid I can’t even formulate a meaningful question to follow you…nevermind…

:jack_o_lantern:


EDIT: something has happened to the automatic quotation function of the forum - or ist just me?
EDIT2: Obviously it is just me, hm…does not work anymore here.

Not just you, I’ve been having trouble using it all morning.

Okay, I try it anyway: Why is selecting X as variable more logical than A?

If you’re on a graph or any 2D Cartesian space, the 2 axes are traditionally referred to as the X-axis and the Y-axis.

1 Like

Yes. I don’t get the connection to the suggestion I made, resp. the aim to calculate direction changes with @MOVE in distinction to using @DIR + @STEP. Why does it make a difference how the variable is called? Also nobody spoke of A’s and B’s here. What did I miss?

:exploding_head:

If I wrote a script that said

@MOVE FOO BAR

It wouldn’t be as obvious when reading the script as

@MOVE X Y

I guess, to be clearer, it wouldn’t be as obvious when manipulating those variables, i.e.: FOO/BAR and X/Y.

It doesn’t make a difference in execution. It makes a difference to anyone trying to read and understand the code, though.

I was just mentioning that it is fortuitous that of the few general-purpose variables that are available on the teletype, two of them are X and Y. That is all.

Edit: stated differently, it is fortuitous that there are variables with names that happen to be descriptive within the context of manipulating the turtle’s X and Y position.

Edit2: I find it ironic that there is confusion about clarity :laughing:

I find it ironic that there is confusion about clarity :laughing:

Maybe the irony is that there is confusion about confusion - my original confusion was if you have a script that makes the turtle run around diagonally in its corral like this (faster trigger in 1, slower trigger in 2):

1
@STEP; CV 1 N @

2
@DIR ADD MUL RAND 3 90 45

or:

1
@STEP; CV 1 N @; @DIR O

How would you do this with @MOVE X B ?

Sounds like you want something akin to this:

I: X 1; Y 1
1: @MOVE X Y; CV 1 N @
2: Z RAND 3
   IF EQ Z 0: X 1; Y 1
   IF EQ Z 1: X -1; Y 1
   IF EQ Z 2: X -1; Y -1
   IF EQ Z 3: X 1; Y -1

Which rotates to a random 45-degree-from-cardinal offset. It would be trivial to limit this to eliminate 180 degree turns.

My observation was that:

The script that I wrote above is more predictable.

The script that you wrote above does not guarantee that the cell will change each time script 1 is called unless you ensure that @SPEED is about 141 and you `@X @X; @Y @Y’ after every step.

Therefore, the script that I wrote above is also less complex than yours. If you truly intend to move 1 cell at a time in a 45 degree offset to a cardinal direction, I think it is the better script.

Yes, it’s longer and more explicit, but I never understood you to be someone who appreciates terse complexity. Perhaps I was mistaken?

Also, can you see how the script is easier to understand than if I had used the general-purpose variables B and T instead of X and Y?


Wouldn’t that be poetic justice?

Hm, maybe it is about how we are approaching this. I see the turtle as a…err…turtle that is walking around in a corral. So setting a direction and stepping forward feels more consistent to my perception of what is happening than changing coordinates of a point in a grid. That feels like a chopped process of going one step diagonally by going one step left and then one step forward. And how about using all 8 directions or changing speed. I think the If-Then construction is too static or robotic - cold mathematics. To me the beauty of @SPEED @DIR @STEP is its true-to-life way. But I also think of little electrons running back and forth through wires and squeezing themselves through resistors…

I played around with it a lot today and with @X @X; @Y @Y after every step it moves pretty regularly, even with @SPEED 100 which makes it compatible to all 8 directions. With higher speed settings I still got consistent patterns over the whole grid. That’s where I came from when the position rounding OP came to my mind.

I also ran into another problem and did not find a solution / OP for it: When you run different trigger outputs from one script how can you mute single outputs? Also I did run the turtle from the M script and wanted to periodically start and stop movement but M.ACT always started again very off beat. How about TR.MUTE to mute / unmute a trigger while the script keeps going?

1 Like