Hello, we recieved a lovely holiday gift from Steam this week: [img]https://steamcdn-a.akamaihd.net/steamcommunity/public/images/clans/12002589/4a451a05ef1c153520c2d7c514ccd1e4c9201f3c.jpg[/img] The note reads: [i]Happy Holidays! From the Steam Team[/i] The chocolates are delicious and do not seem to be lasting long... [h1]Cutscene Controller[/h1] One of the things planned for the 1.0 release is a proper campaign and a tutorial-like “New Player Experience”. Both of these try to guide the player, and for that we sometimes need to divert the player's attention to a particular place in the virtual world. In other words, we need cutscenes. Basic cutscenes are relatively simple things:We need to take the control away from the player, move the camera around to show the things we need to show, and maybe display some messages on screen. Cutscenes are meant to be triggered and controlled by scenarios, so there needs to be a generic way for scripts to describe a cutscene. Inside the engine, player inputs pass through a layer called, unimaginatively,"controller". The 0.16 version of the game knows three controllers:[list][*]Character controller, where player inputs control the engineer entity in the centre of the screen.[*]God controller which is not tied to an in-world entity but rather allows the camera to fly around the world freely and interact with anything.[*]Ghost controller which does not allow the player to control the game at all.[/list] The controller layer is the ideal place to take control away from the player in a cutscene. It is also a convenient place to move the camera automatically. Even better, Lua scripts can already change the current controller for any given player. Adding a new controller type to facilitate cutscenes was the obvious choice here. The new cutscene controller is created with a list of map positions to pan the camera to, along with how long each pan should take, and how long the camera should stay in that position. The controller figures out on its own how to move the camera between the specified points – for that, it uses [url=https://en.wikipedia.org/wiki/Cubic_Hermite_spline]Cubic Hermite splines[/url] to make the camera movement nice and smooth. Once the controller reaches the last specified camera positions, it smoothly pans back to the starting position and restores the previous controller, giving control back to the player. Here is a short video of the cutscene controller in action: https://cdn.factorio.com/img/blog/fff-273-cutscene.mp4 Since this is all accessible from Lua, modders and scenario creators will be able to make a use of this new functionality in 0.17 from day one. [h1]Rail clock[/h1] While working on the campaign, I ended up needing to do some work on cutscenes too. Inspired by a [url=https://www.youtube.com/watch?v=UnkdQEyGqqU]Youtube video[/url] I ran across by the venerable "arrow in my gluteus maximus", I decided that a great test case for cutscenes would be a static camera for a rail clock in the office, which could display the actual time. [img]https://steamcdn-a.akamaihd.net/steamcommunity/public/images/clans/12002589/4ae16e2befcd0c943c35fee53b47f9acb0365a58.jpg[/img] Because of some technical issues, this needs to run as a multiplayer game, and it actually ended up exposing a few bugs in the cutscene implementation that only manifested in a multiplayer game, so that was a nice side effect. Here's a video of it in action: https://cdn.factorio.com/img/blog/fff-273-rail-clock.mp4 If you're a reasonably technical user, and would like to run one yourself, you can check out my [url=https://gitlab.com/wheybags/factorio-rail-clock]rail clock repo[/url]. Unfortunately, as it does use various 0.17 features, you can't actually run this today, but once 0.17 is released publicly, it should work just fine. You will also need to use either Linux or macOS. Windows might work, but there is a python component involved which has never been tested on Windows. [h1]Localisation plan for 1.0[/h1] For a long time we have been using Crowdin for all the non-English translations of the game. Over the course of the early access period this has served us really well, the majority of the contributions were of a high quality, and since we automated the fetching and packaging of the translations, it was a mostly hands-off system. As we approach 1.0 next year, we want to make sure that all parts of the game are as polished as they can be, so we are planning to have a 3rd party proofread and finalize the game localisation. While most of the current translations are really great, some of the languages we support have less than 50% of the strings translated and approved, so contracting another company to help fill out the rest is a reasonable course of action for us. However we need to know where we should prioritize our efforts, so that the languages we target and focus on are the most significant ones and will help as many players as possible enjoy the game. To gather some preliminary data, we have created a simple Google form with some questions for our community. If you could help us by spending a few minutes filling it out, we will be able to make a more accurate decision on which languages are most important. You can find the survey [url=https://goo.gl/forms/RMvNnDlNOiUFS1g32]here[/url]. Furthermore, if you have any other suggestions or feedback on the localisation of Factorio, any companies which you would recommend, etc. please let us know. As always, the place to share these helpful thoughts is our [url=https://forums.factorio.com/63922]forum[/url].