Steam Update
The solo playable Hazeron Starship is being tested now. All features are complete. There are some things that remain to be tested, to insure the story can be played through to the end.

The solo version uses a data file created by querying the Shores of Hazeron database. It stores some basic stuff that usually comes from the database, such as pirate empires. It also stores building and spacecraft blueprints published by me.

After the update today, I will post a new space station design, in G drive and rocket versions. It is a usable simple design that will be included in the solo play data file. It will appear in the exchange as Del Rey Station - GDrive and Del Rey Station - Rocket.

The release date on Steam is still somewhere around the first of December. I'm not quite ready to make the "coming soon" announcement. Time has been slipping away very quickly and it always feels like there are a million things to do, though my Silverwill list is pretty short.

Primeval Nerf
Primeval world is gone from Shores of Hazeron. It grew up and became Hazeron Starship.

Jurisdiction Indication
When placing buildings, the cursor now shows the name of the city jurisdiction, if any. This shows which city contains the building about to be placed.

Child Spotted
I spotted a child and their hit points were reported as 46/26. This bug was fixed.

Building Design Origin
Previously, the largest possible building site required that the origin be at the center. This was because design limits were defined as maximum absolute coordinate values, in each direction. This created an unfortunate constraint.

The origin of the design is the insertion point when it is placed on the terrain. It determines the altitude of placement. Because of that, it is often desirable to have the insertion point on the road edge of the site, so its altitude works when placed next to an existing road.

The designer was changed to allow the origin anywhere within the site's 3D extents. The maximum size of a site was not changed. This should not have a negative effect on any existing blueprints.

Building Patents
A bug was fixed that caused buildings to not post their patents to the empire under certain conditions. I noticed this when I built a second electronics factory and it had no patents to do anything, yet the first electronics factory had patents. It turned out those patents had not been recorded with the empire for everyone else to use.

Landing System Snafu
It is very frustrating to activate the landing system on your ship only to be told that there are no empty parking spaces.

Landing systems will now replace a parked vehicle with an incoming vehicle, when an empty parking spot cannot be found.

The parked vehicle is replaced at the moment the landing vehicle is recovered.

The replaced vehicle is lost.

A parked vehicle will not be replaced if there is anything or anyone in it.

Vehicle Transporter Snafu
Similar to the landing system snafu, vehicle transporters will sometimes be useless because all the vehicle parking spots are full.

The solution was not quite as straight forward as the landing system. In this case, the parked vehicle is removed at the moment the vehicle transporter is activated.

The replaced vehicle is lost, even if the caller does not enter the vehicle transporter portal.

Transport to Fence?
Fences are no longer listed on the list of transporter destinations. They were never supposed to be there. A bug allowed them to appear there.

Station Cargo
I am the emperor, aboard an empire space station. I am in its chain of command but I cannot see its cargo listed on the cargo manifest.

This was fixed.

Indigenous Species
The indigenous species of every unexplored planet is my own. That means that as long as I explore previously unexplored space, I will only encounter my own species. This has always been the rule in the multi player game. You knew when you crossed paths with another player.

Unfortunately, this does not work for the solo game. There are few other players to seed the galaxy with their species. A solo player can have up to six avatars, just like the multiplayer game. That is not enough.

There is a table of distribution for the pirate empires, used to determine where they live and in what proportion, throughout the game universe. Each pirate empire has a different sentient species.

From now on, when an indigenous encounter is triggered on a world with no established sentient species, there is a 20% chance the species will be that of a pirate empire, rather than your own. The pirate empire selected is based on that table of pirate empire distribution.

Atmodives are such a Hazeron institution, it seems almost blasphemous to make this proposal...Every so often they overwhelm the bug section of the forum and the grievance section of the Discord. Usually some tweaks to navigation and AI processing are made, they quiet down for a while, then we get another flare-up a few moths on.

After I personally atmodived from the helm like the true NPC that I am, I started thinking about a small change that could help fix them from the opposite direction: the direction of remedy, rather than prevention. I don't think we've ever tried that before.

Hull stress is the only instant kill for spaceships in Hazeron. Even black holes and the centres of suns inflict damage over time, which tough ships can tank long enough to try a few emergency saving throws. Why not change atmospheric stress damage in the following way:

Once a ship or vehicle exceeds its max rated atmospheric or underwater speed, a massive alarm goes off. Damage is now inflicted at a rate of 20% total hp per second over 5 seconds (or whatever). Once the alarm is active, that ship's AI helmsman receives maximum server processing priority for the duration of the emergency, and his sole job is to slam the breaks and put on maximum reverse thrust until the ship is back under safe speed. A human helmsman would, naturally, try to do the same.

Atmodives would still be dangerous and almost always costly, just as they're meant to be for careless pilots, but not instantly and universally fatal. A ship with a cyclic mission including repairs would be able to survive multiple atmodives, costing resources (it's not a get-out-of-jail-free), but sparing players the massive frustration of starting from scratch. Any good?

I build a biodome on a gas giant core, where the terrain is uneven and curvature high. Now, although the area inside the biodome is graded flat, I cannot build any roads on it, since, in many areas, the start and end points are too high or too low compared to the "virgin terrain".

In some cases, it then becomes impossible to connect buildings within or between biodomes without creating useless filler buildings just to get them in range of each other.

I submit that roads should consider compare their start and end heights to the existing height of the graded or site-graded terrain, not the virgin terrain. I realise that this will allow strange things to be done, but these strange things are less harmful to smooth and enjoyable gameplay than the frustration of not being able to place roads at all.

Crew have a particular problem with navigating ships at the moment. In particular, they often go too fast and walk straight past the place they are meant to go. They then get stuck in an endless loop of turning back on themselves and overshooting in first one direction, then the other.

To my layman's eye, they need to judge more leniently whether they have arrived or not. Then, if the same order is given again (i.e., they are ordered twice to go to the same coordinates) their tolerance needs to get progressively stricter. Perhaps their movement speed should also slow with repeated identical orders. This would mean that they overshoot less often, while the ability to very precisely position them would not be lost.

(CURRENT WORKAROUND: Give them a "stop" order (Ctrl + S) when they are roughly where you want them to be.

EDIT: This could be related to the current extreme prevalence of overshooting waypoints when AI is controlling a ship, too - maybe a more general AI problem?

Say I have a small source of high quality metal, together lots of low quality metal. I want to make sure the small, high quality source is used for important things like shipbuilding and weapons, while bullion, plantpots, picture frames and so on can use any old junk. 

It would be a practical and easy quality-of-life improvement to forbid certain processes to fetch input resources above a certain Q.

As far as we know, decay is a necessary evil to prevent server resources from going to waste on cities that aren't being used. But since the change to the Land claim system, decay of cities has felt really confusing.
I think we would all love it if decay didn't have to be a thing at all, since exploring and encountering other civilizations is one of the awesome things in this game. So without the full understanding about the reasons for decay, lets discuss alternatives.

If the number of cities is what is actually costing the most server issues, then I really don't know what can be done, aside from upgrading the server hardware. But storing information shouldn't be as big an issue if it isn't actually being used.

Assuming that it is the amount of computation it takes to handle the large amount of cities and units in them, maybe it would be possible to make the cities go dormant when their founder/owner/claimer hasn't been online for 7-30 days.

All manufacturing could either stop completely, slow down a lot, or be more selective; such as only working essential jobs.

Something similar to the old neglect mechanic could make the military units despawn and otherwise leave the military bases nonfunctional. And leaving the worlds defenseless against attacks in the process.

See also: (Idea thread) Automatically Add To Land

With Gen IV avatars, the "draw headless body" or "draw no body" options in the scene menu result in the whole body still being drawn, or the hair only still being drawn, respectively.

A brief description: If you produce vulc or mag on another planet in the system, you cannot upgrade hull using those materials on another planet unless you produce the material from a smelter.

I had a world that had vulc, but didn't produce it there and the option to upgrade hull wasn't there until I placed a smelter and had it make vulc.

Steam Update

I've been working pretty hard to make Shores of Hazeron totally solo playable, in preparation for a Steam release. A huge amount of work was needed to stitch everything together.

This was one of those great house keeping opportunities, from a coding perspective. It was a chance to unify some code under a common interface, code that was getting duplicated on the client side and on the server side. That work flushed out a couple of bugs.

The first wave of changes is complete. All game functions are ready for solo use. A fair bit of testing is needed.

I started building my first solo city. With a little agent-level help along the way, the city could be launching spacecraft by the end of today.

The bug I am currently chasing causes a new avatar to sometimes start in orbit, suffocating to death. It happens a lot in the solo play version. I ended the day on Friday with the bug in hand. The cause of the bug was a surprise, not at all what I expected. The bug will be fixed before I continue building my city.

I am tentatively planning for a Dec 1 release date of the Steam version. That seems very achievable, at this point.

Server Crash

The master server crashed during the weekend, which broke the server grid. It is back up again.

Server software was not updated. Changes have been made that require a coordinated release of a new client with the server. I am not quite ready for that yet.

I didn't have these problems before but since a week or so, ships constantly blow up when approaching a planet or when landing at an airport. I give a mission order to the AI captain, like "orbit over city" and when we get close to the planet it's KABOOM! Ship destroyed. Also happens a lot when landing at an airport. It's always with an AI at the helm. Maybe they approach too fast or something.

The ships we fly cost a lot of resources. It's frustrating to say the least. I would be very grateful if this was fixed. Otherwise I may as well just stop playing cause it's a real game killer.