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

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.