Stationeers Dev Tracker

Hotfix deployed v0.2.4036.19180
* Fixed mining belt Mk2 not working with Mining Drill correctly.
* Fixed Arc Furnace new collision was preventing accessing the entry slot by hand.

Hotfix deployed v0.2.4036.19180
* Fixed mining belt Mk2 not working with Mining Drill correctly.
* Fixed Arc Furnace new collision was preventing accessing the entry slot by hand.

Sorry, Hotfix is being deployed now. Will be out in about 30mins. Fixes this and mining belt issue.

Sorry, Hotfix is being deployed now. Will be out in about 30mins.

If your friend and you restart steam and the game, and rehost, it is a workaround.

We have discovered a few errors with SteamP2P. These are fixed on the beta branch, and we will be deploying a patch to fix this as soon as we have finished testing. Apologies for the bug it is very annoying.

Yes there was quite some debate about this among the team.

Likely in future we may split the IC Chips into multiple types, with some having more instructions than others.

There is a reason to directly reference, the "batch named" instructions are not *quite* as performant as directly referencing something. The cost of finding the device(s) that you want to change goes up the more devices on the network.

The batch named instructions are the same as their batch counterparts, except a final 'test' is applied on the name hashes. So to do the batch named commands, the processor has to loop through all the devices on the network.

It is important to put this in perspective though. The list of devices is cached, and to compare each device it simply uses a "hash" (does one integer equal another). These are *very* simple operations for a computer and it can do thousands or tens of thousands of these kind of operations without breaking a sweat.

A... Read more

Originally posted by DeathBirdsFly: Ok, I understand now. So you have to have at least one device on both networks acting as a bridge of sorts.

You can use db:0 and db:1 to get the two connections for the IC itself. That would mean the IC could be the bridge between two networks.

Originally posted by DeathBirdsFly: but I don't see how you share that data across a network boundary

The IC can access *any* network connection off of a device, even ones not in the same network.

So if you have d0 bound to a logic memory, and another entire network on the *other* connection of the logic memory - you can access *both* cable networks for read/write. This allows IC's to access cable networks for data sharing that they are one removed from.

Note in the latest update, we added constants for rad2deg and deg2rad to help with conversiuon instruction creation.

Hi there, what are you trying to do that is causing this to happen? Is this happening when you try and host a game? or is it when the game itself is booting?

Many of those errors are not fatal, just old code bloat that is throwing warnings, however this one is concerning:

ArgumentException: Partial byte sequence encountered in the input.
Parameter name: string
at (wrapper managed-to-native)
...
Assets.Scripts.Networking.NetworkManager:FetchPublicIp()
Assets.Scripts.Networking.NetworkManager:Init(TransportType)
Assets.Scripts.GameManager:Awake()

This error indicates your computer is trying to host a multiplayer game, but failing because the response from your computers network device is truncated. That means, the game asked your network device what your IP is, and halfway through it's reply, it stopped talking.

Are you on beta branch? I had introduced a bug on beta branch that was causing an issue with connectivity of components

One of the major changes in this area was the addition of deep miners. Cows are Evil has a great video outlining them:
https://www.youtube.com/watch?v=WgXzCSkLtS4

Have you tried this guide?

https://github.com/rocket2guns/StationeersDedicatedServerGuide

Many of the guides out there are for the old dedicated servers. We did a major refactor, the new dedicated servers (and multiplayer in general) is much better than before. Sadly configuration is completely different now though

Let us know if you have any problems

Note high CPU utilisation occurs because the game is optimised to use more “cores” on your CPU than games typically do. This is because Stationeers does a lot of simulation, so it is created to use a lot of “threads” on these cores. This is called “multi threading”.

I’ve seen a few threads pop up suggesting the games high CPU usage is because it is not optimised. The reality is that games can be very unoptimised and have low CPU usage. Multi threading is not very common as it creates a lot of complexity.

Round based play is something we have wanted to do, given the games inspiration from SS13. We realized though we needed to overcome a number of hurdles before we could look at round based play, particularly performance in terms of size of bases as well as multiplayer.

The old multiplayer system was heavily coupled with Unity (the game engine) making it difficult for player avatars to be separated from the players connection. Additionally, the game suffered performance issues in medium or large bases especially with more than three players.

With the new multiplayer system and our further performance improvements there are many less obstacles in the way of what is needed to run public servers and the like.

That unfortunately doesn’t mean we will be rushing straight to these features. We have been methodically going through core features and redoing them with a consistent vision of how we see the game, given what is possible.

Certainly I can see u... Read more

I have added the ability to repair Aimee (for now, using Duct Tape) as well as the ability to desconstruct (using a drill) into revision 18349. This will deploy onto beta during the next deployment.

We are working hard on this. Because we completely replaced how multiplayer was done so that we could fix the myriad of issues with it, as well as moving the requirement for the game to have steam running, it necessitated us redoing the Steam P2P from scratch. This has the added benefit of us being able to really properly implement steamp2p and give a much more stable implementation.

Will include a full status update in each patch notes. It is a major priority at the studio - so the task gets priority over many other things and has company resources available to it. As soon as we can we will get it out for testing.

the 'lb' is the instruction, means "load from batch". In other words, it will load a variable off a batch of devices.

the 'r1' is the register to store the result into

the 'battery' is the type, being a "prefab id", which is a type identifier. In this case, it refers to all Station Batteries.

the 'Charge' is a variable that exists on batteries. Different types of objects have different variables you can read. Charge is the total energy.

the last input 'Sum' is the method to use when taking all the batched devices. Should they be added up? Averaged? The Maximum? or Minimum?

As recommended, if you want to know the total charge of all the batteries on a network, you might be best to use "Ratio" and the method "Average". This will give you the average ratio (0 being totall empty, 1 being totally full) across all of that kind of battery

Note the reason for this change was discussed extensively at the project level and has three core elements

1. To standardize player experience for development
It had become almost impossible to balance the and game and add content that was consistent when there were n number of conditions players could adopt.

2. To focus the experience towards an overall experience "intent"
Players often describe this as the "reason why" or "endgame". In game development this might be described as the "hook". We feel as a studio we have become quite good at making *systems* for systems based games - but we need to make those systems *matter*.

To help with this focusing the experience more allows us to develop towards a specific experience and goal. This doesn't mean we don't intend to support and allow players to craft their own experiences (which is why we left the settings in the ini), but we needed to start working towards this if we ever hope to achie... Read more