Key words come to mind "Interpolation" and "Dead Reckoning" which are the technical terms that describe fluid, smooth multiplayer experiences. Well,  based on a video I have seen on Microsoft flight simulator 2020.

Case in point, it has been 10 years that Shores of Hazeron has been open to the public, and I believe it is time to drill this functionality into the game before an aspirational steam release.

Refer to the video's below to see my usual experience of the game's AI, animals and other players movement when observing from my own perspective (they all look the same)

https://youtu.be/Zddbo1-yn0c?t=44

Note that, that video is from 2015 and is still relevant to the issue at hand.

https://www.youtube.com/watch?v=6o7n6reHqLo

Crew movement; video as of this week. Same for troops etc and other players appear to slide show as well as they run - you can imagine what PVP is like...

https://www.youtube.com/watch?v=YyfguFib11E

Nature's animals, same as crew etc, video taken as of this week.

A good article on the topic as well: https://www.gamasutra.com/view/feature/1...g_for_.php

Now i'm not going to pretend to be an expert on the field, but i'm pretty sure a lot of other multiplayer, and even more faster paced games employ some form of this methodology in their design, and hopefully, we see the same being employed in Hazeron.

Similar to Elite: Dangerous, perhaps a method for preventing atmo-diving/sundiving would be to upgrade the grav drive mechanism into a semi-warp style drive, where the AI will travel towards its targets in a fluid fashion as the same before, and then designate all celestial objects with an invisible 'exclusion' zone around it, upon an accidental AI malfunction, the ship will collide first with this 'exclusion' zone instead of the planet itself, rendering the occupants unharmed as the grav drive 'cools down'.

Grav drive wouldn't be as fast as the warp drive, but it has a distinct bonus compared to rocket driven space craft. So this is an idea to change the mechanics of how a grav drive behaves in relation to its surroundings rather than its arbitrary speed.

So after surveying a bunch of systems, I was using the observatory report function to decide where to go. 

I entered a system, XYQ'RNH'OH'h, and found that the observatory report was incorrect regarding the star type and layout in the system.
Here is where it gets interesting, the exploration report and system map were completely different. Post survey everything was fine because the exploration report is removed post survey from the map. 

I'm guessing this is a bug

Not a bug report per se, but a performance complaint. However, after testing the design I posted in this post, it seems like the computed volume can also be very wrong.

It seems like the time it takes to compute obstruction volumes scales up to the volume, regardless of the actual number of faces, which does not have to be high (for example, you could have a very large tetrahedron). Iterating on a very large design is time-consuming when it takes several minutes to enter preview mode. Actually it's scaling up with extents and not volume; the performance issue mainly comes up in the use case of high volume ships, but even this 1600m^3, 454 byte file design takes a very long time to compute obstruction, because it is rotated so that its bounding box covers all three dimensions: http://arcana.moe/lagstick.SoH

I can only imagine that every single unit cube within the design extents is being individually tested for being in the hull. I don't know the real details of how the designer computes obstruction, and I know you have to handle many inexact cases, like hulls that intersect each other or which are not properly solid. But I really really hope there is some way you can improve the computation time to not scale up so high with volume, because the current performance magnifies the time it takes to fix design issues, like pathing, that require a lot of tweaking and testing in the previewer.

It would be useful when upgrading to a new manufacturing building if there was some way to transfer all the processes configured in an existing building, maybe by allowing copying the configuration to storage media. It is particularly tedious to copy the production lines of an airport repair shop, which typically have many production lines to cover every type of module.

EDIT: Also useful when you just want to move a building somewhere else.

If you dock the Star Map, it'll get corrupted and stay corrupted even after undocking it, closing it, reopening it etc, until a reboot of the game.
this is on the Linux client.

After placing down an unfinished airport terminal, broker and capitol on a new colony, I have tried offering on the trade channel and get no response. Dean used his agent accounts to check the colony, and the airport/broker did not respond no matter how they were hailed. After placing down another airport terminal in the city, this new one started responding to hails and trade offers. 

It seems like the order I placed the buildings may have caused this, as I placed the airport first, then the flag claim, then the broker, then the capitol. However dean was unable to reproduce this. I also originally sent a shipment of stone to the colony, which was accepted and stored fine, so maybe this caused issues?

We could not find the cause of the problem and dean suggested posting this bug report so here it is

In addition to the dedicated sell button in the F11 menu one should be able to hail a building on  the voice channel while standing on its plot.
IMO, the benefit of this would be consistent with how overall trade works and help to establish a vague sense of "comms range" for various building types

Even on the highest grid brightness setting, the grid is very hard to see:


I wish there was an option to make the grid thicker; it seems that with just 1-pixel thick lines there's a limit to how visible the grid can be.

Walking, Rain, and Thruster sounds completely broken after client update. Sounds are not played, a strange crackling occurs instead.