Hey,
first of all: try deleting your cache by deleting everything in %LocalAppdata%/Just Cause 3 Multiplayer. Then start yet again the mod as administrator.
If that doesn't help reinstall the mod. If that doesn't help again, I'm going to forward that case directly to Alex aka. meow, the main dev of nanos.
Greets

It’s a long time ago that we have talked about the previously announced 1.1 update in a blog entry. It’s a long time ago that you have received information on its development status, on when the update is going to come out and on why we communicate and work the way we currently do.
Let’s address the biggest question first:
Why is this all taking so long?
Well. As many of you know, Just Cause 3 Multiplayer is a hobby project which, despite nanos being a company, is done without payment in our free time. Everyone of us, whether in management or development, is looking to invest as much time as possible into our projects. Sadly there are also times where neither of us is able to invest as much time as they want to, for example due to job reasons. This was exactly the case: Alex, our lead developer, was, quickly after the announcement of 1.1, unexpectedly and indefinitely more involved in his job - this meant it was not possible to finish 1.1 on time. Since we did not know when he had the capacity to fully come back we decided on putting the release date on “soon”. Nowadays we know that this was a clear mistake, which even turned into a kind of running gag for the community.
Many of you have noticed that our team is not that small and that we should have enough resources for a speedy development of Just Cause 3 Multiplayer. That may be the case on first sight, but in reality it’s a different story. There are only 3 developers working on JC3:MP, namely Alex, Jan and Aaron. The latter two had to pause due to job reasons shortly after the 1.0 release on Steam, which meant that Alex was the only one left. This would not have been a problem if he hadn’t run into the same issue shortly after. Not a good situation, for both us and you-
Many of you also raised the question why we are not shifting away resources from other projects, such as the Framework or nanos world, to Just Cause 3 Multiplayer. There are two simple reasons:
Every project at nanos, whether its publicly announced or not, are internally fully independent - something that we want to keep that way. This means: If there are issues in one project it should not and will not affect any other project. This is important for us since we want to guarantee a constant workflow in as many projects at possible. This is also so each team can specialize on each project, ensuring highest quality standards.
Development would be halted for a period of time anyways, even if she shifted resources. Developers working on other projects neither know the code and resources of Just Cause 3, nor the codebase of our multiplayer modification. Learning to work with it would take a serious amount of time which can be used more effectively elsewhere - since the development-take-over would anyhow be just temporary till Alex fully comes back.
Another reason on why it takes so long is the size of the update: Despite the many new features we have announced the whole client has been rewritten, including a brand new main menu. This leads to the next question...
Why are you rewriting the client anyways?
Legitimate question, which we can answer by looking at our core values. If we find a way on how to make our code more clear, performant and stable we use that as a chance to improve on our product. For some this might be vanity, but we think it is necessary for maintaining a quality standard you deserve. For the end-user it is pretty clear that a rewrite is the right choice: Better performance, more stability and, in the future, faster updates. We managed to prove that already with the server-code and we are confident to do so with the client as well.
Another important fact is that our code is based on an idea starting in the years 2013 and 2014. The base was created for our former project, GTA:MP. In the beginning of JC3:MP we ported it over, so it could be used with Just Cause 3. Nevertheless, the code had a lot of features and code prepared, which could not be used or was simply deemed irrelevant over the following months of development. This meant that in the end our code was feature rich, but messy: Something we fixed in the server and are currently doing in the client.
At this point we want to show you how our main menu will look like in the future. We could already gather a lot of feedback and improved on our previous preview:
Okay, nice. But what are the other features the update will include?
Some of you already know it, but the most requested feature will be finally available - so let’s talk about it again: Tethering!With 1.1 it will be possible to link objects, vehicles or players to each other. You can find some videos on that on our social media channels and on our previous blogs.
Other features include.
Option to use different skins (bye bye, army of Ricos
Placing objects in the world
Even more nice Scripting API functions enabling server to do more nice things
WebGL support for WebUI
Controller Support for our Main UI
Updated node and cef to their respective latest versions
Probably some more I can't think of right now (This was alex)
Nice! So how far you with the update and when can we finally enjoy it?
A question we are receiving multiple times every day and which we could never clearly answer. So let’s finally clear it up: SOON
Jokes aside, let’s talk facts:
The new base is looking good already. There is a new render backend for CEF which means improved performance. Thanks to the great CEF community we were able to include a patch which makes it possible to bypass the CPU when rendering resulting in the possibility of using WebGL and further reducing input latency.
Looking at the game itself we have finished our new API which we use to communicate internally with the JC3 base game. At the moment all 1.0 features are working, including some new ones. The new API was realised with less layers between our code and JC3 which results in less points of failure and improved performance. We also no longer need to write a wrapper for each feature, which mostly took us time to work on the feature itself.
Tethering is looking really good so far despite some issues with physics and vehicles. We hope to resolve that really quickly.
We have already implemented some new API functions but we have not reached the limit: More are soon to come. The scripting API is most of the time the easiest part to expand because we only need some lines of code to link internal functions with the API. That means it’s usually the last thing we do.
At the moment we are really working on ironing out bugs before we give a first version out to our broader testing team. There are still some features for 1.1 that need some more time or do not function correctly - e.g. problems with skins (wingsuit causing crashes) and with objects (still moveable after spawning, therefor desyncing). There is still some work let to do, bugs to iron out and crashes to fix.
Overall we are very near, after extensive internal testing, on releasing a beta. At the moment we are aiming for a beta release for interested users somewhere in August - provided that there not any major issues occuring. *gg*
The last thing to say: We are very sorry on how everything went till now. Our intention was certainly not to put you off with “soon” for a very long time. Our intention was to inform you on progress as soon as we knew development was going forward and to then release regular updates as we used to in the past. I really hope that I could give you a big and deep insight into the current situation. I hope we could make clear why the patch has been delayed and that work is resuming at a normal pace again. If you have any questions about 1.1 please post them directly into this thread - I am glad to give you all the answers you may need. I still have to announce that there will be no further blog updates on 1.1 till the public preview version since we do not want to interrupt the flow of information in case of another unexpected job related development halt.
Greetz,
your Community Manager aka. master of the pugs

Waddup, your administrative issues are back again with yet another nanos world related blog entry. WHOO!
This blog is primarily about the progress we made on our default map “Armstrong”. We experimented with Armstrong and world creation. Finally, we became world creators. Secondly, we want to talk about our latest team member: Let’s begin!
A new Kiwi for nanos
May we introduce Kieran, aka. Protato aka. EonZenex ( @Legion_Zenex). Kieran is from New Zealand; Thus, he is our new nanos Kiwi, beside our moderator Jeff, better known as “Jeef”. He joined our team two weeks ago. He helped us a lot creating Armstrong with his magical terraforming skills. We welcome him to our team and are thankful for the progress, which wouldn’t be made without him.
Progress on Armstrong - That’s one small step for mankind, one giant leap for us
During the previous week we experimented a lot with Unreal Engine and the world creation, and we are happy to announce that we have finally created our first map. Eventually Christoph and Justus, but at first Eddy, worked a lot on the creation of our landscape. However, it was none other than our spot light team member Kieran, who created the world you can see in these pictures:
Terraforming is fun, but also challenging.
Just to remind you and anyone who doesn’t follow us on twitter yet: We started from scratch, with the picture our producer Malte drew during our nanos world team meeting on an iPad:
With this picture we started with the creation of height maps. For those who don’t know what height maps are: You can think of them as terraforming blue prints.
It was especially Eddy taking the first steps. Our first terraforming blue prints were used to explore the power of Unreal Engine and to set up the first work flow (for those who understand terraforming: we set up all necessary options in Unreal Engine, imported the height maps, worked on the landscape materials, and set everything up for sub-levels). Finally, we created all necessary git repositories for our team.
Even though we were happy with the first results, we knew they were not good enough. To put it in other words: we needed more terraforming power.
Therefore, we decided to use a piece of software called ‘world creator’, which is our terraforming software (https://www.world-creator.com).
Then it was time for our spot light team member Kieran: he understands how to form worlds and how to use ‘world creator’. Inspired by real world locations from Hawaii and China it was he who created our final Armstrong map:
Next steps
The coming week, we will create some more details and finally we aim to import the final version in Unreal Engine.
We also work on the material for our landscape, especially Eddy and Kieran work together on this task. Therefore, we are going to collect real world pictures as a basis for our decision, which textures we want to use for it.
Nevertheless, we already tested some standard textures in world creator to get some first impressions how the map could look like. Of course, we don’t want to exclude you from the results of this first test:
The next blog #5 is going to be about the cities, which will be located at the coast region, the small easter egg on the small island and about the cliff and mountain region.
So, that’s it for now. Stay tuned and don’t miss the latest news, which you will find first of all on our social media channels!

Heyho, your administrative issues are yet back again with another nanos world blog entry!
nanos world - work weekend
As many of you have already noticed via our social media channels, a big part of our team has met between the 2nd and 4th of March at the home of Dennis. There we worked on nanos World in a personal atmosphere and discussed the most important points of the project.
Besides having fun, which is very important for such a meeting, we had a very productive workflow. This is why we will do another one in the future. For us it is very important that our project is transparent to you and that the community is involved in most of the steps. This is why we want to present you this weekends output.
nanos world default map “Armstrong”
On one hand, nanos World is characterized by the nearly endless possibility to change the game and to have a flexible base for your own experiences. On the other hand nanos World should be accessible not only to experienced coders, but also to amateurs trying to create their first experience. This is why our default map “Armstrong” exists.
This is why it is very important to us to make the default map editable and expandable. It should be possible to use it for many different types of gamemodes.
First we discussed which gamemodes can be expected to be played by the biggest ammount of people. We plan on shipping free community-gamemodes in the beginning, which means you can build upon those right from the start. This includes gamemodes like survival, roleplay, deathmatch, battle royal, races and stunting.
Following these first design decisions we talked about the vegetation of Armstong. Here we wanted to follow a “carribean” design, which we have already planned previously. We also looked to Sri Lanka nad Hawaii for inspiration: With photos and Google World we made our mind on what we really wanted to achieve when it comes to the overall design of the island.
Afterwards we used real data of islands, which exist on our planet, to create our very first draft of our default Map. The result was this hand-drawn mockup:
blue: Urban
green: Natural (forest and floor space)
brown: Hills / Cliffs / Mountain Regions
yellow: Shores and Sand
At the moment we are working on a detailed mock up of the map, which will be used as base for our mappers.
The map is planned to be 4km x 8km (13.123,4 feet x 26.264,7 feet) and, as said before, shall be expandable by the community.
At the moment we are planning on a main island with small villages and a capital located in a bay. The capital should contain a small airport and harbour. Each villages and cities will be connected via streets, which can vary in size. When planning those we are focusing on also making them usable for races.
The forest (green on the map) links two mountainous areas on the map and therefore is used as a valley. Besides modern elements we want to also include historic sites such as ruins, which would be the perfect base for survival or DayZ alike projects.
The smaller northern islands are planned to be smaller and should only include small villages, hills and nature. The city in the more southern island will include a small easteregg.
Once we are able to show you some first ingame impressions of our planned landscape we will publish them directly via Twitter, Instagram and our blog.
The "Capital”
The capital shall be many used for roleplaying (e.g. RP, Cops & Robbers, Reallife) and will therefor be designed with that in mind. We will use our years of experience in various multiplayer projects to design it so it can be perfectly used that way.
For us it is important to include service buildings such as hospitals, fire stations, police stations and a town hall. We also plan on including other important sites such as theatres, cinemas or a stadium.
Besides that important infrastructure and a road layout, which can also be used for inner-city racing, we are planning on creating different districts with their own charme, such as an older-styled inner city, a banking district, a ghetto, a noble district, an art district and various types of industries.
Of Course we are also transparent about the cities development and will give you first peeks on it during its creation via Facebook, Instagram, Twitter & Co.
Other examples for gamemode inspireddesign
When looking at the city we have not only focues on rolepla, race and survival. When it comes to deathmatch we are working on making the terrain useable for proper playing rounds. Here we will mainly focus on details such as smaller alleys and backyards, which lead to complicated and interlaced areas. This should make a base for counter-strike based game modes or stuff like battle royale. Wide open areas such as plazas could be used as places for loot.
As said before: Technically it will be possible to place additional objects on the default map to give it your very own touch. This makes it possible for each server owner and community-developer to create individual experiences.
Implementation
At the moment we are working on the landscape design itself. Once that is done and we have technically implemented it we will start working on the layout of flora, fauna and streets. Afterwards we will realise the needed building models via a boxing-out modell and implement them into the environment.
More about the meeting
Besides working hard on nanos World we also did a lot of teambuilding and also had quite a fun time. We went eating, partying and watched movies. Pictures say more than word’s so here we go:
We hope that we could give you a small insight into our project and that you enjoyed it. See you next time!

This week we added a lot of additional TRACE debug messages to enable us to track down bugs easier and more efficiently. We also added more debug code to track the performance for specific parts of our code, this way we have an easier way to see what needs improvement.
We have also been working on updating CEF to the latest version based on Chrome Stable 64. Finally we worked on further improving our internal dump analyzing tools.

Heyho folks, your administrative issues are back again with yet another Just Cause 3 Multiplayer 1.1 development blog!
Current changes
We have improved massively on the way logging is done. We now have much more control over what is logged, and we now write to a single log file instead of a separate one for each component. This way we can send the log with a crash dump. We will be changing our internal tools to utilize this change so during dump analysis we can easily spot the action that caused the crash. This will help us in the future with tracking down issues quicker, fixing the bugs that cause them and making internal testing more efficient. We want to improve further upon this, but these changes already improve upon our previous system immensely. This whole system is something that we could, and probably will, utilize for future projects as well.
We are also still tracking down some CEF issues which for some people causes the mouse wheel to stop working in the latest beta build. The problem we are having with this is that none of our team members have succeeded in reproducing the issue locally, which makes it quite hard to figure out what is causing the issue.
Finally, we worked on adding a couple of missing pieces in functionality that we missed during the re-implementation of the client, we estimate this will be finished sometime during the following week.
This was the development blog for this week. See you guys again next week, stay fresh!

Heyho folks, your administrative issues are back again with yet another Just Cause 3 Multiplayer 1.1 development blog!
Main topic: Internal stuff
This week we spent most of our time on creating internal tools to help prevent issues, like the ones we’ve been having with the handling system, from happening in the future. It will also help us implement new features much faster, going forward.
We continued the work on our new HTTP code which will fix all those annoying file transfer issues. And finally, we did a lot of stuff behind the scenes, which we can't share right now.
Changes, new features and fixes (1.1):
Continued work on improving performance related to web windows
This time we started implementing culling for stuff that is currently not in view or required for the final image. PERFORMANCE HYPE.
Currently trying to investigate slightly inconsistent frame times coming out of the compositor, hopefully gonna submit a PR to upstream, so everyone can enjoy this
This was the development blog for this week. See you guys again next week, stay fresh!

Heyho folks, your administrative issues are back again with yet another Just Cause 3 Multiplayer 1.1 development blog!
Main topic: Investigate Reported Issues from 1.0.6 Beta
We start today with a couple of reported issues from 1.0.6 beta.
First up, there still was a critical issue in the handling implementation. We were able to fix this eventually, but it did take a bit longer than expected.
We added a ‘.enabled’ property to checkpoints which restores the behavior from 1.0.5 and before for the ‘.visible’ property. This means that a ‘.visible’ doesn’t disable a checkpoint it just renders it invisible.
We have also fixed a couple of issues relating to the internal message handling that arrived on the client for entities that hadn’t finished creating yet on the client.
Some critical issues were fixed in the changed code for file transfers, we still see more errors coming in though and we are still investigating these issues. We are also currently working on a completely new implementation for all file transfer related code for 1.1.
Lastly we fixed some bugs in the changed mouse implementation and are porting this over to 1.1.
Changes, new features and fixes (1.1):
We continued implementing small missing things for full feature parity with 1.0, except the new features already in there
We're currently working on further performance improvements in render code
CEF now renders into a shared handle. This still requires some investigation of other chromium internals and is not considered stable yet.
As we always have to use pixel data, because of the multi layered nature and mouse events we changed quite a bit on how we are doing this. The GPU Readbacks are not triple buffered and happen in the background unrelated to other render code, this avoids possible Pipeline stalls. The actual render to the texture is double buffered to avoid pipeline stalls in the chromium implementation
Several other CEF fixes are are submitted to upstream, but not yet merged, to fix issues with changed chromium implementation
This was the development blog for this week. See you guys again next week, stay fresh!