{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "Beacon Developer Blog", "home_page_url": "https:\/\/usebeacon.app\/", "feed_url": "https:\/\/usebeacon.app\/blog\/json.php", "author": { "name": "Thom McGrath" }, "items": [ { "id": "fdd472fe-fbb9-40fc-a8cc-ba69e9ed934e", "url": "https:\/\/usebeacon.app\/blog\/beacon_2_roadmap", "title": "Beacon 2.0 Has Been Released! Here\u2019s What\u2019s Coming Next.", "content_html": "
This update has been in the works for a long time and was supposed to be released just before Ark: Survival Ascended, but some changes were needed that delayed the schedule.<\/p>\n
But it's out now! The release notes<\/a> have a full human-readable breakdown of the major new features, so I won't repeat it all here. This post is really about looking to the future.<\/p>\n Beacon 2.0 was supposed to include support for 7 Days to Die, but I decided to delay it to get ASA support done sooner. This is still coming, but I intend to continue to focus on ASA for the time being.<\/p>\n There's no such thing as a console server vs. PC server, since all servers are cross-play capable. This means that all PC features - such as FTP access and RCON support - are available to all servers. This opens up a number of possible features for Beacon that I will be exploring in the near future.<\/p>\n None of this is a promise that the feature will happen.<\/strong> This is just my roadmap of features I want to explore and add.<\/p>\n<\/blockquote>\n I'd like Beacon to back up the map data, player files, and tribe data. In the past, this wasn't possible for all servers because console servers didn't have FTP access and didn't list all server files. Both of these features are now available, so you should be able to back up your data during deployment. Of course, restoring those backups will also be a necessary feature, because what good is a backup that you can't use?<\/p>\n Beacon already has a lightweight RCON class that is used for ASE's Mod Discovery. My plan is to make this class more robust and build an actual RCON editor into Beacon. I've avoided this in the past because Beacon has historically been a config file generator. Well... not anymore. The site has been calling it a "server manager" for some time now, so I intend to embrace that. RCON will also be useful during deployment, as it can send custom stop messages or behaviors before shutting down.<\/p>\n ASA has the ability to update ini files while the game is running. I would like Beacon to support this. At some point in the future, you'll be able to choose between three deployment behaviors: "shutdown and update", "update and restart", and "update only". The wording of these is subject to change, of course.<\/p>\n I've already got code to find the Epic Online ID, spec ID, player name, and tribe ID from the player files on the server. This information is invaluable for many cheat codes, bans, whitelists, and admin lists. Allowing Beacon to generate a list would be an incredible tool.<\/p>\n I'd also like to see Beacon host player control lists, but I'm still exploring options.<\/p>\n This is another area I'm still exploring. Dynamic config allows you to change a small subset of settings on the server without restarting the server. It requires a URL pointing to a text file, but there's no reason Beacon couldn't provide that.<\/p>\n Ark: Survival Ascended is better than I expected, in my opinion. There are issues with stacking certain items and spawn overrides don't work at all, but I see no reason why these won't be fixed eventually. Overall, the game is solid and the building improvements are fantastic. So go play the game. Have fun.<\/p>",
"date_published": "2023-12-06T18:08:08.000+00:00",
"date_modified": "2023-12-06T18:08:08.000+00:00"
},
{
"id": "1f6fb7d0-c52f-4c0a-a28c-8fa1ca6c7bc5",
"url": "https:\/\/usebeacon.app\/blog\/summer_2023_roadmap",
"title": "Happy Summer! That Means It\u2019s Time for Beacon\u2019s 2023 Roadmap",
"content_html": " A lot of effort is being spent getting ready for Ark: Survival Ascended. But I need to back up a little bit.<\/p>\n I've been working on the fourth version of the Beacon API, which is radically different from the previous versions. Although all versions of the API have been available for public use, none were really designed with that in mind. For example, signing in is done with your email and password, right? But that also means if you wanted to make an app that accessed the data of Beacon users, you would need to collect their email and password. That's a big privacy problem, and something that OAuth<\/a> solved years ago. So the v4 API uses OAuth 2.1 for authentication. Even the next big Beacon update will use it, meaning the official Beacon app will have access to the same features as a third party app.<\/p>\n I mention this because the v4 API is much easier for me to work with, so the ASA stuff will only be available to the v4 API. That means I have to get it finished quickly, and Beacon updated to use it.<\/p>\n The reason for this big API change is because there's a good chance some developers will want access to new features being added. I've got something new in the works that I'm not ready to announce, but I bet there are developers that will want to produce Discord bots. So it's extremely important I get this new version of the API right.<\/p>\n So this year's update isn't particularly entertaining, but I'm not planning too far out due to ASA coming up soon. I might do another update in the fall or winter when the future is a little more predictable. But for now, the update is kind of boring.<\/p>",
"date_published": "2023-06-29T02:32:56.476+00:00",
"date_modified": "2023-06-29T02:33:53.000+00:00"
},
{
"id": "60db82a1-28e9-4295-9f80-88af12203479",
"url": "https:\/\/usebeacon.app\/blog\/beacon_ark_survival_ascended",
"title": "Let\u2019s Talk About Beacon and Ark: Survival Ascended [Updated]",
"content_html": " [Update October 15th 2023]<\/strong>: Based on what little Wildcard has told us about Ark: Survival Ascended (ASA), we already know that there will be enough differences for ASA to be considered a separate game by Beacon. For example, player and dino movement speed will be capped by default, but there will be a configuration option to turn it back on. This confirmed difference alone means that there would have to be some sort of separation between Ark: Survival Evolved and Ark: Survival Ascended. The good news is that the existence of the option at all is a good indicator that ASA will still have plenty of configuration options.<\/p>\n As Beacon grows, my plan is to add support for more non-Ark games. However, I don't think it would be fair to raise the price of Beacon Omni every time a new game is added, since not all users will use Beacon for every game it supports. So Beacon Omni will be a separate purchase for each game, and since ASA is a separate game, there will be a separate purchase for Beacon Omni for Ark: Survival Ascended.<\/p>\n I'm also introducing some other pricing model changes in the interest of keeping Beacon maintainable. Beacon Omni will be moving to an update plan model. This is similar to a subscription, and I'm sure some people will call it a subscription, but it's not exactly the same thing. In an update plan pricing model, you purchase a license to the current version of the software, as well as any updates that are released over a period of time. When your update plan expires, you still have full access to the licensed software<\/strong>. You still have the license for life.<\/p>\n Here's how Beacon Omni for Ark: Survival Ascended will work. $20 USD will get you Beacon Omni for Ark: Survival Ascended and updates for one year. Renewal of the update plan is $10 USD for each additional year. Existing owners of Beacon Omni for Ark: Survival Evolved can upgrade to Beacon Omni for Ark: Survival Ascended for $10 USD<\/strong>, which also includes one year of updates. Prices for other currencies will be based on exchange rates.<\/p>\n Existing licenses of Beacon Omni for Ark: Survival Evolved will not change at all<\/strong>. They are still lifetime licenses.<\/p>\n As for when<\/em> Beacon will support ASA, that's impossible to predict right now. We don't know enough about ASA, and even once it's released, it will take time to discover settings and figure out how they work. Wildcard's documentation of these things is notoriously poor. My plan is to essentially duplicate the ASE code for ASA, and then make changes from there as needed. So support might be available within a week or two, but there's a very high chance that settings will be wrong and require more updates to work out the kinks.<\/p>\n Original post<\/strong>:\nI'll get right to the point: I don't know anything more about Ark: Survival Ascended (ASA) than you do, so I don't know what Beacon's support for it will look like. There are two possibilities:<\/p>\n If I need to treat ASA as a separate game, there's some good news and bad news. The good news is I already planned for this eventuality, albeit for Ark 2. Beacon 1.6 already understands the concept of multiple games, but the interface elements are just hidden. This means I could get a version of Beacon ready for ASA in weeks (probably with bugs) instead of months.<\/p>\n Besides the timing, the bad news is that at this time, I have not decided wether or not ASA support for Beacon will be a paid upgrade. If I can go with option 1 and not have to treat it as a separate game, it'll be included in your existing Omni purchase. This would be my preferred route. However, my plan has been to charge separate Omni purchases for each game that Beacon supports. This makes sense because if I add support for a game you're not playing, it means you're not paying for something you don't need. This design is also already in place in the shipping version of Beacon. But I'm not convinced wether or not it's "right" to charge an upgrade fee for this, especially with all the repurchasing Wildcard expects us to do.<\/p>\n I have not decided yet<\/strong>. Beacon for Ark: Survival Ascended may be a paid upgrade, or it may not be. I need time to consider.<\/p>\n I think we have a rough transition ahead of us. I'll handle it the best I can.<\/p>\n Oh and for the record, this is not<\/strong> an April Fool's joke.<\/p>",
"date_published": "2023-04-01T05:24:01.000+00:00",
"date_modified": "2023-10-16T16:12:25.000+00:00"
},
{
"id": "30976253-d510-48ae-9094-99a479fd1dff",
"url": "https:\/\/usebeacon.app\/blog\/update_163",
"title": "Beacon 1.6.3: The Security Update",
"content_html": " Since Beacon gained online features, user security has worked pretty much the same way. When you sign into Beacon, your profile information is downloaded which includes your account's private key. This private key is encrypted with your password (or more specifically, a key derived from your password) and then stored on your computer. This unencrypted private key allows Beacon to use your account without ever needing your password again.<\/p>\n The trouble with this design comes from users giving out their passwords. They might find somebody to help with their project, that somebody signs into their account, and then won't sign out. The only solution is to generate a new private key, which breaks the encrypted data inside your projects and all your files stored in the cloud. Changing your password doesn't help because Beacon is not using your password.<\/p>\n Also, please don't do this. Beacon has project sharing features to avoid this. Never give your password to anybody for any reason.<\/p>\n As of Beacon 1.6.3, private keys will remain encrypted with your account password while stored on your device. This means if you change your password, your key stored on other devices won't decrypt for long.<\/p>\n Technically, the key will still decrypt using the old password, but Beacon checks for changes each launch. This is how relaunching Beacon gets it to notice when Omni has been purchased. So after the launch, Beacon will download new profile data, try to decrypt the private key with the old password, fail, and kick the user back to the login window. The profile data is also removed from the device at this time.<\/p>\n This new logic means Beacon needs to know your account password for every single run. This sounds inconvenient, but there's a solution to that too. When you log in now, there is a new "Login Automatically" option that will save your password. On macOS, this uses the system keychain. On Windows, your password is encrypted with a key derived from hardware identifiers, so it won't decrypt on a different device. With this option enabled, Beacon can automatically get your password and decrypt your private key each launch.<\/p>\n One potential problem with this design is it requires somebody to use the new version of Beacon. If they sign in with an older version of Beacon, they still have your unencrypted private key and we're back to square one. This is where two step authentication comes into play.<\/p>\n When you enable two step authentication for your account, older versions of Beacon cannot log in. Only Beacon 1.6.3 and newer is able to understand the second step.<\/p>\n To enable two step authentication, head to https:\/\/usebeacon.app\/account\/#security<\/a> and you'll see a new "Authenticators" section. You can have multiple authenticators on your account, though at the moment only TOTP (like Google Authenticator) is supported. More options might be added in the future, though SMS will never be an option.<\/p>\n As with other implementations of two step authentication, you'll be presented with a QR code to scan, then you generate a code and continue. In Beacon's case, you can also give a nickname to the authenticator in case you add more than one. Most users won't have more than one authenticator.<\/p>\n Once your account has an authenticator, that's it, two step authentication is enabled for your account. Currently signed in sessions will continue to work, but cannot be renewed without signing in again. You can revoke sessions in the Sessions section of the account control panel. Your account will also gain 10 backup codes. Store these somewhere that they cannot be lost, as they can be used in place of a verification code should something happen to your authenticator.<\/p>",
"date_published": "2023-01-17T18:53:04.010+00:00",
"date_modified": "2023-01-17T18:54:57.000+00:00"
},
{
"id": "a76b5994-32a7-4b66-8f0a-44419b359eee",
"url": "https:\/\/usebeacon.app\/blog\/summer_2022_dev_update",
"title": "Beacon Summer 2022 Development Update",
"content_html": " It's time for another annual roadmap and status update.<\/p>\n Today's maintenance was rougher than anticipated, but that's always how it goes. But it's worth it, because Beacon services are much better off with this batch of changes.<\/p>\n Most importantly, I haven't been happy with Beacon's response times in some parts of the world. Beacon has been hosted from a server in New Jersey since its inception. This gives a reasonable access time in the most populated parts of the world, but leaves Australia (and its neighbors) with a very long ~900ms time to first byte<\/a>. I've wanted to do better for a long time, but scaling has been a weakness of mine when it comes to IT skills.<\/p>\n With this new architecture, Beacon now has three servers: one "master" you'll never directly interact with, a server in New Jersey, and a server in Sydney. Should the need arise, additional servers could be added in about 30 minutes. I don't want to go overboard of course, as these cost money, but I could see putting one in Frankfurt and San Francisco. We'll see what the future holds.<\/p>\n With these new servers, I've taken the opportunity to improve user privacy in a couple ways. I'm a big fan of privacy and avoid sharing user data unless absolutely necessary. There were two areas I noticed I could do better.<\/p>\nWhat's Next for Beacon?<\/h2>\n
\n
Save Data Backups<\/h3>\n
RCON Support<\/h3>\n
Deploy Without Restart<\/h3>\n
Player Management<\/h3>\n
Dynamic Config<\/h3>\n
For Now... Enjoy<\/h2>\n
\n
No More Unencrypted Keys<\/h2>\n
One Step Further<\/h2>\n
Server Upgrades<\/h3>\n
Privacy<\/h3>\n