Ship doesn't cycle mission orders, for example when selling items or categories to a city with an officer in chain of command and having the Con. 

Ship also cannot sell electricity to a city anymore either, not sure if by design or if a bug but the sell electricity is still an option.

Bug with flying the space rocket in system, upon reaching near orbit of destination planet with an established city, rocket just freezes in space and doesn't move again - though you can still exit vehicle.

This is cool. I had to laugh at the name of the company.

https://www.orrerydesign.com/the-genesis...OWn9EJuHwo

So this started yesterday but I ignored it. After hearing from other players similar issues with ships diving into planets it started to makes sense. I know it's not the ships because I have built these ships a few times with no issues. 

In short:
- Any existing or new ship I build, the AI is unable to path to their stations
   - The ships: Atlantis, RC-232, and a few more. 
   - I have to order the crew to mount me and I carry them to their stations one at a time
- If I order my crew to go orbit above a planet or city they either dive bomb into the planet or dip a bit into the atmo.
   - Right now this is consistent.


I don't know if this is my star system only. I am looking into that.

After capturing the pirate base, I built a city in its place, after some time I discovered that I have two cities with identical names. The city is called Divina. Also, I cannot place a police station here because it creates overlapping jurisdictions between cities.

Think like a square where if a specific category of item is in the hold the mesh appears and a player can click on the mesh and pull one of the items from the hold adding it to the Avatar's inventory. 

This would enable buildings or ships to have interactive item racks, tables, food replicator, bars, ect...

I noticed a lot of ship got destroyed by extreme atmosspheric stress even if they were just being in close proximity of world, passively in orbit without flying around or moving.

It seems to have appeared only recently.

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