Report this content

Sun & Sky > Sun Position's "distance" (vector magnitude) is inconsistent: The output takes into account the sun gizmo's distance along the stalk. Changing the brightness changes the distance the sun gizmo is along the stalk, but does not affect the sun position output. When sending a 3-number vector into the input, its magnitude is ignored and does not affect the brightness. The only time the vector's magnitude is updated is when the sun gizmo itself is dragged around.

This indicates to me that internally, the sun position is a simple normalised vector. When dragging the sun gizmo it remembers the distance. Then when outputting the sun position it sets the magnitude of the normalised vector to that distance. As opposed to it being coupled to the brightness or anything.

My suggestion would be that it outputs the normalised vector, and that's it. I would also guess that would be the most common usage of the output; to always normalise it first, because the magnitude is not normally helpful (or reliable, according to these tests).

Footage of my initial testing: https://www.twitch.tv/videos/1475546189?t=1h4m53s

"Wide Calculator" name: It seems funny to me that the gadget is called "Wide Calculator" when it is literally thinner than the normal calculator. It's certainly very tall, so perhaps "Tall Calculator" would be better? Though honestly the name should be something that tells the creator what it does, which "wide" and "tall" do no help on whatsoever. 😅

Trigonometry functions accessibility: I understand the reason for this... computers like radians, there are pros to radians, etc. One big pro for degrees is that the average person knows what they are and how to use them. In fact, Dreams uses already degrees when talking about angles, likely because of that. For example, the rotation wire type you'd get from a tag uses degrees (I would think this will be the most common use case for using trig functions in a game).

This means that a creator cannot simply wire an angle generated by Dreams and wire it into a calculator to perform trig operations on it. They need to: 1) know what a radian is, 2) know that trig functions in programming languages use radians and not degrees to know they even need to know about radians (or happen to hover long enough for the popup to appear), 3) know how to convert degrees into radians, and/or 4) know how to convert radians into degrees.

I feel like that list is a pretty big burden of knowledge to even get started using these functions, even if they understand what the different functions are for and how to use them. I learned all about sin/cos/tan from school, using degrees. I would not have been able to use these sin/cos/tan functions without doing external research.

Trigonometry function tooltips: The names for these are not inconsistent. Some just say the text of the icon, which doesn't help understanding (sin, cos, tan, atan, Atan2). Some say the proper name for the function but not completely (arcsin is really "arcsine", arccos is really "arccosine"). To find their true mathematical names, the user has to hover and wait for the popup. Ideally, I'd expect the tooltips to give the full proper name to give the user the best chance of finding the right thing when they Google it ;p

Bake Emitted Tool sets the initial state of all logic: As demonstrated here... https://www.twitch.tv/videos/1475546189?t=1h46m47s

It may not be obvious why that's a problem, so let me give you an example... If we emit some zombies, their internal logic will begin running. They may change into some special mode because they get close to the player puppet which is already in the scene. They may have activated an animation to lunge at them. Now we bake, and rewind, and the zombies are still there. But they're mid-lunge, and in that special mode. But then if we move the player away to start in a different room, none of that makes any sense.

What would make sense is if the zombie was in its initial default state: standing doing nothing, waiting for the player to be in the same room, not lunging from the start of the scene. If the internal logic state was not set as the initial state at the start of the scene, that would all be resolved.

We also get some other odd behaviours for gadgets where we cannot normally set its initial state such as the selector. If we emit a selector, change it to mode C, and bake it... now it will start at mode C from the start of the scene. This could create some confusing bugs until we figure out it's starting on C instead of A. And the only way to fix it would be to completely replace the gadget because we cannot set that initial state ourselves.

And think of how this will affect things like exclusive gates, which are already hard to understand, and it can be quite easy to mess one up and it winds up starting open when you didn't intend it to be. Even nodes can have weird "stuck state," which might be caused by this byproduct of "bake emitted." And something like a timeline half-way through seems to also start from halfway through. Imagine trying to adjust the logic of the object you baked and then realising it has a stuck timeline so you can't just power it to play it because it's going to start halfway through, forever.

There are likely cases where this doesn't matter, but there are also cases where it will definitely be a problem.

On the other hand, it could lead to some weird hacky uses to set such initial state--emitting a selector purely to create a selector that starts from C for example. Which seems hacky and unintentional. (Though an actual setting for which starts as default, and opening up these hidden initial states would be great as an official addition.) So some sort of option may be the best way of introducing this, so that people who like these hacky things or find some special use for this quirk can still do so... Not sure.

My old baking methods were more involved and tricky to set up, but have the benefit of not keeping all the initial state of the internal logic, so it will run completely fresh from the start of the scene. This means you can make an element that is some creation tool or other (eg. planting trees around the place) that also has internal logic that won't start in the middle of it when you start the scene. All the instructions a user of such a tool would need are: how to use the tool itself, and then they bake, and job done.

I did show a couple of workarounds on-stream for how to emit without running internal logic, then bake, then allow that logic to run only after it's been baked. https://www.twitch.tv/videos/1475546189?t=1h57m25s But both are kind of hacky, and would require the user of the logic to mess about with things unrelated to just using the built tool to create.

Apply Fleck Tool cannot apply the square fleck: https://www.twitch.tv/videos/1475546189?t=1h50m34s This is unexpected, as all other fleck types can be applied after-the-fact. This means that we cannot apply the square fleck to any existing paintings, or paintings that were converted from sculpts. Only new strokes can be square flecks. This is pretty frustrating for people who want to turn their old paintings into square-fleck paintings (eg. pixel art that was made with paint cannot be converted). Such paintings need to be created again from complete scratch if they want it to use the square fleck.

It also means if we make a square fleck stroke and then apply a different fleck to it, we cannot get back to the original square fleck.

I understand there are reasons that making the square fleck work for sculpts is a more involved process so that may or may not come in the future. But if we could apply the square fleck to just paintings that would save a lot of time and frustration for creators who want to use it.