So here's a list of functions that would be useful for my project (and also for any other project, I hope!)

https://wri.tt/43mbmsj9xj1eh7po

I've tried to write them down with the current scripting system in mind, but they probably can be improved, merged or split to make everything fit together. The priorities are also kind of arbitrary, they can of course be modified if some features depend of each other and need to be implemented in a different order.

Thanks again for putting this list together!

I am wrapping up the first item, "Put Entity". Here's a quick test where I am moving the rock and the NPC to a new location. :) I'll probably include this along with a few other small changes/fixes in a release tomorrow.

Great! This should give more freedom to manipulate anything on the map. I'll use it mainly to reorganize NPC through various locations, but that lever makes me think about many uses for puzzles with switches and moving objects :)

Yeah, I know what you mean. It's exciting thinking about the possibilities!

I've released v0.3.4.8 and posted the release notes. I managed to fit in a couple more features than planned since they were pretty straightforward. :)

Hey there - I am working on the "Lock/Unlock Player Movement" function and trying to determine the best way to implement it while taking future possibilities into consideration. I am thinking the one-way path stuff would be its own thing for limiting specific directions, so would the lock function be flexible enough if I had these 3 parameters that could be specified to be locked or unlocked?

• Walking: If locked, player can't move/strafe from the tile they are on
• Turning: If locked, player can't turn left or right (only applicable to first-person)
• Interaction: If locked, player can't interact with objects or characters at adjacent tiles

Whether this works probably depends on what some of the specific scenarios are that you have planned. I want to plan ahead when creating these functions, but then again I don't want to make a particular function too complex since I can always add additional functions if something more specific is needed. Let me know what you think! It's a difficult decision because I could make a function as specific as "lock player from turning left" all the way to a very generic "lock player from any sort of movement or interaction".

Actually, I guess either way I can always add more functions, so for now it's probably up to what scenarios you will need to handle. :)

This would probably be enough for most scenarios I can think of. Here's a typical scenario I'd use this for:

- Lock turning
- Call a dialogue
- The player moves forward a few tiles
- Call another dialogue
- Unlock walking
- Call another dialogue
- and so on.

This would be mostly meant to force the player to move along a predefined path, with stuff happening along the way, and without turning back. I could also use it with "Put Player" to move the player instantly and lock walking, with dialogues between each different location.

Anyway, you're right, there's probably no need for this function to control specific directions, these three parameters would be fine.

Okay, thanks! I've been working on the "high priority" player/camera movement functions as a group (and slowly making progress).

I discovered that I can use the smootherstep function for interpolating the camera movement which gives it a nice ease in and ease out when changing positions: https://en.wikipedia.org/wiki/Smoothstep

I think the hardest part so far has been deciding how to name and split out the functions. :) I hope to have at least a few of them available by this weekend.

That sounds great! I'm in the process of making several versions of various characters, depending on their age. So you can take your time, I still have a bunch of models to design and animate before scripting the whole family :)

Sounds good! In regards to specifying a camera position, I am trying to decide if it will work best to specify the position using the existing tile coordinate system (but allow decimals for fine tuning).

For example, (0, 0, 8) would place the camera at a height of 8 voxels above the center of tile (0,0,0), whereas (0.5, 0.5, 8) would place the camera at a height of 8 voxels above the southeast corner of tile (0,0,0) (i.e. halfway between tile (0,0,0) and tile (1,1,0)).

I've thought about eventually coming up with a visual system in the Map Editor for creating camera positioning that you could reference in scripts, but that's probably further down the road since it's more involved. What are your thoughts on this?

I think it's a good idea, since the map editor already relies on tiles coordinates, the user should find quite easy to use tiles as points of reference for the camera. Sure, some special objects like "camera points" to place on the map would come handy for beginners (and so would waypoints for moving characters, I guess). Personally I won't need this, but as you say, it would be nice further down the road. So yes, the camera placement system you're describing sounds totally fine for now. Decimals would allow a lot of freedom while keeping the settings straighforward.

Okay great, I will plan to use that approach. Thanks for the feedback!

This first set of functions is taking longer than I had planned, but I am still making progress. :)

Here is where I have landed with the "Move Camera Over Time" function. There will be a similar one for "Move Camera At Speed" to move it at a fixed speed (in voxels/sec) as opposed to a duration of time. There is an optional "Look At" parameter to have the camera rotate towards a particular entity or coordinate as it moves to the new location.

Besides cleaning up and tweaking some things, I need to make a modification to the way scripts are executed in-game to account for these types of actions. For example, right now if you triggered a camera move from a script followed by a second camera move, the game would not wait for the first camera move to complete before starting the second, so I need to add in some timing to hold the script from continuing until certain functions like these have finished executing.

This looks excellent ! So if I'm not mistaken, the Move Camera Over Time function would allow to create timed events based on camera moves, for example "go from here to there in 1 second, play a sound and repeat", which could give interesting audio/video rhythmic sequences. I guess you could make synchronised chiptune videos with that :)

Hi!

Since I've finished a couple of child characters I'm currently testing my first map with different vision heights, and it's pretty cool :) It's awfully simple but still a nice trick: adults look taller and children look the same size as the player, you have to look up to see through the windows... The result is quite immersive, it indeed changes the way the player perceive space.

Hence the need for the "Set Vision Height" function I put earlier in the list, which led me to think about other character properties. I was thinking that I'd also probably need something to change a character's name (assuming it's displayed in dialogues) and movement speed. Maybe also to change if it's walkable and if it emits light, though it's less important for now.

But there's already a "Set Entity Property" which does something quite different, so I guess a single function could be confusing. Would some new functions like "Set Movement Speed" or "Set Name" make sense? They could all be useful both for the player and for NPC (except for NPC vision height, unless we add a "Change Player" function in the future), so they could be even more confusing to name if defined as specific to the player or to NPC.

I probably should add these functions to the list if you're okay with that but I'm not sure how to define them, what do you think?

Hi there, quick question: I'd like to call a dialogue within a script, then resume the script once the dialogue ends. Is it possible? It seems the script doesn't wait for the dialogue. I'm trying to load a map after the dialogue, but the map loads at the same time the dialogue is displayed. I know I could call another script at the end of dialogue itself to load the map, but this would mean "script 1 > dialogue > script 2", while something like "script 1 (part one) > dialogue > script 1 (part 2)" would be more convenient. Or maybe some kind of "Wait for Input" function to put before loading the map would be useful?

It's funny that you mention that because I am working on something very similar at the moment! Now that I've started implementing functions for camera movement, I realized I would need it to wait in certain circumstances - for example, waiting for the camera movement to complete before the next function gets triggered.

I can do something similar for the scenario you have mentioned, also. I think the default behavior should be to wait for the dialogue to end before proceeding in the script (so the map would not load until the dialogue has completed), so I will incorporate that. I think I'll need to do the same thing for "Display Message", as well. Thanks for bringing that to my attention!

Hi again! I pushed a new release a bit ago, v0.3.5.1. I believe this now contains all of the high priority functions except for Rotate Camera and Rotate Player - I am still working those out and should have them for the next release. Since I was working on some timing functionality, I also went ahead and added a "Wait" function to delay the script for a specific number of seconds (or milliseconds if needed, as decimals are allowed).

Let me know how they seem to be working once you get a chance to test them out. There's one known issue - you will not see the player model if you move the camera away from the player in First-Person mode, since the model is hidden by default to prevent it from being seen. I'll need to resolve that for the next release.

Also, one other thing to note that I mentioned in the release notes is the change to the "Load Map" function. The easiest way to fix any existing scripts that use this function is to open them in a text editor and enclose the start coordinate within "coord[x, y, z]" as such:

Old syntax: load_map("start_map", 1, 2, 3, "north")

New syntax: load_map("start_map", coord[1, 2, 3], "north")

Otherwise, the script may fail when it executes. I hate to make changes that break things, but making coordinates into one parameter will be better for the long run and hopefully it doesn't cause too much work to fix your existing scripts. Have fun! :)

Hi, lots of great stuff in that release :) No problem with the new syntax, I was experimenting with map loading so it's no big deal to change a few things. I'll try these new functions as soon as possible!

Okay, great! Also, you may already be aware of this, but enabling the developer console in your game configuration is convenient for testing scripts like these so you can tweak values and see the results right away in-game. For example, you can paste something like this in and hit the enter key to run it:

lock_camera(); move_camera_over_time(coord[2, 2, 24], 2, entity["chest01"])

I've added functions for "Rotate Camera" and "Rotate Camera Over Time" in the latest release. I believe that covers everything in the high priority section except for "Rotate Player". :) I am still making some decisions on how to best define/implement that one, but I should have it ready soon.

I also added a keyboard shortcut of "H" to hide all UI elements (minimap, inventory icon, message box, etc.), which should help with taking minimal screenshots. At some point I will also add some game configuration options around these also (for example, disabling the minimap).

Hi again!

I'm currenty trying to set up a dialogue which appears to be rather more complex than what I thought, involving several NPCs, so I may need a few additional features at some point. I'm not sure how it would work, but basically, this would require a few more parameters for NPC dialogue nodes:

• A way to tell which NPC is talking when calling the dialogue from a script (for scenes where the player doesn't initiate the dialogue)
• Similarly, a way for another NPC to continue the dialogue, so there can be more than two people involved in the dialogue (but I guess this would work the same, by specifying the speaker's ID)
• A way to prevent the NPCs from moving while the dialogue is active (though it can probably be an external function called before the dialogue, like "Set Movement Speed")
• Ideally, an option to look at the NPC who's talking (like "Look At Target", with an optional rotation duration)
• A nice cosmetic detail would be to automatically rotate the NPC who's speaking to face the player, this would make sense since the player is already doing this, and give a more natural feel.
• I guess a way to change the animation of the NPC who's speaking could also be useful at some point.

Hello! I think these are all doable. I can add a field to the NPC node that would let you specify the entity ID of the speaker. If not specified, it would default to the NPC that the dialogue was initiated from (if applicable, otherwise default to "???" or something similar). That gives me another idea to eventually add - further customization of the NPC node where you could enter a custom speaker name (and portrait once that feature is there) that would show instead of referencing an existing entity.

In regards to the NPCs not moving during dialogue, are you referring to all NPCs in the scene, or just the ones that will are engaged in the current dialogue?

I should be getting several more new functions released this evening and then I will take a look at these features in more detail. :)

This sounds excellent :) Sure, custom names and portraits could also be nice options in the future. About NPCs not moving, most of the time all NPCs stopping should be fine, but there would probably be cases where it would look odd if there are many characters in the background. So stopping only NPCs whose ID are mentioned in the dialogue would be fine, I think.

Hi! After testing various dialogue configurations there's something else I'd find useful, though not urgent at all. In my opinion, repeating endlessly the same dialogue when clicking a NPC or object after there's nothing more to do with it tends to break immersion (at least regarding my design choices, even if it's kind of a convention in RPG). So once a dialogue is finished, most often I set properties to avoid triggering anything when interacting again with the NPC/object. It works fine, but the entity is indeed still shown as "interactable" since technically it still has a dialogue or a script. So what I'd need, if possible, is a function to set an entity as non-interactive, in order to remove the current green pointer feedback when needed and avoid confusing the player. Does that seem doable?

Hello! I believe currently you can use the "Set Dialogue" function to achieve this by selecting "(None)" from the dropdown in the visual editor or by specifying an empty string for the dialogue name if you are using a quick script. For example:

set_dialogue("npc_id", "")

There's no way to do it yet for object scripts, so I will make a note to get that functionality added. It should be very simple. :)

Excellent then, thanks :)