MattScott

Hi all, There seems to be some confusion about Full screen mode, so I'll try to clear up the information we are working from, and then we discuss the issue further. There are two forms of Fullscreen - Exclusive and Borderless Windowed. As of DX12, Microsoft is no longer supporting Fullscreen Exclusive. Essentially this is going away whether any of us like it or not. It is worth pointing out that every game that runs on DX12 has already removed Fullscreen Exclusive and replaced it with a Borderless Windowed version. Fullscreen Exclusive literally doesn't work in DX12. They just weren't as transparent about it. Microsoft has written a pretty concise explanation of their strategy here: https://devblogs.microsoft.com/directx/demystifying-full-screen-optimizations/ They are basically saying that Fullscreen Optimizations under Windows 10 equalizes the performance between Windowed and Exclusive, which is why they are phasing out Exclusive. For those that don't know, Fullscreen Borderless Windowed mode looks just like Fullscreen Exclusive. It just interacts with the OS differently. Based on that information, we looked at the distribution of Windows versions across players. Here is what that currently looks like on Steam: Out of the 95% represented by all Windows versions on Steam, Windows 10 accounts for 85% (so 90% of Windows gamers overall). Even with all of that in mind, I recognize that still leaves 10% running Windows 7 or Windows 8 at a disadvantage because of increased input lag. I know that up until January 1 2020, Microsoft was still giving away copies of Windows 10, and believe there are still some ways to get a legitimate copy for free - even with a fresh install. But lastly, we are making this change for a specific reason: During playtests, we kept encountering a common crash related to a vague DirectX error where the DX device was "lost". After spending a lot of time researching this, we narrowed the error down to a combination of problems with Fullscreen Exclusive mode. In our last playtest, we had all the players run in some form of windowed mode. That test only had 1-2 crashes down from 25 for the previous test. I don't want to hold back the Open Beta any more than I need to, so for now based on the information at hand, we are going to remove Fullscreen Exclusive. If the team finds a way to make DX11 Fullscreen Exclusive work without crashing during the Beta, then we'll put that back in. Thanks, Matt

Hi everyone, My schedule has been out of control for the last couple weeks. I've made it through the worst of it, but some of those commitments cut into my time interacting with the community. All of my various inboxes are overflowing with messages from around February. I am hoping to start responding soon. The last two playtests have been somewhat smaller. After reviewing the results from the 29th, there wasn't much to comment on. We did collect a number of very good crash reports, and the district server issue got fixed. Yesterday's test was very positive, but we had less testers, so I can't do an apples to apples. I don't want to get lulled in by good numbers based on less concurrency. For this update, I'm going to track progress on the few remaining items blocking the launch of the Open Beta. I have highlighted the actual blocker bugs, so you can see how close we are. The original crash bug that I listed on Memorial Day. (fixed) 3 more crashes popped up on the 29th, but our test yesterday only had a single crash. So we're making progress. Still investigating the new crash from yesterday. (not yet started) One of the new crashes seems to be related to exclusive fullscreen mode (in progress) This is very close. We are implementing borderless windowed fullscreen that can run at different resolutions than the desktop. Nearly all modern games today have dropped exclusive fullscreen in favor of windowed fullscreen. A bug related to the in-game browser (not yet complete but non-blocking) We have a work around in place to force the browser to open externally for now. A bug on the server related to performance (fixed) A bug related to the crash reporter that is stopping it from working all the time. (fixed) A client fix related to hitches every time a new player loads into the district related to baking out customizations. (partially fixed) This ended up being quite a bit of work. The partial fix was tested yesterday, and we saw some improvement. The full fix is finished now, and we're hoping to get tested internally by Tuesday. That will allow us to get another playtest organized for Wednesday and possibly a second on Friday this week if necessary. A backend task related to copying the Live characters to Beta the first time the player logs in (fixed but in testing) Copy new code and content from APB 1.20 to APB 2.1 (not yet started) This usually takes about a week to do, and we've done it plenty of times before. It's necessary so that when characters are copied over from APB 1.20 for Open Beta they don't crash the new version with clothing or guns that don't exist. There are also a lot of minor bugs, but the whole purpose of the Open Beta is to get lots more players involved, so we can fix the remaining issues. I'm excited to get this behind us, so we can start working on more impactful things like matchmaking and phasing. I'll be back on the 13th with another update. Thanks, Matt

Hi all, This week looks weird, but overall we made good progress. It seems there were just some really high ticket volumes on the 13th and 14th. As of today we have: 260 new tickets (way down from last week) 454 total tickets (way down from last week) We are responding to tickets submitted on 5/14, so we lost ground on the date putting us back slightly over 3 weeks. But since we're significantly lower on tickets, so I expect us to jump ahead on days soon. We added a new CS, and we're interviewing 2 more. Thanks, Matt

Hi there, Sorry I missed this post last year. I appreciate your perspective (and offer to help push money toward development). This is a tricky line for me, because we get a fair amount of inquiries like this each week. Out of respect for the original backers who took the leap of faith back in 2014 and then got burned for so many years, I made a commitment not to re-open the Kickstarter campaign to new people. Instead we are looking at Steam Early Access before the end of 2020. That version wont have all the KS rewards, but we're going to try and do a pre-order once Chapter 1 is launched that is less expensive than the entire game, but above what KS backers paid. Thanks, Matt

Hi there, Everyone is getting the same error. It was reported about an hour ago on Discord. We have determined what the problem is and we are working with Steam Support to resolve it - hopefully with no change on your end. Worst case, we'll email out new codes tomorrow to everyone once they are approved. Thanks, Matt

Hi everyone, If you missed my First Playable stream today on the Little Orbit Twitch channel, we have uploaded it for everyone on our YouTube channel. You can watch all 3 hours here: Thanks, Matt

I don't have exact stats, but I don't remember quite so much latency back when we were using BattlEye. I assume this is because EAC is still sending all the data needed for the server side system even though they cant use it.

Hi all, We're going to be making a change to the anti-cheat soon, and I want to walk the community through it instead of brushing it under the rug. I'll start with why we are no longer sticking with Easy Anti-Cheat. When we negotiated the deal with Kamu (Epic Games), the service was supposed to be client and server side. The critical reason for moving was their management tools and the server side piece which we didn't get with BattlEye. However, we also agreed to pay more to get that. The client side integration was fairly smooth, but the server side integration hit immediate snags. We spent months trying different configurations with the networks to get them talking properly, and when that didn't work, both sides dedicated programming support to fix the issues. When it still didn't work, we started exploring other ways to possibly fix it, but Kamu said based on our concurrency we wouldn't like get good results anyway. More recently I was finally contacted by their head of development with the news that they could no longer justify the resources to finish the server side integration. So then we attempted to work out a reduction in pricing. But we couldn't come to a compromise, so we have mutually decided to end the agreement. Clearly, we will need to keep evaluating server side solutions or build our own, because I have yet to see one that works well enough. During my discussions with various providers, I also went back to BattlEye. Their solution has had some nice improvements since we left, so we're going to give that a try again. Next I want to talk about the current cheating issues in APB. While we do have some private cheats for EAC floating around, I will say that is still in the low single digit percentages for our entire population. However, we do have a problem right now with scripted triggerbots and aimbots. These are an entirely different category of cheat, because they are typically built with the hot key/mouse scripting systems. They are easy to spot, but they are easy to false positive. There are many legitimate uses for scripting systems, and players don't often realize they are enabled by default when they enter the game. With all of that in mind, once we switch to BattlEye we are going to start taking measures against the systems that these cheats are written in. This may be a little bumpy, and I guarantee some players will not read the forums and find themselves very frustrated. But I am taking this step to let all of you to know in advance, that you need to disable your macros and hot key / mouse scripting systems. Anti-cheat will always a work in progress. We will continue to iterate on this. We need a level playing field for players to have fun. Thanks, Matt

Hi everyone, Today is my APB AMA on Reddit, so I wont be updating this thread until maybe tomorrow or Monday. But you can get Reddit and ask me questions directly here: Thanks, Matt

Hi all, We did pretty good this week, but hit a large ticket today that took up one agent all day. I don't want to single this player out, because they pro-actively put their ticket on hold weeks ago till we got more availability. As of today we have: 424 new tickets (slightly up from last week) 585 total tickets (slightly lower than last week) We are responding to tickets submitted on 5/10, so we're holding steady at just under 3 weeks out. Thanks, Matt

Hi everyone, This update isn't going to be very long. We finished a number of fixes last week, and ran another playtest. We knew there was a potential issue with the test district server that popped up on our 5/15 test, so this time we staged a backup district server. We were right and the same issue popped up, but switching to the backup failed because our provider didn't open up the right access, so it was useless. Frustratingly, we still haven't gotten a decent run without crashes on APB 2.1. However, the devs were still able to do a few profiles and capture more areas that we can look at for optimizations. Right now, the most common question I get asked is "When will the Beta launch?" I can't answer that yet, but I can share the remaining tasks/bugs blocking the release: A crash bug that has already been fixed (we hope) A bug on the server related to performance (this has been blocking our last two play tests) A bug related to the crash reporter that is stopping it from working all the time. (this is critical for getting good data from the Beta) A client fix related to fixing hitches every time a new player loads into the district (this is the client taking a hit to generate the customizations for the new character) A backend task related to copying the Live characters to Beta the first time the player logs in Enjoy the Memorial Day weekend, and stay safe. Thanks, Matt

Hi all, This week was good. Both our new tickets and total tickets are lower than last week. But unfortunately there were a metric ton of tickets created on 5/3, so we've been blocked for days trying to clear all those out. As of today we have: 416 new tickets 606 total tickets We are responding to tickets submitted on 5/3, so we're just under 3 weeks out. My hope is that we'll jump ahead on the date a lot next week. Thanks, Matt

Hi everyone, I didn't quite make Monday, but this was a lot to organize. I probably wont be able to post this level of detail in the future. These stats are admittedly a little disappointing. I know many of the testers complained about latency issues on APB 2.1. We're looking to what happened there, but the stats also show that OTW2 didn't perform across the board like last time. It is also important to know that we ran the most complicated customizations that we could, and we still have hitches when new players are entering the district and their customizations are being baked. With so many players versus the 5/8 that could be affecting the stats as well. Regardless, here are the numbers: 5 testers performed lower on APB 2.1 than APB 1.20. And 6 testers from 5/8 weren't able to make it this time. I left their entries blank. We do have more lower spec machines this time, and everyone is running Maximum in APB 1.20 and Very High in APB 2.1. You can definitely see how much raw processing speed affects APB 1.20. The biggest gains for us in APB 2.1 are tied to having more cores. I might be missing some over clocking data for a few of these, which might explain some of the oddball discrepancies. Like I mentioned on Saturday, we had about 10 crashes. They all turned out to be related to the same thing, and we believe we have a fix for that now. We'll spend the next couple days chasing down the rest of the issues, continuing to multi thread new bits of the game, and fixing the hitch when baking customizations. We plan on running another test on Friday 5/22, and this time we'll try to make sure the APB 2.1 server is running better. UPDATE 5/19: I put a new listing up that had more details for overlocking by several testers. I think that helps put the numbers in better perspective. Thanks, Matt

Hi everyone, This is going to be a shorter update with a follow up tomorrow or Monday. We spent the week fixing the bugs and crashes that plagued last week's play test. Yesterday did a new play test with ~30 players. Everyone started by getting on APB 1.20 and testing Asylum for about 30 minutes. Several of the players last week didn't have their logging setup correctly, so we re-ran that portion to establish a benchmark. With people jumping in and out it looks like we had a pretty solid average of ~22 players over the entire test. Next, they got back on APB 2.1 and tested Asylum for the same amount of time. Looks like we got ~22 players during this test too. There were a few crashes, so we have some things to fix this week, but overall the stability was way better. Unfortunately something was going on with the server. There was definitely a latency problem. There are a lot more logs to go through this time, and I had other obligations this weekend, so I haven't finished collating everything This process involves matching up CPU/GPUs to stats for both OTW1 and OTW2, and instead of 19 like last week, there are 29. However, here are the stats from the first player in my list. APB 1.20: AMD Ryzen 7 3800X 8-Core Processor + NVIDIA GeForce GTX 1070 - 102FPS with ~22 players Highest 1% FPS = 173FPS Lowest 1% FPS = 65FPS APB 2.1: AMD Ryzen 7 3800X 8-Core Processor + NVIDIA GeForce GTX 1070 - 125FPS with ~22 players Highest 1% FPS = 248FPS Lowest 1% FPS = 63FPS Thanks, Matt

Hi all, Lots of good discussion. There is a strategy in the works, but I want to hold back the details till we get the combat systems in and can see how things are working. Thanks, Matt

Hi all, This was a really good week for CS. Lots of tickets came in over the weekend, which put us even further behind. But everyone pitched in, and we ended up in a good place. As of today we have: 454 new tickets 672 total tickets We are responding to tickets submitted on 5/1, so we're at the 2 week mark. Thanks, Matt

Hi everyone, I missed yesterday's post due to some hard core number crunching that needed to be done for this update. Sorry about that. My schedule has been extremely busy lately. That also means I'm several months behind responding to messages in my forum inbox. I plan on trying to squeeze some time in this week to catch up a little. With that out of the way, today marks the 2 year anniversary of Little Orbit taking over APB Reloaded in 2018. To be honest, I had hoped that the Engine Upgrade would be shipped by now. But once it was clear that many of the issues plaguing us were not going to be easily resolved, I decided to start this thread a little over 7 months ago. Here is a quick recap of where we are at this point. - We found a new way to multithread using an upgrade to an existing library in the game. We had avoided doing this previously, because the library was only supported on Windows. But the upgrade seems to support console now, so we took a shot. Our first test is focused on how we update lights in the game. The new system is far more efficient and has the capacity to manage more cores at higher utilization. This is still pretty experimental, but we're pretty excited about it. If this test holds up, then we'll likely implement this across the other multithreaded areas. - The team spent last week continuing work on UI optimizations to frame rate. As I said last week, there is still a significant difference in time spent rendering the UI between Live and the Beta. - We also found some clean up audio work that was causing an occasional crash. - And we are exploring a persistent crash popping up for the in-game browser. There has been light weight work going on there for the last couple weeks to get it sorted before we ship the Beta. That brought us to Friday and a rather quickly thrown together stress test to see how all the changes performed. This time we kept it private, because we knew were pushing the envelope. The plan was for each player to first spend some time on OTW playing the Live build of Asylum for a base line benchmark. We encouraged many of the players to load up their most complex customizations, and we tried to fill the district as much as possible. Then we did the same thing in our Beta environment. Each player submitted both logs to us, so we could process the results. At the same time, we had our devs in the Beta environment running around and capturing performance profiles to determine the functions that execute the most and require optimizations. In retrospect, I'm glad I kept things private, because the Beta portion of the playtest was a bit of a disaster. It appears that several of the "rare" or "occasional" crashes scaled up under more load and became "constant". I doubt anyone was able to play for more than 3-5 minutes without crashing and having to load back in. However, we did accomplish most of what we wanted. We got some usable comparisons from testers. We also captured many crash logs, and the devs got quite a number of good profiles that revealed some things we knew, some thing we suspected, and some things we didn't. Based on the logs we did get, here are the results. DISCLAIMER #1: This was a lot less scientific than I prefer, so please don't read too much into the results. Due to the consistent crashes, it was really hard to pull apples-to-apples comparisons, but I did my best by grabbing specific segments of time when things were more equal. At a minimum there might be some good data here for players on APB 1.20 looking to figure out how to improve their performance. DISCLAIMER #2: Our logs don't capture whether the machine is overclocked, so there may be performance discrepancies. I'll start with system configurations and their FPS stats for APB 1.20: AMD Ryzen 9 3950X 16-Core Processor + NVIDIA GeForce GTX 1080 Ti - 112 FPS average with unknown players (grapher bug processing log - but probably 3x as many as the 2.1 log) AMD Ryzen 7 3800X 8-Core Processor + NVIDIA GeForce GTX 1070 - 112 FPS average with ~13 players AMD Ryzen 7 2700X 8-Core Processor + NVIDIA GeForce GTX 1060 - 89 FPS average with ~14 players AMD Ryzen 7 1800X 8-Core Processor + NVIDIA GeForce GTX 1080 Ti - 65 FPS average with ~20 players AMD Ryzen 5 3600 6-Core Processor + NVIDIA GeForce RTX 2060 SUPER - 134 FPS average with ~8 players Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz + NVIDIA GeForce RTX 2080 Ti - 184 FPS average with ~11 players Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz + NVIDIA GeForce GTX 1080 Ti - 144 FPS average with ~13 players Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz + NVIDIA GeForce GTX 1080 - 92 FPS average with ~9 players Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (OC to 5.0GHz) + NVIDIA GeForce GTX 1070 - 151 FPS average with ~8 players Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz (OC to 4.60GHz) + NVIDIA GeForce GTX 1080 Ti - 117 FPS with ~13 players Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz + Radeon RX Vega - 117 FPS average with ~22 players Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (OC to 4.4GHz) + NVIDIA GeForce RTX 2070 - 111 FPS average with ~11 players Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz + NVIDIA GeForce GTX 1080 Ti - 127 FPS average with ~13 players Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz + NVIDIA GeForce GTX 970 - 61 FPS average with ~8 players Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz + NVIDIA GeForce RTX 2060 - 96 FPS average with ~13 players Intel(R) Core(TM) i7-4820K CPU @ 3.70GHz + NVIDIA GeForce RTX 2060 - 72 FPS average with ~14 players Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz + NVIDIA GeForce RTX 2070 - 65 FPS average with ~8 players Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz + NVIDIA GeForce GTX 660 Ti - 62 FPS average with ~8 players Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz + NVIDIA GeForce GTX 1060 - 75 FPS average with unknown players (grapher bug processing log - but probably 3x as many as the 2.1 log) Next, here are their FPS stats for APB 2.1: AMD Ryzen 9 3950X 16-Core Processor + NVIDIA GeForce GTX 1080 Ti - 177 FPS average with unknown players (grapher bug processing log - player count likely 1/3 of the 1.20 log) AMD Ryzen 7 3800X 8-Core Processor + NVIDIA GeForce GTX 1070 - 123 FPS average with ~11 players AMD Ryzen 7 2700X 8-Core Processor + NVIDIA GeForce GTX 1060 - 132 FPS average with unknown players (grapher bug processing log - player count likely 1/2 of the 1.20 log) AMD Ryzen 7 1800X 8-Core Processor + NVIDIA GeForce GTX 1080 Ti - 117 FPS average with ~9 players AMD Ryzen 5 3600 6-Core Processor + NVIDIA GeForce RTX 2060 SUPER - 140 FPS average with ~5 players Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz + NVIDIA GeForce RTX 2080 Ti - 197 FPS average with ~11 players Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz + NVIDIA GeForce GTX 1080 - 214 FPS average with ~11 players Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz + NVIDIA GeForce GTX 1080 - 130 FPS average with ~9 players Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (OC to 5.0GHz) + NVIDIA GeForce GTX 1070 - 194 FPS average with unknown players ( player count likely close to the 1.20 log) Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz (OC to 4.60GHz) + NVIDIA GeForce GTX 1080 Ti - 169 FPS average with ~8 players Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz + Radeon RX Vega - 147 FPS average with ~11 players Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (OC to 4.4GHz) + NVIDIA GeForce RTX 2070 - 154 FPS average with ~7 players Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz + NVIDIA GeForce GTX 1080 Ti - 134 FPS average with ~13 players Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz + NVIDIA GeForce GTX 970 - 59 FPS average with unknown players (grapher bug processing log - player count likely close to the 1.20 log) Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz + NVIDIA GeForce RTX 2060 - 113 FPS average with unknown players (grapher bug processing log - player count likely 1/2 of the 1.20 log) Intel(R) Core(TM) i7-4820K CPU @ 3.70GHz + NVIDIA GeForce RTX 2060 - 72 FPS average with ~13 players Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz + NVIDIA GeForce RTX 2070 - 164 FPS average with ~6 players (don't read into this.. no idea what was happening or not) Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz + NVIDIA GeForce GTX 660 Ti - 62 FPS average with unknown players (grapher bug processing log - player count likely close to the 1.20 log) Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz + NVIDIA GeForce GTX 1060 - 112 FPS average with unknown players (grapher bug processing log - player count likely 1/3 of the 1.20 log) Whew! That is a relatively small amount of info, but took quite a while to compile. We are planning another play test this week, so I should have a better update on the 16th. Thanks, Matt

Hi all, The team did a great job of plowing through tickets and bringing the numbers down overall compared to last week. We continuing to explore new CS resources. As of today we have: 469 new tickets 672 total tickets We are 2 away from responding to tickets submitted on 4/23, so we're slightly over 2 weeks to respond. Thanks, Matt

Hi everyone, First, I want to acknowledge that I have been absolutely terrible about providing updates on Fallen Earth. Certainly COVID-19 has had an impact on the studio's ability to work on multiple titles at once, but this mostly rests on me. I kept scheduling an update for you guys, and then by the end of a 10-12 work day, I just couldn't seem to find the time. Second, I want to set expectations (again) for where we are and where we aren't. This project is #3 on our priority list right now. As a company we can only do so many concurrent projects with the staff we have. 1) We need to get the APB Engine Upgrade out the door. Internally, we have been forced to keep shifting the date out due to performance issues, but we have reached the "all hands on deck" point. This needs to ship, so we can free up developers to focus on other priorities. 2) After that, we have also committed to a Live stream of Unsung Story for those backers who have waited 5 years to get a glimpse of the game they funded. So the rest of the studio is working overtime to prepare for the June 1st stream. I want to be clear that Fallen Earth isn't loved any less in the studio. Temporary circumstances have forced us to be very specific where we are putting our resources. The team is excited to get back into the Wastelands, so we can get you guys the game you deserve too. We are still very much in the early, exploratory phase of development where we were testing various solutions to each system that needs to be ported. But here is a description of the short term roadmap to get to our first internal milestone: - Recreating the terrain This effort got fairly far along, but there is still work to do. While the basic shape of the terrain is in, there are 2 subsystems that haven't been ported. The first system uses image "stamps" to deform terrain based on where the original designers placed them. These stamps create more interesting geometry and help break up the height mapped look of what we have now. The second system uses nodes that form lines and areas to deform terrain for roads, hills, lakes, and other areas where geometry has been "carved" away by the remnants of humanity to build their structures. - Terrain texture layers This technology has gotten quite a bit better since Fallen Earth was written. The team was starting to identify the strategy for "splatting" or compositing textures on the terrain to create more variation and interest as the player moves through different ecosystems or biomes. - Foliage rendering This is likely one of the biggest areas where I think we can make the world of Fallen Earth feel more realistic. Foilage systems have become so much more powerful and now contain more realistic looking plants and trees. The team was exploring how to adapt the game's foliage data so it could be applied into Unity's systems. This combined with the above terrain enhancements should be impressive in the final product. - Streaming the terrain and objects The original code was very good at rendering chunks of terrain with only the nearest objects to you. In the new code, we've gone with an entirely new way of chunking up the map that will require us to stream in pieces as you run around. We had just started experimenting with a couple techniques, before the devs got pulled onto other projects. NOTE: We have a basic demo for the terrain that I took screenshots from, and this runs extremely slow because all of the terrain and objects across the entire world of FE are rendered. - Fixes to imported assets We also found some bugs in our importer that created inverted normal maps, didn't assign textures properly, or created rigs wrong. We were in the process of fixing these bugs, so we could delete the imported assets and reimport everything from scratch. Then we can re-run the process that builds the various layers to the map, so we can prep streaming. - Character assembly With all the pieces for characters imported, the team had started work on the code that assembles the player with the proper body proportions, head, tattoos, clothes and items. We hit an immediate snag on supporting "selection sets". These are lists of faces on the model that can be shown or hidden by name. The original code used them to hide the areas that are covered up by clothes. - Basic movement prototype This is our first milestone for the project. With all of the above tasks completed, the plan is to (1) assemble a character (2) load into the world and (3) run around the environment with active collisions preventing you from walking through objects. This wont be connected to any servers or running any multiplayer code. It's just a milestone to test everything all together and see how it looks. With all of that in mind, I thought it would be fun to post some WIP screenshots for classic Fallen Earth locations, so you could see how some of this is coming along. The shots below show the assembled terrain, buildings, objects and props for the entire world. You'll notice in the upper right hand corner, that we're sticking with the game's original coordinate system. This allows us to hop around the map to inspect things. There are no terrain textures yet because the layering system hasn't been implemented. Just imagine this is Fallen Earth in winter . Oddly, that effect is enhanced by a good number of the objects that are embedded too low into the ground. This is because we're still missing those two subsystems that I mentioned above that deform the terrain in smaller areas. You'll also see some texturing artifacts on the buildings and objects. Everything looked good as we inspected a couple buildings at a time during the import process. But when we assembled the whole map we found areas that still needed work in the importer. Clinton F.A.R.M. Embry Crossroads Los Alamos Haven Watchtower Odenville And a bit of a fail with Boneclaw… Apparently the ramps for this area are heavily carved out from the terrain, so much of it is buried. I appreciate your patience. Stay safe. Thanks, Matt

Hi all, Sorry for the late post today. I try to get these out a bit earlier, so they can be read by our European player base. We had another big push this week to try and clean up remaining items for the Beta. We completed a lot of the audio re-work late on Friday, but I had an SPCT member go in, and we saw many of the issues were fixed. Still a couple stragglers, but with the limited testing, it looks like we got about 80-85% of these bugs. Next, let's deep dive frame rate issues. Last week, I walked through our work on optimizing the UI during missions in Asylum. Today, I thought I would post some of the performance statistics from several builds. These all came off the same machine with the following specs: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz with 16GB of ram and an NVIDIA GeForce RTX 2080 SUPER The test is based on the average frame rate running around for 10 minutes in Asylum while actively doing objectives and missions. I should make the disclaimer that we always accept these benchmarks with a grain of salt, because with an online game it is impossible to recreate the same exact testing conditions. But we use them as a general feedback mechanism to let us know if we're on the right track. I'll apologize in advance for not having any of Skay's pretty charts. We started with the performance on Live with ~18-19 players in the district: Mean Frame time = 8.08ms Mean Frame rate = 123.75 FPS Average Frame time = 8.125ms Average Frame rate = 123.07 FPS Maximum 1% Frame time = 6.95ms Maximum 1% Frame rate = 143.8 FPS Minimum 1% Frame time = 11.12ms (ignoring hitches) Minimum 1% Frame rate = 89.87 FPS UI accounted for 1.41ms on average We actually pulled two logs from two different sessions during the 4/17 Beta. I'm going to share them both, because it illustrates the variance in benchmarking. Session #1 during the Beta stream with ~19-24 players in the district: Mean Frame time = 12.02ms Mean Frame rate = 83 FPS Average Frame time = 12.19ms Average Frame rate = 82 FPS Maximum 1% Frame time = 6.62ms Maximum 1% Frame rate = 151 FPS Minimum 1% Frame time = 18.16ms (no hitches) Minimum 1% Frame rate = 55 FPS UI accounted for 4.43ms on average (more than 3ms higher than Live) Session #2 during the Beta stream with ~19-24 players in the district (but only half that for the last couple minutes): Mean Frame time = 10.98ms Mean Frame rate = 91 FPS Average Frame time = 11.21ms Average Frame rate = 89 FPS Maximum 1% Frame time = 5.55ms Maximum 1% Frame rate = 180 FPS Minimum 1% Frame time = 16.94ms (no hitches) Minimum 1% Frame rate = 59 FPS UI accounted for 3.49ms on average (only 2ms higher than Live) You can see that just dropping some opponents during the stream for the last couple minutes made a significant difference in the frame rate between Session #1 and Session #2. All three of these tests had real players running around firing and jumping a lot more often in concentrated areas with customizations. The bots don't do that. There is literally no AI at all. They randomly path around the district, fire and interact with things. They are great for us to trace code and diagnose issues, because we can start up missions in Asylum without gathering a bunch of real people. In retrospect, I wish we had a bot run from the 4/17 Beta build. We got an original benchmark today, and I had to throw it out because we didn't have enough bots running and the bots that were in the district were super far from each other. So the stats were clearly skewed and too good. We fired up more (although couldn't get 19-24 to compare), and this time they clustered up a bit near the Criminal spawn point. But even this next benchmark wont represent an apples to apples test with the first three. Here are the results from today's session in the new Beta build with 15 bots: Mean Frame time = 6.03ms Mean Frame rate = 165.78 FPS Average Frame time = 6.07ms Average Frame rate = 164.8 FPS Maximum 1% Frame time = 4.82ms Maximum 1% Frame rate = 207.4 FPS Minimum 1% Frame time = 7.80ms (no hitches) Minimum 1% Frame rate = 128.2 FPS UI accounted for 2.56ms on average (we are still running both Unreal UI and Scaleform for now during game play in APB 2.1) Based on this test, the next step will be to organize another large playtest between SPCT, the streamers, and LO staff so we can get a better benchmark. I'll let you guys know when that will happen. FOOTNOTE: Also for those that are interested, we started work on the unfinished DAM (District Allocation Management) system that was designed by Reloaded. This system dynamically collapses and expands threat by spinning down and spinning up new districts during the day. This is the first major system we will launch directly aimed at solving match making in a new way. It requires APB 2.1 to work, but I wont hold back the Beta for it. I wanted to make sure we get that feature pushed out as soon as possible. Thanks, Matt

Interesting format and questions. I'd be curious to see the results. Thanks, Matt

Hi all, We worked hard to make up ground this week despite the rising tide of tickets. We also brought on a new CS person. As of today we have: 493 new tickets 685 total tickets We are responding to tickets submitted on 4/17, so we're at 2 weeks to respond. Thanks, Matt

Hi all, I’m definitely interested in seeing the results once enough people have weighed in. Thanks, Matt

Ahh. Thanks. I wasn’t.

Hi there, We had to turn on this feature recently when our registration / login pages were getting hit by bots. This isn’t a DDoS attack, but it’s similar in that attackers direct lot of traffic to fill out specific page to make them unavailable. Thanks, Matt